Intel Works On RandR Implementation For Wayland's Weston

[phoronix]

Phoronix: Intel Works On RandR Implementation For Wayland's Weston

The latest work by Intel employees on Wayland is adding an RandR protocol, similar to the X RandR protocol, to the Weston compositor...

http://www.phoronix.com/vr.php?view=MTYxNjg

[papper]

You didn't think it would be prudent to comment on the fact that they seem reluctant to accept these patches?

[newwen]

They say this kind of protocol should be private and not exposed publicly to regular clients.

[ssokolow]

They say this kind of protocol should be private and not exposed publicly to regular clients.

I generally agree. One of the biggest reasons I was looking forward to Wayland was because of the "applications which want to fullscreen can only use a resolution-changing API similar to xdg-screensaver which is bound to a window and can't get stuck if the application dies unexpectedly" idea.

Allowing RandR via a public API makes it that much easier for lazy ports of Windows games to do the wrong thing... potentially bringing us back to square one by requiring a hack analogous to "focus-stealing prevention" but for resolution changing.

[JX8p]

Weston grows again? So much for it just being a "simple reference compositor".

[TheOne]

Weston grows again? So much for it just being a "simple reference compositor".

Well since wayland is just a protocol you could said that Weston is the project which proves that wayland does works, without weston wayland would be pure vaporware.

[DrYak]

Allowing RandR via a public API makes it that much easier for lazy ports of Windows games to do the wrong thing... potentially bringing us back to square one by requiring a hack analogous to "focus-stealing prevention" but for resolution changing.

On the other hand, you'll want to have applications like "KScreen" which help you handle plugging -in and -out screen, selecting different resolution for displays that supports several, etc.
The problems you mention should be handled by granting capabilities and similar.

A regular application shouldn't be able to directly call into RandR APIs (or at least, nothing beyond getting a few basic info about currently plugged in monitors. That wouldn't be disruptive, and might be handy for some specific software: presentation software like LibreOffice Impress might need to know if there's a projector plugged in, so they know on which screen to ask for a fullscreen window (for the actual presentation) and on which screen to keep the user interface (for the presenter's notes).

Only special application (like applets part of the desktop environment, like KDE's KScreen, or a potential "WRandR" for Wayland/Weston) should be granted special rights to manipulate screen settings for the whole compositor (along with a mechanism to revert change to latest "good" setting. So even in the case of a "WRandR"'s crash, the screen reverts if the Wayland server didn't get any confirmation before timeout).
Any other application should be receiving a "request denied" answer.

[curaga]

Hm, doesn't seem to be useful outside wayland. There's still a hole in that no "drmrandr" exists that would allow resolution switching / underscan / etc control for the VTs.

[erendorn]

They say this kind of protocol should be private and not exposed publicly to regular clients.

This looks like the correct approach to me.
I cannot think of any use case where a client would need to set the display to a specific value that would not be covered by wl_shell_surface.set_fullscreen.

[Lemonzest]

Whats Waylands support for 2+ monitors?