Page 2 of 2 FirstFirst 12
Results 11 to 20 of 20

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

  1. #11
    Join Date
    Apr 2013
    Posts
    124

    Default

    Quote Originally Posted by Lemonzest View Post
    Whats Waylands support for 2+ monitors?
    Already supports it for a very long time

  2. #12
    Join Date
    Feb 2014
    Posts
    30

    Default

    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.

  3. #13
    Join Date
    Dec 2010
    Location
    MA, USA
    Posts
    1,485

    Default

    Quote Originally Posted by TheOne View Post
    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.

  4. #14
    Join Date
    Dec 2012
    Posts
    202

    Default

    Quote Originally Posted by DrYak View Post
    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??

    Quote Originally Posted by DrYak View Post
    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?

    Quote Originally Posted by erendorn View Post
    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

  5. #15
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,939

    Default

    Quote Originally Posted by newwen View Post
    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.

  6. #16
    Join Date
    Dec 2009
    Posts
    367

    Default

    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.

  7. #17
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,806

    Default

    Quote Originally Posted by erendorn View Post
    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
    Last edited by nanonyme; 02-27-2014 at 03:14 PM.

  8. #18
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,806

    Default

    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.

  9. #19
    Join Date
    Jul 2009
    Location
    Germany
    Posts
    542

    Default

    I think these are pretty good arguments against this approach:

    Quote Originally Posted by Pekka Paalanen
    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?
    Quote Originally Posted by Pekka Paalanen
    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.
    Quote Originally Posted by Jason Ekstrand
    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.

  10. #20
    Join Date
    Sep 2012
    Posts
    792

    Default

    Quote Originally Posted by newwen View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •