I think that I didn't make myself clear on that... let me try to
explain on what I'm thinking to do. Let's take as example Dan's driver
at http://prdownload.berlios.de/dpfp/dpfp-driver-0.1.2.tar.bz2.
On our usb_device_id, we specify the vendor of the device, etc. We
could also (I don't know if this is the best place to do that) specify
which kind of device is it (printer, storage, fingerprint reader, HID,
etc). Let's suppose that we have some #define's or a enum that specify
the hundreds of different device types (is that possible ? :) Nothing
that a USB_GENERIC can't solve lol).
enum usb_device_type {
USB_DEVICE_SCANNER,
USB_DEVICE_KEYBOARD,
USB_DEVICE_MOUSE,
USB_DEVICE_FINGERPRINT_READER,
USB_DEVICE_GENERIC,
...
};
For each device, he have some kind of struct that is complex enough to
describe characteristics of each device, at least the most common
ones. So, for USB_DEVICE_FINGERPRINT_READER, we could have:
#define FINGEPRINT_IMAGE_JPG 0
#define FINGEPRINT_IMAGE_PNM 1
#define FINGEPRINT_IMAGE_BMP 2
#define FINGEPRINT_IMAGE_RAW 3
struct usb_devcap_fingerprint_reader {
unsigned int width;
unsigned int height;
unsigned int colors;
unsigned char cap_encrypted_output;
unsigned char image_type; /* FINGEPRINT_IMAGE_PNM */
};
(I know, this sucks, but you got the idea).
So our usb_device_id array could also include the kind of device and a
pointer to our structure describing the device capabilities, something
like:
static struct usb_devcap_fingerprint_reader
usb_devcap_fingerprint_reader_mskeyboard = {
.width = 100,
.height = 100,
.colors = 2,
.cap_encrypted_output = 0,
.image_type = FINGEPRINT_IMAGE_BMP,
}
static struct usb_device_id dpfp_table[] = {
{
/* Microsoft Keyboard with Fingerprint reader */
USB_DEVICE(0x045e, 0x00bb),
.driver_info = DPFP_TYPE_URU4000B,
USB_DEVICE_FINGERPRINT_READER,
(usb_devcap_fingerprint_reader *) usb_devcap_fingerprint_reader_mskeyboard,
},
{} /* terminating null entry */
};
So, to know each fingerprint reader device (if any) and its
capabilities, we could have a directory like /dev/usb/fingerprint
where we could iterate and access the device thru
/dev/usb/fingerprint/fingerprint0. Opening a fd to this device and
issuing a ioctl(), we could have a usb_devcap_fingerprint_reader-like
structure on userspace filled in with the device's capabilities, so we
would know exactly what to expect when doing a cat
/dev/usb/fingerprint/fingerprint0 > /tmp/catchme.bmp.
I think that the most difficult part would be summarize the thousands
of different devices and their capabilities in a struct ()... but I
also think that this stuff is needed, and should be kept by the
kernel, and not some lib in userspace...
Daniel
--
What this world needs is a good five-dollar plasma weapon.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]