[Since this is an open LSARC case, this is a copy of the mail sent to
the internal LSARC mailing list.]
I am sponsoring this fasttrack for Mahmood Ali of the X group, and
have set the timer to next Monday, August 13. Since it does not
change any interfaces, just documents and commits existing ones, it
requests a patch release binding.
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
Some X clients need a reliable way to figure out if xscreensaver is
running. For example, Sun Ray's utxlock tries to run xlock if it finds
that xscreensaver is not running. Currently, there is no reliable way to
do this that Sun has documented, but xscreensaver has long provided a
status mechanism, which this case documents and commits to maintain.
When Xscreensaver is running in an X session, an X window will
be created as a child of the root window. When XGetClassHint is
called on this window, it will return an XClassHint structure
which has the 'res_class' field ("application class name") set
to "XScreenSaver".
When Xscreensaver has taken control of the screen, and either made
it blank or is displaying the drawings of a screensaver "hack" module
it will set a property on the root window named _SCREENSAVER_STATUS.
If the screen can be returned to the normal state by just using one
of the input devices to wake it up, without requiring any
authentication, this property will contain an atom with atom_name
"BLANK". If authentication will be required to return to the user
session, this property will contain an atom with atom_name "LOCK".
If the property does not exist or does not contain either atom,
then xscreensaver is not currently controlling the screen.
Imported Interfaces:
X atoms, properties, class hints Committed X11 Standard
Exported Interfaces:
Application class name: XScreenSaver
on a child of the root window Committed
_SCREENSAVER_STATUS property on the
root window Committed
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering