View Single Post
Posts: 194 | Thanked: 1,167 times | Joined on May 2016
#175
Originally Posted by Android_808 View Post
Been playing around with some ideas lately, hence no update.

I'm currently working on an idea for a replacement of HildonWindowStack and HildonStackedWindow in a stock build of GTK3, making the functionality free from requiring matchbox/hildon-desktop.
Is this to get Hildon apps running in other environments?

Not sure if this is the right topic to post this, but I wanted to sum up some ideas and experiments I had on running Fremantle UI on relatively modern phones

I used Arch Linux ARM rootfs with custom PKGBUILDs for packages in fremantle-gtk2 repo (I will upload them after some cleaning up if anyone is interested) in chroot under SailfishOS. Arch Linux in part because it was easy to setup and I’m more familiar with its packaging compared to Debian/Devuan, but it shouldn’t be a problem to do the same once Maemo packages for Devuan are built.

Testing under SailfishOS allowed to skip initial boot issues, such as properly starting Android bits, but this isn’t required of course. There is Halium project effort by Plasma Mobile and UBPorts devs which can be useful to built proper distro when needed.

Android uses different graphics stack compared to normal Linux: SurfaceFlinger acts as display server/compositor and talks to Hardware Composer (HWC) API, while gralloc is used for memory buffer allocations. libhybris has the code to provide Wayland integration to Wayland compositor (which then speaks to HWC instead of SurfaceFlinger) and Wayland EGL clients.

hildon-desktop is Xorg compositor/window manager instead and uses clutter, which requires OpenGL (ES) acceleration. The problem is that there is no intergration provided for X server windowing platform in libhybris. There are some ways to workaround that.
  • Using native graphics drivers
    Qualcomm SoC devices: there is open-source driver for Adreno graphics found in Qualcomm SoCs - Freedreno. It should work just fine for Xorg OpenGL acceleration, but it requires either using fairly new mainline kernel (isn’t the case with Android devices) or backporting DRM subsystem to older one. It’s mostly used with Qualcomm development boards, such as DragonBoard. The only phone there were efforts to get it working with is Nexus 4, which is old by now.

    MediaTek SoC devices: most MediaTek SoCs come with Mali graphics, which provide Linux userspace binaries, but it seems they need to be built for each specific SoC and only silicon manufacturers have license to Mali DDK for that.

    There are also some SoCs with PowerVR graphics and lately they appeared in Chromebooks with mainline kernel support for DRM/modesetting, but this can’t be easily backported to phone SoCs either.
  • Adding X server platform integration to libhybris
    It should be doable to add X server integration as EGL windowing system in libhybris the way it was done for Wayland compositors/client, but I’m not familar enough with Xorg architecture to understand how to do it right. I tried doing it based on the idea/code for Raspberry Pi, which involves offscreen rendering and using XPutImage/XShmPutImage to output result. While don’t need to use glReadPixels(), since gralloc provides access to graphics memory buffer, it’s still slower than it needs to be and involves doing extra copies. My implementation in libhybris works as proof-of-concept, but seems to suffer from race conditions and surely can be improved.

    I wonder if there is an easy way to assotiate XPixmap with arbitrary value (gralloc buffer handle) and modify Xorg server to access pixmap data through it when available (via some kind of extension?). This way extra copies could be avoided.
  • Partially using Wayland
    Proper wayland integration would require moving to GTK+ 3 (GTK+ 2 apps don’t support Wayland, but can be launched via XWayland integration) and either rewrite of hildon-desktop to act as display server/Wayland compositor, or using different compositor/window manager, such as Mutter from GNOME Shell or KWin.

    Instead I tried to make a hack of xlib Cogl windowing system integration to make it connect both to X server and Wayland compositor. This way hildon-desktop can still act as X (Xwayland in this case) compositor, but OpenGL will render to Wayland compositor and be overlayed on top of Xwayland output (I modified QtWayland example to act as such compositor).

    It works fastest on devices I could test (Xiaomi Redmi Note 2, OnePlus 2, Moto Z Play), but is pretty quirky to say the least. Screen capture by X server apps won’t work, unless it’s mixed with previous approach, and I’m not sure what to do with other X server clients using OpenGL, unless they also run fullscreen.

I tried to cover only graphics for now. Other subsystems adaptations could be probably reused from SailfishOS/UBPorts, since they bind Android drivers to pretty standard Linux components (for example ofono/telepathy-ring for telephony, PulseAudio, gstreamer for hardware decoding/camera access).
 

The Following 11 Users Say Thank You to TheKit For This Useful Post: