Yeah, I think he has the password to change who incoming bugs get routed to. I'll start bugging him to fix some of those bugs; that should get the routing table updated
Originally Posted by monraaf
BTW are you saying that we don't *fix* reported bugs (which I would disagree with strongly) or that we don't update the workflow state of bugs when we fix them and leave that to the original reporter ? Those are two very different things.
I gave up ati proprietary drivers... the out-of-the-box experience on ubuntu 10.04 is great with my X350 and unless you need higher performances for some 3d stuff, there is absolutely no need to change your driver. I just can't wait to have VDPAU implemented... (Assuming it will be documented one day )
I'm saying that IMO ATI/AMD doesn't take the whole bug reporting process for their proprietary Linux driver very serious, and as a result people might not feel inclined to report bugs.
A bug tracker that has been down for days, bug reports being forwarded to someone who is no longer employed by ATI/AMD, no feedback on most bug reports, come on. Also what is the reason for the bug tracker to be not affiliated with AMD in any way? It is a bug tracker for AMD's proprietary driver after all. I find this rather insulting.
I'm sure you have a different bug reporting process for your valued customers, and bugs probably do get fixed as a result of that. But I don't get the feeling that for the 'ordinary' Linux user filing bugs is worth the effort.
I don't know if you're using 10.1 in its current state (no official support), but I'm using 10.1 on my HD 5650 mobility without any problem -- had to configure xorg.conf manually, but otherwise it's working great - games, suspend/resume, compiz.
Originally Posted by raulromania
I switched over to win7 until everything get more efficient. I mean, there are a many thnigs which are under development to ensure a nice workflow.
It will take a while to fully support all of the hardware its in my ACER 7740G (http://geizhals.at/eu/a497111.html) Hopefully lucid will do most of it.
It is not the problem to the configure xorg.conf manually. The package scripts for karmic are broken for 10.1. So I gave up. Its not my cup of tea to give up so fast, but i dont want to waste so much time with configuring my system. You are using arch, right? Probably i will try it these days.
I do not have dualboot. My Linux is completly removed - but hopefully not a long time. One important question kronius.
What Hard disk drive is/was installed in your Notebook.
In my Acer Aspire 7740G-434G64Mn (LX.PNX02.021) is a Western Digital Scorpio Blue 640GB, SATA II (WD6400BEVT) installed.
The Power Management of the HD is very aggressive (60h).
If you dont use a tool or hdparm and if the drive has nothing to do (idle), it parks the head a few times per minute. The Load Cycle Count (a S.M.A.R.T. value) of your HD will rise very fast and your HD can be f***** up in only one year or faster. Additionally it can be very annoying if you are in a room where it is dead silence.
If you have a WD HD, check your S.M.A.R.T. values.
I use CrystalDiskInfo under Win7.
You can change AAM and APM values with it and make it start with your OS. I've shut down APM completly (FEh).
If YOU (reader) are using a Linux/Unix OS check THIS.
Thanks for the info! Arch has a so called storage-fixup created for that purpose. For now i have added a script that turns APM off as my HDD isnt included in the default config file of this thing, I will try to extend the arch based package's config file.
Originally Posted by raulromania
"However, with Ubuntu now looking for people to test out the proprietary ATI driver and emailing Pulido for instructions, it looks like they're getting ready to roll out an unreleased Catalyst driver for Linux."
No, this is the wrong conclusion to draw. We do not have updated ATI Catalyst drivers yet. The actual reason we're doing this testing is not so much for finding issues in the proprietary drivers themselves (they're pretty well tested before they get to us, and if we found bugs we couldn't fix them), but rather to detect regressions caused by changes elsewhere in the system, which only show up for users of proprietary drivers.
For instance, last release we upgraded the proprietary drivers and at the time everything worked fine. Later on, towards the end of the development cycle, upstart and gdm2 were introduced, along with several boot speed improvements. In certain circumstances, these changes caused breakage for proprietary driver users. (For instance, the boot speed improvements that went in late in the cycle could cause X to attempt booting before dkms had finished building the kernel driver. We don't need dkms for the open source drivers, so the issues didn't affect them.)
So, this effort is just geared to set up a weekly testing regimen throughout the development cycle, that will hopefully highlight regressions caused by changes in the underlying system at the point where those changes are made (we get plenty of random bug reports but these lack the indication of *when* the change went in causing the regression.) The purpose of this is to give us more power to solve these issues well before release, so we can ensure a smooth experience for proprietary driver users.
Tags for this Thread