David Reveman of Novell shares his thoughts on Xgl, Metacity, and more."I've been getting a lot of mail from people asking me about my thoughts on AIGLX, the GL compositing work being done on Metacity and nVidia's xdevconf paper. Instead of replying to everyone individually, I though I'd send a mail to the Xorg list."
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-07-06
I've read arguments against this approach describing it as Linux centric.
So far none of the shipping versions of EGL have been on Linux. EGL is a Khronos API, http://www.khronos.org/egl/ It is totaly platform independent. Current implementations are on proprietary embedded systems and cell phones. It is likely that EGL will be used in the PS/3.
Quote from the Khronos page: EGL can be implemented on multiple operating systems (such as Symbian, embedded Linux, Unix, and Windows) and native window systems (such as X and Microsoft Windows).
Just because I built a non-released implementation of the EGL API by using the Linux fbdev drivers, the entire EGL API has now been tagged as Linux centric.
Edited 2006-02-23 23:53
Member since:2005-07-10
For anyone wanting context, read the "Xegl lives!" thread:
http://lists.freedesktop.org/archives/dri-egl/2005-May/thread.html
Alan Coopersmith from Sun was the person raising concerns about Xegl being Linux centric. Several people point out that he is mistaken and that OpenGL/EGL as well as the input subsystem are platform agnostic. It is only the OpenGL/EGL stack and input drivers that are platform specific.
Member since:2006-02-04
Me too.
Xegl may be a better way to take advantages of modern graphics rather than AIGLX. And Xgl is making the way straight to that. So before drivers for Xegl is ready, we can adopt to Xgl with current drivers, then why AIGLX? Because of high quality driver of one vendor, we choose AIGLX, that's not a good idea.
Member since:
2005-07-10
Xgl isn't the "final" solution because it still has to run on top of another X server. Xegl is seen as the goal and that is still a ways off. The problem, as I understand it, is that Xorg includes too much code which talks directly to hardware. It basically has its own drivers for input and video. These drivers can conflict with kernel level drivers (e.g. fbdev on Linux) because they both try to manage mode setting, etc. The idea behind Xegl is to move drivers out of X by allowing the X server to use the EGL APIs for mode setting, multi-head, etc. Drivers then just implement EGL. Mesa apparently makes this a lot less work. I believe this is what Jon Smirl meant by "leveling the playing field" in his comment above. I've read arguments against this approach describing it as Linux centric. Others worry that venders (nvidia, ati) won't want to rewrite their drivers to use EGL. I view this as something X needed to have done yesterday (honestly, who whats to continue hand editing a *.conf file), and effort spent giving Xorg more life (AIGLX) is just making it that much harder for Xegl.