[PATCH] xRandr strikes back

[Jonas Ådahl]

On Sun, Mar 10, 2013 at 4:39 PM, Scott Moreau <oreaus at gmail.com> wrote:
>
>
> On Sun, Mar 10, 2013 at 9:17 AM, Jonas Ådahl <jadahl at gmail.com> wrote:
>>
>> On Sun, Mar 10, 2013 at 3:53 PM, Hardening <rdp.effort at gmail.com> 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 Jonas,
>
>>
>>
>> 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.
>
>
> What you stated is the common consensus but the fact is, we have no way to
> change the output resolution in weston while it is running. This is not a
> secure protocol and any client can use it, true. However, we need a way to
> do this right now so we can shake out the bugs that do not detect mode
> switching properly. The outstanding case is desktop-shell components, panel
> and background. It would be interesting to find a way to secure a protocol
> such as this but aside from handling mode switching directly in the
> compositor somehow, there's really not many sane options left. Unless you
> have a better way to switch modes while weston is running?
>

One simple (but not as convenient I suppose) way would be to add debug
bindings to the shell that increase or decrease resolution according
to some resolution list. I haven

> - Scott
>
>>
>>
>> Jonas
>>
>
>