RandR 1.3 and other future X.Org development

cube-with-matrix
A month ago the X Developer Summit took place. Now notes about most of the talks are available and show where X development heads to. Among the information are a feature list for RandR 1.3, for the Intel driver and for X.Org 7.4/7.5.

The X Developer Summit took place from 10th to 12th September and got quite some attention when AMD used the Summit to announce their release of hardware SPECS without any NDA. But there were of course other talks dealing with other, not less interesting topics and the notes about these talks are now available.

RandR 1.3

RandR 1.2 is nowadays shipped with all recent distributions and is supported by most of the current drivers (it is really a twist of fate that my hardware is no yet supported…). It makes live much easier if you have a mobile system or need device hotplugging elsewhere.

The next version however will feature GPU object support. According to a discussion about that topic the GPU object support will enable RandR to combine different a set of X screens with a different number of hardware GPUs:

Right now, with RandR 1.2, you get multiple X screens, one per-GPU, each of which can have multiple monitors connected.

With this feature several GPUs could be merged into one X screen similar to the classical Xinerama setup.

Intel driver

Keith Packard reported about the Intel driver development. Intel graphics hardware still has the best graphics drivers for Linux, but that might change soon due to AMD’s new efforts.
Anyway, the Intel driver itself is in a pretty good state: all current X.Org features like RandR 1.2 and even TV out are fully supported. The next version will feature OpenGL 2.1 support, MPEG hardware decoding, HDMI, improved power savings and output scaling. The driver can be expected around January 2008.

Also, it is interesting to know that the Intel driver developers have a test environment containing at least one of each chipset – this should be normal for every hardware driver development group, but unfortunately isn’t yet for Linux driver developers. The support of hardware vendors still isn’t in such a state (yet) and sometimes the developers depend on donated hardware.

X.Org 7.4/7.5

The X Access Control Extension (XACE) will be ready for SELinux and Solaris Trusted Extensions with X.Org 7.4. This will improve the security model of the X.Org server.
Also, the Distributed Multihead X (DMX) feature which can combine several different backend X servers (think of separated hardware here) into a single virtual X server will be able to use Device Independent X (DIX) as an input module (but to be honest I’m not sure which direct effect this will have for average users).
The notes also say that we can expect Glucose in 7.4 or 7.5: it would fill the gap between Xgl (rendering everything but with a second X server) and AIGLX (rendering without a second server, but not rendering everything).

But there is also a feature delay: as it looks like the multi pointer support for X, MPX, will not be ready for X.Org 7.4. Instead it will be shipped with X.Org 7.5.

Other news

In other news Vedran Rodic made clear that OpenGL performance on Linux sucks and has to be improved – and he is right! He mentioned that regular tests should be done and should be compared to Windows results to determine what and where the problems are.
I hope that in one day there will be entire test labs dedicated to just testing drivers and driver performance on different machines and setups for Linux. But we might have to wait years for that to come true…

Also Michael Dales introduced the new driver “nivo”: network in, video out. The idea is to push VGA and input data through the network thus creating ultra thin clients. While this can be done already via Xvnc Dales is developing an extra driver for better performance. This driver is unique in the X.Org driver collection: all drivers are for output OR input, but “nivo” is for both. :)
While I do not have any personal need for nivo it could push the Linux adoption even further since it makes it even cheaper (and more power saving) to create thin clients. Nice.

About these ads

13 thoughts on “RandR 1.3 and other future X.Org development

  1. Thanks for this nice and clearly exposed summary. The future of X looks so exciting. I can’t wait for the next releases.

  2. Any idea how thrifty nivo might be? We currently use Sun’s thinclient, a sunray, and that setup is pretty slick. Would nivo make X connections as lite as say nx?

  3. I don’t actually know what you mean by “OpenGL performance on Linux sucks”. Which drivers are you talking about? The close source Nvidia driver is pretty much on par with the Windows version. Modern games like Quake4 or Doom3 are just a bit slower (maybe 5%-10%) compared to Windows, but according to Timothee Besset (he’s responsible for all Linux clients @ id software) that’s because the games aren’t really optimized for Linux. For example the Quake4 version lacks inline assembly on Linux. This costs about 5%.

  4. I know this might be long and coming, but I’d really like to see MPX support in the major desktop environments. I think there is a lot of unexplored potential in multiple mice.

  5. Christian: The best would be to ask the developer himself – also, the current state seems to be Alpha or pre-Alpha, so it might be too early to ask such questions.

    anom: The open drivers do have serious OpenGL problems. Linux’ original OpenGL stack is the problem.

  6. What do you mean with multiple boards? You can connect several monitors to one GPU, that is for sure because I have such a system running here. But I’m not sure what boards are in this regard. Mainboards?

  7. By multiple boards, I think Veloce means multiple graphics cards. Or to put it another way, could RandR 1.2 work with 2 graphics cards and 3 monitors?

Comments are closed.