GNOME Bugzilla – Bug 335831
does not stop the session going idle when just scrollwheel is used
Last modified: 2006-04-04 14:39:57 UTC
When I'm reading a document in firefox or evince, I just use the scroll-down scrollwheel to read the document. After the delay I've set in g-s-p, the screen dims as g-p-m thinks that the session is idle. This is wrong. I guess the fix is to monitor the scroll events as well as the mouse move and button events. Tell me what extra info you need. Thanks, Richard.
I remember now. Here's one of the comments (from jwz) in gs-watcher-x11.c: /* Select for SubstructureNotify on all windows. Select for KeyPress on all windows that already have it selected. Note that we can't select for ButtonPress, because of X braindamage: only one client at a time may select for ButtonPress on a given window, though any number can select for KeyPress. Someone explain *that* to me. So, if the user spends a while clicking the mouse without ever moving the mouse or touching the keyboard, we won't know that they've been active, and the screensaver will come on. That sucks, but I don't know how to get around it. Since X presents mouse wheels as clicks, this applies to those, too: scrolling through a document using only the mouse wheel doesn't count as activity... Fortunately, /proc/interrupts helps, on systems that have it. Oh, if it's a PS/2 mouse, not serial or USB. This sucks! */
Ok, thanks for the info. I love X! Is it worth asking the X.org guys for some input (heh) on this?
I imagine only one client can select for ButtonPress because when X gets a buttonpress event it implicitly grabs the pointer (until button release or an explict XGrabPointer). We should probably push for XIDLE to get added to Xorg. One random thought...Can we watch for _NET_WM_USER_TIME changes to work around this? Modern toolkits should update that property, I believe, when the user clicks/scrolls anyway.
for reference here's the xidle bug: https://bugs.freedesktop.org/show_bug.cgi?id=1419
xidle, as it stands, doesn't really seem ideal to me. We really don't want to have to poll. Using a signal/event based approach seems much more useful - especially for noticing activity during the activation warning period. Also, the suggestions in that bug that it should be possible to "feed back" information into the server seems really odd to me. If you regard X11 input as just one source of input then there is really no need to inject information into the server. It seems the motivation for this is to handle the screen is locked case. I think it makes more sense to define idle policy and state outside the Xserver.
Unless I'm missing something obvious, this sounds perfect: http://freedesktop.org/wiki/Software/XEvIE
A quick test showed that using libXevie with an xorg server with XEVIE enabled detects these events nicely.
Yay, I guess most distros compile XEVIE into xorg? FC5 sure does.
However, it is off by default. And it seems like some versions only support one client using it at a time. So, this will obviously have to be optional support.
Actually, it looks like the multiple client support may never have been completed. Ray, do you about its status?
No idea.
Soeren might know though, adding to CC list.
Created attachment 62583 [details] [review] watch for user time changes on windows Hey Richard, Does something like the above fix things for you? I don't have a scroll wheel so I can't test.
Yes Ray, that patch works as required. When I'm scrolling through a document in evince, I get: [_gs_watcher_notice_activity] gs-watcher-x11.c:569 (09:58:07): Activity detected: resetting timers [remove_idle_timer] gs-watcher-x11.c:464 (09:58:07): killing idle_timer (60000, 208) [add_idle_timer] gs-watcher-x11.c:477 (09:58:07): starting idle_timer (50000, 209) [_gs_watcher_check_pointer_position] gs-watcher-x11.c:1404 (09:58:07): Idle 0 seconds and the screen no longer dims. Jon, good to commit if you ask me. Thanks again Ray, Richard.
Thanks Ray. I've committed this. I'll open a new bug for xevie support.