Skip to main content

Your submission was sent successfully! Close

Thank you for signing up for our newsletter!
In these regular emails you will find the latest updates from Canonical and upcoming events where you can meet our team.Close

Thank you for contacting us. A member of our team will be in touch shortly. Close

An error occurred while submitting your form. Please try again or file a bug report. Close

  1. Blog
  2. Article

Victor Tuson Palau
on 7 March 2012

Improving Hardware Support in Ubuntu


Anthony Wong, Project Technical Lead at Canonical, presented our process for improving hardware support in Ubuntu at our 2011 Hardware Summit.  He did such a good job that I asked him to distill the essence of his presentation into a blog post. This is what he had to say:

Ubuntu has always been dedicated to providing a great user experience to support a wide variety of hardware on the desktop, by installing the necessary drivers seamlessly during the system installation. Having said that, there are lots of things happening behind the scene to deliver this level of hardware support that is among the best in Linux distributions.

Canonical has been working closely with many Original Equipment Manufacturers (OEMs) for several years in shipping Ubuntu on laptops, desktops and servers. Lots of hardware issues have been found and fixed so that all the major hardware in the machines can be operated correctly.

One of the missions of the Canonical Hardware Enablement (HWE) Team is to track and drive code changes from OEM enablement projects into future Ubuntu releases and upstream. We have a concept of n+1 fixes which we do our best to make sure that those bugs are corrected in our next (that is, n+1) release.

The following two diagrams illustrate how HWE collaborate with upstream maintainers and our kernel team in order to have code fixes flow from OEM projects to Ubuntu distribution and upstream (click on the images to enlarge).

The first scenario depicts the case that a hardware bug is found in an OEM enablement project and no known fix has yet existed.There are generally two ways we can proceed from here, one is to have our engineers develop a fix and submit to upstream, the other one is to report the issue to upstream and work with them until a fix is done, which can then be merged into our kernel. In the former case, once our fix is acknowledged by the upstream maintainers and committed to their git tree, we can then merge it into our n+1 kernel and update the current release via the Stable Release Update (SRU) process.

It’s not unusual to find that issues found in OEM projects have already been resolved in the latest code branches. We will usually verify if they have already been fixed in mainline or the n+1 kernel, and if they have, we will identify the related patches and provide them to the OEM team, and also backport them as SRU’s to the current release. The diagram below shows two cases of such scenario.

We aim to certify any OEM project (e.g. based on 11.10) with the next release of standard Ubuntu (e.g 12.04). 

For more information on how we engage with OEM/ODMs please visit odm.ubuntu.com

 

Related posts


Giulia Lanzafame
4 September 2025

Implement an enterprise-ready data lakehouse architecture with Spark and Kyuubi 

Data Platform Article

Here at Canonical we are excited to announce that we have shipped the first release of our solution for enterprise-ready data lakehouses, built on the combination of Apache Spark and Apache Kyuubi. Using our Charmed Apache Kyuubi in integration with Spark, you can deliver a robust, production-level, and open source data lakehouse . Our Ap ...


Lidia Luna Puerta
3 September 2025

54% of European enterprises want long term open source support: how Ubuntu Pro + Support delivers

Ubuntu Article

Europe’s open source ecosystem is at a turning point. The Linux Foundation’s Open Source as Europe’s Strategic Advantage: Trends, Barriers, and Priorities for the European Open Source Community amid Regulatory and Geopolitical Shifts report shows organizations across the continent are broadly adopting open source software (OSS). But adopt ...


Bertrand Boisseau
3 September 2025

Using ISO/SAE 21434 to stay ahead of the Cyber Resilience Act

Automotive Article

How ISO/SAE 21434 helps you get ready for the Cyber Resilience Act If you work in automotive, you’ve probably already heard of the CRA – the EU’s Cyber Resilience Act. It’s one of the most ambitious pieces of cybersecurity regulation in years. And while it wasn’t written specifically for cars, it’s going to impact a ...