Bug 71136

Is this related to this thread?
https://listman.redhat.com/pipermail/limbo-list/2002-August/002191.html

In this post someone mentions this is a bug in Speakup, and he has a patch to
fix it.
https://listman.redhat.com/pipermail/limbo-list/2002-August/002359.html

Author sent a fix, added for the next build

Appears to be fixed with kernel-2.4.18-11.

*** Bug 71778 has been marked as a duplicate of this bug. ***

I have installed 'null' today with kernel 2.4.18-11 today and the bug is still
there.

Enable numlock, press AltGR enters 0 chars.

I've installed 8.0 today and this bug is still there.

RedHat Linux 7.3 upgraded to latest available kernel (2.4.18-17.7.x) using
up2date. Same problem (using fr-latin1 layout).

*** Bug 76081 has been marked as a duplicate of this bug. ***

Changing the product to RHL 8.0.

*** Bug 74759 has been marked as a duplicate of this bug. ***

I just repeat what I say here:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=76081

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.

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...

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.

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.

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).

True enough, I didn't test it enough on the console. After some banging on AltGr
the problem reoccured on the console.

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.

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.

Greetings,
ttl

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...

greetings,
ttl

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).

Still happens with the latest kernel from updates (2.4.18-18.8.0).

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

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 :-)

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):

 void
 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
necessary.

hope this can help, because it's a really anoying bug we encounter here with a
french layout keyboard under virtual consoles.

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 "|".

Created attachment 87244 [details]
midified linux-2.4.18-speakup.patch which avoid altgr key to write a "0"

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

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 ?)

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 ???

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.

Please use the umbrella 79062 bug now to enter general comments. Thanks.

A problem report was posted to the speakup mailing list. You can read the thread
at this address:
http://speech.braille.uwo.ca/pipermail/speakup/2002-December/018724.html

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.

seems to have been corrected in kernel-2.4.18-19.8.0 from updates. don't see the
problem with that kernel.

I can not reproduce this problem with kernel-2.4.18-19.8.0 (swedish keymap)

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
persists.

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/