Unless you can also experience a performance loss and/or excessive heating … it is likely only cosmetic … as described in the plethora of posts before this.
You can live with it and wait for an update … OR …
compile yourself with patch
remove any widgets/apps that depend on akonadi and mariadb (and remove them too?)
replace your desktop database software with something other than mariadb
(kalendar + akonadi + mariadb is exactly the combination that would produce said cosmetic bug)
(though it should probably be noticeable under any circumstances that akonadi+mariadb is used)
Thanks for your suggestions. Guess I’ll just play the waiting game.
Quickly looked for any “maria” process, then for akonadi. Found like 12 akonadis, maybe I can pause them or so to get rid of the peak.
Wanted to see how much the add-on Active Blur (user-made Desktop Background) is consuming first. Then apply the update later. Hm but here I’m getting off-topic now, sorry.
As far as I recall cilynx’s fork of rtl88x2bu driver didn’t work with my wifi dongle. I am using RinCat’s fork via rtl88x2bu-dkms-git AUR package. While rtl88x2bu-cilynx-dkms-git is orphaned. Though both are still being updated on github.
I seem to be having issues related to auto login in KDE. I’ve had set to autologin for very long time, but since this update, or the one before that I frequently land on login screen that wants my password.
That’s not all, sometimes when I’ve landed on login screen on tty1, there is already a logged in desktop on tty2, but this desktop has no internet connection working.
Certainly the problem(?) of X running on TTY2 exists for me. It started with the last update. Though my autologin is working fine.
I’m seeing all of the bootup messages on TTY1, then it’s switching to TTY2 for X (I can see the bootup messages by going to TTY1).
I’m very suspicious that opening X on TTY2 is at the back of the problem I and some other people have of programmes triggered by autostart or systemd timers being unable to open the X server.
I can’t find any more information than that. Doesn’t cause any problems for me personally but yes, anything that expects sddm and/or kwin_x11 to be on tty1 will be broken.
Does anyone know if there’s a way to get X back on TTY1? Any config change that can be made?
I have a strong suspicion this is the cause of my autostart programs being unable to open the X server (though oddly, they can on the second and subsequent login after booting).
@beermad@MrLavender@mikaka27
For all you tty people … I’m pretty sure this is a product of sddm.
As far as I know it is a bug.
Not so much the ‘wrong tty’ … I believe that was a deliberate change.
But rather the need to ‘change seats’ as it is not always done automatically - that is a bug.
(and/or the selection being tantamount to random)
There is actually a better bug report/thread somewhere … but I cant find it.
There are a number of related and duplicate threads.
I did search both this forum and DuckDuckGo but was unable to find anything recent that definitely says that this is either a bug or intended. That Github issue is over 2 years old and this change has only happened recently. I don’t know exactly which update it was because I didn’t notice it for a while but it was within the last few months.
Oh … well … looking at your bug report … we might be talking about different things.
The magic cookie issue can probably be fixed by
mv ~/.Xauthority.bak
Then logout and login again (not reboot)
Like I said … not the supposedly ‘wrong tty’ issue … but SDDM 0.20+ does have a problem with properly assigning seats. I have to manually hit Ctrl+Alt+F2 maybe ~50% of the time I start.
This has been true ever since 0.20+, when I started using sddm-git a while back … and is now in sddm regular.
So apparently there have been a LOT of changes made between sddm 0.19 (Nov 2020) and 0.20 (Jun 2023)…
Including a complete rewrite of how the initial VT is selected. E.g.
Looking at /usr/lib/systemd/system/sddm.service it has been configured and built with SDDM_INITIAL_VT=1 but is choosing to use 2 instead for whatever reason. Possibly related;
TLDR; does look like a bug in sddm 0.20, and for now downgrading to 0.19 seems to be the only option if you need it to use tty1
SDDM. I remember there was something with the pacdiff -s after the Stable update on 23-07-10.
The sddm configuration file changed for me then. Did you do:
The [community] repository has been merged into [extra] and is now empty.
It may take a bit of time for mirrors to catch up (more details here 11).
Update your system and handle the pacman
sudo pacman -Syu "pacman>=6.0.2-11"
In order to remove the defunct [community] repo changes must be made to /etc/pacman.conf.
Changes will be provided in a file with the extension .pacnew 9.
Pacman provides the utility pacdiff to manage these files and will use vim -d for comparison if the environment variable DIFFPROG is not set.
pacdiff -s
If you would like to use a different comparison tool you may prepend the env var:
DIFFPROG=meld pacdiff -s
Then sync with the repositories again:
sudo pacman -Syu
… back then? If not, that might be the reason for your issues, but just my 2c, you can keep them, I might be wrong!
SDDM 0.20 allows for rootless graphical session though. And thats more important to me than what tty is what and/or needing to manually switch to seat 2 sometimes.
But you are right … lots of changes. 0.19 had languished for a while … some even thought it abandoned.
With KDE now invested in SDDM we will likely see more smoothing over the near future.
