Wayland as a X replacement... in the future :)


McLovin

Member
Joined
Aug 28, 2010
Messages
278
Location
Germany
Would a switch to wayland be feasible? Do we have the needed KMS-support? Might add some performance :)
 
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.
 
Last edited by a moderator:
yeah, either the programs use wayland directly or a x-server connects them. OpenGL-ES sounds great, but the kernel (and the graphics-driver) need KMS to support it.
 
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.
 
Last edited by a moderator:
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:
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.
 
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.
 
Back
Top