For F21, I plan to orphan the following X video drivers:
xorg-x11-drv-apm xorg-x11-drv-cirrus xorg-x11-drv-geode xorg-x11-drv-glint xorg-x11-drv-i128 xorg-x11-drv-i740 xorg-x11-drv-mach64 xorg-x11-drv-mga xorg-x11-drv-neomagic xorg-x11-drv-r128 xorg-x11-drv-rendition xorg-x11-drv-s3virge xorg-x11-drv-savage xorg-x11-drv-siliconmotion xorg-x11-drv-sis xorg-x11-drv-tdfx xorg-x11-drv-trident
Effectively this means that the graphics team will be focusing on KMS for graphics support, with vesa and fbdev available as last-ditch fallbacks. If anyone is interested in taking on support for these chips, they're welcome to, though we would encourage anyone doing so to work towards KMS support and not merely do "keep it building" maintenance.
One other detail: the intel driver currently has both UMS support for the i810 chipset, and KMS support for everything newer. To be consistent with the above changes I'll be dropping the i810 support, which will then fall back to vesa. Again, if someone wants to own the i810 support, let me know and we can add you as a comaintainer.
- ajax
On 08/27/2013 02:46 PM, Adam Jackson wrote:
For F21, I plan to orphan the following X video drivers:
xorg-x11-drv-apm xorg-x11-drv-cirrus xorg-x11-drv-geode xorg-x11-drv-glint xorg-x11-drv-i128 xorg-x11-drv-i740 xorg-x11-drv-mach64 xorg-x11-drv-mga xorg-x11-drv-neomagic xorg-x11-drv-r128 xorg-x11-drv-rendition xorg-x11-drv-s3virge xorg-x11-drv-savage xorg-x11-drv-siliconmotion xorg-x11-drv-sis xorg-x11-drv-tdfx xorg-x11-drv-trident
Is it not better to drop entirely graphics drivers that do not have kms support and at the *same time* adopt the policy
"From this point forward only graphics driver that have kms support will be allow to be packaged and shipped in the distribution"
JBG
On Tue, Aug 27, 2013 at 4:54 PM, "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
On 08/27/2013 02:46 PM, Adam Jackson wrote:
For F21, I plan to orphan the following X video drivers:
xorg-x11-drv-apm xorg-x11-drv-cirrus xorg-x11-drv-geode xorg-x11-drv-glint xorg-x11-drv-i128 xorg-x11-drv-i740 xorg-x11-drv-mach64 xorg-x11-drv-mga xorg-x11-drv-neomagic xorg-x11-drv-r128 xorg-x11-drv-rendition xorg-x11-drv-s3virge xorg-x11-drv-savage xorg-x11-drv-siliconmotion xorg-x11-drv-sis xorg-x11-drv-tdfx xorg-x11-drv-trident
Is it not better to drop entirely graphics drivers that do not have kms support and at the *same time* adopt the policy
"From this point forward only graphics driver that have kms support will be allow to be packaged and shipped in the distribution"
Isn't that a bit too much?
On 08/27/2013 03:14 PM, drago01 wrote:
On Tue, Aug 27, 2013 at 4:54 PM, "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
Is it not better to drop entirely graphics drivers that do not have kms support and at the *same time* adopt the policy
"From this point forward only graphics driver that have kms support will be allow to be packaged and shipped in the distribution"
Isn't that a bit too much?
Depends If we want people to kick some live to upstream and add kms support we go that route.
If we want to just keep building these things and have our end user base having to come up with their own xorg.conf and basically deliver broken out the box support for some if not all those drivers we dont.
JBG
On Tue, 2013-08-27 at 14:54 +0000, "Jóhann B. Guðmundsson" wrote:
Is it not better to drop entirely graphics drivers that do not have kms support and at the *same time* adopt the policy
"From this point forward only graphics driver that have kms support will be allow to be packaged and shipped in the distribution"
I don't know why that would be "better". There's no intrinsic reason why we should forbid UMS drivers if there's a maintainer, it doesn't necessarily make my life harder to allow that. And, given that the list _does_ include hardware that people have filed bugs about in recent memory, I figure I should allow those interested in to step forward.
- ajax
On 08/27/2013 11:20 AM, Adam Jackson wrote:
On Tue, 2013-08-27 at 14:54 +0000, "Jóhann B. Guðmundsson" wrote:
Is it not better to drop entirely graphics drivers that do not have kms support and at the *same time* adopt the policy
"From this point forward only graphics driver that have kms support will be allow to be packaged and shipped in the distribution"
I don't know why that would be "better". There's no intrinsic reason why we should forbid UMS drivers if there's a maintainer, it doesn't necessarily make my life harder to allow that. And, given that the list _does_ include hardware that people have filed bugs about in recent memory, I figure I should allow those interested in to step forward.
- ajax
Sorry to come out of left field like this, but would the system profile info we collect on install be useful in determining the weight of the need for some of these drivers? For example, if there is still a bunch of SIS video adapters out there, we might prioritize support for that driver, but then not for others that don't show-up in our hardware surveys.
Perhaps this step has already been taken.
On Wed, Aug 28, 2013 at 10:13:09AM -0400, Basil Mohamed Gohar wrote:
Sorry to come out of left field like this, but would the system profile info we collect on install be useful in determining the weight of the need for some of these drivers? For example, if there is still a bunch of SIS video adapters out there, we might prioritize support for that driver, but then not for others that don't show-up in our hardware surveys.
Another way to look at it is the platform capabilities of these graphics devices. For example, Fedora 19's release notes claims a minimum of 1GB RAM is required. Were there any pre-PCIe platforms capable of supporting this much RAM?
Ditto on the embedded graphics (eg SiS or i810 etc) -- many of those platforms had serious RAM limitations too. I have a pile of old P4+i845 boxes stacked in a corner that max out at 512MB (due to chipset limitations) which isn't even enough RAM to boot the Fedora installer in text mode.
On the other hand, graphics chips that were available on PCI add-in cards could theoretically be used on modern systems, so those may be worth continuing to support.
- Solomon
On 08/28/2013 10:41 AM, Solomon Peachy wrote:
On Wed, Aug 28, 2013 at 10:13:09AM -0400, Basil Mohamed Gohar wrote:
Sorry to come out of left field like this, but would the system profile info we collect on install be useful in determining the weight of the need for some of these drivers? For example, if there is still a bunch of SIS video adapters out there, we might prioritize support for that driver, but then not for others that don't show-up in our hardware surveys.
Another way to look at it is the platform capabilities of these graphics devices. For example, Fedora 19's release notes claims a minimum of 1GB RAM is required. Were there any pre-PCIe platforms capable of supporting this much RAM?
Plenty! The common limitation in the pre-PCIe era was 2GB or 4GB (e.g., common 32-bit architecture memory limits). I have several that are non-PCIe and have 2GB of RAM. They run Fedora just fine. They do, however, have more modern AGP-based video cards installed, however. I haven't bothered with the embedded video adapter on them, so I cannot speak to their suitability for running Fedora 19.
Ditto on the embedded graphics (eg SiS or i810 etc) -- many of those platforms had serious RAM limitations too. I have a pile of old P4+i845 boxes stacked in a corner that max out at 512MB (due to chipset limitations) which isn't even enough RAM to boot the Fedora installer in text mode.
On the other hand, graphics chips that were available on PCI add-in cards could theoretically be used on modern systems, so those may be worth continuing to support.
- Solomon
I just wanted to comment about the memory issue. I cannot say much else about the rest here.
Hi
28.08.2013 20:31, Basil Mohamed Gohar wrote:
On 08/28/2013 10:41 AM, Solomon Peachy wrote:
On Wed, Aug 28, 2013 at 10:13:09AM -0400, Basil Mohamed Gohar wrote:
Sorry to come out of left field like this, but would the system profile info we collect on install be useful in determining the weight of the need for some of these drivers? For example, if there is still a bunch of SIS video adapters out there, we might prioritize support for that driver, but then not for others that don't show-up in our hardware surveys.
Another way to look at it is the platform capabilities of these graphics devices. For example, Fedora 19's release notes claims a minimum of 1GB RAM is required. Were there any pre-PCIe platforms capable of supporting this much RAM?
Plenty! The common limitation in the pre-PCIe era was 2GB or 4GB (e.g., common 32-bit architecture memory limits). I have several that are non-PCIe and have 2GB of RAM. They run Fedora just fine. They do, however, have more modern AGP-based video cards installed, however. I haven't bothered with the embedded video adapter on them, so I cannot speak to their suitability for running Fedora 19.
I have old desktop installation with matrox-mga driver used. Is it will only single VESA driver choose which do smaller resolution for that?
On Wed, 2013-08-28 at 10:41 -0400, Solomon Peachy wrote:
Ditto on the embedded graphics (eg SiS or i810 etc) -- many of those platforms had serious RAM limitations too. I have a pile of old P4+i845 boxes stacked in a corner that max out at 512MB (due to chipset limitations) which isn't even enough RAM to boot the Fedora installer in text mode.
This isn't actually correct; the release notes are a tad conservative (intentionally). There are actually some quite subtle variables for minimal RAM situations - including RAM sharing with graphics adapters, package set selection, and available swap space - so this isn't 100% applicable to all situations, but the testing we did on F19 indicated that you can do successfully complete a graphical DVD default package install with 512MB of RAM, or a text network default package install. I believe a text install may even work in 384MB, though I don't absolutely remember, and you may have to pass the parameter that disable's anaconda's RAM check to try it. Graphical network installs require more than 512MB - network installs need extra RAM before swap space comes online, as they go out and get package lists. Actually you could probably do an ugly hack around that by passing an intentionally invalid repo=, going through the storage spoke, and *then* setting the correct repo interactively, but that'd be hideous.
It _is_ possible to deploy Fedora in ways that bypass the installer, as well, and the memory required to actually run a Fedora system that does useful things is well south of 512MB. Even for desktop purposes you can still do useful stuff using a light WM or DE in 256MB, and one of my server VMs (which runs IRC and IM proxying and my XMPP server) sits at under 100MB of RAM use, IIRC. A minimal Fedora install sitting there doing nothing uses about 60-80MB of RAM, last I checked.
On Thu, Oct 03, 2013 at 12:35:31 +0100, Adam Williamson awilliam@redhat.com wrote:
that you can do successfully complete a graphical DVD default package install with 512MB of RAM, or a text network default package install. I believe a text install may even work in 384MB, though I don't absolutely remember, and you may have to pass the parameter that disable's anaconda's RAM check to try it. Graphical network installs require more than 512MB - network installs need extra RAM before swap space comes online, as they go out and get package lists. Actually you could probably do an ugly hack around that by passing an intentionally invalid repo=, going through the storage spoke, and *then* setting the correct repo interactively, but that'd be hideous.
I tried doing an F20 live install on a 512 MB machine and wasn't able to get it to work. There was no swap drive available though. The install configuration was extremely slow and seemed to have some of the subparts terminate. I never got to the part where I could start the install transaction. At some point I might try using an install image on the machine and see if that works better.
On 3 Oct 2013 16:48, "Bruno Wolff III" bruno@wolff.to wrote:
On Thu, Oct 03, 2013 at 12:35:31 +0100, Adam Williamson awilliam@redhat.com wrote:
that you can do successfully complete a graphical DVD default package install with 512MB of RAM, or a text network default package install. I believe a text install may even work in 384MB, though I don't absolutely remember, and you may have to pass the parameter that disable's anaconda's RAM check to try it. Graphical network installs require more than 512MB - network installs need extra RAM before swap space comes online, as they go out and get package lists. Actually you could probably do an ugly hack around that by passing an intentionally invalid repo=, going through the storage spoke, and *then* setting the correct repo interactively, but that'd be hideous.
I tried doing an F20 live install on a 512 MB machine and wasn't able to
get it to work. There was no swap drive available though. The install configuration was extremely slow and seemed to have some of the subparts terminate. I never got to the part where I could start the install transaction. At some point I might try using an install image on the machine and see if that works better.
At least on Fedora 18 on the olpc xo-1 with 256mb of ram and no swap fedora runs OK with a full GUI. Not had the time to check later releases but I'm not sure much has changed in that regard.
Peter
Peter
On Wed, Oct 09, 2013 at 10:40:17 +0100, Peter Robinson pbrobinson@gmail.com wrote:
At least on Fedora 18 on the olpc xo-1 with 256mb of ram and no swap fedora runs OK with a full GUI. Not had the time to check later releases but I'm not sure much has changed in that regard.
The 512mb laptop runs Fedora OK. I was just having an issue with the Live install. A yum upgrade should work. I suspect that an anaconda install from an install iamge would probably do better than a live install. The day I tried, I was testing the games spin, so I wanted to try the live install. Soon I'll bring it from F19 to F20 by some means.
On Thu, 2013-10-03 at 10:44 -0500, Bruno Wolff III wrote:
On Thu, Oct 03, 2013 at 12:35:31 +0100, Adam Williamson awilliam@redhat.com wrote:
that you can do successfully complete a graphical DVD default package install with 512MB of RAM, or a text network default package install. I believe a text install may even work in 384MB, though I don't absolutely remember, and you may have to pass the parameter that disable's anaconda's RAM check to try it. Graphical network installs require more than 512MB - network installs need extra RAM before swap space comes online, as they go out and get package lists. Actually you could probably do an ugly hack around that by passing an intentionally invalid repo=, going through the storage spoke, and *then* setting the correct repo interactively, but that'd be hideous.
I tried doing an F20 live install on a 512 MB machine and wasn't able to get it to work. There was no swap drive available though. The install configuration was extremely slow and seemed to have some of the subparts terminate. I never got to the part where I could start the install transaction. At some point I might try using an install image on the machine and see if that works better.
The above was written with the assumption some swap space would be available, yeah. Once anaconda gets into package installation, memory consumption increases notably, but at that point, swap space is available if any has been configured during partitioning, so effective available memory is also greater.
Last time I ran the numbers - which are on my blog somewhere - overall peak memory consumption (RAM plus swap) during a typical DVD install was, IIRC, somewhere around 750MB.
that you can do successfully complete a graphical DVD default package install with 512MB of RAM, or a text network default package install. I believe a text install may even work in 384MB, though I don't absolutely remember, and you may have to pass the parameter that disable's anaconda's RAM check to try it. Graphical network installs require more than 512MB - network installs need extra RAM before swap space comes online, as they go out and get package lists. Actually you could probably do an ugly hack around that by passing an intentionally invalid repo=, going through the storage spoke, and *then* setting the correct repo interactively, but that'd be hideous.
I tried doing an F20 live install on a 512 MB machine and wasn't able to get it to work. There was no swap drive available though. The install configuration was extremely slow and seemed to have some of the subparts terminate. I never got to the part where I could start the install transaction. At some point I might try using an install image on the machine and see if that works better.
The above was written with the assumption some swap space would be available, yeah. Once anaconda gets into package installation, memory consumption increases notably, but at that point, swap space is available if any has been configured during partitioning, so effective available memory is also greater.
Last time I ran the numbers - which are on my blog somewhere - overall peak memory consumption (RAM plus swap) during a typical DVD install was, IIRC, somewhere around 750MB.
From memory the peak was when the selinux policies were being
applied/installed and those numbers are about right from my memory of the peak but I believe there's been work to reduce the high water mark although, like you, I have no idea what the current figures are.
Peter
On Wed, 2013-08-28 at 10:13 -0400, Basil Mohamed Gohar wrote:
Sorry to come out of left field like this, but would the system profile info we collect on install be useful in determining the weight of the need for some of these drivers? For example, if there is still a bunch of SIS video adapters out there, we might prioritize support for that driver, but then not for others that don't show-up in our hardware surveys.
We don't actually collect this information anymore, smolt has been put out of its misery. Which is a shame, in a sense, but smolt never did work particularly well so I guess I don't mind.
But I don't think it'd be very useful in any event. The ati, intel, and nouveau drivers each have about an order of magnitude more open bugs filed than all of the to-be-orphaned drivers _combined_. geode's relatively recent, but has a maintainer. mga is the only one you can get in PCIE form factor, and there's already KMS support for some variants of it, so the barrier to proper support is pretty low should someone actually be interested. Outside of mga the most recent hardware in that list at all is probably either sis or trident, and neither of those has seen new hardware support (or any other real maintenance) since about 2005. And (again outside of mga) the most recent PCI cards of anything in that set would probably have been made in 2002 or so, at this point they are likely to be physically damaged just by powering them on.
So mga and sis I feel a little bad about, and if we had infinite resources it'd be cool to support them better. But we don't, so if we have to decide between fixing support for ten-year-old designs or making your next laptop light up, well, it's not a hard decision.
- ajax
On Wed, 2013-08-28 at 15:15 -0400, Adam Jackson wrote:
On Wed, 2013-08-28 at 10:13 -0400, Basil Mohamed Gohar wrote:
Sorry to come out of left field like this, but would the system profile info we collect on install be useful in determining the weight of the need for some of these drivers? For example, if there is still a bunch of SIS video adapters out there, we might prioritize support for that driver, but then not for others that don't show-up in our hardware surveys.
We don't actually collect this information anymore, smolt has been put out of its misery. Which is a shame, in a sense, but smolt never did work particularly well so I guess I don't mind.
There is active work going on on the Census project to replace it. I hope that works out better. Detailed and easily queryable information on graphics hardware usage patterns would be *extremely* useful QA and blocker bug process purposes.
On Tue, Aug 27, 2013 at 02:54:46PM +0000, "Jóhann B. Guðmundsson" wrote:
"From this point forward only graphics driver that have kms support will be allow to be packaged and shipped in the distribution"
Only if you want to drop VESA support.
From: mjg59@srcf.ucam.org On Tue, Aug 27, 2013 at 02:54:46PM +0000, "Jóhann B. Guðmundsson" wrote:
"From this point forward only graphics driver that have kms support will be allow to be packaged and shipped in the distribution"
Only if you want to drop VESA support.
Please don't drop that. I have a large install base of SBCs using geode and some on savage and s3virge IIRC. I need at least the VESA fallback, although I suspect that may not suffice in some cases.
-- John Florian
On Tue, Aug 27, 2013 at 04:30:25PM -0400, John.Florian@dart.biz wrote:
From: mjg59@srcf.ucam.org On Tue, Aug 27, 2013 at 02:54:46PM +0000, "Jóhann B. Guðmundsson" wrote:
"From this point forward only graphics driver that have kms support will be allow to be packaged and shipped in the distribution"
Only if you want to drop VESA support.
Please don't drop that. I have a large install base of SBCs using geode and some on savage and s3virge IIRC. I need at least the VESA fallback, although I suspect that may not suffice in some cases.
Yeah, I don't think anyone's planning on dropping VESA support. It's just that supporting it at the moment means that we continue to support some UMS drivers, which makes it difficult to stick to a "KMS or nothing" approach.
Out of curiosity, is the cirrus driver used in qemu/kvm or does it use something else?
On 08/27/2013 10:46 AM, Adam Jackson wrote:
For F21, I plan to orphan the following X video drivers:
xorg-x11-drv-apm xorg-x11-drv-cirrus xorg-x11-drv-geode xorg-x11-drv-glint xorg-x11-drv-i128 xorg-x11-drv-i740 xorg-x11-drv-mach64 xorg-x11-drv-mga xorg-x11-drv-neomagic xorg-x11-drv-r128 xorg-x11-drv-rendition xorg-x11-drv-s3virge xorg-x11-drv-savage xorg-x11-drv-siliconmotion xorg-x11-drv-sis xorg-x11-drv-tdfx xorg-x11-drv-trident
Effectively this means that the graphics team will be focusing on KMS for graphics support, with vesa and fbdev available as last-ditch fallbacks. If anyone is interested in taking on support for these chips, they're welcome to, though we would encourage anyone doing so to work towards KMS support and not merely do "keep it building" maintenance.
One other detail: the intel driver currently has both UMS support for the i810 chipset, and KMS support for everything newer. To be consistent with the above changes I'll be dropping the i810 support, which will then fall back to vesa. Again, if someone wants to own the i810 support, let me know and we can add you as a comaintainer.
- ajax
On Tue, 2013-08-27 at 10:58 -0400, Brian Wheeler wrote:
Out of curiosity, is the cirrus driver used in qemu/kvm or does it use something else?
There's a KMS driver for qemu's cirrus emulation now; X loads xorg-x11-drv-modesetting in that scenario. (Likewise for the Matrox G200SE series of server GPUs, they get handled by -modesetting not by -mga.)
- ajax
On Tue, Aug 27, 2013 at 10:46:19AM -0400, Adam Jackson wrote:
For F21, I plan to orphan the following X video drivers:
xorg-x11-drv-apm xorg-x11-drv-cirrus xorg-x11-drv-geode xorg-x11-drv-glint xorg-x11-drv-i128 xorg-x11-drv-i740 xorg-x11-drv-mach64 xorg-x11-drv-mga xorg-x11-drv-neomagic xorg-x11-drv-r128 xorg-x11-drv-rendition xorg-x11-drv-s3virge xorg-x11-drv-savage xorg-x11-drv-siliconmotion xorg-x11-drv-sis xorg-x11-drv-tdfx xorg-x11-drv-trident
Effectively this means that the graphics team will be focusing on KMS for graphics support, with vesa and fbdev available as last-ditch fallbacks. If anyone is interested in taking on support for these chips, they're welcome to, though we would encourage anyone doing so to work towards KMS support and not merely do "keep it building" maintenance.
Presumably for virtualization environments, the implication is that people should aim to use SPICE + QXL for graphics, and if they really, really, really want to stick with the crappy Cirrus + VNC combo, they will just have to use the vesa Xorg driver.
GNOME Boxes is already doing SPICE + QXL by default for all modern Fedora. We'll need to make sure virt-manager/virt-install are doing the same by default for Fedora, and then we'll be fine wrt virt IMHO.
Regards, Daniel
xorg-x11-drv-geode
geode is used on the OLPC XO-1 and is maintained by Daniel Drake (dsd) and he's basically done all recent commits for upstream releases and fixes unless it's been something like an ABI rebuild or similar. I'm sure he'll take over the maintainership if needed.
Peter
On Tue, Aug 27, 2013 at 9:30 AM, Peter Robinson pbrobinson@gmail.com wrote:
xorg-x11-drv-geode
geode is used on the OLPC XO-1 and is maintained by Daniel Drake (dsd) and he's basically done all recent commits for upstream releases and fixes unless it's been something like an ABI rebuild or similar. I'm sure he'll take over the maintainership if needed.
Yes, I will take that one. Thanks for looking after it over the years.
Daniel
On Tue, 2013-08-27 at 12:58 -0600, Daniel Drake wrote:
On Tue, Aug 27, 2013 at 9:30 AM, Peter Robinson pbrobinson@gmail.com wrote:
xorg-x11-drv-geode
geode is used on the OLPC XO-1 and is maintained by Daniel Drake (dsd) and he's basically done all recent commits for upstream releases and fixes unless it's been something like an ABI rebuild or similar. I'm sure he'll take over the maintainership if needed.
Yes, I will take that one. Thanks for looking after it over the years.
No problem. I'm happy to continue doing drive-by rebuilds for the things we end up keeping, I'm just trying to make sure that what we keep reflects how Fedora is used.
- ajax
On Tue, 2013-08-27 at 10:46 -0400, Adam Jackson wrote:
For F21, I plan to orphan the following X video drivers:
xorg-x11-drv-apm xorg-x11-drv-cirrus xorg-x11-drv-geode xorg-x11-drv-glint xorg-x11-drv-i128 xorg-x11-drv-i740 xorg-x11-drv-mach64 xorg-x11-drv-mga xorg-x11-drv-neomagic xorg-x11-drv-r128 xorg-x11-drv-rendition xorg-x11-drv-s3virge xorg-x11-drv-savage xorg-x11-drv-siliconmotion xorg-x11-drv-sis xorg-x11-drv-tdfx xorg-x11-drv-trident
These have now been orphaned.
One other detail: the intel driver currently has both UMS support for the i810 chipset, and KMS support for everything newer. To be consistent with the above changes I'll be dropping the i810 support, which will then fall back to vesa.
This is done, too.
- ajax
On Thu, Oct 24, 2013 at 04:41:09PM -0400, Adam Jackson wrote:
One other detail: the intel driver currently has both UMS support for the i810 chipset, and KMS support for everything newer. To be consistent with the above changes I'll be dropping the i810 support, which will then fall back to vesa.
This is done, too.
Given that the i810/815 chipsets max out at 512MB RAM (and even then only under specific module combinations) there's no real loss there..
- Solomon
On Thursday, October 24, 2013, 4:41:09 PM, Adam Jackson wrote:
On Tue, 2013-08-27 at 10:46 -0400, Adam Jackson wrote:
For F21, I plan to orphan the following X video drivers: ... xorg-x11-drv-mach64 xorg-x11-drv-r128 ...
These have now been orphaned.
I would like to volunteer to pick up ownership of these two packages. I would also like to assist with the F21 Radeon graphics test day.
I will need someone in turn to volunteer to be my sponsor since I am not (yet) a Fedora packager. Later this week, I will start the full "How to get sponsored into the packager group" process.
I've been experiencing difficulties with a R300-family laptop since Fedora 17 (worked great with Gnome 3 at GA, then regressed, then back to working near F17 EOL). Fedora 18 and 19 did not work, and I've been forced to use Mate.
It comes as no surprise that with limited resources (time, hardware, or interest) the current developers were not able to investigate my bugzilla entry. I had decided in early summer that I would be best served to investigate deeper myself.
I figured that a good place to start would be verification. I've been gathering the necessary resources to test the older Radeon releases (originally R100, R200, R300, and early R600) and it grew into covering the original ATI Mach64 and R128 ranges too.
Between discrete video cards, a few laptops, integrated GPUs and APUs I can now test approximately 30 different Radeon, R128 and Mach 64 video configurations. I am finishing setup of dedicated test hardware for AGP (1X,2X,4X,8X), PCI-E (and naturally PCI). To cover non-x86/x64, I've also got an Apple G5 with AGP 8X Radeon 9650. For display, aside from the usual full and wide screen LCDs, I picked up a Samsung CRT to ensure that side is covered.
This is while also covering the usual real life (work, plus I've been busy all summer doing renovations to my mother-in-law's townhouse (drywall, and some significant rewiring). I can see the light at the end of that tunnel now, and look forward to some time of my own to learn and play. 8^)
While my original intent was to contribute primarily as a tester, I do have a hardware and software background that I hope I can grow to active support and development.
Given time I would like to migrate these over to using KMS. Provided that goes well, the next goal would be to learn OpenGL basics and get up to speed by fixing some mesa issues I have with R300, R200, and R100. Beyond that, the goal would proper mach64 and R128 mesa drivers that would be suitable for reintegration (vs. the obsolete drivers that were removed in Dec 2012).
Al
PS: My EE bachelor's final project (in 1979... sigh) was a S-100 bus video card with text and overlaid grayscale bit graphics. I initially worked at IBM on hardware testing of memory, PC and integrated displays before moving on to mainframe debuggers and the C/C++ compiler group. It's been a while, but I'm hoping that some of that will still prove relevant and useful. 8^)
On Monday, October 28, 2013, 10:07:05 PM, I began...
I left IBM in 2002. Since then, I have joined RBC, and spend my days developing a mainframe file/data server (written in C and assembler - about 250 KLOC) and a few bits and pieces on AIX.
I'm still a quite active coder, just not so much hardware oriented.
devel@lists.stg.fedoraproject.org
-
Adam Jackson -
Adam Williamson -
Al Dunsmuir -
Basil Mohamed Gohar -
Brian Wheeler -
Bruno Wolff III -
Daniel Drake -
Daniel P. Berrange -
drago01 -
John.Florian＠dart.biz -
Jóhann B. Guðmundsson -
Matthew Garrett -
Pavel Alexeev -
Peter Robinson -
Solomon Peachy