Thread Tools
Posts: 545 | Thanked: 2,804 times | Joined on Oct 2009
This post is doing to be a data dump of all my findings/research/etc on the N900 PowerVR graphics drivers and stack. I wont be talking about anything happening in the kernel (since I am not a kernel guy) or about the x11 stuff and omapfb things (since I dont understand those)

The following components are involved in the GPU drivers on the N900: (provides the egl functions and is a wrapper around (provides the gles functions) (compiler for GLSL) (actual egl implementation) (OpenVG implementation) (OpenVG VGU implementation) (PowerVR 2D APIs) (provides glue linking the PowerVR drivers and EGL to X/DRI/DRM) (related to performance counters and things) (lower level library that talks to the kernel)
pvrsrvinit (initializes the hardware) (xorg ddx driver)

The GPU drivers on the N900 have clearly been customized by Nokia as there is a custom EGL extention "EGL_NOKIA_texture_from_pixmap" which (as far as I can tell) is used in rendering the UI.

The file is open source (in the package xserver-xorg-video-fbdev) but the rest is closed source (in the package opengl-sgx-img) with a few OpenGL related dev headers released by Nokia.

Compiling the xserver-xorg-video-fbdev package requires a number of PowerVR header files which Nokia did not release as part of any development stuff (they would likely be in opengl-sgx-img somewhere if they were released but they aren't).

Using header files from (which originally came from Meego-on-N900 IIRC) and along with the debug information in the xserver-xorg-video-fbdev-dbg package, I was able to produce a set of header files that will allow you to compile xserver-xorg-video-fbdev and get a binary that is identical to the stock binary other than the timestamp (obviously that assumes you have identical compilers and libs and things to what Nokia used and what I have in my Maemo dev VM).

This repository
contains the unmodified source code from the Nokia xserver-xorg-video-fbdev package along with the aforementioned PowerVR header files and will allow it to be recompiled and changed any way we want. I have attached my compiled binaries built from this repository for the benefit of people who want to test this out and play with it. Do NOT install these unless you know what you are doing and do NOT install these on a phone you can't afford to live without (those with spare phones for development purposes where they can afford to reflash the things if they break are encouraged to play with these

There are 2 pieces of code that talk to the kernel and its drivers. talks to the omapfb driver and talks to the powervr driver.

There are also 2 pieces of code that talk to the X system (X/dri/drm/etc). One is and the other is

If we want to become independent from the specific X version we are currently using, we need to clone and we need to port both and to the new X/dri/drm/etc version.

To move to a newer kernel (assuming the omapfb and framebuffer stuff hasn't changed) we just need to port the PowerVR driver to the new kernel (I believe its been done at least once so its definitely possible)

If we wanted to move away from omapfb completely and move to omapdrm or something else, we would need to port to the new interface (and possibly change as well). There does not appear to be anything in the other PowerVR blobs that in any way ties it to the omapfb/framebuffer stuff, to X/drm/dri (or any specific versions of those) or to any other library other than glibc.

There is a Wayland replacement for the DRI2 driver at that may be worth looking at and studying although it almost certainly wont work as-is on the PowerVR blobs we have (the PowerVR blobs the Mer people have are newer and have different API versions)

In any case if we clone then the only interfaces and libraries that the remaining closed source PowerVR binaries will be relying on is the PowerVR kernel driver interface and the glibc ABI and we will be free to switch (if someone puts in the porting work) to a new X/dri/drm version, to a new kernel version, to omapdrm instead of omapfb (or even to something entirely new like Wayland).

I make no claims that there aren't other parts of the system that are tied to specific kernel or X versions or to omapfb or whatever that would need to be ported (or cloned if they are closed source), I am just talking about the situation with regards to the PowerVR GPU.

In terms of cloning that blob, all of the interfaces it talks to in the other PowerVR blobs are documented in the PowerVR header files that were added to allow to compile. The wsegl.h file from the above QT link will also help (since it documents the interface that these wsegl blobs need to expose). I dont have the skills to clone that blob or do any kind of porting work on things (blob, xorg dds, whatever) so someone else will have to do that work if we want to move away from our ancient X version.

Please feel free to hit me up in here or on IRC with any questions about this stuff and I will do my best to answer them.

Oh and whatever you do, don't go looking for (or looking at) the leaked PowerVR source code that's out there. Firstly using it for anything is a bad idea (unless being sued by Imagination Technologies for copyright infringement is your idea of fun) and secondly, even if it wasn't for that, according to information I found online the leaked code is for omap4 and not for the omap3430 we have in the N900 (it seems like TI never published any public SDK for the omap3430 unfortunately which is why I had to use the Mer stuff, the QT stuff and the debug symbols to produce the needed headers to build

Last edited by jonwil; 2017-10-21 at 03:32.

The Following 13 Users Say Thank You to jonwil For This Useful Post:
Posts: 52 | Thanked: 597 times | Joined on Dec 2016
One thing to note is that, as far as I know, if we would switch to omapdrmfb, we should abandon the fbdev driver. Replacing it with xf86-video-modesetting or something similar (which is now part of X), if we then implement the right dri/drm API calls from the closed blob you mention, we should get 3d for 'free' (not really for free at all, just that we'd be using the api that others also use for 3d on modesetting -- radeon and nouveau I think).

The Following User Says Thank You to Wizzup_ For This Useful Post:

Thread Tools

Forum Jump

All times are GMT. The time now is 06:10.