Hi all,
The new control framework makes it very easy to expose controls in sysfs.
The way it is implemented now in the framework is that each device node
will get a 'controls' subdirectory in sysfs. Below which are all the controls
associated with that device node.
So different device nodes can have different controls if so desired.
The name of each sysfs file is derived from the control name, basically making
it lowercase, replacing ' ', '-' and '_' with '_' and skipping any other non-
alphanumerical characters. Seems to work well.
For numerical controls you can write numbers in decimal, octal or hexadecimal.
When you write to a button control it will ignore what you wrote, but still
execute the action.
It looks like this for ivtv:
$ ls /sys/class/video4linux/video1
controls dev device index name power subsystem uevent
$ ls /sys/class/video4linux/video1/controls
audio_crc chroma_gain
spatial_chroma_filter_type video_bitrate_mode
audio_emphasis contrast spatial_filter
video_encoding
audio_encoding hue spatial_filter_mode
video_gop_closure
audio_layer_ii_bitrate insert_navigation_packets
spatial_luma_filter_type video_gop_size
audio_mute median_chroma_filter_maximum stream_type
video_mute
audio_sampling_frequency median_chroma_filter_minimum stream_vbi_format
video_mute_yuv
audio_stereo_mode median_filter_type temporal_filter
video_peak_bitrate
audio_stereo_mode_extension median_luma_filter_maximum temporal_filter_mode
video_temporal_decimation
balance median_luma_filter_minimum video_aspect
volume
brightness mute video_b_frames
chroma_agc saturation video_bitrate
The question is, is this sufficient?
One of the few drivers that exposes controls in sysfs is pvrusb2. As far as
I can tell from the source it will create subdirectories under the device
node for each control. Those subdirs have the name ctl_<control-name> (e.g.
ctl_volume), and below that are files exposing all the attributes of that
control: name, type, min_val, max_val, def_val, cur_val, custom_val, enum_val
and bit_val. Most are clear, but some are a bit more obscure. enum_val is
basically a QUERYMENU and returns all menu options. bit_val seems to be used
for some non-control values like the TV standard that pvrusb2 also exposes
and where bit_val is a bit mask of all the valid bits that can be used.
Mike, if you have any additional information, just let us know. My pvrusb2
is in another country at the moment so I can't do any testing.
Personally I think that it is overkill to basically expose the whole
QUERYCTRL information to sysfs. I see it as an easy and quick way to read and
modify controls via a command line.
Mike, do you know of anyone actively using that additional information?
And which non-control values do you at the moment expose in pvrusb2 through
sysfs? Can you perhaps give an ls -R of all the files you create in sysfs
for pvrusb2?
I am wondering whether some of those should get a place in the framework as
well. While I don't think e.g. cropping parameters are useful, things like the
current input or tuner frequency can be handy. However, for those to be useful
they would have to be wired up internally through the framework. For example,
VIDIOC_S_FREQUENCY would have to be hooked up internally to a control. That
would ensure that however you access it (ioctl or sysfs) it will both end up
in the same s_ctrl function.
It will be nice to hear from you what your experience is.
Comments? Ideas? Once we commit to something it is there for a long time to
come since sysfs is after all a public API (although it seems to be more
changable than ioctls).
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
