GNOME Bugzilla – Bug 444927
get idle time from xorg
Last modified: 2009-08-21 04:23:14 UTC
Matthias pointed me to: http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=7e2c935920cafadbd87c351f1a3239932864fb90 It seems like it should work. I guess we can define two alarms: 1. Positive transition of IDLETIME at (gs-idle-timeout - 10 sec) 2. Negative transition of IDLETIME at (gs-idle-timeout - 10 sec) so long as they don't race each other. This is in order to support the cancellation of the warning fade out.
Hi all, do you think this is hard to implement ? I'd like to give it a try, but don't know either gnome-screensaver or Xorg, so it's hard to evaluate the dificulty of this task... If someone is able to give me some hints or advice, I'd like to help in getting rid of the useless wakeups in the GNOME desktop. See http://blog.freeside.fr/post/2007/12/11/Process-wakeups-on-GNOME-218
Great. Thanks for taking a look at this. FWIW, the stuff in that blog is obsolete. Things are a little different now. Anyway, this bug still applies. I think Richard has some code in gnome-power-manager that uses xsync. So, that would probably be a good place to start.
Well, the blog is mine, and tests were done on GNOME 2.18 :-) So I'm happy if the situation improved. On the gpm side, I only could find bug 325911, for which you have implemented idle management (which may have caused bug 427815 ?), so I supose the whole idle management is don in src/gpm-idle.[ch]. I still find in src/gpm-idle.c this: /* How many seconds between polling? */ #define POLL_FREQUENCY 5 So I don't think gpm has implemented the xlib solution...
Oh, and could you please point out the outdated stuff in my blog entry so I can update it ? Thanks.
Oh, maybe Richard has not put the xsync in svn yet. Not sure. Been a while since I looked. I haven't had a chance to study what you're doing in the blog but one thing is that you may be confusing the idea of "polling" (ie. waking up an checking stuff) with the poll syscall. The poll syscall does not wakeup. We do set some timeouts but they are very long (on the order of minutes). Since Ryan wrote that stuff we did this: 2006-10-19 William Jon McCann <mccann@jhu.edu> * src/gs-watcher-x11.c: (notice_events_inner), (query_pointer_timeout), (gs_watcher_xevent), (start_idle_watcher), (stop_idle_watcher), (gs_watcher_init), (gs_watcher_finalize), (power_timer), (idle_timer), (schedule_wakeup_event): Remove the pointer polling and try to select motion events. Fixes #363436. Hope that helps.
Ok, I checked again the numbers and you're right: they're far too high. What is strange is that I tested that twice, and had similar (bad) results, but I don't know why... First run: % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- nan 0.000000 0 10 read nan 0.000000 0 31 ioctl nan 0.000000 0 22 gettimeofday nan 0.000000 0 10 poll ------ ----------- ----------- --------- --------- ---------------- 100.00 0.000000 73 total Second run: % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- nan 0.000000 0 10 read nan 0.000000 0 33 ioctl nan 0.000000 0 26 gettimeofday nan 0.000000 0 1 writev nan 0.000000 0 12 poll nan 0.000000 0 1 clock_gettime ------ ----------- ----------- --------- --------- ---------------- 100.00 0.000000 83 total And now, when I perform the same test, I have: % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- nan 0.000000 0 1 ioctl nan 0.000000 0 2 gettimeofday ------ ----------- ----------- --------- --------- ---------------- 100.00 0.000000 3 total So I really don't understand what happened. Maybe my mouse moved on the other tests, just a bit...
This also means that I didn't understand really this bug report, as I thought it was to correct that (non-existent) issue. Could you please give me some information about: * how it's done currently * why it needs to be improved * and how you'd like to have it done. Thanks in advance.
*** Bug 547131 has been marked as a duplicate of this bug. ***
Fixed in trunk.
*** Bug 552209 has been marked as a duplicate of this bug. ***
*** Bug 586310 has been marked as a duplicate of this bug. ***
*** Bug 581344 has been marked as a duplicate of this bug. ***
*** Bug 335149 has been marked as a duplicate of this bug. ***
*** Bug 347092 has been marked as a duplicate of this bug. ***