On Wed, 12 Apr 2000, David Brownell wrote:
> There's another category of software to consider, too. It's
> what one might call "management" or "troubleshooting" or
> "system monitoring" applications. Userspace tools, ideally,
> that talk to devices to handle things that are outside the
> scope of what a kernel driver does (or another userspace tool).
I'd like to mention that such "management" tools could do also a
driver-specific job. Windows DLLs for device-specific procedures,
settings are just one good example. Many devices (especially vendor)
offer lots of hardware features (controls) which aren't necessarily
supported or managed by higher layers (like V4L) or client app
(because nobody likes to include specific h/w code into each & every
application).
As an example, cameras can be programmed for sensitivity, color
balance (each channel separately and all together), exposure, frame
rate and many more; all settings are chipset-dependent. Currently we
use module options (then good luck compiling driver into the kernel,
even if it -really- makes sense - for embedded device, for instance.)
I heard that new CPiA code uses /proc to set up the device - this is
not much better. This subject is closely related to user-friendliness
of the system.
At this time drivers would have to support multiple open() to allow
someone else (other than a client) to play with settings (clients
don't want to do that, see above). There is no standard for such
ioctl() either, and there is no [clean] way to invoke the tool (even a
Perl/Tk script) automatically or on demand to adjust settings. The
-proper- tool must be invoked for each type of connected hardware (I
assume a desktop box here, but headless boxen could be addressed too.)
The problem is not limited to USB devices. Any device which is not
strictly class-compliant (and as such couldn't be fully supported by
upper layer) may have "hidden" controls. SoundBlaster could be an
example, or a keyboard with programmable keys, lights - or with LCD on
each key, if you prefer, for instant layout switch. Firmware uploaders
are likely to fall into that category too. In world of cameras many
have "snapshot" button - and it can't be used because V4L does not
propagate such event back to the client (and client, naturally, is
unaware of the event.)
Thanks,
Dmitri
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
