Review Request 121755: Fix input focus for KDM's dialogs when GrabInput is not active

Tue Aug 4 15:26:16 BST 2015

> On Juli 30, 2015, 12:05 nachm., Thomas Lübking wrote:
> > This is Qt4, right?
> > 
> > ::activateWindow() should be equivalent to "XSetInputFocus(display, winId(), XRevertToParent, X11->time);" unless
> > a) _NET_ACTIVE_WINDOW is listed in _NET_SUPPORTED on the root window (supposed to be set and withdrawn by window managers, crash on exit?)
> > AND
> > b) Qt::X11BypassWindowManagerHint is NOT set on the toplevel window
> > OR
> > c) the window is not mapped/waiting for a mapping notification
> > 
> > => If the problem occurs, login aside (VT1 or ssh) and
> > 
> >    export DISPLAY=:0
> >    xprop -root | grep _NET_ACTIVE_WINDOW
> > 
> > If that's emtpy, focus setting fails on either "qt_widget_private(tlw)->topData()->waitingForMapNotify" (qt bug in event handling? missing "XSync(dpy, false)"? events are being processed after show) or "X11->time" being superseded by a more recent/future XSetInputFocus call ("fixed" by passing CurrentTime)
> > 
> > If the feature /is/ listed, that's a bug caused by a crashing WM => setting Qt::X11BypassWindowManagerHint will likely be sufficient.
> 
> Wolfgang Bauer wrote:
>     > This is Qt4, right?
>     
>     Yes.
>     
>     > => If the problem occurs, login aside (VT1 or ssh) and
>     >
>     > export DISPLAY=:0
>     >    xprop -root | grep _NET_ACTIVE_WINDOW
>     
>     Hm, I don't seem to be able to get the properties of kdm's root window.
>     After opening a new login session:
>     ```
>     # export DISPLAY=:1
>     # xprop -root
>     No protocol specified.
>     xprop: unable to open display ':1'
>     ```
>     On fresh boot:
>     ```
>     # export DISPLAY=:0
>     # xprop -root
>     Invalid MIT-MAGIC-COOKIE-1 keyxprop: unable to open display ':0'
>     ```
>     
>     If I kill kwin in a running KDE4 session, the feature is listed. But that's to be expected I suppose, if I understand you correctly.
>     And focus changes when you move the mouse, which I think is undesirable at the login screen anyway (there are not really multiple windows, just modal dialogs).
>     
>     > If the feature /is/ listed, that's a bug caused by a crashing WM => setting Qt::X11BypassWindowManagerHint will likely be sufficient.
>     
>     I will try if that helps.
>     
>     But just to avoid a misunderstanding here: this is about kdm's login greeter. There's no window manager running at all.
> 
> Thomas Lübking wrote:
>     > There's no window manager running at all.
>     
>     Yeah, got that ;-)
>     
>     > xprop: unable to open display ':1'
>     
>     Ah, that's likely because the superuser has the X11 authority - try from a su login.
>     
>     > And focus changes when you move the mouse
>     
>     That's the default X11 behavior, it will always behave like that (while unmanaged; and iirc it's suppressable by a config key/X switch)
> 
> Wolfgang Bauer wrote:
>     >> There's no window manager running at all.
>     
>     > Yeah, got that ;-)
>     
>     I thought so, but I still wanted to mention it because you were talking about a crashing WM... ;-)
>     
>     >> xprop: unable to open display ':1'
>     
>     > Ah, that's likely because the superuser has the X11 authority - try from a su login.
>     
>     Well, that was in fact a su login.
>     
>     But meanwhile I modified kdm to run xprop (at the same place that this patch modifies...).
>     _NET_ACTIVE_WINDOW is *not* set, and _NET_SUPPORTED(ATOM) was not even mentioned in xprop's output.
>     
>     >> And focus changes when you move the mouse
>     
>     > That's the default X11 behavior, it will always behave like that (while unmanaged; and iirc it's suppressable by a config key/X switch)
>     
>     I know, I even mentioned that in the openSUSE bugreport (I have to admit that I used wrong terms though...)
>     
>     So, is this patch ok for you?
>     I think it should be, as Qt itself just calls XSetInputFocus().
>     
>     The actual bug seems to be in Qt4, but that's unlikely to be fixed any more, isn't?
> 
> Thomas Lübking wrote:
>     The patch is certainly correct since it does the right thing, I'm rather worried *why* it's required in the first place, ie. why the Qt code doesn't work as expected here.
>     
>     Either the mapping condition flag is broken or there's trouble with timestamp handling.
>     
>     If you want to do another test on the causes, check whether you patch still works with QX11Info::appTime() instead of CurrentTime (but that's just for understanding, there's no problem with the patch itself, esp. not on local X11 servers)

> If you want to do another test on the causes, check whether you patch still works with QX11Info::appTime() instead of CurrentTime

Yes, that seems to work.

- Wolfgang

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121755/#review83168
-----------------------------------------------------------

On Juli 29, 2015, 11:39 vorm., Wolfgang Bauer wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121755/
> -----------------------------------------------------------
> 
> (Updated Juli 29, 2015, 11:39 vorm.)
> 
> 
> Review request for kde-workspace, Thomas Lübking and Oswald Buddenhagen.
> 
> 
> Bugs: 268988 and 338018
>     http://bugs.kde.org/show_bug.cgi?id=268988
>     http://bugs.kde.org/show_bug.cgi?id=338018
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> -------
> 
> [Commit d03df616](https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/d03df6169ecb291318e87099a346488c961fe1d6) made input grabbing optional in KDM. But without it, input dialogs do not correctly get focus and keyboard shortcuts don't work.
> 
> KDM does call activateWindow() on opened dialogs, but this doesn't seem to have the desired effect without a window manager running. And if you hover the mouse over a widget, it visually looks like it has focus, but often it doesn't accept input anyway.
> 
> This patch sets the input focus via XSetInputFocus() instead, this also has the positive side-effect that a widget retains the focus if you move the mouse away.
> 
> 
> Diffs
> -----
> 
>   kdm/kfrontend/kfdialog.cpp 3f6fa84 
> 
> Diff: https://git.reviewboard.kde.org/r/121755/diff/
> 
> 
> Testing
> -------
> 
> Tried all things mentioned in the bug reports, keyboard input and shortcuts work now in all cases.
> 
> I also tested with onboard keyboards (xvkbd and kvkbd), both work fine. Before, kvkbd didn't work at all (the text input widget lost focus as soon as you moved the mouse to the OSK) and xvkbd only works if you forced the focus to the text input widget via its "Focus" button (from which this patch was inspired actually ;-) ).
> 
> Other openSUSE users have tested this as well, and the patch is even part of openSUSE's official package since January.
> See also https://bugzilla.opensuse.org/show_bug.cgi?id=772344
> 
> 
> Thanks,
> 
> Wolfgang Bauer
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20150804/db75b38a/attachment.htm>