WARNING: This server is unstable and will be retired in the next days.
If you want to keep this forum available, please request immediately a migration
on the Nabble Support forum.
Forums that don't receive any migration request will be deleted forever.
On Tue, Jan 12, 2010 at 10:52 PM, Jakob Bornecrantz <jakob@...> 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.
>> * 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
* 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.
>> * 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
>> 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
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
> 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.
>> There will be simple window-system glue code that the demos may use.
>> demos who use the glue code will be able to run on multiple window systems
>> X11 and bare KMS.
>> There are also plans for new features and internal cleanups. But I want
>> start with attracting new users/developers first, as EGL is almost ready
> 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
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
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
Mesa3d-dev mailing list