> Screen surfaces are by definition scan-out buffers of the adapters. In > theory, the extension is used by opengl applications in an environment > without display server, or used by the display server itself. And the > extension cannot be supported by any X11 driver. > > The main reason, at least for me, to "emulate" it under X11 is that > about half of the demos require the extension to run. It might scare > away those who are new to EGL when half of the demos fail to run under > X11. But to emulate it, I would like it to be as simple as possible.
Another big advantage is that it is the only way to write EGL programs without window system specific code. Maybe an EGL_MESA_input could be added to abstract input in the same way, but this is more tricky. I'm not sure if it can be made simpler. Presenting a maximized window seems to me much more user friendly that a randomly sized one, especially considering that the application may not have code to handle resizing of the window, so I wouldn't cut that out You could cut out the xrandr modesetting, but that would prevent using the extension to actually set a screen mode as it would happen on a console implementation. Outside of eglx11.c, the changes are minimal. egl_glx support is required for acceleration. egl_xlib support may be removed, but it is cheap to have. > What do you think if the changes are made minimal and are made to a > single driver? I think eglx11.[ch] may be simplified for less > flexibility and functionality, but still enough to support the demos. > Also, I would like to move it to either egl_softpipe or egl_glx. I > prefer egl_softpipe because it supports APIs other than OpenGL (which is > why it is default). But if you would like to have acceleration, egl_glx > is fine too. For the purpose of making demos just work, egl_glx seems superior, as it would be surprising for the user to have their demos possibly taking several seconds per frame with egl_softpipe. That allows to have EGL demos be as good as the GLX ones, and actually better since they would automatically present sensibly sized (i.e. maximized) windows and support fullscreen. > There are 3 EGL drivers for X11 right now. Longer term, I would like to > have a single driver that supports multiple APIs and acceleration. The > driver should talk DRI2 (the protocol) and probably minimal GLX to the X > server. Yes, that probably should be done. Ideally the following should probably happen: 1. Make all the various components shared libraries (with git version or whatever in the filename to allow ABI breaking): Mesa, the Mesa state tracker, and the Gallium state trackers and drivers 2. Make libGL.so GLX a driver loader 3. Make a GLX indirect driver from src/glx/x11 4. Make a DRI GLX driver from src/glx/x11 and mesa/drivers/dri/common. Remove 5. Make a Gallium software GLX driver from src/gallium/winsys/xlib 6. Remove egl_xlib in favor of egl_glx over the Gallium software GLX driver. This way X11 support is only done through GLX. 7. Remove the non-Gallium fakeglx stuff in src/mesa/drivers/x11 in favour of src/gallium/state_trackers/glx/xlib 8. Remove egl_dri and egl_xdri 9. Change src/gallium/state_trackers/egl to be an independent EGL driver loading the shared librariy Gallium drivers 10. Possibly remove swrast and all the Mesa drivers except state_tracker This way we would have the Gallium EGL driver for console EGL and egl_glx for X11. Non-Gallium DRI EGL support probably doesn't matter since it will hopefully go away relatively soon and there is no real installed base. ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
