ribalda: feel free to ping me on IRC to discuss the inactive control flag before you submit patches, if there's anything that you think would be dodgy
Hi pinchartl!, Thanks. Regarding the events. I think we have to submit events for every change. Even it it started by the user calling g_ctrl()
should we discuss this with Hans ?
sure
hverkuil-: ping
I have a volatile control. Some hardware support sending an irq when the control changes. In those situations we send an event when the control changes
the issue is for hardware that does not support irqs. Shall we send an event when the user calls g_ctrl() and the value has changed from the previous state?
I think Hans is on vacation this week and the next :-S
sailus: maybe you have an opinion on this ?
H
pinchartl: ribalda: Interesting corner case.
sailus: isn't it ? :-)
I don't remember seeing something like this that the user space would be interested in.
Isn't the control event sent when the value changes, i.e. it is read, and this is done by the control framework?
Or is it something that should be polled by the driver?
ribalda: What kind of information is it?
control events are generated by drivers
well
the driver has to handle the hardware event
and then notify the control framework
but in this specific case
the V4L2 control framework isn't involved
as the uvcvideo driver doesn't use it
the use case is as follows
for an integrated webcam in a device
there's a physical privacy shutter that can block the camera
it's connected to a GPIO
so the kernel can be notified by an interrupt when the shutter is opened or closed
and this information needs to be propagated to applications
so far, no issue
there will be a control event sent
for some devices, however, the GPIO can't generate an interrupt
it can be polled
Can you recognise such devices?
yes
That's a major plus.
polling isn't done in the kernel
it's handled by userspace in Ricardo's case
when the application polls the control
the driver reads the state of the GPIO
and can then realize it has changed
the question is whether a control event should be generated in that case
ribalda: do you actually have a device where the GPIO can't generate an interrupt ?
There could be other processes that are interested in the information. But this may be just a theoretical possibility.
pinchartl: no
:-)
Nowadays in general there are less systems where the user space isn't in a better position to distribute the information.
I wouldn't generate one.
my rationale is, when you use set_ctrl(), you receive an event
It can be always added though.
But harder to remove.
ribalda: I wonder if we should delay addressing this issue until we encounter a system where the GPIO can't generate an interrupt
ok, so whenever we get an irq an event is launched
Seems reasonable.
You could also fail in probe if the hardware can't generate an event. This way you'd know if such a device appears. :-)
good idea.
I think the only devices that will use this for the foreseable future are Chrome OS devices, so Ricardo should know about them :-)
and if we encounter devices with no irq we can always rescue the original patchset
;)
you would have to poll the control from userspace, which would be bad from a battery point of view. I doubt there would be such a chromebook
ribalda: Why is it possible there's no IRQ? Because some spec makes it possible?
Or is it UVC?
sailus: the signal is connected to a GPIO, not all GPIOs can generate IRQs
the privacy pin is connected to a gpio. So far, all the gpio it has been connected supports irq
Ah, ok.