Re: Making Xorg easier to test (was Re: [git pull] drm request 3)
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 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Making Xorg easier to test (was Re: [git pull] drm request 3)
On Fri 5.Mar'10 at 8:44:07 +0100, Ingo Molnar wrote: Yeah. I've seen a few other bad arguments as well: 'exploding test matrix' This is often the result of _another_ bad technical decision: over-modularization. Xorg, mesa/libdrm and the kernel DRM drivers pretty share this signature: I agree 100% with this! I test the kernel often (running 2.6.33-05070-g64ba992 ATM) because it is _easy_ for me. Every morning I simply do a 'git pull' + compile + install and I am ready to test the bleeding edge kernel. And everytime I complained about something breaking it got fixed. Really, testing the linux kernel is a hobby for me because it is easy. Whereas everytime I wanted to do that with Xorg it was such a pain that I want to keep away from that mess. - it's developed by the same tightly knit developer base who often cross between these packages. Features often need changes in each component. - a developer to be able to do real work has to have the latest sources of all these components. - a user just uses whatever horizontal version cut the distro did and never truly 'mixes' these components as a conscious decision. True! Why can't there be a 'Linus Torvalds' for Xorg accepting patches from various maintainers and keeping the whole thing tied up? Why can't it mimic the 'make menuconfig' way of selecting what to compile to have the guarantee that the whole thing will simply work nicely together? If this could be done for the kernel (which from my user POV seems much more complicated), I guess it could be done with Xorg. And Linux would have more Xorg testers and be better as a whole. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Making Xorg easier to test (was Re: [git pull] drm request 3)
On Fri, 05 Mar 2010 11:00:30 +0100, Carlos R. Mafra said: Why can't there be a 'Linus Torvalds' for Xorg accepting patches from various maintainers and keeping the whole thing tied up? Why can't it mimic the 'make menuconfig' way of selecting what to compile to have the guarantee that the whole thing will simply work nicely together? Feel free to do so. Note that you'll hit 2 problems: 1) In the kernel, the sysadmin can almost always get away with saying I have no XYZ devices or I only have ext4 filesystems or similar choices, and have the resulting kernel still support basically all the syscalls (unless you start going into CONFIG_EMBEDDED and doing some *major* surgury). Over on the X side of the fence, there aren't as many options that don't involve dropping major chunks of the functionality. You *sure* that nothing on your system depends on the XRandR extension? ;) 2) Lately, the X server is *already* highly modular and different components built from different source trees. Note that the base X server is only about half the size of the kernel RPM - there really isn't much left to trim out of the base server anymore. ncftp ...velopment/source/SRPMS dir kern* xorg* -rw-r--r--1 263 263 66965350 Feb 26 18:03 kernel-2.6.34-0.4.rc0.git2.fc14.src.rpm -rw-r--r--1 263 26344300 Feb 27 01:39 xorg-sgml-doctools-1.1.1-4.fc12.src.rpm -rw-r--r--2 263 263 2229508 Feb 11 02:23 xorg-x11-apps-7.4-10.fc13.src.rpm -rw-r--r--1 263 263 8250097 Feb 27 00:06 xorg-x11-docs-1.3-6.fc12.src.rpm -rw-r--r--1 263 263 9718 Feb 27 03:27 xorg-x11-drivers-7.3-13.fc12.src.rpm -rw-r--r--2 263 263 263291 Feb 5 21:40 xorg-x11-drv-acecad-1.4.0-3.fc13.src.rpm -rw-r--r--2 263 263 271426 Feb 5 23:03 xorg-x11-drv-aiptek-1.3.0-3.fc13.src.rpm -rw-r--r--1 263 263 293991 Feb 27 01:02 xorg-x11-drv-apm-1.2.2-1.fc12.src.rpm -rw-r--r--2 263 263 247603 Feb 5 19:49 xorg-x11-drv-ark-0.7.2-2.fc13.src.rpm -rw-r--r--1 263 263 273849 Feb 26 20:22 xorg-x11-drv-ast-0.89.9-1.fc12.src.rpm -rw-r--r--1 263 263 475771 Feb 19 00:50 xorg-x11-drv-ati-6.13.0-0.23.20100219gite68d3a389.fc14.src.rpm -rw-r--r--1 263 263 354400 Feb 27 01:17 xorg-x11-drv-chips-1.2.2-1.fc12.src.rpm -rw-r--r--2 263 263 296790 Feb 5 16:10 xorg-x11-drv-cirrus-1.3.2-2.fc13.src.rpm -rw-r--r--2 263 263 257700 Feb 5 19:48 xorg-x11-drv-dummy-0.3.3-2.fc13.src.rpm -rw-r--r--2 263 263 260227 Feb 5 16:26 xorg-x11-drv-elographics-1.2.3-6.fc13.src.rpm -rw-r--r--2 263 263 537577 Feb 5 21:59 xorg-x11-drv-evdev-2.3.99-2.20100108.fc13.src.rpm -rw-r--r--2 263 263 254313 Feb 9 13:19 xorg-x11-drv-fbdev-0.4.1-3.fc13.src.rpm -rw-r--r--1 263 263 252387 Feb 17 05:13 xorg-x11-drv-fpit-1.3.0-8.fc14.src.rpm -rw-r--r--2 263 263 608480 Feb 5 23:07 xorg-x11-drv-geode-2.11.4.1-2.fc13.src.rpm -rw-r--r--2 263 263 361698 Feb 5 21:40 xorg-x11-drv-glint-1.2.4-2.fc13.src.rpm -rw-r--r--2 263 263 244962 Feb 9 13:48 xorg-x11-drv-hyperpen-1.3.0-4.fc13.src.rpm -rw-r--r--2 263 263 289677 Feb 5 22:38 xorg-x11-drv-i128-1.3.3-2.fc13.src.rpm -rw-r--r--2 263 263 281904 Feb 5 20:33 xorg-x11-drv-i740-1.3.2-2.fc13.src.rpm -rw-r--r--1 263 263 978993 Feb 12 07:15 xorg-x11-drv-intel-2.10.0-4.fc13.src.rpm -rw-r--r--2 263 263 305926 Feb 5 19:26 xorg-x11-drv-ivtv-1.1.1-1.fc13.src.rpm -rw-r--r--2 263 263 296974 Feb 5 19:22 xorg-x11-drv-keyboard-1.4.0-4.fc13.src.rpm -rw-r--r--2 263 263 492204 Feb 5 20:02 xorg-x11-drv-mach64-6.8.2-2.fc13.src.rpm -rw-r--r--2 263 263 427579 Feb 5 20:39 xorg-x11-drv-mga-1.4.11-2.fc13.src.rpm -rw-r--r--2 263 263 318263 Feb 9 13:52 xorg-x11-drv-mouse-1.5.0-4.fc13.src.rpm -rw-r--r--2 263 263 254590 Feb 5 20:17 xorg-x11-drv-mutouch-1.2.1-6.fc13.src.rpm -rw-r--r--2 263 263 290495 Feb 5 22:02 xorg-x11-drv-neomagic-1.2.4-3.fc13.src.rpm -rw-r--r--2 263 26391334 Feb 18 16:59 xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.src.rpm -rw-r--r--2 263 263 449803 Feb 9 12:19 xorg-x11-drv-nv-2.1.15-5.fc13.src.rpm -rw-r--r--2 263 263 475028 Feb 9 12:26 xorg-x11-drv-openchrome-0.2.904-2.fc13.src.rpm -rw-r--r--2 263 263 248668 Feb 9 12:27 xorg-x11-drv-penmount-1.4.0-6.fc13.src.rpm -rw-r--r--2 263 263 280184 Feb 5 22:08 xorg-x11-drv-qxl-0.0.9-0.1.fc13.src.rpm -rw-r--r--2 263 263 424771 Feb 5 19:36 xorg-x11-drv-r128-6.8.1-3.fc13.src.rpm -rw-r--r--2 263 263
Re: Making Xorg easier to test (was Re: [git pull] drm request 3)
On Fri, Mar 5, 2010 at 5:00 AM, Carlos R. Mafra crmaf...@gmail.com wrote: Why can't there be a 'Linus Torvalds' for Xorg accepting patches from various maintainers and keeping the whole thing tied up? Why can't it mimic the 'make menuconfig' way of selecting what to compile to have the guarantee that the whole thing will simply work nicely together? You must not follow X development at all. His name is Keith Packard. Matt Turner -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Making Xorg easier to test (was Re: [git pull] drm request 3)
On Fri, Mar 05, 2010 at 10:22:27AM -0500, Matt Turner wrote: On Fri, Mar 5, 2010 at 5:00 AM, Carlos R. Mafra crmaf...@gmail.com wrote: Why can't there be a 'Linus Torvalds' for Xorg accepting patches from various maintainers and keeping the whole thing tied up? Why can't it mimic the 'make menuconfig' way of selecting what to compile to have the guarantee that the whole thing will simply work nicely together? You must not follow X development at all. His name is Keith Packard. Except that if you look at X lately, you'll realise that we do not have the resources to even come close to being able to do this properly. We struggle to support what we have already today, and we've still been hoping to create a real API, instead of the sad joke that is /usr/include/xorg/*.h, for the last few years. But we don't have enough people (or at least enough people who aren't busy with the other parts of their day jobs, or kids, or burnout, or whatever) to do it. I understand that you guys are upset about this, so maybe you'd like to donate, say, 10% of your developer base to help out? That'd be pretty ace. Cheers, Daniel pgpB62OHx1v5N.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Making Xorg easier to test
From: Daniel Stone dan...@fooishbar.org Date: Fri, 5 Mar 2010 17:41:43 +0200 I understand that you guys are upset about this, so maybe you'd like to donate, say, 10% of your developer base to help out? That'd be pretty ace. You have to support less than %10 of the amount of hardware we have to support. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Making Xorg easier to test (was Re: [git pull] drm request 3)
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. And the modularization often works: you can often (but by no means always; it does require that the other parts are close enough and that there haven't been any major changes) just have the source code to the one driver you care about, and recompile and install just that _single_ driver. I've done it. It's becautiful when it works. And it's a major pain when you notice it didn't work, and you needed to get the whole server and libdrm trees after all, and now you're not replacing single files any more and have little idea what it will stomp on in your distro. So it really is very convenient when it works. And X doesn't have thousands of drivers like the kernel (maybe 10-15 that people care about at all, and about three or four that actually really matter), and there are seldom huge changes that affect them all, so the modularization doesn't turn totally crazy. So I can see where the Xorg people really like their new modular world. It does work, it's _sooo_ much better than the mess it used to be, and the problems are fairly manageable when they do happen. The modular approach really works very well when there aren't lots of interactions between the modules, and when the modules are few enough that it isn't a total disaster (imagine doing a change that requires changes to all drivers in Xorg, vs doing a change that requires changes to all drivers in the kernel - the modular approach simply wouldn't work for the latter case, because you'd spend all your time just chasing down external users). 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. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Making Xorg easier to test
On Fri, 05 Mar 2010 07:49:32 -0800 (PST) David Miller da...@davemloft.net wrote: From: Daniel Stone dan...@fooishbar.org Date: Fri, 5 Mar 2010 17:41:43 +0200 I understand that you guys are upset about this, so maybe you'd like to donate, say, 10% of your developer base to help out? That'd be pretty ace. You have to support less than %10 of the amount of hardware we have to support. If we believe the changelogs including X.org userspace then they also have a good deal less than 10% of the contributors. Alan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Making Xorg easier to test
On Fri, Mar 05, 2010 at 07:49:32AM -0800, David Miller wrote: From: Daniel Stone dan...@fooishbar.org I understand that you guys are upset about this, so maybe you'd like to donate, say, 10% of your developer base to help out? That'd be pretty ace. You have to support less than %10 of the amount of hardware we have to support. With a great deal less than 10% of the number of developers. pgpdiV1fa8kSW.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Making Xorg easier to test (was Re: [git pull] drm request 3)
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 pgpnHb05h5vaf.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Making Xorg easier to test (was Re: [git pull] drm request 3)
On Fri, 5 Mar 2010 07:53:46 -0800 (PST) Linus Torvalds torva...@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 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Making Xorg easier to test (was Re: [git pull] drm request 3)
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 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Making Xorg easier to test
From: Xavier Bestel xavier.bes...@free.fr Date: Fri, 05 Mar 2010 18:50:24 +0100 On Fri, 2010-03-05 at 07:49 -0800, David Miller wrote: From: Daniel Stone dan...@fooishbar.org Date: Fri, 5 Mar 2010 17:41:43 +0200 I understand that you guys are upset about this, so maybe you'd like to donate, say, 10% of your developer base to help out? That'd be pretty ace. You have to support less than %10 of the amount of hardware we have to support. You can't compare a network card and a GPU. The latter is way more complex to code for. I wasn't talking specifically about network cards. But if you want specific examples... How about the x86 or parisc cpu, and all their derivatives, are those complex enough for you? :-) I've worked on OpenGL capable grapics card drivers of various vintages, and I honestly don't think there is anything in there more complex than what we have to deal with in the kernel. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Making Xorg easier to test
On Fri, 05 Mar 2010 09:54:06 -0800 (PST) David Miller da...@davemloft.net wrote: From: Xavier Bestel xavier.bes...@free.fr Date: Fri, 05 Mar 2010 18:50:24 +0100 On Fri, 2010-03-05 at 07:49 -0800, David Miller wrote: From: Daniel Stone dan...@fooishbar.org Date: Fri, 5 Mar 2010 17:41:43 +0200 I understand that you guys are upset about this, so maybe you'd like to donate, say, 10% of your developer base to help out? That'd be pretty ace. You have to support less than %10 of the amount of hardware we have to support. You can't compare a network card and a GPU. The latter is way more complex to code for. I wasn't talking specifically about network cards. But if you want specific examples... How about the x86 or parisc cpu, and all their derivatives, are those complex enough for you? :-) I've worked on OpenGL capable grapics card drivers of various vintages, and I honestly don't think there is anything in there more complex than what we have to deal with in the kernel. I think you must be saying this for the sake of argument. The complexity lies not in the programming interfaces exposed by the device (those indeed are complex, more so than some CPUs, less so than others). The complexity lies in the fact that those interfaces change from revision to revision, and even between boards sharing the same chip. And more than that, the interfaces exposed to applications are spread across many software components, some of which send commands to the hardware directly. The problem Linus ran into is directly related to this fact, because it involved the interfaces between a few of these components. So from that perspective, the graphics stack is the most complex one in Linux by a long shot. It's even worse than if we had STREAMS networking with a ton of different modules up in userspace messing with protocol. :) -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Making Xorg easier to test
From: Jesse Barnes jbar...@virtuousgeek.org Date: Fri, 5 Mar 2010 10:02:44 -0800 So from that perspective, the graphics stack is the most complex one in Linux by a long shot. It's even worse than if we had STREAMS networking with a ton of different modules up in userspace messing with protocol. :) Maybe :-) -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Making Xorg easier to test
On Fri, 2010-03-05 at 07:49 -0800, David Miller wrote: From: Daniel Stone dan...@fooishbar.org Date: Fri, 5 Mar 2010 17:41:43 +0200 I understand that you guys are upset about this, so maybe you'd like to donate, say, 10% of your developer base to help out? That'd be pretty ace. You have to support less than %10 of the amount of hardware we have to support. You can't compare a network card and a GPU. The latter is way more complex to code for. Xav -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
