Intel Works On RandR Implementation For Wayland's Weston

[gufide]

Whats Waylands support for 2+ monitors?

Already supports it for a very long time

[Tom B]

So will this simplify configuration of multiple monitors running from different GPUs of different vendors? As it stands all the methods of doing this are a bit hacky and messy.

[schmidtbag]

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.

That's true, though GNOME 3 and Enlightenment are currently wayland compatible and KDE will be pretty soon. By the time KDE supports it, weston won't be a necessity. However, weston has really transformed into something functional. I've considered switching my XFCE setup to weston. I don't even like most of the XFCE applications, I just like how balanced XFCE is in terms of system resources and features.

[newwen]

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.

Well, each compositor can have it's own private dBus protocol and ship with its own XRandR-like app.
BTW, Is there any permissions granting mechanism in wayland??

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

Good point. Wouldn't a read-only RandR-like protocol be enough for this use case?

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.

have a look at the use cases described by DrYak

[Ericg]

Well, each compositor can have it's own private dBus protocol and ship with its own XRandR-like app.
BTW, Is there any permissions granting mechanism in wayland??

Its in the works. Currently its only limited input capture and screen recording, but it could probably be extended to monitor settings as well.

[shmerl]

Since KDE will be using Kwin as Wayland compositor, I wonder what features are going to end up there. Weston is really of little practical use for end users, but I guess developers of other compositors can reuse its code.

[nanonyme]

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.

Can you select full-screen resolution and refresh rate with it? If not, it's not enough for games.
Edit: After reading some docs, yes it is. wl_shell_surface::fullscreen_method as an argument set to driver should actually resize the screen (possibly adding black borders). http://wayland.freedesktop.org/docs/...l_surface.html

[nanonyme]

Honestly though, xrandr isn't an all bad API and eg Wine now has support for it. If wrandr as an API is similar/same, having a remapper for existing programs that need to change modesetting would probably not be unfeasible.

[droste]

I think these are pretty good arguments against this approach:

Let's say I want to change a mode and move an output to another side.
How would I do that atomically? I mean, without the compositor e.g.
first showing me the output on the other side in original mode, and
then switches the mode to what I asked for.

How do I do many operations, perhaps on multiple outputs, in a single
shot without flickering or glitches?

If I change the mode on two different outputs, how do I know which
action_done corresponds to which request?

What if move succeeds but mode change fails? Wouldn't that leave the
output in an unwanted state which is neither the original nor the
wanted setting?

The solution to this would tie in with the solution to take changes
atomic. For instance, to prepare for a configuration change, one might
create a change object in the protocol, store all changes in that
object, and then commit that set of changes atomically. Then have one
return value: the whole set either succeeds or fails.

I guess you could look for inspiration in the DRM atomic mode setting
API. I don't know how the RandR X11 protocol works, if that would be a
good example also.

Second, it doesn't appear that you have any security mechanism for this? I
don't think we want arbitrary clients to be allowed to rotate, change mode,
and change output layout. While I agree that it would be great to have a
tool (possibly even a command-line one) to do these things dynamically, we
shouldn't make it a public interface that just anyone can bind to. I'm not
saying that some sort of randr interface isn't needed. I'm simply that it
should be privileged and we need a well-defined mechanism for keeping rogue
applications from messing up the compositor for everyone else. For
standard applications, I believe the intention is that any modesetting they
do will be done in a very controlled manner through the shell.

[erendorn]

have a look at the use cases described by DrYak

Obviously the shell needs to provide an application to let the user configure the screen, I was thinking more about arbitrary clients.