GNOME Bugzilla – Bug 492974
only locks one screen
Last modified: 2018-07-01 08:56:42 UTC
[ Forwarded from http://bugs.debian.org/449102 by Karl Chen ] I have two monitors with two Screen definitions in my xorg.conf. When the typing break enforcement feature of gnome-typing-monitor locks the screen, it only locks one of the screens.
Can't recreate this issue with my two screen/two monitor, This might be fixed, need info from Karl Chen on details of his setup
100% true. I use 2 screens with xrandr extension. Postpone button is out of the "locked" screen and another screen is totally functional: I can do anything on it.
Another downstream report is https://bugzilla.redhat.com/show_bug.cgi?id=448077 I have not seen this in Fedora 8 in Zaphod mode (two separate screens, :0.0 and :0.1) - maybe the comment #1 is from the Zaphod mode? The bug is present in Fedora 9 (control-center-2.22.1-4.fc9.x86_64) in xrandr mode (i.e. single virtual screen spanning over two physical monitors). Moreover, when the cursor is on the second screen, the typing monitor locks only this screen, but under the grey stripes there is a screenshot from the _first_ screen. I have not tested Fedora 8 with xrandr (I have no F8 with dual head anymore) nor Fedora 9 with Zaphod mode (the ATi driver in F9 does not work for me in Zaphod mode).
I see this using nvidia TwinView, Debian testing with g-c-c 2.22.1. The unlocked screen responds to mouse input, but not keyboard.
This bug is still present in gnome 2.24 (Fedora 10). Any chance of getting it fixed?
I tried to block bug 573207 with this bug as Federico asked, but failed for lack of permissions.
Still present in GNOME 2.28 (Fedora 12). Is anybody working on it?
Created attachment 149287 [details] [review] a patch I see this with multiple monitors and no compositing manager. What is happening is that the window has a size of 200x200 at the time the background pixmap is set, because the window manager doesn't respect the default size (I think). This patch gets the window manager out of the equation by making the window override-redirect, which is arguably more correct anyway. One thing that is still not handled here is correctly locking of dynamically appearing monitors, ie plug in a monitor while the typing break is active.
Another improvement would be to repeat the 'typing break' message on all monitors, since the slightly grayed out appearance is not exactly obvious without the message. Oh, and it should show the controls on the primary monitor, not just on monitor 0.
Comment on attachment 149287 [details] [review] a patch Indentation is off once again, please commit with that fixed.
Created attachment 155733 [details] [review] [typing-break] Lock all the screens Gray out all the monitors properly when the typing break is on.
Comment on attachment 155733 [details] [review] [typing-break] Lock all the screens Committed to gnome-2-28 and master
I think this patch is broken: with the latest gtk you get: (gnome-typing-monitor:14132): GLib-GObject-WARNING **: IA__g_object_set_valist: construct property "type" for object `DrwBreakWindow' can't be set after construction
Apparently in control-center-2.30.1-2.fc13.x86_64 (Fedora 13) the bug is back. As far as I can tell, it has disappeared in Fedora 12 (control-center-2.28), but reappeared in 2.30. In addition to that, in 2.30 it sometimes does not gray out _any_ screen, leaving the user confused. The only sign that typing break is in progress (apart from losing the keyboard input) is the notification-area applet, which is red non-blinking. I can use the mouse, but not the keyboard. Another problem (probably worth a separate bug report?) is that it does not count the time the screen has been locked: yesterday I left my computer locked (gnome-screensaver) with just few minutes remaining to the typing break, and the typing break occured today almost immediately after I unlocked the screen and started working. This is probably related to this downstream bug "Typing break does not count suspend time": https://bugzilla.redhat.com/show_bug.cgi?id=485588
*** Bug 632075 has been marked as a duplicate of this bug. ***
Mass move to DrWright module. The code has been removed from the control-center, and put back in the drwright module as its interaction with the GNOME 3.x experience was not defined. See http://git.gnome.org/browse/drwright
This is still happening in version 3.5.0, gnome 3.10
DrWright is not under active development anymore, has not seen code changes for about five years, and saw its last tarball release in the year 2012. Its codebase has been archived: https://gitlab.gnome.org/Archive/drwright/commits/master Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.