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 17:18:05 +0100 (CET)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Stéphane Chatty <chatty@...c.fr>
Cc:	Henrik Rydberg <rydberg@...omail.se>,
	"benjamin.tissoires Tissoires" <benjamin.tissoires@...il.com>,
	Fabien ANDRÉ <fabien.andre@...c.fr>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	USB list <linux-input@...r.kernel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/5] HID: autoload hid-multitouch as needed

On Thu, 8 Mar 2012, Stéphane Chatty wrote:

> >> I had the feeling that the current hid code was somehow trying to be
> >> universal, thus making the point moot, and figured that we would
> >> need to reintegrate hid-multitouch into hid-core at some
> >> point. You're suggesting another, more distributed option, in which
> >> new categories of HID devices appear from time to time and are
> >> handled in new modules, right? Sounds interesting to me, I'd like to
> >> hear what the original designers of the hid module think of it.
> > 
> > Me too. Reading through the module code, it really seems to put
> > userland in charge, only providing sufficient information to be able
> > to load the right modules. If this was fully possible in hid, at least
> > one of the special blacklists would disappear. One would also be able
> > to split the current hid-input into several different drivers, for
> > instance, gaining some clarity in addition to memory savings.
> 
> This would be a radical change from the current hid code that tends to 
> restrict "true hid" to a limited range of HID usages and to reject the 
> rest (cf the IS_INPUT_APPLICATION that caused us some difficulties three 
> years ago). But this definitely would make sense to me. Jiri, Dmitry, 
> what do you think?

Frankly, I'd personally love IS_INPUT_APPLICATION() to die, it's just 
horribly ugly and doesn't scale with rapidly growing number of HID devices 
appearing every day (with multitouch definitely being the most active 
group).

So restructuring a HID core in a way that makes the whole process much 
more generic and offloads the responsibility into modaliases seems like a 
proper way to go for me.

I'll be thinking about it a little bit more in the upcoming days, other 
ideas are of course very welcome.

Thanks everybody for initiating this discussion,

-- 
Jiri Kosina
SUSE Labs
--
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/