LCA: Updates on the X Window System
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.
Index entries for this article | |
---|---|
Conference | linux.conf.au/2007 |
(Log in to post comments)
LCA: Updates on the X Window System
Posted Jan 22, 2007 21:11 UTC (Mon) by furlongm (subscriber, #34572) [Link]
Here is a vid of the talk Keith gave at aKademy 2006 about Multi head RandR -> Multi-Head RandR - Keith Packard
LCA: Updates on the X Window System
Posted Jan 22, 2007 21:24 UTC (Mon) by AndyBurns (guest, #27521) [Link]
The video from LCA2007http://mirror.linux.org.au/pub/linux.conf.au/2007/video/m...
LCA: Updates on the X Window System
Posted Feb 12, 2007 9:56 UTC (Mon) by csamuel (✭ supporter ✭, #2624) [Link]
I think you meant here:
http://mirror.linux.org.au/pub/linux.conf.au/2007/video/m...
:-)
LCA: Updates on the X Window System
Posted Feb 12, 2007 20:15 UTC (Mon) by AndyBurns (guest, #27521) [Link]
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
Posted Feb 13, 2007 10:25 UTC (Tue) by csamuel (✭ supporter ✭, #2624) [Link]
That would be my guess, it may be they recorded the time the sessionbegan incorrectly.
Moving mode setting into the kernel
Posted Jan 22, 2007 22:01 UTC (Mon) by nix (subscriber, #2304) [Link]
Surely there must be a fallback mode-setting implementation which works inuserspace? Otherwise the portability of the X server to non-Linux systems
(and older Linux systems too) will go *way* down :/
Moving mode setting into the kernel
Posted Jan 22, 2007 22:12 UTC (Mon) by bronson (subscriber, #4806) [Link]
Those other systems can take the jettisoned code and set up a modesetting shim between their kernel and X. That would be more desirable than letting all the hardware-specific junk continue to live inside the X server, wouldn't it?
Moving mode setting into the kernel
Posted Jan 22, 2007 22:58 UTC (Mon) by drag (guest, #31333) [Link]
Well the utopian viewpoint in this is that X should have absolutely nothing to do with the hardware.
That their should be a standardized API that the OS should have that will allow X to run well. OSes then are free to impliment that in any manner that they want to.
That is one of the reasons they are targetting OpenGL.
OpenGL is able to provide most of the low-level things that X needs, as well as provide plenty of extra capabilities that will be required by applications now and into the future.
The only major problem with it is that it doesn't have a standard for having ways for a application to control aspects of the display that X needs to have to do things like the RandR stuff.
Assuming that gets sorted out (and it should) then X becoming a pure OpenGL means that it becomes just another application that a OS can handle in any manner that that OS see fits. Usermode drivers, kernelmode drivers, software mesa, etc etc. Whatever works best for that system design.
Right now it's 'You use X's drivers to access harwdare or you won't use X at all'. It's a very non-portable way to be portable, it seems like to me.
Moving mode setting into the kernel
Posted Jan 23, 2007 15:23 UTC (Tue) by sylware (guest, #35259) [Link]
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.
Moving mode setting into the kernel
Posted Jan 23, 2007 15:37 UTC (Tue) by k8to (guest, #15413) [Link]
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
Posted Feb 1, 2007 14:50 UTC (Thu) by Janne (guest, #40891) [Link]
"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
Posted Jan 22, 2007 23:28 UTC (Mon) by jwb (guest, #15467) [Link]
It's an entertaining fiction to say that Intel will have drivers as soon as their hardware is released, but the reality is somewhat different. I purchased an Intel G965 motherboard with integrated graphics and to this day it is still not possible for it to use my monitor's 1920x1200 native mode. Oh, sure, if I use git to checkout the modesetting branch of the Intel driver as well as the randr-randr-randr-1.2-exa-randr-ramalamadingdong branch of the xorg core I might get something working. But is there a released version for people without infinite free time? Sadly, no.
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.
LCA: Updates on the X Window System
Posted Jan 23, 2007 0:06 UTC (Tue) by vmlinuz (guest, #24) [Link]
Keith did specifically mention the whole modesetting mess, and that it was one of the very few things where there were IP issues in fixing it. Seriously - go watch his talk - I was there and I'm about to rewatch it because it was so interesting...
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.
Also worth noting that xorg are stuck in a slight release blockage at the moment - 7.2 should have been out about a month ago, but is still pending. That, in turn, is slightly messing up the release of some more interesting stuff.
LCA: Updates on the X Window System
Posted Jan 23, 2007 15:54 UTC (Tue) by vmole (guest, #111) [Link]
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
Posted Jan 24, 2007 15:26 UTC (Wed) by drag (guest, #31333) [Link]
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
Posted Jan 23, 2007 0:16 UTC (Tue) by neilbrown (subscriber, #359) [Link]
The current Intel driver uses the Video BIOS to get mode settings. If your Video bios has bad information, then X will have trouble setting the mode properly.
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.
LCA: Updates on the X Window System
Posted Jan 23, 2007 0:20 UTC (Tue) by jwb (guest, #15467) [Link]
Of course it's Intel's fault. My motherboard is made by Intel, my graphics are made by Intel, I download my BIOS from Intel's site, and Intel's name and logo are all over the place. They can hardly claim that the BIOS implementation is out of their hands.
Also, 915resolution doesn't work on the G965.
LCA: Updates on the X Window System
Posted Jan 23, 2007 1:32 UTC (Tue) by drag (guest, #31333) [Link]
Ya.. it's definately Intel's problem.
Their hardware, their design, their vbios. Other manufacturers just use what they get from Intel.
LCA: Updates on the X Window System
Posted Jan 23, 2007 1:48 UTC (Tue) by neilbrown (subscriber, #359) [Link]
My understanding from Keith's talk at LCA is that the Intel graphics chipdoesn't actually control mode setting at all. It somehow leaves that for
some other glue chip that the motherboard manufacturer needs to provide.
(Apparently this is similar to the AC97 sound architecture where the
analogue bits were not in the Intel chipset, only the digital bits).
The interface to these mode-setting glue chips is not standardised
so everybody does it differently. So for Xorg to be able to do
mode setting, it with has to know about how all the different glue
chips work (Which is what the new mode-setting branch of the driver tries)
or it needs help from the VBIOS (which is what the 'stable' branch does).
So maybe it is Intel's fault for not standardising the interface properly,
and very likely it is Intel's fault if you have an Intel motherboard, but
the situation doesn't seem to be as straight forward as one might like it to be.
LCA: Updates on the X Window System
Posted Jan 23, 2007 6:51 UTC (Tue) by keithp (subscriber, #5140) [Link]
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
Posted Jan 23, 2007 14:43 UTC (Tue) by sylware (guest, #35259) [Link]
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.
LCA: Updates on the X Window System
Posted Jan 23, 2007 15:51 UTC (Tue) by jzbiciak (guest, #5246) [Link]
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
Posted Jan 23, 2007 18:02 UTC (Tue) by bronson (subscriber, #4806) [Link]
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? :)
LCA: Updates on the X Window System
Posted Jan 23, 2007 23:51 UTC (Tue) by gdt (subscriber, #6284) [Link]
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).
LCA: Updates on the X Window System
Posted Jan 25, 2007 19:23 UTC (Thu) by kamil (subscriber, #3802) [Link]
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
Posted Jan 23, 2007 0:42 UTC (Tue) by wilreichert (guest, #17680) [Link]
You really just need the modesetting branch of their driver, randr 1.2 isn't necessary.
LCA: Updates on the X Window System
Posted Jan 23, 2007 1:20 UTC (Tue) by jwb (guest, #15467) [Link]
So you claim:
git checkout modesetting && ./autogen.sh && make
../i830_xf86Crtc.h:261: error: expected declaration specifiers or '...' before 'RRPropertyValuePtr'
The missing symbol is from RandR 1.2. So, again, more than five months after Intel announced a "free software graphics drivers for Intel i965 chipset" and more than 21 years after the introduction of the multisync monitor, people without infinite free time still do not have access to a G965 driver that can perform the simple function of programming the video mode.
LCA: Updates on the X Window System
Posted Jan 23, 2007 1:50 UTC (Tue) by wilreichert (guest, #17680) [Link]
Odd, I'm running libXrandr 1.1.2 and it compiles & runs just fine. No RRPropertyValuePtr in randrstr.h either. Sure Intel may have hyped their OSS support a bit, but what are the alternatives? I'll pass on waiting for nvidia or ati to release driver update because some ABI got changed.
LCA: Updates on the X Window System
Posted Jan 24, 2007 0:33 UTC (Wed) by proski (subscriber, #104) [Link]
It was fixed today.
LCA: Updates on the X Window System
Posted Jan 24, 2007 1:28 UTC (Wed) by jwb (guest, #15467) [Link]
Aren't you the same person who accused me of lying earlier in this discussion?
LCA: Updates on the X Window System
Posted Jan 31, 2007 2:02 UTC (Wed) by proski (subscriber, #104) [Link]
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
Posted Jan 23, 2007 2:11 UTC (Tue) by proski (subscriber, #104) [Link]
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.
LCA: Updates on the X Window System
Posted Jan 23, 2007 15:43 UTC (Tue) by k8to (guest, #15413) [Link]
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.
LCA: Updates on the X Window System
Posted Feb 9, 2007 12:18 UTC (Fri) by k8to (guest, #15413) [Link]
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
Posted Jan 23, 2007 0:41 UTC (Tue) by scottt (guest, #5028) [Link]
> Keith now thinks that the Linux kernel developers got it right by keeping drivers inside the kernel.
Sun microsystems would probably not like this change.
LCA: Updates on the X Window System
Posted Jan 23, 2007 6:54 UTC (Tue) by Thalience (subscriber, #4217) [Link]
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
Posted Jan 23, 2007 7:56 UTC (Tue) by bronson (subscriber, #4806) [Link]
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
Posted Jan 23, 2007 11:22 UTC (Tue) by liljencrantz (guest, #28458) [Link]
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
Posted Jan 23, 2007 18:17 UTC (Tue) by i3839 (guest, #31386) [Link]
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
Posted Feb 12, 2007 21:56 UTC (Mon) by jospoortvliet (guest, #33164) [Link]
Well, if many of these things are his idea, it should be acknowledged. Onthe 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...
CRTCs vs. outputs
Posted Jan 23, 2007 13:25 UTC (Tue) by daenzer (subscriber, #7050) [Link]
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.
Does this explain TV-Out configuration?
Posted Jan 23, 2007 13:44 UTC (Tue) by rankincj (subscriber, #4865) [Link]
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!
Does this explain TV-Out configuration?
Posted Jan 23, 2007 14:06 UTC (Tue) by daenzer (subscriber, #7050) [Link]
Possibly, although some TV encoders can convert more or less arbitrary input signals.
Does this explain TV-Out configuration?
Posted Jan 23, 2007 15:58 UTC (Tue) by jzbiciak (guest, #5246) [Link]
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.
Too late? I hope not.
Posted Jan 23, 2007 16:49 UTC (Tue) by sbishop (guest, #33061) [Link]
This talk about X development picking up speed reminds me of theannouncement 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.
Too late? I hope not.
Posted Jan 23, 2007 18:42 UTC (Tue) by nim-nim (guest, #34454) [Link]
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
Too late? I hope not.
Posted Jan 23, 2007 20:50 UTC (Tue) by k8to (guest, #15413) [Link]
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.
Posted Jan 23, 2007 21:55 UTC (Tue) by nim-nim (guest, #34454) [Link]
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)
LCA: Updates on the X Window System
Posted Jan 26, 2007 2:23 UTC (Fri) by pimlott (guest, #1535) [Link]
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
Posted Jan 26, 2007 6:03 UTC (Fri) by bronson (subscriber, #4806) [Link]
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
Posted Jan 26, 2007 17:07 UTC (Fri) by pimlott (guest, #1535) [Link]
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
Posted Jan 26, 2007 18:46 UTC (Fri) by bronson (subscriber, #4806) [Link]
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
Posted Jan 26, 2007 15:33 UTC (Fri) by ortalo (guest, #4654) [Link]
"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
Posted Jan 26, 2007 18:34 UTC (Fri) by bronson (subscriber, #4806) [Link]
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
Posted Feb 1, 2007 20:33 UTC (Thu) by Thalience (subscriber, #4217) [Link]
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.