I have collected all the ideas up to now in a V2 of the agenda.
The items are grouped by the person(s) that suggested them. As done in the past those who suggested a topic and who will attend the mini-summit are expected to prepare for it, perhaps making a (very) small presentation if necessary.
Hans Verkuil:
- Discuss ideas/use-cases for a property-based API. An initial discussion appeared in this thread:
http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/65...
- What is needed to share i2c video transmitters between drm and v4l? Hopefully we will know more after the upcoming LPC.
- Decide on how v4l2 support libraries should be organized. There is code for handling raw-to-sliced VBI decoding, ALSA looping, finding associated video/alsa nodes and for TV frequency tables. We should decide how that should be organized into libraries and how they should be documented. The first two aren't libraries at the moment, but I think they should be. The last two are libraries but they aren't installed. Some work is also being done on an improved version of the 'associating nodes' library that uses the MC if available.
- Define the interaction between selection API, ENUM_FRAMESIZES and S_FMT. See this thread for all the nasty details:
http://www.spinics.net/lists/linux-media/msg65137.html
- VIDIOC_TRY_FMT shouldn't return -EINVAL when an unsupported pixelformat is provided, but in practice video capture board tend to do that, while webcam drivers tend to map it silently to a valid pixelformat. Some applications rely on the -EINVAL error code.
We need to decide how to adjust the spec. I propose to just say that some drivers will map it silently and others will return -EINVAL and that you don't know what a driver will do. Also specify that an unsupported pixelformat is the only reason why TRY_FMT might return -EINVAL.
Alternatively we might want to specify explicitly that EINVAL should be returned for video capture devices (i.e. devices supporting S_STD or S_DV_TIMINGS) and 0 for all others.
Mauro Carvalho Chehab:
- Better integration between DVB and V4L2, including starting using the media controller API on DVB side too.
- Get the status about the media controller API usage on ALSA.
Oliver Schinagl, Benjamin Gaignard, Hugues Fruchet, Laurent Pinchart, Pawel Osciak:
- How to handle codecs where part of the processing is done in HW and part in SW?
Sakari Ailus:
- Multi-format frames and metadata. Support would be needed on video nodes and V4L2 subdev nodes. I'll prepare the RFC for the former; the latter has an RFC here: http://www.spinics.net/lists/linux-media/msg67295.html
Ricardo Ribalda Delgado, Sylwester Nawrocki:
- Support for multiple rectangle cropping See thread: http://www.spinics.net/lists/linux-media/msg67824.html
Feel free to add suggestions to this list.
As it stands I don't think it will be possible to handle it all in one day. In particular the codec problem as mentioned by Oliver et al needs a lot of time. Should we set aside a separate day for just this? October 21 or 22 would work for me. I would really like to get some feedback on this. If we decide to go for a second day for this topic, then I can see if I can get a room. It looks like there is a lot of interest in getting this sorted, so brainstorming for a day might be quite useful.
Note: my email availability will be limited in the next two weeks, especially next week, as I am abroad (LinuxCon and LPC).
Regards,
Hans
_______________________________________________ media-workshop mailing list media-workshop@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/media-workshop
Hi,
I would like to have a short discussion on LED flash devices support in the kernel. Currently there are two APIs: the V4L2 and LED class API exposed by the kernel, which I believe is not good from user space POV. Generic applications will need to implement both APIs. I think we should decide whether to extend the led class API to add support for more advanced LED controllers there or continue to use the both APIs with overlapping functionality. There has been some discussion about this on the ML, but without any consensus reached [1].
[1] http://www.spinics.net/lists/linux-leds/msg00899.html
-- Regards, Sylwester
On 09/23/13 16:45, Sylwester Nawrocki wrote:
Hi,
I would like to have a short discussion on LED flash devices support in the kernel. Currently there are two APIs: the V4L2 and LED class API exposed by the kernel, which I believe is not good from user space POV. Generic applications will need to implement both APIs. I think we should decide whether to extend the led class API to add support for more advanced LED controllers there or continue to use the both APIs with overlapping functionality. There has been some discussion about this on the ML, but without any consensus reached [1].
What about the linux-pwm framework and its support for the backlight via dts?
Or am I talking way to uninformed here. Copying backlight to flashlight with some minor modification sounds sensible in a way...
Oliver
[1] http://www.spinics.net/lists/linux-leds/msg00899.html
-- Regards, Sylwester
-- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/23/2013 06:37 PM, Oliver Schinagl wrote:
On 09/23/13 16:45, Sylwester Nawrocki wrote:
Hi,
I would like to have a short discussion on LED flash devices support in the kernel. Currently there are two APIs: the V4L2 and LED class API exposed by the kernel, which I believe is not good from user space POV. Generic applications will need to implement both APIs. I think we should decide whether to extend the led class API to add support for more advanced LED controllers there or continue to use the both APIs with overlapping functionality. There has been some discussion about this on the ML, but without any consensus reached [1].
What about the linux-pwm framework and its support for the backlight via dts?
Or am I talking way to uninformed here. Copying backlight to flashlight with some minor modification sounds sensible in a way...
I'd assume we don't need yet another user interface for the LEDs ;) AFAICS the PWM subsystem exposes pretty much raw interface in sysfs. The PWM LED controllers are already handled in the leds-class API, there is the leds_pwm driver (drivers/leds/leds-pwm.c).
I'm adding linux-pwm and linux-leds maintainers at Cc so someone may correct me if I got anything wrong.
Presumably, what we need is a few enhancements to support in a standard way devices like MAX77693, LM3560 or MAX8997. There is already a led class driver for the MAX8997 LED controller (drivers/leds/leds-max8997.c), but it uses some device-specific sysfs attributes.
Thus similar devices are currently being handled by different subsystems. The split between the V4L2 Flash and the leds class API WRT to Flash LED controller drivers is included in RFC [1], it seems still up to date.
-- Thanks, Sylwester
On Mon, Sep 23, 2013 at 10:27:06PM +0200, Sylwester Nawrocki wrote:
On 09/23/2013 06:37 PM, Oliver Schinagl wrote:
On 09/23/13 16:45, Sylwester Nawrocki wrote:
Hi,
I would like to have a short discussion on LED flash devices support in the kernel. Currently there are two APIs: the V4L2 and LED class API exposed by the kernel, which I believe is not good from user space POV. Generic applications will need to implement both APIs. I think we should decide whether to extend the led class API to add support for more advanced LED controllers there or continue to use the both APIs with overlapping functionality. There has been some discussion about this on the ML, but without any consensus reached [1].
What about the linux-pwm framework and its support for the backlight via dts?
Or am I talking way to uninformed here. Copying backlight to flashlight with some minor modification sounds sensible in a way...
I'd assume we don't need yet another user interface for the LEDs ;) AFAICS the PWM subsystem exposes pretty much raw interface in sysfs. The PWM LED controllers are already handled in the leds-class API, there is the leds_pwm driver (drivers/leds/leds-pwm.c).
I'm adding linux-pwm and linux-leds maintainers at Cc so someone may correct me if I got anything wrong.
The PWM subsystem is most definitely not a good fit for this. The only thing it provides is a way for other drivers to access a PWM device and use it for some specific purpose (pwm-backlight, leds-pwm).
The sysfs support is a convenience for people that needs to use a PWM in a way for which no driver framework exists, or for which it doesn't make sense to write a driver. Or for testing.
Presumably, what we need is a few enhancements to support in a standard way devices like MAX77693, LM3560 or MAX8997. There is already a led class driver for the MAX8997 LED controller (drivers/leds/leds-max8997.c), but it uses some device-specific sysfs attributes.
Thus similar devices are currently being handled by different subsystems. The split between the V4L2 Flash and the leds class API WRT to Flash LED controller drivers is included in RFC [1], it seems still up to date.
Perhaps it would make sense for V4L2 to be able to use a LED as exposed by the LED subsystem and wrap it so that it can be integrated with V4L2? If functionality is missing from the LED subsystem I suppose that could be added.
If I understand correctly, the V4L2 subsystem uses LEDs as flashes for camera devices. I can easily imagine that there are devices out there which provide functionality beyond what a regular LED will provide. So perhaps for things such as mobile phones, which typically use a plain LED to illuminate the surroundings, an LED wrapped into something that emulates the flash functionality could work. But I doubt that the LED subsystem is a good fit for anything beyond that.
Thierry
Hi Thierry and Sylwester,
My apologies for the late answer.
On Tue, Sep 24, 2013 at 11:20:53AM +0200, Thierry Reding wrote:
On Mon, Sep 23, 2013 at 10:27:06PM +0200, Sylwester Nawrocki wrote:
On 09/23/2013 06:37 PM, Oliver Schinagl wrote:
On 09/23/13 16:45, Sylwester Nawrocki wrote:
Hi,
I would like to have a short discussion on LED flash devices support in the kernel. Currently there are two APIs: the V4L2 and LED class API exposed by the kernel, which I believe is not good from user space POV. Generic applications will need to implement both APIs. I think we should decide whether to extend the led class API to add support for more advanced LED controllers there or continue to use the both APIs with overlapping functionality. There has been some discussion about this on the ML, but without any consensus reached [1].
What about the linux-pwm framework and its support for the backlight via dts?
Or am I talking way to uninformed here. Copying backlight to flashlight with some minor modification sounds sensible in a way...
I'd assume we don't need yet another user interface for the LEDs ;) AFAICS the PWM subsystem exposes pretty much raw interface in sysfs. The PWM LED controllers are already handled in the leds-class API, there is the leds_pwm driver (drivers/leds/leds-pwm.c).
I'm adding linux-pwm and linux-leds maintainers at Cc so someone may correct me if I got anything wrong.
The PWM subsystem is most definitely not a good fit for this. The only thing it provides is a way for other drivers to access a PWM device and use it for some specific purpose (pwm-backlight, leds-pwm).
The sysfs support is a convenience for people that needs to use a PWM in a way for which no driver framework exists, or for which it doesn't make sense to write a driver. Or for testing.
Presumably, what we need is a few enhancements to support in a standard way devices like MAX77693, LM3560 or MAX8997. There is already a led class driver for the MAX8997 LED controller (drivers/leds/leds-max8997.c), but it uses some device-specific sysfs attributes.
Thus similar devices are currently being handled by different subsystems. The split between the V4L2 Flash and the leds class API WRT to Flash LED controller drivers is included in RFC [1], it seems still up to date.
Perhaps it would make sense for V4L2 to be able to use a LED as exposed by the LED subsystem and wrap it so that it can be integrated with V4L2? If functionality is missing from the LED subsystem I suppose that could be added.
The V4L2 flash API supports also xenon flashes, not only LED ones. That said, I agree there's a common subset of functionality most LED flash controllers implement.
If I understand correctly, the V4L2 subsystem uses LEDs as flashes for camera devices. I can easily imagine that there are devices out there which provide functionality beyond what a regular LED will provide. So perhaps for things such as mobile phones, which typically use a plain LED to illuminate the surroundings, an LED wrapped into something that emulates the flash functionality could work. But I doubt that the LED subsystem is a good fit for anything beyond that.
I originally thought one way to do this could be to make it as easy as possible to support both APIs in driver which some aregued, to which I agree, is rather poor desing.
Does the LED API have a user space interface library like libv4l2? If yes, one option oculd be to implement the wrapper between the V4L2 and LED APIs there so that the applications using the LED API could also access those devices that implement the V4L2 flash API. Torch mode functionality is common between the two right now AFAIU,
The V4L2 flash API also provides a way to strobe the flash using an external trigger which typically connected to the sensor (and the user can choose between that and software strobe). I guess that and Xenon flashes aren't currently covered by the LED API.
Hi Sakari,
On Tuesday 08 October 2013 00:06:23 Sakari Ailus wrote:
On Tue, Sep 24, 2013 at 11:20:53AM +0200, Thierry Reding wrote:
On Mon, Sep 23, 2013 at 10:27:06PM +0200, Sylwester Nawrocki wrote:
On 09/23/2013 06:37 PM, Oliver Schinagl wrote:
On 09/23/13 16:45, Sylwester Nawrocki wrote:
Hi,
I would like to have a short discussion on LED flash devices support in the kernel. Currently there are two APIs: the V4L2 and LED class API exposed by the kernel, which I believe is not good from user space POV. Generic applications will need to implement both APIs. I think we should decide whether to extend the led class API to add support for more advanced LED controllers there or continue to use the both APIs with overlapping functionality. There has been some discussion about this on the ML, but without any consensus reached [1].
What about the linux-pwm framework and its support for the backlight via dts?
Or am I talking way to uninformed here. Copying backlight to flashlight with some minor modification sounds sensible in a way...
I'd assume we don't need yet another user interface for the LEDs ;) AFAICS the PWM subsystem exposes pretty much raw interface in sysfs. The PWM LED controllers are already handled in the leds-class API, there is the leds_pwm driver (drivers/leds/leds-pwm.c).
I'm adding linux-pwm and linux-leds maintainers at Cc so someone may correct me if I got anything wrong.
The PWM subsystem is most definitely not a good fit for this. The only thing it provides is a way for other drivers to access a PWM device and use it for some specific purpose (pwm-backlight, leds-pwm).
The sysfs support is a convenience for people that needs to use a PWM in a way for which no driver framework exists, or for which it doesn't make sense to write a driver. Or for testing.
Presumably, what we need is a few enhancements to support in a standard way devices like MAX77693, LM3560 or MAX8997. There is already a led class driver for the MAX8997 LED controller (drivers/leds/leds- max8997.c), but it uses some device-specific sysfs attributes.
Thus similar devices are currently being handled by different subsystems. The split between the V4L2 Flash and the leds class API WRT to Flash LED controller drivers is included in RFC [1], it seems still up to date.
Perhaps it would make sense for V4L2 to be able to use a LED as exposed by the LED subsystem and wrap it so that it can be integrated with V4L2? If functionality is missing from the LED subsystem I suppose that could be added.
The V4L2 flash API supports also xenon flashes, not only LED ones. That said, I agree there's a common subset of functionality most LED flash controllers implement.
If I understand correctly, the V4L2 subsystem uses LEDs as flashes for camera devices. I can easily imagine that there are devices out there which provide functionality beyond what a regular LED will provide. So perhaps for things such as mobile phones, which typically use a plain LED to illuminate the surroundings, an LED wrapped into something that emulates the flash functionality could work. But I doubt that the LED subsystem is a good fit for anything beyond that.
I originally thought one way to do this could be to make it as easy as possible to support both APIs in driver which some aregued, to which I agree, is rather poor desing.
Does the LED API have a user space interface library like libv4l2? If yes, one option oculd be to implement the wrapper between the V4L2 and LED APIs there so that the applications using the LED API could also access those devices that implement the V4L2 flash API. Torch mode functionality is common between the two right now AFAIU,
The V4L2 flash API also provides a way to strobe the flash using an external trigger which typically connected to the sensor (and the user can choose between that and software strobe). I guess that and Xenon flashes aren't currently covered by the LED API.
The issue is that we have a LED API targetted at controlling LEDs, a V4L2 flash API targetted at controlling flashes, and hardware devices somewhere in the middle that can be used to provide LED or flash function. Merging the two APIs on the kernel side, with a compatibility layer for both kernel space and user space APIs, might be an idea worth investigating.
On Mon, Oct 7, 2013 at 3:24 PM, Laurent Pinchart laurent.pinchart@ideasonboard.com wrote:
Hi Sakari,
On Tuesday 08 October 2013 00:06:23 Sakari Ailus wrote:
On Tue, Sep 24, 2013 at 11:20:53AM +0200, Thierry Reding wrote:
On Mon, Sep 23, 2013 at 10:27:06PM +0200, Sylwester Nawrocki wrote:
On 09/23/2013 06:37 PM, Oliver Schinagl wrote:
On 09/23/13 16:45, Sylwester Nawrocki wrote:
Hi,
I would like to have a short discussion on LED flash devices support in the kernel. Currently there are two APIs: the V4L2 and LED class API exposed by the kernel, which I believe is not good from user space POV. Generic applications will need to implement both APIs. I think we should decide whether to extend the led class API to add support for more advanced LED controllers there or continue to use the both APIs with overlapping functionality. There has been some discussion about this on the ML, but without any consensus reached [1].
What about the linux-pwm framework and its support for the backlight via dts?
Or am I talking way to uninformed here. Copying backlight to flashlight with some minor modification sounds sensible in a way...
I'd assume we don't need yet another user interface for the LEDs ;) AFAICS the PWM subsystem exposes pretty much raw interface in sysfs. The PWM LED controllers are already handled in the leds-class API, there is the leds_pwm driver (drivers/leds/leds-pwm.c).
I'm adding linux-pwm and linux-leds maintainers at Cc so someone may correct me if I got anything wrong.
The PWM subsystem is most definitely not a good fit for this. The only thing it provides is a way for other drivers to access a PWM device and use it for some specific purpose (pwm-backlight, leds-pwm).
The sysfs support is a convenience for people that needs to use a PWM in a way for which no driver framework exists, or for which it doesn't make sense to write a driver. Or for testing.
Presumably, what we need is a few enhancements to support in a standard way devices like MAX77693, LM3560 or MAX8997. There is already a led class driver for the MAX8997 LED controller (drivers/leds/leds- max8997.c), but it uses some device-specific sysfs attributes.
Thus similar devices are currently being handled by different subsystems. The split between the V4L2 Flash and the leds class API WRT to Flash LED controller drivers is included in RFC [1], it seems still up to date.
Perhaps it would make sense for V4L2 to be able to use a LED as exposed by the LED subsystem and wrap it so that it can be integrated with V4L2? If functionality is missing from the LED subsystem I suppose that could be added.
The V4L2 flash API supports also xenon flashes, not only LED ones. That said, I agree there's a common subset of functionality most LED flash controllers implement.
If I understand correctly, the V4L2 subsystem uses LEDs as flashes for camera devices. I can easily imagine that there are devices out there which provide functionality beyond what a regular LED will provide. So perhaps for things such as mobile phones, which typically use a plain LED to illuminate the surroundings, an LED wrapped into something that emulates the flash functionality could work. But I doubt that the LED subsystem is a good fit for anything beyond that.
I originally thought one way to do this could be to make it as easy as possible to support both APIs in driver which some aregued, to which I agree, is rather poor desing.
Does the LED API have a user space interface library like libv4l2? If yes, one option oculd be to implement the wrapper between the V4L2 and LED APIs there so that the applications using the LED API could also access those devices that implement the V4L2 flash API. Torch mode functionality is common between the two right now AFAIU,
The V4L2 flash API also provides a way to strobe the flash using an external trigger which typically connected to the sensor (and the user can choose between that and software strobe). I guess that and Xenon flashes aren't currently covered by the LED API.
The issue is that we have a LED API targetted at controlling LEDs, a V4L2 flash API targetted at controlling flashes, and hardware devices somewhere in the middle that can be used to provide LED or flash function. Merging the two APIs on the kernel side, with a compatibility layer for both kernel space and user space APIs, might be an idea worth investigating.
I'm so sorry for jumping in the discussion so late. Some how the emails from linux-media was archived in my Gmail and I haven't checkout this for several weeks.
I agree right now LED API doesn't quite fit for the usage of V4L2 Flash API. But I'd also like to see a unified API.
Currently, LED API are exported to user space as sysfs interface, while V4L2 Flash APIs are like IOCTL and user space library. We also merged some LED Flash trigger into LED subsystem. My basic idea is what about creating or expanding the LED Flash trigger driver and provide a well defined sysfs interface, which can be wrapped into user space libv4l2.
Thanks, -Bryan
Hi Bryan,
On Thursday 10 October 2013 17:02:18 Bryan Wu wrote:
On Mon, Oct 7, 2013 at 3:24 PM, Laurent Pinchart wrote:
On Tuesday 08 October 2013 00:06:23 Sakari Ailus wrote:
On Tue, Sep 24, 2013 at 11:20:53AM +0200, Thierry Reding wrote:
On Mon, Sep 23, 2013 at 10:27:06PM +0200, Sylwester Nawrocki wrote:
On 09/23/2013 06:37 PM, Oliver Schinagl wrote:
On 09/23/13 16:45, Sylwester Nawrocki wrote: > Hi, > > I would like to have a short discussion on LED flash devices support > in the kernel. Currently there are two APIs: the V4L2 and LED class > API exposed by the kernel, which I believe is not good from user > space POV. Generic applications will need to implement both APIs. I > think we should decide whether to extend the led class API to add > support for more advanced LED controllers there or continue to use > the both APIs with overlapping functionality. There has been some > discussion about this on the ML, but without any consensus reached > [1].
What about the linux-pwm framework and its support for the backlight via dts?
Or am I talking way to uninformed here. Copying backlight to flashlight with some minor modification sounds sensible in a way...
I'd assume we don't need yet another user interface for the LEDs ;) AFAICS the PWM subsystem exposes pretty much raw interface in sysfs. The PWM LED controllers are already handled in the leds-class API, there is the leds_pwm driver (drivers/leds/leds-pwm.c).
I'm adding linux-pwm and linux-leds maintainers at Cc so someone may correct me if I got anything wrong.
The PWM subsystem is most definitely not a good fit for this. The only thing it provides is a way for other drivers to access a PWM device and use it for some specific purpose (pwm-backlight, leds-pwm).
The sysfs support is a convenience for people that needs to use a PWM in a way for which no driver framework exists, or for which it doesn't make sense to write a driver. Or for testing.
Presumably, what we need is a few enhancements to support in a standard way devices like MAX77693, LM3560 or MAX8997. There is already a led class driver for the MAX8997 LED controller (drivers/leds/leds-max8997.c), but it uses some device-specific sysfs attributes.
Thus similar devices are currently being handled by different subsystems. The split between the V4L2 Flash and the leds class API WRT to Flash LED controller drivers is included in RFC [1], it seems still up to date.
Perhaps it would make sense for V4L2 to be able to use a LED as exposed by the LED subsystem and wrap it so that it can be integrated with V4L2? If functionality is missing from the LED subsystem I suppose that could be added.
The V4L2 flash API supports also xenon flashes, not only LED ones. That said, I agree there's a common subset of functionality most LED flash controllers implement.
If I understand correctly, the V4L2 subsystem uses LEDs as flashes for camera devices. I can easily imagine that there are devices out there which provide functionality beyond what a regular LED will provide. So perhaps for things such as mobile phones, which typically use a plain LED to illuminate the surroundings, an LED wrapped into something that emulates the flash functionality could work. But I doubt that the LED subsystem is a good fit for anything beyond that.
I originally thought one way to do this could be to make it as easy as possible to support both APIs in driver which some aregued, to which I agree, is rather poor desing.
Does the LED API have a user space interface library like libv4l2? If yes, one option oculd be to implement the wrapper between the V4L2 and LED APIs there so that the applications using the LED API could also access those devices that implement the V4L2 flash API. Torch mode functionality is common between the two right now AFAIU,
The V4L2 flash API also provides a way to strobe the flash using an external trigger which typically connected to the sensor (and the user can choose between that and software strobe). I guess that and Xenon flashes aren't currently covered by the LED API.
The issue is that we have a LED API targetted at controlling LEDs, a V4L2 flash API targetted at controlling flashes, and hardware devices somewhere in the middle that can be used to provide LED or flash function. Merging the two APIs on the kernel side, with a compatibility layer for both kernel space and user space APIs, might be an idea worth investigating.
I'm so sorry for jumping in the discussion so late. Some how the emails from linux-media was archived in my Gmail and I haven't checkout this for several weeks.
I agree right now LED API doesn't quite fit for the usage of V4L2 Flash API. But I'd also like to see a unified API.
Currently, LED API are exported to user space as sysfs interface, while V4L2 Flash APIs are like IOCTL and user space library. We also merged some LED Flash trigger into LED subsystem. My basic idea is what about creating or expanding the LED Flash trigger driver and provide a well defined sysfs interface, which can be wrapped into user space libv4l2.
The biggest reason why we're not fond of sysfs-based APIs for media devices is that they can't provide atomicity. There's no way to set multiple parameters in a single operation.
We can't get rid of the sysfs LEDs API, but maybe we could have a unified kernel LED/flash subsystem that would provide both a sysfs-based API to ensure compatibility with current userspace software and an ioctl-based API (possibly through V4L2 controls). That way LED/flash devices would be registered with a single subsystem, and the corresponding drivers won't have to care about the API exposed to userspace. That would require a major refactoring of the in- kernel APIs though.
On Fri, Oct 11, 2013 at 12:38 AM, Laurent Pinchart laurent.pinchart@ideasonboard.com wrote:
Hi Bryan,
On Thursday 10 October 2013 17:02:18 Bryan Wu wrote:
On Mon, Oct 7, 2013 at 3:24 PM, Laurent Pinchart wrote:
On Tuesday 08 October 2013 00:06:23 Sakari Ailus wrote:
On Tue, Sep 24, 2013 at 11:20:53AM +0200, Thierry Reding wrote:
On Mon, Sep 23, 2013 at 10:27:06PM +0200, Sylwester Nawrocki wrote:
On 09/23/2013 06:37 PM, Oliver Schinagl wrote: > On 09/23/13 16:45, Sylwester Nawrocki wrote: >> Hi, >> >> I would like to have a short discussion on LED flash devices support >> in the kernel. Currently there are two APIs: the V4L2 and LED class >> API exposed by the kernel, which I believe is not good from user >> space POV. Generic applications will need to implement both APIs. I >> think we should decide whether to extend the led class API to add >> support for more advanced LED controllers there or continue to use >> the both APIs with overlapping functionality. There has been some >> discussion about this on the ML, but without any consensus reached >> [1]. > > What about the linux-pwm framework and its support for the backlight > via dts? > > Or am I talking way to uninformed here. Copying backlight to > flashlight with some minor modification sounds sensible in a way...
I'd assume we don't need yet another user interface for the LEDs ;) AFAICS the PWM subsystem exposes pretty much raw interface in sysfs. The PWM LED controllers are already handled in the leds-class API, there is the leds_pwm driver (drivers/leds/leds-pwm.c).
I'm adding linux-pwm and linux-leds maintainers at Cc so someone may correct me if I got anything wrong.
The PWM subsystem is most definitely not a good fit for this. The only thing it provides is a way for other drivers to access a PWM device and use it for some specific purpose (pwm-backlight, leds-pwm).
The sysfs support is a convenience for people that needs to use a PWM in a way for which no driver framework exists, or for which it doesn't make sense to write a driver. Or for testing.
Presumably, what we need is a few enhancements to support in a standard way devices like MAX77693, LM3560 or MAX8997. There is already a led class driver for the MAX8997 LED controller (drivers/leds/leds-max8997.c), but it uses some device-specific sysfs attributes.
Thus similar devices are currently being handled by different subsystems. The split between the V4L2 Flash and the leds class API WRT to Flash LED controller drivers is included in RFC [1], it seems still up to date.
Perhaps it would make sense for V4L2 to be able to use a LED as exposed by the LED subsystem and wrap it so that it can be integrated with V4L2? If functionality is missing from the LED subsystem I suppose that could be added.
The V4L2 flash API supports also xenon flashes, not only LED ones. That said, I agree there's a common subset of functionality most LED flash controllers implement.
If I understand correctly, the V4L2 subsystem uses LEDs as flashes for camera devices. I can easily imagine that there are devices out there which provide functionality beyond what a regular LED will provide. So perhaps for things such as mobile phones, which typically use a plain LED to illuminate the surroundings, an LED wrapped into something that emulates the flash functionality could work. But I doubt that the LED subsystem is a good fit for anything beyond that.
I originally thought one way to do this could be to make it as easy as possible to support both APIs in driver which some aregued, to which I agree, is rather poor desing.
Does the LED API have a user space interface library like libv4l2? If yes, one option oculd be to implement the wrapper between the V4L2 and LED APIs there so that the applications using the LED API could also access those devices that implement the V4L2 flash API. Torch mode functionality is common between the two right now AFAIU,
The V4L2 flash API also provides a way to strobe the flash using an external trigger which typically connected to the sensor (and the user can choose between that and software strobe). I guess that and Xenon flashes aren't currently covered by the LED API.
The issue is that we have a LED API targetted at controlling LEDs, a V4L2 flash API targetted at controlling flashes, and hardware devices somewhere in the middle that can be used to provide LED or flash function. Merging the two APIs on the kernel side, with a compatibility layer for both kernel space and user space APIs, might be an idea worth investigating.
I'm so sorry for jumping in the discussion so late. Some how the emails from linux-media was archived in my Gmail and I haven't checkout this for several weeks.
I agree right now LED API doesn't quite fit for the usage of V4L2 Flash API. But I'd also like to see a unified API.
Currently, LED API are exported to user space as sysfs interface, while V4L2 Flash APIs are like IOCTL and user space library. We also merged some LED Flash trigger into LED subsystem. My basic idea is what about creating or expanding the LED Flash trigger driver and provide a well defined sysfs interface, which can be wrapped into user space libv4l2.
The biggest reason why we're not fond of sysfs-based APIs for media devices is that they can't provide atomicity. There's no way to set multiple parameters in a single operation.
We can't get rid of the sysfs LEDs API, but maybe we could have a unified kernel LED/flash subsystem that would provide both a sysfs-based API to ensure compatibility with current userspace software and an ioctl-based API (possibly through V4L2 controls). That way LED/flash devices would be registered with a single subsystem, and the corresponding drivers won't have to care about the API exposed to userspace. That would require a major refactoring of the in- kernel APIs though.
I agree this. I'm thinking about expanding the ledtrig-camera.c created by Milo Kim. This trigger will provide flashing and strobing control of a LED device and for sure the LED device driver like drivers/leds/leds-lm355x.c.
So we basically can do this: 1. add V4L2 Flash subdev into ledtrig-camera.c. So this trigger driver can provide trigger API to kernel drivers as well as V4L2 Flash API to userspace. 2. add the real flash torch functions into LED device driver like leds-lm355x.c, this driver will still provide sysfs interface and extended flash/torch control sysfs interface as well.
I'm not sure about whether we need some change in V4L2 internally. But actually Andrzej Hajda's patchset is quite straightforward, but we just need put those V4L2 Flash API into a LED trigger driver and the real flash/torch operation in a LED device driver.
Milo, could you please give some comments here?
Thanks, -Bryan
Hi Bryan,
On Tuesday 15 October 2013 11:37:23 Bryan Wu wrote:
On Fri, Oct 11, 2013 at 12:38 AM, Laurent Pinchart wrote:
On Thursday 10 October 2013 17:02:18 Bryan Wu wrote:
On Mon, Oct 7, 2013 at 3:24 PM, Laurent Pinchart wrote:
On Tuesday 08 October 2013 00:06:23 Sakari Ailus wrote:
On Tue, Sep 24, 2013 at 11:20:53AM +0200, Thierry Reding wrote:
On Mon, Sep 23, 2013 at 10:27:06PM +0200, Sylwester Nawrocki wrote: > On 09/23/2013 06:37 PM, Oliver Schinagl wrote: >> On 09/23/13 16:45, Sylwester Nawrocki wrote: >>> Hi, >>> >>> I would like to have a short discussion on LED flash devices >>> support in the kernel. Currently there are two APIs: the V4L2 and >>> LED class API exposed by the kernel, which I believe is not good >>> from user space POV. Generic applications will need to implement >>> both APIs. I think we should decide whether to extend the led >>> class API to add support for more advanced LED controllers there >>> or continue to use the both APIs with overlapping functionality. >>> There has been some discussion about this on the ML, but without >>> any consensus reached [1]. >> >> What about the linux-pwm framework and its support for the >> backlight via dts? >> >> Or am I talking way to uninformed here. Copying backlight to >> flashlight with some minor modification sounds sensible in a >> way... > > I'd assume we don't need yet another user interface for the LEDs ;) > AFAICS the PWM subsystem exposes pretty much raw interface in > sysfs. The PWM LED controllers are already handled in the leds- > class API, there is the leds_pwm driver (drivers/leds/leds-pwm.c). > > I'm adding linux-pwm and linux-leds maintainers at Cc so someone > may correct me if I got anything wrong.
The PWM subsystem is most definitely not a good fit for this. The only thing it provides is a way for other drivers to access a PWM device and use it for some specific purpose (pwm-backlight, leds- pwm).
The sysfs support is a convenience for people that needs to use a PWM in a way for which no driver framework exists, or for which it doesn't make sense to write a driver. Or for testing.
> Presumably, what we need is a few enhancements to support in a > standard way devices like MAX77693, LM3560 or MAX8997. There is > already a led class driver for the MAX8997 LED controller > (drivers/leds/leds-max8997.c), but it uses some device-specific > sysfs attributes. > > Thus similar devices are currently being handled by different > subsystems. The split between the V4L2 Flash and the leds class > API WRT to Flash LED controller drivers is included in RFC [1], it > seems still up to date. > > >>[1] http://www.spinics.net/lists/linux-leds/msg00899.html
Perhaps it would make sense for V4L2 to be able to use a LED as exposed by the LED subsystem and wrap it so that it can be integrated with V4L2? If functionality is missing from the LED subsystem I suppose that could be added.
The V4L2 flash API supports also xenon flashes, not only LED ones. That said, I agree there's a common subset of functionality most LED flash controllers implement.
If I understand correctly, the V4L2 subsystem uses LEDs as flashes for camera devices. I can easily imagine that there are devices out there which provide functionality beyond what a regular LED will provide. So perhaps for things such as mobile phones, which typically use a plain LED to illuminate the surroundings, an LED wrapped into something that emulates the flash functionality could work. But I doubt that the LED subsystem is a good fit for anything beyond that.
I originally thought one way to do this could be to make it as easy as possible to support both APIs in driver which some aregued, to which I agree, is rather poor desing.
Does the LED API have a user space interface library like libv4l2? If yes, one option oculd be to implement the wrapper between the V4L2 and LED APIs there so that the applications using the LED API could also access those devices that implement the V4L2 flash API. Torch mode functionality is common between the two right now AFAIU,
The V4L2 flash API also provides a way to strobe the flash using an external trigger which typically connected to the sensor (and the user can choose between that and software strobe). I guess that and Xenon flashes aren't currently covered by the LED API.
The issue is that we have a LED API targetted at controlling LEDs, a V4L2 flash API targetted at controlling flashes, and hardware devices somewhere in the middle that can be used to provide LED or flash function. Merging the two APIs on the kernel side, with a compatibility layer for both kernel space and user space APIs, might be an idea worth investigating.
I'm so sorry for jumping in the discussion so late. Some how the emails from linux-media was archived in my Gmail and I haven't checkout this for several weeks.
I agree right now LED API doesn't quite fit for the usage of V4L2 Flash API. But I'd also like to see a unified API.
Currently, LED API are exported to user space as sysfs interface, while V4L2 Flash APIs are like IOCTL and user space library. We also merged some LED Flash trigger into LED subsystem. My basic idea is what about creating or expanding the LED Flash trigger driver and provide a well defined sysfs interface, which can be wrapped into user space libv4l2.
The biggest reason why we're not fond of sysfs-based APIs for media devices is that they can't provide atomicity. There's no way to set multiple parameters in a single operation.
We can't get rid of the sysfs LEDs API, but maybe we could have a unified kernel LED/flash subsystem that would provide both a sysfs-based API to ensure compatibility with current userspace software and an ioctl-based API (possibly through V4L2 controls). That way LED/flash devices would be registered with a single subsystem, and the corresponding drivers won't have to care about the API exposed to userspace. That would require a major refactoring of the in- kernel APIs though.
I agree this. I'm thinking about expanding the ledtrig-camera.c created by Milo Kim. This trigger will provide flashing and strobing control of a LED device and for sure the LED device driver like drivers/leds/leds-lm355x.c.
So we basically can do this:
- add V4L2 Flash subdev into ledtrig-camera.c. So this trigger driver
can provide trigger API to kernel drivers as well as V4L2 Flash API to userspace. 2. add the real flash torch functions into LED device driver like leds-lm355x.c, this driver will still provide sysfs interface and extended flash/torch control sysfs interface as well.
I'm not sure about whether we need some change in V4L2 internally. But actually Andrzej Hajda's patchset is quite straightforward, but we just need put those V4L2 Flash API into a LED trigger driver and the real flash/torch operation in a LED device driver.
I believe we should look at both ends of the problem and then try to draft an architecture for what goes between, based on what we already have. Those two ends are the LED controller chips on one side, and the application needs on the other side.
Regarding applications, I believe the needs have been captured by our current userspace APIs (LED sysfs API, triggers, and V4L2 flash API). Regarding the hardware, please have a look at the ADP1653 and AS3645A/LM3555. They're both pretty complex chips, and most of their features need to be exposed. Let's keep in mind that there can be pretty complex dependencies between the flash and torch features.
Would you be interesting in writing an architecture proposal ?
Do you plan to attend KS/ELC-E next week ?
Milo, could you please give some comments here?
On Tue, Oct 15, 2013 at 11:50 AM, Laurent Pinchart laurent.pinchart@ideasonboard.com wrote:
Hi Bryan,
On Tuesday 15 October 2013 11:37:23 Bryan Wu wrote:
On Fri, Oct 11, 2013 at 12:38 AM, Laurent Pinchart wrote:
On Thursday 10 October 2013 17:02:18 Bryan Wu wrote:
On Mon, Oct 7, 2013 at 3:24 PM, Laurent Pinchart wrote:
On Tuesday 08 October 2013 00:06:23 Sakari Ailus wrote:
On Tue, Sep 24, 2013 at 11:20:53AM +0200, Thierry Reding wrote: > On Mon, Sep 23, 2013 at 10:27:06PM +0200, Sylwester Nawrocki wrote: >> On 09/23/2013 06:37 PM, Oliver Schinagl wrote: >>> On 09/23/13 16:45, Sylwester Nawrocki wrote: >>>> Hi, >>>> >>>> I would like to have a short discussion on LED flash devices >>>> support in the kernel. Currently there are two APIs: the V4L2 and >>>> LED class API exposed by the kernel, which I believe is not good >>>> from user space POV. Generic applications will need to implement >>>> both APIs. I think we should decide whether to extend the led >>>> class API to add support for more advanced LED controllers there >>>> or continue to use the both APIs with overlapping functionality. >>>> There has been some discussion about this on the ML, but without >>>> any consensus reached [1]. >>> >>> What about the linux-pwm framework and its support for the >>> backlight via dts? >>> >>> Or am I talking way to uninformed here. Copying backlight to >>> flashlight with some minor modification sounds sensible in a >>> way... >> >> I'd assume we don't need yet another user interface for the LEDs ;) >> AFAICS the PWM subsystem exposes pretty much raw interface in >> sysfs. The PWM LED controllers are already handled in the leds- >> class API, there is the leds_pwm driver (drivers/leds/leds-pwm.c). >> >> I'm adding linux-pwm and linux-leds maintainers at Cc so someone >> may correct me if I got anything wrong. > > The PWM subsystem is most definitely not a good fit for this. The > only thing it provides is a way for other drivers to access a PWM > device and use it for some specific purpose (pwm-backlight, leds- > pwm). > > The sysfs support is a convenience for people that needs to use a > PWM in a way for which no driver framework exists, or for which it > doesn't make sense to write a driver. Or for testing. > > > Presumably, what we need is a few enhancements to support in a > > standard way devices like MAX77693, LM3560 or MAX8997. There is > > already a led class driver for the MAX8997 LED controller > > (drivers/leds/leds-max8997.c), but it uses some device-specific > > sysfs attributes. > > > > Thus similar devices are currently being handled by different > > subsystems. The split between the V4L2 Flash and the leds class > > API WRT to Flash LED controller drivers is included in RFC [1], it > > seems still up to date. > > > > >>[1] http://www.spinics.net/lists/linux-leds/msg00899.html > > Perhaps it would make sense for V4L2 to be able to use a LED as > exposed by the LED subsystem and wrap it so that it can be > integrated with V4L2? If functionality is missing from the LED > subsystem I suppose that could be added.
The V4L2 flash API supports also xenon flashes, not only LED ones. That said, I agree there's a common subset of functionality most LED flash controllers implement.
> If I understand correctly, the V4L2 subsystem uses LEDs as flashes > for camera devices. I can easily imagine that there are devices out > there which provide functionality beyond what a regular LED will > provide. So perhaps for things such as mobile phones, which > typically use a plain LED to illuminate the surroundings, an LED > wrapped into something that emulates the flash functionality could > work. But I doubt that the LED subsystem is a good fit for anything > beyond that.
I originally thought one way to do this could be to make it as easy as possible to support both APIs in driver which some aregued, to which I agree, is rather poor desing.
Does the LED API have a user space interface library like libv4l2? If yes, one option oculd be to implement the wrapper between the V4L2 and LED APIs there so that the applications using the LED API could also access those devices that implement the V4L2 flash API. Torch mode functionality is common between the two right now AFAIU,
The V4L2 flash API also provides a way to strobe the flash using an external trigger which typically connected to the sensor (and the user can choose between that and software strobe). I guess that and Xenon flashes aren't currently covered by the LED API.
The issue is that we have a LED API targetted at controlling LEDs, a V4L2 flash API targetted at controlling flashes, and hardware devices somewhere in the middle that can be used to provide LED or flash function. Merging the two APIs on the kernel side, with a compatibility layer for both kernel space and user space APIs, might be an idea worth investigating.
I'm so sorry for jumping in the discussion so late. Some how the emails from linux-media was archived in my Gmail and I haven't checkout this for several weeks.
I agree right now LED API doesn't quite fit for the usage of V4L2 Flash API. But I'd also like to see a unified API.
Currently, LED API are exported to user space as sysfs interface, while V4L2 Flash APIs are like IOCTL and user space library. We also merged some LED Flash trigger into LED subsystem. My basic idea is what about creating or expanding the LED Flash trigger driver and provide a well defined sysfs interface, which can be wrapped into user space libv4l2.
The biggest reason why we're not fond of sysfs-based APIs for media devices is that they can't provide atomicity. There's no way to set multiple parameters in a single operation.
We can't get rid of the sysfs LEDs API, but maybe we could have a unified kernel LED/flash subsystem that would provide both a sysfs-based API to ensure compatibility with current userspace software and an ioctl-based API (possibly through V4L2 controls). That way LED/flash devices would be registered with a single subsystem, and the corresponding drivers won't have to care about the API exposed to userspace. That would require a major refactoring of the in- kernel APIs though.
I agree this. I'm thinking about expanding the ledtrig-camera.c created by Milo Kim. This trigger will provide flashing and strobing control of a LED device and for sure the LED device driver like drivers/leds/leds-lm355x.c.
So we basically can do this:
- add V4L2 Flash subdev into ledtrig-camera.c. So this trigger driver
can provide trigger API to kernel drivers as well as V4L2 Flash API to userspace. 2. add the real flash torch functions into LED device driver like leds-lm355x.c, this driver will still provide sysfs interface and extended flash/torch control sysfs interface as well.
I'm not sure about whether we need some change in V4L2 internally. But actually Andrzej Hajda's patchset is quite straightforward, but we just need put those V4L2 Flash API into a LED trigger driver and the real flash/torch operation in a LED device driver.
I believe we should look at both ends of the problem and then try to draft an architecture for what goes between, based on what we already have. Those two ends are the LED controller chips on one side, and the application needs on the other side.
Sound good to me. I will take a look in detail about the architecture.
Regarding applications, I believe the needs have been captured by our current userspace APIs (LED sysfs API, triggers, and V4L2 flash API). Regarding the hardware, please have a look at the ADP1653 and AS3645A/LM3555. They're both pretty complex chips, and most of their features need to be exposed. Let's keep in mind that there can be pretty complex dependencies between the flash and torch features.
Actually recently I'm also working V4L2 SoC camera controller driver for Tegra. We are using some similar LED/Flash chip you mentioned.
Would you be interesting in writing an architecture proposal ?
Sure, I will do this. And probably post it our before the KS/ELC-E, then you guys can discuss it during the mini-summit.
Do you plan to attend KS/ELC-E next week ?
Unfortunately I won't, but I might ask some colleagues to present.
Thanks, -Bryan
On 10/15/2013 08:37 PM, Bryan Wu wrote:
On Fri, Oct 11, 2013 at 12:38 AM, Laurent Pinchart
[...]
The biggest reason why we're not fond of sysfs-based APIs for media devices is that they can't provide atomicity. There's no way to set multiple parameters in a single operation.
I wonder what are your concerns WRT atomicity about usage of flash devices in camera subsystems ? Is atomicity really so important here ? I don't disagree with this argument, but I'm curious if you had any specific use cases in mind ?
We can't get rid of the sysfs LEDs API, but maybe we could have a unified kernel LED/flash subsystem that would provide both a sysfs-based API to ensure
One of my original concerns were that same chip (often a multi-function device) can be used as a camera Flash or an ordinary LED indicator. It depends on physical system a chip is deployed, LED current configured, etc. So it appears bad from design POV to have different drivers for different purposes of same device.
I believe led API should be a lower level layer, so each LED can be used as a simple indicator.
compatibility with current userspace software and an ioctl-based API (possibly through V4L2 controls). That way LED/flash devices would be registered with a single subsystem, and the corresponding drivers won't have to care about the API exposed to userspace. That would require a major refactoring of the in- kernel APIs though.
I agree this. I'm thinking about expanding the ledtrig-camera.c created by Milo Kim. This trigger will provide flashing and strobing control of a LED device and for sure the LED device driver like drivers/leds/leds-lm355x.c.
So we basically can do this:
- add V4L2 Flash subdev into ledtrig-camera.c. So this trigger driver
can provide trigger API to kernel drivers as well as V4L2 Flash API to userspace.
That sounds reasonable to me, I guess this could be a kernel config option, so one can disable dependency on videodev module and the like at the LED module if V4L2 flash API is not needed.
- add the real flash torch functions into LED device driver like
leds-lm355x.c, this driver will still provide sysfs interface and extended flash/torch control sysfs interface as well.
+1
I'm not sure about whether we need some change in V4L2 internally. But actually Andrzej Hajda's patchset is quite straightforward, but we just need put those V4L2 Flash API into a LED trigger driver and the real flash/torch operation in a LED device driver.
I guess some changes will be needed at both subsystems, but these are details. Such high level design sounds good to me.
Sorry for not replying earlier in this thread, have been busy and travelling for last two weeks.
-- Thanks, Sylwester
Hi Bryan,
On 10/16/2013 03:37 AM, Bryan Wu wrote:
On Fri, Oct 11, 2013 at 12:38 AM, Laurent Pinchart laurent.pinchart@ideasonboard.com wrote:
Hi Bryan,
On Thursday 10 October 2013 17:02:18 Bryan Wu wrote:
On Mon, Oct 7, 2013 at 3:24 PM, Laurent Pinchart wrote:
On Tuesday 08 October 2013 00:06:23 Sakari Ailus wrote:
On Tue, Sep 24, 2013 at 11:20:53AM +0200, Thierry Reding wrote:
On Mon, Sep 23, 2013 at 10:27:06PM +0200, Sylwester Nawrocki wrote: > On 09/23/2013 06:37 PM, Oliver Schinagl wrote: >> On 09/23/13 16:45, Sylwester Nawrocki wrote: >>> Hi, >>> >>> I would like to have a short discussion on LED flash devices support >>> in the kernel. Currently there are two APIs: the V4L2 and LED class >>> API exposed by the kernel, which I believe is not good from user >>> space POV. Generic applications will need to implement both APIs. I >>> think we should decide whether to extend the led class API to add >>> support for more advanced LED controllers there or continue to use >>> the both APIs with overlapping functionality. There has been some >>> discussion about this on the ML, but without any consensus reached >>> [1]. >> >> What about the linux-pwm framework and its support for the backlight >> via dts? >> >> Or am I talking way to uninformed here. Copying backlight to >> flashlight with some minor modification sounds sensible in a way... > > I'd assume we don't need yet another user interface for the LEDs ;) > AFAICS the PWM subsystem exposes pretty much raw interface in sysfs. > The PWM LED controllers are already handled in the leds-class API, > there is the leds_pwm driver (drivers/leds/leds-pwm.c). > > I'm adding linux-pwm and linux-leds maintainers at Cc so someone may > correct me if I got anything wrong.
The PWM subsystem is most definitely not a good fit for this. The only thing it provides is a way for other drivers to access a PWM device and use it for some specific purpose (pwm-backlight, leds-pwm).
The sysfs support is a convenience for people that needs to use a PWM in a way for which no driver framework exists, or for which it doesn't make sense to write a driver. Or for testing.
> Presumably, what we need is a few enhancements to support in a > standard way devices like MAX77693, LM3560 or MAX8997. There is > already a led class driver for the MAX8997 LED controller > (drivers/leds/leds-max8997.c), but it uses some device-specific sysfs > attributes. > > Thus similar devices are currently being handled by different > subsystems. The split between the V4L2 Flash and the leds class API > WRT to Flash LED controller drivers is included in RFC [1], it seems > still up to date. > >>> [1] http://www.spinics.net/lists/linux-leds/msg00899.html
Perhaps it would make sense for V4L2 to be able to use a LED as exposed by the LED subsystem and wrap it so that it can be integrated with V4L2? If functionality is missing from the LED subsystem I suppose that could be added.
The V4L2 flash API supports also xenon flashes, not only LED ones. That said, I agree there's a common subset of functionality most LED flash controllers implement.
If I understand correctly, the V4L2 subsystem uses LEDs as flashes for camera devices. I can easily imagine that there are devices out there which provide functionality beyond what a regular LED will provide. So perhaps for things such as mobile phones, which typically use a plain LED to illuminate the surroundings, an LED wrapped into something that emulates the flash functionality could work. But I doubt that the LED subsystem is a good fit for anything beyond that.
I originally thought one way to do this could be to make it as easy as possible to support both APIs in driver which some aregued, to which I agree, is rather poor desing.
Does the LED API have a user space interface library like libv4l2? If yes, one option oculd be to implement the wrapper between the V4L2 and LED APIs there so that the applications using the LED API could also access those devices that implement the V4L2 flash API. Torch mode functionality is common between the two right now AFAIU,
The V4L2 flash API also provides a way to strobe the flash using an external trigger which typically connected to the sensor (and the user can choose between that and software strobe). I guess that and Xenon flashes aren't currently covered by the LED API.
The issue is that we have a LED API targetted at controlling LEDs, a V4L2 flash API targetted at controlling flashes, and hardware devices somewhere in the middle that can be used to provide LED or flash function. Merging the two APIs on the kernel side, with a compatibility layer for both kernel space and user space APIs, might be an idea worth investigating.
I'm so sorry for jumping in the discussion so late. Some how the emails from linux-media was archived in my Gmail and I haven't checkout this for several weeks.
I agree right now LED API doesn't quite fit for the usage of V4L2 Flash API. But I'd also like to see a unified API.
Currently, LED API are exported to user space as sysfs interface, while V4L2 Flash APIs are like IOCTL and user space library. We also merged some LED Flash trigger into LED subsystem. My basic idea is what about creating or expanding the LED Flash trigger driver and provide a well defined sysfs interface, which can be wrapped into user space libv4l2.
The biggest reason why we're not fond of sysfs-based APIs for media devices is that they can't provide atomicity. There's no way to set multiple parameters in a single operation.
We can't get rid of the sysfs LEDs API, but maybe we could have a unified kernel LED/flash subsystem that would provide both a sysfs-based API to ensure compatibility with current userspace software and an ioctl-based API (possibly through V4L2 controls). That way LED/flash devices would be registered with a single subsystem, and the corresponding drivers won't have to care about the API exposed to userspace. That would require a major refactoring of the in- kernel APIs though.
I agree this. I'm thinking about expanding the ledtrig-camera.c created by Milo Kim. This trigger will provide flashing and strobing control of a LED device and for sure the LED device driver like drivers/leds/leds-lm355x.c.
So we basically can do this:
- add V4L2 Flash subdev into ledtrig-camera.c. So this trigger driver
can provide trigger API to kernel drivers as well as V4L2 Flash API to userspace. 2. add the real flash torch functions into LED device driver like leds-lm355x.c, this driver will still provide sysfs interface and extended flash/torch control sysfs interface as well.
I'm not sure about whether we need some change in V4L2 internally. But actually Andrzej Hajda's patchset is quite straightforward, but we just need put those V4L2 Flash API into a LED trigger driver and the real flash/torch operation in a LED device driver.
Milo, could you please give some comments here?
General LED trigger APIs were created not for the application interface but for any kernel space driver. The LED camera trigger APIs are used by a camera driver, not application.
Some LED devices provide basic LED functionalities and high current features like a flash and a torch.(eg. LM3554, LM3642) The reason why I added the LED camera trigger is "for providing multiple operations(LEDs, flash and torch) by one LED device driver".
For example, A LED indicator is controlled via the LED sysfs. And flash and torch are controlled by a camera driver - calls exported LED trigger function, ledtrig_flash_ctrl().
My understanding is the V4L2 subsystem provides rich IOCTLs for the media device. I agree that the V4L2 is more proper interface for camera *application*.
So, my suggestion is: - If a device has only flash/torch functionalities, then register the driver as the V4L2 sub-device. - If a device provides not only flash/torch but also LED features, then create the driver as the MFD.
For example, LM3555 (and AS3645A) is used only for the camera. Then, this driver is registered as the V4L2 sub-device. (drivers/media/i2c/as3645a.c) - no change at all.
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).
Then, ledtrig-camera will be removed after we complete to change the driver structure.
Best regards, Milo
Hi,
On 16/10/13 03:49, Milo Kim wrote:
General LED trigger APIs were created not for the application interface but for any kernel space driver. The LED camera trigger APIs are used by a camera driver, not application.
Some LED devices provide basic LED functionalities and high current features like a flash and a torch.(eg. LM3554, LM3642) The reason why I added the LED camera trigger is "for providing multiple operations(LEDs, flash and torch) by one LED device driver".
For example, A LED indicator is controlled via the LED sysfs. And flash and torch are controlled by a camera driver - calls exported LED trigger function, ledtrig_flash_ctrl().
My understanding is the V4L2 subsystem provides rich IOCTLs for the media device. I agree that the V4L2 is more proper interface for camera *application*.
So, my suggestion is:
- If a device has only flash/torch functionalities, then register the
driver as the V4L2 sub-device.
Presumably it's not something we want. I think a core module is needed so drivers can expose both sysfs LED API and V4L2 Flash API with minimal effort for a single device. Then LED API would be extended with standard attributes for Torch/Flash and user applications can use either sysfs or V4L2 subdev/controls API. No need to worry that for some of the devices the kernel will expose only the sysfs and for some only the V4L2 interface.
Also for some multifunction devices integrating features like PMIC, clock generator, Flash/Torch LED driver, etc. the LED might be used for different purpose than originally intended. E.g. Torch LED as an indicator. So it is not correct IMO to select a specific API based on device's primary purpose only. I think there should be more flexibility.
- If a device provides not only flash/torch but also LED features,
then create the driver as the MFD.
For example, LM3555 (and AS3645A) is used only for the camera. Then, this driver is registered as the V4L2 sub-device. (drivers/media/i2c/as3645a.c) - no change at all.
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).
Then, ledtrig-camera will be removed after we complete to change the driver structure.
I'm not sure it needs to be removed. We will still have hardware and software triggered Flash LEDs. What would provide ledtrig-camera's current functionality when you remove it ?
-- Regards, Sylwester
On Tue, Oct 15, 2013 at 6:49 PM, Milo Kim milo.kim@ti.com wrote:
Hi Bryan,
On 10/16/2013 03:37 AM, Bryan Wu wrote:
On Fri, Oct 11, 2013 at 12:38 AM, Laurent Pinchart laurent.pinchart@ideasonboard.com wrote:
Hi Bryan,
On Thursday 10 October 2013 17:02:18 Bryan Wu wrote:
On Mon, Oct 7, 2013 at 3:24 PM, Laurent Pinchart wrote:
On Tuesday 08 October 2013 00:06:23 Sakari Ailus wrote:
On Tue, Sep 24, 2013 at 11:20:53AM +0200, Thierry Reding wrote: > > On Mon, Sep 23, 2013 at 10:27:06PM +0200, Sylwester Nawrocki wrote: >> >> On 09/23/2013 06:37 PM, Oliver Schinagl wrote: >>> >>> On 09/23/13 16:45, Sylwester Nawrocki wrote: >>>> >>>> Hi, >>>> >>>> I would like to have a short discussion on LED flash devices >>>> support >>>> in the kernel. Currently there are two APIs: the V4L2 and LED >>>> class >>>> API exposed by the kernel, which I believe is not good from user >>>> space POV. Generic applications will need to implement both APIs. >>>> I >>>> think we should decide whether to extend the led class API to add >>>> support for more advanced LED controllers there or continue to use >>>> the both APIs with overlapping functionality. There has been some >>>> discussion about this on the ML, but without any consensus reached >>>> [1]. >>> >>> >>> What about the linux-pwm framework and its support for the >>> backlight >>> via dts? >>> >>> Or am I talking way to uninformed here. Copying backlight to >>> flashlight with some minor modification sounds sensible in a way... >> >> >> I'd assume we don't need yet another user interface for the LEDs ;) >> AFAICS the PWM subsystem exposes pretty much raw interface in sysfs. >> The PWM LED controllers are already handled in the leds-class API, >> there is the leds_pwm driver (drivers/leds/leds-pwm.c). >> >> I'm adding linux-pwm and linux-leds maintainers at Cc so someone may >> correct me if I got anything wrong. > > > The PWM subsystem is most definitely not a good fit for this. The > only > thing it provides is a way for other drivers to access a PWM device > and > use it for some specific purpose (pwm-backlight, leds-pwm). > > The sysfs support is a convenience for people that needs to use a PWM > in a way for which no driver framework exists, or for which it > doesn't > make sense to write a driver. Or for testing. > >> Presumably, what we need is a few enhancements to support in a >> standard way devices like MAX77693, LM3560 or MAX8997. There is >> already a led class driver for the MAX8997 LED controller >> (drivers/leds/leds-max8997.c), but it uses some device-specific >> sysfs >> attributes. >> >> Thus similar devices are currently being handled by different >> subsystems. The split between the V4L2 Flash and the leds class API >> WRT to Flash LED controller drivers is included in RFC [1], it seems >> still up to date. >> >>>> [1] http://www.spinics.net/lists/linux-leds/msg00899.html > > > Perhaps it would make sense for V4L2 to be able to use a LED as > exposed > by the LED subsystem and wrap it so that it can be integrated with > V4L2? If functionality is missing from the LED subsystem I suppose > that > could be added.
The V4L2 flash API supports also xenon flashes, not only LED ones. That said, I agree there's a common subset of functionality most LED flash controllers implement.
> If I understand correctly, the V4L2 subsystem uses LEDs as flashes > for > camera devices. I can easily imagine that there are devices out there > which provide functionality beyond what a regular LED will provide. > So > perhaps for things such as mobile phones, which typically use a plain > LED to illuminate the surroundings, an LED wrapped into something > that > emulates the flash functionality could work. But I doubt that the LED > subsystem is a good fit for anything beyond that.
I originally thought one way to do this could be to make it as easy as possible to support both APIs in driver which some aregued, to which I agree, is rather poor desing.
Does the LED API have a user space interface library like libv4l2? If yes, one option oculd be to implement the wrapper between the V4L2 and LED APIs there so that the applications using the LED API could also access those devices that implement the V4L2 flash API. Torch mode functionality is common between the two right now AFAIU,
The V4L2 flash API also provides a way to strobe the flash using an external trigger which typically connected to the sensor (and the user can choose between that and software strobe). I guess that and Xenon flashes aren't currently covered by the LED API.
The issue is that we have a LED API targetted at controlling LEDs, a V4L2 flash API targetted at controlling flashes, and hardware devices somewhere in the middle that can be used to provide LED or flash function. Merging the two APIs on the kernel side, with a compatibility layer for both kernel space and user space APIs, might be an idea worth investigating.
I'm so sorry for jumping in the discussion so late. Some how the emails from linux-media was archived in my Gmail and I haven't checkout this for several weeks.
I agree right now LED API doesn't quite fit for the usage of V4L2 Flash API. But I'd also like to see a unified API.
Currently, LED API are exported to user space as sysfs interface, while V4L2 Flash APIs are like IOCTL and user space library. We also merged some LED Flash trigger into LED subsystem. My basic idea is what about creating or expanding the LED Flash trigger driver and provide a well defined sysfs interface, which can be wrapped into user space libv4l2.
The biggest reason why we're not fond of sysfs-based APIs for media devices is that they can't provide atomicity. There's no way to set multiple parameters in a single operation.
We can't get rid of the sysfs LEDs API, but maybe we could have a unified kernel LED/flash subsystem that would provide both a sysfs-based API to ensure compatibility with current userspace software and an ioctl-based API (possibly through V4L2 controls). That way LED/flash devices would be registered with a single subsystem, and the corresponding drivers won't have to care about the API exposed to userspace. That would require a major refactoring of the in- kernel APIs though.
I agree this. I'm thinking about expanding the ledtrig-camera.c created by Milo Kim. This trigger will provide flashing and strobing control of a LED device and for sure the LED device driver like drivers/leds/leds-lm355x.c.
So we basically can do this:
- add V4L2 Flash subdev into ledtrig-camera.c. So this trigger driver
can provide trigger API to kernel drivers as well as V4L2 Flash API to userspace. 2. add the real flash torch functions into LED device driver like leds-lm355x.c, this driver will still provide sysfs interface and extended flash/torch control sysfs interface as well.
I'm not sure about whether we need some change in V4L2 internally. But actually Andrzej Hajda's patchset is quite straightforward, but we just need put those V4L2 Flash API into a LED trigger driver and the real flash/torch operation in a LED device driver.
Milo, could you please give some comments here?
General LED trigger APIs were created not for the application interface but for any kernel space driver. The LED camera trigger APIs are used by a camera driver, not application.
That's basically correct, but trigger sometime can also provide sysfs interface which might be used by user space app.
Actually this camera flash/torch trigger API can also be used by V4L2 Flash subdev. We create a V4L2 Flash subdev in the driver, which will expose V4L2 API to user space. And this V4L2 Flash subdev will use this flash/torch trigger API to talk with our LED core and it really doesn't need to know the details about the LED flash/torch chip, if we can provide a good interface between trigger and LED device driver.
So benefits are a) one trigger/V4L2 Flash subdev driver can be used by multiple LED chips b) LED chip driver just need to provide standard or extended LED API to support flash/torch c) LED chip driver still keep those LED sysfs interface to user space and won't break user space application
Some LED devices provide basic LED functionalities and high current features like a flash and a torch.(eg. LM3554, LM3642) The reason why I added the LED camera trigger is "for providing multiple operations(LEDs, flash and torch) by one LED device driver".
For example, A LED indicator is controlled via the LED sysfs. And flash and torch are controlled by a camera driver - calls exported LED trigger function, ledtrig_flash_ctrl().
My understanding is the V4L2 subsystem provides rich IOCTLs for the media device. I agree that the V4L2 is more proper interface for camera *application*.
So, my suggestion is:
- If a device has only flash/torch functionalities, then register the
driver as the V4L2 sub-device.
- If a device provides not only flash/torch but also LED features, then
create the driver as the MFD.
We really don't need to separate them, one LED device driver can provide flash/torch/normal functions in on driver. I think LED device driver is trying to provide the LED chip's hardware functions, like flash/torch/indicator etc. how to use it, we can choose different trigger. That gives us the maxim flexibility.
For example, LM3555 (and AS3645A) is used only for the camera. Then, this driver is registered as the V4L2 sub-device. (drivers/media/i2c/as3645a.c) - no change at all.
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.
Thanks, -Bryan
Then, ledtrig-camera will be removed after we complete to change the driver structure.
Best regards, Milo
Hi Bryan,
On 10/17/2013 02:17 AM, Bryan Wu wrote:
On Tue, Oct 15, 2013 at 6:49 PM, Milo Kim milo.kim@ti.com wrote:
Hi Bryan,
On 10/16/2013 03:37 AM, Bryan Wu wrote:
On Fri, Oct 11, 2013 at 12:38 AM, Laurent Pinchart laurent.pinchart@ideasonboard.com wrote:
Hi Bryan,
On Thursday 10 October 2013 17:02:18 Bryan Wu wrote:
On Mon, Oct 7, 2013 at 3:24 PM, Laurent Pinchart wrote:
On Tuesday 08 October 2013 00:06:23 Sakari Ailus wrote: > > On Tue, Sep 24, 2013 at 11:20:53AM +0200, Thierry Reding wrote: >> >> On Mon, Sep 23, 2013 at 10:27:06PM +0200, Sylwester Nawrocki wrote: >>> >>> On 09/23/2013 06:37 PM, Oliver Schinagl wrote: >>>> >>>> On 09/23/13 16:45, Sylwester Nawrocki wrote: >>>>> >>>>> Hi, >>>>> >>>>> I would like to have a short discussion on LED flash devices >>>>> support >>>>> in the kernel. Currently there are two APIs: the V4L2 and LED >>>>> class >>>>> API exposed by the kernel, which I believe is not good from user >>>>> space POV. Generic applications will need to implement both APIs. >>>>> I >>>>> think we should decide whether to extend the led class API to add >>>>> support for more advanced LED controllers there or continue to use >>>>> the both APIs with overlapping functionality. There has been some >>>>> discussion about this on the ML, but without any consensus reached >>>>> [1]. >>>> >>>> >>>> What about the linux-pwm framework and its support for the >>>> backlight >>>> via dts? >>>> >>>> Or am I talking way to uninformed here. Copying backlight to >>>> flashlight with some minor modification sounds sensible in a way... >>> >>> >>> I'd assume we don't need yet another user interface for the LEDs ;) >>> AFAICS the PWM subsystem exposes pretty much raw interface in sysfs. >>> The PWM LED controllers are already handled in the leds-class API, >>> there is the leds_pwm driver (drivers/leds/leds-pwm.c). >>> >>> I'm adding linux-pwm and linux-leds maintainers at Cc so someone may >>> correct me if I got anything wrong. >> >> >> The PWM subsystem is most definitely not a good fit for this. The >> only >> thing it provides is a way for other drivers to access a PWM device >> and >> use it for some specific purpose (pwm-backlight, leds-pwm). >> >> The sysfs support is a convenience for people that needs to use a PWM >> in a way for which no driver framework exists, or for which it >> doesn't >> make sense to write a driver. Or for testing. >> >>> Presumably, what we need is a few enhancements to support in a >>> standard way devices like MAX77693, LM3560 or MAX8997. There is >>> already a led class driver for the MAX8997 LED controller >>> (drivers/leds/leds-max8997.c), but it uses some device-specific >>> sysfs >>> attributes. >>> >>> Thus similar devices are currently being handled by different >>> subsystems. The split between the V4L2 Flash and the leds class API >>> WRT to Flash LED controller drivers is included in RFC [1], it seems >>> still up to date. >>> >>>>> [1] http://www.spinics.net/lists/linux-leds/msg00899.html >> >> >> Perhaps it would make sense for V4L2 to be able to use a LED as >> exposed >> by the LED subsystem and wrap it so that it can be integrated with >> V4L2? If functionality is missing from the LED subsystem I suppose >> that >> could be added. > > > The V4L2 flash API supports also xenon flashes, not only LED ones. > That > said, I agree there's a common subset of functionality most LED flash > controllers implement. > >> If I understand correctly, the V4L2 subsystem uses LEDs as flashes >> for >> camera devices. I can easily imagine that there are devices out there >> which provide functionality beyond what a regular LED will provide. >> So >> perhaps for things such as mobile phones, which typically use a plain >> LED to illuminate the surroundings, an LED wrapped into something >> that >> emulates the flash functionality could work. But I doubt that the LED >> subsystem is a good fit for anything beyond that. > > > I originally thought one way to do this could be to make it as easy as > possible to support both APIs in driver which some aregued, to which I > agree, is rather poor desing. > > Does the LED API have a user space interface library like libv4l2? If > yes, one option oculd be to implement the wrapper between the V4L2 and > LED APIs there so that the applications using the LED API could also > access those devices that implement the V4L2 flash API. Torch mode > functionality is common between the two right now AFAIU, > > The V4L2 flash API also provides a way to strobe the flash using an > external trigger which typically connected to the sensor (and the user > can choose between that and software strobe). I guess that and Xenon > flashes aren't currently covered by the LED API.
The issue is that we have a LED API targetted at controlling LEDs, a V4L2 flash API targetted at controlling flashes, and hardware devices somewhere in the middle that can be used to provide LED or flash function. Merging the two APIs on the kernel side, with a compatibility layer for both kernel space and user space APIs, might be an idea worth investigating.
I'm so sorry for jumping in the discussion so late. Some how the emails from linux-media was archived in my Gmail and I haven't checkout this for several weeks.
I agree right now LED API doesn't quite fit for the usage of V4L2 Flash API. But I'd also like to see a unified API.
Currently, LED API are exported to user space as sysfs interface, while V4L2 Flash APIs are like IOCTL and user space library. We also merged some LED Flash trigger into LED subsystem. My basic idea is what about creating or expanding the LED Flash trigger driver and provide a well defined sysfs interface, which can be wrapped into user space libv4l2.
The biggest reason why we're not fond of sysfs-based APIs for media devices is that they can't provide atomicity. There's no way to set multiple parameters in a single operation.
We can't get rid of the sysfs LEDs API, but maybe we could have a unified kernel LED/flash subsystem that would provide both a sysfs-based API to ensure compatibility with current userspace software and an ioctl-based API (possibly through V4L2 controls). That way LED/flash devices would be registered with a single subsystem, and the corresponding drivers won't have to care about the API exposed to userspace. That would require a major refactoring of the in- kernel APIs though.
I agree this. I'm thinking about expanding the ledtrig-camera.c created by Milo Kim. This trigger will provide flashing and strobing control of a LED device and for sure the LED device driver like drivers/leds/leds-lm355x.c.
So we basically can do this:
- add V4L2 Flash subdev into ledtrig-camera.c. So this trigger driver
can provide trigger API to kernel drivers as well as V4L2 Flash API to userspace. 2. add the real flash torch functions into LED device driver like leds-lm355x.c, this driver will still provide sysfs interface and extended flash/torch control sysfs interface as well.
I'm not sure about whether we need some change in V4L2 internally. But actually Andrzej Hajda's patchset is quite straightforward, but we just need put those V4L2 Flash API into a LED trigger driver and the real flash/torch operation in a LED device driver.
Milo, could you please give some comments here?
General LED trigger APIs were created not for the application interface but for any kernel space driver. The LED camera trigger APIs are used by a camera driver, not application.
That's basically correct, but trigger sometime can also provide sysfs interface which might be used by user space app.
Actually this camera flash/torch trigger API can also be used by V4L2 Flash subdev. We create a V4L2 Flash subdev in the driver, which will expose V4L2 API to user space. And this V4L2 Flash subdev will use this flash/torch trigger API to talk with our LED core and it really doesn't need to know the details about the LED flash/torch chip, if we can provide a good interface between trigger and LED device driver.
So benefits are a) one trigger/V4L2 Flash subdev driver can be used by multiple LED chips b) LED chip driver just need to provide standard or extended LED API to support flash/torch c) LED chip driver still keep those LED sysfs interface to user space and won't break user space application
Some LED devices provide basic LED functionalities and high current features like a flash and a torch.(eg. LM3554, LM3642) The reason why I added the LED camera trigger is "for providing multiple operations(LEDs, flash and torch) by one LED device driver".
For example, A LED indicator is controlled via the LED sysfs. And flash and torch are controlled by a camera driver - calls exported LED trigger function, ledtrig_flash_ctrl().
My understanding is the V4L2 subsystem provides rich IOCTLs for the media device. I agree that the V4L2 is more proper interface for camera *application*.
So, my suggestion is:
- If a device has only flash/torch functionalities, then register the
driver as the V4L2 sub-device.
- If a device provides not only flash/torch but also LED features, then
create the driver as the MFD.
We really don't need to separate them, one LED device driver can provide flash/torch/normal functions in on driver. I think LED device driver is trying to provide the LED chip's hardware functions, like flash/torch/indicator etc. how to use it, we can choose different trigger. That gives us the maxim flexibility.
For example, LM3555 (and AS3645A) is used only for the camera. Then, this driver is registered as the V4L2 sub-device. (drivers/media/i2c/as3645a.c) - no change at all.
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.
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
On Wed, Oct 16, 2013 at 4:36 PM, Milo Kim milo.kim@ti.com wrote:
Hi Bryan,
On 10/17/2013 02:17 AM, Bryan Wu wrote:
On Tue, Oct 15, 2013 at 6:49 PM, Milo Kim milo.kim@ti.com wrote:
Hi Bryan,
On 10/16/2013 03:37 AM, Bryan Wu wrote:
On Fri, Oct 11, 2013 at 12:38 AM, Laurent Pinchart laurent.pinchart@ideasonboard.com wrote:
Hi Bryan,
On Thursday 10 October 2013 17:02:18 Bryan Wu wrote:
On Mon, Oct 7, 2013 at 3:24 PM, Laurent Pinchart wrote: > > > On Tuesday 08 October 2013 00:06:23 Sakari Ailus wrote: >> >> >> On Tue, Sep 24, 2013 at 11:20:53AM +0200, Thierry Reding wrote: >>> >>> >>> On Mon, Sep 23, 2013 at 10:27:06PM +0200, Sylwester Nawrocki wrote: >>>> >>>> >>>> On 09/23/2013 06:37 PM, Oliver Schinagl wrote: >>>>> >>>>> >>>>> On 09/23/13 16:45, Sylwester Nawrocki wrote: >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> I would like to have a short discussion on LED flash devices >>>>>> support >>>>>> in the kernel. Currently there are two APIs: the V4L2 and LED >>>>>> class >>>>>> API exposed by the kernel, which I believe is not good from user >>>>>> space POV. Generic applications will need to implement both >>>>>> APIs. >>>>>> I >>>>>> think we should decide whether to extend the led class API to >>>>>> add >>>>>> support for more advanced LED controllers there or continue to >>>>>> use >>>>>> the both APIs with overlapping functionality. There has been >>>>>> some >>>>>> discussion about this on the ML, but without any consensus >>>>>> reached >>>>>> [1]. >>>>> >>>>> >>>>> >>>>> What about the linux-pwm framework and its support for the >>>>> backlight >>>>> via dts? >>>>> >>>>> Or am I talking way to uninformed here. Copying backlight to >>>>> flashlight with some minor modification sounds sensible in a >>>>> way... >>>> >>>> >>>> >>>> I'd assume we don't need yet another user interface for the LEDs >>>> ;) >>>> AFAICS the PWM subsystem exposes pretty much raw interface in >>>> sysfs. >>>> The PWM LED controllers are already handled in the leds-class API, >>>> there is the leds_pwm driver (drivers/leds/leds-pwm.c). >>>> >>>> I'm adding linux-pwm and linux-leds maintainers at Cc so someone >>>> may >>>> correct me if I got anything wrong. >>> >>> >>> >>> The PWM subsystem is most definitely not a good fit for this. The >>> only >>> thing it provides is a way for other drivers to access a PWM device >>> and >>> use it for some specific purpose (pwm-backlight, leds-pwm). >>> >>> The sysfs support is a convenience for people that needs to use a >>> PWM >>> in a way for which no driver framework exists, or for which it >>> doesn't >>> make sense to write a driver. Or for testing. >>> >>>> Presumably, what we need is a few enhancements to support in a >>>> standard way devices like MAX77693, LM3560 or MAX8997. There is >>>> already a led class driver for the MAX8997 LED controller >>>> (drivers/leds/leds-max8997.c), but it uses some device-specific >>>> sysfs >>>> attributes. >>>> >>>> Thus similar devices are currently being handled by different >>>> subsystems. The split between the V4L2 Flash and the leds class >>>> API >>>> WRT to Flash LED controller drivers is included in RFC [1], it >>>> seems >>>> still up to date. >>>> >>>>>> [1] http://www.spinics.net/lists/linux-leds/msg00899.html >>> >>> >>> >>> Perhaps it would make sense for V4L2 to be able to use a LED as >>> exposed >>> by the LED subsystem and wrap it so that it can be integrated with >>> V4L2? If functionality is missing from the LED subsystem I suppose >>> that >>> could be added. >> >> >> >> The V4L2 flash API supports also xenon flashes, not only LED ones. >> That >> said, I agree there's a common subset of functionality most LED >> flash >> controllers implement. >> >>> If I understand correctly, the V4L2 subsystem uses LEDs as flashes >>> for >>> camera devices. I can easily imagine that there are devices out >>> there >>> which provide functionality beyond what a regular LED will provide. >>> So >>> perhaps for things such as mobile phones, which typically use a >>> plain >>> LED to illuminate the surroundings, an LED wrapped into something >>> that >>> emulates the flash functionality could work. But I doubt that the >>> LED >>> subsystem is a good fit for anything beyond that. >> >> >> >> I originally thought one way to do this could be to make it as easy >> as >> possible to support both APIs in driver which some aregued, to which >> I >> agree, is rather poor desing. >> >> Does the LED API have a user space interface library like libv4l2? >> If >> yes, one option oculd be to implement the wrapper between the V4L2 >> and >> LED APIs there so that the applications using the LED API could also >> access those devices that implement the V4L2 flash API. Torch mode >> functionality is common between the two right now AFAIU, >> >> The V4L2 flash API also provides a way to strobe the flash using an >> external trigger which typically connected to the sensor (and the >> user >> can choose between that and software strobe). I guess that and Xenon >> flashes aren't currently covered by the LED API. > > > > The issue is that we have a LED API targetted at controlling LEDs, a > V4L2 > flash API targetted at controlling flashes, and hardware devices > somewhere > in the middle that can be used to provide LED or flash function. > Merging > the two APIs on the kernel side, with a compatibility layer for both > kernel space and user space APIs, might be an idea worth > investigating.
I'm so sorry for jumping in the discussion so late. Some how the emails from linux-media was archived in my Gmail and I haven't checkout this for several weeks.
I agree right now LED API doesn't quite fit for the usage of V4L2 Flash API. But I'd also like to see a unified API.
Currently, LED API are exported to user space as sysfs interface, while V4L2 Flash APIs are like IOCTL and user space library. We also merged some LED Flash trigger into LED subsystem. My basic idea is what about creating or expanding the LED Flash trigger driver and provide a well defined sysfs interface, which can be wrapped into user space libv4l2.
The biggest reason why we're not fond of sysfs-based APIs for media devices is that they can't provide atomicity. There's no way to set multiple parameters in a single operation.
We can't get rid of the sysfs LEDs API, but maybe we could have a unified kernel LED/flash subsystem that would provide both a sysfs-based API to ensure compatibility with current userspace software and an ioctl-based API (possibly through V4L2 controls). That way LED/flash devices would be registered with a single subsystem, and the corresponding drivers won't have to care about the API exposed to userspace. That would require a major refactoring of the in- kernel APIs though.
I agree this. I'm thinking about expanding the ledtrig-camera.c created by Milo Kim. This trigger will provide flashing and strobing control of a LED device and for sure the LED device driver like drivers/leds/leds-lm355x.c.
So we basically can do this:
- add V4L2 Flash subdev into ledtrig-camera.c. So this trigger driver
can provide trigger API to kernel drivers as well as V4L2 Flash API to userspace. 2. add the real flash torch functions into LED device driver like leds-lm355x.c, this driver will still provide sysfs interface and extended flash/torch control sysfs interface as well.
I'm not sure about whether we need some change in V4L2 internally. But actually Andrzej Hajda's patchset is quite straightforward, but we just need put those V4L2 Flash API into a LED trigger driver and the real flash/torch operation in a LED device driver.
Milo, could you please give some comments here?
General LED trigger APIs were created not for the application interface but for any kernel space driver. The LED camera trigger APIs are used by a camera driver, not application.
That's basically correct, but trigger sometime can also provide sysfs interface which might be used by user space app.
Actually this camera flash/torch trigger API can also be used by V4L2 Flash subdev. We create a V4L2 Flash subdev in the driver, which will expose V4L2 API to user space. And this V4L2 Flash subdev will use this flash/torch trigger API to talk with our LED core and it really doesn't need to know the details about the LED flash/torch chip, if we can provide a good interface between trigger and LED device driver.
So benefits are a) one trigger/V4L2 Flash subdev driver can be used by multiple LED chips b) LED chip driver just need to provide standard or extended LED API to support flash/torch c) LED chip driver still keep those LED sysfs interface to user space and won't break user space application
Some LED devices provide basic LED functionalities and high current features like a flash and a torch.(eg. LM3554, LM3642) The reason why I added the LED camera trigger is "for providing multiple operations(LEDs, flash and torch) by one LED device driver".
For example, A LED indicator is controlled via the LED sysfs. And flash and torch are controlled by a camera driver - calls exported LED trigger function, ledtrig_flash_ctrl().
My understanding is the V4L2 subsystem provides rich IOCTLs for the media device. I agree that the V4L2 is more proper interface for camera *application*.
So, my suggestion is:
- If a device has only flash/torch functionalities, then register the
driver as the V4L2 sub-device.
- If a device provides not only flash/torch but also LED features,
then create the driver as the MFD.
We really don't need to separate them, one LED device driver can provide flash/torch/normal functions in on driver. I think LED device driver is trying to provide the LED chip's hardware functions, like flash/torch/indicator etc. how to use it, we can choose different trigger. That gives us the maxim flexibility.
For example, LM3555 (and AS3645A) is used only for the camera. Then, this driver is registered as the V4L2 sub-device. (drivers/media/i2c/as3645a.c) - no change at all.
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.
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.
Yeah, my proposal is to add V4L2 interface into ledtrig-camera.c. For existing chip driver like yours LM3555, I guess we don't need to big change but for future support for new chip or adding flash/torch to existing chip, we need to create or change chip driver. Because eventually those flash/torch/indicator operation happens in chip driver.
Thanks, -Bryan
On Wed, Oct 16, 2013 at 4:54 PM, Bryan Wu cooloney@gmail.com wrote:
On Wed, Oct 16, 2013 at 4:36 PM, Milo Kim milo.kim@ti.com wrote:
Hi Bryan,
On 10/17/2013 02:17 AM, Bryan Wu wrote:
On Tue, Oct 15, 2013 at 6:49 PM, Milo Kim milo.kim@ti.com wrote:
Hi Bryan,
On 10/16/2013 03:37 AM, Bryan Wu wrote:
On Fri, Oct 11, 2013 at 12:38 AM, Laurent Pinchart laurent.pinchart@ideasonboard.com wrote:
Hi Bryan,
On Thursday 10 October 2013 17:02:18 Bryan Wu wrote: > > > On Mon, Oct 7, 2013 at 3:24 PM, Laurent Pinchart wrote: >> >> >> On Tuesday 08 October 2013 00:06:23 Sakari Ailus wrote: >>> >>> >>> On Tue, Sep 24, 2013 at 11:20:53AM +0200, Thierry Reding wrote: >>>> >>>> >>>> On Mon, Sep 23, 2013 at 10:27:06PM +0200, Sylwester Nawrocki wrote: >>>>> >>>>> >>>>> On 09/23/2013 06:37 PM, Oliver Schinagl wrote: >>>>>> >>>>>> >>>>>> On 09/23/13 16:45, Sylwester Nawrocki wrote: >>>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I would like to have a short discussion on LED flash devices >>>>>>> support >>>>>>> in the kernel. Currently there are two APIs: the V4L2 and LED >>>>>>> class >>>>>>> API exposed by the kernel, which I believe is not good from user >>>>>>> space POV. Generic applications will need to implement both >>>>>>> APIs. >>>>>>> I >>>>>>> think we should decide whether to extend the led class API to >>>>>>> add >>>>>>> support for more advanced LED controllers there or continue to >>>>>>> use >>>>>>> the both APIs with overlapping functionality. There has been >>>>>>> some >>>>>>> discussion about this on the ML, but without any consensus >>>>>>> reached >>>>>>> [1]. >>>>>> >>>>>> >>>>>> >>>>>> What about the linux-pwm framework and its support for the >>>>>> backlight >>>>>> via dts? >>>>>> >>>>>> Or am I talking way to uninformed here. Copying backlight to >>>>>> flashlight with some minor modification sounds sensible in a >>>>>> way... >>>>> >>>>> >>>>> >>>>> I'd assume we don't need yet another user interface for the LEDs >>>>> ;) >>>>> AFAICS the PWM subsystem exposes pretty much raw interface in >>>>> sysfs. >>>>> The PWM LED controllers are already handled in the leds-class API, >>>>> there is the leds_pwm driver (drivers/leds/leds-pwm.c). >>>>> >>>>> I'm adding linux-pwm and linux-leds maintainers at Cc so someone >>>>> may >>>>> correct me if I got anything wrong. >>>> >>>> >>>> >>>> The PWM subsystem is most definitely not a good fit for this. The >>>> only >>>> thing it provides is a way for other drivers to access a PWM device >>>> and >>>> use it for some specific purpose (pwm-backlight, leds-pwm). >>>> >>>> The sysfs support is a convenience for people that needs to use a >>>> PWM >>>> in a way for which no driver framework exists, or for which it >>>> doesn't >>>> make sense to write a driver. Or for testing. >>>> >>>>> Presumably, what we need is a few enhancements to support in a >>>>> standard way devices like MAX77693, LM3560 or MAX8997. There is >>>>> already a led class driver for the MAX8997 LED controller >>>>> (drivers/leds/leds-max8997.c), but it uses some device-specific >>>>> sysfs >>>>> attributes. >>>>> >>>>> Thus similar devices are currently being handled by different >>>>> subsystems. The split between the V4L2 Flash and the leds class >>>>> API >>>>> WRT to Flash LED controller drivers is included in RFC [1], it >>>>> seems >>>>> still up to date. >>>>> >>>>>>> [1] http://www.spinics.net/lists/linux-leds/msg00899.html >>>> >>>> >>>> >>>> Perhaps it would make sense for V4L2 to be able to use a LED as >>>> exposed >>>> by the LED subsystem and wrap it so that it can be integrated with >>>> V4L2? If functionality is missing from the LED subsystem I suppose >>>> that >>>> could be added. >>> >>> >>> >>> The V4L2 flash API supports also xenon flashes, not only LED ones. >>> That >>> said, I agree there's a common subset of functionality most LED >>> flash >>> controllers implement. >>> >>>> If I understand correctly, the V4L2 subsystem uses LEDs as flashes >>>> for >>>> camera devices. I can easily imagine that there are devices out >>>> there >>>> which provide functionality beyond what a regular LED will provide. >>>> So >>>> perhaps for things such as mobile phones, which typically use a >>>> plain >>>> LED to illuminate the surroundings, an LED wrapped into something >>>> that >>>> emulates the flash functionality could work. But I doubt that the >>>> LED >>>> subsystem is a good fit for anything beyond that. >>> >>> >>> >>> I originally thought one way to do this could be to make it as easy >>> as >>> possible to support both APIs in driver which some aregued, to which >>> I >>> agree, is rather poor desing. >>> >>> Does the LED API have a user space interface library like libv4l2? >>> If >>> yes, one option oculd be to implement the wrapper between the V4L2 >>> and >>> LED APIs there so that the applications using the LED API could also >>> access those devices that implement the V4L2 flash API. Torch mode >>> functionality is common between the two right now AFAIU, >>> >>> The V4L2 flash API also provides a way to strobe the flash using an >>> external trigger which typically connected to the sensor (and the >>> user >>> can choose between that and software strobe). I guess that and Xenon >>> flashes aren't currently covered by the LED API. >> >> >> >> The issue is that we have a LED API targetted at controlling LEDs, a >> V4L2 >> flash API targetted at controlling flashes, and hardware devices >> somewhere >> in the middle that can be used to provide LED or flash function. >> Merging >> the two APIs on the kernel side, with a compatibility layer for both >> kernel space and user space APIs, might be an idea worth >> investigating. > > > > I'm so sorry for jumping in the discussion so late. Some how the > emails from linux-media was archived in my Gmail and I haven't > checkout this for several weeks. > > I agree right now LED API doesn't quite fit for the usage of V4L2 > Flash API. But I'd also like to see a unified API. > > Currently, LED API are exported to user space as sysfs interface, > while V4L2 Flash APIs are like IOCTL and user space library. We also > merged some LED Flash trigger into LED subsystem. My basic idea is > what about creating or expanding the LED Flash trigger driver and > provide a well defined sysfs interface, which can be wrapped into user > space libv4l2.
The biggest reason why we're not fond of sysfs-based APIs for media devices is that they can't provide atomicity. There's no way to set multiple parameters in a single operation.
We can't get rid of the sysfs LEDs API, but maybe we could have a unified kernel LED/flash subsystem that would provide both a sysfs-based API to ensure compatibility with current userspace software and an ioctl-based API (possibly through V4L2 controls). That way LED/flash devices would be registered with a single subsystem, and the corresponding drivers won't have to care about the API exposed to userspace. That would require a major refactoring of the in- kernel APIs though.
I agree this. I'm thinking about expanding the ledtrig-camera.c created by Milo Kim. This trigger will provide flashing and strobing control of a LED device and for sure the LED device driver like drivers/leds/leds-lm355x.c.
So we basically can do this:
- add V4L2 Flash subdev into ledtrig-camera.c. So this trigger driver
can provide trigger API to kernel drivers as well as V4L2 Flash API to userspace. 2. add the real flash torch functions into LED device driver like leds-lm355x.c, this driver will still provide sysfs interface and extended flash/torch control sysfs interface as well.
I'm not sure about whether we need some change in V4L2 internally. But actually Andrzej Hajda's patchset is quite straightforward, but we just need put those V4L2 Flash API into a LED trigger driver and the real flash/torch operation in a LED device driver.
Milo, could you please give some comments here?
General LED trigger APIs were created not for the application interface but for any kernel space driver. The LED camera trigger APIs are used by a camera driver, not application.
That's basically correct, but trigger sometime can also provide sysfs interface which might be used by user space app.
Actually this camera flash/torch trigger API can also be used by V4L2 Flash subdev. We create a V4L2 Flash subdev in the driver, which will expose V4L2 API to user space. And this V4L2 Flash subdev will use this flash/torch trigger API to talk with our LED core and it really doesn't need to know the details about the LED flash/torch chip, if we can provide a good interface between trigger and LED device driver.
So benefits are a) one trigger/V4L2 Flash subdev driver can be used by multiple LED chips b) LED chip driver just need to provide standard or extended LED API to support flash/torch c) LED chip driver still keep those LED sysfs interface to user space and won't break user space application
Some LED devices provide basic LED functionalities and high current features like a flash and a torch.(eg. LM3554, LM3642) The reason why I added the LED camera trigger is "for providing multiple operations(LEDs, flash and torch) by one LED device driver".
For example, A LED indicator is controlled via the LED sysfs. And flash and torch are controlled by a camera driver - calls exported LED trigger function, ledtrig_flash_ctrl().
My understanding is the V4L2 subsystem provides rich IOCTLs for the media device. I agree that the V4L2 is more proper interface for camera *application*.
So, my suggestion is:
- If a device has only flash/torch functionalities, then register the
driver as the V4L2 sub-device.
- If a device provides not only flash/torch but also LED features,
then create the driver as the MFD.
We really don't need to separate them, one LED device driver can provide flash/torch/normal functions in on driver. I think LED device driver is trying to provide the LED chip's hardware functions, like flash/torch/indicator etc. how to use it, we can choose different trigger. That gives us the maxim flexibility.
For example, LM3555 (and AS3645A) is used only for the camera. Then, this driver is registered as the V4L2 sub-device. (drivers/media/i2c/as3645a.c) - no change at all.
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.
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.
Yeah, my proposal is to add V4L2 interface into ledtrig-camera.c. For existing chip driver like yours LM3555, I guess we don't need to big change but for future support for new chip or adding flash/torch to existing chip, we need to create or change chip driver. Because eventually those flash/torch/indicator operation happens in chip driver.
Thanks, -Bryan
Remove my old email address.
-Bryan
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
On Wed, Oct 16, 2013 at 5:12 PM, Andy Walls awalls@md.metrocast.net 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/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
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
Please find the multi selection api proposal attached.
See you in Edinburgh.
Thanks
On Sat, Oct 19, 2013 at 2:17 AM, Bryan Wu cooloney@gmail.com wrote:
On Wed, Oct 16, 2013 at 5:12 PM, Andy Walls awalls@md.metrocast.net 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/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
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
On Sat, Oct 19, 2013 at 1:25 PM, Ricardo Ribalda Delgado ricardo.ribalda@gmail.com wrote:
Please find the multi selection api proposal attached.
See you in Edinburgh.
Thanks
On Sat, Oct 19, 2013 at 2:17 AM, Bryan Wu cooloney@gmail.com wrote:
On Wed, Oct 16, 2013 at 5:12 PM, Andy Walls awalls@md.metrocast.net 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/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
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
Is the time and location of media mini-summit fixed? My colleague might show up if it's not conflicted with ARM mini-summit.
Thanks, -Bryan
On 10/21/2013 06:40 PM, Bryan Wu wrote:
On Sat, Oct 19, 2013 at 1:25 PM, Ricardo Ribalda Delgado ricardo.ribalda@gmail.com wrote:
Please find the multi selection api proposal attached.
See you in Edinburgh.
Thanks
On Sat, Oct 19, 2013 at 2:17 AM, Bryan Wu cooloney@gmail.com wrote:
On Wed, Oct 16, 2013 at 5:12 PM, Andy Walls awalls@md.metrocast.net 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/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
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
Is the time and location of media mini-summit fixed? My colleague might show up if it's not conflicted with ARM mini-summit.
It's in the Glamis room on Wednesday. We start at 9 am and the LED topic is currently scheduled as the second topic so I expect that it will be discussed between 9 and 10 am.
Regards,
Hans
I thought that i was second... btw could i borrow somebodys notebook for presenting the slides?
Thanks On 21 Oct 2013 19:53, "Hans Verkuil" hverkuil@xs4all.nl wrote:
On 10/21/2013 06:40 PM, Bryan Wu wrote:
On Sat, Oct 19, 2013 at 1:25 PM, Ricardo Ribalda Delgado ricardo.ribalda@gmail.com wrote:
Please find the multi selection api proposal attached.
See you in Edinburgh.
Thanks
On Sat, Oct 19, 2013 at 2:17 AM, Bryan Wu cooloney@gmail.com wrote:
On Wed, Oct 16, 2013 at 5:12 PM, Andy Walls awalls@md.metrocast.net
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/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
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
Is the time and location of media mini-summit fixed? My colleague might show up if it's not conflicted with ARM mini-summit.
It's in the Glamis room on Wednesday. We start at 9 am and the LED topic is currently scheduled as the second topic so I expect that it will be discussed between 9 and 10 am.
Regards,
Hans
On 10/21/2013 07:29 PM, Ricardo Ribalda Delgado wrote:
I thought that i was second...
You are right, I was looking at an older version.
The LED topic is third, around 9:50.
Sorry for the confusion.
btw could i borrow somebodys notebook for presenting the slides?
Sure. Put them on a USB stick or make them available on the web for download and I can present them for you. I've saved the slides you mailed me earlier to my laptop.
Regards,
Hans
Thanks
On 21 Oct 2013 19:53, "Hans Verkuil" <hverkuil@xs4all.nl mailto:hverkuil@xs4all.nl> wrote:
On 10/21/2013 06:40 PM, Bryan Wu wrote: > On Sat, Oct 19, 2013 at 1:25 PM, Ricardo Ribalda Delgado > <ricardo.ribalda@gmail.com <mailto:ricardo.ribalda@gmail.com>> wrote: >> Please find the multi selection api proposal attached. >> >> See you in Edinburgh. >> >> >> Thanks >> >> On Sat, Oct 19, 2013 at 2:17 AM, Bryan Wu <cooloney@gmail.com <mailto:cooloney@gmail.com>> wrote: >>> On Wed, Oct 16, 2013 at 5:12 PM, Andy Walls <awalls@md.metrocast.net <mailto:awalls@md.metrocast.net>> wrote: >>>> On Thu, 2013-10-17 <tel: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 >> >> > > Is the time and location of media mini-summit fixed? My colleague > might show up if it's not conflicted with ARM mini-summit. It's in the Glamis room on Wednesday. We start at 9 am and the LED topic is currently scheduled as the second topic so I expect that it will be discussed between 9 and 10 am. Regards, Hans
On 10/21/2013 06:52 PM, Hans Verkuil wrote:
On 10/21/2013 06:40 PM, Bryan Wu wrote:
Is the time and location of media mini-summit fixed? My colleague might show up if it's not conflicted with ARM mini-summit.
It's in the Glamis room on Wednesday. We start at 9 am and the LED topic is currently scheduled as the second topic so I expect that it will be discussed between 9 and 10 am.
I just posted the final (at least, I really hope it will be the final) version of the agenda to linux-media and media-workshop. The LED topic moved to a somewhat later slot and is currently scheduled for 10:50. All these times are tentative so for this topic you should probably be there at 10:30 to be safe.
Regards,
Hans
Resending using Bryan's correct email address.
On Mon, Sep 23, 2013 at 10:27:06PM +0200, Sylwester Nawrocki wrote:
On 09/23/2013 06:37 PM, Oliver Schinagl wrote:
On 09/23/13 16:45, Sylwester Nawrocki wrote:
Hi,
I would like to have a short discussion on LED flash devices support in the kernel. Currently there are two APIs: the V4L2 and LED class API exposed by the kernel, which I believe is not good from user space POV. Generic applications will need to implement both APIs. I think we should decide whether to extend the led class API to add support for more advanced LED controllers there or continue to use the both APIs with overlapping functionality. There has been some discussion about this on the ML, but without any consensus reached [1].
What about the linux-pwm framework and its support for the backlight via dts?
Or am I talking way to uninformed here. Copying backlight to flashlight with some minor modification sounds sensible in a way...
I'd assume we don't need yet another user interface for the LEDs ;) AFAICS the PWM subsystem exposes pretty much raw interface in sysfs. The PWM LED controllers are already handled in the leds-class API, there is the leds_pwm driver (drivers/leds/leds-pwm.c).
I'm adding linux-pwm and linux-leds maintainers at Cc so someone may correct me if I got anything wrong.
The PWM subsystem is most definitely not a good fit for this. The only thing it provides is a way for other drivers to access a PWM device and use it for some specific purpose (pwm-backlight, leds-pwm).
The sysfs support is a convenience for people that needs to use a PWM in a way for which no driver framework exists, or for which it doesn't make sense to write a driver. Or for testing.
Presumably, what we need is a few enhancements to support in a standard way devices like MAX77693, LM3560 or MAX8997. There is already a led class driver for the MAX8997 LED controller (drivers/leds/leds-max8997.c), but it uses some device-specific sysfs attributes.
Thus similar devices are currently being handled by different subsystems. The split between the V4L2 Flash and the leds class API WRT to Flash LED controller drivers is included in RFC [1], it seems still up to date.
Perhaps it would make sense for V4L2 to be able to use a LED as exposed by the LED subsystem and wrap it so that it can be integrated with V4L2? If functionality is missing from the LED subsystem I suppose that could be added.
If I understand correctly, the V4L2 subsystem uses LEDs as flashes for camera devices. I can easily imagine that there are devices out there which provide functionality beyond what a regular LED will provide. So perhaps for things such as mobile phones, which typically use a plain LED to illuminate the surroundings, an LED wrapped into something that emulates the flash functionality could work. But I doubt that the LED subsystem is a good fit for anything beyond that.
Thierry
Hi Oliver,
On Monday 23 September 2013 18:37:48 Oliver Schinagl wrote:
On 09/23/13 16:45, Sylwester Nawrocki wrote:
Hi,
I would like to have a short discussion on LED flash devices support in the kernel. Currently there are two APIs: the V4L2 and LED class API exposed by the kernel, which I believe is not good from user space POV. Generic applications will need to implement both APIs. I think we should decide whether to extend the led class API to add support for more advanced LED controllers there or continue to use the both APIs with overlapping functionality. There has been some discussion about this on the ML, but without any consensus reached [1].
What about the linux-pwm framework and its support for the backlight via dts?
Or am I talking way to uninformed here. Copying backlight to flashlight with some minor modification sounds sensible in a way...
Flash has more advanced requirements, such as internal/external trigger support, hardware timings control, overheat prevention, ... Furthermore, a flash API should not be limited to LEDs, as Xeon flashes are common and similar enough to be supported by the same API.
I would like to see the two APIs merged in a way, at least for flash devices.
Hi Hans,
On Tuesday 10 September 2013 11:34:32 Hans Verkuil wrote:
I have collected all the ideas up to now in a V2 of the agenda.
The items are grouped by the person(s) that suggested them. As done in the past those who suggested a topic and who will attend the mini-summit are expected to prepare for it, perhaps making a (very) small presentation if necessary.
[snip]
As it stands I don't think it will be possible to handle it all in one day. In particular the codec problem as mentioned by Oliver et al needs a lot of time. Should we set aside a separate day for just this? October 21 or 22 would work for me. I would really like to get some feedback on this. If we decide to go for a second day for this topic, then I can see if I can get a room. It looks like there is a lot of interest in getting this sorted, so brainstorming for a day might be quite useful.
I believe a second day would indeed be very useful. As the ARM kernel summit will take place on the 22nd and 23rd, I would vote for brainstorming on the 21st.
Note: my email availability will be limited in the next two weeks, especially next week, as I am abroad (LinuxCon and LPC).
On Tue 24 September 2013 12:59:44 Laurent Pinchart wrote:
Hi Hans,
On Tuesday 10 September 2013 11:34:32 Hans Verkuil wrote:
I have collected all the ideas up to now in a V2 of the agenda.
The items are grouped by the person(s) that suggested them. As done in the past those who suggested a topic and who will attend the mini-summit are expected to prepare for it, perhaps making a (very) small presentation if necessary.
[snip]
As it stands I don't think it will be possible to handle it all in one day. In particular the codec problem as mentioned by Oliver et al needs a lot of time. Should we set aside a separate day for just this? October 21 or 22 would work for me. I would really like to get some feedback on this. If we decide to go for a second day for this topic, then I can see if I can get a room. It looks like there is a lot of interest in getting this sorted, so brainstorming for a day might be quite useful.
I believe a second day would indeed be very useful. As the ARM kernel summit will take place on the 22nd and 23rd, I would vote for brainstorming on the 21st.
I'm working on the agenda and I think we have enough time to go through all the items in one day. It would be great if you can be present for either the morning or afternoon for the mini-summit. I have about 4 hours worth of topics for which your input would be much appreciated.
I would be happy to add another brainstorming day, but since Hugues won't be available on the 21st we can only do limited codec discussions, so we would need other topics as well. Proposals are welcome.
Regards,
Hans
Hi Hans,
On Tuesday 24 September 2013 13:24:25 Hans Verkuil wrote:
On Tue 24 September 2013 12:59:44 Laurent Pinchart wrote:
On Tuesday 10 September 2013 11:34:32 Hans Verkuil wrote:
I have collected all the ideas up to now in a V2 of the agenda.
The items are grouped by the person(s) that suggested them. As done in the past those who suggested a topic and who will attend the mini-summit are expected to prepare for it, perhaps making a (very) small presentation if necessary.
[snip]
As it stands I don't think it will be possible to handle it all in one day. In particular the codec problem as mentioned by Oliver et al needs a lot of time. Should we set aside a separate day for just this? October 21 or 22 would work for me. I would really like to get some feedback on this. If we decide to go for a second day for this topic, then I can see if I can get a room. It looks like there is a lot of interest in getting this sorted, so brainstorming for a day might be quite useful.
I believe a second day would indeed be very useful. As the ARM kernel summit will take place on the 22nd and 23rd, I would vote for brainstorming on the 21st.
I'm working on the agenda and I think we have enough time to go through all the items in one day. It would be great if you can be present for either the morning or afternoon for the mini-summit. I have about 4 hours worth of topics for which your input would be much appreciated.
The ARM KS agenda hasn't been published yet, so I can't tell when I'll be available. I've CC'ed you on an e-mail to Olof regarding this.
I would be happy to add another brainstorming day, but since Hugues won't be available on the 21st we can only do limited codec discussions, so we would need other topics as well. Proposals are welcome.
Brainstorming a property-based API is one topic that would benefit from longer discussions. I'm also always free to discuss CDF and how it would be related with V4L2 in the future :-)
Hi Hans and Laurent,
On Wed, Sep 25, 2013 at 12:39:11PM +0200, Laurent Pinchart wrote:
Hi Hans,
On Tuesday 24 September 2013 13:24:25 Hans Verkuil wrote:
On Tue 24 September 2013 12:59:44 Laurent Pinchart wrote:
On Tuesday 10 September 2013 11:34:32 Hans Verkuil wrote:
I have collected all the ideas up to now in a V2 of the agenda.
The items are grouped by the person(s) that suggested them. As done in the past those who suggested a topic and who will attend the mini-summit are expected to prepare for it, perhaps making a (very) small presentation if necessary.
[snip]
As it stands I don't think it will be possible to handle it all in one day. In particular the codec problem as mentioned by Oliver et al needs a lot of time. Should we set aside a separate day for just this? October 21 or 22 would work for me. I would really like to get some feedback on this. If we decide to go for a second day for this topic, then I can see if I can get a room. It looks like there is a lot of interest in getting this sorted, so brainstorming for a day might be quite useful.
I believe a second day would indeed be very useful. As the ARM kernel summit will take place on the 22nd and 23rd, I would vote for brainstorming on the 21st.
I'm working on the agenda and I think we have enough time to go through all the items in one day. It would be great if you can be present for either the morning or afternoon for the mini-summit. I have about 4 hours worth of topics for which your input would be much appreciated.
The ARM KS agenda hasn't been published yet, so I can't tell when I'll be available. I've CC'ed you on an e-mail to Olof regarding this.
I would be happy to add another brainstorming day, but since Hugues won't be available on the 21st we can only do limited codec discussions, so we would need other topics as well. Proposals are welcome.
Sounds like a good idea to me. I haven't been in the meetings for a while but in the past the tendency has often been that there's more to discuss that what there's time for.
Brainstorming a property-based API is one topic that would benefit from longer discussions. I'm also always free to discuss CDF and how it would be related
What an excellent idea! :)
with V4L2 in the future :-)
On Sat, Sep 28, 2013 at 01:07:34AM +0300, Sakari Ailus wrote:
I would be happy to add another brainstorming day, but since Hugues won't be available on the 21st we can only do limited codec discussions, so we would need other topics as well. Proposals are welcome.
Oops. I missed this. I'll arrive to Edinburgh on the afternoon 22nd so 21st is out of question for me. :I
-
Andy Walls -
Bryan Wu -
Hans Verkuil -
Hans Verkuil -
Laurent Pinchart -
Milo Kim -
Oliver Schinagl -
Ricardo Ribalda Delgado -
Sakari Ailus -
Sylwester Nawrocki -
Sylwester Nawrocki -
Thierry Reding