RandR 1.2 output properties and options

[Srećko Morović]

On 11/18/06, Keith Packard <keithp at keithp.com> wrote:
>
>
> 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.



Certainly synchronous (mode changes are rare so UI/WM hopefully won't be
starved-except if application starts to do DoS with randr calls), manager
should resolve calls immediately; either block or allow, possibly modify
parameters, e.g. if user wants refresh rate to be enforced - or, as
discussed in another post, if there is a special TV encoder so that
modelines (coming from a program not aware of special TV-out extension) have
to be overriden to something more fancy (not sure though if this matching
logic should be in external manager (library) or be in server or drivers).



> 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.



Good use case as well (needs randr call can to be somehow mapped to
application so WM can detect when it exits or crashes). If "Manager" does
bookkeeping of modes <-> applications, it is possible for example to do
alt-tabbing between fullscreen apps, where manager will suspend mode changes
for one it switched from and before putting other in front, restore mode
belonging to it  (so that apps where author forgets to re-set the mode will
still work). Mode change callback can be used to tell FS application to
voluntarily "suspend" while in background, but maybe manager should be
capable of masking that callback for some apps (those that are already
suspended) to avoid possible race conditions.


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
> future.


Agreed.


Srecko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg/attachments/20061120/e98cac33/attachment.html>