Anyone knows if this impacts Qt environments like KDE (and Kwin) in any way?
Been there. Totem becomes unstable and Parole is too lacking in core functionality (plus I can't seem to get it to build on 10.04, for some reason), to replace it. With the sole exception of gstreamer failing to downmix AAC audio with ALSA (oddly enough, it works with pulse, even when pulse is merely acting as a wrapper for ALSA), gstreamer has been the only multimedia backend that's worked reliably for me. Mplayer and VLC both have performance difficulties, with motion jidders, regardless of DRI2 redirected overlays.
Of course. What made you think this was Gtk/Gnome related? The article is about the KMS and DDX driver work.
I hope that's not to imply gstreamer is, "Gnome tech".
Anybody knows if the patch for the kernel-module is already merged to the drm-radeon-testing branch? And if not where i can find it?
Not really. It seems that it's a non-standard GLX operation: A new GLX swap event extension also came about out of expressed needs by the Clutter/Mutter developers.. Thus, I wonder if KWin composite manager can use it and if Qt can use it in it's opengl renderer (as opposed to the software renderer).
Well, it's Glib techI hope that's not to imply gstreamer is, "Gnome tech".Gnome is the major user of Glib and AFAIK Gnomes main player Totem uses GStreamer (correct me if I'm wrong), so they're tightly related.
Oh, I misinterpreted your question. Sorry. It's just a matter of implementation, I suppose.
Glib's been it's own entity for a while now and yes totem uses gstreamer but it can (could?) also use xine. Gstreamer's not exactly a project that emerged within the Gnome eco-sphere and it's also worth pointing out that phonon can use gstreamer and does so by default, IIRC - at least on the distributions I'm familiar with. During the KDE4.0 development cycle, it was the belle of the ball in Gnome, KDE and freedesktop.org's efforts to standardise a lot of the underlying implementation of common technologies.Well, it's Glib techGnome is the major user of Glib and AFAIK Gnomes main player Totem uses GStreamer (correct me if I'm wrong), so they're tightly related.
Actually under Linux you don't need a new kernel either. You could checkout drm testing and buidl the modules separately just like v4l. That of course would be impractical, but it is possible.
As for Windows. Well, there you have the kernel which is provided by Microsoft and you've got the driver that's provided by AMD. The stack used by AMD is completely separate from the Microsoft kernel stack, apart from using the appropriate kernel APIs. Thanks to that, when the Microsoft API changes, you can say goodbye to your old driver and your old graphics card, it simply won't work.
Both models have their strengths and weaknesses, so the above "single driver" rant isn't really worth taking note of.
Windows and Linux hardware driver both include kernel and multiple userspace components. The only "difference" here is that Windows and Linux binary drivers deliver all the required components are delivered as a single bundle, while in the open source world each of the required components is a separate source tree (project).
The components still have to be designed as a set, and during times of rapid change to internal APIs it's a good idea to upgrade them as a set.