Problems with focus losing on virtual desktops

[Christian Authmann]

Hi,

after installing 0.9.42 I noticed some odd behavior when playing Diablo
2. I did a git bisect and nailed it down to this patch:

http://source.winehq.org/git/wine.git/?a=commit;h=d836a5062141dd42293ed044de...

  winex11drv: Correctly react to focus loss away from Wine.


I noticed the following changes:

a) Using diablo 2's windowed mode: d2 will realize when it's losing
focus again (as it did somewhere around 0.9.2x). As far as I can tell,
this works reliable.
(That's not a good thing for diablo 2, since d2 will minimize on losing
focus and cannot be brought back to life afterwards. But that's a
different bug.)
> From now on, please read "Diablo 2 minimizes" as "Diablo 2 thinks it
> lost focus".

b) Using d2 in fullscreen mode inside wine's virtual desktop: d2 will
sometimes think it lost focus, even if it didn't.
Moving the wine window around with hotkey+drag: d2 minimizes.
Moving the window by the title bar: nothing happens. (using kde/kwin btw)
Sometimes just clicking inside the window while playing will cause d2 to
minimize, although I haven't found a reproducible pattern (i.e. do I
have to press certain keys, do I have to double-click, etc).

Activating a different window outside the virtual desktop? d2 stays
open. Or opening another application via hotkey, or pulling down yakuake
via hotkey. It stays open.
But, if I reactivate the virtual desktop window afterwards: d2
minimizes. Ouch.


c) virtual desktop again: when holding ALT to show the dropped items,
then left clicking somewhere, d2 thinks that ALT has been released. This
makes it quite hard to pick up items.
This problem does not occur when using regular windowed mode or when
changing the hotkey to something different - as far as I can tell only
ALT in virtual desktop mode is affected.
Note that I don't have any hotkeys on Alt (or Alt+click), I bound window
dragging to the otherwised unused windows key.


While the patch does as intended on regular windows, it's effects on
virtual desktop windows can only be described as weird.

I don't know how virtual desktops are supposed to work. At least for d2,
it'd be useful if one application inside the virtual desktop always
keeps focused (or rather, is told it'd still be focused).
IMHO that's the purpose of virtual desktops: banning the apps inside a
container where they shouldn't be influenced by outside stuff, including
activating a different window.
Not losing focus is also more sensible when virtual desktops are used as
a way to ban fullscreen-apps into windows: most fullscreen applications
don't expect to lose focus and behave weird.

However, even if you think of virtual desktops simply as a means to
group windows, it's currently broken: losing focus on reactivation is a
little late.


I have compiled the latest git version without this patch, and virtual
desktop mode works fine again, so it's really down to this single line
of code.

I'm not far enough into the code to know any possible solution, but for
immediate results a simple

if (inside a virtual desktop)
  do old behaviour
else
  do new behaviour

should do the trick until a better solution is found.


greetings,
Christian

[Jesse Allen]

On 8/13/07, Christian Authmann <spam(a)authmann.de> wrote:
> Hi,
>
> after installing 0.9.42 I noticed some odd behavior when playing Diablo
> 2. I did a git bisect and nailed it down to this patch:
>
> http://source.winehq.org/git/wine.git/?a=commit;h=d836a5062141dd42293ed044de...
>
> winex11drv: Correctly react to focus loss away from Wine.
>
> I noticed the following changes:
>
> a) Using diablo 2's windowed mode: d2 will realize when it's losing
> focus again (as it did somewhere around 0.9.2x). As far as I can tell,
> this works reliable.
> (That's not a good thing for diablo 2, since d2 will minimize on losing
> focus and cannot be brought back to life afterwards. But that's a
> different bug.)

I don't have much to comment on this one other than if you can prove
that this is not a behavior in windows, then you should probably open
a bug report. But I do believe the windowed mode wasn't really how the
game was intended to be played, just how the "-opengl" switch does
nothing other than corrupt the games graphics (and doesn't even
utilize opengl). These were more likely used in development and left
in for archaic reasons (seeing that the game doesn't visibly advertise
either). It's entirely possible that the messaging handler reacts very
similarly to like when it's in a virtual desktop because the game was
designed to be full screen.
> > From now on, please read "Diablo 2 minimizes" as "Diablo 2 thinks it
> > lost focus".
>
> b) Using d2 in fullscreen mode inside wine's virtual desktop: d2 will
> sometimes think it lost focus, even if it didn't.
> Moving the wine window around with hotkey+drag: d2 minimizes.
> Moving the window by the title bar: nothing happens. (using kde/kwin btw)
> Sometimes just clicking inside the window while playing will cause d2 to
> minimize, although I haven't found a reproducible pattern (i.e. do I
> have to press certain keys, do I have to double-click, etc).
>
> Activating a different window outside the virtual desktop? d2 stays
> open. Or opening another application via hotkey, or pulling down yakuake
> via hotkey. It stays open.
> But, if I reactivate the virtual desktop window afterwards: d2
> minimizes. Ouch.

This problem sounds like is caused by the design of the game. We can't fix this.
> c) virtual desktop again: when holding ALT to show the dropped items,
> then left clicking somewhere, d2 thinks that ALT has been released. This
> makes it quite hard to pick up items.
> This problem does not occur when using regular windowed mode or when
> changing the hotkey to something different - as far as I can tell only
> ALT in virtual desktop mode is affected.
> Note that I don't have any hotkeys on Alt (or Alt+click), I bound window
> dragging to the otherwised unused windows key.

This ALT key problem seems like the window manager is still
intercepting the ALT key somehow (even though certain keystrokes are
disabled). I'll test for this and tell you whether that's my
conclusion.
> While the patch does as intended on regular windows, it's effects on
> virtual desktop windows can only be described as weird.
>
> I don't know how virtual desktops are supposed to work. At least for d2,
> it'd be useful if one application inside the virtual desktop always
> keeps focused (or rather, is told it'd still be focused).
> IMHO that's the purpose of virtual desktops: banning the apps inside a
> container where they shouldn't be influenced by outside stuff, including
> activating a different window.
> Not losing focus is also more sensible when virtual desktops are used as
> a way to ban fullscreen-apps into windows: most fullscreen applications
> don't expect to lose focus and behave weird.
>
> However, even if you think of virtual desktops simply as a means to
> group windows, it's currently broken: losing focus on reactivation is a
> little late.
>
> I have compiled the latest git version without this patch, and virtual
> desktop mode works fine again, so it's really down to this single line
> of code.
>
> I'm not far enough into the code to know any possible solution, but for
> immediate results a simple
>
> if (inside a virtual desktop)
>   do old behaviour
> else
>   do new behaviour
>
> should do the trick until a better solution is found.

I can't tell you if this will happen. But I can look at the game
again, and give my advice.

[Christian Authmann]

Jesse Allen schrieb:
> I don't have much to comment on this one other than if you can prove
> that this is not a behavior in windows, then you should probably open
> a bug report.

I don't even know if it's a wine bug, it might as well be d2, the window
manager or a windows design issue.
It works fine when explorer.exe is present in wine (i.e. virtual desktop
mode) but fails when it's not. I never checked what happens to d2 in
windows when explorer.exe isn't there. And I don't feel like wasting a
day to get a working windows installation which allows me to kill explorer.
It's really not an issue, virtual desktop mode is superior to diablo's
window mode anyway: diablo defaults to slow and ugly direct2d rendering
when started with -w.

Hence no bug report.
> > b) Using d2 in fullscreen mode inside wine's virtual desktop: d2 will
> > sometimes think it lost focus, even if it didn't.
> > Moving the wine window around with hotkey+drag: d2 minimizes.
> > Moving the window by the title bar: nothing happens. (using kde/kwin btw)
> > Sometimes just clicking inside the window while playing will cause d2 to
> > minimize, although I haven't found a reproducible pattern (i.e. do I
> > have to press certain keys, do I have to double-click, etc).
> >
> > Activating a different window outside the virtual desktop? d2 stays
> > open. Or opening another application via hotkey, or pulling down yakuake
> > via hotkey. It stays open.
> > But, if I reactivate the virtual desktop window afterwards: d2
> > minimizes. Ouch.
>
> This problem sounds like is caused by the design of the game. We can't fix this.

How is this the game's fault?
Of course, minimizing on losing focus is the game's fault/feature, but
thinking that the focus has been lost when it clearly hasn't (or the
other way round) is a bug. Something has to tell the game "you lost
focus". These problems didn't happen in older wine versions (even 0.9.2x
where focus losing was possible) and don't happen on windows.

I've just tested with a different application inside a virtual desktop,
watching the window title to see if it's active or not. In short: This
broken focus behaviour on virtual desktops isn't limited to d2.


Moving the virtual desktop window with Hotkey+drag: lost focus.
I've noticed that kwin seems to contribute to this. Hotkey-dragging a
xev-window leads to these entries (keypress-events removed):

-- snip --
FocusOut event, serial 31, synthetic NO, window 0x3000001,
    mode NotifyGrab, detail NotifyAncestor

ConfigureNotify event, serial 32, synthetic YES, window 0x3000001,
    event 0x3000001, window 0x3000001, (1605,56), width 178, height 178,
    border_width 0, above 0x0, override NO

[more of those while moving. Then, when letting go:]

FocusIn event, serial 32, synthetic NO, window 0x3000001,
    mode NotifyUngrab, detail NotifyAncestor
-- snap --

However, this should mean that the window inside the virtual desktop
regains focus after the drag is complete, right? It doesn't.


Opening (and activating) a different window: the windows program thinks
it's still focused. Reactivating the virtual desktop window: the windows
program loses focus.

here's an xev dump of what xev receives when opening another window via
hotkey while xev is active (the Super_L-Key is obviously part of my
hotkey-combination).

-- snip --
KeyPress event, serial 31, synthetic NO, window 0x3000001,
    root 0x1a5, subw 0x0, time 2684778, (738,830), root:(2343,873),
    state 0x10, keycode 115 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

FocusOut event, serial 31, synthetic NO, window 0x3000001,
    mode NotifyGrab, detail NotifyAncestor

FocusIn event, serial 31, synthetic NO, window 0x3000001,
    mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 31, synthetic NO, window 0x0,
    keys:  2   0   0   0   0   0   64  0   0   0   0   0   0   0   8   0
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0

FocusOut event, serial 31, synthetic NO, window 0x3000001,
    mode NotifyNormal, detail NotifyNonlinear
-- snap --

now the additional FocusOut/FocusIn seems weird and may well be a kwin
bug that leads to this issues. Again, wine handles this good on regular
windows, but bad inside a virtual desktop.

After closing the opened app so that the virtual desktop (or xev in this
case) receives focus again, it'll get a simple FocusIn event, which
activates the virtual desktop window, but deactivates the application
window inside.
> This ALT key problem seems like the window manager is still
> intercepting the ALT key somehow (even though certain keystrokes are
> disabled). I'll test for this and tell you whether that's my
> conclusion.

thank you.
I've tried testing with a couple of different window managers, but they
all had Alt+click bound to window moving, so I couldn't test.
Maybe it is KWin-specific (or specific to my configuration), but it'll
still only happen inside virtual desktops, never on native linux windows
or d2 outside a virtual desktop.

Is there something like xev for windows I could use for further testing?


greetings,
Tub

[L. Rahyen]

On Tuesday August 14 2007 13:58, Christian Authmann wrote:
> thank you.
> I've tried testing with a couple of different window managers, but they
> all had Alt+click bound to window moving, so I couldn't test.

I see no problem here. Personally I use KDE and have Win+click combination to 
move windows. Go to Window menu (you can find it in any window) -> Configure 
Window Behavior -> Actions -> Window Actions -> Modifier key. You will 
have "Alt" there. Choose "Meta" instead and now you can use Win button 
instead of Alt. This is very useful because Alt+Click is very important in 
many Windows applications not only games but even in professional software 
like Maya or Lightwave.

[Jesse Allen]

On 8/14/07, Christian Authmann <spam(a)authmann.de> wrote:
> Jesse Allen schrieb:
> > I don't have much to comment on this one other than if you can prove
> > that this is not a behavior in windows, then you should probably open
> > a bug report.
>
> I don't even know if it's a wine bug, it might as well be d2, the window
> manager or a windows design issue.
> It works fine when explorer.exe is present in wine (i.e. virtual desktop
> mode) but fails when it's not. I never checked what happens to d2 in
> windows when explorer.exe isn't there. And I don't feel like wasting a
> day to get a working windows installation which allows me to kill explorer.
> It's really not an issue, virtual desktop mode is superior to diablo's
> window mode anyway: diablo defaults to slow and ugly direct2d rendering
> when started with -w.
>
> Hence no bug report.

Oh that's right. That's another reason why the window option from the
game is pretty much a "hack"; it only allows ddraw mode.
> > > b) Using d2 in fullscreen mode inside wine's virtual desktop: d2 will
> > > ...
> >
> > This problem sounds like is caused by the design of the game. We can't fix this.
>
> How is this the game's fault?
> Of course, minimizing on losing focus is the game's fault/feature, but
> thinking that the focus has been lost when it clearly hasn't (or the
> other way round) is a bug. Something has to tell the game "you lost
> focus". These problems didn't happen in older wine versions (even 0.9.2x
> where focus losing was possible) and don't happen on windows.

Windows doesn't have virtual desktop.
> I've just tested with a different application inside a virtual desktop,
> watching the window title to see if it's active or not. In short: This
> broken focus behaviour on virtual desktops isn't limited to d2.

Which application is this?
> Moving the virtual desktop window with Hotkey+drag: lost focus.
> I've noticed that kwin seems to contribute to this. Hotkey-dragging a
> xev-window leads to these entries (keypress-events removed):
>
> -- snip --
>
> now the additional FocusOut/FocusIn seems weird and may well be a kwin
> bug that leads to this issues. Again, wine handles this good on regular
> windows, but bad inside a virtual desktop.
>
> After closing the opened app so that the virtual desktop (or xev in this
> case) receives focus again, it'll get a simple FocusIn event, which
> activates the virtual desktop window, but deactivates the application
> window inside.

This seems correct behavior to me, if the wine windows are confined to
the virtual desktop. But someone else can comment.
> > This ALT key problem seems like the window manager is still
> > intercepting the ALT key somehow (even though certain keystrokes are
> > disabled). I'll test for this and tell you whether that's my
> > conclusion.
>
> thank you.
> I've tried testing with a couple of different window managers, but they
> all had Alt+click bound to window moving, so I couldn't test.
> Maybe it is KWin-specific (or specific to my configuration), but it'll
> still only happen inside virtual desktops, never on native linux windows
> or d2 outside a virtual desktop.
>
> Is there something like xev for windows I could use for further testing?

Like I said, windows doesn't have "virtual desktop"


Jesse

[Jesse Allen]

On 8/14/07, Christian Authmann <spam(a)authmann.de> wrote:
> Moving the virtual desktop window with Hotkey+drag: lost focus.
> I've noticed that kwin seems to contribute to this. Hotkey-dragging a
> xev-window leads to these entries (keypress-events removed):
>
> -- snip --
>
> now the additional FocusOut/FocusIn seems weird and may well be a kwin
> bug that leads to this issues. Again, wine handles this good on regular
> windows, but bad inside a virtual desktop.
>
> After closing the opened app so that the virtual desktop (or xev in this
> case) receives focus again, it'll get a simple FocusIn event, which
> activates the virtual desktop window, but deactivates the application
> window inside.

This problem sounds similar to bug 9301 (resolved WONTFIX). Look here
for reasons.
http://bugs.winehq.org/show_bug.cgi?id=9301