SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Firefox 105.0.1 error messages after Sep 28th upgrade - Slack64-Current
After today's upgrades (Slackware64-current), Firefox 105.0.1 refused to start. I killed the process that remained running in background, lauched FF again from a console and it started but with error messages (FF is running now, but with these errors in the console). I have an AMD GPU card running stock drivers (see inxi -G output below). Things were running nicely yesterday. Kernel 5.19.12, display server X.org.
I'm not running current, but you might want to try switching to the amdgpu driver. I have a Tahiti card as well and if my memory serves me, I used to see those errors with firefox before I switched drivers. The amdgpu driver has better support for hw acceleration.
There's a couple other ways to enable it, but this the method I used.
Code:
# cat /etc/modprobe.d/amdgpu.conf
options amdgpu si_support=1
options amdgpu cik_support=1
# cat /etc/modprobe.d/radeon.conf
options radeon si_support=0
options radeon cik_support=0
#also added the following and rebuilt initrd.gz
echo "MODCONF=\"1\"" >> /etc/mkinitrd.conf
Regarding the first VAAPI error, you probably got bitten by the last mesa update. Starting from 22.2, mesa does not build by default video decode codecs for h264/h265, thus leaving amd gpus without VAAPI support.
Regarding the first VAAPI error, you probably got bitten by the last mesa update. Starting from 22.2, mesa does not build by default video decode codecs for h264/h265, thus leaving amd gpus without VAAPI support.
Yep
Code:
Support for building Mesa with select video codecs disabled out of software patent concerns.
You mean remove? It's not adding anything TBH
And maybe if it goes down that route, then vdpau also should be moved to SBo or something?
Nope
Others also do it like that (at least Arch & Gentoo)
Code:
option(
'video-codecs',
type : 'array',
value : [],
choices: [
'vc1dec', 'h264dec', 'h264enc', 'h265dec', 'h265enc'
],
description : 'List of patent encumbered codecs to build support for. Distros might want to consult their legal
department before enabling these. This is used for all video APIs (vaapi, vdpau, vulkan). Non-patent encumbered
codecs will be enabled by default.'
but maybe there will be a veto from Pat's legal department ;-)
Nope? Can't you be more specific? You mean nope; you're not removing by compiling without, or nope; the vdpau should stay in broken state?
That part of mesa should really go to SBo, but with SBo policy of not replacing distro packages, how?
Nope? Can't you be more specific? You mean nope; you're not removing by compiling without, or nope; the vdpau should stay in broken state?
That part of mesa should really go to SBo, but with SBo policy of not replacing distro packages, how?
I'm not removing
The -D means :
Code:
Universal options
All these can be set by passing -Doption=value to meson (aka meson setup)
OK, I'm not removing it either, we may legally keep this enabled because we're in EU.
Still not clear if we're going to have to recompile all of mesa in the future, to get this.
From my understandings this mostly affects GPU-accellerated video decode/encode (VAAPI) on AMD hardware using mesa's va driver.
Intel already needed an external driver for this (https://github.com/intel/media-driver/), while nouveau is probably out of luck anyway on recent cards.
About 5 months ago a change was introduced in mesa to require an explicit list of enabled video codecs at configure time: https://gitlab.freedesktop.org/mesa/...9bf33337bc2c96
The default list of enabled codecs is empty, but all of them are explicitly enabled in mesa's automatic CI build script, and they are still enabled as of today.
And if i understand correcly, slackware won't enable them because it's US based, while debian/arch/gentoo can get away because they are community managed right?
Guess we will have to compile our own mesa package, luckily it's very easy on slack but still an annoyance.
Yesterday everything was working, I updated to current just now and Firefox is broken (also Librewolf). There's no error messages, it just hangs. I'm posting this from SeaMonkey.
Good news: rebuilding Mesa with the patch fixes things. Bad news: Firefox wanted to "refresh" for some reason, which I foolishly allowed, losing all my bookmarks and configuration.
I turned off Firefox hardware acceleration but still kept radeon driver (I will try to change the radeon driver to amdgpu driver later, as suggested by fourtysixandtwo). This way, the RENDERER DEVICE error went off, but the VA-API / mesa error kept showing up.
Good news: rebuilding Mesa with the patch fixes things. Bad news: Firefox wanted to "refresh" for some reason, which I foolishly allowed, losing all my bookmarks and configuration.
No old profiles in ~/.mozilla/firefox to copy Places.sqlite into the new profile?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.