Page 3 of 6 FirstFirst 12345 ... LastLast
Results 21 to 30 of 51

Thread: Raspberry Pi Is Running Well On Wayland/Weston

  1. #21
    Join Date
    Jul 2012
    Location
    Czech Republic
    Posts
    166

    Default It's not about power...

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

  2. #22
    Join Date
    Feb 2013
    Posts
    9

    Default

    Quote 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.

  3. #23
    Join Date
    Sep 2012
    Posts
    650

    Default

    Quote 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).

  4. #24
    Join Date
    Mar 2013
    Posts
    162

    Default

    Quote 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

  5. #25
    Join Date
    Jul 2012
    Posts
    708

    Default

    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.

  6. #26
    Join Date
    Jan 2013
    Posts
    1,446

    Default

    Quote 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".

  7. #27
    Join Date
    Sep 2010
    Posts
    453

    Default

    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.

  8. #28
    Join Date
    Feb 2009
    Posts
    113

    Default

    Quote 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.

  9. #29
    Join Date
    Mar 2013
    Posts
    162

    Default

    Quote 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?

  10. #30
    Join Date
    Oct 2008
    Posts
    3,038

    Default

    Quote 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 at 02:27 PM.

Posting Permissions

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