linux-kernel - Re: [linux-usb-devel] [RFC] HID bus design overview.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0704010002280.6040@jikos.suse.cz>
Date:	Sun, 1 Apr 2007 00:49:26 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Dmitry Torokhov <dtor@...ightbb.com>
Cc:	Li Yu <raise.sail@...il.com>, yanghong@...ss.com.cn,
	linux-usb-devel <linux-usb-devel@...ts.sourceforge.net>,
	hongzhiyi@...ss.com.cn, Marcel Holtmann <marcel@...tmann.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [linux-usb-devel] [RFC] HID bus design overview.

On Fri, 30 Mar 2007, Dmitry Torokhov wrote:

> There should be one device and your driver should simply do:
> static void my_driver_hid_event(struct hid_device *hid, struct hid_field *field,
> 				struct hid_usage *usage, __s32 value)
> {
> 	if (special_processing_needed(usage)) {
> 		do_special_processing(...);
> 		input_event(field->hidinput->input, XXX, YYY, ZZZ);
> 		...
> 
> 	} else
> 		hidinput_hid_event(hid, field, usage, value);
> }

Hi,

in fact I am not entirely sure that the specialized drivers hooked to the 
HID bus should be passed individual fields/usages by the generic HID 
driver. That would imply that generic HID layer would have to parse the 
received report using information retrieved from the report descriptor of 
the device. But this is in some way in contrary to one of the features 
this effort should be heading to, isn't it? We want to provide means how 
to bypass possible errors in HID descriptor of the device (or do any other 
possible quirky handling) - we want to be able to allow for completely 
different interpretation of fields than the generic HID parser would do, 
right?

So I guess the above should rather be

static void my_driver_hid_report(struct hid_device *hid, u8 *data, 
				 int size)
{
      if (special_processing_needed(data)) {
              do_special_processing(...);
              input_event(field->hidinput->input, XXX, YYY, ZZZ);
              ...
      } else
              hid_input_report(hid, data, size);
}

Such driver will register itself onto a HID bus. Both USB and BT 
transports could provide VID and PID which could then be easily matched 
against by the bus code to easily check whether processing by specialized 
driver is needed or handling by (existing) generic HID layer is enough.

As an added value, hooking the hidraw code to this architecture would then 
be rather a trivial task.

Thanks,

-- 
Jiri Kosina
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/