In message <[EMAIL PROTECTED]> you write:
>although it has a little problem with hid.c in 2.4.3 ac patches
>(maybe all 2.4.3 - I didn't check).
I've used it with 2.4.3 proper, and the patch applied silently, and
the code works with my APC UPS. I'll pick up the ac patched version
and figure this out.
>It works pretty well, although the ioctl()s are a bit confusing -
>possibly because I am not so strong on HID reports and usage etc.
>The ups.c example allowed me to make a few examples, which I will
>make into a programmers guide for hiddev if it gets into the kernel.
Let me know if you have any questions about usage. The API explicitly
tries not to mask the underlying HID abstractions.
>Which brings me to the big question. Is there any reason why this
>can't go into the kernel? It (or something equivalent) would appear
>to be needed to support user space power device and monitor device
>drivers (and maybe PID), and I think that power
>(http://www.usb.org/developers/data/devclass/pdcv10.pdf) and monitor
>(http://www.usb.org/developers/data/devclass/usbmon10.pdf) classes
>should be in user space. It may also be needed for Point of Sale
>devices - I don't know how that is going.
I thought it might be nice if it was in the kernel. :-) I've had
someone developing point-of-sale drivers drop me a line saying they'd
picked up the code.
>As a side benefit, it may be possible to modify the behaviour so
>that every HID device gets attached to a hiddev device, and then we
>can make USBView (http://www.kroah.com/linux-usb/) also display HID
>descriptors.
I've been faily careful so far not to stomp on Vojtech toes with my
changes, but yes, one could easily imagine even "input" HID devices
with at least informational support.
>I am currently looking at making an interface for NUT
>(http://www.exploits.org/nut/) to handle the UPS. However the
>interface driver is dead without the kernel support. So I'd really
>like to know what the future holds for this.
>
>Any objections for someone making a patch for Alan Cox for the -ac
>patches? Do you want me to do it?
While the threads on this were active, Vojtech sounded positive on
picking up the patch. I'm not sure what the tradeoffs are (technical
or otherwise) to your doing it versus Vojtech, and what his current
take on his time availability / willingness. My stance is that I'd
like to get things to a point where I'm not tracking patches to
kernel versions. If you know how to have that happen (and there are
no objections) I'd say go for it.
The usb-devel folks have, from time to time, thrashed back and forth
on how much USB support should be in the kernel. I've seen arguments
ranging as far as saying that the devio stuff should be enough to
operate HID devices, and everything below that should be done in shared
library APIs. Since there's a reasonable amount of effort and traffic
involved in enumeration of the device HID usage table, I'd claim that
it would be better for the kernel to deal with this (in the way that
hid/hiddev currently works), so a device isn't probed for this
information every time there is user code that's curious about what
devices are on the bus.
--
Paul
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
