David Dawes is maybe the most active XFree86 developer and he is also the lead founder of the project. He works for Tungsten Graphics, which is the main company working on the XFree, DRI and Mesa codebases today. We are happy to host an interview with David, discussing the present and future of XFree86 project. Update: Still confused how a VSYNCed desktop look like? Read here.
Permalink for comment
To read all comments associated with this story, please click here.
I think it has been an astounding success (something that has been designed in the 80's and still works really well?), and will be with us for a couple of more years even.
However, I think even they are seeing they've should have moved things alot more server-side. Your hardware is at the server-side (3d card), and the user is at the server side (GUI policy/prefs). Does it really make sense that the app creates a pixel-based representation of the GUI at the _client_-side?
I think the way forward is something like Fresco aka Berlin (www2.fresco.org) - which probably won't appeal to most people here because it's really a research project, slow, and years (?) off from being usable. Nevertheless, it holds alot of potential, and tries to do the Right Thing.
As an example of coolness: It's completely device-independent (no more pixels!) - something even MacOSX doesn't do properly (and yes, everything (windows, buttons,text,...) can be hw-accelerated using openGL - it can even output to postscript, or if you're the conservative type - pixels).
As for problems i have with the Xfree86 implementation (not X design):
I really hope:
- they clean up their input layer. See Linux's input API, or the GGI project's GII library.
- they chop the whole thing up in little pieces: I'd like to be able to run DRI fullscreen without the 2D windowing management or X network protocol. I imagine there's other people that want to dump other pieces etc. Modularity is good.
- do they really need to run the whole thing as root? jeez.
- the font handling gets sorted. Actually, freetype is quite good, it's just there's a need for a lot of other infrastructure. I heard rumblings of a "unitype" service from the freetype people to standardize font locations etc on unix systems (everything that doesn't have to do with the actual rendering of fonts) I'm sure it'll get sorted eventually.
I have several problems with X.
I think it has been an astounding success (something that has been designed in the 80's and still works really well?), and will be with us for a couple of more years even.
However, I think even they are seeing they've should have moved things alot more server-side. Your hardware is at the server-side (3d card), and the user is at the server side (GUI policy/prefs). Does it really make sense that the app creates a pixel-based representation of the GUI at the _client_-side?
I think the way forward is something like Fresco aka Berlin (www2.fresco.org) - which probably won't appeal to most people here because it's really a research project, slow, and years (?) off from being usable. Nevertheless, it holds alot of potential, and tries to do the Right Thing.
As an example of coolness: It's completely device-independent (no more pixels!) - something even MacOSX doesn't do properly (and yes, everything (windows, buttons,text,...) can be hw-accelerated using openGL - it can even output to postscript, or if you're the conservative type - pixels).
As for problems i have with the Xfree86 implementation (not X design):
I really hope:
- they clean up their input layer. See Linux's input API, or the GGI project's GII library.
- they chop the whole thing up in little pieces: I'd like to be able to run DRI fullscreen without the 2D windowing management or X network protocol. I imagine there's other people that want to dump other pieces etc. Modularity is good.
- do they really need to run the whole thing as root? jeez.
- the font handling gets sorted. Actually, freetype is quite good, it's just there's a need for a lot of other infrastructure. I heard rumblings of a "unitype" service from the freetype people to standardize font locations etc on unix systems (everything that doesn't have to do with the actual rendering of fonts) I'm sure it'll get sorted eventually.