Re: rfc/headsup: graphics driver packaging in F16+
Adam Jackson (a...@redhat.com) said: > There are two major package classes in Fedora that provide graphics > drivers: xorg-x11-drv-*, and mesa-dri-drivers-*. > > In F15, mesa-dri-drivers now only includes drivers with DRI2 support > (radeon, nvidia, intel) and the software renderer; if you want all the > older drivers you have to install mesa-dri-drivers-dri1. This list is: > > i810, mga, r128, savage, sis, tdfx, unichrome > > Basically all of this hardware is, ahem, inept. The most featureful > device supported by these drivers would be the MGA G550, which just > barely manages to do DirectX 7 (comparable to a Radeon 7000 or GeForce > 2, both ~1999 vintage). All the others are back in the DX6 stone age. > For comparison, the baseline for the GPU in the phone in your pocket - > and that platform layers like clutter more or less expect - is GLES 2.0, > which is roughly comparable to DirectX 9. We're rapidly approaching the > point where the software renderer is going to be a more satisfying > experience than hardware 3d support for these chips, both for features > and for performance. > > So in my ideal world, we would simply drop the -dri1 subpackage (and for > that matter, DRI1 support in the X server). > > For 2D we've got an xorg-x11-drivers metapackage that includes, well, > pretty much everything, and which is included in comps as a default. > This is lame, because it means a bunch of backwater drivers end up as > critical path and can never possibly get tested. (Smolt says there are > all of 3 savage users. I assume the number of i740 users is actually > negative.) The list of video drivers that see any actual use is > probably something like: > > ast, ati, cirrus, fbdev, geode, intel, mga, nouveau, openchrome, > qxl, sis/xgi, vesa, vmware > > And input is even briefer (evdev, synaptics, wacom, vmmouse). I'd like > to chop the -drivers metapackage down to just this set, and either make > a new metapackage in optional for -drivers-retrocomputing or simply list > all the drivers there individually. Note that since we're keeping > drivers for fbdev and vesa we should still get graphics on most devices > even if the user doesn't explicitly ask for a native driver. > > So that's the rough plan. Comments appreciated if I'm overlooking > anything. The question would be how we ensure that these additional drivers are in the install image, or in the installed system, if necessary. Or do we not care if they get vesa? How would users be informed/able to install drivers if necessary? (I don't know that PK search is good here.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On Tue, 2011-04-12 at 12:12 -0400, Adam Jackson wrote: > And input is even briefer (evdev, synaptics, wacom, vmmouse). I'd like > to chop the -drivers metapackage down to just this set, and either make > a new metapackage in optional for -drivers-retrocomputing or simply list > all the drivers there individually. Note that since we're keeping > drivers for fbdev and vesa we should still get graphics on most devices > even if the user doesn't explicitly ask for a native driver. > > So that's the rough plan. Comments appreciated if I'm overlooking > anything. Well, the less intrusive alternative is just to make graphics drivers a comps group rather than using a metapackage. Metapackages are generally 'frowned upon' in Fedora anyway, and you're supposed to do stuff with comps groups. Doing it that way would remove the critical path implications; we could then just add the important drivers to critpath individually. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On Tue, Apr 12, 2011 at 5:34 PM, Adam Williamson wrote: > On Tue, 2011-04-12 at 12:12 -0400, Adam Jackson wrote: > >> And input is even briefer (evdev, synaptics, wacom, vmmouse). I'd like >> to chop the -drivers metapackage down to just this set, and either make >> a new metapackage in optional for -drivers-retrocomputing or simply list >> all the drivers there individually. Note that since we're keeping >> drivers for fbdev and vesa we should still get graphics on most devices >> even if the user doesn't explicitly ask for a native driver. >> >> So that's the rough plan. Comments appreciated if I'm overlooking >> anything. > > Well, the less intrusive alternative is just to make graphics drivers a > comps group rather than using a metapackage. Metapackages are generally > 'frowned upon' in Fedora anyway, and you're supposed to do stuff with > comps groups. Doing it that way would remove the critical path > implications; we could then just add the important drivers to critpath > individually. And have the most used drivers that are listed above set as "default" and the retro ones set as optional. That way they're not there by default but they're selectable at install for the couple of people that do wish to use them (provided they do have enough RAM on those machines to actually be able to install. but that's a different problem entirely!). Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On Tue, 2011-04-12 at 09:34 -0700, Adam Williamson wrote: > On Tue, 2011-04-12 at 12:12 -0400, Adam Jackson wrote: > > > And input is even briefer (evdev, synaptics, wacom, vmmouse). I'd like > > to chop the -drivers metapackage down to just this set, and either make > > a new metapackage in optional for -drivers-retrocomputing or simply list > > all the drivers there individually. Note that since we're keeping > > drivers for fbdev and vesa we should still get graphics on most devices > > even if the user doesn't explicitly ask for a native driver. > > > > So that's the rough plan. Comments appreciated if I'm overlooking > > anything. > > Well, the less intrusive alternative is just to make graphics drivers a > comps group rather than using a metapackage. Metapackages are generally > 'frowned upon' in Fedora anyway, and you're supposed to do stuff with > comps groups. Doing it that way would remove the critical path > implications; we could then just add the important drivers to critpath > individually. Not that I object, but that's just moving the goalposts from "which drivers in the metapackage" to "which drivers in comps". It doesn't address the construction of the list. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On Tue, 2011-04-12 at 12:23 -0400, Bill Nottingham wrote: > Adam Jackson (a...@redhat.com) said: > > So that's the rough plan. Comments appreciated if I'm overlooking > > anything. > > The question would be how we ensure that these additional drivers are in the > install image, or in the installed system, if necessary. Or do we not care > if they get vesa? How would users be informed/able to install drivers if > necessary? (I don't know that PK search is good here.) To a first approximation, I deeply do not care. If you're choosing to use an s3virge in 2011 you've already decided to make your life hard. But if we're trying to be completionists about it, import the data from /usr/share/hwdata/videoaliases/*.xinf into virtual Provides for each driver package and teach packagekit or whatever how to cope. Something like this: http://lists.fedoraproject.org/pipermail/devel/2010-April/135004.html But then, if we had _that_, comps could grow a fourth class for "as-needed" and we'd just list all driver packages there, including cups and webcam drivers and etc. Install image creation would pull them all in; anaconda would filter the available as-needed's based on target hardware. In that scenario you'd still need to do manual selection of some driver packages for critpathness, but, okay. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On Tue, 2011-04-12 at 13:38 -0400, Adam Jackson wrote: > On Tue, 2011-04-12 at 12:23 -0400, Bill Nottingham wrote: > > Adam Jackson (a...@redhat.com) said: > > > So that's the rough plan. Comments appreciated if I'm overlooking > > > anything. > > > > The question would be how we ensure that these additional drivers are in the > > install image, or in the installed system, if necessary. Or do we not care > > if they get vesa? How would users be informed/able to install drivers if > > necessary? (I don't know that PK search is good here.) > > To a first approximation, I deeply do not care. If you're choosing to > use an s3virge in 2011 you've already decided to make your life hard. > > But if we're trying to be completionists about it, import the data > from /usr/share/hwdata/videoaliases/*.xinf into virtual Provides for > each driver package and teach packagekit or whatever how to cope. > Something like this: > > http://lists.fedoraproject.org/pipermail/devel/2010-April/135004.html > > But then, if we had _that_, comps could grow a fourth class for > "as-needed" and we'd just list all driver packages there, including cups > and webcam drivers and etc. Install image creation would pull them all > in; anaconda would filter the available as-needed's based on target > hardware. > > In that scenario you'd still need to do manual selection of some driver > packages for critpathness, but, okay. With this approach, you have lost a critical feature: the ability for you to change your hardware (or move the software bits to a different computer) and have everything automatically work. Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On Tue, Apr 12, 2011 at 01:48:19PM -0400, Nathaniel McCallum wrote: > > With this approach, you have lost a critical feature: the ability for > you to change your hardware (or move the software bits to a different > computer) and have everything automatically work. > > Nathaniel You lose it for a couple of strange usecases though: 1) Moving from a card that is up to date in what it supports to an older card that isn't (rare). 2) Moving from one crappy ancient card to another (plausible, but still rare). The vesa driver should mean some workable video support in either case, and from there, if we were really, truly concerned, we could detect the need for the driver and prompt to install it. That's starting to sound like the bad old days of kudzu though, and I'd be surprised if anyone really felt this was worth that effort. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On Tue, 2011-04-12 at 13:48 -0400, Nathaniel McCallum wrote: > On Tue, 2011-04-12 at 13:38 -0400, Adam Jackson wrote: > > But then, if we had _that_, comps could grow a fourth class for > > "as-needed" and we'd just list all driver packages there, including cups > > and webcam drivers and etc. Install image creation would pull them all > > in; anaconda would filter the available as-needed's based on target > > hardware. > > > > In that scenario you'd still need to do manual selection of some driver > > packages for critpathness, but, okay. > > With this approach, you have lost a critical feature: the ability for > you to change your hardware (or move the software bits to a different > computer) and have everything automatically work. Assuming pk actually had this feature, the next time you booted pk would happily tell you about what driver you're missing. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On Tue, 2011-04-12 at 13:57 -0400, Casey Dahlin wrote: > On Tue, Apr 12, 2011 at 01:48:19PM -0400, Nathaniel McCallum wrote: > > > > With this approach, you have lost a critical feature: the ability for > > you to change your hardware (or move the software bits to a different > > computer) and have everything automatically work. > > > > Nathaniel > > You lose it for a couple of strange usecases though: > > 1) Moving from a card that is up to date in what it supports to an older > card that isn't (rare). > > 2) Moving from one crappy ancient card to another (plausible, but still > rare). > > The vesa driver should mean some workable video support in either case, > and from there, if we were really, truly concerned, we could detect the > need for the driver and prompt to install it. That's starting to sound > like the bad old days of kudzu though, and I'd be surprised if anyone > really felt this was worth that effort. I think losing it in those cases is probably acceptable. My thought is that the disk space for drivers is minimal, lets just support everything (or at least the current stuff) in a single install. My concern isn't moving to and/or between rare old cards. My concern is moving from nouveau to intel or radeon... The "big" drivers should definitely be installed on every system, regardless of its hardware. Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On Tue, 2011-04-12 at 14:00 -0400, Adam Jackson wrote: > On Tue, 2011-04-12 at 13:48 -0400, Nathaniel McCallum wrote: > > On Tue, 2011-04-12 at 13:38 -0400, Adam Jackson wrote: > > > But then, if we had _that_, comps could grow a fourth class for > > > "as-needed" and we'd just list all driver packages there, including cups > > > and webcam drivers and etc. Install image creation would pull them all > > > in; anaconda would filter the available as-needed's based on target > > > hardware. > > > > > > In that scenario you'd still need to do manual selection of some driver > > > packages for critpathness, but, okay. > > > > With this approach, you have lost a critical feature: the ability for > > you to change your hardware (or move the software bits to a different > > computer) and have everything automatically work. > > Assuming pk actually had this feature, the next time you booted pk would > happily tell you about what driver you're missing. *If* it booted to a sane state where pk could tell you this, then yes I agree. Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On Tue, Apr 12, 2011 at 01:48:19PM -0400, Nathaniel McCallum wrote: > With this approach, you have lost a critical feature: the ability for > you to change your hardware (or move the software bits to a different > computer) and have everything automatically work. You change the card, the system comes up in VESA, Packagekit (or whatever) notices new hardware and installs the drivers. Seems pretty automatic? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On Tue, Apr 12, 2011 at 02:01:26PM -0400, Nathaniel McCallum wrote: > On Tue, 2011-04-12 at 13:57 -0400, Casey Dahlin wrote: > > On Tue, Apr 12, 2011 at 01:48:19PM -0400, Nathaniel McCallum wrote: > > > > > > With this approach, you have lost a critical feature: the ability for > > > you to change your hardware (or move the software bits to a different > > > computer) and have everything automatically work. > > > > > > Nathaniel > > > > You lose it for a couple of strange usecases though: > > > > 1) Moving from a card that is up to date in what it supports to an older > > card that isn't (rare). > > > > 2) Moving from one crappy ancient card to another (plausible, but still > > rare). > > > > The vesa driver should mean some workable video support in either case, > > and from there, if we were really, truly concerned, we could detect the > > need for the driver and prompt to install it. That's starting to sound > > like the bad old days of kudzu though, and I'd be surprised if anyone > > really felt this was worth that effort. > > I think losing it in those cases is probably acceptable. My thought is > that the disk space for drivers is minimal, lets just support everything > (or at least the current stuff) in a single install. My concern isn't > moving to and/or between rare old cards. My concern is moving from > nouveau to intel or radeon... The "big" drivers should definitely be > installed on every system, regardless of its hardware. > I believe (and maybe I've read this thread to quickly) that that will still be the case. Its only the drivers for old cards with smaller feature sets that are being moved at alll. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On Tue, 2011-04-12 at 19:06 +0100, Matthew Garrett wrote: > On Tue, Apr 12, 2011 at 01:48:19PM -0400, Nathaniel McCallum wrote: > > > With this approach, you have lost a critical feature: the ability for > > you to change your hardware (or move the software bits to a different > > computer) and have everything automatically work. > > You change the card, the system comes up in VESA, Packagekit (or > whatever) notices new hardware and installs the drivers. Seems pretty > automatic? Limited to video drivers? yes. I just can't help but think that some will be unable to resist the temptation to do the same thing for firmware. In this case, pk will happily notify you, but you won't have access to the repo to handle the change to the new networking card, etc. Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On 04/12/2011 01:38 PM, Adam Jackson wrote: > On Tue, 2011-04-12 at 12:23 -0400, Bill Nottingham wrote: >> Adam Jackson (a...@redhat.com) said: >>> So that's the rough plan. Comments appreciated if I'm overlooking >>> anything. >> >> The question would be how we ensure that these additional drivers are in the >> install image, or in the installed system, if necessary. Or do we not care >> if they get vesa? How would users be informed/able to install drivers if >> necessary? (I don't know that PK search is good here.) > > To a first approximation, I deeply do not care. If you're choosing to > use an s3virge in 2011 you've already decided to make your life hard. While I don't care about accelerated X support, this hardware darned well better continue working in an "it works" 2D display mode. VESA or whatever is fine. Why? Data centers have /plenty/ of ancient video solutions out there, and basic video support is needed. Jeff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
Once upon a time, Nathaniel McCallum said: > With this approach, you have lost a critical feature: the ability for > you to change your hardware (or move the software bits to a different > computer) and have everything automatically work. That has been the case off and on for a long time, with kernels and glibc split for i386/i686, and then kernels for PAE. Old hardware is always going to fall off the tail. It isn't like the packages are going to be removed, and they'll probably not get any less testing than they do today. Also, since VESA will still be included, it should work on most any hardware. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
Once upon a time, Jeff Garzik said: > Data centers have /plenty/ of ancient video solutions out there, and > basic video support is needed. How many data centers run X on servers? I know I don't; they all boot runlevel 3 and just have a serial console (KVM switches are for Windows machines). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On Tue, 2011-04-12 at 19:06 +0100, Matthew Garrett wrote: > On Tue, Apr 12, 2011 at 01:48:19PM -0400, Nathaniel McCallum wrote: > > > With this approach, you have lost a critical feature: the ability for > > you to change your hardware (or move the software bits to a different > > computer) and have everything automatically work. > > You change the card, the system comes up in VESA, Packagekit (or > whatever) notices new hardware and installs the drivers. Seems pretty > automatic? I should say that about 2.5 years ago I wrote a patch for xorg to print out an inventory of the hardware a given driver supported. http://cgit.freedesktop.org/xorg/xserver/commit/?id=8e368cf5b964f1d29fda0a463f9510457619b14d The patch was subsequently removed by an overzealous committer who thought it would be fun to remove useful functionality he thought xorg didn't need anymore (name concealed to protect the guilty). That patch above, or a similar version, could be used to automatically generate the PK list from the binary at rpm build time, as well as be useful in a variety of other cases. Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On Tue, 2011-04-12 at 13:18 -0500, Chris Adams wrote: > Once upon a time, Nathaniel McCallum said: > > With this approach, you have lost a critical feature: the ability for > > you to change your hardware (or move the software bits to a different > > computer) and have everything automatically work. > > That has been the case off and on for a long time, with kernels and > glibc split for i386/i686, and then kernels for PAE. Old hardware is > always going to fall off the tail. > > It isn't like the packages are going to be removed, and they'll probably > not get any less testing than they do today. Also, since VESA will > still be included, it should work on most any hardware. Sure. To be blunt: I'm in support of the move, I just want to make sure we think about the case of hardware changes and not boot to an unusable system... Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On Tue, Apr 12, 2011 at 02:09:06PM -0400, Nathaniel McCallum wrote: > Limited to video drivers? yes. I just can't help but think that some > will be unable to resist the temptation to do the same thing for > firmware. In this case, pk will happily notify you, but you won't have > access to the repo to handle the change to the new networking card, etc. Upstream ship firmware as a single package, and I don't see us wanting to change that. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
Hello Nathaniel, On Tuesday, April 12, 2011, 2:01:26 PM, Nathaniel McCallum wrote: > On Tue, 2011-04-12 at 13:57 -0400, Casey Dahlin wrote: >> On Tue, Apr 12, 2011 at 01:48:19PM -0400, Nathaniel McCallum wrote: >> > >> > With this approach, you have lost a critical feature: the ability for >> > you to change your hardware (or move the software bits to a different >> > computer) and have everything automatically work. >> > >> > Nathaniel >> >> You lose it for a couple of strange usecases though: >> >> 1) Moving from a card that is up to date in what it supports to an older >> card that isn't (rare). >> >> 2) Moving from one crappy ancient card to another (plausible, but still >> rare). >> >> The vesa driver should mean some workable video support in either case, >> and from there, if we were really, truly concerned, we could detect the >> need for the driver and prompt to install it. That's starting to sound >> like the bad old days of kudzu though, and I'd be surprised if anyone >> really felt this was worth that effort. > I think losing it in those cases is probably acceptable. My thought is > that the disk space for drivers is minimal, lets just support everything > (or at least the current stuff) in a single install. My concern isn't > moving to and/or between rare old cards. My concern is moving from > nouveau to intel or radeon... The "big" drivers should definitely be > installed on every system, regardless of its hardware. > Nathaniel For the Intel arches, it may make sense to have all kinds of X drivers available by default. For the secondary arches, the user requirements and physical environment. On zSeries, there is no relevant graphics hardware. When one runs X, it is the application side only via a remove X display server on another system. For ARM, the root filesystem is set up with an appropriate kernel (likely customized) and a single X display driver. On ARM, system space is typically quite tight. Heck, even Intel-based netbooks and tablets don't have all _that_ much storage. Whatever decisions are made should take these differences between arches into account and allow appropriate default and custom setups. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On Tuesday, April 12, 2011, 3:04:36 PM, I wrote: > For the Intel arches, it may make sense to have all kinds of X drivers > available by default. For the secondary arches, the user requirements > and physical environment. Brain fart - I meant to say "and physical environment differ". Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On Tue, 2011-04-12 at 14:16 -0400, Jeff Garzik wrote: > While I don't care about accelerated X support, this hardware darned > well better continue working in an "it works" 2D display mode. VESA or > whatever is fine. You'll notice I included vesa in the standard list. Not that vesa works very well when EFI is involved, but that's an entirely different kettle of excrement. > Data centers have /plenty/ of ancient video solutions out there, and > basic video support is needed. Dude. I know this better than just about anyone. I own the X packaging in RHEL. Trust. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On 04/12/2011 03:34 PM, Adam Jackson wrote: > On Tue, 2011-04-12 at 14:16 -0400, Jeff Garzik wrote: > >> While I don't care about accelerated X support, this hardware darned >> well better continue working in an "it works" 2D display mode. VESA or >> whatever is fine. > > You'll notice I included vesa in the standard list. Not that vesa works > very well when EFI is involved, but that's an entirely different kettle > of excrement. But in that case (if you haven't picked completely braindead hardware) you have a working fbcon that we can fall back to. It'll just be very slow. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On Tue, 12 Apr 2011 20:16:45 +0200, Jeff Garzik wrote: > While I don't care about accelerated X support, this hardware darned > well better continue working in an "it works" 2D display mode. VESA or > whatever is fine. VESA is not fine, ancient Free drivers are debuggable code when something crashes, VESA is a proprietary code one cannot debug. It can for example crash in the VESA code due to a bug in Fedora code corrupting its stack etc, this is difficult to debug. Why is proposed a proprietary code over existing Free drivers? The size of `retrocomputing' drivers is negligible and the maintenance of them needs to be done anyway. Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On Tue, Apr 12, 2011 at 10:02:33PM +0200, Jan Kratochvil wrote: > On Tue, 12 Apr 2011 20:16:45 +0200, Jeff Garzik wrote: > > While I don't care about accelerated X support, this hardware darned > > well better continue working in an "it works" 2D display mode. VESA or > > whatever is fine. > > VESA is not fine, ancient Free drivers are debuggable code when something > crashes, VESA is a proprietary code one cannot debug. It can for example crash > in the VESA code due to a bug in Fedora code corrupting its stack etc, this is > difficult to debug. > > Why is proposed a proprietary code over existing Free drivers? Have you checked how many of these old drivers rely on BIOS services anyway? In any case, it's vital that VESA work given that it's the only way to bring up hardware that's newer than the install image - increasing its test coverage can only be a good thing. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On Tue, 2011-04-12 at 13:19 -0500, Chris Adams wrote: > Once upon a time, Jeff Garzik said: > > Data centers have /plenty/ of ancient video solutions out there, and > > basic video support is needed. > > How many data centers run X on servers? I know I don't; they all boot > runlevel 3 and just have a serial console (KVM switches are for Windows > machines). I run in runlevel 3 so its not turned on, but I do have X installed and I'll start it in the datacenter (on a non-broken machine!) when I'm looking up docs, remoting my workstation to browse my email, etc. So it might not be running daily, but its there. Brian > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On Tue, 12 Apr 2011 22:09:36 +0200, Matthew Garrett wrote: > In any case, it's vital that VESA work given that it's the only > way to bring up hardware that's newer than the install image - > increasing its test coverage can only be a good thing. It does not make sense to test VESA as we cannot fix VESA. (That is the BIOS part; I doubt the VESA xorg driver needs too much testing.) Thanks, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On Wed, Apr 13, 2011 at 04:03:48AM +0200, Jan Kratochvil wrote: > On Tue, 12 Apr 2011 22:09:36 +0200, Matthew Garrett wrote: > > In any case, it's vital that VESA work given that it's the only > > way to bring up hardware that's newer than the install image - > > increasing its test coverage can only be a good thing. > > It does not make sense to test VESA as we cannot fix VESA. > (That is the BIOS part; I doubt the VESA xorg driver needs too much testing.) Not so much the vesa driver, but x86emu tends to have a bewildering array of bugs. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On 04/12/2011 09:12 AM, Adam Jackson wrote: > There are two major package classes in Fedora that provide graphics > drivers: xorg-x11-drv-*, and mesa-dri-drivers-*. > > In F15, mesa-dri-drivers now only includes drivers with DRI2 support > (radeon, nvidia, intel) and the software renderer; if you want all the > older drivers you have to install mesa-dri-drivers-dri1. This list is: > > i810, mga, r128, savage, sis, tdfx, unichrome > > Basically all of this hardware is, ahem, inept. The most featureful > device supported by these drivers would be the MGA G550, which just > barely manages to do DirectX 7 (comparable to a Radeon 7000 or GeForce > 2, both ~1999 vintage). All the others are back in the DX6 stone age. My r128 card (Rage Mobility M3 AGP 2X; pci 1002:4c46) is running DirectX 9.0c (4.09..0904) on Windows ME. The main driver ATI2DRAI.DRV says "DDI Version 7". The machine also runs Fedora 12 using: xorg-x11-server-Xorg.1.7.6-4.fc12.i686 xorg-x11-drv-ati-6.13.0-0.21.20100219gite68d3a389.fc12.i686 xorg-x11-drv-r128-6.8.1-2.fc12.i686 Such a machine is quite usable. > For comparison, the baseline for the GPU in the phone in your pocket - > and that platform layers like clutter more or less expect - is GLES 2.0, > which is roughly comparable to DirectX 9. We're rapidly approaching the > point where the software renderer is going to be a more satisfying > experience than hardware 3d support for these chips, both for features > and for performance. How rapidly? Today, which one leads in "satisfying experience", and by how much? > [snip] > So in my ideal world, we would simply drop the -dri1 subpackage (and for > that matter, DRI1 support in the X server). Such a wish would be better justified by statistics on usage (smolt, at least) and support effort (size and rate of change in source commits, number of maintainers with relevant experience, ...) -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On 04/12/2011 06:12 PM, Adam Jackson wrote: > There are two major package classes in Fedora that provide graphics > drivers: xorg-x11-drv-*, and mesa-dri-drivers-*. > > In F15, mesa-dri-drivers now only includes drivers with DRI2 support > (radeon, nvidia, intel) and the software renderer; if you want all the > older drivers you have to install mesa-dri-drivers-dri1. This list is: > > i810, mga, r128, savage, sis, tdfx, unichrome > > Basically all of this hardware is, ahem, inept. The most featureful > device supported by these drivers would be the MGA G550, which just > barely manages to do DirectX 7 (comparable to a Radeon 7000 or GeForce > 2, both ~1999 vintage). All the others are back in the DX6 stone age. > For comparison, the baseline for the GPU in the phone in your pocket - > and that platform layers like clutter more or less expect - is GLES 2.0, > which is roughly comparable to DirectX 9. We're rapidly approaching the > point where the software renderer is going to be a more satisfying > experience than hardware 3d support for these chips, both for features > and for performance. > > So in my ideal world, we would simply drop the -dri1 subpackage (and for > that matter, DRI1 support in the X server). > > For 2D we've got an xorg-x11-drivers metapackage that includes, well, > pretty much everything, and which is included in comps as a default. > This is lame, because it means a bunch of backwater drivers end up as > critical path and can never possibly get tested. (Smolt says there are > all of 3 savage users. I assume the number of i740 users is actually > negative.) The list of video drivers that see any actual use is > probably something like: > > ast, ati, cirrus, fbdev, geode, intel, mga, nouveau, openchrome, > qxl, sis/xgi, vesa, vmware > Would this affect the way KVM and specifically qemu-kvm in it's default setup for video using the cirrus driver would work? Just wondering if there would be any implications for the virt guys in that regard. Thanks & regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Supervisor Core Services | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.com/ D-70178 Stuttgart, Germany Motd: You're only jealous cos the little penguins are talking to me. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On 4/13/11 5:14 AM, Phil Knirsch wrote: > On 04/12/2011 06:12 PM, Adam Jackson wrote: >> ast, ati, cirrus, fbdev, geode, intel, mga, nouveau, openchrome, >> qxl, sis/xgi, vesa, vmware > > Would this affect the way KVM and specifically qemu-kvm in it's default > setup for video using the cirrus driver would work? Just wondering if > there would be any implications for the virt guys in that regard. "cirrus" is in that list for precisely that reason. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
Adam Jackson (a...@redhat.com) said: > On 4/13/11 5:14 AM, Phil Knirsch wrote: > > On 04/12/2011 06:12 PM, Adam Jackson wrote: > >> ast, ati, cirrus, fbdev, geode, intel, mga, nouveau, openchrome, > >> qxl, sis/xgi, vesa, vmware > > > > Would this affect the way KVM and specifically qemu-kvm in it's default > > setup for video using the cirrus driver would work? Just wondering if > > there would be any implications for the virt guys in that regard. > > "cirrus" is in that list for precisely that reason. ... should we work on making qemu/kvm default to something more modern/sane? (qxl, vmware?) Does it not end up mattering (or do we need cirrus for legacy OS support)? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On 4/13/11 9:09 AM, Bill Nottingham wrote: > ... should we work on making qemu/kvm default to something more modern/sane? > (qxl, vmware?) Does it not end up mattering (or do we need cirrus for > legacy OS support)? It ends up being a function of the guest OS - vmware's Windows driver will refuse to run on anything but vmware's hypervisor, etc - which means that's really more of a virt-manager question. That said, the dumb vesa support in kvm is quite possibly a better choice as a default than cirrus, as the latter is limited (by the choice of chip emulated!) to 1024x768. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
Dne 12.4.2011 18:12, Adam Jackson napsal(a): > negative.) The list of video drivers that see any actual use is > probably something like: > > ast, ati, cirrus, fbdev, geode, intel, mga, nouveau, openchrome, > qxl, sis/xgi, vesa, vmware A word from your Xorg bugmaster. I think even this list is too generous .. I haven't found any Fedora bug for -ast, only 3 hopelessly ignored bugs for -sis, -geode is alive only because of OLPC (and yes, that's a good reason enough to keep it around), and outside of KVM emulation I don't remember I've ever seen a -cirrus bug. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On 04/13/2011 03:10 PM, Adam Jackson wrote: > On 4/13/11 9:09 AM, Bill Nottingham wrote: > >> ... should we work on making qemu/kvm default to something more >> modern/sane? >> (qxl, vmware?) Does it not end up mattering (or do we need cirrus for >> legacy OS support)? > > It ends up being a function of the guest OS - vmware's Windows driver > will refuse to run on anything but vmware's hypervisor, etc - which > means that's really more of a virt-manager question. > Hm, odd. When i switch from cirrus to the vmware display driver it seems to work quite nicely here on my box (RHEL-6 host) and Xorg.log.0 clearly shows it using the vmware driver in the guest, too. And i'm pretty sure we didn't do any hacks in RHEL-6 to make this work specifically as the default was and is cirrus driver (as limited as that may be). Thanks & regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Supervisor Core Services | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.com/ D-70178 Stuttgart, Germany Motd: You're only jealous cos the little penguins are talking to me. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On 4/13/11 11:02 AM, Phil Knirsch wrote: > On 04/13/2011 03:10 PM, Adam Jackson wrote: >> On 4/13/11 9:09 AM, Bill Nottingham wrote: >> >>> ... should we work on making qemu/kvm default to something more >>> modern/sane? >>> (qxl, vmware?) Does it not end up mattering (or do we need cirrus for >>> legacy OS support)? >> >> It ends up being a function of the guest OS - vmware's Windows driver >> will refuse to run on anything but vmware's hypervisor, etc - which >> means that's really more of a virt-manager question. > > Hm, odd. When i switch from cirrus to the vmware display driver it seems > to work quite nicely here on my box (RHEL-6 host) and Xorg.log.0 clearly > shows it using the vmware driver in the guest, too. And i'm pretty sure > we didn't do any hacks in RHEL-6 to make this work specifically as the > default was and is cirrus driver (as limited as that may be). I said "vmware's Windows driver" for a reason. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On 4/13/11 10:25 AM, Matej Cepl wrote: > Dne 12.4.2011 18:12, Adam Jackson napsal(a): >> negative.) The list of video drivers that see any actual use is >> probably something like: >> >> ast, ati, cirrus, fbdev, geode, intel, mga, nouveau, openchrome, >> qxl, sis/xgi, vesa, vmware > > A word from your Xorg bugmaster. I think even this list is too generous > .. I haven't found any Fedora bug for -ast, only 3 hopelessly ignored > bugs for -sis, -geode is alive only because of OLPC (and yes, that's a > good reason enough to keep it around), and outside of KVM emulation I > don't remember I've ever seen a -cirrus bug. ast I only included because I know there's currently shipping server hardware with it. The rest... yeah, pretty much. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On 4/12/11 11:58 PM, John Reiser wrote: > On 04/12/2011 09:12 AM, Adam Jackson wrote: >> Basically all of this hardware is, ahem, inept. The most featureful >> device supported by these drivers would be the MGA G550, which just >> barely manages to do DirectX 7 (comparable to a Radeon 7000 or GeForce >> 2, both ~1999 vintage). All the others are back in the DX6 stone age. > > My r128 card (Rage Mobility M3 AGP 2X; pci 1002:4c46) is running > DirectX 9.0c (4.09..0904) on Windows ME. The main driver ATI2DRAI.DRV > says "DDI Version 7". The machine also runs Fedora 12 using: The DX level that the OS claims is not the DX level that the hardware supports. Rage 128 doesn't have any shader hardware. The first ATI card that did was the Radeon 8500, a DX8 part. If you use any DX9 features on setup, I assure you, they're implemented in software. Which is what I'm proposing for Fedora. I should emphasize that I'm not proposing the Mesa packaging change (just) because it makes my life easier. I'm proposing it because I think it'll make users' lives better. >> For comparison, the baseline for the GPU in the phone in your pocket - >> and that platform layers like clutter more or less expect - is GLES 2.0, >> which is roughly comparable to DirectX 9. We're rapidly approaching the >> point where the software renderer is going to be a more satisfying >> experience than hardware 3d support for these chips, both for features >> and for performance. > > How rapidly? Today, which one leads in "satisfying experience", and by how > much? F16 timeframe? That's kind of why I bring it up now. Put it this way: gnome-shell will barely work on your card as it is, if at all, and no DRI1 driver can or will ever handle Composite redirection of GL apps. I can conjure up some benchmarks if you think they'd be relevant, I suppose. >> So in my ideal world, we would simply drop the -dri1 subpackage (and for >> that matter, DRI1 support in the X server). > > Such a wish would be better justified by statistics on usage > (smolt, at least) and support effort (size and rate of change in > source commits, number of maintainers with relevant experience, ...) So, in reverse order: the number of maintainers for the DRI1 drivers is approximately 0. Anyone who did have any experience with them is now interested in competent hardware instead. I can probably remember how a Voodoo5 works if you force me, but I'd rather not. The support effort for keeping them working at their current level is not zero, but it's not large. Breakages mostly happen when mechanical API changes are made internally to Mesa that happen to violate some invariant that the old driver was relying on. Nobody notices breakage like that because nobody has the hardware. Time spent on this level of support is time not spent on hardware people have. But time spent on this level of support is also time spent on a level of support that is not sufficient for the future. We can either chase bugs in seven DX7-or-worse drivers, for hardware that is on the far end of the bathtub curve; or we can maintain one software-based driver that runs everywhere including in virtual machines, shares most of its internal infrastructure with r600 and nouveau, and already implements better than DX9-level functionality. I know which one I'd prefer. --- But then, smolt. Sigh. Smolt. What a travesty. You would hope that a result like: http://smolt.fedoraproject.org/reports/view_devices?device=MGA&search=Submit+Query would mean there's one report for each of those device, but no. And then you'd hope that you could click on the first device and get a uniquified list, but no: http://smolt.fedoraproject.org/reports/view_device/MGA%20G200%20AGP The one thing - the _one_ thing - I'd want out of smolt is a query by PCI ID tuple, and that doesn't exist. Even this page: http://smolt.fedoraproject.org/static/stats/by_class_VIDEO.html is nonsense. As of just now, the sum of the (unlabeled) column immediately right of the vendor name is 38553. The "total count" above is 432462 and the percentage of systems reporting a video device is 17.7%, but 38553 is not 17.7% of 432462. Not even close. Assuming that 38553 is anywhere close to a meaningful number, we then get: nvidia: 38.6% (14888) ati:34.2% (13176) intel: 19.1% (7347) So that's 92% of the installed base as a ballpark, but not corrected for mach64, rage128, i740, i810, or (ha!) nv1. Of the remaining 3142 systems where DRI1 support might work: matrox:11.0% (347) s3:14.4% (451) sis: 20.1% (633) 3dfx: 2.6% (81) via: 20.4% (640) total: 68.5% (2152) Which is an overestimate: - mga includes pre-G200 devices, P-series, and M-series - savage includes all S3 chips, including pre-Savage devices like Virge and 968, and post-savage4 like savage2000 and chrome cards - sis includes all sis variants where we only have 3d support for the 300 series (see 'man
Re: rfc/headsup: graphics driver packaging in F16+
On Tue, 2011-04-12 at 13:38 -0400, Adam Jackson wrote: > On Tue, 2011-04-12 at 12:23 -0400, Bill Nottingham wrote: > > Adam Jackson (a...@redhat.com) said: > > > So that's the rough plan. Comments appreciated if I'm overlooking > > > anything. > > > > The question would be how we ensure that these additional drivers are in the > > install image, or in the installed system, if necessary. Or do we not care > > if they get vesa? How would users be informed/able to install drivers if > > necessary? (I don't know that PK search is good here.) > > To a first approximation, I deeply do not care. If you're choosing to > use an s3virge in 2011 you've already decided to make your life hard. > > But if we're trying to be completionists about it, import the data > from /usr/share/hwdata/videoaliases/*.xinf into virtual Provides for > each driver package and teach packagekit or whatever how to cope. > Something like this: > > http://lists.fedoraproject.org/pipermail/devel/2010-April/135004.html I've been trying to get someone to write something like this (I called it 'HardwareKit' back when kits were cool...) for absolutely ages, but I'm worried it might wind up derailing this thread, which is about a much more modest change. Perhaps we should branch the thread... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On Tue, 2011-04-12 at 13:17 -0400, Adam Jackson wrote: > On Tue, 2011-04-12 at 09:34 -0700, Adam Williamson wrote: > > On Tue, 2011-04-12 at 12:12 -0400, Adam Jackson wrote: > > > > > And input is even briefer (evdev, synaptics, wacom, vmmouse). I'd like > > > to chop the -drivers metapackage down to just this set, and either make > > > a new metapackage in optional for -drivers-retrocomputing or simply list > > > all the drivers there individually. Note that since we're keeping > > > drivers for fbdev and vesa we should still get graphics on most devices > > > even if the user doesn't explicitly ask for a native driver. > > > > > > So that's the rough plan. Comments appreciated if I'm overlooking > > > anything. > > > > Well, the less intrusive alternative is just to make graphics drivers a > > comps group rather than using a metapackage. Metapackages are generally > > 'frowned upon' in Fedora anyway, and you're supposed to do stuff with > > comps groups. Doing it that way would remove the critical path > > implications; we could then just add the important drivers to critpath > > individually. > > Not that I object, but that's just moving the goalposts from "which > drivers in the metapackage" to "which drivers in comps". It doesn't > address the construction of the list. Well, I was focusing on this part of your mail: "For 2D we've got an xorg-x11-drivers metapackage that includes, well, pretty much everything, and which is included in comps as a default. This is lame, because it means a bunch of backwater drivers end up as critical path and can never possibly get tested." Which suggests the major reason to change this is the critpath implications. My point being that if we do this with comps groups, it completely removes the critpath issue, meaning we could still choose to install lots of drivers by default and not worry about critpath. It seems you have other good reasons to want to de-emphasize some drivers, but still, if we make the comps change too, it means we don't have to worry about drivers that are well maintained but for niche hardware: we can keep them installed by default and 'fully supported', but still not have to worry about them being critpath. We can still not install by default drivers that we really want to stop caring about. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
Adam Jackson wrote: > On 4/12/11 11:58 PM, John Reiser wrote: >> On 04/12/2011 09:12 AM, Adam Jackson wrote: >>> For comparison, the baseline for the GPU in the phone in your pocket - >>> and that platform layers like clutter more or less expect - is GLES 2.0, >>> which is roughly comparable to DirectX 9. We're rapidly approaching the >>> point where the software renderer is going to be a more satisfying >>> experience than hardware 3d support for these chips, both for features >>> and for performance. >> >> How rapidly? Today, which one leads in "satisfying experience", and by >> how much? > > F16 timeframe? That's kind of why I bring it up now. Will F16 finally ship the llvmpipe as the default software renderer? (I can see the llvmpipe beat ancient cards easily, judging from the benchmarks I've seen so far, but the existing software pipes are really really slow.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On 4/13/11 5:43 PM, Kevin Kofler wrote: > Will F16 finally ship the llvmpipe as the default software renderer? If by F16, you mean F15, then yes. http://fedoraproject.org/wiki/Docs/Beats/Xorg - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
Adam Jackson wrote: > On 4/13/11 5:43 PM, Kevin Kofler wrote: > >> Will F16 finally ship the llvmpipe as the default software renderer? > > If by F16, you mean F15, then yes. > > http://fedoraproject.org/wiki/Docs/Beats/Xorg Hmmm, really? When I look at upstream mesa's code, I see this: http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/targets/dri-swrast/Makefile This sure looks like it builds swrastg using the softpipe, not the llvmpipe. I also don't see any Fedora patch which would be changing this. Now I'm not going to claim that I know my way around the Mesa codebase, so what am I missing? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On 4/13/11 7:17 PM, Kevin Kofler wrote: > Adam Jackson wrote: >> On 4/13/11 5:43 PM, Kevin Kofler wrote: >>> Will F16 finally ship the llvmpipe as the default software renderer? >> >> If by F16, you mean F15, then yes. > > Hmmm, really? I don't know. Let's ask the machine: synephrine:~% DISPLAY=:0 LIBGL_ALWAYS_SOFTWARE=1 glxinfo | grep renderer OpenGL renderer string: Gallium 0.4 on llvmpipe synephrine:~% rpm -q mesa-dri-drivers mesa-dri-drivers-7.11-0.6.20110412.0.fc15.x86_64 - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On Wed, 2011-04-13 at 19:57 -0400, Adam Jackson wrote: > On 4/13/11 7:17 PM, Kevin Kofler wrote: > > Adam Jackson wrote: > >> On 4/13/11 5:43 PM, Kevin Kofler wrote: > >>> Will F16 finally ship the llvmpipe as the default software renderer? > >> > >> If by F16, you mean F15, then yes. > > > > Hmmm, really? > > I don't know. Let's ask the machine: > > synephrine:~% DISPLAY=:0 LIBGL_ALWAYS_SOFTWARE=1 glxinfo | grep renderer > OpenGL renderer string: Gallium 0.4 on llvmpipe > synephrine:~% rpm -q mesa-dri-drivers > mesa-dri-drivers-7.11-0.6.20110412.0.fc15.x86_64 In the interests of general public enlightenment, it would've been nice if you'd answered KK's question "what am I missing", i.e., where's the magic bit which makes llvmpipe the default? Knowledge is always a good thing :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On 4/13/11 11:58 PM, Adam Williamson wrote:
> In the interests of general public enlightenment, it would've been nice
> if you'd answered KK's question "what am I missing", i.e., where's the
> magic bit which makes llvmpipe the default? Knowledge is always a good
> thing :)
The specfile contains this stanza, after it has built OSMesa:
# now build the rest of mesa
%configure %{common_flags} \
--disable-glw \
--disable-glut \
--disable-gl-osmesa \
--with-driver=dri \
--with-dri-driverdir=%{_libdir}/dri \
--with-state-trackers=dri,glx \
--enable-egl \
--enable-gles1 \
--enable-gles2 \
--disable-gallium-intel \
--disable-gallium-svga \
--disable-gallium-egl \
%if %{with_hardware}
--enable-gallium-llvm \
--enable-gallium-radeon \
--enable-gallium-r600 \
--enable-gallium-nouveau \
%else
--disable-gallium-llvm \
--disable-gallium-radeon \
--disable-gallium-r600 \
--disable-gallium-nouveau \
%endif
%{?dri_drivers}
The --enable-gallium-llvm bit, in particular, is key. There's some
small magic later where it renames swrastg_dri.so to be swrast_dri.so
because that's the name the X server and libGL are expecting, and that's
not perfect yet in that the debuginfo search gets a little confused, but
in the main I've tried to be pretty clear in the operation of the Mesa
spec, despite the utter malignancy of the Mesa buildsystem (any of them,
take your pick, there's like five now). If I've failed in any way to
document sufficiently our work in the specfile, please, do let me know.
But - as an aside - you're right. I was a little irked at being asked
whether I'd actually done the thing I'd said I'd done, had tested that
I'd done, had documented that I'd done, had claimed in public that I'd
done, and had been doubted of without any evidence of the inquisitor
having made even cursory investigation into the matter. It was wrong of
me to assume that someone reading the spec would look for the string
/llvm/i when looking for how to enable the LLVM support in Mesa, to
assume that someone would read the spec to learn how the package was
built, or to assume that someone would try to test a software GL path
like Xvfb or vesa to see if I was in fact telling the truth before
doubting my honesty. I was unnecessarily short in my reply, and for
that, I apologize. In the future I'll be less succinct.
(No, I won't.)
- ajax
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
