Replacing X With Wayland On The Raspberry Pi

[GreatEmerald]

The question was meant for the average user. People who actually know a thing or 2 about developing video drivers would obviously care and have a reason to create open source drivers. But the average user would have no interest or ability to mess with an open source driver, so it boggles my mind why the average user would care what kind of driver they're using as long as it is free and functional.

Well, you replied to someone saying that they don't want to buy such a device due to it not having OSS drivers. It was not talk about the hypothetical average user.

[Imroy]

1. Open sourcing the drivers is beyond the RPi team's power.

Actually, they did release the driver source. The problem is that it's just a shim, sending commands to the "VideoCore IV" GPU/VPU. The "driver" is really the firmware that runs on VideoCore and, as you said, Broadcom is not going to release that.

Raspberry Pi GPU Driver Turns Out To Be Crap

[Delgarde]

The question was meant for the average user.

What kind of "average user" are you envisioning, given that the Pi is basically a geek toy - not a device for the computer-using masses?

[Thaodan]

---

You're wrong: it was about server side management(allocation) of buffers.

This is no reason, since the wayland protocoll spec isn't against it.

[curaga]

What I find most interesting about this.. is the ABILITY to have hardware specific backends. X is a one size fits all approach, and if it doesnt fit you...youre screwed. With the ability to switch out the backend so easily, it really helps to future-proof Wayland because if we realize we screwed up NOW we can just change the backend in the future.

Um, switching a wayland backend is similar to switching the X driver. Can't run X on a native driver? Make it run on the native framebuffer, as is done on n900 for example. No native FB either? X doesn't care how the driver interfaces the hw.

[smitty3268]

Um, switching a wayland backend is similar to switching the X driver. Can't run X on a native driver? Make it run on the native framebuffer, as is done on n900 for example. No native FB either? X doesn't care how the driver interfaces the hw.

Except in this case, the native driver interface needs more information than X provides. So you'd have to do a pretty extensive rework of the X internals to track it all in order to pass on that info to the driver. Wayland already does all that natively.

[oleid]

---

This is no reason, since the wayland protocoll spec isn't against it.

Sure! That's why I wrote "one of the *alleged* reasons for Mir." That's what makes this news about Wayland for Pi quite funny.

[Ericg]

Um, switching a wayland backend is similar to switching the X driver. Can't run X on a native driver? Make it run on the native framebuffer, as is done on n900 for example. No native FB either? X doesn't care how the driver interfaces the hw.

See smitty's comment below yours; I should've clarified by my point: We can do it, and its apparently relatively easy. Thats a big boon to the community.

[oleid]

What I find most interesting about this.. is the ABILITY to have hardware specific backends. X is a one size fits all approach, and if it doesnt fit you...youre screwed. With the ability to switch out the backend so easily, it really helps to future-proof Wayland because if we realize we screwed up NOW we can just change the backend in the future.

Maybe 10 years ago, back wenn XFree had no module loader, we had an X server for every graphic hardware. And even today, we have different X servers: normal X, kdrive, ...

[renox]

A "specific backend" which would be unfeasible to implement for X.

Yes, I know, that is why I wrote "so Wayland allow great local performance"