Hi, I'm a developer working on getting OpenGL ES working with QWS - the window system built into Qt/Embedded. That is, Trolltech's own windowing system, completely independent of X. The typical hardware we're working with is PowerVR MBX, an OpenGL ES 1.1 complient device. We have also played with ATI mobile chipsets. One thing all these devices have in common is rubbish (IMO), closed source drivers. The only API we have for them is EGL, the only on-screen surface is the entire display.
While we are continuing development with these devices, I'm very keen to develop a proof-of-concept driver using an open source desktop OpenGL implementation. I want to show people what can be done with decent (& open) drivers. I'm pretty new to X, DRI & associated code bases but have spent the last few months reading documentation & code, trying to understand how everything works together. I think I've now got to a stage where I've read everything I could find and need some help. The effect I'm looking for is iPhone/Compiz style window composition. We have this already, but the problem is that the drivers are designed for a single process accessing the hardware at a time. This is fine if there's only a single process (in QWS, the window system is a shared library which is loaded by the first application to be launched). All the windows can be drawn into off-screen pbuffers and then used as textures to be rendered onto the screen. The problem comes when there are multiple processes. Our current solution is to get the client processes to use our raster paint engine to render into shared memory, which the server then uploads as a texture. As you can imagine, this is *SLOW*. It also doesn't allow client processes to use OpenGL themselves - something we really want to have. What we want to do is use our OpenGL paint engine (or, even better, an OpenVG paint engine - which maps much better to Qt's painter API) in the client processes. The client processes render both 2D windows and OpenGL calls to off-screen buffers, which the server can use as textures. We'd also like video to be handled in a similar way (VAAPI?). >From what I've read, AIGLX allows compiz to composite OpenGL window surfaces because it's the X server which does the rendering. I.e. X clients serialize OpenGL commands and send them to the server via GLX. While we could do this too, (and will probably have to do this for nasty closed source OpenGL ES drivers), I stumbled upon this: http://hoegsberg.blogspot.com/2007/08/redirected-direct-rendering.html What I'm hoping to do is bring together all the very fine work done in the last few years. What I'm stuck on is how everything is going to hang together. This is what I have so far (most of which is probably wrong, so please correct): Write a QWS driver where the server opens the framebuffer using DRM Modesetting. The server also initializes the DRM. QWS clients render into off-screen buffers (pbuffers or Framebuffer objects?) using OpenGL (Mesa/Gallium?). The QWS client then magicaly gets the DRM ID of the off-screen buffer (Is there a 1:1 relationship between a DRM buffer and a framebuffer object's color buffer?). The clients then send that DRM ID to the server. The server then somehow magically tells mesa/gallium about the buffer which is then (also magically) mapped to a texture name/ID and used as a texture to be drawn into the framebuffer. Obviously, I still have a lot to learn. :-D The first step I'd like to make is to just get something on the screen. I was wondering if it's possible to use DRM to just map the framebuffer into a user process's address space and use it like we would use the LinuxFB device? Or do modern frame buffer drivers use the DRM themselves to do this? Any/all comments, suggestions & insults are welcome. :-) Cheers, Tom ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
