On Tue, 2009-10-06 at 10:51 +0200, David Jander wrote: > Hi all, > > My excuses if this question may seem slightly off-topic (I hope it is > not). In the light of the painful state of hardware acceleration support > for embedded devices using X, I have been wondering about the following > possibilities, and want to know if someone else has thought of, or tried > something like this before: > > I have: > An embedded (linux-) system with a display interface (linux > framebuffer), running kdrive Xserver (Xfbdev) and a MBX 3-D core with > binary OpenGL-ES 1.1 and EGL libraries.
First, obviously, you are in a world of hurt for running a driver you can't modify. I gently suggest that such hardware _not_ be improved in the open code as punishment, so that market forces drive people to hardware with a sensible driver story. That said... > I want: > To be able to develop an X-application that gets OpenGL (-ES) graphics > rendered into an X-window (local rendering only). > > The problem: > The OpenGL-ES/EGL libraries that are delivered with the hardware, do not > support any other than full-screen rendering (EGL is restricted to the > NULL-window) or rendering to off-screen buffers (pbuffer support). I think you want: > 3. Since the applications will run locally anyway, implement some hack > in the X-server, like shadow-buffers, to update screen contents > efficiently from EGL-pbuffer surfaces. You'd want to backend the X server's GLX provider onto your GLES stack, which is more or less straightforward, and then just run all GLX apps indirect. GLX pixmap support would be fairly easy, just don't advertise any GLX visuals and only-pixmap-enabled fbconfigs, and either point the pixmap's storage to the GLES stack's storage (if it lets you get a pointer to it) or copy the bits back and forth (if it doesn't). GLX window support would be similarly easy, just allocate the back buffer as an EGL pbuffer and copy out of it on SwapBuffers, and hope no one's stupid enough to try GL_FRONT rendering. - ajax
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
