SFX in future Ubuntu releases

[Étienne Bersac]

Hello,

> > It seems that some people here need a review of desktop technologies.
> Clearly.

;) Thanks for your clarification :)

> 
> First, neither Composite nor X.org were made by Fedora/Red Hat.

Yes, i underestimate the importance of Fedora. I just wanna point that
Fedora/Red Hat is sustaining AIGLX where Novell (and maybe Mandriva)
sustain X*gl*. Of course Red Hat just collaborate where Novell did all
the work behind the curtain.

> You are possibly confusing Composite with AIGLX (they
> are two *completely* different things). 

Wish i don't. AFAIK, Composite just allow a composite-manager to compose
frame buffers in memory before displaying it. This allow to not redraw
window when moving one over it. In the other hand, AIGLX allow to use
that frame as GLX Texture to enable effect such as the one compiz do. I
may be wrong, but at least, Composite != AIGLX :)

> So far as a security hole... there is no security hole opened by
> Composite.

No, the problem in X11 is the driver model which give big power on
drivers. Especially for drivers not using DRI.

> 1) Why write an all-new architecture for an all-new server when you could
> just offer fixes to X.org, which requires *far* less work and change? 
> X.org developers are already working on this theoretical "security hole." 
> It's going to take some work on both their and the kernel developers'
> parts, but it'll be less work than EGL would require.

AFAIK, writing a driver for X is quite difficult. There is many way to
write a driver.  I see three exemple : radeon which use dri, but not
necessarily fb, sis which use necessarily (a bloated) fb and dri, and
nvidia, the big blog that use neither dri nor nvidia. Exploring an other
way to design drivers for an Xserver is quite interesting at least in
that point.

> 2) Why write a whole new X server
> when you can just write a glitz backend for X.org?
> This wasn't possible before because the X.org server couldn't directly
> access the 3D hardware at the same time as client apps, but that's what
> AIGLX fixed.

That is a big good news man ! But will that simplify driver
architecture ? Also, i consider that this is painful to have a
framebuffer and an Xserver not synced. EGL and an Xserver on top of EGL
might be a good solution to have a consistent graphic support. Why have
we so big restriction with usplash (16 colors, etc.) where Xorg work
fine ?

> 3) Actual driver developers disagree. 

You may be right, i don't pretend knowing more than you this problem,
but, hey, i'm not David Reveman ! Howver, ubuntu-art needs a deep review
of the future possibility.

> I didn't find anything on it at
> http://code.google.com/soc

I missed that this was just an Idea. Sorry.
https://wiki.ubuntu.com/GoogleSoC2006#head-585998c7c709ee2a87c4d4cf917cd2227d826a17

> And before anyone brings up the "X.org 7.1 w/ AIGLX breaks NVIDIA"
> argument, note that since Xglx has to run on top of X.org, once Edgy
> updates to X.org 7.1, Xglx is going to be just as broken until new NVIDIA
> drivers come out that support X.org 7.1 fully.

The guilt is to nVidia blob ! Where is the EGL nVidia driver ? nVidia is
clearly against that driver model, partly because it makes all driver
the same at the end : OpenGL (modulo the subsets).

> I think it's pretty clear that I'm against putting XGL into Edgy in any
> official capacity.

100% agree. Xglx is funny, but that's not a solution to push xserver
over xserver !

For the most important things for Edgy is composition, not GL window
manager. I get tired of that cpu hungry windows move.

Thanks for your comments. Very interesting.

Étienne.
-- 
Verso l'Alto !