LWN: Comments on "LCA: Updates on the X Window System"

LCA: Updates on the X Window System

csamuel — 2007-02-13T10:25:40+00:00

That would be my guess, it may be they recorded the time the session
began incorrectly.

LCA: Updates on the X Window System

jospoortvliet — 2007-02-12T21:56:46+00:00

Well, if many of these things are his idea, it should be acknowledged. On
the other hand, if there is code in there from him, and it has his
copyright, he is acknowledged, right? I can see it's sad Keith doesn't
metion him, but what, should Keith tell the world he didn't invent this
but luc did, every time he gave a presentation? Luc could give talks too,
that is what makes Keith visible...

LCA: Updates on the X Window System

AndyBurns — 2007-02-12T20:15:03+00:00

Well it was definitely named "monday_1430_debian.ogg" at the time I downloaded it, I still have a local copy of the file, perhaps someone re-organised the archives afterwards?

LCA: Updates on the X Window System

csamuel — 2007-02-12T09:56:07+00:00

I think you meant here:

http://mirror.linux.org.au/pub/linux.conf.au/2007/video/m...

:-)

LCA: Updates on the X Window System

k8to — 2007-02-09T12:18:52+00:00

After loading the Windows driver from Intel for the GMA x3000, suddenly DVI out on the pegasus ADD2 card worked.

The modelines I had been using for the device under VGA for a matrox card were still for some reason required (Under X.Org 7.1.x) and the presence of the 1400x1050 line for some reason caused the output to be blurry. Leaving only the 1600x1200 line in the xorg.conf, for my 1600x1200 Dell 2001FP allowed the display to come up nicely.

Remaining problems with the i810 driver:
- Changing resolutions with CTRL-ALT-+ and - results in a virtual desktop where not all regions can be reached, and the mouse display does not match the mouse click events. xrandr does not have this problem. The support for virtual desktops with scrolling appears broken.
- With the Mesa 6.5.1 based dri, opengl texturing has issues, and some kind of assertion against malformed pipeline instructions typically crashes openGL programs on context teardown.
- With Mesa 6.5.2 and 6.5.1 glx, many opengl applications crash the X server or corrupt the display. Sometimes the 1.7.2 version of the i810 driver cannot reinitialize the display, reporting lockups during attempts, forcing a reboot.

LCA: Updates on the X Window System

Thalience — 2007-02-01T20:33:55+00:00

I also seem to recall that the kernel developers were not on board with the KGI interface and code. If you are the sort who enjoys reading old flamewars, the following should be amusing:

http://marc.theaimsgroup.com/?t=89085703000001&r=9&...

I honestly don't know if there were good technical arguments against the KGI API (I have only browsed the flamewar a bit). But quite a bit of ill will between the two projects seems to have been based on personality conflict and snap judgments that were never reconsidered.

I do agree that the whole episode was "outrageously frustrating". It has always seemed obvious to me that XAA's "pci driver in userspace" design was the wrong way to go. Graphics cards are devices, and the kernel's job is to manage devices.

Moving mode setting into the kernel

Janne — 2007-02-01T14:50:36+00:00

"Otherwise the portability of the X server to non-Linux systems
(and older Linux systems too) will go *way* down :/"

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.

LCA: Updates on the X Window System

proski — 2007-01-31T02:02:13+00:00

No, I'm not the same person. I actually don't see words "lie" and "lying" anywhere in this discussion.

LCA: Updates on the X Window System

bronson — 2007-01-26T18:46:29+00:00

When video modes are set in the kernel, it will be as you say.

Until then, it is up to the process to set up the card. How can the news process know what mode the card is currently in? Even if it COULD reliably read back the mode settings (and on most hardware you can't), it would also have to see if the framebuffer is obscured by a video surface or GL surface, or if it's rotated 90 degrees, or... It amounts to a ton of code.

So, until it's all in the kernel (2 years at least, maybe more, IMo) it's safest just to reset and start from scratch.

LCA: Updates on the X Window System

bronson — 2007-01-26T18:34:19+00:00

amen. That was outrageously frustrating. I think difference is abandoning all the crufty xfree "leaders" in the move to xorg. I'm thinking of one leader in particular.

Or, if Luc Verhagen is to be believed, Keith Packard took a mighty U-turn at some point last year. I'm on the outside, so I have no idea. :)

LCA: Updates on the X Window System

pimlott — 2007-01-26T17:07:38+00:00

The obvious follow-up: Why isn't it fast? If video modes are set in the kernel (as seems the plan), in the common case where the mode is the same in the old and new virtual terminals, no reset should be necessary. But I'm a graphics ignoramus, so I may be missing something.

LCA: Updates on the X Window System

ortalo — 2007-01-26T15:33:17+00:00

"Looking further ahead, the X developers would like to move video card mode setting into the kernel."

Wow. What about all the funky arguments thrown upon KGI developers when they proposed the same thing 10 years ago ?

Grumbling...

LCA: Updates on the X Window System

bronson — 2007-01-26T06:03:16+00:00

Because it's not fast. On most hardware, it takes many seconds of blackness for the graphics card to reset and the monitor to sync back up. Users do not like this at all. The blank screen and flickering tends to scare them. Just ask my girlfriend; she uses my account because she really doesn't like the couple seconds it takes to switch.

Go figure.

LCA: Updates on the X Window System

pimlott — 2007-01-26T02:23:42+00:00

Keith noted that the policy of splitting the X drivers from the core server has not worked as well as they would have liked.

Can someone confirm: This is not referring to the recent modularization effort, but the stable ABI introduced with XFree86 4, right?

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.

What's wrong with using Linux virtual terminals? We've had fast user switching since day one!

LCA: Updates on the X Window System

kamil — 2007-01-25T19:23:16+00:00

Well, my notebook with 855GM chipset has an 1024x768 LCD, and that mode is in the BIOS. But I now have a 20" widescreen Dell flatpanel, with a native resolution of 1680x1050, which, not surprisingly, is not in the Video BIOS.

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.

LCA: Updates on the X Window System

drag — 2007-01-24T15:26:52+00:00

Wow. That is potentially very good news.

I know I'd buy one in a heartbeat if they plan on providing open source drivers like they do now. Even if it doesn't end up beating Nvidia in performance (which I doubt; after all nvidia is very good at what they do) my onboard 945g has been kind to me reliability-wise. Better then Nvidia, at least.

LCA: Updates on the X Window System

jwb — 2007-01-24T01:28:34+00:00

Aren't you the same person who accused me of lying earlier in this discussion?

LCA: Updates on the X Window System

proski — 2007-01-24T00:33:53+00:00

It was fixed today.

LCA: Updates on the X Window System

gdt — 2007-01-23T23:51:05+00:00

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).

Too late? I hope not.

nim-nim — 2007-01-23T21:55:33+00:00

I followed the Java story more closely myself. At one point SUN started saying things like "Java people feel JCP is open enough, but it's still not good enough for many Linux distributions and we need Java there too, so we'll bite the full GPL bullet like GNU Classpath"

In fact they found themselves attacked as soon as the deal was announced both by IBM/Motorola/Intel (wanted BSD/Apache) and a lot of Java developers (what's the deal with GPL, you've been teaching us for years Java didn't need it, we don't care about Linux commies, etc).

The Linux market had everything to do with the opening of Java (with .Net helping SUN to come to its senses)

Too late? I hope not.

k8to — 2007-01-23T20:50:26+00:00

Hmm, this smells believable to me, but how do you know this? Are you thinking of (for example) the Apache Foundation as "old UNIX/BSD guard" and GNU Classpath/GCJ as "Linux Users". I know the X story in more detail and I guess that one sorta rings true, since the deliberate addition of "old BSD license" style GPL incompatability was the straw breaking that particular camel's back. Although I rather suspect OpenBSD would have tossed it out, along with many others.

Perhaps I'm just doubting how much you can consider FSF-style worldviews and development groups as conjoined with Linux users. Which I suppose is a boring old saw, although it will probably end up being very important over time.

Too late? I hope not.

nim-nim — 2007-01-23T18:42:15+00:00

What's interesting is both are linked to increasing Linux market pressure. In both cases Linux users forced the change, whereas the old UNIX/BSD guard was fine with the status-quo

LCA: Updates on the X Window System

i3839 — 2007-01-23T18:17:31+00:00

Looking a bit at it, I'd say it were mainly Luc's ideas at how to approach modesetting and so on, not the code itself (except a small part). And that after Keith earlier said that Luc's approach was wrong or could never work. Throw in personality clashes and you get a nice mix. Luc feels like his ideas and code are used without giving him any credits, with Keith/Intel trying to get all of it.

LCA: Updates on the X Window System

bronson — 2007-01-23T18:02:49+00:00

Because "CRTC" is an industry term that is older than I am. All video driver writers know what you're talking about when you say "CRTC" regardless of platform or API.

Besides, what should it be replaced with? LCDC? And then replace that 5 years later with LEDC? :)

Too late? I hope not.

sbishop — 2007-01-23T16:49:26+00:00

This talk about X development picking up speed reminds me of the
announcement about Java opening up. It's great news, but it's also a
shame that it has taken so long. I hope that it's not too late! Good
luck, Keith.

Does this explain TV-Out configuration?

jzbiciak — 2007-01-23T15:58:54+00:00

Does the TV Out display the same thing as the monitor? If so, then there's probably only one display generation pipeline that feeds to multiple physical outputs. My interpretation of the CRTC abstraction is that it also allows a single display controller to control multiple heads, each potentially displaying something different.

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.

LCA: Updates on the X Window System

vmole — 2007-01-23T15:54:30+00:00

And I really didn't expect him to answer my question about discrete adapters, but I'm sure I've seen rumours to that effect around, so it seemed worth asking

Apparently you needed to wait a couple of days: Intel discrete graphics chips confirmed (via slashdot).

LCA: Updates on the X Window System

jzbiciak — 2007-01-23T15:51:09+00:00

And what about these plotters that are actually printers, SCSI disks that are actually flash drives, and TTYs that haven't seen a teletype in decades? Next you'll be telling me that the primary use of TAR files really is tape backup! ;-) ;-) ;-)

LCA: Updates on the X Window System

k8to — 2007-01-23T15:43:11+00:00

Hah, I bought a new G965 system, but could not source one with DVI anywhere, so I bought an ADD2 card with DVI.

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.

Moving mode setting into the kernel

k8to — 2007-01-23T15:37:12+00:00

Of course remember that the terminal situation you propose (and I agree that could occur) need not be terminal. There could be some folding together at some point afterwards.

Moving mode setting into the kernel

sylware — 2007-01-23T15:23:24+00:00

As far as I know, there is no randr equivalent model in opengl (even opengl egl).
If they target opengl only, the khronos group (the guys which are now defining opengl) have to improve the opengl APIs in order to include at least the services randr provides.
If the opengl APIs stay out of the randr addressed issues and xorg folks still pushes hard towards opengl, we will end with a xorg server reduced to only opengl/glx and randr.

LCA: Updates on the X Window System

sylware — 2007-01-23T14:43:00+00:00

BTW, why "CRTC"? In randr 1.2, "CRTC"s are not really dealing only with Cathod Ray Tubes. Maybe a more appropriate name should be chosen since you have control over the API. I do realize it's a rather super minor detail.

Does this explain TV-Out configuration?

daenzer — 2007-01-23T14:06:58+00:00

Possibly, although some TV encoders can convert more or less arbitrary input signals.

Does this explain TV-Out configuration?

rankincj — 2007-01-23T13:44:09+00:00

Is this why the TV-Out instructions on my old G400 MAX and Radeon 9200 video cards say that the monitor will be driven at the same frequency as the TV, and so anyone intending to use a PAL TV should be sure that the monitor is happy running at 50 Hz? This is one restriction I would really like to avoid!

CRTCs vs. outputs

daenzer — 2007-01-23T13:25:02+00:00

There's some confusion between CRTCs and outputs. A CRTC scans out the pixel data from memory and converts it into a serial signal. Several outputs can pick up this signal, process it, and send it to an output device. But they can't display anything the CRTC didn't scan out in the first place, so the number of independent viewports is essentially limited by the number of CRTCs, not outputs. Most current popular GPUs (such as that in Keith's laptop) have two CRTCs.

Nice article though.

LCA: Updates on the X Window System

liljencrantz — 2007-01-23T11:22:43+00:00

Could somebody who is involved with X.org comment on the claims made by Luc Verhaegen in his <a href="http://libv.livejournal.com/13685.html">blog</a>? Basically, he's saying that a lot of the shiny newness like modesetting in RandR 1.2 was first implemented by him, that Keith Packard told him is was impossible, and that once he proved otherwise Keith picked up his work but is failing to give credit where credit is due.

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.

LCA: Updates on the X Window System

bronson — 2007-01-23T07:56:02+00:00

It also means -- and this is a biggie -- that you don't need to maintain forward/backward compatibility (no ABIs or APIs to maintain). If there's a change you want to make, you just MAKE it. Add RCU? No problem. It's wonderful.

This is why there's so little cruft in the Linux source tree (or, more accurately, the little cruft that's there is baked in so hard that it takes major surgery to get it out). This is quite unlike the Windows DDK which has grown into a massive hairy monster as Microsoft was forced to ensure that old drivers and new drivers alike could call into the same API.

I really hope the X devs choose to use the kernel model. Otherwise they're likely to get bogged down in API management and development will be slower than it should be.

LCA: Updates on the X Window System

Thalience — 2007-01-23T06:54:05+00:00

I believe that refers to managing/releasing the core server and graphics drivers as one source tree, as is done with Linux; not to the separate idea of using an OpenGL-based DDX and pushing all hardware access to the kernel.

Keeping the drivers in the same tree with the rest of the kernel helps to keep the drivers from growing their own private implementations of various utility code.

LCA: Updates on the X Window System

keithp — 2007-01-23T06:51:27+00:00

Intel chips have some outputs built-in and rely on external chips for other outputs. G965 has only VGA built-in, and relies on SDVO for DVI and TV-out. Mobile chips (915GM, 945GM) have built-in LVDS and TV out as well, so there's no external chip driver needed for most operations.

The Intel driver has relied for far too long on BIOS-based modesetting, and after I joined Intel, replacing that became our highest priority. While initial support for LVDS and VGA was running early last year, getting the remaining outputs working correctly has taken a long time. Of course, all of that would have been a lot easier if we hadn't also been working on RandR 1.2 at the same time.

LCA: Updates on the X Window System

proski — 2007-01-23T02:11:36+00:00

I don't think you have tried to compile the driver from git. With the new Autoconf/Automake configuration, it's pretty easy. You can even run "make distcheck" to make the tarball. I've seen released versions of software that were much harder to compile and that failed "make distcheck".

It's quite offensive for developers if their software is judged by experience with other software.