Yes, it is now that legendary time, well loved by the hearts of men for millennia(*): Graphics Test Week!
Tomorrow - 2009-09-09 - is ATI/AMD Radeon graphics card Test Day (1). Thursday - 2009-09-10 - is NVIDIA graphics card Test Day (2). And Friday - 2009-09-11 - is Intel graphics card Test Day (3). I am currently rolling up a pair of live CD images that will likely be used for all three days; they should be uploaded soon. Please, please grab the live CDs, do the testing, and come out to the Test Day(s) for the graphics hardware you own! As always, graphics are a critical piece of Fedora and we want to make sure Fedora 12 works on as wide a range of graphics hardware as possible.
The testing's very easy to do and it shouldn't take more than an hour of your time to boot the live CD and run the tests. There's no need to install anything to hard disk. You don't even need to be a Fedora user to take part, and what's in Fedora's drivers today will be in everyone else's tomorrow, so helping us test this benefits all distributions down the road.
The Test Day gatherings themselves are held in IRC, in channel #fedora-test-day on the Freenode network. Please do join in if you can - we can help advise you with any questions you have, and if you run into bugs, the developers can investigate them with you right away. If you can't make it out for the actual day, though, you can still do the testing, and your results are still useful! Just download the live image, do the tests, and fill in the results table as the page instructs. Many thanks to everyone who's able to make it out and do the testing. Remember - tomorrow ATI; Thursday NVIDIA; Friday Intel.
* - well, okay. Not really millennia. More like...months.
(1) - https://fedoraproject.org/wiki/Test_Day:2009-09-09_Radeon (2) - https://fedoraproject.org/wiki/Test_Day:2009-09-10_Nouveau (3) - https://fedoraproject.org/wiki/Test_Day:2009-09-11_Intel
On Tue, 08 Sep 2009 14:26:06 -0700 Adam Williamson wrote:
The testing's very easy to do and it shouldn't take more than an hour of your time to boot the live CD and run the tests.
If ATI hasn't improved a lot since the alpha release, it will only take me a few seconds - fedora 12 alpha on my original ATI All-In-Wonder radeon 7200 pukes its guts out during the graphics hardware probe stage while booting (fedora 11 works OK with nomodeset and xdriver=vesa, but that doesn't help on 12).
On Wed, 2009-09-09 at 08:02 -0400, Tom Horsley wrote:
On Tue, 08 Sep 2009 14:26:06 -0700 Adam Williamson wrote:
The testing's very easy to do and it shouldn't take more than an hour of your time to boot the live CD and run the tests.
If ATI hasn't improved a lot since the alpha release, it will only take me a few seconds - fedora 12 alpha on my original ATI All-In-Wonder radeon 7200 pukes its guts out during the graphics hardware probe stage while booting (fedora 11 works OK with nomodeset and xdriver=vesa, but that doesn't help on 12).
Try radeon.nomodeset=0 (the Alpha has a bug which makes nomodeset not work).
But yes, the code in the test day live build is actually pretty different from the Alpha, and it's possible it may work.
On Wed, 2009-09-09 at 09:06 -0700, Adam Williamson wrote:
On Wed, 2009-09-09 at 08:02 -0400, Tom Horsley wrote:
On Tue, 08 Sep 2009 14:26:06 -0700 Adam Williamson wrote:
The testing's very easy to do and it shouldn't take more than an hour of your time to boot the live CD and run the tests.
If ATI hasn't improved a lot since the alpha release, it will only take me a few seconds - fedora 12 alpha on my original ATI All-In-Wonder radeon 7200 pukes its guts out during the graphics hardware probe stage while booting (fedora 11 works OK with nomodeset and xdriver=vesa, but that doesn't help on 12).
Try radeon.nomodeset=0 (the Alpha has a bug which makes nomodeset not work).
Erf, sorry - that should be 'radeon.modeset=0' .
On 09/08/2009 03:26 PM, Adam Williamson wrote:
Yes, it is now that legendary time, well loved by the hearts of men for millennia(*): Graphics Test Week!
Tomorrow - 2009-09-09 - is ATI/AMD Radeon graphics card Test Day (1).
Using 2009-09-09 ISO, when passing 'radeon.modeset=1' as boot param, I get "Unknown boot option 'radeon.modeset=1'. Ignoring..." Is that expected?
Using 2009-09-09 ISO, when passing 'radeon.modeset=1' as boot param, I get "Unknown boot option 'radeon.modeset=1'. Ignoring..." Is that expected?
In the end you still might have modesettings enabled. What dmesg gives you ? something like :
/var/log/dmesg |grep drm
I red somewhere about a space after this argument, i'm not sure it help but you can try.
'radeon.modeset=1' to 'radeon.modeset=1 '
regards Flo
2009/9/10 Dariusz J. Garbowski thuforuk@yahoo.co.uk:
On 09/08/2009 03:26 PM, Adam Williamson wrote:
Yes, it is now that legendary time, well loved by the hearts of men for millennia(*): Graphics Test Week!
Tomorrow - 2009-09-09 - is ATI/AMD Radeon graphics card Test Day (1).
Using 2009-09-09 ISO, when passing 'radeon.modeset=1' as boot param, I get "Unknown boot option 'radeon.modeset=1'. Ignoring..." Is that expected?
Yes, because the kernel don't know this option, but it will pass it trough the X driver, which will take care of it.
-- Regards, Niels
On Thu, 2009-09-10 at 08:49 -0600, Dariusz J. Garbowski wrote:
On 09/08/2009 03:26 PM, Adam Williamson wrote:
Yes, it is now that legendary time, well loved by the hearts of men for millennia(*): Graphics Test Week!
Tomorrow - 2009-09-09 - is ATI/AMD Radeon graphics card Test Day (1).
Using 2009-09-09 ISO, when passing 'radeon.modeset=1' as boot param, I get "Unknown boot option 'radeon.modeset=1'. Ignoring..." Is that expected?
(sending to all lists as this is #1 Top Question...)
Yes, it is. The 'science bit' is that the kernel itself truly doesn't understand the parameter, which is why you see this message - but the radeon. prefix means it gets automatically passed on to the radeon module, which _does_ understand (and interprets) it.
Personally I consider this a kernel bug, it shouldn't display this message for parameters which will be passed to modules.
radeon.modeset=1 is a no-op, though, modesetting is now default for Radeon chips. So only radeon.modeset=0 (to disable it) makes any sense. Did I leave radeon.modeset=1 in one of the test cases?
On 09/10/2009 09:10 AM, Adam Williamson wrote:
On Thu, 2009-09-10 at 08:49 -0600, Dariusz J. Garbowski wrote:
On 09/08/2009 03:26 PM, Adam Williamson wrote:
Yes, it is now that legendary time, well loved by the hearts of men for millennia(*): Graphics Test Week!
Tomorrow - 2009-09-09 - is ATI/AMD Radeon graphics card Test Day (1).
Using 2009-09-09 ISO, when passing 'radeon.modeset=1' as boot param, I get "Unknown boot option 'radeon.modeset=1'. Ignoring..." Is that expected?
(sending to all lists as this is #1 Top Question...)
Yes, it is. The 'science bit' is that the kernel itself truly doesn't understand the parameter, which is why you see this message - but the radeon. prefix means it gets automatically passed on to the radeon module, which _does_ understand (and interprets) it.
Personally I consider this a kernel bug, it shouldn't display this message for parameters which will be passed to modules.
Thanks to all who responded with explanation. This indeed is confusing and I agree with you that this deserves a "bug" status...
radeon.modeset=1 is a no-op, though, modesetting is now default for Radeon chips. So only radeon.modeset=0 (to disable it) makes any sense. Did I leave radeon.modeset=1 in one of the test cases?
Errr... I thought I saw it there yesterday but I might be wrong (I have taken a not of this the day before). I can't see it anywhere today.
BTW: my test report on wiki.
On Thu, 2009-09-10 at 22:15 -0600, Dariusz J. Garbowski wrote:
radeon.modeset=1 is a no-op, though, modesetting is now default for Radeon chips. So only radeon.modeset=0 (to disable it) makes any sense. Did I leave radeon.modeset=1 in one of the test cases?
Errr... I thought I saw it there yesterday but I might be wrong (I have taken a not of this the day before). I can't see it anywhere today.
Yeah, after I wrote the above mail I found where I'd left it in, and took it out :) Thanks for the heads-up.
BTW: my test report on wiki.
Thanks!
On Thu, 2009-09-10 at 22:15 -0600, Dariusz J. Garbowski wrote:
Yes, it is. The 'science bit' is that the kernel itself truly doesn't understand the parameter, which is why you see this message - but the radeon. prefix means it gets automatically passed on to the radeon module, which _does_ understand (and interprets) it.
Personally I consider this a kernel bug, it shouldn't display this message for parameters which will be passed to modules.
Thanks to all who responded with explanation. This indeed is confusing and I agree with you that this deserves a "bug" status...
http://bugzilla.kernel.org/show_bug.cgi?id=14164