On 12 jan 2010, at 16.16, Chia-I Wu wrote: > On Tue, Jan 12, 2010 at 10:52 PM, Jakob Bornecrantz > <ja...@vmware.com> wrote: >> On 12 jan 2010, at 04.23, Chia-I Wu wrote: >>> * Write up documentation >>> * Remove unused/non-working EGL drivers >>> * Remove drivers that are deprecated by egl_g3d >>> * Automatic driver selection (like DRI) >>> * Re-organize EGL demos >>> >>> The drivers to be removed are >>> >>> * Unused >>> * src/egl/drivers/demo/ >>> * src/egl/drivers/xdri/ >> I think that at least demo should remain if for nothing more then >> to serve >> as a empty skeleton for anybody wishing to make their own driver. > The idea is that src/egl/drivers/glx/ has already provided a simple > EGL driver > that works. The demo driver, though compiles, is outdated or may > outdate over > time since it is not a working driver that can be verified.
Hmm, maybe you are right. But it doesn't cost anything to keep it around. >>> * Non-working >>> * src/egl/drivers/dri/ >> Having the dri driver working would be desirable since it allows >> you to use >> none gallium drivers standalone. > The only problem with the dri driver is that no one is maintaining > it. I agree > that there might still interests in loading DRI drivers from EGL > drivers. I > wrote one for Android. > > How about we keep the xdri driver and leave dri driver in the git > history? The > xdri driver > > * dlopen()s DRI1/DRI2 drivers > * talks with the X server using DRI1/DRI2 (the protocol) to implement > functions like getBuffersWithFormat > * works well > > The first point is the key idea shared by both dri and xdri drivers. The xdri driver is pretty much deprecated by the glx driver as it does pretty much the same thing. The dri is more interesting then the xdri driver since it is standalone from X. >>> * src/mesa/drivers/dri/fb/fb_egl.c >>> * src/mesa/drivers/dri/radeon/server/radeon_egl.c >>> * src/mesa/drivers/dri/r600/server/radeon_egl.c >>> * src/mesa/drivers/dri/r300/server/radeon_egl.c >>> * src/mesa/drivers/dri/r200/server/radeon_egl.c >>> * Deprecated by egl_g3d >>> * src/gallium/state_trackers/egl/ >>> * src/gallium/winsys/egl_xlib/ >>> >>> If anyone has any concern or is actively using any of the driver >>> listed >>> above, >>> please let me konw. The removal, especially of those in the last >>> category, is >>> still a plan, and is supposed to be several weeks away. If anyone >>> has any >>> trouble using/testing egl_g3d, please let me know too. >> I'm okay with removing s/g/st/egl and moving egl_g3d to s/g/st/egl. >> Actually >> I'm more then okay with the move since I'm not a big fan of the >> name name >> egl_g3d. > Thanks. I will do the rename after the removal :P >>> >>> As for the re-organization, I want to move various demos using EGL >>> to >>> progs/egl/. The directory structure will be like >>> >>> progs/egl/opengl >>> progs/egl/opengles1 >>> progs/egl/opengles2 >>> progs/egl/openvg >> Also progs/egl/interop once we get inter API communication working. > Yes. Actually, inter API communication should be working with > egl_g3d. It > just lacks demos. Ah cool, I'm looking forwards to when we get EGLImage. >>> >>> There will be simple window-system glue code that the demos may use. >>> Simple >>> demos who use the glue code will be able to run on multiple window >>> systems >>> like >>> X11 and bare KMS. >>> >>> There are also plans for new features and internal cleanups. But >>> I want >>> to >>> start with attracting new users/developers first, as EGL is almost >>> ready >>> to >>> shine. >> Nice work! >> Can you write down a list of what drivers that the new code produce? > When configured with --egl-native-displays=x11,kms, egl_g3d will give > libeglx11.a and libeglkms.a. They are used by winsys/drm/ to give Just a nitpick --egl-native-displays should be somehow marked as being gallium only as the native display interface is dependent on gallium, also why do you have to include egl_g3d there shouldn't that just be common? > > egl_x11_i965.so > egl_x11_i915.so > egl_x11_nouveau.so > egl_x11_r300.so > egl_x11_vmwgfx.so > egl_kms_i965.so > egl_kms_i915.so > egl_kms_nouveau.so > egl_kms_r300.so > egl_kms_vmwgfx.so > > I only tested the i915 ones. Luca reported success with nouveau > ones. The > others are only compile tested. Automatic driver selection is also > part of the > plan. Ok cool stuff. Cheers Jakob. ------------------------------------------------------------------------------ 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
