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]

Message-Id: <1173207440.11247.24.camel@aeonflux.holtmann.net>
Date:	Tue, 06 Mar 2007 19:57:20 +0100
From:	Marcel Holtmann <marcel@...tmann.org>
To:	Jiri Kosina <jikos@...os.cz>
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

Hi Jiri,

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

my point is basically that we shouldn't waste any effort on a simple
driver while we actually need a generic driver interface. This generic
interface might be look simple and stupid in the beginning, but it can
easily grow over time. With this interface of course we need the concept
of a HID bus.

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

Maybe the report descriptor is broken. I have some Bluetooth HID where
they actually byte-swapped values and it totally confused the report
descriptor parser. For some devices it might be better to actually patch
the report descriptor instead of adding quirks to the HID core.

Regards

Marcel


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