At these days the X Developer Summit takes place in Cambridge, UK. Most interesting is the AMD/ATI non-NDA announcement. Also some notes about a talk by Red Hat about their work at X appeared online.
This year’s X Developer Summit is taking place and it is yet another event were I would have liked to be. 😉 (Just to be clear: all I know is taken from other sources!)
Of course the biggest news is that AMD/ATI will be releasing the hardware SPECS without an NDA. It means that everyone will be able to develop drivers or software in general for their hardware without any larger problems (well, given that there are sufficient coding skills of course).
But of course the summit was used to talk about more things. While there are not that much information out yet some short notes about a Red Hat presentation caught my attention: it looks like Red Hat is heavily working on smoothing out the edges X stil has during boot (and when you switch to the virtual terminals):
Smooth GUI booting: no mode switches and annoying flashes.
Nice, I’m looking forward to see that stuff in Fedora!
Anyway, the problem is that the work done by Red Hat requires some techniques which are only available on Linux – not on BSDs or Solaris.
This brings up an interesting conflict: the lack of certain technologies on BSD and Solaris might hinder improvements on Linux. The question is now what to do. Wait for the others to catch up? Fork? I guess that the big, cross-platform projects are often faced with such situations. GNOME heavily depends on HAL for example, and I’m not sure where this fits with Solaris. KDE 4 might be a bit less complicated in this regard because there are abstractions to take care of such issues (Solid, Phonon, etc.). But the general problem is there, and the question what to do is there as well.
I wonder how X.Org will deal with that problem.
/home/liquidat 
Well, Solaris probably can catchup linux but the bsds is another history….
T entire idea of HAL was to be a sane OS-independent API, and it seems to be fine at that:
FreeBSD backend:
http://lists.freedesktop.org/archives/hal/2006-November/006485.html
Solaris backend:
http://lists.freedesktop.org/archives/hal/2006-November/006479.html
HAL doesn’t attempt to address hardware abstraction of graphics; that’s X’s job. The whole discussion here is about what X should expect from the OS.
The expectation is that if there’s interest in the other OSes, they’ll catch up. Most of the X code is MIT-licensed anyway, so once you’ve got a sample implementation for Linux, adding one for BSD/Solaris/whoever is fairly easy.
Ajay, I never stated that hal abstracts graphics. I just thought about other situations where you might have OS specific things which hinder real cross-platform development.
Colin, thanks for the info, I wasn’t aware that there are existing solutions for Solaris. Do you know how well this is implemented?
Slowing down X development because another system doesn’t support xyz functionality should not happen. GNOME faced the same dilemma with HAL which was not supported on Solaris or BSD. Developers in both communities stepped up and wrote hooks in HAL to work with their kernels. The key was backwards compatibility with extra features (like reliable automounting) being optional but useful enough that the other systems would soon implement the needed APIs.
you can find the specs (more than 900! pages) here:
http://www.x.org/docs/AMD/
Correct it’s a major issue…
An another example about that is the dri/drm system for graphic driver. If every thing go on direct rendering interface, X could be rootless. When you know that X.org it is 16 miilions of line code, and 1/3 of them whose work with high privileges (and doing a ‘part’ that linux already does !!), you understand with critical machine (like web server) never work with a X session on it.
Prb is neither Solaris nor other *nix (except FreeBSD) can have direct register manager module on kernel space… so GNU/Linux is stuck for the moment…