RandR 1.2 output properties and options

Keith Packard keithp at keithp.com
Sat Nov 18 14:05:43 PST 2006

On Sat, 2006-11-18 at 13:07 +0000, Srecko Morovic wrote:
> Keith Packard <keithp <at> keithp.com> writes:
> > 
> > This raises some interesting questions -- who gets to set the range of
> > valid values? Can you set and query the pending value separately from
> > the current value?
> >
> Besides a range set by X server based on driver, display and config file
> information, there should be a method to block certain property (or mode switch)
> change and ability to have limited alowed "subset" of settings, as a policy. I
> think this control ability(API) should be given to window managers as they are
> responsible for a lot more (input interception, even compositing).

Hmm. An interesting idea; effectively a RandR 'redirect' that could take
mode switch requests and push them through an external application. I
think this idea has some merit. I also think it can be added later, much
as the existing window redirection was bolted onto the existing window
manipulation system. I would suggest that we make this redirection
synchronous so that we don't end up with applications failing to wait
for the mode switch to occur.

> What this could allow is better fail-safe way to tackle misbehaving apps which
> are constantly trying to set strange property/mode ( similar concept is
> applicable also to those that steal input, focus or trying to stay on top). WM
> could be configured to catch on certain input combination and after reverting to
> default mode and at the same point disallowing property or mode changes, it can
> launch session control application, which can for example present user with
> tasklist and ability to kill bad process (similar to ctrl+alt+del event in 
> Windows).

Or even some way to make mode switching revert to the previous mode when
the application performing the switch exits.

I think these are both interesting ideas that we can look at adding to
the extension in the future; right now I'm focused on getting the
semantics of the actual mode switch correct and making sure we don't
prevent the kinds of changes you're suggesting from happening in the

keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20061118/e8fc178d/attachment.pgp>

More information about the xorg mailing list