Thanks for the tip.
FWIW: Crocus driver performance is acceptable if I turn off compositing (Picom), which I often do anyway. But now it is particularly slow to redraw: moving windows is a flickery affair. Without it, everything is as snappy as i915 was.
I’m using Openbox (on Mabox, which is Manjaro with a custom Openbox WM setup), and am fine with this so far. Have not tried any graphics-intensive tricks yet though. I would prefer to stay with a maintained driver if it can do all I need it to.
I agree, and noticed this happening sometime last Fall. I posted about it, but never have found out the reason why this happens.
For me it is an annoyance, but I switch kernels from time to time anyway. so it is no more than that. Eventually I will have nothing better to do but figure out what is going on with kernel updates, grub configs, UEFI settings, and/or ???. If so, I’ll shout it from the rooftops. So to speak. 
Same here, about the annoyance and the motivation to figure it out when I have nothing better to do I’d guess it’s somewhere in how the new grub entries are created. It might be missing a read from UEFI to find out the current default entry and adjust it for the new grub menu. But I’m neither a GRUB nor a UEFI expert, so it would take same time to figure out what’s really going on there.
From what I understand, Grub’s menu reads like an “index”.
0
1
2
3
4
5
6
Etc…
So if the order of this index gets “shifted”, so too will your “default” entry. I believe this is the case even if you use “Remember my last choice”.
Grub is not aware of “kernel preference”. It only knows “0, 1, 2, 3, 4, etc…”.
What would be cool, and may even be possible, is some sort of “hook” that always places your preferred kernel to the top of the list post Grub config generation. But that’s getting a bit off topic and somewhat extravagant. 
I noticed that my wifi connects faster after coming out of sleep on my laptop recently. Props to the team on that one!
Looks like a possible package snafu in the update just pushed for manjaro-gnome-settings.
$ pamac update
Preparing...
Synchronizing package databases...
Resolving dependencies...
Warning: cannot resolve "qgnomeplatform-qt5", a dependency of "manjaro-gnome-settings"
Error: Failed to prepare transaction:
could not satisfy dependencies:
- unable to satisfy dependency 'qgnomeplatform-qt5' required by manjaro-gnome-settings
There is no qgnomeplatform-qt5 in the repos, typo? I do see qgnomeplatform-qt6 and qgnomeplatform.
And to be certain checked my mirrors.
$ pacman-mirrors
Pacman-mirrors version 4.23.2
Local mirror status for stable branch
Mirror #1 OK 00:14 United_States https://repo.ialab.dsu.edu/manjaro/
Mirror #2 OK 00:40 United_States https://mirror.math.princeton.edu/pub/manjaro/
Got the same thing, tried removing qgnomeplatform as it seem to be qt5 based but it errors with:
could not satisfy dependencies:
So not sure what to do now.
Looks like we’re all fixed up! Just gotta wait for mirrors to sync etc.
Hello everybody. After update (six times) the system, it stay in the black screen previous to show the login input (GDM). Updating by parts, I get the system starts fine and I found the problem: gdm-plymouth.
Updating the full system without gdm-plymouth goes fine. Now I stay with the GDM previous to the update. Is there any reason for that error with gdm-plymouth? Thanks.
What error?
Updating gdm to gdm-plymouth doesn’t show the login input nor let alt+ctrl-f2 to go to tty.
You can get into console mode adding 3 to the boot option, and then, go to gnome with ‘gnome-shell – wayland’. Downloading gdm-plumouth to gdm, every goes fine again.
AUR packages are neither supported by Arch nor Manjaro
But this question is about why packages in the official repo are pulling in AUR packages as dependencies. It shouldn’t happen.
$ pikaur -Qua --devel
...
kipi-plugins 21.12.3-1 -> 22.04.0-1
libkipi 21.12.3-1 -> 22.04.0-1
...
At https://manjaro.org/branch-compare/:
Packages: kipi-plugins kde-unstable
Branch: Stable: 21.12.2.1.r12087.g604ce6cc3-1
So it looks like they did not get updated to 22.04 in Manjaro repos. ?
I never heard of KIPI before, I did not install it, I don’t use kde-unstable,
but now kipi-plugins and libkipi appear in AUR, and it looks like
I cannot remove them without breaking gwenview and spectacle :
$ pikaur -R libkipi
:: removing libkipi breaks dependency 'libkipi' required by gwenview
:: removing libkipi breaks dependency 'libkipi' required by spectacle
gwenview and spectacle still work,
so I’ll not do anything with kipi until some well-founded advice appears.
This is already mentioned in the Known issues and solutions above.
Thanks.
I read that list before I upgraded, at which time libkipi meant nothing to me, so I didn’t remember it after the upgrade. I’ll try forcing pikaur to remove them.
EDIT:
There’s still something wrong with this situation though, isn’t there? –
that some package you never heard of can suddenly appear in your AUR helper’s list.
Not really, AFAIK anyway. Because packages can get downgraded to AUR relatively easily, and it does happen, and has happened previously. Even easier for a dependency that you might not know about.
But perhaps that’s just my opinion.
This might be getting off topic,
but look at the change between 13:32 and 17:15 (AEST) :
at 17:15, gwenview and spectacle were no longer listed as dependencies.
[code edited to remove excess space]
[jh@SSD2 220521 13:32:11 logs]$ pikaur -R libkipi
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: removing libkipi breaks dependency 'libkipi' required by gwenview
:: removing libkipi breaks dependency 'libkipi' required by kipi-plugins
:: removing libkipi breaks dependency 'libkipi' required by spectacle
[jh@SSD2 220521 13:32:19 logs]$
----------
[jh@SSD2 220521 17:15:29 logs]$ pikaur -R libkipi
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: removing libkipi breaks dependency 'libkipi' required by kipi-plugins
[jh@SSD2 220521 17:15:52 logs]$
[jh@SSD2 220521 17:16:08 logs]$ pikaur -R kipi-plugins
checking dependencies...
Packages (1) kipi-plugins-21.12.3-1
Total Removed Size: 6.52 MiB
:: Do you want to remove these packages? [Y/n] y
:: Processing package changes...
(1/1) removing kipi-plugins [####] 100%
:: Running post-transaction hooks...
(1/3) Arming ConditionNeedsUpdate...
(2/3) Updating icon theme caches...
(3/3) Updating the desktop file MIME type cache...
[jh@SSD2 220521 17:16:35 logs]$
[jh@SSD2 220521 17:16:37 logs]$ pikaur -R libkipi
checking dependencies...
Packages (1) libkipi-21.12.3-1
Total Removed Size: 0.27 MiB
:: Do you want to remove these packages? [Y/n] y
:: Processing package changes...
(1/1) removing libkipi [#####] 100%
:: Running post-transaction hooks...
(1/2) Arming ConditionNeedsUpdate...
(2/2) Updating icon theme caches...
[jh@SSD2 220521 17:16:44 logs]$
I’m also having the same problem trying to open .jnlp files since the update. this is what I get:
selected jre: /usr/lib/jvm/default-runtime
WARNING: package sun.applet not in java.desktop
WARNING: package com.sun.net.ssl.internal.ssl not in java.base
WARNING: package javax.jnlp not in java.desktop
Exception in thread "main" java.lang.UnsupportedOperationException: The Security Manager is deprecated and will be removed in a future release
at java.base/java.lang.System.setSecurityManager(System.java:416)
at net.sourceforge.jnlp.runtime.JNLPRuntime.initialize(JNLPRuntime.java:268)
at net.sourceforge.jnlp.runtime.Boot.init(Boot.java:353)
at net.sourceforge.jnlp.runtime.JnlpBoot.run(JnlpBoot.java:58)
at net.sourceforge.jnlp.runtime.Boot.run(Boot.java:274)
at net.sourceforge.jnlp.runtime.Boot.run(Boot.java:63)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
at net.sourceforge.jnlp.runtime.Boot.main(Boot.java:214)
As for you, with Java 17 works. Did you manage to find a solution to get Java 18 to work?
A little annoyance: after the update, at every reboot I can’t see anymore the “Network: Wifi activated” KDE popup.
I suspect network is activated before desktop is displayed.
From the previous update I had noticed that the popup was shown much earlier than usual, but sufficiently in time to be visible.