8:01 a.m.
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.
8:12 a.m.
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.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect
Cyberinfrastructure Labs / Instructional & Research Computing
Computing & Information Technology
Harvard School of Engineering & Applied Sciences
8:24 a.m.
New subject: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
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 ...
8:27 a.m.
New subject: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing 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
9:41 a.m.
There is an interesting thread on the developers list entitled "Fedora
12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?"
LG
9:37 p.m.
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
8:14 a.m.
2009/11/26 Terry Barnaby <terry1(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
8:39 a.m.
On 11/26/2009 02:14 PM, Rudolf Kastl wrote:
2009/11/26 Terry Barnaby<terry1(a)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(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
8:43 a.m.
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
9:04 a.m.
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.
9:11 a.m.
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(a)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(a)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(a)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.
--
Tomasz Torcz There exists no separation between gods and men:
xmpp: zdzichubg(a)chrome.pl one blends softly casual into the other.
10:08 a.m.
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 Ebbert<cebbert(a)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(a)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(a)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
10:34 a.m.
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
11:09 a.m.
New subject: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
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 :)
1:46 p.m.
On Thu, Nov 26, 2009 at 17:09:14 +0000,
Terry Barnaby <terry1(a)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.
2:16 p.m.
New subject: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
On 11/26/2009 07:46 PM, Bruno Wolff III wrote:
On Thu, Nov 26, 2009 at 17:09:14 +0000,
Terry Barnaby<terry1(a)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.
2:30 p.m.
On Thu, Nov 26, 2009 at 20:16:54 +0000,
Terry Barnaby <terry1(a)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.
3:23 p.m.
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 Barnaby<terry1(a)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.
4:14 p.m.
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 Barnaby<terry1(a)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.
3:02 a.m.
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 Barnaby<terry1(a)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.
--
Jaroslav Řezník <jreznik(a)redhat.com>
Associate Software Engineer - Base Operating Systems Brno
Office: +420 532 294 275
Mobile: +420 731 455 332
Red Hat, Inc. http://cz.redhat.com/
2:29 p.m.
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 Barnaby<terry1(a)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.
3:35 a.m.
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 Barnaby<terry1(a)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 ?
1:33 p.m.
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
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
2:04 p.m.
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.
2:12 p.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
1:31 a.m.
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
2:36 a.m.
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
3:23 p.m.
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 ?
2:06 p.m.
> 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.
4:26 p.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
3:23 a.m.
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.
4:43 p.m.
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 :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
2:03 p.m.
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. :)
*https://fedoraproject.org/wiki/How_to_debug_Xorg_problems
12:05 a.m.
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.
:)
*https://fedoraproject.org/wiki/How_to_debug_Xorg_problems
Get a Fedora account and create a new page under your username and show
it to the QA team get some consensus.
Rahul
4:44 p.m.
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.
:)
*https://fedoraproject.org/wiki/How_to_debug_Xorg_problems
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
2:21 p.m.
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(a)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
6:49 p.m.
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
7:43 p.m.
On 11/26/09, Terry Barnaby <terry1(a)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
9:08 a.m.
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
9:12 a.m.
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:
1) Cronometer crashes KDE session.
https://bugzilla.redhat.com/show_bug.cgi?id=504173
Filed against wrong component. How is Fedora marketing related to a KDE
issue? Please reassign.
2) Display not operating properly
https://bugzilla.redhat.com/show_bug.cgi?id=528188
Waiting on information from you.
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
Likewise.
4) KDE session display gets messed up on Gateway LT3108u
https://bugzilla.redhat.com/show_bug.cgi?id=525767
Likewise.
Rahul
12:07 a.m.
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.)
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
12:08 a.m.
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.
1:18 a.m.
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.
2:52 a.m.
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.
2:08 p.m.
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
5:17 a.m.
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.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
5:27 a.m.
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)
2:38 p.m.
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
1:59 a.m.
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
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
11:01 a.m.
New subject: Ubuntu Xorg Guru calls for help. Was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
12:01 p.m.
New subject: Ubuntu Xorg Guru calls for help. Was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
Linuxguy123 wrote:
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
1:09 p.m.
New subject: Ubuntu Xorg Guru calls for help. Was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
On Mon, 2009-11-30 at 10:01 -0700, Linuxguy123 wrote:
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
1:16 p.m.
New subject: Ubuntu Xorg Guru calls for help. Was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
Le 30/11/2009 18:01, Linuxguy123 a écrit :
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.
1:28 p.m.
New subject: Ubuntu Xorg Guru calls for help. Was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
On Mon, Nov 30, 2009 at 10:16 AM, Haïkel Guémar <karlthered(a)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
2:23 p.m.
New subject: Ubuntu Xorg Guru calls for help. Was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
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
4:47 p.m.
New subject: Ubuntu Xorg Guru calls for help. Was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
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(a)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'.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
5:01 a.m.
New subject: Ubuntu Xorg Guru calls for help. Was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
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?
10:16 a.m.
New subject: Ubuntu Xorg Guru calls for help. Was Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
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
9:04 a.m.
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.
--
The husband should fulfill his marital duty to
his wife, and likewise the wife to her husband.
1 Corinthians 7:3 NIV
Team OS/2 ** Reg. Linux User #211409
Felix Miata *** http://fm.no-ip.com/
4:12 p.m.
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.
3:24 a.m.
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.
3:28 a.m.
On Thu, Nov 26, 2009 at 11:12 PM, Dave Airlie <airlied(a)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.....
4:52 a.m.
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 husband should fulfill his marital duty to
his wife, and likewise the wife to her husband.
1 Corinthians 7:3 NIV
Team OS/2 ** Reg. Linux User #211409
Felix Miata *** http://fm.no-ip.com/
2:21 p.m.
On Fri, Nov 27, 2009 at 11:52 AM, Felix Miata <mrmazda(a)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".
2:24 p.m.
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(a)gmail.com>:
On Fri, Nov 27, 2009 at 11:52 AM, Felix Miata
<mrmazda(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
2:34 p.m.
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').
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
12:17 a.m.
On 11/27/09, Adam Williamson <awilliam(a)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
2:43 p.m.
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.
2:41 p.m.
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
2:51 p.m.
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.
2:51 p.m.
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.
--
The husband should fulfill his marital duty to
his wife, and likewise the wife to her husband.
1 Corinthians 7:3 NIV
Team OS/2 ** Reg. Linux User #211409
Felix Miata *** http://fm.no-ip.com/
2:53 p.m.
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
3:19 p.m.
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.
--
The husband should fulfill his marital duty to
his wife, and likewise the wife to her husband.
1 Corinthians 7:3 NIV
Team OS/2 ** Reg. Linux User #211409
Felix Miata *** http://fm.no-ip.com/
3:37 p.m.
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
3:56 p.m.
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.
--
The husband should fulfill his marital duty to
his wife, and likewise the wife to her husband.
1 Corinthians 7:3 NIV
Team OS/2 ** Reg. Linux User #211409
Felix Miata *** http://fm.no-ip.com/
4:01 p.m.
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
4:29 p.m.
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.
--
The husband should fulfill his marital duty to
his wife, and likewise the wife to her husband.
1 Corinthians 7:3 NIV
Team OS/2 ** Reg. Linux User #211409
Felix Miata *** http://fm.no-ip.com/
5:32 p.m.
On Fri, Nov 27, 2009 at 11:29 PM, Felix Miata <mrmazda(a)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).
5:37 p.m.
On Sat, 28 Nov 2009 00:32:04 +0100
drago01 <drago01(a)gmail.com> wrote:
On Fri, Nov 27, 2009 at 11:29 PM, Felix Miata
<mrmazda(a)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.
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
5:02 p.m.
On Fri, Nov 27, 2009 at 4:01 PM, Rahul Sundaram
<sundaram(a)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.
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.
8:35 p.m.
On Fri, 2009-11-27 at 17:02 -0600, Sir Gallantmon wrote:
On Fri, Nov 27, 2009 at 4:01 PM, Rahul Sundaram
<sundaram(a)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.
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.
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.
4:11 p.m.
2009/11/28 Felix Miata <mrmazda(a)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)!
--
Regards,
Debayan Banerjee
11:05 a.m.
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
--
Peter
I'd like to start a religion. That's where the money is.
-- L. Ron Hubbard to Lloyd Eshbach, in 1949;
quoted by Eshbach in _Over My Shoulder_.
11:24 a.m.
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.
9:07 a.m.
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
5:02 p.m.
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)
10:49 p.m.
On Fri, Dec 4, 2009 at 9:02 PM, Kevin Kofler <kevin.kofler(a)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.
11:31 a.m.
2009/12/5 Sir Gallantmon <ngompa13(a)gmail.com>:
On Fri, Dec 4, 2009 at 9:02 PM, Kevin Kofler
<kevin.kofler(a)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.
--
Mat Booth
8:32 p.m.
On Sat, Dec 5, 2009 at 12:31 PM, Mat Booth <fedora(a)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.
1:42 p.m.
On Fri, Nov 27, 2009 at 08:12:05 +1000,
Dave Airlie <airlied(a)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.
2:33 p.m.
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(a)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.
9:46 p.m.
New subject: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
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
12:24 p.m.
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.
12:26 p.m.
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.
8:59 a.m.
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.
1:28 p.m.
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
11:01 a.m.
On Nov 26, 2009, at 6:01, Terry Barnaby <terry1(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
11:05 a.m.
On Nov 26, 2009, at 6:01, Terry Barnaby <terry1(a)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
11:27 a.m.
On 11/26/2009 05:05 PM, Jesse Keating wrote:
On Nov 26, 2009, at 6:01, Terry Barnaby <terry1(a)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 ??
1:12 p.m.
On Nov 26, 2009, at 9:27, Terry Barnaby <terry1(a)beam.ltd.uk> wrote:
--
Jes
On 11/26/2009 05:05 PM, Jesse Keating wrote:
> On Nov 26, 2009, at 6:01, Terry
Barnaby <terry1(a)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.
9:53 p.m.
New subject: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12?
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
5:29 a.m.
New subject: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12?
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
6:55 a.m.
New subject: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12?
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
?
7:43 a.m.
New subject: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12?
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.
5253
days inactive
5264
days old
107 comments
35 participants
participants (35)
-
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