Bug 467634 - Alt+Fn virtual console switch problem
Alt+Fn virtual console switch problem
Status: CLOSED DUPLICATE of bug 467430
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Airlie
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F10Blocker/F10FinalBlocker F10DesktopBlocker
  Show dependency treegraph
 
Reported: 2008-10-19 14:53 EDT by Yusuf Ma
Modified: 2008-10-27 15:32 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-27 15:32:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Yusuf Ma 2008-10-19 14:53:10 EDT
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):

kernel-2.6.27.3-27.rc1.fc10.i686

How reproducible:

Everytime

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

Virtual console hang

Expected results:

Switch between virtual consoles quickly

Additional info:
Comment 1 Mads Kiilerich 2008-10-20 09:07:30 EDT
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 13:50:22 EDT
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 13:53:30 EDT
perhaps x.org is the correct component.

http://who-t.blogspot.com/2008/10/avoid-evdev-devices-in-xorgconf.html
Comment 4 Yusuf Ma 2008-10-20 16:16:43 EDT
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 19:09:48 EDT
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-20 22:29:20 EDT
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-21 23:30:52 EDT
Updated kernel and plymouth but no luck. Problem still exists.

kernel-2.6.27.3-30.rc1.fc10.i686
plymouth-0.6.0-0.2008.10.17.3.fc10.i386
Comment 8 Matthias Clasen 2008-10-23 14:56:22 EDT
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 15:23:28 EDT
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 02:04:15 EDT
Ctrl+Alt+F1 gives black screen
Ctrl+Alt+F7 gives black screen with dead mouse

kernel-2.6.27.3-39.fc10.i686
plymouth-0.6.0-0.2008.10.21.2.fc10.i386
xorg-x11-server-Xorg-1.5.2-8.fc10.i386
Comment 11 Matthias Clasen 2008-10-24 19:14:13 EDT
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 15:32:26 EDT
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.