As some you may have been aware, this year’s XDevConf was held at the beginning of the month (and much thanks to Sun and Stuart Kreitman for putting it on!) and I was fortunate to be there for some of the talks and to give a small presentation of my own of the Virtual Multihead feature in the up coming VMware Workstation 6.0. As you might expect, the challenge of getting X multihead to work on both the host and the guest is not to be taken lightly and despite my best efforts, the presentation was not without complications (primarily due to a bug in some of our code that I fixed immediately afterwards…) but most importantly, my discussion of some of the limitations I had to deal with (including the old classic of not being able to resize above the initial screen resolution) led to a very productive conversation with Andy Ritger and Aaron Plattner from nVidia where they explained how to resize as large as you want, and I was able to make the requisite changes in the driver pretty quickly that afternoon.
I think this illustrates one of the perennial problems with X and the cannonical X.org server implementation – that there’s a large collection of accepted wisdom and very few people who know enough to be able to verify what is still true, used to be true, or never was true. The ability to resize the screen (or lack thereof) definitely falls into this category. Originally, we all believed it couldn’t be done – as reinforced by the VidMode extension that would let you resize the viewport, but not the screen itself. Then Keith proved that you could resize the screen and the root window smaller than the initial size when he did the original Xrandr implementation. And for most observers, that was and remains the status quo. But most people (me included) didn’t really understand what the problem was that prevented resizing larger than the initial size – and at the current moment in time, it seems the only real problem is XAA – the old and obsolescent X Acceleration Architecture – which is on the way out in favour of EXA. If you don’t need XAA, you can resize the framebuffer as you please and grow larger than the initial size. The nVidia drivers don’t use XAA (or EXA for that matter) in favour of their own acceleration architecture and consequently were able to fix this problem. Thomas Winischhofer has also apparently fixed it in his closed-source SiS drivers, but I’ve not seen it for myself or heard from anyone who has. The other drivers all seem to remain stuck, although the intel driver apparently supports resizing the X screen larger but still backs it with a fixed framebuffer allocation.
As for the VMware driver, we had a bunch of code to implement XAA hooks but due to the nature of virtualization, we pay a very high penalty whenever an unaccelerated operation appears in the stream – so high in fact, that it cancels out any performance gain from providing acceleration in the first place! As such, we disabled this “acceleration” back in Workstation 5.0. So, I was happily free of any XAA encumberances and I could make the change (and delete all the dead XAA code as well). The final piece of the puzzle is knowing how to resize the framebuffer and the screen’s root pixmap. Eric Anholt had mentioned this to me last year as being something you’d have to do, but I got the impression it was a scary thing to do with implications that no one really understood, so I didn’t really pursue it. Of course, it turns out that there are actually calls you can make to do this and once I was informed by the nVidia guys, I was able to grep my way to understanding by looking at the intel driver which uses these calls to do rotation (and also confirm that no other drivers are doing it).
So, the new 10.15 driver has been released and will be present in Workstation 6.0 but you can go grab it now and it will work with Workstation 5.5 just fine. As a bonus, I also pre-populated the mode list with a fairly comprehensive set of standard 4:3, 16:9 and 16:10 modes because the X server will filter out any modes in your xorg.conf larger than the initial one – so even if you physically can switch to them, they won’t be there.
I think that with Xrandr 1.2, we’ll see this problem fixed in a lot of drivers, because it’s not going to be possible to dynamically add monitors in a useful way without being able to resize up. I’m glad it’s finally happening, but it’s also rather amusing that it was always possible but so few people realised it.
{ 2 } Comments