Bug 467634 - Alt+Fn virtual console switch problem
Summary: Alt+Fn virtual console switch problem
Status: CLOSED DUPLICATE of bug 467430
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati
Version: rawhide
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Dave Airlie
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: F10Blocker, F10FinalBlocker F10DesktopBlocker
TreeView+ depends on / blocked
Reported: 2008-10-19 18:53 UTC by Yusuf Ma
Modified: 2008-10-27 19:32 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-10-27 19:32:26 UTC

Attachments (Terms of Use)

Description Yusuf Ma 2008-10-19 18:53:10 UTC
Description of problem:

In runlevel 5, Alt+Fn (n=2 to 6) can switch between virtual consoles, but Alt+F1 will only show a cursor on the top left corner of screen without login prompt. Alt+F7 will bring a black screen with a mouse cursor instead of the desktop.

If booted into runlevel 3, Virtual Console 1 will show the login prompt but nothing will show up while I am typing my user name. I have to type in a random user name + Return key + random password + Return key, and wait for the "incorrect login" information showing up. After that, the keyboard works as usual. Virtual console 2 to 6 don't have such problem.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Boot the computer into runlevel 5 or 3
2. Press Alt+Fn combination to change between consoles
Actual results:

Virtual console hang

Expected results:

Switch between virtual consoles quickly

Additional info:

Comment 1 Mads Kiilerich 2008-10-20 13:07:30 UTC
Note that with f10 the primary X session is moved to ctrl-alt-f1. There has been a bugs like you describe, and some of them have been resolved.

This looks like a duplicate of bug 466492 and bug 467207 - and perhaps bug 467430 too.

I don't think it is kernel-related - but I really don't know ...

Comment 2 John Poelstra 2008-10-20 17:50:22 UTC
this behavior also seriously conflicts with established short cut in Gnome to launch applications using ALT+22.

If you do ALT+f2 it switches to a virt console.  When you switch back to X the launch application dialog is waiting for you :-/

If this belongs in a separate bug, let me know.

Comment 3 John Poelstra 2008-10-20 17:53:30 UTC
perhaps x.org is the correct component.


Comment 4 Yusuf Ma 2008-10-20 20:16:43 UTC
Agree with Mads. It looks like a duplicate of bug 466492, but I don't know if it is x.org bug because it happens in runlevel 3 too. Probably two bugs here?

Comment 5 Mads Kiilerich 2008-10-20 23:09:48 UTC
Disclaimer: I'm just a tester ...

1. There was a bug in an X version released something like 20 hours ago which caused some shortcuts to behave unexpected (alt-left switched console, ctrl-alt-del restarted) - perhaps it also switched consoles with alt-fn? Another X version were available 12 hours ago - mcepl on IRC strongly recommended upgrading ASAP. That could be what is referred to in comment #2 and #3.

2. The runlevel 3 behaviour could be bug 467207 ...

So, Yusuf, perhaps your issues has been solved in rawhide? I suggest you retest. And make sure you get the new plymouth in your initrd. I will test my reports tomorrow ;-)

Comment 6 Yusuf Ma 2008-10-21 02:29:20 UTC
Upgraded to xorg-x11-server-Xorg-1.5.2-7.fc10.i386

Problem partially solved. Alt+Fn does not switch consoles in runlevel 5 anymore, but problem still exists for Ctrl+Alt+Fn in runlevel 5 or Alt+Fn in runlevel 3. What's more, Ctrl+Alt+F7 still takes too long to bring desktop back. This is not mentioned in bug 467207. I don't know if this is another bug or not. I will wait for the next version plymouth and give it a test.

Comment 7 Yusuf Ma 2008-10-22 03:30:52 UTC
Updated kernel and plymouth but no luck. Problem still exists.


Comment 8 Matthias Clasen 2008-10-23 18:56:22 UTC
This bug is a little unclear to me.

From my understanding, the current state of affairs in X is:

- C-A-Fn switches vts
- A-Fn does not switch vts

Which is as it has always been, and how it shall remain until vts bite the dust...

 What is left open here, if anything ?

Comment 9 Will Woods 2008-10-23 19:23:28 UTC
The remaining bug would probably be that X is stuck (black screen) after the VT switch back.

There are various bugs already that cover that problem: for intel, see bug 467793; for radeon, see bug 467430.

Comment 10 Yusuf Ma 2008-10-24 06:04:15 UTC
Ctrl+Alt+F1 gives black screen
Ctrl+Alt+F7 gives black screen with dead mouse


Comment 11 Matthias Clasen 2008-10-24 23:14:13 UTC
C-A-F7 goes to a vt without a getty on it. 
There is nothing mysterious about that.
If you create /etc/event.d/tty7 as a copy of tty6, then there will be a text
login on vt7.

Comment 12 Bill Nottingham 2008-10-27 19:32:26 UTC
I'm not seeing anything here that implies a unique bug. As stated - X dying on VT switch is bug 467430, and it's not an issue that there is nothing on VT7. Closing as a duplicate of 467430.

*** This bug has been marked as a duplicate of bug 467430 ***

Note You need to log in before you can comment on or make changes to this bug.