Kernel, HAL, Services, IPC and APIs

Hardware Librem 5
1

Hello,
I was wondering with the Librem 5 if there is going to be some unification/layering of the underlying architecture for accessing sensors, camera, GPS, etc…

On Android, there is a clear HAL (especially since project Treble). Then Android services use this HAL to talk to the Kernel / drivers. Then the application framework talk to those services through Binder’s IPC. At last user applications are built using the application framework.

https://source.android.com/devices/architecture

I was wondering if there will be an effort for a similar standardization of layers among KDE Mobile, Gnome and other Distros ?

If we compare layer per layer :

From what I understand the librem will use an upstream kernel. But does the Linux kernel standardizes the way to access everything a phone needs ? (Fingerprint, GPS, vibration, LED, Camera, Accelerometer, Telephony, etc… ). Isn’t there here a need for some standardized HAL like on Android ? Also couldn’t the Librem 5 align with Android HAL ? This way KDE-Mobile, UbPorts, etc… could target this and then run both on Librem 5 and other Android Phones.

Then what would be the equivalent of Android services ? From what I understand there is for eg oFono and ModemManager that talk over DBus.
Are other services going to be all using DBus ? Is there any consensus among distro to all use DBus ? Is DBus going to become the equivalent of Android’s Binder ? Or is it going to be a big mess with a mix of shared library, IPC over DBus , IPC over sockets, etc… that each will depend on the distro.

I would love to develop for a Linux Phone but I need a unified API. I’m not going to develop one app for Gnome, another for KDE, etc… So it would be really nice if all (main) distros could at least agree on one IPC system and on the services/API it offers.

Is there any chance something along those lines happens ?

1 Like
2

Pretty much yeah, there might be some exceptions but in most cases things patches are not accepted upstream unless they are making an abstract and extendable API to userspace. Lots of drivers in android are not upstream and components such as cameras etc have their own implementations rather than using V4L2 AFAIK.

DBus is pretty much a standard nowadays for most high-level applications (both on Qt and GTK desktops).

DBus is pretty much standard for all desktops, the larger issue here is that your app won’t feel “native” on both Qt and GTK desktops because you can only choose one.

1 Like
3

Okay I see, thanks for your answer !
Indeed Qt vs GTK will introduce a lot variability in term of UI. But maybe if we agree on what defines a theme and on the exact size of a header bar, menu, etc… then both QT and GTK could try to follow it (like for e.g Flutter apps are not native Android widgets but still feel native because they implement material design).
But anyway good to hear that at least in terms of service API we have some common IPC where most of distro agree on

2 Likes