Graphic Stack - Revision history

Beroset: add category

2023-06-17T22:11:42Z

add category

← Older revision		Revision as of 22:11, 17 June 2023
Line 1:		Line 1:
			[[Category:Porters]]
	The AsteroidOS’s graphic stack is pretty similar to the one present in SailfishOS or WebOS-Ports. This page is a quick summary of what’s involved in showing an app.		The AsteroidOS’s graphic stack is pretty similar to the one present in SailfishOS or WebOS-Ports. This page is a quick summary of what’s involved in showing an app.

Beroset: added diagram

2023-06-17T16:41:12Z

added diagram

← Older revision		Revision as of 16:41, 17 June 2023
Line 8:		Line 8:

	Libhybris is used to re-use Android drivers from AsteroidOS, SailfishOS, NemoMobile, WebOS-Ports or Ubuntu Touch. It’s clearly a hack and not a perfect solution as it relies on some proprietary binary blobs but it’s often the only way to get reliable hardware acceleration on Android devices and it works really well. It’s worth noticing that Ubuntu Touch uses Mir instead of Wayland which is used by all the other projects, including AsteroidOS.		Libhybris is used to re-use Android drivers from AsteroidOS, SailfishOS, NemoMobile, WebOS-Ports or Ubuntu Touch. It’s clearly a hack and not a perfect solution as it relies on some proprietary binary blobs but it’s often the only way to get reliable hardware acceleration on Android devices and it works really well. It’s worth noticing that Ubuntu Touch uses Mir instead of Wayland which is used by all the other projects, including AsteroidOS.
			[[File:Graphic-stack.jpg\|center\|frameless]]
	~~<img src="{{assets}}/img/graphic~~-stack.jpg~~" style="width:100%"/>~~

Beroset at 16:37, 17 June 2023

2023-06-17T16:37:23Z

← Older revision		Revision as of 16:37, 17 June 2023
Line 3:		Line 3:
	User apps, like asteroid-settings, are small software developed using QML and qml-asteroid. Behind the hood, Qt5 uses the QtWayland “QPA” module API for client windows to show up on screen. A communication is established via the “wayland-egl” protocol with the Wayland compositor. This means that user apps don’t necessarily have to be developed with Qt as long as the library supports the Wayland protocol.		User apps, like asteroid-settings, are small software developed using QML and qml-asteroid. Behind the hood, Qt5 uses the QtWayland “QPA” module API for client windows to show up on screen. A communication is established via the “wayland-egl” protocol with the Wayland compositor. This means that user apps don’t necessarily have to be developed with Qt as long as the library supports the Wayland protocol.

	The Wayland compositor which by default is asteroid-launcher (and could be replaced by GlacierUI for example) is based on Lipstick from the Nemomobile project which allows us to quickly design an interface with QML and qml-asteroid. Behind the hood, two different modules are used: once again QtWayland but this time the compositor API is used which allows us to handle the wayland-egl communication with the client. The QPA module used by asteroid-launcher is qt5-qpa-hwcomposer which uses the <code>libhardware.so</code> glibc binding provided by libhybris in <code>/usr/lib</code.		The Wayland compositor which by default is asteroid-launcher (and could be replaced by GlacierUI for example) is based on Lipstick from the Nemomobile project which allows us to quickly design an interface with QML and qml-asteroid. Behind the hood, two different modules are used: once again QtWayland but this time the compositor API is used which allows us to handle the wayland-egl communication with the client. The QPA module used by asteroid-launcher is qt5-qpa-hwcomposer which uses the <code>libhardware.so</code> glibc binding provided by libhybris in <code>/usr/lib</code>.

	This <code>libhardware.so</code> is only a front-end to the android’s <code>libhardware.so</code> provided in <code>/system/lib/</code> and imported from an Android Wear installation. The Android’s <code>libhardware.so</code> can not be directly used by <code>qt5-qpa-hwcomposer</code> because there is a libc incompatibility; Android libraries are linked against bionic instead of glibc so a compatibility layer is needed: that’s the job of libhybris. Finally this bionic <code>libhardware.so</code> loads some proprietary binary blobs which are able to communicate with the GPU and to show something on-screen.		This <code>libhardware.so</code> is only a front-end to the android’s <code>libhardware.so</code> provided in <code>/system/lib/</code> and imported from an Android Wear installation. The Android’s <code>libhardware.so</code> can not be directly used by <code>qt5-qpa-hwcomposer</code> because there is a libc incompatibility; Android libraries are linked against bionic instead of glibc so a compatibility layer is needed: that’s the job of libhybris. Finally this bionic <code>libhardware.so</code> loads some proprietary binary blobs which are able to communicate with the GPU and to show something on-screen.

Beroset: initial version of graphics stack page

2023-06-17T16:36:47Z

initial version of graphics stack page

New page

The AsteroidOS’s graphic stack is pretty similar to the one present in SailfishOS or WebOS-Ports. This page is a quick summary of what’s involved in showing an app.

User apps, like asteroid-settings, are small software developed using QML and qml-asteroid. Behind the hood, Qt5 uses the QtWayland “QPA” module API for client windows to show up on screen. A communication is established via the “wayland-egl” protocol with the Wayland compositor. This means that user apps don’t necessarily have to be developed with Qt as long as the library supports the Wayland protocol.

The Wayland compositor which by default is asteroid-launcher (and could be replaced by GlacierUI for example) is based on Lipstick from the Nemomobile project which allows us to quickly design an interface with QML and qml-asteroid. Behind the hood, two different modules are used: once again QtWayland but this time the compositor API is used which allows us to handle the wayland-egl communication with the client. The QPA module used by asteroid-launcher is qt5-qpa-hwcomposer which uses the <code>libhardware.so</code> glibc binding provided by libhybris in <code>/usr/lib</code.

This <code>libhardware.so</code> is only a front-end to the android’s <code>libhardware.so</code> provided in <code>/system/lib/</code> and imported from an Android Wear installation. The Android’s <code>libhardware.so</code> can not be directly used by <code>qt5-qpa-hwcomposer</code> because there is a libc incompatibility; Android libraries are linked against bionic instead of glibc so a compatibility layer is needed: that’s the job of libhybris. Finally this bionic <code>libhardware.so</code> loads some proprietary binary blobs which are able to communicate with the GPU and to show something on-screen.

Libhybris is used to re-use Android drivers from AsteroidOS, SailfishOS, NemoMobile, WebOS-Ports or Ubuntu Touch. It’s clearly a hack and not a perfect solution as it relies on some proprietary binary blobs but it’s often the only way to get reliable hardware acceleration on Android devices and it works really well. It’s worth noticing that Ubuntu Touch uses Mir instead of Wayland which is used by all the other projects, including AsteroidOS.

<img src="{{assets}}/img/graphic-stack.jpg" style="width:100%"/>