https://bugs.winehq.org/show_bug.cgi?id=48965
Bug ID: 48965 Summary: regression introduced by 1bc9c4fdb2e6c27621 Product: Wine Version: 4.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs@winehq.org Reporter: mfr@bmx-chemnitz.de Distribution: ---
regression introduced by commit 1bc9c4fdb2e6c27621
The commit causes a regression in key handling for Rift, and possibly other games (see https://forum.winehq.org/viewtopic.php?t=32612).
specific ssue for Rift: key combination with ALT not working (tested with wine-5.4, wine-5.6 causes other issues/crashes)
Commit identified via the above forum entry mentioning 4.10 and 4.11:
$> git log --grep Release | grep -B 5 "4.1"
4.10 -> 78f74446b9806f63a27c2d643b8e29156b5bdcb 4.11 -> 07afb240a87d097c83ca5263c61145a170894a22
$> git log 78f74446b9..07afb240a87d097c83 --grep keyboard 1 result: commit 1bc9c4fdb2e6c2762105c14cdafb7d4ea3370625
Reverting that commit fixed ALT key combinations in Rift.
https://bugs.winehq.org/show_bug.cgi?id=48965
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |1bc9c4fdb2e6c2762105c14cdaf | |b7d4ea3370625 CC| |z.figura12@gmail.com Keywords| |regression
--- Comment #1 from Zebediah Figura z.figura12@gmail.com --- Can you please describe in more detail what breaks? Does Rift ignore the Alt key, or does it ignore the entire keypress? What specific keys have you tried with the Alt modifier?
https://bugs.winehq.org/show_bug.cgi?id=48965
--- Comment #2 from Marko Friedemann mfr@bmx-chemnitz.de --- I have a number of skills assigned to key combinations ALT+(1..6).
Those do not work, and it's not that ALT would get ignored, there is no reaction at all (ie, it does not just send 1..6).
I didn't know what specifically I could try to test stuff, so I started a notepad.exe with the same launcher script (same WINEPREFIX, same wine binary, same settings, ...) and there I was able to press ALT+(menu hotkeys, but letter characters). But that is not a fullscreen application with DX, so I don't know what else might differ.
I then went to search, found the forum entry, grepped in the git log a bit and found that commit which seemed reasonable to be reverted for a try. So I did, and without those changes, the key combinations work as before.
HTH, M.
https://bugs.winehq.org/show_bug.cgi?id=48965
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|regression introduced by |Rift: key combination with |1bc9c4fdb2e6c27621 |ALT not working
https://bugs.winehq.org/show_bug.cgi?id=48965
--- Comment #3 from Marko Friedemann mfr@bmx-chemnitz.de --- Created attachment 66962 --> https://bugs.winehq.org/attachment.cgi?id=66962 log file with trace+key for non-working ALT key-combos (wine 5.4)
This log includes start of the game (launcher, game, char selection). Once in-game, I pressed ALT+1 to ALT+6 (each twice before the next).
As per the earlier comment, the combination gets ignored by the game outright. It does not trigger the ability for key '1'.
https://bugs.winehq.org/show_bug.cgi?id=48965
--- Comment #4 from Marko Friedemann mfr@bmx-chemnitz.de --- Created attachment 66963 --> https://bugs.winehq.org/attachment.cgi?id=66963 log file with trace+key for working ALT key-combos (wine 5.4 w/ 1bc9c4fdb reverted)
Same sequence as in the other attachment:
This log includes start of the game (launcher, game, char selection). Once in-game, I pressed ALT+1 to ALT+6 (each twice before the next).
https://bugs.winehq.org/show_bug.cgi?id=48965
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|wine-bugs@winehq.org |z.figura12@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=48965
--- Comment #5 from Zebediah Figura z.figura12@gmail.com --- Sorry for the long delay in getting to this.
I just tried to launch Rift, assign alt-6 to a skill, and press it, and the game did respond, both when assigning the key binding and when using it. It works also in both windowed and fullscreen mode.
Can you please check with current Wine (i.e. 6.0-rc1)? This bug may have been fixed.
If you can still reproduce it, can you please attach a new log with WINEDEBUG=+dinput,+rawinput,+win,+keyboard,+key,+event,+server?
https://bugs.winehq.org/show_bug.cgi?id=48965
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEEDINFO
--- Comment #6 from Zebediah Figura z.figura12@gmail.com --- I checked with 1bc9c4fdb2e6c27621, and I can't reproduce the bug in that version either. This may be dependent on window manager, or X11 version, or something else. Can you please provide that information as well?
https://bugs.winehq.org/show_bug.cgi?id=48965
--- Comment #7 from Marko Friedemann mfr@bmx-chemnitz.de --- Well, there's two things that might be relevant.
I have been running stuff for years with "wine explorer /desktop=$name,$resolution $executable" That way, they are running within their own "virtual desktop" and are not minimized when I alt-tab out. This might be in conflict with that particular key remapping function, because from the log, it appears it is kicking in every time, whereas from the comments, I assume it's not meant to do that.
I also have a patch that makes Unity's global menu disappear.
I didn't have much time to further test, have just been using an older build with all my patches. Will see if I can test with a fully stock wine without the explorer option.
M.
https://bugs.winehq.org/show_bug.cgi?id=48965
--- Comment #8 from Zebediah Figura z.figura12@gmail.com --- Thanks. I still can't reproduce with the virtual desktop under KDE/Kwin. Is your patch to Wine? Do you know specifically what window manager you're using?
https://bugs.winehq.org/show_bug.cgi?id=48965
--- Comment #9 from Marko Friedemann mfr@bmx-chemnitz.de --- It's actually two patches to help with fullscreen mode.
One is "winex11.drv: Bypass compositor in fullscreen mode", from Kai Krakow. The other is a patch named compiz-workaround, which gets rid of Unity's stupid global menu.
Both are patches to winex11.drv/window.c, the first adds a XChangeProperty call, the second one removes one (I'll attach both for reference).
I am using an old Ubuntu 16.04 LTS (yes, I know), with its Unity desktop, wmctrl -m says the WM is compiz, which would make sense given the 2nd patch name (can't remember where I fetched that from).
HTH, M.
https://bugs.winehq.org/show_bug.cgi?id=48965
--- Comment #10 from Marko Friedemann mfr@bmx-chemnitz.de --- Created attachment 69125 --> https://bugs.winehq.org/attachment.cgi?id=69125 FS_bypass_compositor.patch
https://bugs.winehq.org/show_bug.cgi?id=48965
--- Comment #11 from Marko Friedemann mfr@bmx-chemnitz.de --- Created attachment 69126 --> https://bugs.winehq.org/attachment.cgi?id=69126 compiz-workaround.diff
https://bugs.winehq.org/show_bug.cgi?id=48965
--- Comment #12 from Zebediah Figura z.figura12@gmail.com --- Thanks. I still can't reproduce the bug with those patches, so I'm guessing this is a compiz-specific bug. I can't either reproduce it with compiz 0.9.14.1 built and running in Xephyr on Arch, but that may be somewhat artificial. I'll try to set up an Ubuntu 16.04 VM.
https://bugs.winehq.org/show_bug.cgi?id=48965
--- Comment #13 from Zebediah Figura z.figura12@gmail.com --- It may be easier, though, if you can provide a log with WINEDEBUG=+dinput,+rawinput,+win,+keyboard,+key,+event,+message,+msg.
https://bugs.winehq.org/show_bug.cgi?id=48965
Marko Friedemann mfr@bmx-chemnitz.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #66962|0 |1 is obsolete| |
--- Comment #14 from Marko Friedemann mfr@bmx-chemnitz.de --- Created attachment 69206 --> https://bugs.winehq.org/attachment.cgi?id=69206 log file with +dinput,+rawinput,+win,+keyboard,+key,+event,+message,+msg for non-working ALT key-combos (wine-6.0 stock)
https://bugs.winehq.org/show_bug.cgi?id=48965
Marko Friedemann mfr@bmx-chemnitz.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #66963|0 |1 is obsolete| |
--- Comment #15 from Marko Friedemann mfr@bmx-chemnitz.de --- Created attachment 69207 --> https://bugs.winehq.org/attachment.cgi?id=69207 log file with +dinput,+rawinput,+win,+keyboard,+key,+event,+message,+msg for working ALT key-combos (wine-6.0 + extra patches)
https://bugs.winehq.org/show_bug.cgi?id=48965
--- Comment #16 from Marko Friedemann mfr@bmx-chemnitz.de --- OK, so I compiled wine-6.0 today and ran the game with the debug flags you requested.
I ran it once on an wine-6.0 as-is from git, and once with my patches applied (did not revert the commit 1bc9c4fdb2e6c27621 but instead just changed the loop to run through the range as before that commit):
- for (vkey = 1; vkey <= 0xff; vkey++) + for (vkey = VK_LSHIFT; vkey <= VK_RMENU; vkey++)
With both version, I started the game, then pressed, in sequence: ALT + 1, 2, 3 (without releasing ALT), then released ALT CLTRL + 1, 2, 3 (without releasing CTRL), then released CTRL 1, 2, 3
Log files attached above this comment.
Regards, HTH, M.
https://bugs.winehq.org/show_bug.cgi?id=48965
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |UNCONFIRMED Ever confirmed|1 |0
--- Comment #17 from Zebediah Figura z.figura12@gmail.com --- I'm inclined to call this a compiz bug. See, here's the thing:
01e4:trace:event:call_event_handler 479 FocusOut for hwnd/window 0x200c8/8800005 01e4:trace:event:X11DRV_FocusOut win 0x200c8 xwin 8800005 detail=NotifyAncestor mode=NotifyGrab 01e4:trace:event:call_event_handler 479 FocusIn for hwnd/window 0x200c8/8800005 01e4:trace:event:X11DRV_FocusIn win 0x200c8 xwin 8800005 detail=NotifyAncestor mode=NotifyUngrab
Someone randomly grabs the keyboard, apparently, causing our window to focus out and back in again. Okay, fine, whatever, they're within rights to do that I guess...
01e4:trace:event:call_event_handler 479 KeymapNotify for hwnd/window (nil)/0 01e4:trace:keyboard:X11DRV_KeymapNotify Adjusting state for vkey 0xa4. State before 00 01e4:trace:event:process_events processed 4 events, returning 1
The FocusIn is followed by a KeymapNotify, which is correct. Problem is, that notify already has the alt key pressed.
01e4:trace:event:call_event_handler 479 KeyPress for hwnd/window 0x200c8/8800005 01e4:trace:key:X11DRV_KeyEvent type 2, window 8800005, state 0x0000, keycode 64 01e4:trace:key:X11DRV_KeyEvent XmbLookupString needs 0 byte(s) 01e4:trace:key:X11DRV_KeyEvent nbyte = 0, status 3 01e4:trace:key:X11DRV_KeyEvent KeyPress : keysym=ffe9 (Alt_L), # of chars=0 / "" 01e4:trace:key:EVENT_event_to_vkey e->keycode = 64 01e4:trace:key:X11DRV_KeyEvent keycode 64 converted to vkey 0xA4 scan 38 01e4:trace:key:X11DRV_send_keyboard_input hwnd 0x200c8 vkey=00a4 scan=0038 flags=0000 01e4:trace:event:process_events processed 2 events, returning 1 01e4:trace:msg:peek_message got type 7 msg 104 (WM_SYSKEYDOWN) hwnd 00000000000200C8 wp a4 lp 60380001
Then we get a KeyPress of the left alt key. Trouble is, we report to Rift that the key was already held down, and it seems to ignore key presses in that case.
This isn't actually invalid according to the X11 spec (at least, I think), and it can happen in practice due to auto-repeat. But it confuses the application, and I don't think compiz should be doing this.
I'll try to set up a VM to reproduce, and possibly create a minimal test case, and then report the bug to compiz.
https://bugs.winehq.org/show_bug.cgi?id=48965
--- Comment #18 from Esme Povirk madewokherd@gmail.com --- It's normal (in fact I think it's required) to get those Focus notifications when a key combination gets caught by another client with XGrabKey.
https://bugs.winehq.org/show_bug.cgi?id=48965
--- Comment #19 from Zebediah Figura z.figura12@gmail.com --- (In reply to Esme Povirk from comment #18)
It's normal (in fact I think it's required) to get those Focus notifications when a key combination gets caught by another client with XGrabKey.
Sure. I'm more bothered by the KeymapNotify telling us that alt is already pressed, followed by a KeyPress event, when the user only actually pressed it once. I feel like the answer to this is "compiz shouldn't do that", but of course X11 is hard. Does that sound right to you?
https://bugs.winehq.org/show_bug.cgi?id=48965
--- Comment #20 from Esme Povirk madewokherd@gmail.com --- As far as I know, window managers aren't responsible for sending KeymapNotify events, so I wouldn't expect compiz to be involved.
https://bugs.winehq.org/show_bug.cgi?id=48965
--- Comment #21 from Marko Friedemann mfr@bmx-chemnitz.de --- Created attachment 69286 --> https://bugs.winehq.org/attachment.cgi?id=69286 xev log of the same input sequence
OK, I see where you are coming from.
I tested the same input sequence with xev, attached the output. Sure enough, ALT_L involves FocusIn/FocusOut, wonder if that might have to do with the ALT key being mapped to something in unity/compiz.
Will take a look at options etc.
Thanks, HTH, M.
https://bugs.winehq.org/show_bug.cgi?id=48965
--- Comment #22 from Marko Friedemann mfr@bmx-chemnitz.de --- Alright, I found the ALT key to be configured for "Key to show the menu bar while pressed" in the Ubuntu Unity Plugin for compiz.
Reconfigured it to use the MENU key instead, and now the FocusOut/FocusIn and KeymapNotify events are gone from xev when using ALT.
Thanks, this means that you are right about this not being a bug in wine (I marked it as such now) and that it can be closed, I guess.
https://bugs.winehq.org/show_bug.cgi?id=48965
--- Comment #23 from Marko Friedemann mfr@bmx-chemnitz.de --- Ah, apparently I am not allowed to change status or resolve it as NOTOURBUG.
Anyway, meant to post a link that shows the options mentioned in the comment above: https://askubuntu.com/a/894914. That answer has a screenshot of the settings manager and has highlighted another option, the one that appears to have been the culprit for me is the first one there in that list.
Thanks for taking the time to look into this and help me fix it. M.
https://bugs.winehq.org/show_bug.cgi?id=48965
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |NOTOURBUG Status|UNCONFIRMED |RESOLVED
--- Comment #24 from Zebediah Figura z.figura12@gmail.com --- Cool, thanks.
I think Esme is right, and that the window manager isn't necessarily doing anything wrong here. I'm not sure why it doesn't just steal the key press entirely, though. But in any case, it looks nontrivial for Wine to work around the bug, and guess whether a key actually was pressed while we technically had focus.
-
WineHQ Bugzilla