What's the current state of this patch?
- Marvin Raaijmakers
On Thu, 2007-08-02 at 23:27 +0200, Vojtech Pavlik wrote:
> On Mon, Jul 30, 2007 at 04:09:04PM +0200, Jiri Kosina wrote:
> > **
> > diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> > index 7f81789..c604a1d 100644
> > --- a/drivers/hid/hid-input.c
> > +++ b/drivers/hid/hid-input.c
> > @@ -818,6 +818,11 @@ static void hidinput_configure_usage(struct hid_input
> > *hidinput, struct hid_fiel
> > field->dpad = usage->code;
> > }
> >
> > + if (usage->type == EV_KEY) {
> > + set_bit(EV_MSC, input->evbit);
> > + set_bit(usage->code, input->mscbit);
>
> Should be set_bit(MSC_SCAN, input->mscbit);
>
> > + }
> > +
> > hid_resolv_event(usage->type, usage->code);
> > #ifdef CONFIG_HID_DEBUG
> > printk("\n");
> > @@ -908,6 +913,9 @@ void hidinput_hid_event(struct hid_device *hid, struct
> > hid_field *field, struct
> > if ((usage->type == EV_KEY) && (usage->code == 0)) /* Key 0 is
> > "unassigned", not KEY_UNKNOWN */
> > return;
> >
> > + if (usage->type == EV_KEY)
> > + input_event(input, EV_MSC, MSC_SCAN, usage->hid);
> > +
> > input_event(input, usage->type, usage->code, value);
> >
> > if ((field->flags & HID_MAIN_ITEM_RELATIVE) && (usage->type == EV_KEY))
>
> If you look back through the history of hid-input.c, you'll see that
> very much this usage reporting was already in there and was removed
> later because of excessive number of events generated.
>
> It was partly because I didn't limit the usage reporting to keys, for
> the sake of genericity.
>
> > There is an slight issue with this patch though. Imagine you have such a
> > keyboard that sends in one field the status of Caps/Num/Shift/etc and in
> > another field the pressed key(s) itself, i.e. something like this:
> >
> > INPUT[INPUT]
> > Field(0)
> > Usage(8)
> > Keyboard.00e0
> > Keyboard.00e1
> > Keyboard.00e2
> > Keyboard.00e3
> > Keyboard.00e4
> > Keyboard.00e5
> > Keyboard.00e6
> > Keyboard.00e7
> > Logical Minimum(0)
> > Logical Maximum(1)
> > Report Size(1)
> > Report Count(8)
> > Report Offset(0)
> > Flags( Variable Absolute )
> > ...
> >
> > and then the next field is used to transfer the actual keys. Therefore,
> > with this patch, hid-input sees a report containing usages e0-e7 set to
> > zero (when no caps/num/shift/... was pressed). This results in evtest
> > seeing this (with the patch below applied) for a single keypress:
> >
> > Event: time 1182930853.026146, type 4 (Misc), code 4 (ScanCode), value 700e0
> > Event: time 1182930853.026159, type 4 (Misc), code 4 (ScanCode), value 700e1
> > Event: time 1182930853.026168, type 4 (Misc), code 4 (ScanCode), value 700e2
> > Event: time 1182930853.026178, type 4 (Misc), code 4 (ScanCode), value 700e3
> > Event: time 1182930853.026187, type 4 (Misc), code 4 (ScanCode), value 700e4
> > Event: time 1182930853.026197, type 4 (Misc), code 4 (ScanCode), value 700e5
> > Event: time 1182930853.026206, type 4 (Misc), code 4 (ScanCode), value 700e6
> > Event: time 1182930853.026216, type 4 (Misc), code 4 (ScanCode), value 700e7
> > Event: time 1182930853.026227, type 4 (Misc), code 4 (ScanCode), value 70004
> > Event: time 1182930853.026233, type 1 (Key), code 30 (A), value 1
> > Event: time 1182930853.026237, -------------- Report Sync ------------
> > Event: time 1182930853.114137, type 4 (Misc), code 4 (ScanCode), value 700e0
> > Event: time 1182930853.114150, type 4 (Misc), code 4 (ScanCode), value 700e1
> > Event: time 1182930853.114160, type 4 (Misc), code 4 (ScanCode), value 700e2
> > Event: time 1182930853.114169, type 4 (Misc), code 4 (ScanCode), value 700e3
> > Event: time 1182930853.114179, type 4 (Misc), code 4 (ScanCode), value 700e4
> > Event: time 1182930853.114188, type 4 (Misc), code 4 (ScanCode), value 700e5
> > Event: time 1182930853.114198, type 4 (Misc), code 4 (ScanCode), value 700e6
> > Event: time 1182930853.114207, type 4 (Misc), code 4 (ScanCode), value 700e7
> > Event: time 1182930853.114218, type 4 (Misc), code 4 (ScanCode), value 70004
> > Event: time 1182930853.114223, type 1 (Key), code 30 (A), value 0
> > Event: time 1182930853.114227, -------------- Report Sync ------------
> >
> > I don't think this is what you want. We could alternatively for example
> > remember all the previous states of all the KEY controls and report
> > scancodes only of those which got changed, this would solve this issue.
> > **
> >
> > However, this might look like an overhead.
>
> Well, the input subsystem knows whether a key state report will be
> forwarded or not. Maybe we could (ab)use the knowledge.
