[Stable Update] 2022-12-06 - Kernels, Mesa, Plasma, Cinnamon, Nvidia, LibreOffice, Pipewire, Virtualbox

Tried solution suggested by @marlop, but did not work for me ecen though compile and install worked.

So downgraded mesa with the list @Yochanan suggested above. That didn’t work either.

So downgraded mesa with the list @oneno suggested above with lib32 packages and worked!

$ vainfo
Trying display: wayland
Trying display: x11
vainfo: VA-API version: 1.16 (libva 2.16.0)
vainfo: Driver version: Mesa Gallium driver 22.2.3 for AMD CAICOS (DRM 2.50.0 / 5.15.81-1-MANJARO, LLVM 14.0.6)
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileVC1Simple              :	VAEntrypointVLD
      VAProfileVC1Main                :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileNone                   :	VAEntrypointVideoProc
Same on second machine...
$ vainfo
Trying display: wayland
Trying display: x11
vainfo: VA-API version: 1.16 (libva 2.16.0)
vainfo: Driver version: Mesa Gallium driver 22.2.4 for AMD ARUBA (DRM 2.50.0 / 5.15.81-1-MANJARO, LLVM 14.0.6)
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileNone                   :	VAEntrypointVideoProc

After downgrade:

$ vainfo
Trying display: wayland
Trying display: x11
vainfo: VA-API version: 1.16 (libva 2.16.0)
vainfo: Driver version: Mesa Gallium driver 22.2.3 for AMD ARUBA (DRM 2.50.0 / 5.15.81-1-MANJARO, LLVM 14.0.6)
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileVC1Simple              :	VAEntrypointVLD
      VAProfileVC1Main                :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointEncSlice
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointEncSlice
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointEncSlice
      VAProfileNone                   :	VAEntrypointVideoProc
$

2 posts were split to a new topic: Konsolerc already exists in filesystem

so yeah there has to be linux 6.0. But since I am not quite aware of things like [EOL] and rt54 and r14, I thought of asking here. I know my question was stupid but I would be grateful if I was educated on these things.

My original being : is stable update receiving 6.0 kernel or is it still in version 5 ?

rt means “Experimental” (the actual word I don’t right now, but that’s what it boils down to; rc is “Release Candidate”, EOL is “End of Life”, thus about to lose support. Unless you know exactly what you’re doing, stay away from kernels with letters in their version numbers -they’re for testing, and may well give you a headache.

rt is Real Time

1 Like

As long as you don’t have the hardware that module’s needed for, you don’t need to worry.
I deleted some modules for hardware I don’t have and I get warnings like this for them.
On the other hand, if you do have that hardware, you need to find the module in the package manager and install it.

Maybe it’s shown because of the kms hook?
I have merged the mkinitcpio.conf
—> [SOLVED] Latest mkinitcpio giving errors... / Pacman & Package Upgrade Issues / Arch Linux Forums

I will ignore it

Try adding ibt=off to kernel parameters. It helped for me (Intel 9th gen)

@pheiduck If you’re running qemu on Intel hardware, that’s worth trying I guess.

firefox still doesn’t work (sometimes)…

This is worrying news, to say the least…

@direc85 thanks I am a AMD :heart: User :relieved:
And my issue is solved:

1 Like

This seems to be a fairly widespread issue, and does seem to be on the KDE side of things. I’m going to keep an eye on this bug report, but figured I would share this for you or anyone else with this issue who is looking for more info.

https://bugs.kde.org/show_bug.cgi?id=462512

Can also confirm i’m seeing this. Restart pulse audio works until the next crash. Last noticed it after leaving and rejoining a Zoom meeting.

ERROR:pulse_util.cc(350)] pa_operation is nullptr

ThinkPad X1 Carbon 7th, 5.15.81-1-MANJARO
driver=sof-audio-pci-intel-cnl

manjaro is trying to associate thier operating system with retailers of machines, this may be why they are being so cautious, apart from that i dont know

1 Like

I’m still downloading the update (1.7GB) and it’s taking uncharacteristically long (almost 4 hours in total). The update is slow but uninterrupted, which leads me to suspect that something somewhere is rate limiting it. Do you know if any Manjaro mirrors do that?

I updated a laptop today, that also had 1.7 GB of updates, but it was done fairly quickly.

You sure you are not building an AUR package, like Python2 or Ceph-libs?

No it’s definitely the download based on the log. It finished after almost 5 hours. I’ll changed to another mirror in case this one is overloaded. I was also suprised because I had updates of similar size and none of them took this long.

CPU usage of playing videos in the browsers has always been way too high compared to a dedicated video player - even when backed by GPU decoding. Especially Firefox with its multiple processes involved (looking at you Isolated Web Content).

But it’s not a Linux problem. Chrome on Windows sucks at it as well.

Also YouTube uses VP9 per default (see Stats for nerds in the YouTube context menus) which is royalty-free and doesn’t appear to use H264/H265.

I have not experienced a difference in smoothness and I still see the GPU being utilized when playing videos.

This update seems to have seriously messed up multi-monitor support with my laptop. None of the modes which utilize multiple screen at the same time are working correctly anymore. Before the update everything was working as expected.

If you “unify” it will now use separate resolutions for each screen leading to the bigger one only showing a part of the slower screen since the resolution chosen is lower than the one on the smaller one. Or it has a much bigger resolution and it will show the other screen as a smaller part. They now have different resolutions which was never the case before and you need to try to mess around until you find something that works. Before it would select a resolution both screen can work with.

If you use “extend” the “left” and “right” doesn’t seem to be honored anymore.

Also most of the time when you “extend” you won’t be able to access the external desktop with the mouse anymore.

Also the primary display selection appears to be messed up since the display selection dialog now appears on the external display although the built-in one is the primary. So you cannot switch the modes anymore.

Also kscreen_osd_service is crashing even more often now.

Here’s the backtrace:

#0  0x00007fb3cfd426ff in QWindow::setVisible (this=<optimized out>, visible=false)
    at kernel/qwindow.cpp:630
#1  0x00007fb3cf8bda51 in QtPrivate::QSlotObjectBase::call (a=<optimized out>, r=<optimized out>, 
    this=<optimized out>, this=<optimized out>, r=<optimized out>, a=<optimized out>)
    at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398
#2  doActivate<false> (sender=0x5613f5a58200, signal_index=0, argv=0x7ffdba3d4db0)
    at kernel/qobject.cpp:3919
#3  0x00007fb3cf8bddf4 in QObject::destroyed (this=<optimized out>, _t1=<optimized out>)
    at .moc/moc_qobject.cpp:219
#4  0x00007fb3cf8b43ac in QObject::~QObject (this=<optimized out>, this=<optimized out>)
    at kernel/qobject.cpp:1010
#5  0x00007fb3d11d7c2a in KScreen::Output::~Output (this=<optimized out>, this=<optimized out>)
    at /usr/src/debug/libkscreen/libkscreen-5.26.4/src/output.cpp:176
#6  QtSharedPointer::CustomDeleter<KScreen::Output, QtSharedPointer::NormalDeleter>::execute (
    this=<optimized out>) at /usr/include/qt/QtCore/qsharedpointer_impl.h:187
#7  QtSharedPointer::ExternalRefCountWithCustomDeleter<KScreen::Output, QtSharedPointer::NormalDeleter>::deleter (self=<optimized out>) at /usr/include/qt/QtCore/qsharedpointer_impl.h:205
#8  0x00005613f411a956 in QtSharedPointer::ExternalRefCountData::destroy (this=0x5613f5a5b310)
    at /usr/include/qt/QtCore/qsharedpointer_impl.h:149
#9  QSharedPointer<KScreen::Config>::deref (dd=0x5613f5a5b310)
    at /usr/include/qt/QtCore/qsharedpointer_impl.h:458
#10 QSharedPointer<KScreen::Output>::deref (dd=<optimized out>, dd=<optimized out>)
    at /usr/include/qt/QtCore/qsharedpointer_impl.h:454
#11 QSharedPointer<KScreen::Output>::deref (this=<optimized out>, this=<optimized out>)
    at /usr/include/qt/QtCore/qsharedpointer_impl.h:453
#12 QSharedPointer<KScreen::Output>::~QSharedPointer (this=<optimized out>, this=<optimized out>)
    at /usr/include/qt/QtCore/qsharedpointer_impl.h:310
#13 KScreen::Osd::~Osd (this=<optimized out>, this=<optimized out>)
    at /usr/src/debug/kscreen/kscreen-5.26.4/osd/osd.cpp:40
#14 0x00005613f411a9e5 in KScreen::Osd::~Osd (this=<optimized out>, this=<optimized out>)
    at /usr/src/debug/kscreen/kscreen-5.26.4/osd/osd.cpp:38
#15 qDeleteAll<QMap<QString, KScreen::Osd*>::const_iterator> (end=..., begin=...)
    at /usr/include/qt/QtCore/qalgorithms.h:320
#16 qDeleteAll<QMap<QString, KScreen::Osd*> > (c=...) at /usr/include/qt/QtCore/qalgorithms.h:328
#17 KScreen::OsdManager::quit (this=0x7ffdba3d53a0)
    at /usr/src/debug/kscreen/kscreen-5.26.4/osd/osdmanager.cpp:49
#18 0x00007fb3cf8b0be0 in QObject::event (this=0x7ffdba3d53a0, e=0x7fb3c0001d80)
    at kernel/qobject.cpp:1347
#19 0x00007fb3cf88cf98 in QCoreApplication::notifyInternal2 (receiver=0x7ffdba3d53a0, 
    event=0x7fb3c0001d80) at kernel/qcoreapplication.cpp:1064
#20 0x00007fb3cf88daa3 in QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, 
    data=0x5613f58cd100) at kernel/qcoreapplication.cpp:1821
#21 0x00007fb3cf8d3e68 in postEventSourceDispatch (s=0x5613f58d5e90)
    at kernel/qeventdispatcher_glib.cpp:277
#22 0x00007fb3cdf1687b in g_main_dispatch (context=0x7fb3c4005010) at ../glib/glib/gmain.c:3444
#23 g_main_context_dispatch (context=0x7fb3c4005010) at ../glib/glib/gmain.c:4162
#24 0x00007fb3cdf6d299 in g_main_context_iterate.constprop.0 (context=0x7fb3c4005010, block=1, 
    dispatch=1, self=<optimized out>) at ../glib/glib/gmain.c:4238
#25 0x00007fb3cdf15132 in g_main_context_iteration (context=0x7fb3c4005010, may_block=1)
    at ../glib/glib/gmain.c:4303
#26 0x00007fb3cf8d7c4c in QEventDispatcherGlib::processEvents (this=0x5613f5900140, flags=...)
    at kernel/qeventdispatcher_glib.cpp:423
#27 0x00007fb3cf88573c in QEventLoop::exec (this=0x7ffdba3d5300, flags=...)
    at ../../include/QtCore/../../src/corelib/global/qflags.h:69
#28 0x00007fb3cf890269 in QCoreApplication::exec ()
    at ../../include/QtCore/../../src/corelib/global/qflags.h:121
#29 0x00007fb3cfd3a112 in QGuiApplication::exec () at kernel/qguiapplication.cpp:1870
#30 0x00005613f41154db in main (argc=<optimized out>, argv=<optimized out>)
    at /usr/src/debug/kscreen/kscreen-5.26.4/osd/main.cpp:17

Maybe AUR package maintained by someone from Manjaro “community” team, that contains unrestricted mesa libva driver will do the trick? AFAIK it can contain precompiled binary.

The Arch extra package already accomplishes this. It cannot be added to the AUR.

When submitting a package to the AUR, observe the following rules:

  • The submitted PKGBUILDs must not build applications already in any of the official binary repositories under any circumstances. Check the official package database for the package. If any version of it exists, do not submit the package.

AUR submission guidelines - ArchWiki