I am on XFCE Manjaro and mine is also on tty2, so it has nothing to do with sddm, which i don’t have.
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.
Perhaps the magic cookie is a red herring.
But I’m not going to reverse my reversion to test it 
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.
1 Like
Yeah, I was just curious more than anything, whether it’s on tty1 or tty2 doesn’t affect me personally.
I might poke at it further if/when I have the time. The code path for selecting the VT seems fairly straight-forward at first glance (famous last words) so I think it shouldn’t be too difficult to trace exactly why it’s selecting tty2.
EDIT I poked at it, see SDDM 0.20 uses random TTY, breaks autostart programs needing X server · Issue #1777 · sddm/sddm · GitHub
1 Like
What I’m finding odd about this is that the only time it causes problems is during the first Plasma session after booting. Logging out then back in again allows autostart GUI programs to run OK. Even with $DISPLAY hard-coded (which one of the devs considers “a bad thing” and the reason for the problem). It makes me wonder if the TTY thing is a red herring and there’s actually some other change in there causing problems.
Well you can simply try to git-bisect the issue on SDDM …
I’ve played around with this some more and turns out it’s the AMD microcode image. If I boot without it, everything is fine. If I boot with it, I get the kernel panic.
I’ve tested the Arch amd-ucode package (20230625.ee91452d-5) and it works for me. Seems like the Zenbleed mitigation is also contained in their older(?) version, so it might make sense to roll back @philm.
I can’t be the only one with this issue.
I vaguely remember some people having similar problems with previous amd-ucode updates + newer kernels if they were using an older motherboard BIOS. Is yours up to date?
1 Like
I’ve done a little more testing to check the theory that hard-coding the DISPLAY variable is the problem and can confirm that it isn’t.
I removed all references to DISPLAY in my startup scripts and .profile/.zshrc, reverted to 0.20 and rebooted. Again, GUI programs failed to run. Firefox throws an error:
Error: no DISPLAY environment variable specified
Interestingly, logging out and back again still has everything working as it did previously. The Firefox startup script is now reporting $DISPLAY as :0 (as opposed to what I was setting, :0.0.
Going back to 0.19 and rebooting, no autostarted GUI programs work: again due to no DISPLAY variable being specified. At least proving that one way or another they have to be given that environment variable.
I do now think that your problem is probably nothing to do with ttys and is more likely caused by other changes made to address bugs/security issues between 0.19 and 0.20. That’s one for the developers to answer.
It’s not the very latest but maybe half a year old. I’ll keep this in mind if the problem doesn’t resolve itself in the future–thanks!
Regarding the autologin I use, I think it works, but since user session is now started on tty2, I’m sometimes left on tty1 even though the session on tty2 logged in automatically.
At the very least it should auto switch to tty2 every time, instead of only sometimes.
I’m experiencing an odd sound issue under GNOME - at a random interval, my sound only comes from the left speaker on my 5.1 setup.
As long as I open Settings > Sound and do a test of all speakers, sound goes back to normal, for a while at least.
That’s a known bug, there are numerous reports of switching issues on the sddm github repo. It even happens without autologin sometimes if you use rootless x11 (because that starts on VT1 and then switches to VT2, or is supposed to).
Will hopefully get fixed as a priority now that 0.20.0 is released, otherwise slower-paced distros like Ubuntu will have the same problem when they upgrade.
No known issue has made to the top of the page.
checkupdates tells me updated will be
linux61 6.1.38-1 → 6.1.41-1
6.1.41-1 is not on the affected kernels list by Phil in the testing update thread from today [Testing Update] 2023-08-04 - Kernels, Nextcloud, Plasma 5.27.7, Mesa 23.1.5, Firefox, Thunderbird
Says there only 3 versions are affected. So I guess good news for me as I had reverted back from 6.1.39 when I didn’t like that peak.
Please, please, update right 
Unfortunately, 6.1.41-1 is also affected — I’m running it here right now. But as stated, it’s a cosmetic issue; the load is not actually going up, and the pertinent CPU core’s temperature also stays within normal parameters.
1 Like