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]

Date:	Mon, 2 Apr 2007 11:37:47 +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>,
	Robert Marquardt <marquardt@...emercs.com>
Subject: Re: [linux-usb-devel] [RFC] HID bus design overview.

On Mon, 2 Apr 2007, Dmitry Torokhov wrote:

> > 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);
> > }
> > 
> Well, this of course is most flexible, however I think that for most
> drivers hooking into parsed data would be much easier. That means that
> we need to allow defining 2 hooks - one for raw data and another for
> parsed reports and let drivers decice which one they want to use.

I agree. I am aware of devices for which just inspecting the parsed data 
would be OK (some keyboards with usage mappings which are not defined by 
HUT, for example), but also of devices which require special handling on 
the report level - Robert Marquardt pointed me in a private mail to a few 
devices which are broken par-excellence, and for which handling on report 
level would be convenient.

Also, handling on report level would be nice to have so that we could hook 
a hidraw driver to it.

Li, would this be OK by you?

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/