From: Jerome G. <gl...@fr...> - 2008-01-19 00:10:46
|
Tom Cooksey wrote: >> The MESA_screen_surface spec hasn't been touched in a few years, but >> it's probably pretty close to being workable and implementable. Some >> code was written to support it but not finished, like the rest of Mesa's >> EGL code. I suspect we'll get back to it one of these days... >> > > The extension's great if all you want is have a single client access > the graphics hardware. It falls down if other processes want to use > the graphics hardware too. I.e. It's not possible to write a window > system using EGL (which is what I want to do :-)). What could make > this possible however is if other clients render into off-screen > buffers and the window system's process is then able to access those > off-screen buffers and draw them to the screen. I think I'm right in > saying there's 2 ways to render into an off-screen buffer for this > purpose: (1) a texture bindable pbuffer (the render_texture extension) > and (2) a framebuffer (the GL_EXT_framebuffer_object extension). > > I envisage a client obtaining a handle/id/address of an off-screen > buffer it's just rendered into and passing it to the server via some > form of IPC mechenism. The server then uses the handle/id/address and > draws the client's off-screen buffer onto the screen possibly using > some fancy animated transition. :-) > > Am I dreaming? Would it be easier/better to implement a new window > system using the gallium interface? What docs do people recommend I > read to understand this better? > > > Cheers, > > Tom > EGL & this mesa extension have been exactly though for that. You create your window manager which implement EGL base window system and your composite manager use the mesa extension to display on screen. Other scheme can fit. Cheers, Jerome Glisse |