[lkml]   [2003]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Input issues - key down with no key up
On Fri, Aug 15, 2003 at 02:36:41PM +0200, Andries Brouwer wrote:
> On Fri, Aug 15, 2003 at 12:58:02PM +0200, Vojtech Pavlik wrote:
> > > > I have a notebook (Dell Latitude D800) which has some keys (actual
> > > > fn+something combinations) that generate Down events but no Up events
> > > > (clever, isn't it).
> > > > This makes those keys unusable with 2.6.0 as it is
> > > I think we should go for the simple fix: only enable the timer-induced
> > > repeat when the user asks for that (say, by boot parameter).
> > > The keyboard already knows which keys repeat and which don't.
> > That won't solve it - the key, while not repeating would be still
> > considered 'down' by the kernel and any more pressing of the key
> > wouldn't do anything.
> Yes, it would still be considered down. But that does not imply
> that pressing it doesnt do anything. It is up to the driver
> to discard key presses, and I think it shouldnt.
> (Unless of course the user asks for that behaviour - it may be required
> on some broken laptops.)
> Just the simple: a keypress generates an interrupt and we see a keystroke.
> Use a kernel timer only when we know or the user tells us that it is needed.
> Not in the default situation.

I'm not very fond of making special exception for the (hopefully soon to
be doing) PS/2 genre of keyboards. For USB for example you don't get an
interrupt and a scancode per keypress. You get the current keyboard
state. So I prefer to keep the keyboard state in the kernel, too, since
that is a model that fits more devices. Also not just keyboards.

> > My proposed solution is to do an input_report_key(pressed) immediately
> > followed by input_report_key(released) for these keys straight in
> > atkbd.c. Possibly based on some flag in the scancode->keycode table for
> > that scancode.
> But that would require users to report on precisely which keys are affected
> and would give complications where I suppose 2.4 did not have any.
> This is the way towards an ever more complicated keyboard driver.
> Not what you would want.

I definitely want one single driver being more complicated than the core
getting more complicated.

Vojtech Pavlik
SuSE Labs, SuSE CR
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:47    [W:0.128 / U:0.700 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site