My hardware needs a module to be blacklisted to work, how can I get this fix shipped?

If you want it to go anywhere, don't just file a bug. Of course you should file a bug on Launchpad but that's really just the start of the process of something inherently upstream like this.

• Find out what it does

  Look at the code find out what it's supposed to do. If you don't need it, why is it there? Is something else doing its job now? If it's something that's still in demand, why isn't it working for you?

  You'll quite often see hardware-specific software written for edge cases like a single range of laptops (eg there are dozens of various Thinkpad hardware drivers).

  According to its readme, the driver covers wireless, LEDs, bluetooth, 3g and the backlight. To me, it sounds like something you (or others) might want so having it dumped or blacklisted by default might not be desirable.

• Find out how it got installed on your computer

  Where did it come from? Is it pulled into the kernel? Is it an Ubuntu pull? This will ultimately decide where you need to make your complaint.

  With kernel-level issues, it really helps to test the latest stable vanilla kernel. You can grab a copy from the mainline repository although you'll probably find there are GCC version mismatches with certain binary-only drivers (I have, with nvidia) so it's not something you'll want to run on all the time IMO.

  If the problem persists with a vanilla kernel, add a bug upstream and link it to the Launchpad bug and track it backwards too. A nice double-linked bug will help everybody stay on the same page.

  In this case, it sounds like it's an in-tree kernel driver (ie its source is pulled into the kernel repository and built in).

• Find the person or people responsible for it

  It's not reasonable to just to dump a bug on Launchpad and hope it finds the right person. I would say only a small portion of developers track their bugs through it so you need to find the maintainers of the software and get in touch.

  It might feel rude to start cold-emailing people but the software is their baby. If it's not working, I think they'd like to know. Nine times in ten, they'll help you identify the problem too.

  If it's still maintained, get debugging instructions. Check to make sure your hardware is compatible.

  If it's not maintained, and you can confirm that with the old maintainer, file a bug in the kernel alerting people that there's a portion of code rotting and that it's causing you issues.

• Suggest action to the right people

  When you know what the problem is, don't keep it to yourself. Make sure you take action on your bugs.

  If it's something that can be fixed in the driver, chase people in the kernel up to get the new version pulled into the development release. Ask about having it backported to 2.6.35 for existing Ubuntu users. Talk to the Kernel team about pulling in the changes to the Maverick kernel (though you might not have any luck there).

  If it's rotting, push the core kernel developers to dump it from their repo. Ask the Ubuntu kernel team developers to remove it from their repo. At the least, ask for it to be blacklisted (how some modules have been forcibly been removed by Ubuntu in the past).

  If you get good turnaround on fixing/destroying the driver, it should be possible to get its fix into the final Natty kernel (which is still at -next stage in the proper kernel repo).

The point I'm trying to get across is when you do your own triage and talk to the right people, things get so much more attention and have such a higher chance of a good end result.

And by no means stop if you see another person with the same problem. Subscribe to it, comment on their bug, ask what they've found, ask what they've done about it... And then carry on. Don't rely on them to get your problem solved.

This is how open source is supposed to work. Collaboration through good, open communication. Communicate your problem well, help where you can and you stand a good chance of getting better quality software.

This is a kernel bug¹, so you'd want to use ubuntu-bug linux in a Terminal. You'd then want to modify the created bug report to add that you need to blacklist acer-wmi as a workaround for the wireless chipset not working as suspected.

¹ Technically it isn't a kernel bug but probably a combination of broken hardware, BIOS, and kernel drivers. On the upside, it probably can be hacked around in the kernel, hence the loose use of "kernel bug."

Speaking as a member of the Ubuntu Kernel Team, specifically as the 'Kernel Bug Guy', I agree with Daniel's answer as it is the sum of what the Engineers see being the total issue. This is not to discount Oli's answer.

In the realm of the highly technical end user, Oli's answer is completely true in that it is a set of the steps we would expect a person of considerable technical acumen to use, however, our intent (and indeed the entire purpose of this site) is to guide the less technical.

Our main goal must be to provide them with quick and accurate answers that allow them to continue using the software that we build. My favorite saying is, "If it isn't simple 'they' won't do it." The 'they' here referring to whomever the user is at the time.

Having said that, and given my personal admiration for the completeness of your post Oli, I have to be honest and say that there are very few readers of this site that will read all of it. They will likely not read all of mine, and that is fine.

In the end, Daniel's response is exactly what we need here. It conveys both my and the Team's impression of these issues as well as our preferred method to address.