Making Xorg easier to test (was Re: [git pull] drm request 3)
in [Kernel]
|
Prev: [PATCH 1/1] gitignore: do not ignore include/linux/
Next: [PATCH 0/3] ramzswap: Eliminate stale data in compressed memory
From: Daniel Stone on 5 Mar 2010 11:20 Hi, On Fri, Mar 05, 2010 at 07:53:46AM -0800, Linus Torvalds wrote: > These days, there's a few dependencies you need to know about (I do agree > that from a user perspective the thing might have been made a bit _too_ > modular) Indeed, no argument here. > That said, the _one_ thing I really wish could be done would be to make it > easier to install things side-by-side - and with the modularization, you > really do want to do it module-by-module. One of the things that makes it > so easy to test the kernel is that when you install one kernel, that > doesn't affect the others, and you can go back-and-forth in testing. > That's really important, because it makes testing trivial and non-scary > even in the presense of issues that makes the new version unusable. FWIW, Option "ModulePath" in xorg.conf lets you more or less do this; the usual approach is to install your new server + drivers into a separate prefix. Cheers, Daniel
From: Jesse Barnes on 5 Mar 2010 11:30 On Fri, 5 Mar 2010 07:53:46 -0800 (PST) Linus Torvalds <torvalds(a)linux-foundation.org> wrote: > > > On Fri, 5 Mar 2010, Carlos R. Mafra wrote: > > > > Whereas everytime I wanted to do that with Xorg it was such a pain that > > I want to keep away from that mess. > > Actually, take it from me: Xorg is _pleasant_ to test these days. > > Ok, so that's partly compared to the mess it _used_ to be, but it's really > night and day. The whole build system was so incredibly baroque and heavy > that you really had to understand it deeply if you wanted to do anything > fancy. > > And the non-fancy alternative was to just build the whole thing, which > took _hours_ even on fast machines because the build system overhead was > near-infinite (I dunno, maybe parallel builds could be made to work, but > it took more brain-power than I could ever put into it). > > These days, there's a few dependencies you need to know about (I do agree > that from a user perspective the thing might have been made a bit _too_ > modular) but they are generally fairly trivial, and there are scripts to > download all the drivers and misc utilities needed. Just FYI for those following this thread; testing the server and 3D drivers really isn't too much trouble these days, you can even install everything into a separate path (I usually choose /opt-gfx-test); you just need to build libdrm, mesa, xserver and your video driver (along with an input driver or tw) in that order. Then just startx -- /opt/gfx-test/bin/Xorg and put something reasonable in .xinitrc. Full instructions at http://wiki.x.org/wiki/Development/BuildingX. -- Jesse Barnes, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 5 Mar 2010 11:40 On Fri, 5 Mar 2010, Daniel Stone wrote: > > FWIW, Option "ModulePath" in xorg.conf lets you more or less do this; > the usual approach is to install your new server + drivers into a > separate prefix. The thing is, Xorg has - and I think for _very_ good reasons - deprecated using xorg.conf at all. So most people don't even have one (I certainly don't), and wouldn't know how to create one in the first place. And yeah, I used to happily edit timing lines and make up non-standard modes for my monitor, but I have to admit that I never _ever_ want to touch that file ever again. Last time I tried to, it was to set DPI to be something sane, but these days X gets even that right automatically, and no longer does the insane "set DPY by size of the screen" thing any more. And I think all of the reasons xorg.conf is basically being deprecated are valid for this case too. Switching between kernels is - in this case, due to the whole API change - effectively the same as switching the graphics card in the machine, but without even the ability to _name_ the cards and share a xorg.conf for the two cases (not that I think that you could do different ModulePath's per display anyway). So yeah, you could "switch between kernels, start out in init 3, edit xorg.conf appropriately, switch to init 5", but once you start doing that, you might as well just switch a symlink around instead - it's easier. So I don't think xorg.conf is a help. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Daniel Stone on 8 Mar 2010 04:20
On Fri, Mar 05, 2010 at 08:30:38AM -0800, Linus Torvalds wrote: > On Fri, 5 Mar 2010, Daniel Stone wrote: > > FWIW, Option "ModulePath" in xorg.conf lets you more or less do this; > > the usual approach is to install your new server + drivers into a > > separate prefix. > > The thing is, Xorg has - and I think for _very_ good reasons - deprecated > using xorg.conf at all. So most people don't even have one (I certainly > don't), and wouldn't know how to create one in the first place. Most people don't know how to bisect the kernel, either. :) xorg.conf hasn't at all been deprecated, beyond autoconf and xorg.conf.d. The goal was to ensure that no-one needed an xorg.conf _by default_, which I can quite safely say we've since achieved, but xorg.conf(.d) remains as the way to tell the server your non-default requirements. Anyway, badly OT here, so. Cheers, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |