Em Mon, 3 Aug 2009 11:01:56 -0500 (CDT) Theodore Kilgore <kilgota@xxxxxxxxxxxxxxxxxxxxxx> escreveu: > On Mon, 3 Aug 2009, Jean-Francois Moine wrote: > > > On Sun, 2 Aug 2009 14:12:28 -0500 (CDT) > > Theodore Kilgore <kilgota@xxxxxxxxxxxxxxxxxxxxxx> wrote: > > > > [snip] > >>> - as there is only one vend:prod, one line is enough in gspca.txt. > >> > >> This is a question about which I have been curious for quite some > >> time, and I think that now is a good time to ask it. > >> > >> Just what policy do we have about this? The information which links > >> brand and model to driver ought to be presented somewhere. If it does > >> not go into gspca.txt then where exactly is the appropriate place to > >> put said information? > > [snip] > > > > Hi Theodore, > > > > gspca.txt has been defined only to know which subdriver has to be > > generated for a webcam that a user already owns. > > > > The trade name of the webcams are often not clear enough (look at all > > the Creative varieties). So, the user has just to plug her webcam and > > with the vend:prod ID, she will know which driver she has to generate > > So, from this the general advice to users is > > 1. Buy a camera > 2. Plug it in to see if it has a driver? > > > (you may say that there are already tools which do the job, as easycam, > > but I do not think they are often used). > > The problem is, the USB ID (and hence the driver) are not publicized by > anyone connected to the manufacturer or the retailer. So the result is > that there is a lot of hardware out there which is is currently unusable > and nobody knows that, and also lots of hardware out there which is > perfectly usable because we already supported it, but again nobody knows > that. The corollary is that the "trade names" you refer to ought to be > listed _somewhere_ as completely, clearly, and precisely as possible. To > me, and obviously good place to start with that would be to list somewhere > in the kernel documentation the devices supported by a given driver or > module. > > > > > > The device list of the other drivers (CARDLIST.xx) are not sorted and > > their format (numbered list) does not facilitate this job. So, I > > prefered a list sorted by vend:prod. > > > > In gspca.txt, the 3rd column contains the webcam names. As you can see, > > it is a comma separated list, so, you may put here all the names you may > > know. But, is it useful? > > I would certainly hope so. Otherwise, why bother to put any names in there > at all? > > > I think that the webcam names should be only > > in the file usb.ids which comes with the usbutils. > > That file is hopelessly out of date, by definition, and occasionally > seems to me inaccurate in such details as ownership of USB ID X by > company Y, for which, for example, see the association of 0x2770 (S&Q > Technologies) to the Japanese camera and electronics packager and > retailer NHL. > > More relevant to the present discussion, though, is that even if the > usb.ids file were completely up to date it serves an entirely different > purpose from what we are discussing here. My understanding is that the > usb.ids file is supposed to be nothing but an inventory of the devices > that we know about. It was never intended as a list of supported devices > and by its nature can not serve that purpose simultaneously. Also, a lot > of USB devices come under the category of "who cares what the Vendor and > Product number are?" such as standard mass storage pocket flash drives. So > I suspect that no one is conscientious about listing them. > > > > > To go further, there should be a general file which should contain all > > the usb (and pci) devices and their associated drivers. This > > information exists in /lib/modules/`uname -r`/modules.usbmap when all > > drivers are generated. So, we just need a tool (and a guy!) to maintain > > this general file... > > Hmm. Yes. The "guy." Well, it is better to figure out a way to make > things like that happen automatically, and then one does not need to worry > so much about the "guy." I will mention how Gphoto handles this problem, > for comparison. It might not be so easy to carry out here, because what > finally comes is the command option gphoto2 --list-cameras. That command > will print out a (very long) list of all the currently nsupported cameras, > by name. At this point, the list has over 1000 entries. It is up to the > writer of the camera library to list the cameras which are supported by > that particular piece of software. So the entry instead of just looking > like this > > /* Table of supported USB devices */ > static const __devinitdata struct usb_device_id device_table[] = { > {USB_DEVICE(0x2770, 0x905c)}, > {USB_DEVICE(0x2770, 0x9050)}, > {USB_DEVICE(0x2770, 0x913d)}, > {} > }; > > must contain two other additional fields, describing the name in > human-readable form (intended to identify the camera to the extent that > one can probably pick it out from others on the shelf) and the current > status of the support for the camera. Like this: > > {"Sakar Micro Digital 2428x", GP_DRIVER_STATUS_EXPERIMENTAL, 0x2770, 0x905c}, > {"Jazz JDC9", GP_DRIVER_STATUS_EXPERIMENTAL, 0x2770, 0x905c}, > {"Disney pix micro", GP_DRIVER_STATUS_EXPERIMENTAL, 0x2770, 0x9050}, > {"Disney pix micro 2", GP_DRIVER_STATUS_EXPERIMENTAL, 0x2770, 0x9052}, > {"Suprema Digital Keychain Camera", GP_DRIVER_STATUS_EXPERIMENTAL, > 0x2770, 0x913d} The struct usb_device_id doesn't have any thing like that, and creating another table repeating the USB ID is very ugly (yet, a few drivers do it). This also means to add 4 extra bytes per camera, just to store a duplicated information. The better way is to do something like: enum { SAKAR_MICRO_DIGITAL_2428X, DISNEY_PIX_MICRO, DISNEY_PIX_MICRO2, SUPREMA_DIGITAL_KEYCHAIN_CAMERA, }; static const __devinitdata struct usb_device_id device_table[] = { {USB_DEVICE(0x2770, 0x905c), .driver_info = SAKAR_MICRO_DIGITAL_2428X}, {USB_DEVICE(0x2770, 0x9050), .driver_info = DISNEY_PIX_MICRO}, {USB_DEVICE(0x2770, 0x9052), .driver_info = DISNEY_PIX_MICRO2}, {USB_DEVICE(0x2770, 0x913d), .driver_info = SUPREMA_DIGITAL_KEYCHAIN_CAMERA}, {} }; struct camera_description { char *name; unsigned int flags; }; static struct camera_description cameras[] = { [SAKAR_MICRO_DIGITAL_2428X] = { .name = "Sakar Micro Digital 2428x/Jazz JDC9", .flags = GP_DRIVER_STATUS_EXPERIMENTAL, }, [DISNEY_PIX_MICRO] = { .name = "Disney pix micro", .flags = GP_DRIVER_STATUS_EXPERIMENTAL, }, [DISNEY_PIX_MICRO2] = { .name = "Disney pix micro 2", .flags = GP_DRIVER_STATUS_EXPERIMENTAL, }, [SUPREMA_DIGITAL_KEYCHAIN_CAMERA] = { .name = "Suprema Digital Keychain Camera", .flags = GP_DRIVER_STATUS_EXPERIMENTAL, }, }; The association between the two tables can easily be done at the .config ops: /* this function is called at probe time */ static int sd_config(struct gspca_dev *gspca_dev, const struct usb_device_id *id) { ... int board_nr = id->driver_info; printf(KERN_WARN "Detected camera %s\n", cameras[board_nr]); ... } A small change at cx88.pl will be enough to auto-generate gspca.txt. > > If something similar were done here, then perhaps it would be possible to > provide a tool which would print out two lists. One of them could be a > list of the known and supported devices by gspca, say. The second option > could provide a list of the devices which the local kernel supports. > > The need to rely on "the guy" is greatly reduced if such procedures are > put into place. Then it is the responsibility of the person who writes the > module to produce the information in the first place, and it is one of the > items on the checklist at submission time. It is also very easy for > someone else to add to the iist later on, if the occasion arises. > > Perhaps someone else can come up with a better idea? > > Theodore Kilgore > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html