* [RFC] Configuration generic drivers at runtime
@ 2007-03-10 22:57 Laurent Pinchart
2007-03-12 20:39 ` [RFC] Configuring " Laurent Pinchart
0 siblings, 1 reply; 2+ messages in thread
From: Laurent Pinchart @ 2007-03-10 22:57 UTC (permalink / raw)
To: linux-kernel
Hi everybody,
I'm writing a Linux driver for USB Video Class (UVC) devices. Before
submitting it to the kernel, there are still a few rough corners I'd like to
polish. Comments would be appreciated for the following one.
The UVC spec defines a way for device vendors to provide extensions to the
standard through so-called extension units, identified by a GUID (Globally
Unique IDentifier). An extension unit can define any number of controls
(think of controls as simple parameters such as brightness, zoom, pan/tilt,
shutter speed, ...). Devices advertise in their USB descriptors the extension
units they support, along with the controls that are supported in each
extension unit.
To access those extension units from user-space, the UVC driver will offer two
methods. One of them will map the controls defined by extension units to V4L2
controls. The question that arises is how to define and store those mappings.
And obvious solution would be to have an ever growing array in the driver,
storing control information for all possible extension units ever defined by
webcam vendors. While this is quite straightforward, it might not be the most
usable solution for device vendors who wouldn't want debug controls to be
included in the kernel by default, or who wouldn't want to submit new control
definitions for inclusion in the kernel (with the implied delay) every time a
new device comes out.
Another solution would be to introduce a way to define controls and mappings
at runtime. Mappings would be stored in test-based user-space configuration
files, distributed by vendors. A small user-space utility would add them
through a few ioctls. This obviously raises some security concerns (regarding
which users will be allowed to add mappings, or how many of them they can
add).
I would like comments regarding the second solution. Is this something that is
likely to be accepted in the mainline kernel ? I don't know of any other
Linux driver implementing such kind of dynamic runtime configuration.
Best regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [RFC] Configuring generic drivers at runtime
2007-03-10 22:57 [RFC] Configuration generic drivers at runtime Laurent Pinchart
@ 2007-03-12 20:39 ` Laurent Pinchart
0 siblings, 0 replies; 2+ messages in thread
From: Laurent Pinchart @ 2007-03-12 20:39 UTC (permalink / raw)
To: linux-kernel
Hi,
as I got no reply to my previous e-mail, I assume it got stopped by
grammar-checking filters, so I fixed the subject line :-) (this is what
happens when you write the first word and the rest of the title 10 minutes
apart). More seriously, this is a generic architecture issue which I'd like
to get right. If nobody has any opinion on the subject, I'll just go on and
implement my idea. But if something isn't going to be accepted in the
mainline kernel, I'd rather find out now to spend time on finding a better
idea.
Best regards,
Laurent Pinchart
> Hi everybody,
>
> I'm writing a Linux driver for USB Video Class (UVC) devices. Before
> submitting it to the kernel, there are still a few rough corners I'd like
> to polish. Comments would be appreciated for the following one.
>
> The UVC spec defines a way for device vendors to provide extensions to the
> standard through so-called extension units, identified by a GUID (Globally
> Unique IDentifier). An extension unit can define any number of controls
> (think of controls as simple parameters such as brightness, zoom, pan/tilt,
> shutter speed, ...). Devices advertise in their USB descriptors the
> extension units they support, along with the controls that are supported in
> each extension unit.
>
> To access those extension units from user-space, the UVC driver will offer
> two methods. One of them will map the controls defined by extension units
> to V4L2 controls. The question that arises is how to define and store those
> mappings.
>
> And obvious solution would be to have an ever growing array in the driver,
> storing control information for all possible extension units ever defined
> by webcam vendors. While this is quite straightforward, it might not be the
> most usable solution for device vendors who wouldn't want debug controls to
> be included in the kernel by default, or who wouldn't want to submit new
> control definitions for inclusion in the kernel (with the implied delay)
> every time a new device comes out.
>
> Another solution would be to introduce a way to define controls and
> mappings at runtime. Mappings would be stored in text-based user-space
> configuration files, distributed by vendors. A small user-space utility
> would add them through a few ioctls. This obviously raises some security
> concerns (regarding which users will be allowed to add mappings, or how
> many of them they can add).
>
> I would like comments regarding the second solution. Is this something that
> is likely to be accepted in the mainline kernel ? I don't know of any other
> Linux driver implementing such kind of dynamic runtime configuration.
>
> Best regards,
>
> Laurent Pinchart
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2007-03-12 20:38 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-03-10 22:57 [RFC] Configuration generic drivers at runtime Laurent Pinchart
2007-03-12 20:39 ` [RFC] Configuring " Laurent Pinchart
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).