Re: Re: [patches!] Re: v4l2/kernel-2.5

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Hi,

I need some more clarifications for the spec.

struct v4l2_capability has a name field: "Canonical name for this
device. This name is descriptive, but it is also unique for each device.
It can be used to build a menu of available devices for a device-select
user interface." The "unique" clause was added because a list of
identical names is not very useful, something like "BT878 (Hauppauge
WinTV) #2" is expected. (I'd prefer "PCI Slot 2" etc, but I've been told
it's next to impossible.) Anyway, to help driver specific apps identify
the driver it would be really nice to have another name field which
contains the driver name ("bttv"), only the driver name, and never
changes.

Gerd added a version field. It wasn't clearly stated, so I assume this
refers to the driver version, not the API version. If so, it's rather
pointless to require KERNEL_VERSION() since the versioning scheme is
already a private matter between the driver and its apps. Recommendation
ok. If this is intended as API version we must also define what the
numbers actually mean.

There are two fields containing flags, 'capabilities' and:
_u32   flags;          /* Feature flags, see below */
What is the purpose of this field, no flags seem to be defined.

struct v4l2_audio: What is capability V4L2_AUDCAP_LOUDNESS and mode
V4L2_AUDMODE_LOUDNESS? These didn't exist before. Supposedly
V4L2_AUDCAP_EFFECTS refers to the V4L2_AUDMODE_STEREO_* modes. They were
never fully explained, does anyone know what they do, or can provide a
pointer to docs? If they're intentionally vague a menu control may be
more appropriate.

Btw there's no stereo capability flag. Suppose the audio connector on
the tv card is mono and audio is looped back to the soundcard. The
oss/alsa device cannot, and hence the app cannot know if the audio is
always mono.

struct v4l2_tuner: We have an index field here. How are tuners numbered:
a) Sequentially 0 ... n, so they can be enumerated with VIDIOC_G_TUNER;
b) Same as the respective input index; c) No numbering scheme, only
v4l2_input.tuner -> v4l2_tuner.index. Same issue w/modulators.

rangelow, rangehigh, frequency: We have to units, 62.5 kHz and 62.5 Hz
depending on V4L2_TUNER_CAP_LOW. Originally v4l2 just used 1 Hz (0 ... 4
GHz in __u32) but it was changed back for some reason. I want to add a
footnote explaining why we need two units.

rxsubchans is defined as the received audio subprograms. I suppose this
field is valid only when this input (and its tuner) is currently
selected, similar to Gerd's suggestion regarding input status flags
(V4L2_IN_ST_*). Maybe a status ioctl would be better, well.

The various audio flags are a bit confusing. Here's what I think, please
correct me if I'm wrong.

Valid combinations in rxsubchans are MONO, STEREO, MONO|LANG2, MONO|SAP,
STEREO|SAP. Which of MONO|LANG2 or MONO|SAP (since LANG2=SAP) applies
for proper display depends on the capability field. Or if that's
inconclusive on the current video standard (BTSC goes with M/NTSC).
Actually LANG2, SAP => LANG1. But as LANG1 is defined as "device
can/does receive first language of two" the combinations LANG2 or SAP
only are also valid.

The audmode values yield the following output:
                    Selected
Received            MONO    STEREO      LANG1      LANG2=SAP
Mono                Mono   Mono/Mono    Mono         Mono
Stereo              L+R      L/R         1)           2)
+ SAP (BTSC)         -        -          3)         SAP (mono)
Bilingual (2C)     Lang1      4)      Lang1 (mono) Lang2 (mono)

With four undefined cases:
1) L/L, L+R (mono), L/R (stereo)
2) R/R, L+R, L/R
3) Main audio program, mono or stereo
4) Lang1/Lang1, Lang1/Lang2

Effectively LANG1 is the same as MONO or STEREO (whatever received), but
I understand it's needed because some hardware cannot automatically
distinguish between stereo and bilingual. If so, should the driver set
rxsubchans to MONO|STEREO|LANG2 (all of them should appear in a menu) or
0 (nothing detected)?

In the capability (to receive and decode) field all flags can appear in
any combination. Typically I'd expect MONO, MONO|SAP, MONO|STEREO|SAP or
MONO|STEREO|LANG1|LANG2. But just from this field it's not clear if the
capability is really MONO|LANG2, MONO|STEREO|LANG2 (no LANG1, strange
hw) or MONO|STEREO|LANG1|LANG2 + MONO|STEREO|SAP (multi-standard
device).

Btw what about surround? There are tv cards with surround decoder but
the API does not mention this once. No input/output types, capability,
rxsubchans, audmod flag. Is surround decoding purely a function of the
PCM sampling interface?

struct v4l2_tuner signal: "The signal strength if known." I assume this
field is valid only when this input (and its tuner) is currently
selected, as above. Which values should it assume, higher is better? "if
known" is ambiguous: really no signal or unknown?

The afc field is of type __u32 but defined as: "If negative, tune
higher; if positive, tune lower". Actually afc may never settle. Any
suggestions what apps are supposed to do?

Video standards. I must repeat my criticism of the link between
v4l2_input, v4l2_output, and v4l2_standard.

The VIDIOC_ENUMSTD ioctl is ok, one item for each standard distinguished
by the hardware (e.g. tuner PAL-B/G or PAL-I; video decoder PAL-B/G/H/I,
NTSC-M, SECAM-L, ...). Originally there were inputset and outputset
fields, and I proposed "to add .standardset in v4l2_input/v4l2_output
and remove the .input/outputset here. Rationale is that we have the
.tuner link and .audioset there too. This change would root everything
in the input/output enum."

Now we have a std (v4l2_std_id) field in v4l2_input/v4l2_output which
must be looked up. Also VIDIOC_G_STD and VIDIOC_S_STD take a v4l2_std_id
pointer, remnant of v4l2 0.20. This isn't needed anymore after we
dropped the idea of arbitrary standards. No idea what the purpose of
VIDIOC_QUERYSTD _IOR ('V', 63, v4l2_std_id) is. Standards should work
like this: each bit in .standardset corresponds to one enumerated
standard akin to .audioset. VIDIOC_G|S_STD take an int like
VIDIOC_G|S_INPUT|OUTPUT, index of the respective standard|input|output.

struct v4l2_queryctrl: The step field is __s32 like minimum, maximum,
and default_value but it cannot actually be negative (minimum >=
maximum?). Maybe it should be changed to __u32.

One of the predefined controls demands explanation:
V4L2_CID_AUDIO_LOUDNESS boolean "Audio Loudness mode." What is this and
how is it related, if at all, to struct v4l2_audio
V4L2_AUDMODE_LOUDNESS?

Michael






[Index of Archives]     [Linux DVB]     [Video Disk Recorder]     [Asterisk]     [Photo]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Free Photo Albums]     [Fedora Users]     [Fedora Women]     [ALSA Users]     [ALSA Devel]     [Linux USB]

Powered by Linux