linux-kernel - Re: [PATCH 4/5] HID: autoload hid-multitouch as needed

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, 12 Mar 2012 21:47:19 +0100
From:	Stéphane Chatty <chatty@...c.fr>
To:	Marcel Holtmann <marcel@...tmann.org>
Cc:	Jiri Kosina <jkosina@...e.cz>,
	Henrik Rydberg <rydberg@...omail.se>,
	"benjamin.tissoires" <benjamin.tissoires@...il.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	"Gustavo F. Padovan" <padovan@...fusion.mobi>,
	linux-bluetooth@...r.kernel.org
Subject: Re: [PATCH 4/5] HID: autoload hid-multitouch as needed


Hi Marcel and Jiri

> Hi Jiri,
> 
>>>> What if we were to change the definition of a HID device on the
>>>> modalias level?
>>>> 
>>>> In practise, a HID device can be either an usb device, a hid device,
>>> 
>>> Just to be sure: do you mean "bluetooth device"? or is there such a 
>>> thing as a hid device per se? I'm asking because I've always been 
>>> surprised at seeing usbhid/ in hid/, which kind of breaks the potential 
>>> symmetry between USB and Bluetooth wrt hid.
>> 
>> Please don't get confused by the directory layout ... this has mostly 
>> non-technical reasons -- Marcel wanted to keep bluetooth/hidp under his 
>> wings, and I didn't have reasons to object strongly.
>> 
>> I am adding Marcel and Gustavo to CC just in case they have changed their 
>> mind, but it's definitely a side-topic in this discussion.
> 
> I have not changed my mind. HIDP is Bluetooth specific and should stay
> there. Especially since we are currently discussing changes to make
> things also work over Bluetooth Low Energy (LE), but that is a complete
> different topic and it just started.

Just in case it makes a difference, I knew nothing about HIDP when I wrote the message above. My point was rather that hid looks like a bus to which several transport layers can connect (USB, Bluetooth, ZigBee, etc), and that having USB-specific code in hid/ (as opposed to having it in usb/) seems biased towards USB. I was (and am still) wondering how much it limits future uses of the hid core by making it USB-dependent.

In other words: is the hid core generic enough or are there steps to take to make it more generic wrt transport layers? If we are talking about restructuring parts of it, this seems like the right time to ask :-)

Cheers,

St.

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