Red Hat Bugzilla – Bug 80694
Low-level typematic setting causes console screen switch
Last modified: 2007-04-18 12:49:22 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows 98; hahaha-fooled you!
This is really Mozilla/5.0 on Linux i686 rv:1.0.1 Gecko/2002103)
Description of problem:
In the file lnx_io.c there is a piece of code that sets the keyboard typematic
rate using low-level port input and output.
Unfortunately this code causes the keyboard to emit a scancode 0xfa which the
Linux kernel misinterprets as a keysym 0xf505 which happens to be equivalent to
ALT+F6. This causes the console screen to switch to screen 6, which is ok
provided you stick to the default RedHat distribution setting which has X run on
virtual screen 6 (because it only defines 6 virtual screens).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Add 4 extra console screens to /etc/inittab; telinit q
Actual Results: X will be running on console 10 but console 6 will be current
Expected Results: Console 10 should be current console (with X on it).
I don't quite understand the precice detailed steps in order to attempt to
reproduce. Could you expand step by step, with exact details?
I've always had 12-24 consoles configured in inittab since 1995 or so, and
have never encountered random VT switching like described above, so I would
like to make absolutely positive of the exact steps to reproduce. Attach
your /etc/inittab, X log, and config file please along with the details.
This possibly only happens when using startx to bring up X.
That is how I usually have things configured.
I also have a different keymap that maps Delete to Delete and Backspace to
Backspace instead of the usual strange US.map.
I have also patched and recompiled my XFree86 with the typematic stuff
commented out. This fixes the problem. But at this point in time I
am not prepared to undo everything and go back just to get some logs etc.
My initiab is nothing special - just extra mingetty's and runlevel of 5.
But I have screen :0 commented out of my Xservers file.
I suggest that you start your testing by preventing the xdm startup of local
screen :0 and see what happens when you log in to, say virtual console 1,
and type startx.
Well, if there is a problem here at all, it definitely is not a Red Hat
Linux specific problem as we aren't patching the code in any ways that
could cause the behaviour you describe, so it would be a generic XFree86
Since you're the first to report such a problem, I doubt that if it is
an actual software bug that it is affecting very many users at all.
If you're not willing to provide me with log files and information that
I've requested above, then you seem satisfied with your own workaround,
and I'm not going to waste time tracking down something that is potentially
just some weird issue on your own local system.
If you believe this is indeed a bug in XFree86, then I suggest reporting
it to XFree86.org directly by using the firstname.lastname@example.org mailing list,
and email@example.com bug report address.
Inability to reproduce this on 2 systems makes this a non-priority issue
for me to investigate further without co-operation from you.
Closing as WORKSFORME.
I reported this to XFree over a year ago. The same problem occurred on
complete different hardware (different keyboard and motherboard and with
RH7.0 and RH7.2 and now RH8.0).
But one does wonder why the default RH distribution
is configured with only 6 VTs so that VT6 is used for X
(that is what the glitch causes a switch to - handy coincidence!).
If you look at the XFree code you will see the inb() and outb()'s that
are used to zap the keyboard. Given that the kernel already has a driver
for the keyboard active it is small wonder that things get temporarily
But you are right. Why bother? No one else complains because they probably
use the default configuration. And those that do probably just attribute
it to typically flakey linux desktops.
BTW it has something to do with the fact that the kernel returns EINVAL
from KDKBDREP, so the code falls beack to direct port i/o.
Have a nice day. Sorry to waste your time (and, more importantly, because
I dont get paid for this - my time).
>I reported this to XFree over a year ago. The same problem occurred on
>complete different hardware (different keyboard and motherboard and with
>RH7.0 and RH7.2 and now RH8.0).
How did you report it exactly? What email address did you report to?
I can ping someone there to investigate your report if it got lost in
the pile somehow.
>But one does wonder why the default RH distribution
>is configured with only 6 VTs
Well, that is basically because it has been standard practice in all
Linux distributions basically since the dawn of time to preconfigure
6 VCs in inittab, and most documentation assumes 6 preconfigured VCs.
Most Linux X related documentation also assumes that 6 VCs are the
default as it mentions X starting on VC 7 in countless places.
>so that VT6 is used for X
No, X by default uses the first unused tty unless you manually specify
a specific VC to start on using an X server commandline option. Since
all Linux distributions (not just Red Hat) default to using 6 VCs, X
starts up on VC 7 (/dev/tty7) by default in all Linux distributions.
>(that is what the glitch causes a switch to - handy coincidence!).
I don't see any coincidence here, since it is tty7 that the X server
is physically running on, and not tty6 as you imply above.
>If you look at the XFree code you will see the inb() and outb()'s that
>are used to zap the keyboard. Given that the kernel already has a driver
>for the keyboard active it is small wonder that things get temporarily
I wonder why only one person has ever reported this? As I stated before,
*I* run more than 6 virtual consoles on all my Linux machines, and I
always have, since 1995 if not earlier. Across every release of Slackware
up until 1997, and every release of Red Hat Linux since 4.2. I have
_never_ encountered this problem on tonnes of machines.
I am not saying there _isnt_ a problem, just that I have not ever experienced
it, and using your above info, I am unable to do so currently either.
>But you are right. Why bother? No one else complains because they probably
>use the default configuration. And those that do probably just attribute
>it to typically flakey linux desktops.
That is bogus. I have never encountered this problem in 7 years of heavy
Linux usage on many different computers across many XFree86 releases on
many distributions. I've not seen any bug reports of this nature ever other
than yours right now, and I am unable so far to reproduce the problem you
are claiming exists.
If this problem is really a problem, and it bothers you so greatly, you
would provide the information requested, and you would work WITH developers
instead of AGAINST them, and you would do so politely rather than ranting.
If I were to chase every single bug that a user reports and is adamant about,
a good 50% if not more of them would waste my time chasing bugs that are
end user misconfiguration, or end user self-compiled-kernel problems, or
other similar end user invoked problems. I don't have time to do that, which
is why I ask people to provide me with as many details as possible for their
Again, please take this issue upstream to XFree86.org as it is not
reproduceable by me given the supplied information above, and considering
the plethora of other problems that are actually reproduceable, and the
triviality of this one which is not, it is not going to get any priority
Closing again as WORKSFORME, on a Compaq Proliant ML530, a Tyan HEsl 2567,
an Acer AMD 486DX2/66, a VIA TXPro motherboard, an Itanium 2, and another
Exact steps to reproduce the problem:
1. Modify /usr/kbd/keymaps/i386/qwerty/us.map.gz
by adding "keycode 93 = Console_6"
2. Re-load it with "loadkeys us"
3. Type "startx"
4. Voila! You get VT6 instead of the correct VT with X.
The low-level XFree code which zaps the keyboard causes the emission of
a "false" keycode. It is just that not many people (in fact I suspect I
might be the only one) has anything mapped to keycode 93.
What exactly is the purpose of editing the keymap files at all?
On a default installation of Red Hat Linux, there are 6 virtual consoles,
and X will open the first free one which is tty7. Without modifying
/etc/inittab, you can switch between any of the consoles using ALT-F1 through
ALT-F7 from the console, or by using ALT-LEFTARROW/ALT-RIGHTARROW. This is
standard default console configuration. If you add entries for other consoles
to /etc/inittab, then the system will automatically use them also.
To illustrate my point, here is my inittab:
1:2345:respawn:/sbin/mingetty tty1 --noclear
When the system starts up, 22 virtual consoles are created with mingetty
logins, the first of which I have added the --noclear option to. ALT-F1
through ALT-F12 selects consoles 1 to 12, and RIGHT_ALT-F1 through
RIGHT_ALT-F12 selects consoles 13 to 24. I start up X using "startx" with
sufficient commandline options to make it start on tty24 which is where
I want it to be.
I am able to switch to whatever terminal both inside and outside X, and
I do not need to edit any console nor X keymaps to do so. I also do not
experience the problem you are describing, nor do I understand why you
feel the need to edit the keymap.
If there is a bug here, and I'm not acknowledging that there is, it is
NOT something that is going to be fixed by Red Hat, nor in Red Hat Linux.
It is something that MUST be done by XFree86.org before I will even
I am closing this as WONTFIX this time to differentiate it from WORKSFORME,
in that if there is a bug, it is not going to be fixed, at least not here.
If you were unsuccessful in getting XFree86.org to fix it or to look at your
patch, then perhaps you should try talking to them again, and establish
2 way communication.
Do not reopen this report again please, as that is a pointless waste of
both of our time. I've indicated it is WONTFIX, and that isn't going
to change. As far as I'm concerned, your keyboard is broken.
Your additional information was absolutely pointless.
So what you are saying is that Redhat has never contributed to a fix
for a product that they don't "own"? Is that what the open source
community is about?
Have a nice day and I hope you never use a keyboard made outside of the
USA for non-USA users or non-English language etc.
BTW my keyboard is NOT broken, and if your analysis has drawn that conclusion
then it is definitely flawed. The XFree86 code is broken because it causes
ALL keyboards (not just mine) to emit the same keycode - it just so happens
that there is normally nothing in the keymap that coincides with that code.
And this has nothing to do with the normal ALT-Fn switching of console
screens - I cannot understand why you thought you needed to explain
I suggest you read what I said carefully. But I'll repeat because you
don't seem to be listening.
THE LOW LEVEL I/O POST ACCESS THAT XFREE86 USES WHEN TYPEMATIC IOCTL
FAILS CAUSES ALL KEYBOARDS TO GENERATE A SPURIOUS KEYCODE.