[Atrix 4G Q&A, Help & Troubleshooting] AmeiseMike:
I've never seen an application that required 'certain system calls'. Your driver is compiled for the kernel its on, and in Linux' case, for the specific version due to the volatile ABI. Calling the graphics driver does not require systems calls; it requires IPC which is already supported. The driver itself certainly will use syscalls, but it can already do that (as it was built for the kernel it runs on). All you need is potentially specific features to be exposed by the driver, which from what I've read regarding framebuffers can be implemented as an intermediate layer as I've described below.

Activity -> Library (GLES) -> Driver Interface -> PLATFORM|KERNEL -> Driver -> syscalls/black box

"(possibly due to a newer 3D/OpenGL library)"

OpenGL ES 2 is OpenGL ES 2. All the calls should still work via the GLES2 interface library.

"Here's the thing - on GB each app that needs HWA has its own copy of the framebuffer/video memory/whatever, which was fine because only a relatively small percentage actually used HWA. On ICS/JB however, the whole entire thing is hardware-accelerated. Each single app having its own copy (plus of course the system having its own copy) means we'd be lucky to be able to run a couple of apps before running out of memory. ICS/JB framework redid this approach by having a shared framebuffer (or something like that), but that requires proper support in the kernel..."

Most non-mobile systems take neither of those approaches - each application that requests a framebuffer gets a framebuffer, and they all share general GPU memory (though they cannot necessarily share objects unless list space is being shared, which is rare). On the Atrix, a framebuffer would require either 2MiB or 1MiB of shared RAM (this depends on whether it stores data internally in SRGB or in 565 format, I suspect it's the former). This is only for applications that actually request a framebuffer, of course. On my Honeycomb implementation, I implemented what I described below, which took a few days. I'd point out, however, that even on the older platforms that used software rasterization, they still required a framebuffer, it just wasn't a hardware framebuffer, but since the platform uses shared memory, you're using 2MiB of memory one way or the other. I suspect that the rasterizer uses a similar technique to what I've described below.

Now, if this is actually a concern, I see no reason you couldn't write a simple wrapper between GLES 2 and your application layer that emulates the shared approach while still being accelerated. Presuming that only one application is actively using the framebuffer at a time, you can do this without requiring driver support, though it requires knowledge of OpenGL (which I have). As I said, I was able to get Honeycomb (which is actually where the new framebuffer approach was implemented, I'm aware of it) to work on a far older device with the original drivers. One of the nice things of current mobile GPUs (including the Tegra 2) is that there are ways to force list-space awareness. My solution (though I'd like to find a better one) was to make a single global context (to force list space to be global) and pass the context to the activity threads. No two activities should ever be drawing simultaneously, so it's not a problem. If they are, simple locks can be implemented (though it'd slow it down a bit). This isn't an ideal solution, though, but it will work. Some system-controlled buffer clears and you have what will appear to an application to be a dedicated framebuffer that isn't.