Bug 1419

I can try my luck, but first the Xarch board (xorg_arch@x.org) has to give the
permission to restore the extension.
And it may even be interesting to extend the XIDLE extension that the idle
status for each screen and each window can be queried seperately (e.g. per
screen for per-screen screensavers and per-window for tools like xcompmgr to
make "idle" windows more transparent than those which were more recently
active).

(In reply to comment #1)
> I can try my luck, but first the Xarch board (xorg_arch@x.org) has to give the
> permission to restore the extension.
> And it may even be interesting to extend the XIDLE extension that the idle
> status for each screen and each window can be queried seperately (e.g. per
> screen for per-screen screensavers and per-window for tools like xcompmgr to
> make "idle" windows more transparent than those which were more recently
> active).

Yes, we will all want that ;)

bjd

Jamie, I agree that resurrecting the XIdle extension may be a good idea.
One may want to add new features - but this doesn't have to happen in one step:
We can reinclude the old version and add new things in the future.

However I'm curious why the MIT-SCREEN-SAVER extension doesn't meet your needs:
It is very easy to receive an event when the time for the screen saver has
expired (ie. no input has been made). So I assume that the overhead with the
'screen saver window' doesn't meet your needs.

(In reply to comment #3)
> However I'm curious why the MIT-SCREEN-SAVER extension doesn't meet your needs:
> It is very easy to receive an event when the time for the screen saver has
> expired (ie. no input has been made). So I assume that the overhead with the
> 'screen saver window' doesn't meet your needs.

http://www.jwz.org/xscreensaver/man1.html

There's a section in there about MIT-SCREEN-SAVER being ugly when fading into
the screensaver (the way you can do on SGI and XIDLE-having machines).  That
alone justifies it for me.

Roland's comment about extending XIDLE to report idle times per-window seems
excessive in the presence of XEVIE, which any serious compmgr will end up using.
 Per-screen almost makes sense but would assuredly confuse users (neither XP nor
OS X do independent screen saver timeouts per screen).

Would it be more difficult to "fix" MIT-SCREEN-SAVER than reviving XIDLE?

(In reply to comment #5)
> Would it be more difficult to "fix" MIT-SCREEN-SAVER than reviving XIDLE?

Primary purpose of MIT-SCREEN-SAVER are screen-savers while XIDLE could be used
for other stuff, too (custom IME comes in mind).

(In reply to comment #4)
[snip]
> Roland's comment about extending XIDLE to report idle times per-window seems
> excessive in the presence of XEVIE, which any serious compmgr will end up using.

Using XEVIE here may be possible but it would be a pain. Why having the compmgr
to track each and every single event per window when the same information is
already in the Xserver ? XIDLE would just expose these values.
And the idea with compmgr usage was just an example - there are likely more
places where these values could be used to implement usefull stuff...

> Per-screen almost makes sense but would assuredly confuse users (neither XP 
> nor OS X do independent screen saver timeouts per screen).

AFAIK both XP and MacOSX treat both monitors as a single surface - but X11 also
allows that multiple monitors act completely independently ("traditional
multihead") so having (optional) ways to do the screen blanking independently
sounds a good idea for me...

The MIT-SCREEN-SAVER extension takes this approach:

   - when the user is idle, immediately map full screen
     black windows on each screen;

   - inform the screen saver client that the screen is now
     black;

   - when user activity occurs, unmap the windows an inform
     the screen saver client.

The screen saver client can specify a few parameters of that
window, like visual and depth, but that's it.

The way xscreensaver works is:

   - detect when the user is idle;

   - optionally fade the screen slowly to black (by playing
     games with gamma and/or colormaps);

   - map a black window or windows.  note that in xinerama-
     mode, it may map more than one window per X screen (to
     achieve the effect of having different graphics on each
     monitor.)

   - choose a screen saver to run, and choose an appropriate
     visual for it (e.g., different visuals may be needed
     for "normal" X programs than for OpenGL programs.)

   - after a timeout, choose a different screen saver to
     run.  If the new one needs a different visual, create a
     new window for it and destroy the old window.

   - detect user activity;

   - optionally fade the desktop in from black.

So what this comes down to is that xscreensaver just *can't*
use the window that was created by the MIT extension.  It
appears on screen too early, is removed from the screen too
early, its visual cannot be changed after it was created,
and there might be one window instead of four.

There's a lot of complicated logic and policy up there,
related to when and what manner of windows get mapped when
the user is idle.  Currently, the MIT extension is dictating
policy, and that policy belongs in a client, not in the
server.

Also, in my experience, use of the MIT extension led to
occasional server crashes on various systems.  Given its
other shortcomings, I never bothered to track that down, and
instead, just disabled it by default in xscreensaver long
ago.

So, yeah, I don't really have much desire to see the
MIT-SCREEN-SAVER extension fixed, because, not to mince
words, I think it's junk...

SGI had their own SCREEN-SAVER extension that just reported
two events: "user is idle" and "user is no longer idle."  I
was able to make good use of that in xscreensaver.  However,
given the namespace collisions, it wouldn't be possible for
the MIT and SGI savers to exist simultaniously in either the
same X server or the same X client.  So porting/cloning that
extension isn't really an option.

So I think that XIDLE is our best bet.

For my purposes, a single per-display query that gives me
the time at which the last user input occurred would be
sufficient.

If we're talking about extending XIDLE with additional
features, one thing that would be useful would be a way to
feed idle times back upstream: for example, xscreensaver
would sometimes like to say "consider the user to be idle
now" and "consider the user to no longer be idle now."

I don't think that per-Screen idle-reporting would be
particularly useful.  99.9% of the people who have multiple
monitors use Xinerama instead of multiple screens per
display, and such a thing wouldn't work in that case anyway.

The old XIDLE code is here:
http://ftp.rge.com/pub/X/X11R5/contrib/xidle.tar.gz

(I wanted to check out XEVIE and see if perhaps it would be
appropriate for to be making use of that in xscreensaver,
but all the links on http://freedesktop.org/Software/XEvIE
are 404.)

> (I wanted to check out XEVIE and see if perhaps it would be
> appropriate for to be making use of that in xscreensaver,
> but all the links on http://freedesktop.org/Software/XEvIE
> are 404.)

I've fixed the links, thanks for the catch.

Thanks for the explanation.   It does sound like resurrecting XIdle is more 
reasonable than attempting to completely rewhack MIT-SCREEN-SAVER to simply
end up with something that's much more like XIdle.

Are there any objections that I take the bug and try my luck with a patch (and
ask xorg_arch to get the extension back in the default build) ?

Roland, please go for it.
But forget about xorg_arch. I would think discussing this on xorg@ would get 
more feedback. Simply point people to this ticket and they should understand why
this is a good idea.

*ping* One year since the last comment!

I am writing a backlight dimming utility for laptops, and need idle times
separate from any screen blanking activity. May I bug the assignee to work on it
or pass the project along to someone else?

My two cents:

 o JWZ's suggestion of feeding idle times back to the system
   would be excellent; on a laptop, if the user clicks "lock
   screen now" then the backlight would also dim immediately,
   away messages would go up on your instant messenger, etc.

  o From the sample code I've read over, the old XIDLE required
   polling of the idle state; async notification would be nice.

The assignee is xorg-team, which means it's unassigned and simply sitting here
waiting for someone to care enough about it to volunteer to do the work.

I know absolutely nothing about the internals of X nor or Xlib programming...
assuming that the old xidle contrib code would just need to be ported and
updated, where would you put this on a 1-10 scale of difficulty?

(In reply to comment #15)
> I know absolutely nothing about the internals of X nor or Xlib programming...
> assuming that the old xidle contrib code would just need to be ported and
> updated, where would you put this on a 1-10 scale of difficulty?

3 to 5 (assuming you mean 10 as hardest).

It seems you can use the screensaver extension just to get the idle time, and 
ignore all the rest of it...

See for example:
http://svn.mugshot.org/dumbhippo/trunk/client/linux/src/hippo-idle.c

Originally found in the GNOME "typing break" code. It seems to work OK so far.

This does involve polling still, maybe getting an event is slightly better.

I too would like to be able to feed the idle time back.  I'm in the process of trying to hash out a pleasant system where joystick activity reasonably delays screensaver activation.  It might be nice to have the X Server pick this up itself, but there are some issues there (is it worth it to add a driver to X just to pick up idleness?).  

Right now I've a userspace program that finds out about joystick plugin events events via dbus, blocks a read on each joystick, and delays screensaving via 'xset' or 'xscreensaver-command', which the user has to pick.  It would certainly be more elegant to simply notify the X server that user activity is occurring.

Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.

XIDLE is fundamentally the wrong approach, since a polling-based API is not very useful.  fredrikh committed a new idle sync counter to xserver's git master, which doesn't require any new extensions, requests, or events, and allows you to avoid polling.