Change:
Describe the bug To enable hardware video decoding in Firefox the system call needs to be available, because mesa depends on it. This was observed on an AMD Renoir Thinkpad. To make this work, the config option needs to be enabled in Linux. To Reproduce Steps to reproduce the behavior: a system with AMD GPU with , follow the to enable the right flags for VA-API for Firefox firefox with debug logs: that VA-API fails to be enabled by finding in the log when you try to play a youtube video Expected behavior VA-API works and video decoding is hardware accelerated. Additional context The issue is linked to Mesa not being able to use the system call. This in turn leads to VA-API not being initialzed. See the big at the beginning of The system call is exposed by the Linux kernel when the config option is enabled. On NixOS it defaults to off. On a Fedora box, it defaults to on. usage seems to have been introduced in mesa in 2020 with this commit: Notify maintainers Firefox: Mesa: Linux kernel: ?? Metadata Please run and paste the result. Maintainer information:
Sounds good to me, thanks for the detailed analysis! We currently set only for CRIU (, cc but setting as well shouldn't be required anymore. And on Debian Buster is also set by default: From : So in we should be able to replace: with just and an explanation that this is required for CRIU and Mesa.
Sounds OK at a quick look, but it would be nice to test it fixes the acceleration before merging that. (even though it seems more about mesa using the syscall than about firefox) EDIT: we may need to be careful about different kernel versions, perhaps enabling just since some version.
Good call. I retested everything with the same settings with and without and the only difference at the moment is that without it Mesa complains when starting Firefox: But VA-API works in both cases despite the ominous warning. I could have sworn_ it didn't until I changed the kernel settings. :confused: So we might want to enable anyway to not subtly break Mesa, but for my issue it turned out to be a red herring...
What do you think. Should we enable kcmp anyway now that mesa seems to depend on it? It seems like the right thing to do.
Coincidentally, upstream seems to be changing to be available without . See (only freely available on February 25) or just look at the patchset: This isn't to say that we shouldn't enable , just that it might not be necessary in the long run.
I expect it's worth getting by default. I believe we'll be defaulting to 5.4 or 5.10 kernels for quite some time (about a year at least) and those branches surely won't change in this respect anymore. (I assume they need for but I haven't verified that.)
We could just backport the patch ourselves, but since we don't really do that kind of thing AFAIK, we can just enable and maybe think about disabling it again, when an upstream stable kernel doesn't need it for anymore. Do we have any defined processes on how do decide on kernel config or is it as ad-hoc as everything else?
I believe there's no process for that specifically. (so PR, maintainers, consensus, merge)
So was removed from with this commit, which landed in Linux 4.19:
I gave this a shot in .

Discussion:
XZ_DEC_TEST              = option no; }; <del> criu = optionalAttrs (features.criu or false) ({ </del> <ins> criu = if (versionAtLeast version "4.19") then { # Unconditionally enabled, because it is required for CRIU and # it provides the kcmp() system call that Mesa depends on. CHECKPOINT_RESTORE  = yes; } else optionalAttrs (features.criu or false) ({ # For older kernels, CHECKPOINT_RESTORE is hidden behind EXPERT. </ins> EXPERT              = yes; CHECKPOINT_RESTORE  = yes; } // optionalAttrs (features.criu_revert_expert or true) {