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/cpi...
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