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] [day] [month] [year] [list]

Message-ID: <4609CBC5.4080208@gmail.com>
Date:	Wed, 28 Mar 2007 09:58:29 +0800
From:	Li Yu <raise.sail@...il.com>
To:	Marcel Holtmann <marcel@...tmann.org>
CC:	Li Yu <raise.sail@...il.com>, hongzhiyi@...ss.com.cn,
	Jiri Kosina <jkosina@...e.cz>,
	linux-usb-devel <linux-usb-devel@...ts.sourceforge.net>,
	yanghong@...ss.com.cn, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [linux-usb-devel] [RFC] HID bus design overview.

Marcel Holtmann wrote:
> please don't take the transport layers into account when designing the
> HID bus. They have nothing to do with the upper layer. Especially the
> upper layer shouldn't care at all if the actual HID reports are sent
> over USB or Bluetooth.
>
>   
I am sorry for I see this mail so later.

I also sense this. we may need not such a complete layer at all. Although the work of hiddev/rawdev support does not begin, however, as the design, especially, let hiddev/rawdev live in HIDAL, I think this may need a bit of abstract of transport layer.

> The transport drivers (usbhid and hidp) will only communicate with the
> HID core and for the bus it makes no difference. The current abstraction
> for HID transports works pretty fine and there is no need to change
> this.
>
>   
Nod. HIDAL should not care which transport layer works under it. if so, that is not HIDAL, that is HIDBL(HID Branch instruction Layer) instead of. :D

> I think that a HID bus driver should be able register to a specific HID
> report for a specific device. This would allow to have a generic driver
> that can handle all common keyboard and mouse functionality and then in
> addition a specific driver that handles vendor specific reports. It
> might also make sense to let the driver match on specific HUT codes.
>
>   
In current development implementation, the match process still can work in traditional Vendor ID/Product ID way, but it do not reject other means. If the author of driver hope to match for specific HID report, just do it. In fact, the HIDAL only know the result of match process, not how to do it.I think your "generic driver" is same with my "fundamental driver", and "specific driver" is same with "shadow driver" too.

Er, What's mean of your "HUT", HID Usage Table? if so, I think I have already explained we can do it.However, we should supply some convenient API for this work. or HIT is other mysterious thing? ;)

> Regards
>
> Marcel
>
>
>   
Progress: It seem the shadow basic support works! but It still need more tests.

Good luck.

- Li Yu

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