[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: Bug #45385 related to keyboard and probably wineserver - where to start the search
From:       John Found <johnfound () asm32 ! info>
Date:       2018-06-28 17:07:55
Message-ID: 20180628200755.a1f76171081852cb6a20566c () asm32 ! info
[Download RAW message or body]

OK, continuing the bug #45385 investigation, I found out that it is somehow related \
to the window manager and its focus policies.

I am working and testing in XFCE and in the window manager settings there are two \
checkboxes:

    [ ] Activate focus stealing protection
    [ ] Honor ICCCM focus hint

So, the buggy behavior happens when and only when both these options are checked. 
When only one of the is checked or both are unchecked, the bug does not manifests \
itself.

The big question here is whether the bug is in the WM/X11 or in the WINE itself. 

I can't judge by myself, simply because I don't know how this "stealing prevention" \
works and what is "ICCCM focus hint".

While this finding allows to workaround the problem, I am still curious about the \
actual reason for the wrong behavior.

Any considerations?

Regards


On Wed, 27 Jun 2018 08:50:22 +0300
John Found <johnfound@asm32.info> wrote:

> I just reported bug #45385 (https://bugs.winehq.org/show_bug.cgi?id=45385) and want \
> to try to fix it. 
> So I want to ask about some preliminary directions - where to check the code, 
> what is the general structure of the code related to the bug subject, possible \
> suspicious places. 
> Here is the full bug report in order to save you a visit to the bug tracker:
> 
> > I noticed that the state of the keys sometimes sticks in pressed state.
> > 
> > This happens when cycling windows with some shortcut key combination. 
> > 
> > For example if cycling with Alt+Tab, on pressing Alt, the program gets WM_KEYDOWN \
> > and the state of the VK_MENU becomes pressed. But after cycling windows, the \
> > program does not get WM_KEYUP because the window is not focused and VK_MENU (and \
> > the respective VK_LMENU or VK_RMENU) remain in pressed state. 
> > When cycling back to the program window, the window get focused only after \
> > releasing Alt key, so it does not get this event as well. 
> > If cycling windows with another shortcut key combination (for example \
> > Alt+Shift+Tab - for backward cycling) both VK_MENU and VK_SHIFT keys stick. 
> > In the same time, GetAsyncKeyState returns the proper state of the keys.
> > 
> > Note1: The problem is obviously in the wineserver code, because it handles the \
> > key state tables for the different threads. 
> > Note2: The effect happens only sometimes. It seems the code for proper processing \
> > is already there, but some racing conditions have place. 
> > Note3: There is some probability that the effect is in result of my application \
> > code, but it never happens on real Windows, so I considered it a bug. 
> > Note4: I tried to workaround this problem by reading the whole table by \
> > GetAsyncKeyState and setting it then with SetKeyboardState on WM_ACTIVATE message \
> > of the main window. This workaround actually works, but is too ugly IMO. The same \
> > trick on WM_ACTIVATEAPP does not work.
> 
> -- 
> John Found <johnfound@asm32.info>
> 
> 


-- 
John Found <johnfound@asm32.info>


[prev in list] [next in list] [prev in thread] [next in thread]