On Tuesday 06 April 2010 00:12:48 Hans Verkuil wrote:
> 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.
Replying to your own mails is probably a bad sign, but I can't help myself :-)
I've changed the code to add a control class prefix for all but the user
controls.
It looks much better now:
$ ls /sys/class/video4linux/video1/controls
balance mpeg_insert_navigation_packets
mpeg_video_aspect
brightness mpeg_median_chroma_filter_maximum
mpeg_video_b_frames
chroma_agc mpeg_median_chroma_filter_minimum
mpeg_video_bitrate
chroma_gain mpeg_median_filter_type
mpeg_video_bitrate_mode
contrast mpeg_median_luma_filter_maximum
mpeg_video_encoding
hue mpeg_median_luma_filter_minimum
mpeg_video_gop_closure
mpeg_audio_crc mpeg_spatial_chroma_filter_type
mpeg_video_gop_size
mpeg_audio_emphasis mpeg_spatial_filter
mpeg_video_mute
mpeg_audio_encoding mpeg_spatial_filter_mode
mpeg_video_mute_yuv
mpeg_audio_layer_ii_bitrate mpeg_spatial_luma_filter_type
mpeg_video_peak_bitrate
mpeg_audio_mute mpeg_stream_type
mpeg_video_temporal_decimation
mpeg_audio_sampling_frequency mpeg_stream_vbi_format mute
mpeg_audio_stereo_mode mpeg_temporal_filter saturation
mpeg_audio_stereo_mode_extension mpeg_temporal_filter_mode volume
> > 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:
If we go for something like this, then I think it would be better to make a
new subdirectory. So 'controls' just has the controls, and 'ctrl_info' or
something similar would have read-only files containing this information.
Again, I still don't know whether we should do this. It is dangerously
seductive because it would be so trivial to implement.
Regards,
Hans
>
> 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
