[Bug 12939] New: >=wine-0.9.59: Selection using control key and mouse button does not work.
http://bugs.winehq.org/show_bug.cgi?id=12939 Summary: >=wine-0.9.59: Selection using control key and mouse button does not work. Product: WineHQ Bugzilla Version: unspecified Platform: PC URL: http://www.foobar2000.org OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: bugzilla-unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: h.judt(a)gmx.at In Foobar2000, <Control>-<Mouse1> should select or deselect a single entry in the playlist. Instead, it just selects a new entry and deselects all others as if the control key has not been pressed. This worked in <wine-0.9.59 but does not in >=wine-0.9.59 (last version tested was 0.9.61). Similar problem with <Shift>-<Mouse1> existed in =wine-0.9.59, but was solved in >=0.9.60 and works fine now. Occurs with: Foobar2000-0.9.4.4, Exact Audio Copy-0.99prebeta4, file selector dialogs, but might effect other software / versions / dialogs as well. When I launch Foobar2000 and try to add files, I get the following messages on the terminal, maybe this is of some help: fixme:menu:TrackPopupMenuEx not fully implemented fixme:commdlg:GetFileName95 Flags 0x00800000 not yet implemented fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000011 fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000041 fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000010 fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000011 fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000011 fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000041 fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000010 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=12939 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|bugzilla-unknown |-unknown Product|WineHQ Bugzilla |Wine Version|unspecified |0.9.61. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=12939 Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|major |normal Keywords| |regression Summary|>=wine-0.9.59: Selection |Selection using control key |using control key and mouse |and mouse button does not |button does not work. |work --- Comment #1 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2008-05-06 09:23:56 --- I can not reproduce this with foobar2000. Is this in the main window or somewhere else? Are you running any extra mouse emulators, keyboard switchers? Please attach output when running program with WINEDEBUG=+key,+keyboard -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=12939 --- Comment #2 from Harald Judt <h.judt(a)gmx.at> 2008-05-12 16:19:57 --- Hi, thanks for your response. I'll attached the debug output. What I did: . Start foobar2000. . Click on an entry in the playlist (main window). . Hold down <Control> key. . Click on another entry in the playlist. . Exit foobar2000 by clicking on the window decoration close button. I'm usually using fluxbox as a window manager, but it happens in xfce/compiz too. Both provide configurable hotkeys. I'm also using imwheel for configuring the mouse buttons. Killing it doesn't help. I'm using CAPSLOCK as a Control key, but the Control key retains its function (not swapping CAPSLOCK and Control). Both in console and X. This is my xorg.conf keyboard section: Section "InputDevice" Identifier "Keyboard1" Driver "evdev" Option "Device" "/dev/input/event0" Option "XkbRules" "xorg" Option "XkbModel" "evdev" Option "XkbLayout" "de" Option "XkbOptions" "ctrl:nocaps,eurosign:e" Option "AutoRepeat" "500 30" EndSection And this is the one for the mouse: Section "InputDevice" Identifier "Mouse1" Driver "evdev" Option "Device" "/dev/input/event3" Option "Name" "Logitech USB RECEIVER" Option "CorePointer" Option "ZAxisMapping" "4 5 6 7" Option "Buttons" "9" Option "ButtonNumber" "9" EndSection I could try to use kbd instead of evdev, but this would force me to search for some strange HAL policy file. I'm also using this .Xmodmap file: ! Eject key keycode 169 = keycode 170 = keycode 174 = keycode 194 = XF86Eject ! WWW key keycode 158 = keycode 180 = XF86WWW keycode 156 = keycode 157 = keycode 197 = XF86Launch0 keycode 198 = XF86Launch1 keycode 199 = XF86Launch2 ! Mouse buttons pointer = 1 2 3 4 5 10 11 8 9 12 6 7 Would a debug output of an older wine version help (wine-0.9.58)? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=12939 --- Comment #3 from Harald Judt <h.judt(a)gmx.at> 2008-05-12 16:22:08 --- Created an attachment (id=12982) --> (http://bugs.winehq.org/attachment.cgi?id=12982) WINEDEBUG output WINEDEBUG=+key,+keyboard wine foobar2000.exe &> winedebug.log as requested. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=12939 --- Comment #4 from Harald Judt <h.judt(a)gmx.at> 2008-05-30 03:57:34 --- Ok, so after a hal update I've deleted the keyboard input section in xorg.conf and started using an /etc/hal/fdi/policy file. This solved a few other problems I was not quite aware of before (like some strange key combinations not working 100% correctly or producing strange results). <?xml version="1.0" encoding="utf-8"?> <deviceinfo version="0.2"> <match key="info.capabilities" contains="input.keys"> <merge key="input.xkb.rules" type="string">xorg</merge> <!-- Option "XkbModel" "evdev" --> <merge key="input.xkb.model" type="string">evdev</merge> <merge key="input.xkb.layout" type="string">de</merge> <merge key="input.xkb.options" type="strlist">ctrl:nocaps</merge> <append key="input.xkb.options" type="strlist">eurosign:e</append> </match> </deviceinfo> Now wine nearly works as expected, the only thing still not working correctly is the real <Control> key. <CapsLock> configured as a <Control> key works as it should, but pressing the real <Control> key still shows the same old behaviour which I've already reported. Otherwise, the <Control> key works in wine, because I can use it for shortcut keys. I'm going to attach two winedebug outputs, one using the real control key, the other using the capslock key. To reproduce: 1. Start foobar with WINEDEBUG=+key,+keyboard 2. Click on an entry in the playlist. It will be selected. 3. Hold down <key> and click on another entry in the playlist. Both entries should now be selected. Maybe this is of some help. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=12939 --- Comment #5 from Harald Judt <h.judt(a)gmx.at> 2008-05-30 03:59:26 --- Created an attachment (id=13473) --> (http://bugs.winehq.org/attachment.cgi?id=13473) debug output using real <control> key -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=12939 --- Comment #6 from Harald Judt <h.judt(a)gmx.at> 2008-05-30 04:00:15 --- Created an attachment (id=13474) --> (http://bugs.winehq.org/attachment.cgi?id=13474) debug output using <capslock> key -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=12939 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download --- Comment #7 from Austin English <austinenglish(a)gmail.com> 2008-11-28 00:01:59 --- Please retest in 1.1.9. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=12939 --- Comment #8 from Harald Judt <h.judt(a)gmx.at> 2008-11-29 16:45:23 --- (In reply to comment #7)
Please retest in 1.1.9.
Tested again in 1.1.9, no change. Selection using <CAPSLOCK> (reconfigured as CONTROL_L via .Xmodmap, see comment #2) works, using real <CONTROL_L> key does not. XServer uses HAL configuration shown in comment #4. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=12939 --- Comment #9 from Harald Judt <h.judt(a)gmx.at> 2008-11-29 16:49:52 --- Created an attachment (id=17545) --> (http://bugs.winehq.org/attachment.cgi?id=17545) xmodmap -pk output I've attached output of xmodmap -pk command, maybe it is useful. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=12939 Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID --- Comment #10 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2008-11-30 12:52:41 --- There are still something external to Wine running that messing with key states. The telltale sign are these lines: trace:keyboard:KEYBOARD_UpdateOneState Adjusting state for vkey 0xa2. State before 0xc1 trace:keyboard:KEYBOARD_UpdateOneState State after 0x41 Which mean that after you pressed control key, Wine processed it, then checks it's state as reported by the system. That state is reported as depressed and Wine readjusts it. So all you see is just a single "click" on the control key. This bug is invalid. You have something in your system that messing with reported key states to Wine. This can not be fixed by Wine. Closing invalid. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=12939 Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #11 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2008-11-30 12:52:59 --- Closing. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=12939 Harald Judt <h.judt(a)gmx.at> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |UNCONFIRMED Resolution|INVALID | --- Comment #12 from Harald Judt <h.judt(a)gmx.at> 2008-12-20 12:41:50 --- (In reply to comment #10)
There are still something external to Wine running that messing with key states. The telltale sign are these lines:
[...]
Which mean that after you pressed control key, Wine processed it, then checks it's state as reported by the system. That state is reported as depressed and Wine readjusts it. So all you see is just a single "click" on the control key.
Thanks for your explanation. I found out this has to do with the way I configure my Caps_Lock and Control keys. If I use the standard configuration (Caps_Lock as Caps_Lock), then everything is fine and Control_L works as expected in WINE.
This bug is invalid. You have something in your system that messing with reported key states to Wine. This can not be fixed by Wine.
I have to argue. I WANT to use both Caps_Lock and Control_L as control keys. In every other application, this works as expected, just not in wine. There is no external program messing with key states. You don't even need to configure anything else, just add the following commands to your .Xmodmap or use xmodmap -e "<command>": remove Lock = Caps_Lock keysym Caps_Lock = Control_L add Control = Control_L So WINE simply does not respect my X keyboard configuration. I can use Caps_Lock as Control_L (which is what I do most of the time), but then the real Control_L will not function as Control_L in WINE. This is wrong, and this is why I reported this bug.
Closing invalid.
Please see my initial posting. This worked in <wine-0.9.59. Why doesn't it work now? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=12939 --- Comment #13 from Harald Judt <h.judt(a)gmx.at> 2008-12-20 12:48:43 --- Here is my xmodmap output, for completeness' sake: Control_L (0x42) is the reconfigured Caps_Lock key, while Control_L (0x25) is the real Control_L key. xmodmap: up to 3 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lock control Control_L (0x25), Control_R (0x69), Control_L (0x42) mod1 Alt_L (0x40), Meta_L (0xcd) mod2 Num_Lock (0x4d) mod3 mod4 Super_L (0xce), Hyper_L (0xcf) mod5 ISO_Level3_Shift (0x5c), Mode_switch (0xcb) I've also used the following configuration: lock control Control_L (0x25), Control_R (0x69), Caps_Lock (0x42) Result: Caps_Lock does not function as a control key in wine (which makes sense here, since it will be reported as Caps_Lock), but does so in other applications (I guess these use a different way to determine whether you pressed a modifier key). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=12939 Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID --- Comment #14 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2008-12-20 13:45:13 --- No you can't do that. Wine _have to_ know and use the exact key state. If something sent key_down, key_up events to Wine that's the state Wine will have. Also that state better match to all other X-events Wine receives. In your case - it doesn't. File bug with x-org. It should send consistent key states. Also you can't use trigger buttons (caps lock) for something that is not a trigger (control). Closing invalid - not compatible configuration. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=12939 Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #15 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2008-12-20 13:46:00 --- Remember the way key7board works in windows is different from the way it works in X. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=12939 --- Comment #16 from Harald Judt <h.judt(a)gmx.at> 2008-12-20 17:17:24 --- (In reply to comment #14)
No you can't do that. Wine _have to_ know and use the exact key state. If something sent key_down, key_up events to Wine that's the state Wine will have.
Ok, so I guess this behaviour has been changed in >=wine-0.9.59.
Also that state better match to all other X-events Wine receives. In your case - it doesn't.
File bug with x-org. It should send consistent key states. Also you can't use trigger buttons (caps lock) for something that is not a trigger (control).
I would like to, but I'm a bit lost now. What exactly is X sending incorrectly and what should it send instead? It actually wouldn't help in my case, since caps_lock is just a trigger?
Remember the way key7board works in windows is different from the way it works in X.
I remember you can change keyboard scan code mapping by editing the registry (search terms "caps_lock control registry"), and tried this but could not get it to work in wine. I guess this is not yet implemented, should I file a separate bug asking for enhancement? Thanks for your explanation, it helped me solve another problem I had with Caps_Lock and imwheel in firefox but did not notice before. I've configured Caps_Lock to keep it's keysym but act as a control modifier, because this works and I believe that's the clearest way to deal with this. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=12939 --- Comment #17 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2008-12-20 18:26:47 --- (In reply to comment #16)
(In reply to comment #14)
No you can't do that. Wine _have to_ know and use the exact key state. If something sent key_down, key_up events to Wine that's the state Wine will have.
Ok, so I guess this behaviour has been changed in >=wine-0.9.59.
Yes. Wine distinguishes between left and right control, shift and alt. And properly adjusts for their state changes outside Wine. In your setup Wine gets conflicting information from X about state of modifier key(s). This has nothing todo with scancodes. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=12939 --- Comment #18 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2008-12-21 01:46:03 --- Created an attachment (id=18104) --> (http://bugs.winehq.org/attachment.cgi?id=18104) Detect key masks in run-time Does the attached patch help? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=12939 Dmitry Timoshkov <dmitry(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |UNCONFIRMED Resolution|INVALID | --- Comment #19 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2008-12-21 01:46:32 --- Reopening, this is a valid bug. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=12939 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=12939 --- Comment #20 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2008-12-24 04:36:06 --- I sent a patch: http://www.winehq.org/pipermail/wine-patches/2008-December/066691.html Please re-test. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=12939 --- Comment #21 from Harald Judt <h.judt(a)gmx.at> 2009-01-04 18:43:32 --- (In reply to comment #18)
Created an attachment (id=18104) --> (http://bugs.winehq.org/attachment.cgi?id=18104) [details] Detect key masks in run-time
Does the attached patch help?
Thank you. I tried this patch (sorry for the delay, holidays you know), but unfortunately it does not solve the issue. However, I did not do any WINEDEBUG like before, but will when I got more time and post it here. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=12939 Benjamin Debski <benjamin.debski(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |benjamin.debski(a)gmail.com --- Comment #22 from Benjamin Debski <benjamin.debski(a)gmail.com> 2010-01-07 20:19:41 --- Playlist selection is working fine for me using Wine 20100107 git -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=12939 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED --- Comment #23 from Austin English <austinenglish(a)gmail.com> 2010-01-08 08:57:49 --- Reported fixed. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=12939 Jeff Zaroyko <jeffz(a)jeffz.name> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #24 from Jeff Zaroyko <jeffz(a)jeffz.name> 2010-01-09 04:52:57 --- Closing bugs fixed in 1.1.36. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=12939 --- Comment #25 from Harald Judt <h.judt(a)gmx.at> 2010-01-23 13:19:18 --- (In reply to comment #24)
Closing bugs fixed in 1.1.36.
No, it's not fixed. I still experience the same behaviour in 1.1.36 as elaborated in previous comments. (In reply to comment #22)
Playlist selection is working fine for me using Wine 20100107 git Sorry to bother you, but have you tried this using my configuration as described above? If yes, what do I have to do to get it working right?
Current status: CAPS_LOCK is control key, CONTROL_L is control key, configuration done by HAL and xmodmap. Selecting more entries in the playlist via CAPS_LOCK works, using CONTROL_L does not (application responds as if CONTROL_L has not been pressed). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=12939 --- Comment #26 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2010-01-23 15:00:38 --- (In reply to comment #25)
I still experience the same behaviour in 1.1.36 as elaborated in previous comments. You've been told already - your configuration is invalid, it can not be supported by Wine. The only bug that was present with modifier masks are fixed now. If it still doesn't work for you - report bug to Xorg.
-- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=12939 --- Comment #27 from Harald Judt <h.judt(a)gmx.at> 2011-10-11 15:15:15 CDT --- Vitaliy Margolen:
Also you can't use trigger buttons (caps lock) for something that is not a trigger (control).
You've been told already - your configuration is invalid, it can not be supported by Wine.
I beg your pardon, sir, but it seems what you tried to make me believe is bullshit. Tested and fixed in 1.3.29, and it worked in <wine-0.9.59, so obviously it is supported by wine. Whether it works because of X server or configuration change or a change in wine, I don't know, nevertheless this configuration (Caps_Lock as Control) seems perfectly valid. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org