Appreciate the response. My main advice would be to try and be as upstream-focused as possible. Partnering with distros is great, but if your hardware is well

Appreciate the response. My main advice would be to try and be as upstream-focused as possible. Partnering with distros is great, but if your hardware is well supported upstream, you cover everything anyone would ever want to use. If there's fixes that need to go into older distro kernel it's typically trivial to get them backported if they're already upstream. Making Ubuntu work fixes Ubuntu, making upstream work fixes everything - and you're gonna have a lot of users that like living on the edge with distros that follow upstream closely like Arch and Fedora anyway. Critically, the bulk of the resources on the distro side that would test your hardware as part of their regular testing are quite distant from upstream (Ubuntu is the closest, Fedora is largely community driven, RHEL and SLES aren't appealing desktop distros for most users), so having some upstream testing in-house would probably help a lot in getting ahead of problems. Maybe you could try and get boards into kernelci.org? They're mostly focused on ARM SoCs but they have x86 boards in there too, though I don't think there's much on the desktop side. The i915 driver which has caused me much pain and suffering over the last couple of weeks has some test automation that could be run too: https://intel-gfx-ci.01.org/ https://intel-gfx-ci.01.org/ I'm sure there has to be more upstream automated testing initiatives for laptops but I'm not super familiar with that space. Oh and if anyone's interested I gave a talk back in 2020 about how Linux kernel testing is fundamentally boned here: https://www.youtube.com/watch?v=9Fzd6MapG3Y https://www.youtube.com/watch?v=9Fzd6MapG3Y Good luck!