-
Notifications
You must be signed in to change notification settings - Fork 5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ctrl+Alt+F1 does not switch out of the X Windows desktop to the console #5011
Comments
@popcornmix FYI |
Yeah, I agree that we should revert it. I've reported both issues upstream and will try to look into it after the IGT fixes I'm working on |
Reverting PR didn't fix it. I think it's from upstream bump to 5.15.33. Let me see if I can narrow it down further. |
Reverting upstream "fbdev: Hot-unplug firmware fb devices on forced removal" (which also needs a revert of "fbdev: Fix unregistering of framebuffers without device") seems to fix this issue. |
@davidplowman this should be fixed in rpi-update kernel. |
I've posted https://lists.freedesktop.org/archives/dri-devel/2022-May/353699.html which I believe should solve this issue as well. |
@martinezjavier tested your patch (without the reverts) and it also fixes the issue. |
@popcornmix great, thanks for testing! |
@popcornmix could I ask you to test another patch series? The previous patch shared wasn't really correct and just papered over the issue. The latest attempt is: https://lists.freedesktop.org/archives/dri-devel/2022-May/354285.html Only patch 2/2 should be enough for you if you are using simplefb, but there's also a fix for efifb and a patch to fbdev core to prevent the use-after-free even if the fbdev driver is buggy. |
I was able to reproduce the issue and confirm the fix on a rpi4 with:
|
FYI the fixes landed in mainline and will be in v5.18-rc7. |
@martinezjavier thanks - I'll drop reverts on next update. |
Describe the bug
Normally pressing Ctrl+Alt+F1 switches out of the X Windows desktop to fullscreen console, and Ctrl+Alt+F7 returns again.
I've been observing somewhat random behaviour, with the behaviour changing on reboot:
Sometimes it just doesn't work at all, and the screen looks unchanged (showing the X desktop) but with the cursor missing. Ctrl+Alt+F7 however returns the cursor and everything is OK again. When this happens there is a kernel crash in dmesg.
At other times it does switch to the console, and back again, but then Ctrl+Alt+F1 won't work again until the mouse has been wiggled. Though if you never touched the mouse at all then it continues to work. Nothing in dmesg in this case.
I'm finding this easiest to reproduce on a Pi 3, though I'm sure I've seen it on a Pi 4 as well. I believe this to be the offending commit. The previous commit seems repeatedly and reliably to work correctly, but when "rpi-updating" to this one the bad behaviour is observed.
There's a suggestion that this patch #4971 is related.
Steps to reproduce the behaviour
As above. I've flashed a brand new SD card, inserted it into my Pi 3, let it run through its updates and all is fine. I've installed nothing extra.
Then execute
sudo rpi-update eaac3e5367944f2caf6eda88f81282633a3d7128
, reboot and then the bug occurs. As explained, the behaviour tends to change rather randomly with each reboot.Device (s)
Raspberry Pi 3 Mod. B+, Raspberry Pi 4 Mod. B
System
Logs
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: