Wayland as a X replacement... in the future :)
- Thread starter McLovin
- Start date
Pickle
Mega GP Mania
Would a switch to wayland be feasible? Do we have the needed KMS-support? Might add some performance
As I understand it wayland has many backends like sdl and egl and even within X itself. So in some form it should be runable.
Letalis Sonus
Advanced Member
- Joined
- Mar 5, 2009
- Messages
- 1,532
As far as I know it's like this:
Wayland is the lowest instance in its ecosystem, a Wayland program is actually running on a Wayland session running on a Wayland instance that is working as a graphical multiplexer. Even though a (root-less) X Server running as a Wayland client can use its own DDX drivers for running X programs while still having a Wayland instance beneath it - Wayland itself still needs drivers that explicitly support it.
It is not possible to run Wayland programs (or even Wayland itself) on X as well, they need to directly support X as a back-end - Qt and GTK can already switch between both back-ends at run time.
As Wayland tries to get rid of all X dependencies it does not use OpenGL at all, because that would require GLX and all its X dependencies - so it is already solely relying on OpenGL ES and EGL - which would fit perfectly in what we've got on the Pandora.
Wayland is the lowest instance in its ecosystem, a Wayland program is actually running on a Wayland session running on a Wayland instance that is working as a graphical multiplexer. Even though a (root-less) X Server running as a Wayland client can use its own DDX drivers for running X programs while still having a Wayland instance beneath it - Wayland itself still needs drivers that explicitly support it.
It is not possible to run Wayland programs (or even Wayland itself) on X as well, they need to directly support X as a back-end - Qt and GTK can already switch between both back-ends at run time.
As Wayland tries to get rid of all X dependencies it does not use OpenGL at all, because that would require GLX and all its X dependencies - so it is already solely relying on OpenGL ES and EGL - which would fit perfectly in what we've got on the Pandora.
Last edited by a moderator:
asimov-solensan
Very Active Member
- Joined
- Jan 8, 2010
- Messages
- 743
Correct me if I'm wrong. The gpu driver we are using now is closed and in order to run wayland we would need specific drvers for it.
The only option is ask the manufacturer to develop said driver.
The only option is ask the manufacturer to develop said driver.
Last edited by a moderator:
laurencevde
Member
The framebuffer and the 3d-renderer are separate pieces of hardware. TI has written an open-source KMS-driver for the framebuffer (and got it included in linux 3.3's staging-area, but without any support for using the SGX...), and the SGX-driver is a user-space library, that doesn't require X to be used, though it does need the framebuffer-driver to send it commands. With the KMS-driver, wayland should work, though it won't have 3D out-of-the-box, but that should be sorted out by the time Wayland becomes useful.
Last edited by a moderator:
Letalis Sonus
Advanced Member
- Joined
- Mar 5, 2009
- Messages
- 1,532
Those are still different drivers, I'm afraid. The GPU ain't from TI, their drivers are developed independently and won't work with Imageon's video drivers.
Stephane Hockenhull
Member
- Joined
- Sep 12, 2010
- Messages
- 282
no need for new SGX drivers.
what you need is replace the driver's EGL library from the application's point of view to hook into the SwapBuffer call to capture the finished frame instead of displaying it directly.
then composite and display the result.
no need to modify the lib, have a new lib with the new SwapBuffer call the unmodified closed-source one for the rest of the pixel render buffer setup, etc.
what you need is replace the driver's EGL library from the application's point of view to hook into the SwapBuffer call to capture the finished frame instead of displaying it directly.
then composite and display the result.
no need to modify the lib, have a new lib with the new SwapBuffer call the unmodified closed-source one for the rest of the pixel render buffer setup, etc.
