<div>On 11/18/06, Keith Packard <<a href="mailto:keithp@keithp.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> keithp@keithp.com</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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.</blockquote><div> 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). </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> 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.</blockquote><div> 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. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.</blockquote><div> Agreed. </div></div> Srecko