Bug 181457

Created attachment 124611 [details]
nosoftrepeat patch to atkbd.c

Increasing severity as this is critical for Dell. We expect this patch to be in U4.

Firstly, this seems too much of an ad-hoc approach. It would be much better
(long term) not to add knobs, but to take off some signature of DRAC3.
Please attach a dmesg for starters (I may request necessary files from
the /sys/devices/platform/* later).

Also, what is the upstream status of this? Did Dell try to contact Dmitry
and/or Vojtech on this topic? Do you want us to liason with them?

Let me explain the problem in more detail.

Dell's DRAC3 stuffs keystrokes into the 8042 keyboard controller, so that, to 
the system, it looks like keystrokes are coming in from the main PS/2 
keyboard.  It was done that way because USB keyboard support wasn't ubiquitous 
when the DRAC3 was designed.  However, the DRAC3 card does NOT fully emulate a 
keyboard.  This causs a problem on systems that have no real keyboard plugged 
in, since atkbd probes for the keyboard, and won't take control of the port if 
it doesn't see one.

To get around this issue, we tell users to use the "i8042.dumbkbd=1" kernel 
command line option.  This causes the port not to have a "serio->write" 
function, so atkbd skips the keyboard probe and just takes control of the 
port.  That was fine in RHEL3.

However, at some point in the 2.6 kernel, the atkbd driver was changed, so that 
it now turns on "atkbd_softrepeat" if there's no "write" function (i.e., if 
the "i8042.dumbkbd=1" option was used).  Presumably, this was done on the 
assumption that any "dumb" keyboard wouldn't auto repeat by itself--but this 
isn't the case here.

With softrepeat on, the atkbd driver will auto-repeat a key that has been held 
down for (a hired-coded value of) 250ms.

Our DRAC3 firmware and/or remote console Java client causes keystrokes from the 
DRAC3 to appear to be held down for 500ms.  So, you can't just type one of 
anything... every time you hit a key, you get lots of them.

We have provided a DKMS driver for customers to use for now, but we (and our 
customers) are very eager to get this patch into RHEL4 U4 so that the extra 
driver is not necessary.  This patch adds an option that would only be required 
for people running older Dell hardware (with DRAC3 hardware), RHEL4, and no 
physical keyboard.

We thought this would be the best way to work around this issue, since it adds 
very little code and very little risk, so we could get it in quickly.

If you still want to see dmesg, any sysfs files, or you have any other 
questions, please ask.  I don't think there's much to see in dmesg.  If you 
have a better idea for a workaround or fix, please feel free to suggest that, 
as well.

This has not been sent upstream (yet).

Thanks!

This makes complete sense, thank you, Stuart. Let me pass it by upstream (Dmitry),
and then I post it for the inside review.

The main concern here is, it's a pain to add new variables, get them documented
in 65 languages, then remove them again if upstream changes. Better do it once.

Regarding the comments from Dmitry & Vojtech--"kbdrate -d 1000" isn't a good 
workaround, because sometimes the DRAC3 will take longer than 1s to deliver 
keyboard events.  It worked for me in the lab, but our product support folks 
tried this earlier and found that it was not a robust workaround.  (This 
doesn't make DRAC3 as unusable as it sounds--it will deliver multiple keyboard 
events when it does get around to delivering them.)

And I don't think that the /sys/bus/serio/devices/serioX/softrepeat interface 
is present in RHEL4.  Although--if that is in the latest kernel.org kernel, we 
wouldn't have to push this patch upstream, though we still need some sort of 
fix in RHEL4.

Stuart, it would be better if you sent these comments to the thread instead
of posting to Bugzilla. I haven't posted anything because the public discussion
is not over, so there's no summary yet.

Created attachment 125071 [details]
Candidate #2 - Vojtech's alternative

From: Vojtech Pavlik <vojtech>
To: dtor_core
Cc: Pete Zaitcev <zaitcev>, linux-kernel.org,
stuart_hayes
Subject: Re: Suppressing softrepeat
Date: Wed, 22 Feb 2006 23:09:54 +0100

> I am not keen on changing the default behaviour... How many dumb
> keyboards are out there?

Apart from the DRAC3, some home-made Sun-to-PS2 converter, and a single
non-x86 embedded box, I don't recall anything. Answer: very few.

There may be users, though, that use this option to force the detection
of the keyboard when not really plugged in, eg. for flaky KVMs. I've
Googled for that usage, but found none.

Stuart, have you reviewed Vojtech's altrnative (attached to this bug)? Comments?
Have you commented back on the thread?

Pete, any resolution yet? Can we get something implemented for U4?

I did look at it when he sent it--I think it's perfect!  Thanks.  

This issue is on Red Hat Engineering's list of planned work items 
for the upcoming Red Hat Enterprise Linux 4.4 release.  Engineering 
resources have been assigned and barring unforeseen circumstances, Red 
Hat intends to include this item in the 4.4 release.

committed in stream U4 build 34.17. A test kernel with this patch is available
from http://people.redhat.com/~jbaron/rhel4/

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2006-0575.html