On Monday 05 April 2010 23:47:10 Hans Verkuil wrote:
> 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 thing that might be useful is to prefix the name with the control class
name. E.g. hue becomes user_hue and audio_crc becomes mpeg_audio_crc. It would
groups them better. Or one could make a controls/user and controls/mpeg
directory. That might not be such a bad idea actually.
> 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.
An in between solution would be to add _type files. So you would have 'hue' and
'hue_type'. 'cat hue_type' would give something like:
int 0 255 1 128 0x0000 Hue
In other words 'type min max step flags name'.
And for menu controls like stream_type (hmm, that would become
stream_type_type...)
you would get:
menu 0 5 1 0 Stream Type
MPEG-2 Program Stream
MPEG-1 System Stream
MPEG-2 DVD-compatible Stream
MPEG-1 VCD-compatible Stream
MPEG-2 SVCD-compatible Stream
Note the empty line to denote the unsupported menu item (transport stream).
This would give the same information with just a single extra file. Still not
sure whether it is worth it though.
Regards,
Hans
>
> 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
