On Wed, Oct 16, 2013 at 5:12 PM, Andy Walls <awalls@xxxxxxxxxxxxxxxx> wrote: > On Thu, 2013-10-17 at 08:36 +0900, Milo Kim wrote: > >> > That's current solution, we plan to unify this two API since those >> > chip are basically LED. >> > >> >> On the other hands, LM3642 has an indicator mode with flash/torch. >> >> Then, it will consist of 3 parts - MFD core, LED(indicator) and >> >> V4L2(flash/torch). >> >> >> > >> > So if one LED device driver can support that, we don't need these 3 parts. >> >> Let me clarify our discussion briefly. >> >> For the flash and torch, there are scattered user-space APIs. >> We need to unify them. > > Sorry for the late input. > > There are also subject matter illuminators (is that the same as torch?). > They may be LED or halogen incadescent bulbs that are integral to a > device such as the QX5 microscope: > > http://git.linuxtv.org/media_tree.git/blob/HEAD:/drivers/media/usb/cpia2/cpia2_v4l.c#l1152 > > The V4L2 user controls ioctl()'s are used to control those two lamps > currently. Their activation seemed like a switch the user would want to > turn easily, via a GUI that contained other V4L2 device controls. > > Do these fit in anywhere into the unification? Not that I'm advocating > that. I just thought cases like this shouldn't be overlooked in deciding > what to do. > > Regards, > Andy > >> We are considering supporting V4L2 structures in the LED camera trigger. >> Then, camera application controls the flash/torch via not the LED sysfs >> but the V4L2 ioctl interface. >> So, changing point is the ledtrig-camera.c. No chip driver changes at all. >> >> Is it correct? >> >> Best regards, >> Milo > > Please find my proposal attached and probably my colleague Paul Walmsley will show up for this media mini summit if he is available. Thanks, -Bryan
Attachment:
Unify LED and V4L2 Flash API.pdf
Description: Adobe PDF document
