PackageKit and firmware

For a few months now, PackageKit has been able to install firmware for devices. Sometime in 0.5.x series the functionality broke, so I spent the morning fixing up the module properly.

So, when you start your session (or insert the device), you get greeted by:

Firmware request
Firmware request

Notice, we now display the device model, but in this case where a device is waiting for firmware, normally the results are not complete and thus not pretty. USB WLAN is the best we can do in this case. If the user clicks install, the install continues in the background, and then the user gets a few minutes later:

Replug please!
Replug please!

but if it’s not a removable device:

Restart please!
Restart please!

Of course, you’ll need a pretty new distribution to have GUdev installed, but if you don’t it’ll fall back to being unhelpful.

Published by


Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management. Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food.

24 thoughts on “PackageKit and firmware”

  1. That reminds windows! Wouldn’t it be possible to reload the module instead of rebooting?

  2. Yes, we can unbind and rebind the driver through sysfs, which should trigger a firmware reload. Unfortunately there’s nothing in the stack that can do this for us, so we would need to add a mechanism helper to allow this. The design would be pretty much like the cups-policykit-helper, calling into a helper running as root to do an action requested by the session.

    I’ve got way too many things on my TODO before I could get around to this, but it might be a cool project for someone to hack on.

  3. Actually not even rebinding is needed on many wlan, firmware request is often done on ifconfig up

  4. Hugsie, please don’t go forward with that UI. What extra value does it provide to force user endure popups, and click them through? If he ie. plugs in hardware device he probably WANTS it to just work. Just work, without anything else.

    Also, rebooting is seriously not something that is required, ever, for any reason.

    That fact that Microsoft thought once it would be nice to spam the user constantly doesn’t make it alright for others to do. It is still plain wrong. Let the user focus on HIS tasks instead of having to babysit a computer!

  5. @mehmoomoo:

    We certainly shouldn’t just install firmware without asking. I do agree we can get rid of the reboot stage in most cases, and I’m working on that now. It’ll still have to fallback to spamming the user if pkexec is not available, or if the rebind fails.

  6. A thought that occured to me seeing these screenshots is if the average user knows what “firmware” means and why he might need it. Is there an easy way for the user to find out why his computer is asking him to do this? Either a link to a help page explaining the term “firmware”, or some explanation would be sufficient I think:

    Additional firmware required

    Some additional software needs to be installed to make the following device work correctly:

    – USB WLAN

  7. Why not install them automatically? I do not even understand why on earth a firmware package would not be installed BY DEFAULT on any system. What benefit does it have to go with the complexity of installing them on demand?

      1. Could you make free firmware just work, though, and go straight to the second/third (screenshot) notification for those?

  8. Along the same lines:

    “Additional firmware was installed” => “Installed additional firmware”

    “You will need to … before it/the hardware will work correctly” => “To enable the hardware please …”

  9. Please make this only for non-free firmware and please make sure that the user is notified that the firmware is evil, nasty, non-free, unsupported, binary blob stuff. Oh, and that last bit should be per-distro since some of them don’t care about freeness issues.

    1. The firmware request comes from the kernel, and we access the data using udev. We’re working on a way to get the vendor name in the title properly.

      1. Then it has crossed the line to fantastic software. Perhaps you already knew :-)

        The big difference is whether an app is nagging and trying to help (Telling me “this device doesn’t work” each boot or somesuch), or simply only pipes up when it really helps.

  10. Why use notifications for the UI? If you actually want me to interact with the UI wouldn’t it be much better to open a proper window?

    Also, what is the consequence of pressing the “don’t show this again” button? Will it prevent me from ever getting firmware installed on my computer?

    1. commit c94ca1806ee277871d2fd49866bac7240f8d93ad
      Author: Richard Hughes
      Date: Mon Aug 24 10:29:25 2009 +0100

      Change the firmware ‘Do not show again’ to a ‘Ignore devices’ button, and add vid_pid GConf mechanism

      So if you click ignore device, it will ignore this product-vendor id match only, and not the whole firmware installing functionality. Good catch, thanks.

  11. I propose to install the firmware automatically (without any message) and remove it automatically if it isn’t used for a month.

Comments are closed.