detecting when keys are being pressed on a keyboard

detecting when keys are being pressed on a keyboard

[Oliver Neukum]

Hi,

I got the strange case of a keyboard going into autosuspend while a key
was being pressed. The key release never arrived and I had to unplug
the keyboard to get the key unstuck. Is there a clean way to learn from
hid-core.c if a keyboard has keys pressed?

	Regards
		Oliver

Re: detecting when keys are being pressed on a keyboard

[Jiri Kosina]

On Fri, 21 Sep 2007, Oliver Neukum wrote:

> I got the strange case of a keyboard going into autosuspend while a key 
> was being pressed. The key release never arrived and I had to unplug the 
> keyboard to get the key unstuck. Is there a clean way to learn from 
> hid-core.c if a keyboard has keys pressed?

Hi Oliver,

HID doesn't keep any permanent state by itself. If you want to know 
whether a given key is currently pressed or not, you'd have to inspect the 
bitfields inside input_dev*, I am afraid.

-- 
Jiri Kosina

Re: detecting when keys are being pressed on a keyboard

[Oliver Neukum]

Am Freitag 21 September 2007 schrieb Jiri Kosina:
> On Fri, 21 Sep 2007, Oliver Neukum wrote:
> 
> > I got the strange case of a keyboard going into autosuspend while a key 
> > was being pressed. The key release never arrived and I had to unplug the 
> > keyboard to get the key unstuck. Is there a clean way to learn from 
> > hid-core.c if a keyboard has keys pressed?
> 
> Hi Oliver,
> 
> HID doesn't keep any permanent state by itself. If you want to know 
> whether a given key is currently pressed or not, you'd have to inspect the 
> bitfields inside input_dev*, I am afraid.

I see no way to do this without a race condition. The field isn't locked
as far as I can tell.
Secondly, what is to happen in case of a system wide suspend? Will
the system wake up thinking that the key is still pressed?

	Regards
		Oliver

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] detecting when keys are being pressed on a keyboard

[Dmitry Torokhov]

Hi Oliver,

On 9/24/07, Oliver Neukum <oliver@neukum.org> wrote:
> Am Freitag 21 September 2007 schrieb Jiri Kosina:
> > On Fri, 21 Sep 2007, Oliver Neukum wrote:
> >
> > > I got the strange case of a keyboard going into autosuspend while a key
> > > was being pressed. The key release never arrived and I had to unplug the
> > > keyboard to get the key unstuck. Is there a clean way to learn from
> > > hid-core.c if a keyboard has keys pressed?
> >
> > Hi Oliver,
> >
> > HID doesn't keep any permanent state by itself. If you want to know
> > whether a given key is currently pressed or not, you'd have to inspect the
> > bitfields inside input_dev*, I am afraid.
>
> I see no way to do this without a race condition. The field isn't locked
> as far as I can tell.

You can take input_dev->event_lock to stop event from propagating
through input core while you are evaluating the bits. Input lcoking
changes are im -mm and will be merged into 2.6.24.

> Secondly, what is to happen in case of a system wide suspend? Will
> the system wake up thinking that the key is still pressed?
>

For now it will but it is about to change. Input device will send
'release' events for all pressed keys from their suspend method.

-- 
Dmitry

Re: [linux-usb-devel] detecting when keys are being pressed on a keyboard

[Oliver Neukum]

Am Montag 24 September 2007 schrieb Dmitry Torokhov:
> Hi Oliver,
> 
> On 9/24/07, Oliver Neukum <oliver@neukum.org> wrote:
> > Am Freitag 21 September 2007 schrieb Jiri Kosina:

> > > Hi Oliver,
> > >
> > > HID doesn't keep any permanent state by itself. If you want to know
> > > whether a given key is currently pressed or not, you'd have to inspect the
> > > bitfields inside input_dev*, I am afraid.
> >
> > I see no way to do this without a race condition. The field isn't locked
> > as far as I can tell.
> 
> You can take input_dev->event_lock to stop event from propagating
> through input core while you are evaluating the bits. Input lcoking
> changes are im -mm and will be merged into 2.6.24.

Hi Dmitry,

I was thinking about a second approach. As all keypresses run through
the interrupt handlers of the hid driver, how about checking the bit field
in the interrupt handler after calling hid_input_report() ?

	Regards
		Oliver

Re: [linux-usb-devel] detecting when keys are being pressed on a keyboard

[Dmitry Torokhov]

On 9/24/07, Oliver Neukum <oliver@neukum.org> wrote:
> Am Montag 24 September 2007 schrieb Dmitry Torokhov:
> > Hi Oliver,
> >
> > On 9/24/07, Oliver Neukum <oliver@neukum.org> wrote:
> > > Am Freitag 21 September 2007 schrieb Jiri Kosina:
>
> > > > Hi Oliver,
> > > >
> > > > HID doesn't keep any permanent state by itself. If you want to know
> > > > whether a given key is currently pressed or not, you'd have to inspect the
> > > > bitfields inside input_dev*, I am afraid.
> > >
> > > I see no way to do this without a race condition. The field isn't locked
> > > as far as I can tell.
> >
> > You can take input_dev->event_lock to stop event from propagating
> > through input core while you are evaluating the bits. Input lcoking
> > changes are im -mm and will be merged into 2.6.24.
>
> Hi Dmitry,
>
> I was thinking about a second approach. As all keypresses run through
> the interrupt handlers of the hid driver, how about checking the bit field
> in the interrupt handler after calling hid_input_report() ?
>

That should work as well I think.

-- 
Dmitry

Re: detecting when keys are being pressed on a keyboard

[Jiri Kosina]

On Mon, 24 Sep 2007, Oliver Neukum wrote:

> > HID doesn't keep any permanent state by itself. If you want to know 
> > whether a given key is currently pressed or not, you'd have to inspect 
> > the bitfields inside input_dev*, I am afraid.
> I see no way to do this without a race condition. The field isn't locked
> as far as I can tell.

Hi Oliver,

Dmitry (CC added) has been doing a lot of rework of locking in input as 
far as I know. He would know this better.

> Secondly, what is to happen in case of a system wide suspend? Will
> the system wake up thinking that the key is still pressed?

If the release event didn't happen before the machine went to suspend, I'd 
say so.

-- 
Jiri Kosina

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] detecting when keys are being pressed on a keyboard

[Oliver Neukum]

Am Montag 24 September 2007 schrieb Dmitry Torokhov:
> > I was thinking about a second approach. As all keypresses run through
> > the interrupt handlers of the hid driver, how about checking the bit field
> > in the interrupt handler after calling hid_input_report() ?
> >
> 
> That should work as well I think.
> 

Thanks, I'll try that.

	Regards
		Oliver