Announcement

Collapse
No announcement yet.

Raspberry Pi Is Running Well On Wayland/Weston

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

  • #16
    Originally posted by uid313 View Post
    Raspberry Pi is old legacy ARMv6.

    I would love to see a single-board computer with ARMv8 and 64-bit.
    Once such chips are available, I'm sure you will see it.
    For now, IFC6410, quad krait.

    This rpi stuff is boring as hell. Cheap sure, but in this case, you really do only get what you pay for, which was obsolete even before they came up with the idea. It would be far more interesting if they actually updated the hardware to keep at least consistently far behind the "current standards".

    If your objective is running a graphical desktop, rpi is useless. About its only use is in automation/remote control.

    Comment


    • #17
      Originally posted by TheOne View Post
      That may mean that wayland isn't versatile enough to be supported from driver space.
      No it doesn't? I mean I guess it could be possible to write kernel wrappers around these platform specific interfaces but that has nothing to do with Wayland itself. The thing is that if you want to take use of hardware specific functionality, you need to support hardware specific functionality. That's true for every display server, compositor and graphics framework.

      Originally posted by TheOne View Post
      Imagine every hardware manufacturer doing custom changes to wayland/weston in order to support their specific graphic chips capabilities.
      The idea is that drivers expose KMS/EGL interfaces that Wayland uses but if there's some hardware specific features that would be benefitical for a compositor then it probably should be added, then again that's true for every display server and compositor. NVIDIA will likely never support the Linux KMS interface so similar functionality has to be exposed to Wayland compositors in some otherway hence a NVIDIA backend. I don't think there's anyway to escape that.

      Comment


      • #18
        Originally posted by TheOne View Post
        That may mean that wayland isn't versatile enough to be supported from driver space.

        Nope, Wayland is, however, Weston isn't. Weston needs KMS, DRM and such. The rpi driver doesn't provide that stuff. Therefore they added another backend to Weston.

        Comment


        • #19
          How are the Odroids doing in the graphics field?

          Comment


          • #20
            Originally posted by TheOne View Post
            That may mean that wayland isn't versatile enough to be supported from driver space.

            Imagine every hardware manufacturer doing custom changes to wayland/weston in order to support their specific graphic chips capabilities.
            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.

            Comment


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