If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Comment

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

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

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

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.

Comment

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.