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

[Thomas Lübking]

> On Juli 30, 2015, 10:05 vorm., 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.

> 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)


- Thomas


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


On Juli 29, 2015, 9: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, 9: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/20150730/42c1db36/attachment.htm>