To: video4linux-list@xxxxxxxxxx
Subject: v4l2/kernel-2.5
From: Ronald Bultje <rbultje@xxxxxxxxxxxxxxxxxxx>
Date: 21 Oct 2002 20:47:35 +0200
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx
Hi Gerd & Michael & all,
looking at some random websites, it seems either doom time or I'm just
completely lost. How far is the v4l2 inclusion in the kernel? As far as
I know we've agreed on pretty much everything that needed to be
discussed, which means that v4l2 is now officially stable again (or have
I missed some points here?).
So, how far off from inclusion? Better yet, is there any chance for
inclusion at all?
Ronald
To: video4linux-list@xxxxxxxxxx
Subject: Re: v4l2/kernel-2.5
From: Gerd Knorr <kraxel@xxxxxxxxxxx>
Date: 22 Oct 2002 08:44:07 GMT
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx
Newsgroups: lists.linux.video4linux
Organization: SuSE Labs, Außenstelle Berlin
User-agent: slrn/0.9.7.4 (Linux)
Ronald Bultje wrote:
> Hi Gerd & Michael & all,
>
> looking at some random websites, it seems either doom time or I'm just
> completely lost. How far is the v4l2 inclusion in the kernel? As far as
> I know we've agreed on pretty much everything that needed to be
> discussed, which means that v4l2 is now officially stable again (or have
> I missed some points here?).
>
> So, how far off from inclusion? Better yet, is there any chance for
> inclusion at all?
I'm currently porting xawtv + bttv to the revisited v4l2 API. bttv not
working yet, I hope to get that done today. Next step is building
patches for 2.5 kernels, I'll post a announcement once I'm done with the
patches (later today or tomorrow I hope, depends on how long I need to
fix the bugs in bttv ...).
Gerd
To: video4linux-list@xxxxxxxxxx
Subject: [patches!] Re: v4l2/kernel-2.5
From: Gerd Knorr <kraxel@xxxxxxxxxxx>
Date: 22 Oct 2002 17:41:33 GMT
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx
Newsgroups: lists.linux.video4linux
Organization: SuSE Labs, Außenstelle Berlin
User-agent: slrn/0.9.7.4 (Linux)
> working yet, I hope to get that done today. Next step is building
> patches for 2.5 kernels, I'll post a announcement once I'm done with the
> patches (later today or tomorrow I hope, depends on how long I need to
> fix the bugs in bttv ...).
Had a crash course in using debugfs today after "rm -rf"'ing my current
bttv source tree. Luckily it wasn't reiserfs *grin*.
Anyway, here we go:
Patches for 2.5 are available from
http://bytesex.org/patches/2.5/
That includes the v4l2 api, bttv updates and some other minor stuff.
No v4l2 API docs yet, Michael?
bttv-0.9.x + new v4l2 is also available from http://bytesex.org/snapshot/
A new xawtv release is at http://bytesex.org/xawtv/
The whole thing is rushed out a bit and not tested that much. It is
basically working, but likely needs alot of minor tweaks here and there.
Also not all features are implemented yet. Still have a long todo list:
- create 2.4.x patches
- update v4l1-compat module
- update saa7134 driver
- testing, testing, testing, ...
Comments? Bugs? Crashes?
Gerd
--
You can't please everybody. And usually if you _try_ to please
everybody, the end result is one big mess.
-- Linus Torvalds, 2002-04-20
To: video4linux-list@xxxxxxxxxx
Subject: Re: [patches!] Re: v4l2/kernel-2.5
From: Gerd Knorr < kraxel@xxxxxxxxxxx>
Date: 24 Oct 2002 13:30:01 GMT
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx
Newsgroups: lists.linux.video4linux
Organization: SuSE Labs, Außenstelle Berlin
User-agent: slrn/0.9.7.4 (Linux)
> http://bytesex.org/patches/
> - create 2.4.x patches
Done, available above (along with some versioning notes).
> - update v4l1-compat module
Done.
> - update saa7134 driver
Done.
Also released new bttv/saa7134 tarballs, bumped the versions to 0.9.0 /
0.2.0 because of the incompatible API changes.
Gerd
--
You can't please everybody. And usually if you _try_ to please
everybody, the end result is one big mess.
-- Linus Torvalds, 2002-04-20
To: video4linux-list@xxxxxxxxxx
Subject: Re: Re: [patches!] Re: v4l2/kernel-2.5
From: "Michael H. Schimek" <mschimek@xxxxxx>
Date: Mon, 28 Oct 2002 11:59:33 +0100
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx
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
To: video4linux-list@xxxxxxxxxx
Subject: Re: [patches!] Re: v4l2/kernel-2.5
From: Gerd Knorr <kraxel@xxxxxxxxxxx>
Date: 28 Oct 2002 18:19:12 GMT
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx
Newsgroups: lists.linux.video4linux
Organization: SuSE Labs, Außenstelle Berlin
User-agent: slrn/0.9.7.4 (Linux)
> 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.
How about this:
struct v4l2_capability
{
__u8 driver[16]; /* i.e. "bttv" */
__u8 card[32]; /* i.e. "Hauppauge WinTV" */
__u8 bus_info[32]; /* "PCI:" + pci_dev->slot_name */
__u32 version; /* should use KERNEL_VERSION() */
__u32 capabilities; /* Device capabilities */
__u32 reserved[4];
};
slot_name is the same lspci prints in column #0, that is the best you
can get I think. Which physical slot on the motherboard this actually
is indeed next-to-impossible to figure in some portable and reliable
way.
> Gerd added a version field. It wasn't clearly stated, so I assume this
> refers to the driver version, not the API version.
Yes.
> 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.
Why it is a private matter? The user might want to know this too,
for example because issue $foo in driver $bar has been fixed in version
0.42. IMHO applications should be able to display to version to the
user. This requires a fixed way to specify the version number so the
driver can display it even without knowing that particular driver ...
> 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.
Forgot to delete that one.
> struct v4l2_audio: What is capability V4L2_AUDCAP_LOUDNESS and mode
> V4L2_AUDMODE_LOUDNESS? These didn't exist before.
Redundant, there is also a control for this. Don't know where they came
from. Deleted.
> 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.
Some pseudo-stereo effects. Yes, a control menu likely works better for
these.
> Btw there's no stereo capability flag.
Fixed.
> 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;
Most useful IMHO.
> c) No numbering scheme, only v4l2_input.tuner -> v4l2_tuner.index.
That is required anyway ...
> 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)
Really? IIRC the V4L2_TUNER_CAP_LOW was there all the time ...
At least I hav't changed that last weeks.
> 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_*).
Yes. It simply might not work otherwise on current hardware.
> 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).
I'd make that depend on the video standard. If you put this into a
menu, it would IMHO be useful if the user finds the "well known" terms
there. i.e. use "SAP" for BTSC/NTSC and use "LANG2" for PAL-BG
bilingual mode.
> If so, should the driver set rxsubchans to MONO|STEREO|LANG2 (all of
> them should appear in a menu) or 0 (nothing detected)?
IMHO all of them. I would see rxsubchans as a set of useful choices at
the moment. If the hardware can disturgish between STEREO + LANG1+LANG2
being transmitted it can clear the bits for the modes currently not
available, otherwise all should be set.
> 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.
Yes.
> 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?
I don't want to put that in until someone really needs this. I think
this could be handled using the ALSA mixer API just fine. Maybe v4l2
controls work too.
> 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.
Yes.
> Which values should it assume, higher is better?
Higher is better.
> "if known" is ambiguous: really no signal or unknown?
Use "-1" for unknown?
> The afc field is of type __u32 but defined as: "If negative, tune
> higher; if positive, tune lower".
Changed to __s32, thanks.
> Actually afc may never settle. Any suggestions what apps are supposed
> to do?
Don't think this (scanning algo) belongs into the API spec. A hint
about this issue to app drivers should be enougth.
> 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.
v4l2_std_id isn't a pointer, it is a bitfield. If your input can handle
PAL+NTSC, just do v4l2_input->std = V4L2_STD_PAL | V4L2_STD_NTSC.
> No idea what the purpose of VIDIOC_QUERYSTD _IOR ('V', 63,
> v4l2_std_id) is.
Ask the driver what he thinks the current TV norm of the signal on
current input is. Depending on how good the card is in detecting video
standards this might return V4L2_STD_ALL, V4L2_STD_625_50, V4L2_STD_NTSC
or V4L2_STD_PAL_I ...
> 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.
Again: v4l2_std_id _is_ a bitfield.
> 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.
why step can't be negative? Maybe for some "smaller values are
better"-kind of control?
> 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?
See above ...
Gerd
--
You can't please everybody. And usually if you _try_ to please
everybody, the end result is one big mess.
-- Linus Torvalds, 2002-04-20