Announcement

Collapse
No announcement yet.

Intel Works On RandR Implementation For Wayland's Weston

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Intel Works On RandR Implementation For Wayland's Weston

    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

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

    Comment


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

      Comment


      • #4
        Originally posted by newwen View Post
        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.

        Comment


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

          Comment


          • #6
            Originally posted by JX8p View Post
            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.

            Comment


            • #7
              Originally posted by ssokolow View Post
              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.

              Comment


              • #8
                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.

                Comment


                • #9
                  Originally posted by newwen View Post
                  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.

                  Comment


                  • #10
                    Whats Waylands support for 2+ monitors?

                    Comment


                    • #11
                      Originally posted by Lemonzest View Post
                      Whats Waylands support for 2+ monitors?
                      Already supports it for a very long time

                      Comment


                      • #12
                        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.

                        Comment


                        • #13
                          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.

                          Comment


                          • #14
                            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??

                            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?

                            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

                            Comment


                            • #15
                              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.

                              Comment

                              Working...
                              X