From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marvin Raaijmakers Subject: Re: [PATCH] input: change SysRq keycode for systems without SysRq key Date: Fri, 17 Aug 2007 10:25:12 +0200 Message-ID: <1187339112.3684.10.camel@localhost.localdomain> References: <469C647B.1000307@inwind.it> <469E7E29.2050206@inwind.it> <469FDA19.6020702@inwind.it> <469FF3D9.4080307@inwind.it> <20070802212730.GA10153@suse.cz> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7BIT Return-path: In-reply-to: <20070802212730.GA10153@suse.cz> Sender: owner-linux-input@atrey.karlin.mff.cuni.cz List-Help: List-Owner: List-Post: List-Unsubscribe: To: Vojtech Pavlik Cc: Jiri Kosina , federico ferri , Dmitry Torokhov , Linus Torvalds , linux-input@atrey.karlin.mff.cuni.cz, mzxrlshmm@0pointer.de List-Id: linux-input@vger.kernel.org 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.