The X Window System is, in some sense, the kernel of our graphical desktop
systems; it controls access to the hardware and ensures that applications
play well together. So the capabilities provided by X matter, and that
importance can only increase as free software developers work toward the
![[Keith Packard]](/web/20130516073151im_/https://lwn.net/images/conf/lca2007/keithp-sm.jpg)
creation of more complete and compelling desktop experiences. Keith
Packard gave a couple of talks at linux.conf.au in Sydney on where X is
going; your editor had no choice but to be there and listen.
In its early days, X would normally be run on some sort of Unix
workstation. The display hardware in use in those days was not normally
expected to change while X was running - or over the life of the system in
general. One connected The Monitor to The Adapter and things stayed that
way forevermore. So the X protocol was set up to enumerate all of the
available screens whenever an application made its connection. There was no
way to add more screens on the fly or change their geometry, and there was
no way to move windows from one screen to another. Fixing this was a hard
problem.
As graphics hardware has become more powerful and flexible, a number of
extensions have been developed in an attempt to provide proper support in
X. The Xinerama extension uses a clever technique: merging all of
the monitors into a single, large, virtual screen. Applications can then
move between monitors, because they think they are just moving around on
the same screen. The XFree86 VidModeExtension tried to address hardware
changes by allowing the video modes to be changed on the fly. Then along
came the first version of the Resize and Rotate (RandR) extension, which
tried to improve the handling of mode changes and implement rotation -
especially useful on handheld devices, where the screen can be used in both
landscape and portrait orientations. RandR 1.0 was limited by a policy
(imposed by the XFree86 maintainers) that the driver API could not be
changed; as a result it was nowhere near as flexible as its developers
would have liked.
All of this came together into "a kludge tower of extensions" which was
guaranteed to fall down, sooner or later.
Since then, the X Window System has come under new management and the need
for display flexibility has continued to grow. Enter RandR 1.2, soon
to come to an X server near you. The new RandR release comes with the
intention of being able to fully express (and use) the capabilities of the
hardware. All configuration options will be brought back together into a
single file, and they will all be adjustable at run time. Much of the
driver-specific code has been moved back into the core, allowing all
hardware to be configured in the same way. This was a much-needed change;
according to Keith there are currently five independent Xinerama
implementations in the X server.
RandR 1.2 uses a combination of new and old concepts. A "screen" retains
its current meaning, and the one big screen is still present. Each screen,
however, can work with one or more "CRT controllers," (CRTCs) each of which
grabs a rectangular portion of the big screen and sends it to a monitor
(highly unlikely to actually be a CRT anymore). Each CRTC, in turn, has
one or more outputs which connect to physical devices.
The flexibility of this approach was easily demonstrated on Keith's shiny
little laptop. The hardware is able to implement a 2K pixel square screen,
which is then scanned by three different CRTCs: the built-in display, the
video output, and the (unconnected) TV output. By default, they all look
at the same portion of the screen, but, with a little command line magic,
that can be changed. So Keith's laptop can display an entirely
different set of windows out of each CRTC; the video output can send his
talk slides to the projector while the laptop screen shows something else.
The display areas can overlap if desired.
If a new monitor is plugged into the system, the RandR code will detect the
event and react accordingly. The new output will be turned on and given
screen space according to whatever policy is in effect. If need be, the
user's desktop area will be expanded to cover a wider display. Similar
things happen if a monitor is removed. It all Just Works.
While he was at it, Keith extended RandR to cover some other useful
hardware capabilities. These include the ability to configure the gamma
lookup table, allowing for on-the-fly contrast and brightness adjustments.
Applications can get the monitor's EDID identification data, should they be
interested, and parameters like the brightness of the backlight can be
tweaked.
The current status is that the protocol and device-independent work are
done. The Intel driver works now, and the Radeon driver is『nearly
usable.』 This code is getting ready for people to use.
When most people will actually use this code depends on the release
schedule, however. At a separate talk (in the middle of the Debian
miniconf) Keith covered what's coming up from the X.org project.
Coming soon is the X server 1.2 release. This one looks mostly like a
maintenance release; Keith says that a lot of Coverity-found bugs have been
fixed. Things have been cleaned up to the point that this release has
40,000 fewer lines of code - but more functionality. Keith noted that the
policy of splitting the X drivers from the core server has not worked as
well as they would have liked. It adds a whole set of API compatibility
issues between the two, making it hard to develop and release improved
versions of the server. Keith now thinks that the Linux kernel developers
got it right by keeping drivers inside the kernel.
LibX11 1.1.1 is coming soon. The big change there is that the new XCB
interface is being used underneath the old Xlib API, making it easy to
migrate applications in an incremental manner.
Later on we can expect release 1.2.1 of the X server. This release will
include an EXA acceleration implementation "that actually works." The
RandR 1.2 code described above will also make its appearance here.
Further ahead, the 1.3 release (to be part of a general X.org 7.3 release)
will include significant ABI changes. A lot of the "PCI munging" is coming
out of the drivers. Yes, he said, this will mess up the proprietary NVidia
and ATI drivers. There will also be better support for hotplugging of
input devices.
There is a Mesa 6.5.2 release coming with OpenGL 2.0 API support. It also
has
a new memory manager which can work with the memory management unit found
in modern graphics cards; it can do things like map arbitrary regions of
host memory into the adapter's address space. Among other things, this
means that off-screen objects can be made writable, which will be a big
performance win.
On the Intel driver front, the mode setting code has been much improved in
recent times. Not surprisingly (considering that Keith works for Intel
these days), this driver is the first to have full RandR 1.2 support.
All outputs are fully supported, and EXA is as well. Intel has set a goal
of having drivers available for new chipsets on the day those chipsets are
launched. When asked if Intel planned to start selling discrete adapters,
he became very silent, however.
Looking further ahead, the X developers would like to move video card mode
setting into the kernel. There are a lot of reasons for doing this,
starting with simple robustness. It would also enable better suspend and
resume support, and better handling of panics: if the system goes into an
oops, an in-kernel mode-setting routine can switch back to a text mode,
allowing the oops text to actually be read. There is a lot of interest in
supporting multiple, simultaneous X sessions on the same screen without
using Linux virtual terminals; the goal here is to enable fast switching
between user accounts. And there is interest in H.264 acceleration,
facilitating the display of important things like HDTV. It seems that even
contemporary CPUs can have trouble keeping up with HDTV streams.
Overall, Keith painted a picture of a revitalized X project which is truly
beginning to hit its stride. A lot of work is being done toward the goals
of fully supporting current hardware and providing the foundation for the
creation of the best desktop available anywhere. One cannot help but look
forward to where things will go from here.
(
Log in to post comments)
What makes you think that? Is there any reason why BSD's (for example) couldn't offer the needed functionality as well? And the comment said that "He wants to move mode-setting in to the kernel". Where exactly does that comment say that he wan't to move it to the LINUX-kernel, and only to Linux-kernel? Other kernels could offer the same functionality as well. If they choose not to offer it... well, that's their problem.
As to older Linux-systems.... Since they are older system, why couldn't they keep on using an older release of X? if you want the latest bells and whistles, using an old version might not be the best idea.
I'll be glad when I have a working graphics setup which consists entirely of Free Software, but at the current time Intel's marketing and Intel's execution diverge. Do you think Intel would have released a Windows driver that was incapable of setting the screen size? That's what they've done with their Xorg driver for going on six months.
My new notebook has a 1920x1200 screen, but the vbios doesn't know about that size, only 1600x1200 or 1920x1400. So it isn't exactly Intel's fault
if the hardware manufacturer provides a broken bios.
Fortunately there is a program "915resolution" which "corrects" the VBIOS. I ran it and suddenly 1920x1200 worked just fine.
Besides, what should it be replaced with? LCDC? And then replace that 5 years later with LEDC? :)
Thank you Keith, as the Intel driver's BIOS calls are somewhat problematic on the Mac Mini (requiring the installation of the Bootcamp BIOS emulator, thus during-boot keystrokes are required to select the Linux operating system else it boots MacOS).
You are right that it's not the "fault" of Video BIOS. It is simply a poor design of the Intel's X video driver. Yes, I know they are fixing it; the problem is that it's been in the "being fixed" stage for >6 months already. Obviously, it's still better then nothing; I'm periodically downloading the current modesetting branch, but have yet to encounter a version that would work flawlessly. The latest one I'm running now (from two weeks ago) disables XVideo at my resolution due to some "double-wide pipe mode" nonsense (luckily commenting it out in the source fixes it), and it sometimes locks the machine up for good if I don't use it for a while.
Oh, and 855resolution doesn't work for me. I think the problem is that it adjusts the resolution, but not the frequency. Dell 2007WFP only accepts 1680x1050 at precisely 60Hz, which is apparently not what the laptop is sending it if I use 855resolution.
It's quite offensive for developers if their software is judged by experience with other software.
It doesn't even want to think about working. No bios, no boot, no X. The modesetting branch does recognize the existence of the ADD2 card and produces no display at all. The documentation for configuring the driver is full of undescribed terms (grovelling in the source explains some (LFP/DFP) but not all). I don't know what a pipe is, really and how it might be used or not used in my system.
As someone who can download code from version control and read source to an extent, this configuration for (6 month old?) hardware still doesn't work in Linux. I feel the announcement was premature.
Sun microsystems would probably not like this change.
I am not involved in the X.org development in any way, so I have no way at all of knowing if his claims hold any water, but it would be interesting to know.
Nice article though.
Even then it seems like you might get into restrictions on refresh rates or pixel clocks between the two outputs if there is only one pixel clock source, or if there are synchronization requirements between the two pipelines during refresh. I haven't looked closely at modern display hardware, though, so I really couldn't say.
Wow. What about all the funky arguments thrown upon KGI developers when they proposed the same thing 10 years ago ?
Grumbling...