InputHint and WM_TAKE_FOCUS
Tomas Carnecky
tom at dbservice.com
Fri Jul 27 16:58:14 CDT 2007
Commit d836a5062141dd42293ed044debbaf25f914f383 broke sound in World of
Warcraft. Yes, it sound strange but after I analyzed the issue it makes
perfectly sense: a commit to dlls/winex11.drv/event.c broke sound.
According to the wine source and the ICCCM spec, wine uses either the
'Passive' or 'Locally active' input model. InputHint is always set and
WM_TAKE_FOCUS only if "UseTakeFocus" is set in the registry.
InputHint indicates that the window will have focus set by the WM, and
WM_TAKE_FOCUS indicates that the app may set focus to it's own
subwindows. Both metacity an compiz _don't_ send WM_TAKE_FOCUS to
windows that have InputHint set!
The problem that arises from [1] is the following: If the WM calls
XSetInputFocus() then the xserver sends a FocusIn event to the wine
window, but wine ignores that event and waits for an WM_TAKE_FOCUS
message. But that message never arrives because the WM never sends it.
The above mentioned commit sets the foreground window to desktop if the
WoW window looses focus. This makes WoW stop sound output. But the WoW
window never regains focus and WoW won't resume sound output. I assume
this bug has been in wine for a long time and even though it's a bug I
enjoyed being able to switch away from WoW and still hear the sound
(fishing/grinding while reading slashdot, hacking on wine etc).
The solution? Remove [1] (to process the FocusIn event) or remove
InputHint from WM_HINTS. That would fix around the missing sound.
Anyhow, 'sound while WoW lost focus' will be lost forever and I imagine
there's no way to make that possible again but using a custom patch.
tom
[1]: http://source.winehq.org/source/dlls/winex11.drv/event.c#L509
More information about the wine-devel
mailing list