Hello, there is a newer kernel at https://download.opensuse.org/repositories/Kernel:/SLE15-SP3/standard/ This is the kernel under development that is expected to make it to Leap 15.3 eventually. Also if you know specifically what is missing to make the laptops work it would be a good idea to share the details. Unfortunately FATE is gone so there is no well-defined way to file feature requests for openSUSE. You can file bugs but unless you also happen to CC a relevant person they may just sit in bugzilla forever. Thanks Michal

On Thu, 03 Dec 2020 23:09:26 +0100, Vinzenz Vietzke wrote:

Hi all,

hopefully this is the right list for my question. Otherwise I'd appreciate a pointing in the right direction.

We (TUXEDO Computers) are selling laptops and PCs with openSUSE Leap preinstalled. One problem we run into quite often is the relatively old kernel version of Leap. E.g. for our lines of AMD Renoir laptops we would need at least 5.6.x upwards to get everything running.

In the past we "fixed" that by manually adding kernels from Kernel:stable which neither is a clean solution nor convenient for technically unexperienced users like many of our customers.

Ubuntu has their so called "Hardware Enablement" updates via point releases which delivers newer Kernels, Mesa etc. In addition to that they maintain an so called OEM Kernel, which currently is at 5.6.x. Both things are really helpful for our purposes.

So my question is: Is there something similar available for openSUSE? Maybe an intermedia kernel for Leap?

As Michal already applied, SLE15-SP3 / openSUSE Leap 15.3 kernel will cover those new hardware. But it'll be shipped months later, and the kernel ABI isn't frozen, so it's still a kind of moving target for now. That brings rather the question of your schedule. And, as Torsten suggested, integrating a proper OBS repo is the right thing for assuring the updates. So those replies from my colleagues are already some expected answers. But, OTOH, I know some outstanding (and long-standing) issues, and I guess you suffering from some of them, too: namely, 1. The Kernel:stable occasionally misses Nvidia and other KMP updates, especially at the kernel version jump from 5.x to 5.(x+1). 2. There are occasionally functional regressions at the kernel version jump. 3. It's not always trivial to get a KMP that is built for Kernel:stable. 4. Kernel:stable is no officially signed, and it can be a problem for secure boot. Basically 1 and 2 are about the upstream support and QA. The lag until KMP builds catch up may take a few weeks after the 5.x.0 is released, and the regression fixes may take a couple of stable kernel releases. (Sometimes longer, as we're seeing now for i915 graphics on 5.9.x kernels.) For addressing those, one idea would be to create a dedicated OBS project that offers the kernel for Tuxedo. It's a link from Kernel:stable but pinned to a certain revision. And you'll update the link only after confirming that everything works with the latest Kernel:stable. Also, for 3, you can create liked packages in this project to provide the KMPs for your kernel. That said, this OBS project will provide the snapshot of the package collections as the verified add-on for Tuxedo. The 4 is relevant only if the secure boot is in question. If so, the solution implies that you need either to allow the OBS project cert explicitly on Tuxedo image / deployment, or to do some re-signing work of the kernel package separately outside the OBS. Takashi

On 04.12.20 17:08, Torsten Duwe wrote:

On Thu, 3 Dec 2020 23:09:26 +0100 Vinzenz Vietzke wrote:

...

In the past we "fixed" that by manually adding kernels from Kernel:stable which neither is a clean solution nor convenient for technically unexperienced users like many of our customers.

(Besides the current kernels for SLE15 SP3 that Michal already mentioned)

What exactly do you consider unclean or inconvenient about that procedure?

If I'm adding the Kernel:stable repo to a customer's machine, i'm subjecting them to way tooo frequent kernel updates, and I do not know if they are getting things that break their machines (the famous "5.9 kills intel graphics" story for example, not that it had affected me with my relatively old Thinkpads :-) So if he is adding Kernel:stable, he is throwing away everything why you would want to install Leap and not Factory, at least for the kernel. (Not a problem for me, I run Kernel:HEAD on my Factory machines, just because Factory is much too slow :-P, but I would not want to do this on my wife's machine for example, much less for paying customers). Have fun, seife -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman

On Fri, Dec 04, 2020 at 04:08:51PM +0100, Michal Suchánek wrote:

Unfortunately FATE is gone so there is no well-defined way to file feature requests for openSUSE. You can file bugs but unless you also happen to CC a relevant person they may just sit in bugzilla forever.

For the record, there is a process for requesting features in Leap 15.3: https://en.opensuse.org/Portal:Jump/Policy/CommunitySLEChangeRequests Michal

On Mon, 14 Dec 2020 14:56:27 +0100, Vinzenz Vietzke wrote:

Hi,

Am 05.12.20 um 17:46 schrieb Michal Kubecek:

...

...

We (TUXEDO Computers) are selling laptops and PCs with openSUSE Leap preinstalled. One problem we run into quite often is the relatively old kernel version of Leap. E.g. for our lines of AMD Renoir laptops we would need at least 5.6.x upwards to get everything running. Are you sure neither 15.2 nor upcoming 15.3 kernel support your hardware? We have a lot of hardware enablement in these, both for CPU and GPU.

Yes, kinda. The machines boot and work but there are two major issues with AMD Renoir graphics:

1) Brightness control does not work. The Fn keys for brightness up/down trigger the video port feature from Plasma. Plus it gets triggered on it's own from time to time.

Devs told me it's related to this commit: https://github.com/torvalds/linux/commit/14ed1c908a7a623cc0cbf0203f8201d1b7d...

Hm, do you mean this revert patch may cause another regression, or should this patch fix the reported brightness issue? FWIW, the commit above is already in Leap 15.2 kernel.

2) On machines running kernel 5.6+ glxinfo shows AMDGPU as renderer while on Leap 15.2 stock kernel there's only OpenGL listed as renderer. This leads to a significant performance loss as the hardware capabilities don't get used.

First tests with Intel Tiger Lake (11th Gen) show the same symptoms. This in the end would mean we can't ship stock Leap 15.2 anymore. Which I would wan't to avoid if possible.

I'm afraid that you'll need quite lots of other package upgrades for supporting the new hardware on top of the stock Leap 15.2. e.g. the sound won't work on many recent machines and the upgrades of alsa-* packages are needed. I guess the same applied for the graphics. Takashi

On Tue, 15 Dec 2020 16:12:45 +0100, Vinzenz Vietzke wrote:

Am 14.12.20 um 15:06 schrieb Takashi Iwai:

...

...

2) On machines running kernel 5.6+ glxinfo shows AMDGPU as renderer while on Leap 15.2 stock kernel there's only OpenGL listed as renderer. This leads to a significant performance loss as the hardware capabilities don't get used.

First tests with Intel Tiger Lake (11th Gen) show the same symptoms. This in the end would mean we can't ship stock Leap 15.2 anymore. Which I would wan't to avoid if possible. I'm afraid that you'll need quite lots of other package upgrades for supporting the new hardware on top of the stock Leap 15.2. e.g. the sound won't work on many recent machines and the upgrades of alsa-* packages are needed. I guess the same applied for the graphics.

As Leap 15.3 alpha got available today I tried in on an Ryzen/Renoir and on a Tiger Lake based machine. Both worked fine ootb, which is really great!

So, are there any chances those things necessary will be backported to Leap 15.2 as well?

I don't think we'll backport those to Leap 15.2 as official updates. Leap 15.2 was already released, and it's simply new hardware that wasn't covered by Leap 15.2, which is no "bug" per se. But we definitely need some better support for the new hardware before the official Leap 15.3 release (which will be still far away). Might be worth to set up a repo to carry (or rebuild) a set of chosen packages from Leap 15.3 for 15.2? Then user don't need to update the full packages at each time, at least. Just my $0.02. Takashi