linux-kernel - Re: [DOC] The documentation for HID Simple Driver Interface 0.5.0

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:	Tue, 6 Mar 2007 14:47:11 +0100 (CET)
From:	Jiri Kosina <jikos@...os.cz>
To:	Marcel Holtmann <marcel@...tmann.org>
cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Li Yu <raise.sail@...il.com>,
	Greg Kroah Hartman <greg@...ah.com>,
	linux-usb-devel <linux-usb-devel@...ts.sourceforge.net>,
	LKML <linux-kernel@...r.kernel.org>,
	Vincent Legoll <vincentlegoll@...il.com>,
	"Zephaniah E. Hull" <warp@...allh.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Harold Sargeant <harold-sargeant@...world.com>,
	liyu <liyu@...ss.com.cn>
Subject: Re: [DOC] The documentation for HID Simple Driver Interface 0.5.0

On Mon, 5 Mar 2007, Marcel Holtmann wrote:

> no, because if I recall correctly these are the boot mode drivers and 
> actually not used at all in any modern distribution.

That's correct.

> For me the task of converting HID reports into input events shouldn't be 
> actually the job of the HID core layer. My understanding is that the HID 
> core should support multiple transport layers. This is currently 
> achieved through the hid_device abstraction and used by the USB and by 
> the Bluetooth subsystem. This is the lower interface to HID. On the 
> upper interface I like to see a driver like interface. So we can 
> register specific drivers that can handle specific use cases or vendor 
> specific reports. 

This I completely agree with, and have this on my TODO for quite a long 
time. If Li Yu would like to spend some time on it, it certainly would 
help. The current "simple HID interrface" is a suitable workaround for 
various buggy/broken/nonstandard hardware which is currently not handled 
by the HID kernel code properly, but it's definitely not a long-term 
solution that should go to mainline.

> For standard keyboard and mouse reports we however should have a 
> standard driver that can handle most of them.

Unfortunately there is a non-trivial bunch of hardware that pretends to be 
standard keyboard/mouse, but behaves badly. Last week I had to do 
workaround for Logitech S510, which seems to generate usages far above the 
logical maximum specified in report descriptor, to give one example.

So we will probably end up with many small driver for exotic pieces of 
hardware being registered to the hid bus. But this is definitely much 
better than the current mess of hid quirks.

On Mon, 5 Mar 2007, Dmitry Torokhov wrote:

> We are running out if quirks and we can't continue in this fashion so Li 
> tried to provide mechanism to augment default HID behaviour for sepcific 
> devices. 

That's right. We could always extend the quirks so that it's long long, or 
something like that, but this is also not sustainable in the long term.

-- 
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/