Ok, controversial title.
I have just tried to test install F12 on some of my systems, (5 different ones). All of these bar 1 has problems with the graphics (X11 lockups, system lockups and other problems) mainly in 3D but also in 2D. I still am using F8 on most of my systems as the Graphics systems have not been stable enough for 3D in Fedora since around those times.
I know there is a lot of work going on in the graphics front, I myself have worked on and fed back issues as time and ability allow. During F11 I helped with some issues, but unfortunately none of these made it back into updates for F11 and now F12 is out with yet more issues.
The Linux kernel is generally relatively stable, as is the main system libraries etc in Fedora. The core issues most people seem to be facing is Graphics and Sound issues. Obviously a major issue with Graphics is the sheer number of different graphics chip sets in use and the lack of documentation for quite a few of them. Due to this it requires a lot of user testing and feedback to get these issues sorted out. Unfortunately the very fast Fedora new release schedule gets in the way of getting this testing done and things do not get fixed prior to a new release which introduces yet another set of problems. The new release speed also uses a lot of developer and user time in just managing to create a new release and updating systems to use it.
I know the quick release cycle is one of Fedora's features in its aim to be close to the leading edge, but this has to be balanced with usability otherwise there will be few people actually using it in anger and thus actually testing the software. This could lead to the demise of Fedora.
As an idea, at this stage, how about canceling the F13 release and just fixing and updating the F12 release ? This will concentrate developers and users into one system release. Similar to the pre-release test days we could have post-release test days. For example a Graphics test day for F12 where a certain set of tests with a test suite and a set of well known applications could be run. As F12 would be out longer, more people could participate in this. If a commitment, all round, to producing updates fixing the issues in F12 were made, I think more people would be willing to participate as users could expect to see a stable system for their efforts.
On Thu, Nov 26, 2009 at 02:01:00PM +0000, Terry Barnaby wrote:
another set of problems. The new release speed also uses a lot of developer and user time in just managing to create a new release and updating systems to use it.
This is the key flaw in your suggestion. Fedora developer effort isn't as malleable as you seem to think -- managing a new release is very different from fixing graphics bugs, and even if everyone involved in a different aspect of the project _wanted_ to switch to graphics driver programming _and_ was qualified to do so _and_ was able to get up to speed in a reasonable time, you can't necessarily solve programming problems faster by multiplying the number of developers.
On the other hand, having a release which emphasizes stability over new features is an idea that's been around for a while. It may be a good idea occasionally, but one of the problems you get is that new development in general doesn't stop and wait for stabilization, so the _next_ release, where you open things up again, ends up extra-unstable as all that new stuff hits at once.
On 11/26/2009 02:12 PM, Matthew Miller wrote:
On Thu, Nov 26, 2009 at 02:01:00PM +0000, Terry Barnaby wrote:
another set of problems. The new release speed also uses a lot of developer and user time in just managing to create a new release and updating systems to use it.
This is the key flaw in your suggestion. Fedora developer effort isn't as malleable as you seem to think -- managing a new release is very different from fixing graphics bugs, and even if everyone involved in a different aspect of the project _wanted_ to switch to graphics driver programming _and_ was qualified to do so _and_ was able to get up to speed in a reasonable time, you can't necessarily solve programming problems faster by multiplying the number of developers.
That is true, but a major amount of work in getting a release out must be testing it. Those Fedora people involved in the testing, which are also user-testers, have their own systems with there own hardware and are fully conversant with delving into bugs and reporting them in the correct way.
On the other hand, having a release which emphasizes stability over new features is an idea that's been around for a while. It may be a good idea occasionally, but one of the problems you get is that new development in general doesn't stop and wait for stabilization, so the _next_ release, where you open things up again, ends up extra-unstable as all that new stuff hits at once.
No things don't stop and they shouldn't. But at least it gives a reference platform to assist with future developments and bug fixing and also a stable release that people can recommend. I am unable to recommend F9, F10, F11, or F12 ...
On 11/26/2009 07:54 PM, Terry Barnaby wrote:
That is true, but a major amount of work in getting a release out must be testing it. Those Fedora people involved in the testing, which are also user-testers, have their own systems with there own hardware and are fully conversant with delving into bugs and reporting them in the correct way.
Yes. So let them go ahead and do it. Development can continue in parallel for the next release and that integration testing in the development branch often helps the older branches get more stable when fixes are pushed as updates. Your proposal if it was indeed a serious one doesn't help with anything.
Rahul
There is an interesting thread on the developers list entitled "Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?"
LG
Matthew Miller wrote:
On the other hand, having a release which emphasizes stability over new features is an idea that's been around for a while.
That's actually mostly what F12 has been, partly due to RHEL scheduling, partly due to the shortened release schedule to realign with our target dates and partly due to accidents of scheduling. For example, KDE hasn't received any major changes (e.g. KOffice 2 was punted to F13), only new minor versions (like KDE 4.3) which have also been pushed to F11 updates. You won't get much more conservative in Fedora land.
but one of the problems you get is that new development in general doesn't stop and wait for stabilization, so the _next_ release, where you open things up again, ends up extra-unstable as all that new stuff hits at once.
In fact that has already happened to some extent: F8 was a release with a shortened release schedule which had a reputation of being very stable, F9 was a lot more groundbreaking with brand new stuff like KDE 4, a new release of X11, Upstart, a rewritten GDM etc. The cool new stuff also came with some funkiness, which thankfully mostly got sorted out by updates.
Kevin Kofler
2009/11/26 Terry Barnaby terry1@beam.ltd.uk:
Ok, controversial title.
I have just tried to test install F12 on some of my systems, (5 different ones). All of these bar 1 has problems with the graphics (X11 lockups, system lockups and other problems) mainly in 3D but also in 2D. I still am using F8 on most of my systems as the Graphics systems have not been stable enough for 3D in Fedora since around those times.
which cards exactly did you try? which drivers do you use... and what are the bugzilla bug numbers?
As an idea, at this stage, how about canceling the F13 release and just fixing and updating the F12 release ? This will concentrate developers and users into one system release. Similar to the pre-release test days we could have post-release test days. For example a Graphics test day for F12 where a certain set of tests with a test suite and a set of well known applications could be run. As F12 would be out longer, more people could participate in this.
i dont see the point because that will definitely lead to new regressions in f12 and annoy other people. interested partys can at any time of the development cycle test the current state of development (aka rawhide) and report and fix bugs in it.
my personal experience is:
intel (i965) works fine... there are some problems with shaders i have to investigate and there is a problem with interlaced resolutions. even displayport output works (hooked up to a fullhd tv via displayport -> hdmi adapter)
radeon 4650 works fine... even 3d works to some extent with the experimental dri drivers.... testing a new mesa build from koji even fixed various issues with 3d games i had left... also some effects/shaders seem to be not properly implemented yet... but hey... it is experimental)
nvidia: nouveau kernel mode setting works and 2d experience is alot better already.
2d works in all setups i have personally tested. 3d still requires some progress but i dont see how it helps to stay on one release to get them resolved.
kind regards, Rudolf Kastl
If a commitment, all round, to producing updates fixing the issues in F12 were made, I think more people would be willing to participate as users could expect to see a stable system for their efforts.
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On 11/26/2009 02:14 PM, Rudolf Kastl wrote:
2009/11/26 Terry Barnabyterry1@beam.ltd.uk:
Ok, controversial title.
I have just tried to test install F12 on some of my systems, (5 different ones). All of these bar 1 has problems with the graphics (X11 lockups, system lockups and other problems) mainly in 3D but also in 2D. I still am using F8 on most of my systems as the Graphics systems have not been stable enough for 3D in Fedora since around those times.
which cards exactly did you try? which drivers do you use... and what are the bugzilla bug numbers?
The "cards" I have tried include: Intel Corporation 82945G/GZ Integrated Graphics Controller ATI Technologies Inc RV535 [Radeon X1650 Series] ATI Technologies Inc M22 [Mobility Radeon X300] ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01) VGA compatible controller: Intel Corporation 82G33/G31 Express Integrated Graphics Controller (rev 02)
I have not entered any bugzilla numbers as yet. I spent days with F11 and previous releases diagnosing reporting and attempting to fix bugs. No graphics updates were ever made available for F11 and still Fedora cannot run even Blender on most of my machines. At the moment I am not convinced that it is worth spending this time on F12. It seems likely no updates will appear and in F13 the whole ball game may have changed anyway.
As an idea, at this stage, how about canceling the F13 release and just fixing and updating the F12 release ? This will concentrate developers and users into one system release. Similar to the pre-release test days we could have post-release test days. For example a Graphics test day for F12 where a certain set of tests with a test suite and a set of well known applications could be run. As F12 would be out longer, more people could participate in this.
i dont see the point because that will definitely lead to new regressions in f12 and annoy other people. interested partys can at any time of the development cycle test the current state of development (aka rawhide) and report and fix bugs in it.
For testing Graphics you need a lot of "testers". I would not have thought that the number of people testing rawhide is enough. I would have thought that real users actually using Fedora are required here. Certainly the F12 release seems to reflect the lack of 3D graphics testing ...
my personal experience is:
intel (i965) works fine... there are some problems with shaders i have to investigate and there is a problem with interlaced resolutions. even displayport output works (hooked up to a fullhd tv via displayport -> hdmi adapter)
radeon 4650 works fine... even 3d works to some extent with the experimental dri drivers.... testing a new mesa build from koji even fixed various issues with 3d games i had left... also some effects/shaders seem to be not properly implemented yet... but hey... it is experimental)
nvidia: nouveau kernel mode setting works and 2d experience is alot better already.
2d works in all setups i have personally tested. 3d still requires some progress but i dont see how it helps to stay on one release to get them resolved.
Yes, some graphics boards I am sure work well, although 3D should really be working on all cards in 2009 ... But this is the point, there are a lot of different graphics boards, and so a much wider scope for the testing is required here which requires more users over more time with many different applications using basically the same software.
kind regards, Rudolf Kastl
If a commitment, all round, to producing updates fixing the issues in F12 were made, I think more people would be willing to participate as users could expect to see a stable system for their efforts.
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On 11/26/2009 08:09 PM, Terry Barnaby wrote:
I have not entered any bugzilla numbers as yet. I spent days with F11 and previous releases diagnosing reporting and attempting to fix bugs. No graphics updates were ever made available for F11 and still Fedora cannot run even Blender on most of my machines. At the moment I am not convinced that it is worth spending this time on F12. It seems likely no updates will appear and in F13 the whole ball game may have changed anyway.
Seems a bunch of incorrect assumptions considering that Fedora 11 did get many updates and I already see updates for Fedora 12 in updates-testing repository. Specific bug reports are definitely going to help.
Rahul
On 11/26/2009 02:43 PM, Rahul Sundaram wrote:
On 11/26/2009 08:09 PM, Terry Barnaby wrote:
I have not entered any bugzilla numbers as yet. I spent days with F11 and previous releases diagnosing reporting and attempting to fix bugs. No graphics updates were ever made available for F11 and still Fedora cannot run even Blender on most of my machines. At the moment I am not convinced that it is worth spending this time on F12. It seems likely no updates will appear and in F13 the whole ball game may have changed anyway.
Seems a bunch of incorrect assumptions considering that Fedora 11 did get many updates and I already see updates for Fedora 12 in updates-testing repository. Specific bug reports are definitely going to help.
Rahul
Sorry, should have been more specific. On the graphics package front, there have been no ATI or Intel X11 driver updates in F11 so far. Mesa was last updated 14th of June. Not sure about DRM as that is in the kernel and may have been updated with kernel updates. Yes, clear bug reports are needed but they also need the follow through to a fix and updated packages.
On Thu, Nov 26, 2009 at 03:04:43PM +0000, Terry Barnaby wrote:
On 11/26/2009 02:43 PM, Rahul Sundaram wrote:
On 11/26/2009 08:09 PM, Terry Barnaby wrote:
I have not entered any bugzilla numbers as yet. I spent days with F11 and previous releases diagnosing reporting and attempting to fix bugs. No graphics updates were ever made available for F11 and still Fedora cannot run even Blender on most of my machines. At the moment I am not convinced that it is worth spending this time on F12. It seems likely no updates will appear and in F13 the whole ball game may have changed anyway.
Seems a bunch of incorrect assumptions considering that Fedora 11 did get many updates and I already see updates for Fedora 12 in updates-testing repository. Specific bug reports are definitely going to help.
Rahul
Sorry, should have been more specific. On the graphics package front, there have been no ATI or Intel X11 driver updates in F11 so far. Mesa was last updated 14th of June. Not sure about DRM as that is in the kernel and may have been updated with kernel updates.
xorg-x11-drv-intel-2.7.0-9.fc11 ajax 2009-11-20 20:35:24 xorg-x11-drv-intel-2.7.0-8.fc11 mjg59 2009-09-24 20:58:55 xorg-x11-drv-intel-2.7.0-7.fc11 krh 2009-05-28 19:32:16
xorg-x11-drv-ati-6.12.2-18.fc11 airlied 2009-06-29 02:40:01
And from kernel changelogs: * Fri Sep 25 2009 Chuck Ebbert cebbert@redhat.com 2.6.30.8-63 - Disable the GEM graphics manager on i686 PAE kernels (fixes modesetting on Intel graphics.)
* Fri Aug 14 2009 Chuck Ebbert cebbert@redhat.com 2.6.30.5-28.rc2 - Linux 2.6.30.5-rc2 - Dropped drm-intel-tv-fix.patch, merged in -stable now.
Wed Aug 12 2009 Kyle McMartin kyle@redhat.com - DRM patch sync-up with F-11-2.6.29.y, ABI probably isn't right yet though... - drm-modesetting-radeon.patch - drm-nouveau.patch - drm-no-gem-on-i8xx.patch - drm-i915-resume-force-mode.patch - drm-intel-big-hammer.patch - drm-intel-gen3-fb-hack.patch - drm-intel-hdmi-edid-fix.patch - drm-modesetting-radeon-fixes.patch - drm-radeon-new-pciids.patch - drm-dont-frob-i2c.patch - drm-intel-tv-fix.patch - drm-radeon-cs-oops-fix.patch - drm-pnp-add-resource-range-checker.patch - drm-i915-enable-mchbar.patch - The rest were merged upstream.
Anyway, I understand you sentiment. I was bitten by Intel graphics bug (EQ overflowing) which wasn't fixed for all F11 life. Things are much better in F12 now. But still, without any bug number we have nothing to talk about.
On 11/26/2009 03:11 PM, Tomasz Torcz wrote:
On Thu, Nov 26, 2009 at 03:04:43PM +0000, Terry Barnaby wrote:
On 11/26/2009 02:43 PM, Rahul Sundaram wrote:
On 11/26/2009 08:09 PM, Terry Barnaby wrote:
I have not entered any bugzilla numbers as yet. I spent days with F11 and previous releases diagnosing reporting and attempting to fix bugs. No graphics updates were ever made available for F11 and still Fedora cannot run even Blender on most of my machines. At the moment I am not convinced that it is worth spending this time on F12. It seems likely no updates will appear and in F13 the whole ball game may have changed anyway.
Seems a bunch of incorrect assumptions considering that Fedora 11 did get many updates and I already see updates for Fedora 12 in updates-testing repository. Specific bug reports are definitely going to help.
Rahul
Sorry, should have been more specific. On the graphics package front, there have been no ATI or Intel X11 driver updates in F11 so far. Mesa was last updated 14th of June. Not sure about DRM as that is in the kernel and may have been updated with kernel updates.
xorg-x11-drv-intel-2.7.0-9.fc11 ajax 2009-11-20 20:35:24 xorg-x11-drv-intel-2.7.0-8.fc11 mjg59 2009-09-24 20:58:55 xorg-x11-drv-intel-2.7.0-7.fc11 krh 2009-05-28 19:32:16
xorg-x11-drv-ati-6.12.2-18.fc11 airlied 2009-06-29 02:40:01
And from kernel changelogs:
- Fri Sep 25 2009 Chuck Ebbertcebbert@redhat.com 2.6.30.8-63
- Disable the GEM graphics manager on i686 PAE kernels (fixes modesetting on Intel graphics.)
- Fri Aug 14 2009 Chuck Ebbertcebbert@redhat.com 2.6.30.5-28.rc2
Linux 2.6.30.5-rc2
Dropped drm-intel-tv-fix.patch, merged in -stable now.
Wed Aug 12 2009 Kyle McMartinkyle@redhat.com
DRM patch sync-up with F-11-2.6.29.y, ABI probably isn't right yet though...
- drm-modesetting-radeon.patch
- drm-nouveau.patch
- drm-no-gem-on-i8xx.patch
- drm-i915-resume-force-mode.patch
- drm-intel-big-hammer.patch
- drm-intel-gen3-fb-hack.patch
- drm-intel-hdmi-edid-fix.patch
- drm-modesetting-radeon-fixes.patch
- drm-radeon-new-pciids.patch
- drm-dont-frob-i2c.patch
- drm-intel-tv-fix.patch
- drm-radeon-cs-oops-fix.patch
- drm-pnp-add-resource-range-checker.patch
- drm-i915-enable-mchbar.patch
The rest were merged upstream.
Anyway, I understand you sentiment. I was bitten by Intel graphics bug (EQ overflowing)
which wasn't fixed for all F11 life. Things are much better in F12 now. But still, without any bug number we have nothing to talk about.
Mind you the above xorg packages are not in F11 updates ... I note that there is a package in fedora-testing for xorg-x11-drv-intel but I can't see anything for xorg-x11-drv-ati is this somewhere else ? For me F12 seems worse than F11, so far on this aspect. I'm sure others mileage will vary in the same manner as the number of different graphics boards :)
As you obviously know tracking down and reporting bugs like these do take a lot of time and effort, quite often more than actually fixing them. At the moment with the frequency of Fedora releases and the lack of a push to testing and stability on this front I am not enthused, at the moment, with doing this and I suspect many others feel the same.
Cheers
Terry
On Thu, Nov 26, 2009 at 04:08:27PM +0000, Terry Barnaby wrote:
As you obviously know tracking down and reporting bugs like these do take a lot of time and effort, quite often more than actually fixing them. At the moment with the frequency of Fedora releases and the lack of a push to testing and stability on this front I am not enthused, at the moment, with doing this and I suspect many others feel the same.
I'm confused. You want Fedora to skip a release to focus on testing and fixing, and you have no plans to help and aren't enthusiastic about actually participating in the testing and fixing?
josh
On 11/26/2009 04:34 PM, Josh Boyer wrote:
On Thu, Nov 26, 2009 at 04:08:27PM +0000, Terry Barnaby wrote:
As you obviously know tracking down and reporting bugs like these do take a lot of time and effort, quite often more than actually fixing them. At the moment with the frequency of Fedora releases and the lack of a push to testing and stability on this front I am not enthused, at the moment, with doing this and I suspect many others feel the same.
I'm confused. You want Fedora to skip a release to focus on testing and fixing, and you have no plans to help and aren't enthusiastic about actually participating in the testing and fixing?
josh
I really want to help and get a stable release and present bug reports and even fix them if I can. But, the current short term release schedule, and no focus on testing and fixing graphics issues, does not inspire me with confidence that a stable usable release will emerge. This makes it difficult for me to justify the effort. Convince me :)
On Thu, Nov 26, 2009 at 17:09:14 +0000, Terry Barnaby terry1@beam.ltd.uk wrote:
I really want to help and get a stable release and present bug reports and even fix them if I can. But, the current short term release schedule, and no focus on testing and fixing graphics issues, does not inspire me with confidence that a stable usable release will emerge. This makes it difficult for me to justify the effort. Convince me :)
I follow the radeon updates pretty closely and my 9200 finally starting working with 3d again a few weeks before the release. Airlie has continued development in the f12 branch and there have been several updates over the last couple of weeks. If you have just tried F11 and not F12 you should consider doing so. For r5xx and below, grab a live image and install one of the smaller 3d apps and try it out. For r6xx and above you'll want to install mesa-experimental-drivers and update xorg-x11-drv-ati. This won't get you the kernel updates related to graphics since the release, but should give you a good look at where things are at so that you can decide if you want install F12 on the machine.
On Thu, Nov 26, 2009 at 13:46:54 -0600, Bruno Wolff III bruno@wolff.to wrote:
mesa-experimental-drivers and update xorg-x11-drv-ati. This won't get you
That should be: mesa-dri-drivers-experimental
On 11/26/2009 07:46 PM, Bruno Wolff III wrote:
On Thu, Nov 26, 2009 at 17:09:14 +0000, Terry Barnabyterry1@beam.ltd.uk wrote:
I really want to help and get a stable release and present bug reports and even fix them if I can. But, the current short term release schedule, and no focus on testing and fixing graphics issues, does not inspire me with confidence that a stable usable release will emerge. This makes it difficult for me to justify the effort. Convince me :)
I follow the radeon updates pretty closely and my 9200 finally starting working with 3d again a few weeks before the release. Airlie has continued development in the f12 branch and there have been several updates over the last couple of weeks. If you have just tried F11 and not F12 you should consider doing so. For r5xx and below, grab a live image and install one of the smaller 3d apps and try it out. For r6xx and above you'll want to install mesa-experimental-drivers and update xorg-x11-drv-ati. This won't get you the kernel updates related to graphics since the release, but should give you a good look at where things are at so that you can decide if you want install F12 on the machine.
Hi,
I have tried out F12 on 4 different systems, 2 with different ATI graphics and two with different Intel based boards. Only the last one appears to be able to run Blender. You mention "Airlie has continued development in the f12 branch". If that means there are people working on the bugs and producing new driver updates for F12 (DRM,MESA,X11), especially for ATI then I certainly will give it some time.
On Thu, Nov 26, 2009 at 20:16:54 +0000, Terry Barnaby terry1@beam.ltd.uk wrote:
I have tried out F12 on 4 different systems, 2 with different ATI graphics and two with different Intel based boards. Only the last one appears to be able to run Blender. You mention "Airlie has continued development in the f12 branch". If that means there are people working on the bugs and producing new driver updates for F12 (DRM,MESA,X11), especially for ATI then I certainly will give it some time.
Yes there have been updates to all of those (and the X server and the kernel) since the F12 release, though I am not sure that all have made it to the updates repository. I typically pull that stuff right from koji when I see it show up.
I don't usually mess with blender, though I am starting to learn about Ogre.
On Thu, 2009-11-26 at 20:16 +0000, Terry Barnaby wrote:
On 11/26/2009 07:46 PM, Bruno Wolff III wrote:
On Thu, Nov 26, 2009 at 17:09:14 +0000, Terry Barnabyterry1@beam.ltd.uk wrote:
I really want to help and get a stable release and present bug reports and even fix them if I can. But, the current short term release schedule, and no focus on testing and fixing graphics issues, does not inspire me with confidence that a stable usable release will emerge. This makes it difficult for me to justify the effort. Convince me :)
I follow the radeon updates pretty closely and my 9200 finally starting working with 3d again a few weeks before the release. Airlie has continued development in the f12 branch and there have been several updates over the last couple of weeks. If you have just tried F11 and not F12 you should consider doing so. For r5xx and below, grab a live image and install one of the smaller 3d apps and try it out. For r6xx and above you'll want to install mesa-experimental-drivers and update xorg-x11-drv-ati. This won't get you the kernel updates related to graphics since the release, but should give you a good look at where things are at so that you can decide if you want install F12 on the machine.
Hi,
I have tried out F12 on 4 different systems, 2 with different ATI graphics and two with different Intel based boards. Only the last one appears to be able to run Blender. You mention "Airlie has continued development in the f12 branch". If that means there are people working on the bugs and producing new driver updates for F12 (DRM,MESA,X11), especially for ATI then I certainly will give it some time.
So is blender working the only thing you consider as working?
The current focus is on making graphics work for as many ppl as possible first, then 3D is always further down the list, this is just common sense.
Current priorities are: 0) you aren't running a binary driver - if so no priority for you.
a) Can you see stuff on the screen at install/boot? b) can you run GNOME desktop in reasonably useful manner? i.e. firefox runs okay, no glitches, major slowdowns etc. c) can you suspend/resume? d) can you run compiz/gnome-shell? e) can you run non-Gnome desktops at reasonable speed? (yes we have to prioritise gnome over KDE, it sucks but thats life) f) does misc 3D application run?
So yes I'm sorry 3D generally does end up at the end of the list, but if everything else on your desktops work except that, then I suggest you try and lead some sort of 3D testing group and maybe feedback upstream when your favourite apps breaks.
The big mesa problem for F11 was we pushed one mesa update to fix some r300 bugs, and it broke some Intel, we just cannot get the regression testing necessary with the current Fedora updates/updates-testing system, we are hoping per-user repos stuff will solve some of that.
Dave.
On Fri, 2009-11-27 at 07:23 +1000, Dave Airlie wrote:
On Thu, 2009-11-26 at 20:16 +0000, Terry Barnaby wrote:
On 11/26/2009 07:46 PM, Bruno Wolff III wrote:
On Thu, Nov 26, 2009 at 17:09:14 +0000, Terry Barnabyterry1@beam.ltd.uk wrote:
I really want to help and get a stable release and present bug reports and even fix them if I can. But, the current short term release schedule, and no focus on testing and fixing graphics issues, does not inspire me with confidence that a stable usable release will emerge. This makes it difficult for me to justify the effort. Convince me :)
I follow the radeon updates pretty closely and my 9200 finally starting working with 3d again a few weeks before the release. Airlie has continued development in the f12 branch and there have been several updates over the last couple of weeks. If you have just tried F11 and not F12 you should consider doing so. For r5xx and below, grab a live image and install one of the smaller 3d apps and try it out. For r6xx and above you'll want to install mesa-experimental-drivers and update xorg-x11-drv-ati. This won't get you the kernel updates related to graphics since the release, but should give you a good look at where things are at so that you can decide if you want install F12 on the machine.
Hi,
I have tried out F12 on 4 different systems, 2 with different ATI graphics and two with different Intel based boards. Only the last one appears to be able to run Blender. You mention "Airlie has continued development in the f12 branch". If that means there are people working on the bugs and producing new driver updates for F12 (DRM,MESA,X11), especially for ATI then I certainly will give it some time.
So is blender working the only thing you consider as working?
The current focus is on making graphics work for as many ppl as possible first, then 3D is always further down the list, this is just common sense.
Current priorities are: 0) you aren't running a binary driver - if so no priority for you.
a) Can you see stuff on the screen at install/boot? b) can you run GNOME desktop in reasonably useful manner? i.e. firefox runs okay, no glitches, major slowdowns etc. c) can you suspend/resume? d) can you run compiz/gnome-shell? e) can you run non-Gnome desktops at reasonable speed? (yes we have to prioritise gnome over KDE, it sucks but thats life) f) does misc 3D application run?
I should follow up just as far as the Red Hat X team goes a-d are what we are paid to do, e/f and nice to haves, so really if some community effort was to be brought up around this, e/f are where it would make sense to focus it.
Having some sort of repos where we can publish a new kernel/libdrm/mesa/intel/ati/nouveau package in one block for people to test and find regression that isn't rawhide and isn't updates-testing (since it would be abusing that) would be an excellent place to start.
Dave.
On Thursday 26 November 2009 23:14:09 Dave Airlie wrote:
On Fri, 2009-11-27 at 07:23 +1000, Dave Airlie wrote:
On Thu, 2009-11-26 at 20:16 +0000, Terry Barnaby wrote:
On 11/26/2009 07:46 PM, Bruno Wolff III wrote:
On Thu, Nov 26, 2009 at 17:09:14 +0000,
Terry Barnabyterry1@beam.ltd.uk wrote:
I really want to help and get a stable release and present bug reports and even fix them if I can. But, the current short term release schedule, and no focus on testing and fixing graphics issues, does not inspire me with confidence that a stable usable release will emerge. This makes it difficult for me to justify the effort. Convince me :)
I follow the radeon updates pretty closely and my 9200 finally starting working with 3d again a few weeks before the release. Airlie has continued development in the f12 branch and there have been several updates over the last couple of weeks. If you have just tried F11 and not F12 you should consider doing so. For r5xx and below, grab a live image and install one of the smaller 3d apps and try it out. For r6xx and above you'll want to install mesa-experimental-drivers and update xorg-x11-drv-ati. This won't get you the kernel updates related to graphics since the release, but should give you a good look at where things are at so that you can decide if you want install F12 on the machine.
Hi,
I have tried out F12 on 4 different systems, 2 with different ATI graphics and two with different Intel based boards. Only the last one appears to be able to run Blender. You mention "Airlie has continued development in the f12 branch". If that means there are people working on the bugs and producing new driver updates for F12 (DRM,MESA,X11), especially for ATI then I certainly will give it some time.
So is blender working the only thing you consider as working?
The current focus is on making graphics work for as many ppl as possible first, then 3D is always further down the list, this is just common sense.
Current priorities are: 0) you aren't running a binary driver - if so no priority for you.
a) Can you see stuff on the screen at install/boot? b) can you run GNOME desktop in reasonably useful manner? i.e. firefox runs okay, no glitches, major slowdowns etc. c) can you suspend/resume? d) can you run compiz/gnome-shell? e) can you run non-Gnome desktops at reasonable speed? (yes we have to prioritise gnome over KDE, it sucks but thats life) f) does misc 3D application run?
I should follow up just as far as the Red Hat X team goes a-d are what we are paid to do, e/f and nice to haves, so really if some community effort was to be brought up around this, e/f are where it would make sense to focus it.
Hi, how could we (we = KDE SIG people) help with e) - serious question - not KDE over Gnome flame or blaming ;-) - to make it better?
From Red Hat's POV, KDE should be at least partially supported by X team as
it's official and supported component of RHEL - but this goes together with Fedora.
Thanks for your work on freeing me from fglrx!
Jaroslav
Having some sort of repos where we can publish a new kernel/libdrm/mesa/intel/ati/nouveau package in one block for people to test and find regression that isn't rawhide and isn't updates-testing (since it would be abusing that) would be an excellent place to start.
Dave.
On Fri, 2009-11-27 at 10:02 +0100, Jaroslav Reznik wrote:
On Thursday 26 November 2009 23:14:09 Dave Airlie wrote:
On Fri, 2009-11-27 at 07:23 +1000, Dave Airlie wrote:
On Thu, 2009-11-26 at 20:16 +0000, Terry Barnaby wrote:
On 11/26/2009 07:46 PM, Bruno Wolff III wrote:
On Thu, Nov 26, 2009 at 17:09:14 +0000,
Terry Barnabyterry1@beam.ltd.uk wrote:
I really want to help and get a stable release and present bug reports and even fix them if I can. But, the current short term release schedule, and no focus on testing and fixing graphics issues, does not inspire me with confidence that a stable usable release will emerge. This makes it difficult for me to justify the effort. Convince me :)
I follow the radeon updates pretty closely and my 9200 finally starting working with 3d again a few weeks before the release. Airlie has continued development in the f12 branch and there have been several updates over the last couple of weeks. If you have just tried F11 and not F12 you should consider doing so. For r5xx and below, grab a live image and install one of the smaller 3d apps and try it out. For r6xx and above you'll want to install mesa-experimental-drivers and update xorg-x11-drv-ati. This won't get you the kernel updates related to graphics since the release, but should give you a good look at where things are at so that you can decide if you want install F12 on the machine.
Hi,
I have tried out F12 on 4 different systems, 2 with different ATI graphics and two with different Intel based boards. Only the last one appears to be able to run Blender. You mention "Airlie has continued development in the f12 branch". If that means there are people working on the bugs and producing new driver updates for F12 (DRM,MESA,X11), especially for ATI then I certainly will give it some time.
So is blender working the only thing you consider as working?
The current focus is on making graphics work for as many ppl as possible first, then 3D is always further down the list, this is just common sense.
Current priorities are: 0) you aren't running a binary driver - if so no priority for you.
a) Can you see stuff on the screen at install/boot? b) can you run GNOME desktop in reasonably useful manner? i.e. firefox runs okay, no glitches, major slowdowns etc. c) can you suspend/resume? d) can you run compiz/gnome-shell? e) can you run non-Gnome desktops at reasonable speed? (yes we have to prioritise gnome over KDE, it sucks but thats life) f) does misc 3D application run?
I should follow up just as far as the Red Hat X team goes a-d are what we are paid to do, e/f and nice to haves, so really if some community effort was to be brought up around this, e/f are where it would make sense to focus it.
Hi, how could we (we = KDE SIG people) help with e) - serious question - not KDE over Gnome flame or blaming ;-) - to make it better? From Red Hat's POV, KDE should be at least partially supported by X team as it's official and supported component of RHEL - but this goes together with Fedora.
Find a GPU developer who runs KDE ;-) and feed him treats.
Though seriously its not really a major bias, like I have things on my list priority (a) but I still end up doing (e)&(f) tasks occasionally for my own sanity and to take a break from staring at register dumps.
Like a bug KDE finds in the driver is still a bug, it just means I have to go install KDE on my test machines again and that is where I generally lag and take a few days longer.
I think the main thing non-GNOME users can do is stay on top of packages in updates-testing and stuff as I rarely get time to regression test on non-GNOME desktops.
Dave.
On 11/26/2009 10:14 PM, Dave Airlie wrote:
On Fri, 2009-11-27 at 07:23 +1000, Dave Airlie wrote:
On Thu, 2009-11-26 at 20:16 +0000, Terry Barnaby wrote:
On 11/26/2009 07:46 PM, Bruno Wolff III wrote:
On Thu, Nov 26, 2009 at 17:09:14 +0000, Terry Barnabyterry1@beam.ltd.uk wrote:
I really want to help and get a stable release and present bug reports and even fix them if I can. But, the current short term release schedule, and no focus on testing and fixing graphics issues, does not inspire me with confidence that a stable usable release will emerge. This makes it difficult for me to justify the effort. Convince me :)
I follow the radeon updates pretty closely and my 9200 finally starting working with 3d again a few weeks before the release. Airlie has continued development in the f12 branch and there have been several updates over the last couple of weeks. If you have just tried F11 and not F12 you should consider doing so. For r5xx and below, grab a live image and install one of the smaller 3d apps and try it out. For r6xx and above you'll want to install mesa-experimental-drivers and update xorg-x11-drv-ati. This won't get you the kernel updates related to graphics since the release, but should give you a good look at where things are at so that you can decide if you want install F12 on the machine.
Hi,
I have tried out F12 on 4 different systems, 2 with different ATI graphics and two with different Intel based boards. Only the last one appears to be able to run Blender. You mention "Airlie has continued development in the f12 branch". If that means there are people working on the bugs and producing new driver updates for F12 (DRM,MESA,X11), especially for ATI then I certainly will give it some time.
So is blender working the only thing you consider as working?
The current focus is on making graphics work for as many ppl as possible first, then 3D is always further down the list, this is just common sense.
Current priorities are: 0) you aren't running a binary driver - if so no priority for you.
a) Can you see stuff on the screen at install/boot? b) can you run GNOME desktop in reasonably useful manner? i.e. firefox runs okay, no glitches, major slowdowns etc. c) can you suspend/resume? d) can you run compiz/gnome-shell? e) can you run non-Gnome desktops at reasonable speed? (yes we have to prioritise gnome over KDE, it sucks but thats life) f) does misc 3D application run?
I should follow up just as far as the Red Hat X team goes a-d are what we are paid to do, e/f and nice to haves, so really if some community effort was to be brought up around this, e/f are where it would make sense to focus it.
Having some sort of repos where we can publish a new kernel/libdrm/mesa/intel/ati/nouveau package in one block for people to test and find regression that isn't rawhide and isn't updates-testing (since it would be abusing that) would be an excellent place to start.
Dave.
I use Linux in an engineering environment that requires 3D for CAD and data visualisation. Blender is just a simple well known 3D program that seems to exercise the 3D system to a reasonable extent. Its a simple first pass test that I have been using.
I did mention something like your repos idea during F11. I suggested having something like a fedora-testing-graphics repo that would have any development packages to allow people to test new graphics related drivers easily. One problem noted by people was the amount of work to maintain this and keep it in sync with main fedora-updates repo though.
Also mentioned then I thought it would be good to have a basic, and simple for users, graphics testing system to easily allow users to test and feedback issues. Even if this is simply a short list of 2D/3D applications and a list of operations to try. Would a graphics testing day on F12 with the special graphics repo and some basic list of tests be useful to the developers ?
On Fri, 2009-11-27 at 09:35 +0000, Terry Barnaby wrote:
Also mentioned then I thought it would be good to have a basic, and simple for users, graphics testing system to easily allow users to test and feedback issues. Even if this is simply a short list of 2D/3D applications and a list of operations to try. Would a graphics testing day on F12 with the special graphics repo and some basic list of tests be useful to the developers ?
You mean, just like the three F12 graphics test days, with basic lists of tests and special live spins, which we already did? :)
https://fedoraproject.org/wiki/Test_Day:2009-09-09_Radeon https://fedoraproject.org/wiki/Test_Day:2009-09-10_Nouveau https://fedoraproject.org/wiki/Test_Day:2009-09-11_Intel
So, here's my general take on this. First, as has been pointed out, several of your issues were encountered when running the NVIDIA proprietary driver. There is no way we can sensibly do any work on NVIDIA driver issues as we have no source for the driver. There's no way we can tell what's going wrong or fix it. It's just a complete non-starter. And no, we can't even forward the bugs to NVIDIA, because they don't have a bug tracking system. What they have is a guy who reads the Linux / NVIDIA forums at nvnews.net and Phoronix, and that's it. All we can really do is advise you to post your problem there.
Second, I do understand your frustration, really I do. I do quite a lot of X triage, and it is noticeable that issues are often not fixed in the release against which they're reported. However, there are really genuinely good reasons for this. Mainly, as Dave noted, it's very hard to implement fixes in X for stable releases and be sure they don't cause regressions; again as he noted, we're hoping to work on a system to make this a bit more possible. But also importantly, the 'upstream / downstream divide' that's being discussed in this thread isn't so simple, for Fedora. To a large extent, Fedora is _part_ of upstream, for X server, radeon and nouveau especially. The people who package and develop X in Fedora are also major upstream developers, and the work they do tends to be genuine development work rather than integration / fix backporting. Dave and Jerome are major contributors to radeon driver development, Ben is a major contributor to nouveau driver development, and all of them along with Adam contribute to X server development. So, a lot of what our X team is doing is actually driving the major forward progress of these components - not just fixing specific bugs but working on support for new hardware, and new features / architecture like KMS and DRI2 and GEM. So they tend to work by pulling fixes into new development. A lot of issues reported in, say, 10 and 11 actually got noticed by the developers and worked on, but they were worked on in such a way that the fix isn't a minimal band-aid that it's trivially simple to backport to that release. The fix got incorporated into significant development work which would not be straightforward to backport without the possibility of causing a regression.
It would, of course, be theoretically possible for Fedora's X team to spend less time working on important new driver development and more time working on minimal-impact fixes for the existing releases, but that's not the same as saying it would be _desirable_. In the long run, getting the major development done really needs to happen.
As Dave has implied several times in the thread, there are several openings here for community involvement, and that would be great. It would be entirely possible for volunteers to get involved both in testing and development work, especially in building and testing update packages for stable releases. But it's not something that we could simply redirect existing development towards without suffering significant consequences in other areas.
The Bugzappers also always happy to have more people volunteer to help with X.org bug triage; it's a lot of work to keep on top of. https://fedoraproject.org/wiki/BugZappers/Joining
On 11/27/2009 07:33 PM, Adam Williamson wrote:
On Fri, 2009-11-27 at 09:35 +0000, Terry Barnaby wrote:
Also mentioned then I thought it would be good to have a basic, and simple for users, graphics testing system to easily allow users to test and feedback issues. Even if this is simply a short list of 2D/3D applications and a list of operations to try. Would a graphics testing day on F12 with the special graphics repo and some basic list of tests be useful to the developers ?
You mean, just like the three F12 graphics test days, with basic lists of tests and special live spins, which we already did? :)
https://fedoraproject.org/wiki/Test_Day:2009-09-09_Radeon https://fedoraproject.org/wiki/Test_Day:2009-09-10_Nouveau https://fedoraproject.org/wiki/Test_Day:2009-09-11_Intel
So, here's my general take on this. First, as has been pointed out, several of your issues were encountered when running the NVIDIA proprietary driver. There is no way we can sensibly do any work on NVIDIA driver issues as we have no source for the driver. There's no way we can tell what's going wrong or fix it. It's just a complete non-starter. And no, we can't even forward the bugs to NVIDIA, because they don't have a bug tracking system. What they have is a guy who reads the Linux / NVIDIA forums at nvnews.net and Phoronix, and that's it. All we can really do is advise you to post your problem there.
Second, I do understand your frustration, really I do. I do quite a lot of X triage, and it is noticeable that issues are often not fixed in the release against which they're reported. However, there are really genuinely good reasons for this. Mainly, as Dave noted, it's very hard to implement fixes in X for stable releases and be sure they don't cause regressions; again as he noted, we're hoping to work on a system to make this a bit more possible. But also importantly, the 'upstream / downstream divide' that's being discussed in this thread isn't so simple, for Fedora. To a large extent, Fedora is _part_ of upstream, for X server, radeon and nouveau especially. The people who package and develop X in Fedora are also major upstream developers, and the work they do tends to be genuine development work rather than integration / fix backporting. Dave and Jerome are major contributors to radeon driver development, Ben is a major contributor to nouveau driver development, and all of them along with Adam contribute to X server development. So, a lot of what our X team is doing is actually driving the major forward progress of these components - not just fixing specific bugs but working on support for new hardware, and new features / architecture like KMS and DRI2 and GEM. So they tend to work by pulling fixes into new development. A lot of issues reported in, say, 10 and 11 actually got noticed by the developers and worked on, but they were worked on in such a way that the fix isn't a minimal band-aid that it's trivially simple to backport to that release. The fix got incorporated into significant development work which would not be straightforward to backport without the possibility of causing a regression.
It would, of course, be theoretically possible for Fedora's X team to spend less time working on important new driver development and more time working on minimal-impact fixes for the existing releases, but that's not the same as saying it would be _desirable_. In the long run, getting the major development done really needs to happen.
As Dave has implied several times in the thread, there are several openings here for community involvement, and that would be great. It would be entirely possible for volunteers to get involved both in testing and development work, especially in building and testing update packages for stable releases. But it's not something that we could simply redirect existing development towards without suffering significant consequences in other areas.
The Bugzappers also always happy to have more people volunteer to help with X.org bug triage; it's a lot of work to keep on top of. https://fedoraproject.org/wiki/BugZappers/Joining
Hi,
I did take part in the Radeon test day. Unfortunately the tests did not really cover 3D and it was difficult to test this using the Live system. I did feed back this. But they are a good idea and I would have thought could be extended to having a test day after a release has been going for a month or so so more users could take part.
Actually it was not me with NVIDIA. I don't have any systems using this chipset.
Yes I take your points, but it is hard for users, quite often, to test the system and know how to track down where a bug is occurring and report it. Generally users and volunteers do not have the experience of how the Fedora developer community and its systems work, how the graphics system works and how to test and report issues. So some involvement of developers to getting a relatively simple testing regime going may help get this underway.
Anyway, I have been convinced, from what Dave has said, that things are being done and have now started trying to use F12 and will attempt to report back issues I see.
On Fri, 2009-11-27 at 20:04 +0000, Terry Barnaby wrote:
Hi,
I did take part in the Radeon test day. Unfortunately the tests did not really cover 3D and it was difficult to test this using the Live system. I did feed back this.
Right...that is mainly a product of what Dave mentioned, that general 3D functionality is unfortunately right at the bottom of the priority list, at least until we have drivers that work really solidly for basic desktop functionality. But I'd be happy to have more extensive 3D tests in the list for future test days, please do feel free to submit some.
But they are a good idea and I would have thought could be extended to having a test day after a release has been going for a month or so so more users could take part.
It's not a bad idea, for sure. I'm not sure _I'd_ do it, though, it's enough work organizing the test days for the upcoming release without doing ones for the last release too. :) However, we do have a process for allowing anyone to organize a Test Day. You can propose one just by mailing test-list or filing a ticket in QA trac, and we have an SOP for the whole process of actually hosting one:
https://fedoraproject.org/wiki/QA/SOP_Test_Day_management
so it'd be perfectly feasible for a community member to organize post-release graphics test events for the stable release. I'd be happy to work those into the upcoming test day schedule if you'd be interested in doing it.
Actually it was not me with NVIDIA. I don't have any systems using this chipset.
sorry, yes, mistaken identity :)
Yes I take your points, but it is hard for users, quite often, to test the system and know how to track down where a bug is occurring and report it. Generally users and volunteers do not have the experience of how the Fedora developer community and its systems work, how the graphics system works and how to test and report issues. So some involvement of developers to getting a relatively simple testing regime going may help get this underway.
We do have a page on reporting X.org bugs:
https://fedoraproject.org/wiki/How_to_debug_Xorg_problems
which should cover the major points, and which we try to direct people to wherever we can. Do you think there's anything missing from that?
Anyway, I have been convinced, from what Dave has said, that things are being done and have now started trying to use F12 and will attempt to report back issues I see.
Thanks a lot.
On 11/27/2009 08:12 PM, Adam Williamson wrote:
On Fri, 2009-11-27 at 20:04 +0000, Terry Barnaby wrote:
Hi,
I did take part in the Radeon test day. Unfortunately the tests did not really cover 3D and it was difficult to test this using the Live system. I did feed back this.
Right...that is mainly a product of what Dave mentioned, that general 3D functionality is unfortunately right at the bottom of the priority list, at least until we have drivers that work really solidly for basic desktop functionality. But I'd be happy to have more extensive 3D tests in the list for future test days, please do feel free to submit some.
But they are a good idea and I would have thought could be extended to having a test day after a release has been going for a month or so so more users could take part.
It's not a bad idea, for sure. I'm not sure _I'd_ do it, though, it's enough work organizing the test days for the upcoming release without doing ones for the last release too. :) However, we do have a process for allowing anyone to organize a Test Day. You can propose one just by mailing test-list or filing a ticket in QA trac, and we have an SOP for the whole process of actually hosting one:
https://fedoraproject.org/wiki/QA/SOP_Test_Day_management
so it'd be perfectly feasible for a community member to organize post-release graphics test events for the stable release. I'd be happy to work those into the upcoming test day schedule if you'd be interested in doing it.
Actually it was not me with NVIDIA. I don't have any systems using this chipset.
sorry, yes, mistaken identity :)
Yes I take your points, but it is hard for users, quite often, to test the system and know how to track down where a bug is occurring and report it. Generally users and volunteers do not have the experience of how the Fedora developer community and its systems work, how the graphics system works and how to test and report issues. So some involvement of developers to getting a relatively simple testing regime going may help get this underway.
We do have a page on reporting X.org bugs:
https://fedoraproject.org/wiki/How_to_debug_Xorg_problems
which should cover the major points, and which we try to direct people to wherever we can. Do you think there's anything missing from that?
Anyway, I have been convinced, from what Dave has said, that things are being done and have now started trying to use F12 and will attempt to report back issues I see.
Thanks a lot.
Some really useful info in How_to_debug_Xorg_problems. I couldn't easily find it from the main wiki home page however. Maybe a link to this page marked "Graphics issues" could be made on the front page (focus users on improving the graphics) ? Could improve the title "Graphics problems and bug reporting" ? and add some search terms such as "Graphics Problems", "3D problems" etc. Add some info on what to set for "Bugzilla" fields ? Maybe the bug reports should include the package version numbers ? Maybe some simple user tools could be generated to ease and make bug reporting more useful. Something simple like the following might be useful:
#!/bin/sh date > bug1 lspci | grep VGA >> bug1 (echo -n "kernel: "; uname -r) >> bug1 rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}\n" xorg-x11-server-Xorg >> bug1 rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}\n" xorg-x11-drv-ati >> bug1 rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}\n" mesa-dri-drivers >> bug1 glxinfo | grep "OpenGL renderer string" >> bug1
It might be worth including info on how to update from fedora-testing just graphics related packages. Ie add something like: "includepkgs=kernel* xorg-x11-* mesa*" to the "updates-testing" section of fedora-updates-testing.repo and enable the repo ? Also how to revert. Should it state that all tests should be done with fedora-updates-testing packages ?
I notice there is a new xorg-x11-drv-ati. It does look like things are moving :) All we need now is 2 months down the line for Fedora 12.1 to be released with updated anaconda and all updated packages in ISO form so that Joe public can easily install a good working Fedora release ...
Cheers
Terry
On 11/28/2009 07:31 AM, Terry Barnaby wrote:
On 11/27/2009 08:12 PM, Adam Williamson wrote:
On Fri, 2009-11-27 at 20:04 +0000, Terry Barnaby wrote:
Hi,
I did take part in the Radeon test day. Unfortunately the tests did not really cover 3D and it was difficult to test this using the Live system. I did feed back this.
Right...that is mainly a product of what Dave mentioned, that general 3D functionality is unfortunately right at the bottom of the priority list, at least until we have drivers that work really solidly for basic desktop functionality. But I'd be happy to have more extensive 3D tests in the list for future test days, please do feel free to submit some.
But they are a good idea and I would have thought could be extended to having a test day after a release has been going for a month or so so more users could take part.
It's not a bad idea, for sure. I'm not sure _I'd_ do it, though, it's enough work organizing the test days for the upcoming release without doing ones for the last release too. :) However, we do have a process for allowing anyone to organize a Test Day. You can propose one just by mailing test-list or filing a ticket in QA trac, and we have an SOP for the whole process of actually hosting one:
https://fedoraproject.org/wiki/QA/SOP_Test_Day_management
so it'd be perfectly feasible for a community member to organize post-release graphics test events for the stable release. I'd be happy to work those into the upcoming test day schedule if you'd be interested in doing it.
Actually it was not me with NVIDIA. I don't have any systems using this chipset.
sorry, yes, mistaken identity :)
Yes I take your points, but it is hard for users, quite often, to test the system and know how to track down where a bug is occurring and report it. Generally users and volunteers do not have the experience of how the Fedora developer community and its systems work, how the graphics system works and how to test and report issues. So some involvement of developers to getting a relatively simple testing regime going may help get this underway.
We do have a page on reporting X.org bugs:
https://fedoraproject.org/wiki/How_to_debug_Xorg_problems
which should cover the major points, and which we try to direct people to wherever we can. Do you think there's anything missing from that?
Anyway, I have been convinced, from what Dave has said, that things are being done and have now started trying to use F12 and will attempt to report back issues I see.
Thanks a lot.
Some really useful info in How_to_debug_Xorg_problems. I couldn't easily find it from the main wiki home page however. Maybe a link to this page marked "Graphics issues" could be made on the front page (focus users on improving the graphics) ? Could improve the title "Graphics problems and bug reporting" ? and add some search terms such as "Graphics Problems", "3D problems" etc. Add some info on what to set for "Bugzilla" fields ? Maybe the bug reports should include the package version numbers ? Maybe some simple user tools could be generated to ease and make bug reporting more useful. Something simple like the following might be useful:
#!/bin/sh date > bug1 lspci | grep VGA >> bug1 (echo -n "kernel: "; uname -r) >> bug1 rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}\n" xorg-x11-server-Xorg >> bug1 rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}\n" xorg-x11-drv-ati >> bug1 rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}\n" mesa-dri-drivers >> bug1 glxinfo | grep "OpenGL renderer string" >> bug1
It might be worth including info on how to update from fedora-testing just graphics related packages. Ie add something like: "includepkgs=kernel* xorg-x11-* mesa*" to the "updates-testing" section of fedora-updates-testing.repo and enable the repo ? Also how to revert. Should it state that all tests should be done with fedora-updates-testing packages ?
I notice there is a new xorg-x11-drv-ati. It does look like things are moving :) All we need now is 2 months down the line for Fedora 12.1 to be released with updated anaconda and all updated packages in ISO form so that Joe public can easily install a good working Fedora release ...
Cheers
Terry
Which are the best Bugzilla components to register bugs against:
X11 driver ATI: xorg-x11-drv-ati 3D driver: mesa DRM: kernel ???
Cheers
Terry
On 11/28/2009 08:36 AM, Terry Barnaby wrote:
On 11/28/2009 07:31 AM, Terry Barnaby wrote:
On 11/27/2009 08:12 PM, Adam Williamson wrote:
On Fri, 2009-11-27 at 20:04 +0000, Terry Barnaby wrote:
Hi,
I did take part in the Radeon test day. Unfortunately the tests did not really cover 3D and it was difficult to test this using the Live system. I did feed back this.
Right...that is mainly a product of what Dave mentioned, that general 3D functionality is unfortunately right at the bottom of the priority list, at least until we have drivers that work really solidly for basic desktop functionality. But I'd be happy to have more extensive 3D tests in the list for future test days, please do feel free to submit some.
But they are a good idea and I would have thought could be extended to having a test day after a release has been going for a month or so so more users could take part.
It's not a bad idea, for sure. I'm not sure _I'd_ do it, though, it's enough work organizing the test days for the upcoming release without doing ones for the last release too. :) However, we do have a process for allowing anyone to organize a Test Day. You can propose one just by mailing test-list or filing a ticket in QA trac, and we have an SOP for the whole process of actually hosting one:
https://fedoraproject.org/wiki/QA/SOP_Test_Day_management
so it'd be perfectly feasible for a community member to organize post-release graphics test events for the stable release. I'd be happy to work those into the upcoming test day schedule if you'd be interested in doing it.
Actually it was not me with NVIDIA. I don't have any systems using this chipset.
sorry, yes, mistaken identity :)
Yes I take your points, but it is hard for users, quite often, to test the system and know how to track down where a bug is occurring and report it. Generally users and volunteers do not have the experience of how the Fedora developer community and its systems work, how the graphics system works and how to test and report issues. So some involvement of developers to getting a relatively simple testing regime going may help get this underway.
We do have a page on reporting X.org bugs:
https://fedoraproject.org/wiki/How_to_debug_Xorg_problems
which should cover the major points, and which we try to direct people to wherever we can. Do you think there's anything missing from that?
Anyway, I have been convinced, from what Dave has said, that things are being done and have now started trying to use F12 and will attempt to report back issues I see.
Thanks a lot.
Some really useful info in How_to_debug_Xorg_problems. I couldn't easily find it from the main wiki home page however. Maybe a link to this page marked "Graphics issues" could be made on the front page (focus users on improving the graphics) ? Could improve the title "Graphics problems and bug reporting" ? and add some search terms such as "Graphics Problems", "3D problems" etc. Add some info on what to set for "Bugzilla" fields ? Maybe the bug reports should include the package version numbers ? Maybe some simple user tools could be generated to ease and make bug reporting more useful. Something simple like the following might be useful:
#!/bin/sh date > bug1 lspci | grep VGA >> bug1 (echo -n "kernel: "; uname -r) >> bug1 rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}\n" xorg-x11-server-Xorg >> bug1 rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}\n" xorg-x11-drv-ati >> bug1 rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}\n" mesa-dri-drivers >> bug1 glxinfo | grep "OpenGL renderer string" >> bug1
It might be worth including info on how to update from fedora-testing just graphics related packages. Ie add something like: "includepkgs=kernel* xorg-x11-* mesa*" to the "updates-testing" section of fedora-updates-testing.repo and enable the repo ? Also how to revert. Should it state that all tests should be done with fedora-updates-testing packages ?
I notice there is a new xorg-x11-drv-ati. It does look like things are moving :) All we need now is 2 months down the line for Fedora 12.1 to be released with updated anaconda and all updated packages in ISO form so that Joe public can easily install a good working Fedora release ...
Cheers
Terry
Which are the best Bugzilla components to register bugs against:
X11 driver ATI: xorg-x11-drv-ati 3D driver: mesa DRM: kernel ???
Cheers
Terry
Where is the location of the DRM kernel module master git tree now ? It used to be at: http://cgit.freedesktop.org/mesa/drm/linux-core Is it now worked on directly withing the kernel source trees ?
Which are the best Bugzilla components to register bugs against:
X11 driver ATI: xorg-x11-drv-ati 3D driver: mesa DRM: kernel ???
Cheers
Terry
Where is the location of the DRM kernel module master git tree now ? It used to be at: http://cgit.freedesktop.org/mesa/drm/linux-core Is it now worked on directly withing the kernel source trees ?
Its developed in-kernel now, like any sane driver.
Dave.
On Sat, 2009-11-28 at 07:31 +0000, Terry Barnaby wrote:
Some really useful info in How_to_debug_Xorg_problems. I couldn't easily find it from the main wiki home page however. Maybe a link to this page marked "Graphics issues" could be made on the front page (focus users on improving the graphics) ?
That doesn't scale. There's lots of useful pages in the Wiki. We can't link to all of them from the front page.
There's a link on the front page which says 'Report a new bug', with the word 'bug' a link to https://fedoraproject.org/wiki/BugsAndFeatureRequests . The X page is linked from that page in the 'Information required for bugs in specific components' section. That's two steps from the front page.
Could improve the title "Graphics problems and bug reporting" ?
We have multiple pages of this type, all named How_to_debug_foobar_problems . We found that the best generic naming scheme for all such pages.
and add some search terms such as "Graphics Problems", "3D problems" etc.
I'm not sure you can add search terms to Wiki pages, but if you can, then sure.
Add some info on what to set for "Bugzilla" fields ?
That's not appropriate for subject-specific pages; it's discussed in the main 'how to report bugs' page, https://fedoraproject.org/wiki/BugsAndFeatureRequests .
Maybe the bug reports should include the package version numbers ?
That might be useful in some cases, yeah.
Maybe some simple user tools could be generated to ease and make bug reporting more useful. Something simple like the following might be useful:
#!/bin/sh date > bug1 lspci | grep VGA >> bug1 (echo -n "kernel: "; uname -r) >> bug1 rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}\n" xorg-x11-server-Xorg >> bug1 rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}\n" xorg-x11-drv-ati >> bug1 rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}\n" mesa-dri-drivers >> bug1 glxinfo | grep "OpenGL renderer string" >> bug1
It's a decent idea, the problem I have with it is you wind up with a forest of little scripts with no decent maintenance strategy. I'd rather have a more integrated and properly maintained tool, it may grow out of abrt in future.
It might be worth including info on how to update from fedora-testing just graphics related packages. Ie add something like: "includepkgs=kernel* xorg-x11-* mesa*" to the "updates-testing" section of fedora-updates-testing.repo and enable the repo ? Also how to revert. Should it state that all tests should be done with fedora-updates-testing packages ?
The automated systems for handling updates usually handle this (when an update is submitted to updates-testing that's marked by the maintainer as fixing a particular bug, an automatic comment is added to the bug with a note that an update is in updates-testing to be tried).
I notice there is a new xorg-x11-drv-ati. It does look like things are moving :) All we need now is 2 months down the line for Fedora 12.1 to be released with updated anaconda and all updated packages in ISO form so that Joe public can easily install a good working Fedora release ...
We don't do this except for extreme major brokenness which we somehow missed during testing, it's not worth the effort involved. Fedora Unity does updated re-spins, however they haven't got anything out for F11 yet due to some problems, I believe they're looking for extra volunteers.
On 11/28/2009 10:26 PM, Adam Williamson wrote:
On Sat, 2009-11-28 at 07:31 +0000, Terry Barnaby wrote:
Some really useful info in How_to_debug_Xorg_problems. I couldn't easily find it from the main wiki home page however. Maybe a link to this page marked "Graphics issues" could be made on the front page (focus users on improving the graphics) ?
That doesn't scale. There's lots of useful pages in the Wiki. We can't link to all of them from the front page.
I was thinking of this more as a special Graphics debug push :)
There's a link on the front page which says 'Report a new bug', with the word 'bug' a link to https://fedoraproject.org/wiki/BugsAndFeatureRequests . The X page is linked from that page in the 'Information required for bugs in specific components' section. That's two steps from the front page.
Could improve the title "Graphics problems and bug reporting" ?
We have multiple pages of this type, all named How_to_debug_foobar_problems . We found that the best generic naming scheme for all such pages.
and add some search terms such as "Graphics Problems", "3D problems" etc.
I'm not sure you can add search terms to Wiki pages, but if you can, then sure.
I would have thought that simply adding the text for these in the page would have helped searching ?
Add some info on what to set for "Bugzilla" fields ?
That's not appropriate for subject-specific pages; it's discussed in the main 'how to report bugs' page, https://fedoraproject.org/wiki/BugsAndFeatureRequests .
Maybe the bug reports should include the package version numbers ?
That might be useful in some cases, yeah.
Maybe some simple user tools could be generated to ease and make bug reporting more useful. Something simple like the following might be useful:
#!/bin/sh date> bug1 lspci | grep VGA>> bug1 (echo -n "kernel: "; uname -r)>> bug1 rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}\n" xorg-x11-server-Xorg>> bug1 rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}\n" xorg-x11-drv-ati>> bug1 rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}\n" mesa-dri-drivers>> bug1 glxinfo | grep "OpenGL renderer string">> bug1
It's a decent idea, the problem I have with it is you wind up with a forest of little scripts with no decent maintenance strategy. I'd rather have a more integrated and properly maintained tool, it may grow out of abrt in future.
Yes, but that the moment the Graphics bugs seem to have random user inputs of information. I would have thought that a simple script to help with just Graphics bugs would help just now. (I am hoping all of the graphics problems will have gone away by next year :) )
It might be worth including info on how to update from fedora-testing just graphics related packages. Ie add something like: "includepkgs=kernel* xorg-x11-* mesa*" to the "updates-testing" section of fedora-updates-testing.repo and enable the repo ? Also how to revert. Should it state that all tests should be done with fedora-updates-testing packages ?
The automated systems for handling updates usually handle this (when an update is submitted to updates-testing that's marked by the maintainer as fixing a particular bug, an automatic comment is added to the bug with a note that an update is in updates-testing to be tried).
I notice there is a new xorg-x11-drv-ati. It does look like things are moving :) All we need now is 2 months down the line for Fedora 12.1 to be released with updated anaconda and all updated packages in ISO form so that Joe public can easily install a good working Fedora release ...
We don't do this except for extreme major brokenness which we somehow missed during testing, it's not worth the effort involved. Fedora Unity does updated re-spins, however they haven't got anything out for F11 yet due to some problems, I believe they're looking for extra volunteers.
You say that producing a Fedora "12.1" release is "not worth the effort involved". Is that truly the case ? Certainly that is what I always do here. Normally the initial Fedora releases contain quite a few issues and there are a flurry of updates. So I use pungi to create my own updated release that I use to install on further systems. There is very little effort in this and, I would have thought, not to much further testing effort needed. It is a problem that anaconda updates aren't released however. Certainly from the users front I would have thought that this is worth the effort. It allows them to install a Fedora system with the core bugs that users have found fixed in one pass.
On Sun, 2009-11-29 at 09:23 +0000, Terry Barnaby wrote:
That doesn't scale. There's lots of useful pages in the Wiki. We can't link to all of them from the front page.
I was thinking of this more as a special Graphics debug push :)
Special cases are never a good idea.
and add some search terms such as "Graphics Problems", "3D problems" etc.
I'm not sure you can add search terms to Wiki pages, but if you can, then sure.
I would have thought that simply adding the text for these in the page would have helped searching ?
It would be rather ugly, though?
It's a decent idea, the problem I have with it is you wind up with a forest of little scripts with no decent maintenance strategy. I'd rather have a more integrated and properly maintained tool, it may grow out of abrt in future.
Yes, but that the moment the Graphics bugs seem to have random user inputs of information. I would have thought that a simple script to help with just Graphics bugs would help just now. (I am hoping all of the graphics problems will have gone away by next year :) )
This is never a good way of thinking. The more experience you get with working on an ongoing project like a Linux distribution, the more you want to do _everything_ in a properly planned and sustainable framework, because you find that the things you think will just be temporary hacks never ever wind up that way. They just get built into the plumbing and make people's lives miserable forever :)
Hoping all graphics problems will go away in a year is definitely not a good way to plan. :)
We don't do this except for extreme major brokenness which we somehow missed during testing, it's not worth the effort involved. Fedora Unity does updated re-spins, however they haven't got anything out for F11 yet due to some problems, I believe they're looking for extra volunteers.
You say that producing a Fedora "12.1" release is "not worth the effort involved". Is that truly the case ? Certainly that is what I always do here. Normally the initial Fedora releases contain quite a few issues and there are a flurry of updates. So I use pungi to create my own updated release that I use to install on further systems. There is very little effort in this and, I would have thought, not to much further testing effort needed. It is a problem that anaconda updates aren't released however. Certainly from the users front I would have thought that this is worth the effort. It allows them to install a Fedora system with the core bugs that users have found fixed in one pass.
Building a spin isn't that much work. Validating it (yes, QA would not want to release any image which hadn't been through full installation validation testing) and doing all the other release gubbins which happens as _well_ as just spinning an image is a lot more work.
Not doing .1 releases has been the releng's team position for a long time. I'm not in the releng team so I'm not going to argue their position for them, but it is a properly argued one. Jesse can give you full set of reasons if you like, and if he feels like rehashing them :)
The Bugzappers also always happy to have more people volunteer to help with X.org bug triage; it's a lot of work to keep on top of.
I'd like to help. But the wikipage for testing Xorg issues* is a way to much to read, given the case you follow all the links on the site and you need to do so to get an overview. :S To much confusing for a "newb". A "real" howto with "goal", "what you need", small steps, final step, "conclusion" and "how it change things" would be nice. :)
On 11/30/2009 01:33 AM, Ikem Krueger wrote:
The Bugzappers also always happy to have more people volunteer to help with X.org bug triage; it's a lot of work to keep on top of.
I'd like to help. But the wikipage for testing Xorg issues* is a way to much to read, given the case you follow all the links on the site and you need to do so to get an overview. :S To much confusing for a "newb". A "real" howto with "goal", "what you need", small steps, final step, "conclusion" and "how it change things" would be nice. :)
Get a Fedora account and create a new page under your username and show it to the QA team get some consensus.
Rahul
On Sun, 2009-11-29 at 20:03 +0000, Ikem Krueger wrote:
The Bugzappers also always happy to have more people volunteer to help with X.org bug triage; it's a lot of work to keep on top of.
I'd like to help. But the wikipage for testing Xorg issues* is a way to much to read, given the case you follow all the links on the site and you need to do so to get an overview. :S To much confusing for a "newb". A "real" howto with "goal", "what you need", small steps, final step, "conclusion" and "how it change things" would be nice. :)
If you'd like to mock up such a page as a draft and submit it to test-list, that'd be fine. But I'm not sure it's actually possible to make the existing page any _smaller_ without losing valuable information.
Dne Thu, 26 Nov 2009 13:46:54 -0600 Bruno Wolff III napsal(a):
On Thu, Nov 26, 2009 at 17:09:14 +0000, Terry Barnaby terry1@beam.ltd.uk wrote:
I really want to help and get a stable release and present bug reports and even fix them if I can. But, the current short term release schedule, and no focus on testing and fixing graphics issues, does not inspire me with confidence that a stable usable release will emerge. This makes it difficult for me to justify the effort. Convince me :)
I follow the radeon updates pretty closely and my 9200 finally starting working with 3d again a few weeks before the release. Airlie has continued development in the f12 branch and there have been several updates over the last couple of weeks.
+1 The ATI graphics in my laptop works in F12 better than ever before. Thanks to Dave Airlie and other developers. The activity of the QA team has also been more visible recently. So I disagree with Terry about the lack of focus on testing and fixing graphics issues.
Michal
On Thu, Nov 26, 2009 at 05:09:14PM +0000, Terry Barnaby wrote:
On 11/26/2009 04:34 PM, Josh Boyer wrote:
On Thu, Nov 26, 2009 at 04:08:27PM +0000, Terry Barnaby wrote:
As you obviously know tracking down and reporting bugs like these do take a lot of time and effort, quite often more than actually fixing them. At the moment with the frequency of Fedora releases and the lack of a push to testing and stability on this front I am not enthused, at the moment, with doing this and I suspect many others feel the same.
I'm confused. You want Fedora to skip a release to focus on testing and fixing, and you have no plans to help and aren't enthusiastic about actually participating in the testing and fixing?
josh
I really want to help and get a stable release and present bug reports and even fix them if I can. But, the current short term release schedule, and no focus on testing and fixing graphics issues, does not inspire me with confidence that a stable usable release will emerge. This makes it difficult for me to justify the effort. Convince me :)
You're making some pretty bold accusations that there is no focus on testing and fixing graphics issues. Perhaps you could classify what you see as needing more testing and fixing instead of claiming there is none. I think that would be more accurate.
As for convincing you, I think I'll refrain. I'd rather try and find someone that actually wants to help then spend time trying to talk to someone that has the nerve to propose canceling a release to do testing and fixing and then needs convincing to actually help with their own idea.
Fedora needs less arm-chair quarterbacking. We have shit-tons of that already.
josh
On 11/26/09, Terry Barnaby terry1@beam.ltd.uk wrote:
On 11/26/2009 04:34 PM, Josh Boyer wrote:
On Thu, Nov 26, 2009 at 04:08:27PM +0000, Terry Barnaby wrote:
As you obviously know tracking down and reporting bugs like these do take a lot of time and effort, quite often more than actually fixing them. At the moment with the frequency of Fedora releases and the lack of a push to testing and stability on this front I am not enthused, at the moment, with doing this and I suspect many others feel the same.
I'm confused. You want Fedora to skip a release to focus on testing and fixing, and you have no plans to help and aren't enthusiastic about actually participating in the testing and fixing?
josh
I really want to help and get a stable release and present bug reports and even fix them if I can. But, the current short term release schedule, and no focus on testing and fixing graphics issues, does not inspire me with confidence that a stable usable release will emerge. This makes it difficult for me to justify the effort. Convince me :)
Convince you? Not sure we need to do that. I've had some issues with graphics on my Dell laptop with nvidia graphics and I reported a couple of bugs and ones been fixed, one was not a bug and the other one I've had lots of help to get fixed, and while not there yet its well and truly on its way. My Intel based systems are spectacularly stable.
The thing is with open source communities is that its a two way street. You need to contribute time to get help fixing stuff... if you can't justify the effort to assist in debugging stuff so it can be fixed and help the community as a whole why should the maintainer spend time dealing with your moaning when he's got dozens of other bugs with proper debugs attached that can help with the fixing of the issues and have people appreciate the effort. Its too easy to moan and harder to contribute.
Peter
On Thu, 2009-11-26 at 20:13 +0530, Rahul Sundaram wrote:
Specific bug reports are definitely going to help.
Here are 4 to start with:
1) Cronometer crashes KDE session. https://bugzilla.redhat.com/show_bug.cgi?id=504173
2) Display not operating properly https://bugzilla.redhat.com/show_bug.cgi?id=528188
Notice that this uses nouveau and it was reported back in rawhide.
3) Blank screen on login https://bugzilla.redhat.com/show_bug.cgi?id=525767
4) KDE session display gets messed up on Gateway LT3108u https://bugzilla.redhat.com/show_bug.cgi?id=525767
On 11/26/2009 08:38 PM, Linuxguy123 wrote:
On Thu, 2009-11-26 at 20:13 +0530, Rahul Sundaram wrote:
Specific bug reports are definitely going to help.
Here are 4 to start with:
- Cronometer crashes KDE session.
Filed against wrong component. How is Fedora marketing related to a KDE issue? Please reassign.
- Display not operating properly
Waiting on information from you.
Notice that this uses nouveau and it was reported back in rawhide.
- Blank screen on login
Likewise.
- KDE session display gets messed up on Gateway LT3108u
Likewise.
Rahul
On Thu, 26 Nov 2009, Rahul Sundaram wrote:
I have not entered any bugzilla numbers as yet. I spent days with F11 and previous releases diagnosing reporting and attempting to fix bugs. No graphics updates were ever made available for F11 and still Fedora cannot run even Blender on most of my machines. At the moment I am not convinced that it is worth spending this time on F12. It seems likely no updates will appear and in F13 the whole ball game may have changed anyway.
Seems a bunch of incorrect assumptions considering that Fedora 11 did get many updates and I already see updates for Fedora 12 in updates-testing repository. Specific bug reports are definitely going to help.
Well, here's one graphics regression: https://bugzilla.redhat.com/show_bug.cgi?id=540476
radeon.modeset=0 worked around the problem.
(I'm not sure if it's filed against the right component.)
On Fri, 2009-11-27 at 08:07 +0200, Pekka Savola wrote:
On Thu, 26 Nov 2009, Rahul Sundaram wrote:
I have not entered any bugzilla numbers as yet. I spent days with F11 and previous releases diagnosing reporting and attempting to fix bugs. No graphics updates were ever made available for F11 and still Fedora cannot run even Blender on most of my machines. At the moment I am not convinced that it is worth spending this time on F12. It seems likely no updates will appear and in F13 the whole ball game may have changed anyway.
Seems a bunch of incorrect assumptions considering that Fedora 11 did get many updates and I already see updates for Fedora 12 in updates-testing repository. Specific bug reports are definitely going to help.
Well, here's one graphics regression: https://bugzilla.redhat.com/show_bug.cgi?id=540476
radeon.modeset=0 worked around the problem.
(I'm not sure if it's filed against the right component.)
Don't use radeonhd, the Fedora X team don't support it and never have.
I'm thinking it should reallyt be removed from the distro at this point as it makes things worse rather than better. remove your xorg.conf and turn modesetting on and if its still horrible, then we can talk.
So you've proven you can break your own machine that is all.
Dave.
On 27/11/09 06:08, Dave Airlie wrote:
Don't use radeonhd, the Fedora X team don't support it and never have. I'm thinking it should reallyt be removed from the distro at this point as it makes things worse rather than better.
If you do this, please consider having a radeonhd->radeon testing day for people like myself - radeonhd works for me where radeon doesn't:
https://bugzilla.redhat.com/show_bug.cgi?id=492723
(I haven't yet tested with F12 final, it's on my to-do list - but the various alphas/betas didn't improve matters)
I would have thought that the radeon driver capabilities should be very close to radeonhd, some of these bugs should be easy to squash (he says ;).
Cheers
Alex.
On Fri, 2009-11-27 at 07:18 +0000, Alex Hudson wrote:
On 27/11/09 06:08, Dave Airlie wrote:
Don't use radeonhd, the Fedora X team don't support it and never have. I'm thinking it should reallyt be removed from the distro at this point as it makes things worse rather than better.
If you do this, please consider having a radeonhd->radeon testing day for people like myself - radeonhd works for me where radeon doesn't:
If the radeonhd maintainer would even add kms detection and refuse to start it would help, the fact that with kms loaded, radeonhd cannot work doesn't seem to have made it back into the Fedora package.
https://bugzilla.redhat.com/show_bug.cgi?id=492723(I haven't yet tested with F12 final, it's on my to-do list - but the various alphas/betas didn't improve matters)
I would have thought that the radeon driver capabilities should be very close to radeonhd, some of these bugs should be easy to squash (he says ;).
Not at all, radeonhd has no kernel modesetting support and does a lot of stuff in its own unique way. Please test an F12 LiveCD or something as soon as you can and we'll figure this out. Anyone using radeonhd is only causing themselves long term problems and I encourage them to switch to radeon if they want any support going forward.
Dave.
On 11/27/2009 11:38 AM, Dave Airlie wrote:
Don't use radeonhd, the Fedora X team don't support it and never have.
I'm thinking it should reallyt be removed from the distro at this point
That makes sense. Why don't we drop this from Rawhide? Shipping unsupported drivers like this is deceptive and lets users rely on kludges instead of focusing the effort on one driver.
Rahul
On Fri, 27 Nov 2009, Dave Airlie wrote:
Don't use radeonhd, the Fedora X team don't support it and never have.
I'm thinking it should reallyt be removed from the distro at this point as it makes things worse rather than better. remove your xorg.conf and turn modesetting on and if its still horrible, then we can talk.
Well, a couple of Fedoras back, X didn't work except with radeonhd, but now radeon appears to support this one as well; I switched to it, and the CPU issue is gone even with KMS. Now fonts (esp small ones) look very smudgy though. But I suppose there are already bug(s) open on this.
Well, a couple of Fedoras back, X didn't work except with radeonhd, but now radeon appears to support this one as well; I switched to it, and the CPU issue is gone even with KMS. Now fonts (esp small ones) look very smudgy though. But I suppose there are already bug(s) open on this.
Don't suppose. Either search Bugzilla to see if that's the case, or report it anyway.
If one keeps supposing the bug was already reported, it might never get fixed.
----------
Mathieu Bridon (bochecha)
On Sat, 2009-11-28 at 13:17 +0200, Pekka Savola wrote:
On Fri, 27 Nov 2009, Dave Airlie wrote:
Don't use radeonhd, the Fedora X team don't support it and never have.
I'm thinking it should reallyt be removed from the distro at this point as it makes things worse rather than better. remove your xorg.conf and turn modesetting on and if its still horrible, then we can talk.
Well, a couple of Fedoras back, X didn't work except with radeonhd, but now radeon appears to support this one as well; I switched to it, and the CPU issue is gone even with KMS. Now fonts (esp small ones) look very smudgy though. But I suppose there are already bug(s) open on this.
I'm guessing with radeonhd you did something to increase or decrease your font size in some dialog box, they had different ideas on DPI to the rest of the world. Try with a test user, though it might just be DPI changes.
Dave.
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Sun, 29 Nov 2009, Dave Airlie wrote:
Well, a couple of Fedoras back, X didn't work except with radeonhd, but now radeon appears to support this one as well; I switched to it, and the CPU issue is gone even with KMS. Now fonts (esp small ones) look very smudgy though. But I suppose there are already bug(s) open on this.
I'm guessing with radeonhd you did something to increase or decrease your font size in some dialog box, they had different ideas on DPI to the rest of the world. Try with a test user, though it might just be DPI changes.
Thanks for input. Neither a test user or rolling back to radeonhd helped; maybe something changed between F11 and F12.
I filed a PR: https://bugzilla.redhat.com/show_bug.cgi?id=542398
Linuxguy123 wrote:
http://www.linux-magazine.com/Online/News/Ubuntu-X.org-Guru-Calls-for-
Desktop-Help
They did exactly what some people suggested we do in this thread: stick with an old X.org X11 release and try to fix its bugs on their own. You can see the result in the article and its links. (Hint: it didn't quite work out…) Following upstream like Fedora does clearly looks like the better strategy to me.
Kevin Kofler
On Mon, 2009-11-30 at 10:01 -0700, Linuxguy123 wrote:
http://www.linux-magazine.com/Online/News/Ubuntu-X.org-Guru-Calls-for-Deskto...
Let's see if I can summarize this article:
- we're getting too many bugs - more testing will find more bugs - therefore we should test more so we have fewer bugs
Interesting bit of logic there.
- ajax
Le 30/11/2009 18:01, Linuxguy123 a écrit :
http://www.linux-magazine.com/Online/News/Ubuntu-X.org-Guru-Calls-for-Deskto...
Instead of whining, he should ask his employer to hire more X hackers, one guy is obviously not *enough*. This has nothing to do with our issue and Fedora at all.
On Mon, Nov 30, 2009 at 10:16 AM, Haïkel Guémar karlthered@gmail.com wrote:
Instead of whining, he should ask his employer to hire more X hackers, one guy is obviously not *enough*. This has nothing to do with our issue and Fedora at all.
What is your definition of hacker? Is he contributing to X.org upstream development or is he just pulling patchsets to be applied to distribution specific packages?
Just as interesting..... he's spent most of his time between UDS and that post trying to address nvidia regressions....
"Fwiw, I pretty much ended up spending 100% of my time between release and UDS on SRU bugs (mainly for -nvidia)"
Yippie for prioritizing regressions in proprietary code!
-jef
Le 30/11/2009 20:28, Jeff Spaleta a écrit :
What is your definition of hacker? Is he contributing to X.org upstream development or is he just pulling patchsets to be applied to distribution specific packages?
Likely the second option, I'd expect from the company claiming leadership on the desktop to be more active on the X.org front especially when it needs more horsepower. The poor man is suffering hardships, off course, he is all alone managing the whole X stack. The sensible answer would be to ask to hire some help, the better would be X developers, at least someone familiar enough with X code base to provide some support. Not complaining about the flood of bugs.
Just as interesting..... he's spent most of his time between UDS and that post trying to address nvidia regressions....
"Fwiw, I pretty much ended up spending 100% of my time between release and UDS on SRU bugs (mainly for -nvidia)"
Yippie for prioritizing regressions in proprietary code!
-jef
On Mon, 2009-11-30 at 10:28 -0900, Jeff Spaleta wrote:
On Mon, Nov 30, 2009 at 10:16 AM, Haïkel Guémar karlthered@gmail.com wrote:
Instead of whining, he should ask his employer to hire more X hackers, one guy is obviously not *enough*. This has nothing to do with our issue and Fedora at all.
What is your definition of hacker? Is he contributing to X.org upstream development or is he just pulling patchsets to be applied to distribution specific packages?
Just as interesting..... he's spent most of his time between UDS and that post trying to address nvidia regressions....
"Fwiw, I pretty much ended up spending 100% of my time between release and UDS on SRU bugs (mainly for -nvidia)"
Yippie for prioritizing regressions in proprietary code!
Nope, Bryce doesn't get to work on upstream in any significant way as part of his Ubuntu work. I was chatting with Dave about this on IRC the other day. The most significant submission to upstream X.org that's ever come out of Ubuntu is a quirk table. (yippee.)
As others have said, this post doesn't really teach Fedora any lessons. It could more accurately have been titled 'Why Having Exactly One X Developer Is A Really Bad Idea For A Major Distribution'.
Nope, Bryce doesn't get to work on upstream in any significant way as
part of his Ubuntu work. I was chatting with Dave about this on IRC the other day. The most significant submission to upstream X.org that's ever come out of Ubuntu is a quirk table. (yippee.)
Did you chatted with Bryce?
On Wed, 2009-12-02 at 11:01 +0000, Ikem Krueger wrote:
Nope, Bryce doesn't get to work on upstream in any significant way as part of his Ubuntu work. I was chatting with Dave about this on IRC the other day. The most significant submission to upstream X.org that's ever come out of Ubuntu is a quirk table. (yippee.)
Did you chatted with Bryce?
Let's chat with git:
atropine:~/xserver% git log --author=bryce | grep -c ^commit 0
atropine:~/drivers/intel% git log --author=bryce --pretty=oneline 6b93afc564a5e74b0eaaa46c95f557449951b3b9 add pipe a force quirk for Dell mini 6c56521bdc0443c0656271caaa795feb13bc1d6b pipe-a quirk for thinkpad x30 83377b543defdca7226d7c1a7794e4ff3d8b4c84 Pipe-A quirk for HP 2730p (bug #18852) 6c4e134a1a30785c2e5c6d57b21fde54a2dd3413 PipeA quirk for Quanta/W251U (launchpad bug #244242) afa630b448e5993850433c9f0b129758ec4d37b5 Add TV out quirk for HP Compaq nx6110 231a302013981cc597ba09ee89b367c8ab56e8ba Two more Dell quirks d91d9e6a2f2ba18b35cb6fd7bc3fe8bc617eb44f More Pipe A force quirks be746a90a87d7a9807fa4243493e7e4d48f7f1c0 More quirks from ubuntu/dell 37bc23660a8c346f1eaa6c93ed2c7a840828f0b0 Quirks from Ubuntu/Dell
atropine:~/drivers/ati% git log --author=bryce --pretty=oneline c71b2f050e8996787eae463eddbfdb5864ffa65a radeon: AGPMode quirk needed for SiS e3659ed06fc5bb8817f1dbd7c2d6bc94c67b30f7 radeon: AGPMode quirk needed for IBM Thinkpad T40 with Mobility M7 LW 2391531ed6b7c11ddd5ab91b2369821cc5f8b8a7 radeon: AGPMode quirk needed for HP Omnibook 6200 49b57767d0d2c041517b0764c2ed2d2ba5a7092c Quirk for RV280 on 82865G/PE/P DRAM Controller/Host-Hub fe73d9a7dfe8ec5c8f1a8dc08e14b4e138aa9276 Add another AGP quirk 36a7dc6ea1e1929e986ab1159497c71521cb2f10 Additional AGP quirks 937b7ac2a259cf504a19dcf62a58b1db1afb8eb9 Add AGP quirk table 1cf7a5494fa94e8d9f30f9b2905dfbe6d4faa445 radeon: Fix pasto in connector table setup for vga powerbooks
- ajax
On 2009/11/26 14:39 (GMT) Terry Barnaby composed:
...
The "cards" I have tried include: Intel Corporation 82945G/GZ Integrated Graphics Controller ATI Technologies Inc RV535 [Radeon X1650 Series] ATI Technologies Inc M22 [Mobility Radeon X300] ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01) VGA compatible controller: Intel Corporation 82G33/G31 Express Integrated Graphics Controller (rev 02)
...
For testing Graphics you need a lot of "testers". I would not have thought that the number of people testing rawhide is enough. I would have thought that real users actually using Fedora are required here. Certainly the F12 release seems to reflect the lack of 3D graphics testing ...
...
Yes, some graphics boards I am sure work well, although 3D should really be working on all cards in 2009 ... But this is the point, there are a lot of different graphics boards, and so a much wider scope for the testing is required here which requires more users over more time with many different applications using basically the same software.
Surely fewer testers find 3D to be relevant to getting their work done. I for one always disable that bling as soon as I see it sneak in past a change in configuration methodology.
I tried an F12 install on rv200 Radeon 36 hours ago, and Anaconda refused to even come up in GUI mode.
Yes, some graphics boards I am sure work well, although 3D should really be working on all cards in 2009 ... But this is the point, there are a lot of different graphics boards, and so a much wider scope for the testing is required here which requires more users over more time with many different applications using basically the same software.
Why do you think 3D should be working in 2009 as opposed to any previous years btw? I'm interested in the logic that leads to this point.
GPUs have gotten more and more complex every 6 months for about 8 years now. A current radeonhd 4000 series bears little resemblence to the radeon r100 that was out then. The newer GPUs require a full complier to be written for an instruction set more complex than x86 in some places. The newer GPUs get more and more varied modesetting combos that all require supporting.
Now I'd would guess (educated slightly) that the amount of code required to write a full driver stack for a modern GPU has probably gone up 40-50x what used to be required, whereas the number of open source community developers has probably doubled since 2001. Also newer GPU designs have forced us to redesign the Linux GPU architecture, this had to happen in parallel with all the other stuff, again with similiar number of developers. So yes it sucks but it should point out why there is no reason why 3D should really be working on all cards.
Dave.
On 11/26/2009 10:12 PM, Dave Airlie wrote:
Yes, some graphics boards I am sure work well, although 3D should really be working on all cards in 2009 ... But this is the point, there are a lot of different graphics boards, and so a much wider scope for the testing is required here which requires more users over more time with many different applications using basically the same software.
Why do you think 3D should be working in 2009 as opposed to any previous years btw? I'm interested in the logic that leads to this point.
GPUs have gotten more and more complex every 6 months for about 8 years now. A current radeonhd 4000 series bears little resemblence to the radeon r100 that was out then. The newer GPUs require a full complier to be written for an instruction set more complex than x86 in some places. The newer GPUs get more and more varied modesetting combos that all require supporting.
Now I'd would guess (educated slightly) that the amount of code required to write a full driver stack for a modern GPU has probably gone up 40-50x what used to be required, whereas the number of open source community developers has probably doubled since 2001. Also newer GPU designs have forced us to redesign the Linux GPU architecture, this had to happen in parallel with all the other stuff, again with similiar number of developers. So yes it sucks but it should point out why there is no reason why 3D should really be working on all cards.
Dave.
Hi Dave,
My logic, if you call it that :), is that for an operating system in 2009 not to have good 3D support across most graphics cards is not good. In earlier years, when 3D was a new beast and not used much that was not an issue, but I would have thought that it should be a reasonably core part of a Desktop computers functionality these days.
As you say, and I'm sure you know better than me, new graphics chipsets are complicated and difficult to get working correctly, especially with limited documentation. In my case though I am using Intel 845G, ATI R200 and ATI R300 based chipsets which are quite old now.
I can see you are working hard on fixing the ATI issues, I thank you very much for all this work, and I will try and feed back issues I am having and help out if I can.
On Thu, Nov 26, 2009 at 11:12 PM, Dave Airlie airlied@redhat.com wrote:
Yes, some graphics boards I am sure work well, although 3D should really be working on all cards in 2009 ... But this is the point, there are a lot of different graphics boards, and so a much wider scope for the testing is required here which requires more users over more time with many different applications using basically the same software.
Why do you think 3D should be working in 2009 as opposed to any previous years btw? I'm interested in the logic that leads to this point.
GPUs have gotten more and more complex every 6 months for about 8 years now. A current radeonhd 4000 series bears little resemblence to the radeon r100 that was out then. The newer GPUs require a full complier to be written for an instruction set more complex than x86 in some places. The newer GPUs get more and more varied modesetting combos that all require supporting.
Now I'd would guess (educated slightly) that the amount of code required to write a full driver stack for a modern GPU has probably gone up 40-50x what used to be required, whereas the number of open source community developers has probably doubled since 2001. Also newer GPU designs have forced us to redesign the Linux GPU architecture, this had to happen in parallel with all the other stuff, again with similiar number of developers. So yes it sucks but it should point out why there is no reason why 3D should really be working on all cards.
Thats true but a driver that does not work with 3D can hardly be called a working driver. Sure GPUs are more complex nowdays and we have limited manpower but most of this complexity (which people pay for) is for 3D.
3D shouldn't be considered as "nice to have" but an essential feature that should be working.
But yeah talking is easy, actually fixing this problem is harder.....
On 2009/11/27 10:28 (GMT+0100) drago01 composed:
3D shouldn't be considered as "nice to have" but an essential feature that should be working.
You can't be serious. 3D is an illusion. A computer display screen only provides two dimensions. 3D is bling that I have 0 use for.
On Fri, Nov 27, 2009 at 11:52 AM, Felix Miata mrmazda@earthlink.net wrote:
On 2009/11/27 10:28 (GMT+0100) drago01 composed:
3D shouldn't be considered as "nice to have" but an essential feature that should be working.
You can't be serious. 3D is an illusion. A computer display screen only provides two dimensions. 3D is bling that I have 0 use for.
The fact that you don't need it does not make my statement invalid. And 3D is way more than useless "bling".
Not that i'm unhappy about the way things are going forward (my intel gfx are working great!), but gnome 3 isn't going to be much useful without 3d support...
2009/11/27, drago01 drago01@gmail.com:
On Fri, Nov 27, 2009 at 11:52 AM, Felix Miata mrmazda@earthlink.net wrote:
On 2009/11/27 10:28 (GMT+0100) drago01 composed:
3D shouldn't be considered as "nice to have" but an essential feature that should be working.
You can't be serious. 3D is an illusion. A computer display screen only provides two dimensions. 3D is bling that I have 0 use for.
The fact that you don't need it does not make my statement invalid. And 3D is way more than useless "bling".
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Fri, 2009-11-27 at 21:24 +0100, stefan riemens wrote:
Not that i'm unhappy about the way things are going forward (my intel gfx are working great!), but gnome 3 isn't going to be much useful without 3d support...
Note that gnome-shell working was quite high in Dave's priority list (within the range of 'things RH staff get paid for').
On 11/27/09, Adam Williamson awilliam@redhat.com wrote:
On Fri, 2009-11-27 at 21:24 +0100, stefan riemens wrote:
Not that i'm unhappy about the way things are going forward (my intel gfx are working great!), but gnome 3 isn't going to be much useful without 3d support...
Note that gnome-shell working was quite high in Dave's priority list (within the range of 'things RH staff get paid for').
That's both good to know and also not surprising as having tested Moblin on both ATI and Nouveau devices waiting 15 seconds for a menu to respond is less than ideal :-) I suspect that with both Moblin and gnome-shell depending on clutter/mutter that this will be something we see moving forward in leaps and bounds in the next 12 months in the lead up to gnome 3 or else its going to suck on open drivers.
Peter
On Fri, 2009-11-27 at 21:24 +0100, stefan riemens wrote:
Not that i'm unhappy about the way things are going forward (my intel gfx are working great!), but gnome 3 isn't going to be much useful without 3d support...
3D driver for r600 is 35,000 lines just the chipset specific code, Another 150,000 lines for the mesa core it uses.
Now the hard part with OpenGL or and 3D interface is its massive, we probably need to write another few thousand lines of code to get a decent r600 3D driver that can do GL2.0. Now gnome-shell use of GL is a very known quantity same for compiz, we also have the g-s authors on hand to tell us what is happening. So debugging g-s or compiz is insanely easy compared to say blender or wine games.
We (Red Hat or Fedora) currently don't have access to any sort of conformance suite for our GL though Intel and VMware have started at least doing more and more regression test work lately so less and less crap is making it way into the mainline and thus to users.
So hopefully things get better as we move forward and more companies invest time in the 3D driver stack.
Dave.
On 11/28/2009 02:13 AM, Dave Airlie wrote:
We (Red Hat or Fedora) currently don't have access to any sort of conformance suite for our GL though Intel and VMware have started at least doing more and more regression test work lately so less and less crap is making it way into the mainline and thus to users.
Have we tried asking Intel or VMWare for access to their tests?
Rahul
On Sat, 2009-11-28 at 02:11 +0530, Rahul Sundaram wrote:
On 11/28/2009 02:13 AM, Dave Airlie wrote:
We (Red Hat or Fedora) currently don't have access to any sort of conformance suite for our GL though Intel and VMware have started at least doing more and more regression test work lately so less and less crap is making it way into the mainline and thus to users.
Have we tried asking Intel or VMWare for access to their tests?
We all use piglit from an open source point of view and they both add tests to that quite regularly. we also run some wine dx9 tests.
The main non-open conformance tests suites are the OpenGL suite from Khronos now, and the DX test suite from Microsoft. VMware generally run XP inside a VMware session and run the DX test suite on their virtual GPU which finds a crap load of bugs in the host 3D drivers.
Neither of these are really good solutions for us (though I think an interested user could reproduce the VMware system).
Dave.
On 2009/11/27 21:21 (GMT+0100) drago01 composed:
Fri, 27 Nov 2009 05:52:25 -0500 Felix Miata composed:
On 2009/11/27 10:28 (GMT+0100) drago01 composed:
3D shouldn't be considered as "nice to have" but an essential feature that should be working.
You can't be serious. 3D is an illusion. A computer display screen only provides two dimensions. 3D is bling that I have 0 use for.
The fact that you don't need it does not make my statement invalid. And 3D is way more than useless "bling".
What makes your statement invalid is your use of the word "essential". Bling and essential are mutually exclusive characteristics WRT to normal desktop users. I didn't use the word "useless". And yes, 3D is way more - way more overhead, way more imposition on older hardware. 3D cannot be essential to users of older hardware, since it turns their hardware into unresponsive mush.
On 11/28/2009 02:21 AM, Felix Miata wrote:
What makes your statement invalid is your use of the word "essential". Bling and essential are mutually exclusive characteristics WRT to normal desktop users. I didn't use the word "useless". And yes, 3D is way more - way more overhead, way more imposition on older hardware. 3D cannot be essential to users of older hardware, since it turns their hardware into unresponsive mush.
3D is not just for games and bling. People who work on CAD/CAM, 3D rendering software etc would definitely find it essential. It is not something Red Hat focuses on too much and requires more community development. For them, it makes sense to participate in the test days or try out Rawhide and report bugs as early as possible to help get the next release in a shape suitable for their requirements.
Rahul
On 2009/11/28 02:53 (GMT+0530) Rahul Sundaram composed:
On 11/28/2009 02:21 AM, Felix Miata wrote:
What makes your statement invalid is your use of the word "essential". Bling and essential are mutually exclusive characteristics WRT to normal desktop
^^^^^^^^^^^^^^^^^^^^^
users. I didn't use the word "useless". And yes, 3D is way more - way more
^^^^^
overhead, way more imposition on older hardware. 3D cannot be essential to users of older hardware, since it turns their hardware into unresponsive mush.
3D is not just for games and bling.
No kidding! Note keywords above.
People who work on CAD/CAM, 3D rendering software etc would definitely find it essential.
Somehow those niche users managed 10-20 years ago before there was such a thing as 3D support in XFree86/Xorg.
On 11/28/2009 02:49 AM, Felix Miata wrote:
On 2009/11/28 02:53 (GMT+0530) Rahul Sundaram composed:
On 11/28/2009 02:21 AM, Felix Miata wrote:
What makes your statement invalid is your use of the word "essential". Bling and essential are mutually exclusive characteristics WRT to normal desktop
^^^^^^^^^^^^^^^^^^^^^users. I didn't use the word "useless". And yes, 3D is way more - way more
^^^^^
overhead, way more imposition on older hardware. 3D cannot be essential to users of older hardware, since it turns their hardware into unresponsive mush.
3D is not just for games and bling.
No kidding! Note keywords above.
You assume normal desktop users don't have requirement for 3D which is just plain wrong. Every modern desktop has made 3D a key part of the user interface. Even in Linux, this is increasingly the trend with Compiz and now GNOME Shell. Compositing is sooner or later going to be enabled by default everywhere.
People who work on CAD/CAM, 3D rendering software etc would definitely find it essential.
Somehow those niche users managed 10-20 years ago before there was such a thing as 3D support in XFree86/Xorg.
Times and expectations change.
Rahul
On 2009/11/28 03:37 (GMT+0530) Rahul Sundaram composed:
Compositing is sooner or later going to be enabled by default everywhere.
Somehow those niche users managed 10-20 years ago before there was such a thing as 3D support in XFree86/Xorg.
Times and expectations change.
Physics don't. A two dimensional screen will never be able to more than simulate 3D. 3D requires more dead dinosaurs, coal and/or other sources of electrical energy than 2D to produce. I don't expect that to change, and even if it does, using more than necessary will remain a wasteful allocation of quickly diminishing global resources. Consequently, "enabled by default" will be ecologically irresponsible if it does come to pass.
On 11/28/2009 03:26 AM, Felix Miata wrote:
On 2009/11/28 03:37 (GMT+0530) Rahul Sundaram composed:
Compositing is sooner or later going to be enabled by default everywhere.
Somehow those niche users managed 10-20 years ago before there was such a thing as 3D support in XFree86/Xorg.
Times and expectations change.
Physics don't. A two dimensional screen will never be able to more than simulate 3D.
So who cares if it simulated or not? A lot of things in software is that way. Drag and drop for instance. Doesn't make them any less useful. This is irrelevant point that you keep bringing up.
3D requires more dead dinosaurs, coal and/or other sources of
electrical energy than 2D to produce. I don't expect that to change, and even if it does, using more than necessary will remain a wasteful allocation of quickly diminishing global resources. Consequently, "enabled by default" will be ecologically irresponsible if it does come to pass.
Huh? Your perspective just seems very odd. In a year, if we don't have a composited desktop by default in Fedora, I would be very very surprised. Just watch.
Rahul
On 2009/11/28 03:01 (GMT+0530) Rahul Sundaram composed:
Huh? Your perspective just seems very odd. In a year, if we don't have a composited desktop by default in Fedora, I would be very very surprised. Just watch.
Good thing all puters don't depend on batteries for power.
On Fri, Nov 27, 2009 at 11:29 PM, Felix Miata mrmazda@earthlink.net wrote:
On 2009/11/28 03:01 (GMT+0530) Rahul Sundaram composed:
Huh? Your perspective just seems very odd. In a year, if we don't have a composited desktop by default in Fedora, I would be very very surprised. Just watch.
Good thing all puters don't depend on batteries for power.
It does not matter how often people repeat that (and even if KDE has an option to "disable composting to save power") just running a composite manager should NOT require any more power. If it does it is just broken. In fact it should use LESS power if done right (less wakeups because you don't have to update the whole screen every time something changes),
Let me say this again a cm DOES NOT require more power than a non composited desktop. (notice the NOT)
My laptop uses 6.9W-8W when running compiz, and about the same when running metacity (intel GM45).
On Sat, 28 Nov 2009 00:32:04 +0100 drago01 drago01@gmail.com wrote:
On Fri, Nov 27, 2009 at 11:29 PM, Felix Miata mrmazda@earthlink.net wrote:
On 2009/11/28 03:01 (GMT+0530) Rahul Sundaram composed:
Huh? Your perspective just seems very odd. In a year, if we don't have a composited desktop by default in Fedora, I would be very very surprised. Just watch.
Good thing all puters don't depend on batteries for power.
It does not matter how often people repeat that (and even if KDE has an option to "disable composting to save power") just running a composite manager should NOT require any more power. If it does it is just broken. In fact it should use LESS power if done right (less wakeups because you don't have to update the whole screen every time something changes),
Let me say this again a cm DOES NOT require more power than a non composited desktop. (notice the NOT)
sadly I am no longer convinced you are correct. But to each their own..... in the long run we'll end up with whatever solution is best, whichever it is.
On Fri, Nov 27, 2009 at 4:01 PM, Rahul Sundaram sundaram@fedoraproject.orgwrote:
On 11/28/2009 03:26 AM, Felix Miata wrote:
3D requires more dead dinosaurs, coal and/or other sources of electrical energy than 2D to produce. I don't expect that to change, and
even
if it does, using more than necessary will remain a wasteful allocation
of
quickly diminishing global resources. Consequently, "enabled by default"
will
be ecologically irresponsible if it does come to pass.
Huh? Your perspective just seems very odd. In a year, if we don't have a composited desktop by default in Fedora, I would be very very surprised. Just watch.
Rahul
I actually would be surprised if we had a composited desktop in Fedora by default in a year. Maybe if the radical changes going on in Mesa's master tree weren't going on, that wouldn't be surprising. However, with the Gallium work, I seriously doubt that we will have composited desktop by default next year.
Also, it would be nice if in a repo with experimental graphics drivers, the gallium drivers could be made available. Gallium will soon be the way that VMware offers accelerated 3D for Linux guests since they contributed a gallium driver. Given that, I think it should get some exposure to the rest of the Fedora community to get stuff tested. Gallium isn't totally broken, last I heard. In fact, I think the ATi gallium driver is supposed to be at least partially working.
On Fri, 2009-11-27 at 17:02 -0600, Sir Gallantmon wrote:
On Fri, Nov 27, 2009 at 4:01 PM, Rahul Sundaram sundaram@fedoraproject.org wrote: On 11/28/2009 03:26 AM, Felix Miata wrote:
> 3D requires more dead dinosaurs, coal and/or other sources of > electrical energy than 2D to produce. I don't expect that to change, and even > if it does, using more than necessary will remain a wasteful allocation of > quickly diminishing global resources. Consequently, "enabled by default" will > be ecologically irresponsible if it does come to pass. Huh? Your perspective just seems very odd. In a year, if we don't have a composited desktop by default in Fedora, I would be very very surprised. Just watch. RahulI actually would be surprised if we had a composited desktop in Fedora by default in a year. Maybe if the radical changes going on in Mesa's master tree weren't going on, that wouldn't be surprising. However, with the Gallium work, I seriously doubt that we will have composited desktop by default next year.
Also, it would be nice if in a repo with experimental graphics drivers, the gallium drivers could be made available. Gallium will soon be the way that VMware offers accelerated 3D for Linux guests since they contributed a gallium driver. Given that, I think it should get some exposure to the rest of the Fedora community to get stuff tested. Gallium isn't totally broken, last I heard. In fact, I think the ATi gallium driver is supposed to be at least partially working.
Packaging gallium drivers doesn't give us anything useful at the moment.
Everything else required to run them is in the distro, the overhead of git cloning mesa and following instructions to get a gallium driver is the least of using those drivers worries.
The problem with packaging anything like the current gallium drivers is the rate of change is too high, that by the time you've built the package in koji, its already out of date and possibly useless.
It would require someone staying on top of it full time for little benefit to Fedora or to the gallium driver writers who would need you to have the git tree so you could test patches etc.
Dave.
2009/11/28 Felix Miata mrmazda@earthlink.net:
Physics don't. A two dimensional screen will never be able to more than simulate 3D. 3D requires more dead dinosaurs, coal and/or other sources of electrical energy than 2D to produce.
lol. That was truly funny (and true)!
On 11/27/2009 04:56 PM, Felix Miata wrote:
Physics don't. A two dimensional screen will never be able to more than simulate 3D. 3D requires more dead dinosaurs, coal and/or other sources of electrical energy than 2D to produce.
This isn't necessarily the case, in theory or in practice. I used an ammeter to do some measurements of this on my T41[1] several releases ago[2], and in general compositing the desktop using 3d hardware used slightly less energy than running with desktop effects turned off.
Which is to say, if the 3d hardware can do something easily, it may use more energy for the GPU than using 2d acceleration only, but that translates to less energy doesn't necessarily mean more power for the whole system. If you do more complex 3d things, yes, it will take more power, but the act of using the 3d hardware instead of the 2d hardware can be more efficient in terms of energy.
[1] that's 2373-9FU for those wondering. [2] a bit after compiz came into existance
On 11/30/2009 05:05 PM, Peter Jones wrote:
On 11/27/2009 04:56 PM, Felix Miata wrote:
Physics don't. A two dimensional screen will never be able to more than simulate 3D. 3D requires more dead dinosaurs, coal and/or other sources of electrical energy than 2D to produce.
This isn't necessarily the case, in theory or in practice. I used an ammeter to do some measurements of this on my T41[1] several releases ago[2], and in general compositing the desktop using 3d hardware used slightly less energy than running with desktop effects turned off.
Which is to say, if the 3d hardware can do something easily, it may use more energy for the GPU than using 2d acceleration only, but that translates to less energy doesn't necessarily mean more power for the whole system. If you do more complex 3d things, yes, it will take more power, but the act of using the 3d hardware instead of the 2d hardware can be more efficient in terms of energy.
[1] that's 2373-9FU for those wondering. [2] a bit after compiz came into existance
Whilst I am sure you are right, I do think that the current generation of Graphics chips used in computers are too power hungry. Just look at the heatsinks and fans on a lot of desktop graphics boards or how hot the integrated graphics chipsets get... Most of this power usage seems to stem from the additional 3D circuitry within them and is used even if the 3D features are not. Although I do need 3D on some of my systems (for CAD/CAM not bling) I do try and look for a simple, low power graphics systems for those that don't and this I find difficult to do as most chipsets have gone 3D. I expect that graphics chipset manufacturers may start to improve power usage now with more focus on power usage and the fact that processors can consume less than the graphics chipsets used, we will see, but I would lament the day when a desktop GUI system relied on having 3D support.
Rahul Sundaram wrote:
You assume normal desktop users don't have requirement for 3D which is just plain wrong. Every modern desktop has made 3D a key part of the user interface. Even in Linux, this is increasingly the trend with Compiz and now GNOME Shell.
And KWin compositing / desktop effects before that (but after Compiz).
Compositing is sooner or later going to be enabled by default everywhere.
Right, it already is in upstream KDE, we're disabling it by default in Fedora due to the sad driver situation. But with drivers getting more reliable, we may change this.
Kevin Kofler
3D cannot be essential to users of older hardware, since it turns their hardware into unresponsive mush.
How about visually impaired people? Compiz and the zoom plugin *are* essential to them.
A friend of mine has an old computer, which is « turned into unresponsive mush » by 3D, as you say. But at least, now he can read what's on his screen, and thus actually use his computer. ;)
----------
Mathieu Bridon (bochecha)
On Fri, Dec 4, 2009 at 9:02 PM, Kevin Kofler kevin.kofler@chello.at wrote:
Mathieu Bridon (bochecha) wrote:
How about visually impaired people? Compiz and the zoom plugin *are* essential to them.
They can use the plain old KMag which doesn't require any sort of compositing at all.
Kevin Kofler
But why? And if you didn't install KDE, I doubt you would have KMag installed. And all the dependencies that get pulled in for installing a single KDE app is ridiculous. Plus, Compiz and the zoom plugin are smoother and more effective than KMag.
2009/12/5 Sir Gallantmon ngompa13@gmail.com:
On Fri, Dec 4, 2009 at 9:02 PM, Kevin Kofler kevin.kofler@chello.at wrote:
Mathieu Bridon (bochecha) wrote:
How about visually impaired people? Compiz and the zoom plugin *are* essential to them.
They can use the plain old KMag which doesn't require any sort of compositing at all.
Kevin Kofler
But why? And if you didn't install KDE, I doubt you would have KMag installed. And all the dependencies that get pulled in for installing a single KDE app is ridiculous. Plus, Compiz and the zoom plugin are smoother and more effective than KMag.
Orca then, whatever. Point is, it's possible without compiz.
On Sat, Dec 5, 2009 at 12:31 PM, Mat Booth fedora@matbooth.co.uk wrote:
Orca then, whatever. Point is, it's possible without compiz.
Isn't Orca's magnifier getting phased out?
Yeah. And whenever GNOME Shell rolls out their new accessibility magnifier...well, it's gonna need compositing. Like everything else.
Not to mention that without compositing, usable full-screen magnification really isn't possible. Orca lets you zoom in the screen -- but at modern resolutions, it's a slideshow of a magnifier that doesn't let you do much else very fluidly.
On Fri, Nov 27, 2009 at 08:12:05 +1000, Dave Airlie airlied@redhat.com wrote:
Why do you think 3D should be working in 2009 as opposed to any previous years btw? I'm interested in the logic that leads to this point.
I think one thing that is changing expectations is ATI providing documentation again. I was expecting significant improvements for F12, but near the end I had mostly given up on them. Then between the beta and the release some updates fixed some issues for me and in the end things are pretty much what I expected for radeon support.
The nouveau guys actually did better than I expected since they aren't getting any help from nVidia.
On Fri, 2009-11-27 at 13:42 -0600, Bruno Wolff III wrote:
On Fri, Nov 27, 2009 at 08:12:05 +1000, Dave Airlie airlied@redhat.com wrote:
Why do you think 3D should be working in 2009 as opposed to any previous years btw? I'm interested in the logic that leads to this point.
I think one thing that is changing expectations is ATI providing documentation again. I was expecting significant improvements for F12, but near the end I had mostly given up on them. Then between the beta and the release some updates fixed some issues for me and in the end things are pretty much what I expected for radeon support.
The documentation is great, but it doesn't answer every question, its a guide how a driver for an idealised version of a radeon would look, you then spend most of the time working in the grey undocumented area between the ideal GPU the hw guys wanted to produce and the piece of silicon they ended up shipping.
Also areas like ACPI interaction, suspend/resume, etc are all generally OEM level things so AMD have nothing to do with it, and really can't document it.
The nouveau guys actually did better than I expected since they aren't getting any help from nVidia.
Its a double edged sword, knowing you won't get any help, means you rarely have to wait for anyones help, so you can just do it (though its really really hard to do), I keep the poor AMD open-source guys under a heavy snow of information enquiries.
Dave.
Rudolf Kastl <che666 <at> gmail.com> writes:
intel (i965) works fine...
You are lucky. Major regressions there in F-12. On my hardware, this used to work when nomodeset was passed to kernel. Now, it doesn't any more. With KMS, on the other hand, hibernate/thaw or suspend/resume causes the whole system to go berserk after a few cycles. So, I'm back to metacity and 2D. Bugs filed, of course, etc.
-- Bojan
On Sun, Nov 29, 2009 at 10:46 PM, Bojan Smojver wrote:
Rudolf Kastl writes:
intel (i965) works fine...
You are lucky. Major regressions there in F-12. On my hardware, this used to work when nomodeset was passed to kernel. Now, it doesn't any more. With KMS, on the other hand, hibernate/thaw or suspend/resume causes the whole system to go berserk after a few cycles. So, I'm back to metacity and 2D. Bugs filed, of course, etc.
I've got a i965, and while I admit that it's still a little rough, it works mostly fine, with KMS and 3D doing fine. Compiz and GNOME Shell are pretty functional, and suspend and hibernate are nearly flawless (or at least as flawless is on Linux).
The only real problem is a conflict with rendering in Qt-demo, but...alas.
Le 30/11/2009 19:24, Jud Craft a écrit :
On Sun, Nov 29, 2009 at 10:46 PM, Bojan Smojver wrote:
Rudolf Kastl writes:
intel (i965) works fine...
You are lucky. Major regressions there in F-12. On my hardware, this used to work when nomodeset was passed to kernel. Now, it doesn't any more. With KMS, on the other hand, hibernate/thaw or suspend/resume causes the whole system to go berserk after a few cycles. So, I'm back to metacity and 2D. Bugs filed, of course, etc.
I've got a i965, and while I admit that it's still a little rough, it works mostly fine, with KMS and 3D doing fine. Compiz and GNOME Shell are pretty functional, and suspend and hibernate are nearly flawless (or at least as flawless is on Linux).
The only real problem is a conflict with rendering in Qt-demo, but...alas.
For the Qt-demo rendering issue on intel, it is fixed by Qt 4.6.
On Thu, 2009-11-26 at 14:01 +0000, Terry Barnaby wrote:
Ok, controversial title.
I have just tried to test install F12 on some of my systems, (5 different ones). All of these bar 1 has problems with the graphics (X11 lockups, system lockups and other problems) mainly in 3D but also in 2D. I still am using F8 on most of my systems as the Graphics systems have not been stable enough for 3D in Fedora since around those times.
I know there is a lot of work going on in the graphics front, I myself have worked on and fed back issues as time and ability allow. During F11 I helped with some issues, but unfortunately none of these made it back into updates for F11 and now F12 is out with yet more issues.
The Linux kernel is generally relatively stable, as is the main system libraries etc in Fedora. The core issues most people seem to be facing is Graphics and Sound issues. Obviously a major issue with Graphics is the sheer number of different graphics chip sets in use and the lack of documentation for quite a few of them. Due to this it requires a lot of user testing and feedback to get these issues sorted out. Unfortunately the very fast Fedora new release schedule gets in the way of getting this testing done and things do not get fixed prior to a new release which introduces yet another set of problems. The new release speed also uses a lot of developer and user time in just managing to create a new release and updating systems to use it.
I know the quick release cycle is one of Fedora's features in its aim to be close to the leading edge, but this has to be balanced with usability otherwise there will be few people actually using it in anger and thus actually testing the software. This could lead to the demise of Fedora.
As an idea, at this stage, how about canceling the F13 release and just fixing and updating the F12 release ? This will concentrate developers and users into one system release. Similar to the pre-release test days we could have post-release test days. For example a Graphics test day for F12 where a certain set of tests with a test suite and a set of well known applications could be run. As F12 would be out longer, more people could participate in this. If a commitment, all round, to producing updates fixing the issues in F12 were made, I think more people would be willing to participate as users could expect to see a stable system for their efforts.
+1 on this.
I have 4 bugs entered into bugzilla related to display problems and none of them get any attention. I even posted a warning to the group about this matter. (See November 16, "Warning about possible display issues with F12 upgrade".)
For KDE users, this situation has been building for a while. Back in F9 the Folderview widget didn't work correctly with some nvidia cards, supposedly because of issues in the proprietary nvidia driver. The developer's response to this: tough luck for using a proprietary driver. Now that the open source nvidia driver is out they say to use it. The problem with nouveau is that it has just as many or more problems than the proprietary driver, albeit in different areas.
I am not buying that all of the display problems are caused by the proprietary driver. And if they are, why do these bugs get closed ? They should be forwarded to nvidia for work.
Aside: I know, the bug reporter should forward them to nvidia. But then why even report a bug to the Redhat bugzilla ? EVERYTHING is upstream to them ! And the problem with reporting the bug (non proprietary nvidia) upstream is that they say that we aren't running the general release of the component, we are running the Fedora version and thus Fedora should fix it.
I am VERY frustrated with the state of the display components right now. I am quite frustrated with how display component bugs are handled by the Fedora developers. I think some things need to change.
I'm holding back from upgrading to F12 until I hear that some of these issues are resolved.
Linuxguy123 wrote:
I have 4 bugs entered into bugzilla related to display problems and none of them get any attention. I even posted a warning to the group about this matter. (See November 16, "Warning about possible display issues with F12 upgrade".)
If these are the ones you linked to earlier, from Rahul's reply, they're waiting on you for these. Haven't checked myself, so maybe the status has changed or these aren't your bugs.
For KDE users, this situation has been building for a while. Back in F9 the Folderview widget didn't work correctly with some nvidia cards, supposedly because of issues in the proprietary nvidia driver. The developer's response to this: tough luck for using a proprietary driver. Now that the open source nvidia driver is out they say to use it. The problem with nouveau is that it has just as many or more problems than the proprietary driver, albeit in different areas.
Nouveau is the nicest driver I've used when it comes to stability. The only places I've encountered issues are with 3d because it's not supported fully so that's more of a missing feature than a bug and coming back from sleep with some artifacts that disappear when the screen is unlocked. The blob driver gets many more issues than nouveau and I can't imagine going back on any install I use day to day.
I am not buying that all of the display problems are caused by the proprietary driver. And if they are, why do these bugs get closed ? They should be forwarded to nvidia for work.
A lot are. And *you* should forward them. All we can do is say "there's a problem with your driver that X had, go talk to this guy for details". Since I don't run the driver, I can't even attempt to reproduce any issues that you have other than "well, works with nouveau". We'd be wasting time shuttling messages back and forth.
Aside: I know, the bug reporter should forward them to nvidia. But then why even report a bug to the Redhat bugzilla ? EVERYTHING is upstream to them !
Well, we can at least track it and know when it's fixed to get any related fixes included sooner. Also, we can see if it's truly our problem or not.
And the problem with reporting the bug (non proprietary nvidia) upstream is that they say that we aren't running the general release of the component, we are running the Fedora version and thus Fedora should fix it.
If they give us some source code to work on, we could. As it stands, we can't do *anything* if it doesn't work with their driver and it works with others. As for forwarding bugs upstream, you know what went wrong better than we do. makes no sense for us to play a middleman in communication.
I am VERY frustrated with the state of the display components right now. I am quite frustrated with how display component bugs are handled by the Fedora developers. I think some things need to change.
For nvidia stuff, what are we to do? I don't (as do many other developers) know much about X and the driver inner workings and if I do get started with it, poking the black box that nvidia ships is surely the last thing I ever want to do with it.
--Ben
On Nov 26, 2009, at 6:01, Terry Barnaby terry1@beam.ltd.uk wrote:
Ok, controversial title.
I have just tried to test install F12 on some of my systems, (5 different ones). All of these bar 1 has problems with the graphics (X11 lockups, system lockups and other problems) mainly in 3D but also in 2D. I still am using F8 on most of my systems as the Graphics systems have not been stable enough for 3D in Fedora since around those times.
I know there is a lot of work going on in the graphics front, I myself have worked on and fed back issues as time and ability allow. During F11 I helped with some issues, but unfortunately none of these made it back into updates for F11 and now F12 is out with yet more issues.
The Linux kernel is generally relatively stable, as is the main system libraries etc in Fedora. The core issues most people seem to be facing is Graphics and Sound issues. Obviously a major issue with Graphics is the sheer number of different graphics chip sets in use and the lack of documentation for quite a few of them. Due to this it requires a lot of user testing and feedback to get these issues sorted out. Unfortunately the very fast Fedora new release schedule gets in the way of getting this testing done and things do not get fixed prior to a new release which introduces yet another set of problems. The new release speed also uses a lot of developer and user time in just managing to create a new release and updating systems to use it.
I know the quick release cycle is one of Fedora's features in its aim to be close to the leading edge, but this has to be balanced with usability otherwise there will be few people actually using it in anger and thus actually testing the software. This could lead to the demise of Fedora.
As an idea, at this stage, how about canceling the F13 release and just fixing and updating the F12 release ? This will concentrate developers and users into one system release. Similar to the pre- release test days we could have post-release test days. For example a Graphics test day for F12 where a certain set of tests with a test suite and a set of well known applications could be run. As F12 would be out longer, more people could participate in this. If a commitment, all round, to producing updates fixing the issues in F12 were made, I think more people would be willing to participate as users could expect to see a stable system for their efforts.
You make the assumption that if fedora stopped, s
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Nov 26, 2009, at 6:01, Terry Barnaby terry1@beam.ltd.uk wrote:
Ok, controversial title.
I have just tried to test install F12 on some of my systems, (5 different ones). All of these bar 1 has problems with the graphics (X11 lockups, system lockups and other problems) mainly in 3D but also in 2D. I still am using F8 on most of my systems as the Graphics systems have not been stable enough for 3D in Fedora since around those times.
I know there is a lot of work going on in the graphics front, I myself have worked on and fed back issues as time and ability allow. During F11 I helped with some issues, but unfortunately none of these made it back into updates for F11 and now F12 is out with yet more issues.
The Linux kernel is generally relatively stable, as is the main system libraries etc in Fedora. The core issues most people seem to be facing is Graphics and Sound issues. Obviously a major issue with Graphics is the sheer number of different graphics chip sets in use and the lack of documentation for quite a few of them. Due to this it requires a lot of user testing and feedback to get these issues sorted out. Unfortunately the very fast Fedora new release schedule gets in the way of getting this testing done and things do not get fixed prior to a new release which introduces yet another set of problems. The new release speed also uses a lot of developer and user time in just managing to create a new release and updating systems to use it.
I know the quick release cycle is one of Fedora's features in its aim to be close to the leading edge, but this has to be balanced with usability otherwise there will be few people actually using it in anger and thus actually testing the software. This could lead to the demise of Fedora.
As an idea, at this stage, how about canceling the F13 release and just fixing and updating the F12 release ? This will concentrate developers and users into one system release. Similar to the pre- release test days we could have post-release test days. For example a Graphics test day for F12 where a certain set of tests with a test suite and a set of well known applications could be run. As F12 would be out longer, more people could participate in this. If a commitment, all round, to producing updates fixing the issues in F12 were made, I think more people would be willing to participate as users could expect to see a stable system for their efforts.
You make the assumption that if fedora stopped, so would upstream. You also state that the kernel is stable, yet most of the graphics work is going on at the kernel level so we have to continue to bring in new kernels to pick up these changes.
Graphics work is not a fedora issue alone. It is an upstream issue first and formost. By abandoning upstream and trying to stagnate will ultimatly damage upstreams ability to gennew changes tested and released.
-- Jes
On 11/26/2009 05:05 PM, Jesse Keating wrote:
On Nov 26, 2009, at 6:01, Terry Barnaby terry1@beam.ltd.uk wrote:
Ok, controversial title.
I have just tried to test install F12 on some of my systems, (5 different ones). All of these bar 1 has problems with the graphics (X11 lockups, system lockups and other problems) mainly in 3D but also in 2D. I still am using F8 on most of my systems as the Graphics systems have not been stable enough for 3D in Fedora since around those times.
I know there is a lot of work going on in the graphics front, I myself have worked on and fed back issues as time and ability allow. During F11 I helped with some issues, but unfortunately none of these made it back into updates for F11 and now F12 is out with yet more issues.
The Linux kernel is generally relatively stable, as is the main system libraries etc in Fedora. The core issues most people seem to be facing is Graphics and Sound issues. Obviously a major issue with Graphics is the sheer number of different graphics chip sets in use and the lack of documentation for quite a few of them. Due to this it requires a lot of user testing and feedback to get these issues sorted out. Unfortunately the very fast Fedora new release schedule gets in the way of getting this testing done and things do not get fixed prior to a new release which introduces yet another set of problems. The new release speed also uses a lot of developer and user time in just managing to create a new release and updating systems to use it.
I know the quick release cycle is one of Fedora's features in its aim to be close to the leading edge, but this has to be balanced with usability otherwise there will be few people actually using it in anger and thus actually testing the software. This could lead to the demise of Fedora.
As an idea, at this stage, how about canceling the F13 release and just fixing and updating the F12 release ? This will concentrate developers and users into one system release. Similar to the pre-release test days we could have post-release test days. For example a Graphics test day for F12 where a certain set of tests with a test suite and a set of well known applications could be run. As F12 would be out longer, more people could participate in this. If a commitment, all round, to producing updates fixing the issues in F12 were made, I think more people would be willing to participate as users could expect to see a stable system for their efforts.
You make the assumption that if fedora stopped, so would upstream. You also state that the kernel is stable, yet most of the graphics work is going on at the kernel level so we have to continue to bring in new kernels to pick up these changes.
Graphics work is not a fedora issue alone. It is an upstream issue first and formost. By abandoning upstream and trying to stagnate will ultimatly damage upstreams ability to gennew changes tested and released.
-- Jes
I'm not suggesting F12 should not be updated, in fact the opposite.
As you state most of the Graphics work is being done up-stream, but it is the distributions role to package, release and allow users to test this and feed back bugs. I am saying that a focus on Graphics with a quick update cycle will help upstream get the testing they need and the users to get fixes.
Actually a question on the Mesa packages, these are packaged as version 7.6-0.13 in F12. It seems however, that this is packaged from Mesa's 7.7-devel tree. I think the mesa developers have branched 7.6 as a stable branch and moved new development to 7.7. Shouldn't F12's Mesa packages have a 7.7 version number ??
On Nov 26, 2009, at 9:27, Terry Barnaby terry1@beam.ltd.uk wrote:
On 11/26/2009 05:05 PM, Jesse Keating wrote:
On Nov 26, 2009, at 6:01, Terry Barnaby terry1@beam.ltd.uk wrote:
Ok, controversial title.
I have just tried to test install F12 on some of my systems, (5 different ones). All of these bar 1 has problems with the graphics (X11 lockups, system lockups and other problems) mainly in 3D but also in 2D. I still am using F8 on most of my systems as the Graphics systems have not been stable enough for 3D in Fedora since around those times.
I know there is a lot of work going on in the graphics front, I myself have worked on and fed back issues as time and ability allow. During F11 I helped with some issues, but unfortunately none of these made it back into updates for F11 and now F12 is out with yet more issues.
The Linux kernel is generally relatively stable, as is the main system libraries etc in Fedora. The core issues most people seem to be facing is Graphics and Sound issues. Obviously a major issue with Graphics is the sheer number of different graphics chip sets in use and the lack of documentation for quite a few of them. Due to this it requires a lot of user testing and feedback to get these issues sorted out. Unfortunately the very fast Fedora new release schedule gets in the way of getting this testing done and things do not get fixed prior to a new release which introduces yet another set of problems. The new release speed also uses a lot of developer and user time in just managing to create a new release and updating systems to use it.
I know the quick release cycle is one of Fedora's features in its aim to be close to the leading edge, but this has to be balanced with usability otherwise there will be few people actually using it in anger and thus actually testing the software. This could lead to the demise of Fedora.
As an idea, at this stage, how about canceling the F13 release and just fixing and updating the F12 release ? This will concentrate developers and users into one system release. Similar to the pre-release test days we could have post-release test days. For example a Graphics test day for F12 where a certain set of tests with a test suite and a set of well known applications could be run. As F12 would be out longer, more people could participate in this. If a commitment, all round, to producing updates fixing the issues in F12 were made, I think more people would be willing to participate as users could expect to see a stable system for their efforts.
You make the assumption that if fedora stopped, so would upstream. You also state that the kernel is stable, yet most of the graphics work is going on at the kernel level so we have to continue to bring in new kernels to pick up these changes.
Graphics work is not a fedora issue alone. It is an upstream issue first and formost. By abandoning upstream and trying to stagnate will ultimatly damage upstreams ability to gennew changes tested and released.
-- Jes
I'm not suggesting F12 should not be updated, in fact the opposite.
As you state most of the Graphics work is being done up-stream, but it is the distributions role to package, release and allow users to test this and feed back bugs. I am saying that a focus on Graphics with a quick update cycle will help upstream get the testing they need and the users to get fixes.
This is what rawhide is for. Rapid updates with fast feedback and upstream snapshots. It is not the role of a stable release to be grabbing upstream new stuff and throwing it at users without abandon.
-- Jes
Terry Barnaby wrote:
I have just tried to test install F12 on some of my systems, (5 different ones). All of these bar 1 has problems with the graphics (X11 lockups, system lockups and other problems) mainly in 3D but also in 2D.
That's surprising as I've read mostly positive feedback about graphics in F12 so far, at least compared to F11. Maybe you are just really unlucky?
Kevin Kofler
Am 2009-11-27 04:53, schrieb Kevin Kofler:
Terry Barnaby wrote:
I have just tried to test install F12 on some of my systems, (5 different ones). All of these bar 1 has problems with the graphics (X11 lockups, system lockups and other problems) mainly in 3D but also in 2D.
That's surprising as I've read mostly positive feedback about graphics in F12 so far, at least compared to F11. Maybe you are just really unlucky?
Kevin Kofler
I am having two problems.
X is *really* slow to me until the desktop has finished loading. So slow I can't select a username from the login screen unless I wait for a while. This didn't happen in F11.
For my particular bug it's likely that people will use suspend/resume. This works well and doesn't trigger the bug. If a lot of people use suspend/resume they have a good workaround and there will be no bug reports.
Bug is here: https://bugzilla.redhat.com/show_bug.cgi?id=542097
I get another bug where X crashes if I unplug the USB keyboard, wait some time, then plug it in again: https://bugzilla.redhat.com/show_bug.cgi?id=538500
and another bug where X essentially hangs forever when I resume from a suspend (this is fixed now): https://bugzilla.redhat.com/show_bug.cgi?id=530854
Hi.
On 28.11.2009 12:29, nodata wrote:
X is *really* slow to me until the desktop has finished loading. So slow I can't select a username from the login screen unless I wait for a while. This didn't happen in F11.
Could that be the same as https://bugzilla.redhat.com/show_bug.cgi?id=541878 ?
Am 2009-11-28 13:55, schrieb Ralf Ertzinger:
Hi.
On 28.11.2009 12:29, nodata wrote:
X is *really* slow to me until the desktop has finished loading. So slow I can't select a username from the login screen unless I wait for a while. This didn't happen in F11.
Could that be the same as https://bugzilla.redhat.com/show_bug.cgi?id=541878 ?
Could be - thanks.
Will undupe if the fix for that bug doesn't effect me.
devel@lists.stg.fedoraproject.org
-
Adam Jackson -
Adam Williamson -
Alex Hudson -
Arjan van de Ven -
Ben Boeckel -
Bojan Smojver -
Bruno Wolff III -
David Airlie -
Debayan Banerjee -
drago01 -
Felix Miata -
Haïkel Guémar -
Ikem Krueger -
Jaroslav Reznik -
Jef Spaleta -
Jesse Keating -
Josh Boyer -
Jud Craft -
Kevin Kofler -
linux guy -
Mat Booth -
Mathieu Bridon -
Matthew Miller -
Michal Schmidt -
Neal Gompa -
nodata -
Pekka Savola -
Peter Jones -
Peter Robinson -
Rahul Sundaram -
Ralf Ertzinger -
Rudolf Kastl -
stefan riemens -
Terry Barnaby -
Tomasz Torcz