Look for a recent patch I sent to the list for gspca_cpia for the Intel Play QX3 microscope. (The cpia2 driver handles the QX5)
Illuminator seems to be the standard term in both microscopy and IR photgraphy. I also saw it in plain photography contexts. Just ask the Google... Regards, Andy Hans Verkuil <hverk...@xs4all.nl> wrote: >On Tuesday, September 07, 2010 13:59:19 Hans de Goede wrote: >> Hi all, >> >> On 09/07/2010 11:47 AM, Hans Verkuil wrote: >> > On Tuesday, September 07, 2010 11:44:18 Hans de Goede wrote: >> >> Replying to myself. >> >> >> >> On 09/07/2010 11:42 AM, Hans de Goede wrote: >> >>> Hi, >> >>> >> >>> On 09/07/2010 09:30 AM, Hans Verkuil wrote: >> >>>> On Monday, September 06, 2010 20:11:05 Jean-Francois Moine wrote: >> >>>>> Hi, >> >>>>> >> >>>>> This new proposal cancels the previous 'LED control' patch. >> >>>>> >> >>>>> Cheers. >> >>>>> >> >>>>> >> >>>> >> >>>> Hi Jean-Francois, >> >>>> >> >>>> You must also add support for these new controls in v4l2-ctrls.c in >> >>>> v4l2_ctrl_get_menu(), v4l2_ctrl_get_name() and v4l2_ctrl_fill(). >> >>>> >> >>>> How is CID_ILLUMINATORS supposed to work in the case of multiple lights? >> >>>> Wouldn't a bitmask type be more suitable to this than a menu type? There >> >>>> isn't a bitmask type at the moment, but this seems to be a pretty good >> >>>> candidate for a type like that. >> >>>> >> >>>> Actually, for the status led I would also use a bitmask since there may >> >>>> be >> >>>> multiple leds. I guess you would need two bitmasks: one to select auto >> >>>> vs >> >>>> manual, and one for the manual settings. >> >>>> >> >>> >> >>> So far I've not seen cameras with multiple status leds, I do have seen >> >>> camera >> >>> which have the following settings for their 1 led (logitech uvc cams): >> >>> auto >> >>> on >> >>> off >> >>> blinking >> >>> >> >>> So I think a menu type is better suited, and that is what the current >> >>> (private) >> >>> uvc control uses. >> >> >> >> The same argument more or less goes for the CID_ILLIMUNATORS controls. >> >> Also given >> >> that we currently don't have a bitmask type I think introducing one >> >> without a really >> >> really good reason is a bad idea as any exiting apps won't know how to >> >> deal with it. >> > >> > But I can guarantee that we will get video devices with multiple leds in >> > the >> > future. So we need to think *now* about how to do this. One simple option >> > is of course >> > to name the controls CID_ILLUMINATOR0 and CID_LED0. That way we can easily >> > add LED1, >> > LED2, etc. later without running into weird inconsistent control names. >> > >> >> Naming them LED0 and ILLUMINATOR0 works for me. Note about the illuminator >> one, >> if you look at the patch it made the illuminator control a menu with the >> following >> options: > >Where in the patch? Am I missing something? > >> >> Both off >> Top on, Bottom off >> Top off, Bottom on >> Both on >> >> Which raises the question do we leave this as is, or do we make this 2 >> boolean >> controls. I personally would like to vote for keeping it as is, as both lamps >> illuminate the same substrate in this case, and esp. switching between >> Top on, Bottom off to Top off, Bottom on in one go is a good feature to have >> UI wise (iow switch from top to bottom lighting or visa versa. > >The problem with having one control is that while this makes sense for this >particular microscope, it doesn't make sense in general. > >Standard controls such as proposed by this patch should have a fixed type and >consistent behavior. Note that I am also wondering whether it wouldn't be a >good idea to use a menu for this, just as for the LEDs. In fact, perhaps they >should use the same menu. While their purpose is different, they are quite >similar >in behavior. > >BTW, lovely word: 'illuminator'. > >Regards, > > Hans > >> >> Regards, >> >> Hans >> >> >> > >-- >Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco >-- >To unsubscribe from this list: send the line "unsubscribe linux-media" in >the body of a message to majord...@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html
