Re: Review Request 121755: Fix input focus for KDM's dialogs when GrabInput is not active
On Juli 31, 2015, 10:24 vorm., Oswald Buddenhagen wrote: the description makes a good commit message, so please make sure you use that (apart from adding the BUG lines). Yes, of course. It's not my first commit to kde-workspace and I always handled it like that, i.e. using my description as commit message and adding the BUG lines. (I'm actually using the kdelibs template for my git commits...) ;-) - Wolfgang --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121755/#review83215 --- 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
Re: Review Request 121755: Fix input focus for KDM's dialogs when GrabInput is not active
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) 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? - 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
Re: Review Request 121755: Fix input focus for KDM's dialogs when GrabInput is not active
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. 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? 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) - 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.)
Re: Review Request 121755: Fix input focus for KDM's dialogs when GrabInput is not active
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:
Re: Review Request 121755: Fix input focus for KDM's dialogs when GrabInput is not active
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. 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) Wolfgang Bauer wrote: 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. Thomas Lübking wrote: Ok, then it seems QWidget believes it's not mapped while it is - or it's only mapped by a sync triggered by XSetInputFocus (what then might become a problem when/if kdm is ported to xcb) Wolfgang Bauer wrote: I think that's becoming theoretical now. Who's going to port
Re: Review Request 121755: Fix input focus for KDM's dialogs when GrabInput is not active
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121755/ --- (Updated Aug. 4, 2015, 5:53 p.m.) Status -- This change has been marked as submitted. Review request for kde-workspace, Thomas Lübking and Oswald Buddenhagen. Changes --- Submitted with commit 46f1055ffdcd2e068296576a7824012f42e9b9a8 by Wolfgang Bauer to branch KDE/4.11. 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
Re: Review Request 121755: Fix input focus for KDM's dialogs when GrabInput is not active
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) Wolfgang Bauer wrote: 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. Thomas Lübking wrote: Ok, then it seems QWidget believes it's not mapped while it is - or it's only mapped by a sync triggered by XSetInputFocus (what then might become a problem when/if kdm is ported to xcb) Wolfgang Bauer wrote: I think that's becoming theoretical now. Who's going to port
Re: Review Request 121755: Fix input focus for KDM's dialogs when GrabInput is not active
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121755/#review83215 --- Ship it! the description makes a good commit message, so please make sure you use that (apart from adding the BUG lines). - Oswald Buddenhagen On July 29, 2015, 9:39 a.m., Wolfgang Bauer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121755/ --- (Updated July 29, 2015, 9:39 a.m.) 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
Re: Review Request 121755: Fix input focus for KDM's dialogs when GrabInput is not active
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. 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. - 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
Re: Review Request 121755: Fix input focus for KDM's dialogs when GrabInput is not active
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,
Re: Review Request 121755: Fix input focus for KDM's dialogs when GrabInput is not active
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121755/#review83168 --- 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. - Thomas Lübking 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
