[Bug 15350] New: [Regression] dinput wrong keyboard layout in Tomb Raider Anniversary / Legend
http://bugs.winehq.org/show_bug.cgi?id=15350
Summary: [Regression] dinput wrong keyboard layout in Tomb Raider Anniversary / Legend Product: Wine Version: 1.1.5 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: directx-dinput AssignedTo: wine-bugs@winehq.org ReportedBy: netfab@gmail.com CC: aric@codeweavers.com
Hi,
Today I upgraded wine from 1.1.0 to 1.1.5 on a gentoo system which have a french keyboard layout (AZERTY).
When I run Tomb Raider Anniversary or Legend, the keyboard auto-magically switch to an english layout (QWERTY). But, I have no problem in World of Warcraft for example.
I made some tests, and I discovered that this behaviour is here since 1.1.3.
Then I made some regression tests from 1.1.2 to 1.1.3, and found that the guilty commit is :
http://source.winehq.org/git/wine.git/?a=commit;h=304ff3c7280a53b7cbadfa83ea...
Reversing this patch on the 1.1.5 release fix the problem.
Please let me know if you want more infos or tests.
Thanks.
http://bugs.winehq.org/show_bug.cgi?id=15350
Fab netfab@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |netfab@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=15350
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
http://bugs.winehq.org/show_bug.cgi?id=15350
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|[Regression] dinput wrong |wrong keyboard layout in |keyboard layout in Tomb |Tomb Raider Anniversary / |Raider Anniversary / Legend |Legend
--- Comment #1 from Vitaliy Margolen vitaliy@kievinfo.com 2008-09-21 11:13:55 --- What switching the layout? Wine doesn't have any layouts. Explain step by step what you do and what exactly happens.
http://bugs.winehq.org/show_bug.cgi?id=15350
--- Comment #2 from Fab netfab@gmail.com 2008-09-21 11:30:42 --- I know that wine doesn't have layout, but when I run Tomb Raider, I am in the main menu, then I go to Options --> Controls to set-up my keys.
Then if I click on "up" to set-up the up key, if I press the : - "z" key, then the program will receive the "w" key instead of "z" - "a" key, then the program will receive the "q" key instead of "a"
--> in tomb raider, the keyboard layout seems to be qwerty instead of azerty. I didn't test all the others keys.
My keyboard is in azerty, and I don't have this problem in others programs under wine (WoW for example).
http://bugs.winehq.org/show_bug.cgi?id=15350
--- Comment #3 from Vitaliy Margolen vitaliy@kievinfo.com 2008-09-21 12:27:32 --- Thank you for explanation. This is some-what a long standing problem - not being able to detect correct keyboard layout. Can you attach output of WINEDEBUG=+keyboard,+key wine game.exe ?
http://bugs.winehq.org/show_bug.cgi?id=15350
--- Comment #4 from Fab netfab@gmail.com 2008-09-21 14:08:07 --- Created an attachment (id=16200) --> (http://bugs.winehq.org/attachment.cgi?id=16200) requested output with wine 1.1.5
output of WINEDEBUG=+keyboard,+key wine tra.exe
(with wine 1.1.5)
http://bugs.winehq.org/show_bug.cgi?id=15350
--- Comment #5 from Fab netfab@gmail.com 2008-09-21 14:12:43 --- Created an attachment (id=16201) --> (http://bugs.winehq.org/attachment.cgi?id=16201) same output with patch reversed
You didn't say if you want the output with or without the patch reversed ^^ So in doubt, I post both (don't know if it will make a difference). Thanks.
http://bugs.winehq.org/show_bug.cgi?id=15350
--- Comment #6 from Fab netfab@gmail.com 2008-11-08 09:51:13 --- Created an attachment (id=17144) --> (http://bugs.winehq.org/attachment.cgi?id=17144) fix azerty keyboard
This bug also occurs in the demo of Tomb Raider Underworld. Since wine 1.1.7, I must apply the attached patch (reversed) to fix the issue, see [1].
To summarize : - set your system to use an azerty keyboard - launch a program through wine which use dinput (all Tomb Raider series including demos does it) - in the program, try to use your keyboard : some keys will be inversed : - "z" will be interpreted as "w" - "a" will be interpreted as "q" - ...
[1] http://source.winehq.org/git/wine.git/?a=commit;h=bb2d8577c3d68ddaa6a9571e0c...
http://bugs.winehq.org/show_bug.cgi?id=15350
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
http://bugs.winehq.org/show_bug.cgi?id=15350
--- Comment #7 from Dmitry Timoshkov dmitry@codeweavers.com 2008-11-10 22:09:15 --- This should be implemented using a VK to DIK table, and would be simplify things a lot.
http://bugs.winehq.org/show_bug.cgi?id=15350
--- Comment #8 from Aric Stewart aric@codeweavers.com 2008-11-11 07:26:24 --- Looking at this. I see that the french azerty keyboard has the same scancodes as a qwerty keyboard.
meaning that the 'a' key generates a VK_A but a scancode of 0x10. If under windows this generates the DIK_Q instead of DIK_A then my patches logic is incorrect.
I am attaching the source and mingw compiled test program run this in a console in Windows and press keys. they should print out direct input information on the keys you press.
I would like to know what the program generates for 'a' and 'z' under Windows.
thanks!
-aric
http://bugs.winehq.org/show_bug.cgi?id=15350
--- Comment #9 from Aric Stewart aric@codeweavers.com 2008-11-11 07:27:08 --- Created an attachment (id=17214) --> (http://bugs.winehq.org/attachment.cgi?id=17214) test program source
http://bugs.winehq.org/show_bug.cgi?id=15350
--- Comment #10 from Aric Stewart aric@codeweavers.com 2008-11-11 07:27:39 --- Created an attachment (id=17215) --> (http://bugs.winehq.org/attachment.cgi?id=17215) Test program exe
http://bugs.winehq.org/show_bug.cgi?id=15350
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase
http://bugs.winehq.org/show_bug.cgi?id=15350
--- Comment #11 from Dmitry Timoshkov dmitry@codeweavers.com 2008-11-11 21:22:37 --- I'm not sure why you need to run a test program, according to header file definitions DIK_xxx values can be directly mapped to the VK_xxx ones, and should not depend on any keyboard layout.
http://bugs.winehq.org/show_bug.cgi?id=15350
--- Comment #12 from Fab netfab@gmail.com 2008-11-13 04:59:51 --- Created an attachment (id=17256) --> (http://bugs.winehq.org/attachment.cgi?id=17256) output of test program under Windows XP
Here is the output of the test program under Windwows XP for an azerty keyboard, from A to Z, I added comments for each key pressed. I also pressed the "," key, which is the "m" key with a qwerty layout.
http://bugs.winehq.org/show_bug.cgi?id=15350
--- Comment #13 from Aric Stewart aric@codeweavers.com 2008-11-13 07:20:43 --- (In reply to comment #11)
I'm not sure why you need to run a test program, according to header file definitions DIK_xxx values can be directly mapped to the VK_xxx ones, and should not depend on any keyboard layout.
That is what I thought also. but the test program clearly showed that when the azerty 'A' VK 0x41 was pressed with a scancode of 0x10 it generated DIK_Q 0x10 so it was linked to the scancode and not the VK code.
Which makes the question as to what to do with the same scancode is generating different characters such as with the japanese keyboard where the scancode 0x1A was generating the DIK_AT.
I will try to find time to investigate this further.
http://bugs.winehq.org/show_bug.cgi?id=15350
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |liquitsnake@gmx.net
--- Comment #14 from Vitaliy Margolen vitaliy@kievinfo.com 2008-11-30 15:21:48 --- *** Bug 16288 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=15350
Jayme tuxnet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tuxnet@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=15350
volker.groeschel@sap.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #15 from volker.groeschel@sap.com 2009-03-03 01:07:31 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=15350
--- Comment #16 from Fab netfab@gmail.com 2009-07-14 06:18:54 --- Tested with wine 1.1.25, bug still present.
AFAIK, Microsoft DirectX is localized, so if wine wants to reproduce its behavior, wine must also be localized, am I wrong ?
http://bugs.winehq.org/show_bug.cgi?id=15350
Fab netfab@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #17144|0 |1 is obsolete| |
--- Comment #17 from Fab netfab@gmail.com 2010-04-06 03:35:46 --- Created an attachment (id=27233) --> (http://bugs.winehq.org/attachment.cgi?id=27233) minimal revert of the original commit
Bug still present in wine 1.1.42.
The attached patch is a *partial* reverse of the original commit. When applied, it restore the correct behavior for non-qwerty keyboards in dinput applications.
For gentoo users who wants to auto-apply it on each emerge, just run : # mkdir -p /etc/portage/patches/app-emulation/wine/ and copy the patch here.
http://bugs.winehq.org/show_bug.cgi?id=15350
volker.groeschel@sap.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |volker.groeschel@sap.com
--- Comment #18 from volker.groeschel@sap.com 2010-04-06 03:51:42 --- http://www.Metin2.de
is also affected from this regression.
To pick up loot you need to press 'z' instead of 'y'.
But in the chat input line everything is correct, i.e. a 'y' is a 'y' ...
http://bugs.winehq.org/show_bug.cgi?id=15350
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |adys.wh@gmail.com
--- Comment #19 from Jerome Leclanche adys.wh@gmail.com 2010-08-11 08:14:00 --- Can someone check whether bug 20453 is a dupe?
http://bugs.winehq.org/show_bug.cgi?id=15350
--- Comment #20 from Jerome Leclanche adys.wh@gmail.com 2010-08-26 03:57:49 --- Worms Reloaded appears to be affected by this issue.
http://bugs.winehq.org/show_bug.cgi?id=15350
Vitaliy Margolen vitaliy-bugzilla@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |peter.ganzhorn@googlemail.c | |om
--- Comment #21 from Vitaliy Margolen vitaliy-bugzilla@kievinfo.com 2011-01-25 08:41:14 CST --- *** Bug 19981 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=15350
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |304ff3c7280a53b7cbadfa83eae | |da458ff5959d1
http://bugs.winehq.org/show_bug.cgi?id=15350
sacrediou sacrediou@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sacrediou@yahoo.fr
http://bugs.winehq.org/show_bug.cgi?id=15350
--- Comment #22 from Fab netfab@gmail.com 2011-08-16 04:35:41 CDT --- (In reply to comment #19)
Can someone check whether bug 20453 is a dupe?
I think it is. Wine 1.3.26 patched with the patch from comment #17 behaves correctly, and I remembered unpatched wine having the same troubles with azerty keys on World of Warcraft.
http://bugs.winehq.org/show_bug.cgi?id=15350
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ian@infogroep.be
--- Comment #23 from Jerome Leclanche adys.wh@gmail.com 2013-05-25 13:05:54 CDT --- *** Bug 20453 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=15350
Berillions berillions@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |berillions@gmail.com
--- Comment #24 from Berillions berillions@gmail.com --- *** Bug 35469 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=15350
--- Comment #25 from Berillions berillions@gmail.com --- Still exist on Wine 1.7.11 Far Cry 3, Assassin's Creed series (AC1 to AC Revelations) are affected by this regression.
http://bugs.winehq.org/show_bug.cgi?id=15350
AnAkkk anakin.cs@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |anakin.cs@gmail.com
--- Comment #26 from AnAkkk anakin.cs@gmail.com --- That's a quite annoying issue, happens with Fiesta Online as well.
Seem to be similar as http://bugs.winehq.org/show_bug.cgi?id=33660
I posted a workaround: "I have a very similar problem in Fiesta Online. I could fix it by setting the 1st language in KDE settings to English (UK), and the 2nd one to French (which I use). Of course this is just a workaround and would better be fixed in wine. I also have to use CTRL-ALT-K to switch between both when I have a keyboard issue (none of the keys working at all in wine), but that might be specific to Fiesta Online."
Though this causes another bug in Qt applications: it only uses the 1st keyboard layout, so I have a QWERTY layout in these. (See https://bugreports.qt-project.org/browse/QTBUG-15319)
http://bugs.winehq.org/show_bug.cgi?id=15350
--- Comment #27 from AnAkkk anakin.cs@gmail.com --- I've just tried the last patch, it fixes my issues in Fiesta Online.
http://bugs.winehq.org/show_bug.cgi?id=15350
--- Comment #28 from AnAkkk anakin.cs@gmail.com --- It's not perfect though, it only uses the 1st layout in XKB, not the currently selected one (which is fine for me, but some people might use multiple layouts). Although that might be a different issue.
http://bugs.winehq.org/show_bug.cgi?id=15350
--- Comment #29 from AnAkkk anakin.cs@gmail.com --- There actually seem to be some additional issues when using that patch, number keys 2, 7, 9, 0 don't seem to do anything at all now, which is pretty annoying as a some games (like Fiesta Online) rely on these keys.
http://bugs.winehq.org/show_bug.cgi?id=15350
--- Comment #30 from AnAkkk anakin.cs@gmail.com --- Setting back the 1st language to English(UK), the 2nd to French, and the current one to the 2nd seem to fix key issue, but the patch is pretty useless then, as the same workaround works without.
https://bugs.winehq.org/show_bug.cgi?id=15350
Someone scrimekiler@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |scrimekiler@yahoo.fr
--- Comment #31 from Someone scrimekiler@yahoo.fr --- This seems to be a duplicate of Bug 30984
https://bugs.winehq.org/show_bug.cgi?id=15350
--- Comment #32 from Fab netfab@gmail.com --- (In reply to AnAkkk from comment #30)
Setting back the 1st language to English(UK), the 2nd to French, and the current one to the 2nd seem to fix key issue, but the patch is pretty useless then, as the same workaround works without.
Which language are you talking about ? Is this only in Fiesta Online ?
For another reason I just tried to rebuild wine-1.7.46 without that patch, and I confirm that without it, if your locale is setted up to fr_FR, all of these keys are still reversed in TR:Anniversary and similar games.
https://bugs.winehq.org/show_bug.cgi?id=15350
--- Comment #33 from Fab netfab@gmail.com --- Still a problem with wine-1.8-rc2-54-ge69d9ec.
$ locale | head -n 1 LANG=fr_FR.UTF-8
$ grep xkb_layout /var/log/Xorg.0.log 33.728] (**) Option "xkb_layout" "fr"
Affected games : - Tomb raider Legend - Tomb raider Anniversary - Tomb raider Underworld - Lara croft and the guardian of light
These four games are using the same engine, but I guess that all apps using dinput are affected. Still have to patch wine to get those keys behaves correctly.
https://bugs.winehq.org/show_bug.cgi?id=15350
Yamashita Ren lemaitre.dulotus@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lemaitre.dulotus@yahoo.fr
https://bugs.winehq.org/show_bug.cgi?id=15350
--- Comment #34 from Dmitry Timoshkov dmitry@baikal.ru --- I've modified the attached source to force loading of french keyboard layout, and under windows its output is different from the one under Linux. Under linux for testing it's required to execute 'setxkbmap fr' before running the test since switching and activating a different keyboard layout isn't implemented in wine.
under linux (with 'setxkbmap fr') I get: keydown wParam: 0x41 (A) lParam: 0x100001. MapVirtualKeyW(MAPVK_VK_TO_CHAR) = A DI key 0x1e (state 0x80) keydown wParam: 0x5a (Z) lParam: 0x110001. MapVirtualKeyW(MAPVK_VK_TO_CHAR) = Z DI key 0x2c (state 0x80) keydown wParam: 0x45 (E) lParam: 0x120001. MapVirtualKeyW(MAPVK_VK_TO_CHAR) = E DI key 0x12 (state 0x80) keydown wParam: 0x52 (R) lParam: 0x130001. MapVirtualKeyW(MAPVK_VK_TO_CHAR) = R DI key 0x13 (state 0x80) keydown wParam: 0x54 (T) lParam: 0x140001. MapVirtualKeyW(MAPVK_VK_TO_CHAR) = T DI key 0x14 (state 0x80)
under windows: keydown wParam: 0x41 (A) lParam: 0x100001. MapVirtualKeyW(MAPVK_VK_TO_CHAR) = A DI key 0x10 (state 0x80) keydown wParam: 0x5a (Z) lParam: 0x110001. MapVirtualKeyW(MAPVK_VK_TO_CHAR) = Z DI key 0x11 (state 0x80) keydown wParam: 0x45 (E) lParam: 0x120001. MapVirtualKeyW(MAPVK_VK_TO_CHAR) = E DI key 0x12 (state 0x80) keydown wParam: 0x52 (R) lParam: 0x130001. MapVirtualKeyW(MAPVK_VK_TO_CHAR) = R DI key 0x13 (state 0x80) keydown wParam: 0x54 (T) lParam: 0x140001. MapVirtualKeyW(MAPVK_VK_TO_CHAR) = T DI key 0x14 (state 0x80)
Notice the difference in generated DI key codes.
After reverting the commit 304ff3c7280a53b7cbadfa83eaeda458ff5959d1 or just commenting out the call to map_dik_code() in dlls/dinput/keyboard.c output under linux matches what I get under windows.
The patch that has caused the regression should be reverted, it's clearly wrong.
https://bugs.winehq.org/show_bug.cgi?id=15350
--- Comment #35 from Dmitry Timoshkov dmitry@baikal.ru --- Created attachment 55577 --> https://bugs.winehq.org/attachment.cgi?id=55577 modified test app source
https://bugs.winehq.org/show_bug.cgi?id=15350
--- Comment #36 from Dmitry Timoshkov dmitry@baikal.ru --- Created attachment 55578 --> https://bugs.winehq.org/attachment.cgi?id=55578 modified test app binary
I'm attaching the modified test app source and binary.
https://bugs.winehq.org/show_bug.cgi?id=15350
--- Comment #37 from Dmitry Timoshkov dmitry@baikal.ru --- Looking at the japanese keyboard layouts in winex11.drv it seems that the fix should be there instead of dinput. Aric, could you please have a look, or provide more details about the problem you were trying to fix originally?
https://bugs.winehq.org/show_bug.cgi?id=15350
--- Comment #38 from Aric Stewart aric@codeweavers.com --- (In reply to Dmitry Timoshkov from comment #37)
Looking at the japanese keyboard layouts in winex11.drv it seems that the fix should be there instead of dinput. Aric, could you please have a look, or provide more details about the problem you were trying to fix originally?
Hi, I think the earlier comments are pretty clear as to what I was trying to fix. There was a Japanese application using dinput that was depending on the DIK_ values for keys that where mapped differently on the Japanese keyboard than the US keyboard, resulting in unexpected behavior when keys where pressed.
I do not have access to the application any more for testing unfortunately.
-aric
https://bugs.winehq.org/show_bug.cgi?id=15350
--- Comment #39 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Aric Stewart from comment #38)
(In reply to Dmitry Timoshkov from comment #37)
Looking at the japanese keyboard layouts in winex11.drv it seems that the fix should be there instead of dinput. Aric, could you please have a look, or provide more details about the problem you were trying to fix originally?
Hi, I think the earlier comments are pretty clear as to what I was trying to fix. There was a Japanese application using dinput that was depending on the DIK_ values for keys that where mapped differently on the Japanese keyboard than the US keyboard, resulting in unexpected behavior when keys where pressed.
If you mean comments 7 and 13 where you were asking about the test results running your test application this doesn't provide that much information about the problem you tried to fix. On the other hand a comment in the commit message that has caused the regression mentions '[' key, and according to the results I get after loading a japanese keyboard layout in the modified test application, pressing '[' generates same DIK_ code 0x1a for us english, japanese and french keyboard layouts.
I'd suggest to revert the commit that has caused this regression, and open a separate bug report with more details about the problem with input using japanese keyboard layout, and instructions how to reproduce it.
https://bugs.winehq.org/show_bug.cgi?id=15350
Sagawa sagawa.aki+winebugs@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sagawa.aki+winebugs@gmail.c | |om
https://bugs.winehq.org/show_bug.cgi?id=15350
Iiro Laiho ilmaisin@openmailbox.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ilmaisin@openmailbox.org
--- Comment #40 from Iiro Laiho ilmaisin@openmailbox.org --- Or what about using those numeric X11 keycodes? I mean those that xev outputs. AFAIK they should be same on all keyboard layouts.
https://bugs.winehq.org/show_bug.cgi?id=15350
--- Comment #41 from Iiro Laiho ilmaisin@openmailbox.org --- Another idea would be to make it possible for users to choose between the old and new behavior from winecfg or something. Thus users could try between those two options and use the one that works best for them.
https://bugs.winehq.org/show_bug.cgi?id=15350
--- Comment #42 from Iiro Laiho ilmaisin@openmailbox.org --- *** Bug 43010 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=15350
rebe@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rebe@gmx.net
--- Comment #43 from rebe@gmx.net --- setxkbmap -query
gkbd-keyboard-display -g 1
The French layouts for info: https://en.wikipedia.org/wiki/AZERTY
https://bugs.winehq.org/show_bug.cgi?id=15350
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Fixed by SHA1| |d341b0a86b0d6264677635ba658 | |535a63509b8bc Resolution|--- |FIXED
--- Comment #44 from Dmitry Timoshkov dmitry@baikal.ru --- The offending commit has been reverted.
https://bugs.winehq.org/show_bug.cgi?id=15350
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #45 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 3.7.
https://bugs.winehq.org/show_bug.cgi?id=15350
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |3.0.x
https://bugs.winehq.org/show_bug.cgi?id=15350
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|3.0.x |---
--- Comment #46 from Michael Stefaniuc mstefani@winehq.org --- Removing the 3.0.x milestone from bugs included in 3.0.2.
-
wine-bugs＠winehq.org