Bug 71136 - Altgr key generates 0 characters
Altgr key generates 0 characters
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
: 71778 74759 76081 (view as bug list)
Depends On:
Blocks: 79062
  Show dependency treegraph
Reported: 2002-08-09 01:50 EDT by Simon Matter
Modified: 2008-08-01 12:22 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-30 11:39:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
midified linux-2.4.18-speakup.patch which avoid altgr key to write a "0" (35.75 KB, patch)
2002-12-03 12:18 EST, Sebastien BLAISOT
no flags Details | Diff
speakup patch for rawhide kernel 2.4.20-0.pp.9 (294.37 KB, patch)
2002-12-19 21:45 EST, William F. Acker
no flags Details | Diff

  None (edit)
Description Simon Matter 2002-08-09 01:50:21 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i686)

Description of problem:
On console, when numlock is on, the Altgr key generates 0 characters. I have
tested it with sg-latin1 and us layout on two different computers.

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

How reproducible:

Steps to Reproduce:
1. Install limbo
2. Login on console
3. Activate numlock key
4. Press Altgr

Actual Results:  Every Altgr keystroke generates "0" characters

Expected Results:  Nothing should be visible

Additional info:
Comment 1 Warren Togami 2002-08-11 17:33:03 EDT
Is this related to this thread?

In this post someone mentions this is a bug in Speakup, and he has a patch to
fix it.
Comment 2 Arjan van de Ven 2002-08-13 05:32:34 EDT
Author sent a fix, added for the next build
Comment 3 Jay Turner 2002-08-16 10:10:50 EDT
Appears to be fixed with kernel-2.4.18-11.
Comment 4 Bill Nottingham 2002-08-20 00:34:21 EDT
*** Bug 71778 has been marked as a duplicate of this bug. ***
Comment 5 Simon Matter 2002-08-21 03:51:05 EDT
I have installed 'null' today with kernel 2.4.18-11 today and the bug is still

Enable numlock, press AltGR enters 0 chars.
Comment 6 Simon Matter 2002-10-02 09:53:00 EDT
I've installed 8.0 today and this bug is still there.
Comment 7 Gilles CHAUVIN 2002-10-20 17:26:06 EDT
RedHat Linux 7.3 upgraded to latest available kernel (2.4.18-17.7.x) using
up2date. Same problem (using fr-latin1 layout).
Comment 8 Tim Waugh 2002-10-21 08:27:25 EDT
*** Bug 76081 has been marked as a duplicate of this bug. ***
Comment 9 Christian Rose 2002-10-21 09:21:34 EDT
Changing the product to RHL 8.0.
Comment 10 Christian Rose 2002-10-21 09:22:31 EDT
*** Bug 74759 has been marked as a duplicate of this bug. ***
Comment 11 Gilles CHAUVIN 2002-10-21 09:59:09 EDT
I just repeat what I say here:

I got the same problem using RedHat Linux 7.1, 7.2 and 7.3 updated to the latest
kernel (2.4.18-17.7.x) using up2date. The keyboard layout used here is
"fr-latin1". Same problem too with RedHat 8.0.

Pressing the right Alt key (AltGr) prints "0" on the console. Under X AltGr
generates '"'.

As nicolas(dot)mailhot(at)one2team(dot)com mentionned at
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=74759 , this problem only
occurs when "NumLock" is on when working with the console. If NumLock is off, no
garbage characters are printed on the screen (with console).

When working with X, the '"' are still displayed (i.e. in Mozilla) whenever
NumLock is on or not.

Is this a kernel related bug? Since this bug has appeared when I upgraded my
RH7.x systems to kernel 2.4.18-17.7.x.
Comment 12 Need Real Name 2002-10-22 11:15:34 EDT
I found exactly the same troule in the console and in X. I use a fr and
fr-latin1 keyoard If you try to press AltGr and just after the "b" key, you
obtain that (in any X editor):

bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb ...

And it repeats indefinitly until you press Backspace!!!

I investigated in the /etc/X11/xkb directory and using the xev utilty, sometimes
the AltGr keycode is 56 and should be 113 (keypressed and released).
/usr/X11R6/lib/X11/xkb/keycodes/xfree86 shows <AB05>=56 and <RALT>=113 wich is
normal but in the file /usr/X11R6/lib/X11/xkb/symbols/iso9995-3 included by 
/usr/X11R6/lib/X11/xkb/symbols/en_US, the key <AB05> is redefined and the <RALT>
key too :

replace key <RALT> { [ Mode_switch,  Multi_key ] };
key <AB05> {	[], [ rightdoublequotemark, quoteright	]	};

The rightdoublequotemark appears when you press the AltGr key!

I don't know exactly how all this files work but I hope this could help someone
(with root acces) for debugging...
Comment 13 Olivier Benghozi 2002-10-29 11:29:38 EST
We all know that the bug is in Speakup. It doesn't occur when speakup is not 
after recompilation with Speakup deactivated. It should be either corrected or 
not included in the default .config in the stock kernel if nobody wants to 
correct it.
So what's RedHat waiting for? It's unbelievable that the keyboard was not 
tested before shipping the kernel.
Comment 14 Christian Rose 2002-10-30 17:56:24 EST
On my RHL 8.0 system I recently installed the 2.4.18-17.8.0 errata kernel and
rebooted the machine. The problems with AltGr immediately went away, both in
console and in X.
Comment 15 Olivier Benghozi 2002-10-30 20:29:09 EST
Cool for you, but here this kernel did not fix this problem. Still 000000 with 
AltGr (but here, the problem is in console, not in X).
Comment 16 Christian Rose 2002-10-31 00:35:41 EST
True enough, I didn't test it enough on the console. After some banging on AltGr
the problem reoccured on the console.
Comment 17 Antonio 2002-11-01 13:37:32 EST
i tried different language configurations, including other keyboards, before i
saw  these postings. still no patch or fix for this ?
go go "dot oh" (8.0) version.
Comment 18 ttlquestor 2002-11-03 09:23:36 EST
I have the same problem with a Belgian keyboard.
If i reboot the machine i can log in the console with as many normal users if i
like and the alt key works normal, from the moment i log in as root on 1 of the
consoles the alt key produces a '0' when pressed in all tty's... even at the
login prompt the problem is there... under x the alt key sometimes works normal
and after typing some other text it suddenly generates some unprintable chars
followed by bbbbbb... endlessly repeating until another key is pressed.

Comment 19 ttlquestor 2002-11-04 08:12:34 EST
I think i need to correct my previous post, because of my root password
containing numeric characters i turned num lock on to type my root password and
that was causing the bug to happen i think, i can't check it anymore because i
installed 7.3 again... but it is most likely...

Comment 20 Carlos Rodrigues 2002-11-06 11:48:08 EST
As someone pointed above altgr generates '"' on X. Up to now I have been able to
reproduce this only in mozilla but I feel that this is related to the '0' on
console because  I only see this happening if I startx from a vt where numlock
is turned on (therefore triggering the '0' bug).
Comment 21 Carlos Rodrigues 2002-11-19 15:40:43 EST
Still happens with the latest kernel from updates (2.4.18-18.8.0).
Comment 22 Need Real Name 2002-11-29 11:22:58 EST
i've got the same problem
alt-gr gives """""", but not in kde.
When gnome is active then there is also no problem. but because i use fluxbox in
X i've got the problem too.
also belgian layout, had nog troubles with redhat 7.3 until i upgraded to 8.0
it's really annoying :-)
got the problem also with 2.4.18-18.8.0
gonna try the rawhide kernel 2.4.19 now, we'll see if the problem is fixed then
Comment 23 Need Real Name 2002-11-29 12:02:58 EST
i tried the 2.4.19 rawhide kernel now.
The problem looks fixed in that version. i didn't get any " anymore when i use
the alt-gr button in mozilla, etc
for some people this test kernel could help, but for me it isn't an option
because it crashes when i'm starting apache :-)
Comment 24 Sebastien BLAISOT 2002-12-02 06:49:45 EST
If this can help, I made some tests here.

With a fresh kernel.org 2.4.18 kernel, compiled with only mandatory options for
my system, I see no problem with the AltGr key (no "0" on runlevel 3 with
numlock on)

even with a closest as possible config as the redhat kernel config, I see no
problem with the AltGr Key.

maybe, it's a speakup problem, as we can see in the speakup patch
linux-2.4.18-speakup.patch (from the kernel-2.4.18-18.8.0.src.rpm source package):

 speakup_control(int currcons, struct kbd_struct * kbd, int value)
+        /* speakup output number 0 for altgr key with spkup_num_lock_on=1 */
+        if (spkup_num_lock_on && (value==KVAL(K_ALTGR))) {
+	  speakup_savekey(0); /* clear!  brzzzot */
+	  put_queue('0');
+	  return;
+	}

didn't try commenting this patch out to see if it helps, but I could do it if

hope this can help, because it's a really anoying bug we encounter here with a
french layout keyboard under virtual consoles.
Comment 25 Sebastien BLAISOT 2002-12-02 11:38:37 EST
I tried the following :

* Recompiling RedHat kernel ==> Same problem
  - installed kernel-source-2.4.18-18.8.0.i386.rpm
  - copy config/kernel-2.4.18-i686.config to arch/i386/defconfig
  - make oldconfig
  - make dep && make bzImage && make modules && make modules_install && make install
  - reboot new kernel
  ==> Same problem

* Recompiling RedHat kernel with CONFIG_SPEAKUP unset ==> NO MORE PROBLEM
  - make mrproper
  - edit Makefile to set EXTRAVERSION to -18.8.0nospeakup
  - make menuconfig -> console driver -> uncheck "Speakup Console speech" ->
save and exit
  - make dep && make clean && make bzImage && make modules && make
modules_install && make install
  - reboot new kernel
  ==> Problem not seen

So a workaround could be to recompile a RedHat kernel without speakup, before
waiting for a fix in, I hope, a next kernel release.

I think this problem has come either with the patch-2.4.19-rc1-ac1.tar.bz2 patch
which add speakup support or with the linux-2.4.18-speakup.patch patch included
in the RedHat kernel.

The <kernel tree>/Documentation/speakup/keymap-tutorial file explains:

"The altgr key is not really used for anything important, so we steel it".

This may be true with a US layout keyboard, but is totally wrong with other
layout like french, belgian, ... where AltGr is used to produce common
characters as "@" or "^" or "|".
Comment 26 Sebastien BLAISOT 2002-12-03 12:18:28 EST
Created attachment 87244 [details]
midified linux-2.4.18-speakup.patch which avoid altgr key to write a "0"
Comment 27 Sebastien BLAISOT 2002-12-03 12:19:14 EST
tried something different today.

when removing the line put_queue('0'); in the speakup_control function in
drivers/char/speakup/speakup.c and recompiling the kernel with speakup option
enabled, the problem is not reproduced.

this line was added by the linux-2.4.18-speakup.patch applied by RedHat.

don't know if this can cause speakup to not work anymore. to be tested with a
speakup enabled system.

I had post a proposed modified linux-2.4.18-speakup.patch modified to test.

Hope this problem will be corrected in the next kernel release
Comment 28 Nicolas Mailhot 2002-12-04 07:10:05 EST
I don't want to be harsh, but I'm really astounded this bug is still not fixed,
is qualified as + normal ;, and has seen no RH activity for at least 3 months.

This bug was first reported in august !
It hits a major keyboard key both on the console and in X for many locales.
It was repeatedly reported by many people.
Its cause has been clearly identified in a not-production-ready patch that most
people won't use.

And still there is no fix, either in RH itsef or in Raw Hide. At this point in
time I fully expect RH 8.1 to ship with the bug.

So don't make me laugh with bluecurve. Is Red-Hat desktop or even datacenter
ready ? It can't even get keybord input right for christsakes (just try to work
without ever using &,#,@ or |) !

(sorry for venting up my frustration, but one has just to see what updates went
in RH 8.0 to realise very obscure security bugs take precedence on enabling
non-english speaking users to perform the most basic of tasks. Do *anyone* at
Red Hat realise the impact of this bug ?)
Comment 29 Gilles CHAUVIN 2002-12-04 15:27:02 EST
I agree with Nicolas Mailhot... And tell again this bug is not only in RedHat
8.0 but it was bring to RH7.1, 7.2 & 7.3 since kernel-2.4.18-7.x are available
with "up2date". For now, four different RH official releases are affected by
this bug :(.

It would be great to have someone from RH post a comment here. Just to know that
this bug was not forgotten. Or do we have to do a stupid thing: open a duplicate
of this bug in the hope it'll be seen by someone else than arjanv@redhat.com ???
Comment 30 Christian Rose 2002-12-04 16:35:58 EST
I'll try bumping the severity to "high". This problem isn't causing crashes, but
it causes major loss of keyboard functionality, which probably can be agreed to
be important.
Comment 31 Nicolas Mailhot 2002-12-05 04:48:09 EST
Please use the umbrella 79062 bug now to enter general comments. Thanks.
Comment 32 Christian Rose 2002-12-14 15:04:55 EST
A problem report was posted to the speakup mailing list. You can read the thread
at this address:
Comment 33 William F. Acker 2002-12-19 21:45:28 EST
Created attachment 88823 [details]
speakup patch for rawhide kernel 2.4.20-0.pp.9 

New speakup patch for rawhide kernel 2.4.20-0.pp.9 which should fix problem
with international keyboards. Needs lots of testing.
Comment 34 Sebastien BLAISOT 2003-01-06 03:13:48 EST
seems to have been corrected in kernel-2.4.18-19.8.0 from updates. don't see the
problem with that kernel.
Comment 35 Daniel Resare 2003-01-25 15:05:41 EST
I can not reproduce this problem with kernel-2.4.18-19.8.0 (swedish keymap)
Comment 36 Bugzilla owner 2004-09-30 11:39:49 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

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