James Ausmus <james.aus...@gmail.com> posted b79f23070906171116v24babcedh47c1c9b5fca39...@mail.gmail.com, excerpted below, on Wed, 17 Jun 2009 11:16:50 -0700:
> Just as a note - the Radeon KMS uses a different implementation path > than the Intel KMS - Intel, in the kernel, uses GEM for gfx memory > management, while Radeon (and Nouveau, and other upcoming) use the new > TTM (which is also new for .31) - I don't *think* this will affect how X > interfaces with the kernel driver, but, since TTM is newer than GEM > (GEM/Intel KMS happened in .29), it might still be a little bit before > the wrinkles are worked out. As Sebastian Redi indicated, TTM is actually older. FWIW, from my viewpoint at least, it looks a bit like "NIH syndrome" (not invented here syndrome) from the Intel guys. Whatever. They didn't like TTM as it was already being implemented for Radeon and some of the other drivers (Nouveau, etc) and came up with their own thing, GEM, which works particularly well with the Intel hardware implementation but not quite as well with other implementations. But for various reasons Intel's GEM hit the mainline kernel first. Meanwhile, the TTM folks continued what they were doing, and now it's hitting mainline, but using the GEM interface (as SR again mentioned). It's all a bit confusing, even for those such as myself who follow Linux developments reasonably closely and have been reading pretty much anything they see on it. > As far as the X server interfacing with the > new kernel driver, I *believe* that pretty much all the action behind > the scenes happens in the X driver itself, with the X server being > pretty much unaware of the change (please feel free to correct me if I'm > wrong), so, just because the Intel driver has already been utilizing the > KMS kernel interface for a little while, doesn't necessarily mean that > it will make the Radeon X driver transition any smoother/better/shorter. Well, it's some of both, actually. xorg-server has to support it, but so does the X driver, which with KMS ultimately becomes as I mentioned earlier, not a lot more than a wrapper around the kernel code, with xorg- server in turn interfacing with the wrapper. But since it'll be awhile before it can be assumed that the kernel has KMS drivers on its side, the driver will remain more than a wrapper for awhile, but disable most of itself and only act as a wrapper when KMS is turned on. In addition to that, the first one is /always/ the hardest, and now that it is done, the rest will come easier. So while you are indeed correct that there's some implementation details in the X driver that the Intel driver doesn't help with directly for others (particularly since it went its own way, implementing GEM directly, instead of the GEM interface to TTM that the others are using), that's only one piece of the puzzle. With many of the other pieces, having the first one, Intel, in place and working out the general issues and testing the general idea, means the others have it MUCH easier. >>> 4) Shows up in portage under ~amd64 (Is that the same as ~arch for >>> AMD64?) >>> >> ~arch means the same regardless of architecture ;) It's "~x86" for >> IBM/Intel 32-bit systems, ~amd64 for AMD64, ~ppc for PowerPCs, etc. Exactly. ~arch is simply the generic term, while ~amd64 would be the specific version the readers of this list will be concerned with. > Dunno - X server 1.6 has been out for quite a while (several months - X > server 1.7 is due out in just about 1.5 months at this point), and it > just very recently hit the portage ~ tree (not that I'm complaining Devs > - I understand that there were issues that would've bit lots of users), > so it might be a while before you see Radeon KMS support in the fully > stable portage tree - don't hold your breath quite yet. ;) Of course, if > your system isn't mission-critical, you could always install the -9999 > versions, or at least the ~ versions when they hit, and help move along > the debugging/stabilization process, so that they hit the stable tree > faster... ;) That's my take on it too. Hopefully it won't be 2 years before stable, but it could well be 18 months, and will almost certainly be at /least/ 9 months for Radeon, 6 months for Intel, and a year for others. It's a big change and for Intel users so far, has been /anything/ but smooth. > Having run the Intel KMS kernel/fbcon/X driver for a little while now, I > can say that 2 things *really* stand out to me (at least from my usage > model): > > 1. Native framebuffer console resolution on my 1680x1050 widescreen LCD > - no more 1280x1024 stretched! (Actually not sure if this is directly > due to the kernel updates for Intel/KMS, or just happened to happen at > the same time, but still - Yay!) Well, the radeonfb drivers have existed in the kernel for years, so for older radeon users at least, they've had the possibility of full/native resolution framebuffer for some time. And for those without a specific native hardware fb, there was always vesafb. But you are correct in how nice that extra resolution can be. Before I ran the framebuffer, I ran normal vgacon, but at the highest resolution I could figure out how to get, and with a small font (4x6 IIRC), so I did get a reasonable display (132x50 chars or some such). However, framebuffer was even better, 1600x1200 resolution on my old CRTs, 1920x1200 on the new LCDs, now 240x75 chars with the larger standard font (8x16). But regular framebuffer still isn't KMS, lacking the other features mentioned. > 2. Perfectly fast X/virtual console switching - I mean - Wow! I still, > from time to time, just sit there switching between the two a couple > times just to watch the speed and smoothness - it's amazing... Now /that's/ what I'm looking forward to! Well, that and the security of not having to run X as root. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
