Announcement

Collapse
No announcement yet.

Raspberry Pi Is Running Well On Wayland/Weston

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

  • #21
    It's not about power...

    Many people seems to forget what RPi is all about...

    Comment


    • #22
      Originally posted by papper View Post
      Why does the RPI needs its own backend? I thought wayland/weston was supposed to be rather hardware agnostic as long as there was support in the graphics driver.

      Please enlighten me!
      The released raspberry's graphics driver is an open source RPC interface to a proprietary firmware and shares none of the FOSS graphics driver infrastructure (drm mesa ...). Therefore a new backend is necessary.

      I'd say if Nvidia is to support wayland, this probably would be how it is done --- release an interface to its proprietary blob and (either nvidia or the wayland developers will) write a weston backend for it.

      Comment


      • #23
        Originally posted by papper View Post
        Why does the RPI needs its own backend? I thought wayland/weston was supposed to be rather hardware agnostic as long as there was support in the graphics driver.

        Please enlighten me!
        The RPI has a CPU and a GPU, but also a hardware compositor, so writing a dedicated backend improves performance a lot (see links posted above, as well as this one).

        Comment


        • #24
          Originally posted by dee. View Post
          Wayland is versatile because it is backend-agnostic. You can use whatever backend you want for Wayland and Wayland itself will work the same, it's the backend that needs to be different for different hardware and different situations.

          Like, you can have a backend for gpu egl drivers, you can have another backend for software rendering, another backend for some other type of drivers (android drivers maybe)... that's versatile.
          Well imagine a different backend for every piece of SOC out there, that would suck, im not sure how they implemented the backend stuff on wayland, if it is loaded dynamically at runtime using dl() functions or you have to compile it statically as part of wayland in order to run on the desired system.

          I liked the idea nvidia was working on, of having a standard libopengl stub that would make calls to the real implementation supplied by a driver, thats more flexible in my opinion.

          But still im not sure how backend implementations work statically or dynamically. If dynamically there shouldn't be any concerns

          Comment


          • #25
            Funny how people still think that 2 Ghz Quad-Core ARMs are fast. Even 64-Bit ARMs won't be fast. The fastest ARMs get owned by a Pentium III 700 Mhz. I'm not joking.

            Wayland compositors depend on KMS specifically. Just Weston happens to do that.

            Comment


            • #26
              Originally posted by TheOne View Post
              Well imagine a different backend for every piece of SOC out there, that would suck, im not sure how they implemented the backend stuff on wayland, if it is loaded dynamically at runtime using dl() functions or you have to compile it statically as part of wayland in order to run on the desired system.
              Well that all depends on drivers. If you have 10 SoC's and they all have EGL drivers for their GPUs, then they can all be utilized with the EGL backend. Now enter another SoC which only has Android drivers available. Then, libhybris + another Wayland backend needs to be used to access the GPU.

              Mostly it's about the GPU, but if there's other hardware that needs to be supported, then that affects the issue as well.

              I liked the idea nvidia was working on, of having a standard libopengl stub that would make calls to the real implementation supplied by a driver, thats more flexible in my opinion.

              But still im not sure how backend implementations work statically or dynamically. If dynamically there shouldn't be any concerns
              Not familiar with that, but we don't exactly associate Nvidia with "openness".

              Comment


              • #27
                Originally Posted by TheOne View Post
                Well imagine a different backend for every piece of SOC out there, that would suck, im not sure how they implemented the backend stuff on wayland, if it is loaded dynamically at runtime using dl() functions or you have to compile it statically as part of wayland in order to run on the desired system.
                It's called a driver.

                Comment


                • #28
                  Originally posted by blackout23 View Post
                  Funny how people still think that 2 Ghz Quad-Core ARMs are fast. Even 64-Bit ARMs won't be fast. The fastest ARMs get owned by a Pentium III 700 Mhz. I'm not joking.
                  You are joking.
                  It's not that bad. http://www.notebookcheck.net/SoC-Sho...M.99496.0.html
                  ARM SoCs are cheap, energy efficient and fast enough.

                  Comment


                  • #29
                    Originally posted by plonoma View Post
                    It's called a driver.
                    You seem to be a pretty wise person, can you explain to me the difference between backend and driver on the current scenario being discussed?

                    Comment


                    • #30
                      Originally posted by TheOne View Post
                      You seem to be a pretty wise person, can you explain to me the difference between backend and driver on the current scenario being discussed?
                      The Pi driver doesn't support KMS, so instead of modifying it they instead modified the Wayland backend to hook into the existing driver.

                      You could modify either one to get things working.

                      In this case, they decided to go ahead and do the backend so they could expose more hardware specific capabilities directly into Wayland, to increase performance. That was a specific choice they made, and one that a lot of embedded manufacturers are likely to agree with. Such things are rather common in that space - you can't even run the same ARM linux kernel on multiple devices until very recently, because everything is very SOC-specific.

                      If anything has a Mesa driver, though, it likely won't need any extra work because it will probably already have KMS and other necessary driver features. That's the more generic way of getting things to work.
                      Last edited by smitty3268; 09-18-2013, 02:27 PM.

                      Comment

                      Working...
                      X