Announcement

Collapse
No announcement yet.

Raspberry Pi Gets New Wayland Weston Renderer

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

  • #11
    So..... why are the wayland developers making a hardware specific backend for weston anyway? Is every arm board and intel and amd chip lines going to need specific backends for weston? What's the point in this?

    Comment


    • #12
      Originally posted by Kivada View Post
      Agreed, they should do a both a $50 model and a $100 dollar model, more options with better performance would draw in more people. Though I'd love to see them focus more on parts that can get fully OSS drivers.
      At $100 and above the appeal and the value of the Pi drops exponentially.

      If i'm going to pay a 3-figure sum for a low-powered computer I'd rather spend more on any aftermarket board with an x86 Atom processor that is only a little more power hungry than the Broadcom SoC used in the Pi but has superior processing power. Not to mention all of the benefits that come with the x86 stack such as a wider range of precompiled software available and Flash support.

      Comment


      • #13
        Originally posted by dh04000 View Post
        So..... why are the wayland developers making a hardware specific backend for weston anyway? Is every arm board and intel and amd chip lines going to need specific backends for weston? What's the point in this?
        Because in this case it is the only way to support the hardware. It does not offer any of the standard Linux APIs. Instead, it has a unique proprietary API. If we want to use the device, we have to use that, since there is nothing else. And in this particular case, you can thank the Raspberry Pi Foundation for contracting us (Collabora) to do this, and supporting us while doing it. Otherwise, you would not be running Weston on the RPi in any usable speed.

        When hardware gets drivers into the Linux kernel and Mesa, or proprietary drivers supporting KMS, GBM, EGL, and GLESv2, we just use the Weston drm-backend with the GLESv2-renderer. That already covers practically all PC hardware.

        Also, using dispmanx for accelerating X would be so unimaginably painful, that it's practically not possible.

        Comment


        • #14
          Originally posted by pq__ View Post
          Because in this case it is the only way to support the hardware. It does not offer any of the standard Linux APIs.
          Which, right now, isn't possible for them to do because of the userspace code required to interface with the VideoCore. So it can't provide KMS.

          Originally posted by pq__ View Post
          Also, using dispmanx for accelerating X would be so unimaginably painful, that it's practically not possible.
          Entirely due to limitations in X's architecture.

          Comment


          • #15
            Originally posted by pq__ View Post
            Also, using dispmanx for accelerating X would be so unimaginably painful, that it's practically not possible.
            By accelerating X, do you mean X11 EGL support for GLESv2? Or RENDER acceleration? Or something else?

            Comment


            • #16
              Originally posted by ssvb View Post
              By accelerating X, do you mean X11 EGL support for GLESv2? Or RENDER acceleration? Or something else?
              He's talking about accelerating composition, rather than rendering. You can do that with GLES if you like, and then hand the server back a single flat image to display, but that ignores the massive dedicated 2D composition hardware in the VideoCore completely, and gives you a much higher system load. The only way you can do anything similar with X is to not use compositing, because only then does the server know what it should actually be displaying, and where. Except then you get jitter, you get flicker, and we've stepped back 15 years in the evolution of desktop graphics.

              The Weston backend hands the display hardware a list of every single visible surface, their stacking order, which transformation(s) should be applied, their position, and so on, and then the VideoCore displays it all with zero software intervention.

              This isn't RPi-specific, it's really common on ARM platforms, especially ones targeted towards set-top boxes, in-vehicle, etc.

              Comment


              • #17
                Originally posted by daniels View Post
                Which, right now, isn't possible for them to do because of the userspace code required to interface with the VideoCore. So it can't provide KMS.


                Entirely due to limitations in X's architecture.
                Heeey look who's back, hey Daniel.

                Quick wayland-related question. How's touchpad acceleration going? Or is still on the "TODO" List? I know you had a lot on your plate so no biggie, just curious.
                All opinions are my own not those of my employer if you know who they are.

                Comment


                • #18
                  Originally posted by Ericg View Post
                  Heeey look who's back, hey Daniel.

                  Quick wayland-related question. How's touchpad acceleration going? Or is still on the "TODO" List? I know you had a lot on your plate so no biggie, just curious.
                  Hi there! Still on the TODO list, I'm afraid.

                  I just wrote a blog post about the RPi stuff with a little more detail though, so I hope that makes up for it. http://fooishbar.org/tell-me-about/w...-raspberry-pi/

                  Comment


                  • #19
                    Originally posted by daniels View Post
                    Hi there! Still on the TODO list, I'm afraid.

                    I just wrote a blog post about the RPi stuff with a little more detail though, so I hope that makes up for it. http://fooishbar.org/tell-me-about/w...-raspberry-pi/
                    Actually a very interesting read, so thanks for the heads-up. I didn't even realize you had your own blog though looking at it, it seems pretty new haha.

                    Once the touchpad work goes (Sorry, laptop user :P So I care about it haha) is that Weston work or libwayland work? Meaning: will Kwin have to copy-paste / re-implement your work or will it be automatically available to them as long as they are using version x.y.z of libwayland?
                    All opinions are my own not those of my employer if you know who they are.

                    Comment


                    • #20
                      Originally posted by Ericg View Post
                      Actually a very interesting read, so thanks for the heads-up. I didn't even realize you had your own blog though looking at it, it seems pretty new haha.
                      Yep, my blog was dead for a good couple of years, only just resurrected it.

                      Originally posted by Ericg View Post
                      Once the touchpad work goes (Sorry, laptop user :P So I care about it haha) is that Weston work or libwayland work? Meaning: will Kwin have to copy-paste / re-implement your work or will it be automatically available to them as long as they are using version x.y.z of libwayland?
                      The plan is to make it common for all environments - Weston, Shell, etc - but that's much easier said than done. It's pretty tricky, and just expressing the level of functionality people expect from touchpads is difficult. But I've high hopes of it happening in a reusable library fairly soon.

                      And, no problem. I live on a laptop, with a touchpad and tap-to-click. Infuriating when it doesn't work, or is crap!

                      Comment

                      Working...
                      X