On Mon, Mar 11, 2013 at 2:09 AM, Hardening <[email protected]> wrote: > On 10/03/2013 16:17, Jonas Ådahl wrote: >> On Sun, Mar 10, 2013 at 3:53 PM, Hardening <[email protected]> wrote: >>> This patch adds a wlrandr extension. It is useful to test >>> mode switching. The patch provides the weston-switch-mode >>> utility that can be use quite the same way as xrandr to >>> change graphical modes. For now only the DRM backend supports >>> mode switching, but other may follow. >> >> Hi, >> >> I think the consensus has been not to have a protocol like this as >> clients should not dictate what resolution an output should have. A >> client can ask nicely via the fullscreen API a preferred resolution, >> but it should not set it. The point with this is that no client should >> be able to change resolution, crash, and then leave the compositor in >> an invalid state (read wrong resolution). The shell, however, can have >> its own private protocol for doing this, and then whatever user >> interface wants to have to change resolution, but it should not be in >> a client facing protocol. >> > hi, > the current API only allows to switch to mode listed by backends, can we > assume that this list is sane ? > > For the issue with a client dying and leaving the compositor in a weird > resolution. Perhaps the API could change so that clients can specify > that the resolution change is contextual, and the previous resolution > would be set back when the client dies (it would look like the exclusive > part of the screenshooter). >
People shouldn't confuse the requirements for something like a control panel displays applet or command line mode switcher, for the case that a user wants to switch resolution, from the case where an app wants to switch. User directed modesetting doesn't require app tracking, app directed modesetting is best handled by the fullscreen + size hinting protocol. As long as the app directed is in place and apps knows to use it, then having a user directed one is required in some way for control panel type things. Dave. _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
