List: linux-video
Subject: [video4linux] V4L2: The Great Renaming
From: Bill Dirks <bill.dirks () rendition ! com>
Date: 1998-10-31 21:44:56
I want to do some renaming of things in the V4L2 spec. Naturally, this
will break everybody's programs and drivers, but a little
well-considered Search & Replace will fix most of it. :) Nevertheless, I
am concerned enough about it that I wanted to post this message.
I'll update the documentation first, so you can have a look at it before
the new V4L2 source files are posted.
Two areas I want to make changes in are symbol names in the header file,
and /dev node names.
------------------
video_ to v4l2_:
I want to change the symbols beginning with video_ to v4l2_. 'video' is
kind of generic, and means different things, whereas 'v4l2' is more
specific, and less polluting of the namespace. The change affects
structure names, kernel functions, and likely the #define symbols. There
could also be changes beyond the prefix, like video_format to
v4l2_imageformat, to allow for other kinds of formats.
------------------
/dev tree: [Thanks to Michael Schimek for this scheme.]
Minor device numbers worked great for things like serial ports and
floppy drives, where one driver controlled an array of more or less
identical devices. However, for V4L2 this system is rather ill-suited.
V4L2 devices are rather different from each other, and each is
controlled by a different driver. Here is Erik's V4L2 device list:
minor: type hardware busy name
0: grabber qcam_c 0 Color QuickCam on parport0
1: grabber pseudo 0 Frame buffer capture driver
2: grabber pseudo 0 Example Capture Driver (0)
3: grabber pseudo 0 Example Capture Driver (1)
64: codec pseudo 0 RT software JPEG compressor
65: codec pseudo 0 RT software JPEG decompressor
160: radio rtrack 0 AIMSlab RadioTrack/RadioReveal
Each minor addresses a different type of device, and the way minor
numbers are assigned depends on the order in which the drivers are
loaded. A device node that is a QuickCam now could be something else
later, even if the hardware configuration remains the same.
What's more, there are different sub-categories like grabber, codec,
vbi, and so on, each with a pre-assigned hard-coded range of minors.
Well, I can tell you that deciding how to allocate those minor ranges is
a pain. How big do you make each range? How do you add another type of
device in the future? What if someone wants a proprietary device type?
Michael and I debated different schemes to get around these problems for
well over a month, and just now finally arrived at something we agree
on. If anybody has feedback on this, don't hesitate.
The problem is trying to use the minor number to identify devices when
the minor is assigned dynamically and is not actually permanently
assigned to anything. (Minor ranges are a half-hearted workaround to
this, and create their own new problems.)
So, V4L2 will ignore the minor completely, and instead key entirely off
the name of the device node to identify the device. Device nodes will be
named after the driver and the type of device. Because we can't have a
whole bunch of arbitrary names in /dev, a directory will be created:
/dev/v4l2/
(It doesn't have to be called 'v4l2' if you have a better idea.) A
complete dev node name has the syntax:
/dev/v4l2/<driver><digit(s)>/<type>
Examples:
/dev/v4l2/qcam0/video
/dev/v4l2/bttv0/video
/dev/v4l2/bttv1/video
/dev/v4l2/rtrack0/radio
Thus video capture devices are all called /dev/v4l2/*/video, and so on.
The <driver> name is the same as the module file name. Strictly
speaking, it doesn't need to be, but if it is then V4L2 can load the
module automatically.
The <type> can be anything the driver wants, but applications will be
looking for specific names, of course, like 'video', 'codec', 'radio',
etc. A driver writer can invent new <type>s, as long as there is an
application that can use them. It is also possible to handle fancier
things, e.g. devices that support two video ins can have /video0 and
/video1.
The administrator has to create the special device nodes for each
device. The driver documentation should have that information. But, I'm
thinking that once a module is installed, videodev will have that
information too, and can make it available via the /proc filesystem.
Maybe even in the form of the shell commands needed to create the nodes,
so the admin need only run the file as a script. The nodes will need
some minor number (which will be ignored by the driver). Can two nodes
have the same minor? If not, minors will have to be allocated somehow.
If anybody has any ideas about this, let me know.
I have a prototype of this scheme on my system, and I am capturing video
from /dev/v4l2/v4l2cap0/video (the sample driver), so the concept works.
Applications can no longer just use /dev/videoN for the node name, and
have to enumerate the /dev/v4l2/*/video nodes to find a capture device.
I will make some example code available that does that.
Bill.
------------
To unsubscribe from this list send mail to majordomo@phunk.org with the
line "unsubscribe video4linux" without the quotes in the body of the
message.
List: linux-video
Subject: Re: [video4linux] V4L2: The Great Renaming
From: Gerd Knorr <kraxel () goldbach ! in-berlin ! de>
Date: 1998-11-01 9:31:36
Bill Dirks <bill.dirks@rendition.com> writes:
>------------------
>video_ to v4l2_:
>I want to change the symbols beginning with video_ to v4l2_. 'video' is
>kind of generic, and means different things, whereas 'v4l2' is more
>specific, and less polluting of the namespace. The change affects
>structure names, kernel functions, and likely the #define symbols. There
>could also be changes beyond the prefix, like video_format to
>v4l2_imageformat, to allow for other kinds of formats.
Good. That way one can load both old and new drivers for testing...
BTW: xawtv-2.29 is out, and has v4l2 support. Not complete yet, but it
already displays the cool test image from the v4l2cap module.
>------------------
>/dev tree: [Thanks to Michael Schimek for this scheme.]
[ ... ]
>So, V4L2 will ignore the minor completely, and instead key entirely off
>the name of the device node to identify the device. Device nodes will be
>named after the driver and the type of device. Because we can't have a
>whole bunch of arbitrary names in /dev, a directory will be created:
>/dev/v4l2/
>(It doesn't have to be called 'v4l2' if you have a better idea.) A
>complete dev node name has the syntax:
>/dev/v4l2/<driver><digit(s)>/<type>
>Examples:
>/dev/v4l2/qcam0/video
>/dev/v4l2/bttv0/video
>/dev/v4l2/bttv1/video
>/dev/v4l2/rtrack0/radio
This looks much like devfs. Hav'nt checked out devfs yet (just have
read the flame-wars^H^H^H^Hdiscussions about it in linux-kernel),
but doing something like this should be easy with devfs. So we don't
have do reinvent the wheel...
Gerd
------------
To unsubscribe from this list send mail to majordomo@phunk.org with the
line "unsubscribe video4linux" without the quotes in the body of the
message.
List: linux-video
Subject: Re: [video4linux] V4L2: The Great Renaming
From: Itai Nahshon <nahshon () actcom ! co ! il>
Date: 1998-11-01 11:58:09
Gerd Knorr wrote:
>
> >Examples:
>
> >/dev/v4l2/qcam0/video
> >/dev/v4l2/bttv0/video
> >/dev/v4l2/bttv1/video
> >/dev/v4l2/rtrack0/radio
>
> This looks much like devfs. Hav'nt checked out devfs yet (just have
> read the flame-wars^H^H^H^Hdiscussions about it in linux-kernel),
> but doing something like this should be easy with devfs. So we don't
> have do reinvent the wheel...
I do not see the relation to devfs. With devfs (or pty98 !) there is a
special filesystem that defines the devices automagically. Here (If I
understood Bill) there is a regular file system with heirarchy. Did
anyone say that /dev/ should be flat?
Itai
--
Itai Nahshon nahshon@actcom.co.il
Also nahshon@vnet.ibm.com
------------
To unsubscribe from this list send mail to majordomo@phunk.org with the
line "unsubscribe video4linux" without the quotes in the body of the
message.
List: linux-video
Subject: Re: [video4linux] V4L2: The Great Renaming
From: Alan Cox < alan () cymru ! net>
Date: 1998-11-01 16:50:57
> I do not see the relation to devfs. With devfs (or pty98 !) there is a
> special filesystem that defines the devices automagically. Here (If I
> understood Bill) there is a regular file system with heirarchy. Did
> anyone say that /dev/ should be flat?
No, but there are strong preferences for keeping it so. Secondly the
v4l2 api in its final form has to support back compatibility ioctls and
existing device names, so it would be strange to not use them.
------------
To unsubscribe from this list send mail to majordomo@phunk.org with the
line "unsubscribe video4linux" without the quotes in the body of the
message.
List: linux-video
Subject: Re: [video4linux] V4L2: The Great Renaming
From: Bill Dirks <bill.dirks () rendition ! com>
Date: 1998-11-02 19:34:56
Alan Cox wrote:
> > I do not see the relation to devfs. With devfs (or pty98 !) there is a
> > special filesystem that defines the devices automagically. Here (If I
> > understood Bill) there is a regular file system with heirarchy. Did
> > anyone say that /dev/ should be flat?
>
> No, but there are strong preferences for keeping it so.
What are those? Would it make more sense to fix whatever it is that
depends on a flat /dev? What am I or a user of V4L2 giving up by using a
non-flat /dev space? Empirically, mkdir /dev/v42l seems to work just
fine.
> Secondly the v4l2 api in its final form has to support back
> compatibility ioctls and existing device names, so it would be
> strange to not use them.
Hmm, you seem to know more about the final form of V4L2 than I do. :)
It is my intention that the traditional /dev/video0 names will not be
supported in V4L2 because the system is too inflexible, and there is no
satisfactory and meaningful way to allocate minor numbers to devices.
Bill.
------------
To unsubscribe from this list send mail to majordomo@phunk.org with the
line "unsubscribe video4linux" without the quotes in the body of the
message.
List: linux-video
Subject: Re: [video4linux] V4L2: The Great Renaming
From: Alan Cox <alan () cymru ! net>
Date: 1998-11-02 20:35:44
> > No, but there are strong preferences for keeping it so.
>
> What are those? Would it make more sense to fix whatever it is that
> depends on a flat /dev? What am I or a user of V4L2 giving up by using a
> non-flat /dev space? Empirically, mkdir /dev/v42l seems to work just
> fine.
Mostly those of tradition.
> It is my intention that the traditional /dev/video0 names will not be
> supported in V4L2 because the system is too inflexible, and there is no
> satisfactory and meaningful way to allocate minor numbers to devices.
In order counting from 0 has been good enough for numbering most things,
whats the problem here
------------
To unsubscribe from this list send mail to majordomo@phunk.org with the
line "unsubscribe video4linux" without the quotes in the body of the
message.
List: linux-video
Subject: Re: [video4linux] V4L2: The Great Renaming
From: Bill Dirks <bill.dirks () rendition ! com>
Date: 1998-11-03 5:29:46
[ Ok, here's the finished reply... ;) ]
---
> > It is my intention that the traditional /dev/video0 names will not be
> > supported in V4L2 because the system is too inflexible, and there is no
> > satisfactory and meaningful way to allocate minor numbers to devices.
>
Alan Cox wrote:
> In order counting from 0 has been good enough for numbering most
> things, whats the problem here
I don't want to number video devices. I want to identify and organize
them, in a flexible and extensible way.
V4L2, like v4l before it, is a two-layer system. Which is nothing
special. But the top layer of V4L2 is purely a registrar, and is
completely independent and ignorant of _any_ hardware.
Some devices have numbers at some hardware level; serial ports, floppy
drives, devices on a SCSI bus. It makes a certain amount of sense to
identify them by number. The same number always refers to the same
device.
V4L2 handles a very wide variety of devices, and there is no meaningful
way to number them. What's more, videodev, the device numbering
authority, doesn't really know anything about the devices that it's
numbering. So how does v4l number them? In the order in which the
modules are loaded. And if a module is unloaded, and another loaded, the
number of the old device gets recycled for the new one.
The devices are accessed by name. And the name is attached to the
number. So the same name becomes a different device. Can you imagine if
serial port 1 and serial port 2 could trade identities?
And V4L2 devices vary in features and capabilities, as well being
physically different ports on the back of the machine, hooked to
different external equipment. So if /dev/video0 changes identities with
/dev/video1, not only do you capture from the wrong camera or whatever,
you could be using a device unsuited to the application.
What device on the system does 'vcat /dev/video0' capture from? It
varies-- even if the hardware configuration remains the same.
The range of devices that V4L2 (and v4l) handle is so broad, that there
isn't even a single API for all of them. They use different APIs, give
different kinds of data through read(), etc. Mixing up two devices that
use different APIs would cause big trouble. V4l has that handled,
though. Devices have a type, which identifies the type of data it uses,
the meaning of read() and write(), the API, etc., and each type of
device has a different pre-arranged, hard-coded range of numbers, and a
different pre-arranged, pre-registerd base name in /dev.
But how do you decide how to allocated those number ranges? With only
256 numbers, and several device types, it's a small space. You want to
allow for as many devices of a type as possible.
Now, suppose you want to add some more device types later. You have to
move or reassign numbers, breaking things. What if some hardware vendors
want to add their own proprietary types? Or expand something, like dual
capture channels on a device. For something like V4L2, that kind of
flexibility is desireable.
The /dev space is another problem. Names going into the /dev space
need to be registered. So you have a small number of generic names, and
different V4L2 devices with _unique_ capabilities must all have almost
_identical_ names. You wouldn't want your QuickCam and your Buz to get
mixed up. ;) And again, trouble to add more device types.
It would be nice to be able to automatically load modules when the
device file is opened. For many traditional kinds of devices where the
numbers identify the device, and the same device always has the same
/dev name and the same number, this is possible. For v4l it is not. With
the proposed V4L2 device name scheme it is. Make any access to the V4L2
major load videodev. Then videodev can look at the name of the device
being accessed, and load that module automatically.
Another thing that the proposed scheme adds is locating dependent
devices. By that I mean that the same physical board can handle more
than one API, for example, video capture and VBI. In that case it can be
desirable to find the VBI device that corresponds to a capture device.
That association comes out in the naming scheme, e.g:
/dev/v4l2/buz0/video
/dev/v4l2/bttv0/vbi
/dev/v4l2/bttv0/video
/dev/v4l2/foo0/vbi
This can also be achieved with ioctls, but it is somewhat convenient for
a command line user that it is visible in the ls.
Does that answer the question?
Bill.
------------
To unsubscribe from this list send mail to majordomo@phunk.org with the
line "unsubscribe video4linux" without the quotes in the body of the
message.
List: linux-video
Subject: Re: [video4linux] V4L2: The Great Renaming
From: Alan Cox <alan () cymru ! net>
Date: 1998-11-03 14:41:05
> The devices are accessed by name. And the name is attached to the
> number. So the same name becomes a different device. Can you imagine if
> serial port 1 and serial port 2 could trade identities?
Ok so the issue is number stability.
> different external equipment. So if /dev/video0 changes identities with
> /dev/video1, not only do you capture from the wrong camera or whatever,
> you could be using a device unsuited to the application.
Right that is fixable. Soun also needs a way to load a module as
subdevice 'n'. But thats a tiny change
> But how do you decide how to allocated those number ranges? With only
> 256 numbers, and several device types, it's a small space. You want to
> allow for as many devices of a type as possible.
2.3.x will have about 2^20 minor numbers/device ;)
> move or reassign numbers, breaking things. What if some hardware vendors
> want to add their own proprietary types? Or expand something, like dual
Proprietary interfaces go via the normal request for device major/minor
> different V4L2 devices with _unique_ capabilities must all have almost
> _identical_ names. You wouldn't want your QuickCam and your Buz to get
> mixed up. ;) And again, trouble to add more device types.
Why not ?
The video apps can pick a device
> than one API, for example, video capture and VBI. In that case it can be
> desirable to find the VBI device that corresponds to a capture device.
> That association comes out in the naming scheme, e.g:
In v4l it comes via a single ioctl query, which also handles correctly
the case where the answer is 'none of the above'.
> Does that answer the question?
Yes and no.. naming like /dev/video/buz0 is policy and entirely userspace
so people can change it as they like. You can happily ln -s /dev/video4
/dev/tv for example
Alan
------------
To unsubscribe from this list send mail to majordomo@phunk.org with the
line "unsubscribe video4linux" without the quotes in the body of the
message.
List: linux-video
Subject: Re: [video4linux] V4L2: The Great Renaming
From: Bill Dirks <bill.dirks () rendition ! com>
Date: 1998-11-04 1:10:19
Alan Cox wrote:
> > The devices are accessed by name. And the name is attached to the
> > number. So the same name becomes a different device. Can you imagine if
> > serial port 1 and serial port 2 could trade identities?
>
> Ok so the issue is number stability.
The issue is _name_ stability. The number is not relevant. Videodev
might still number the devices internally (or not), that doesn't matter.
Devices are accessed from user space by name, and the name needs to
identify the device.
The old way the name identifies the device is indirect. The name
translates to a number, and the number is supposed to identify the
device. That works for devices that are intrisically identifiable by
number. Bad system for V4L2.
> > different external equipment. So if /dev/video0 changes identities with
> > /dev/video1, not only do you capture from the wrong camera or whatever,
> > you could be using a device unsuited to the application.
>
> Right that is fixable. Soun also needs a way to load a module as
> subdevice 'n'. But thats a tiny change
>
> > But how do you decide how to allocated those number ranges? only
> > 256 numbers, and several device types, it's a small space.
> 2.3.x will have about 2^20 minor numbers/device ;)
> > What if some hardware vendors want to add their own
> > proprietary types? Or expand something, like dual...
>
> Proprietary interfaces go via the normal request for device
> major/minor
But I've only assigned minor numbers to the device types I knew about
when I wrote videodev.c. A proprietary device _would_have_no_minor_.
Simple user extensibility is an advantage in V4L2. With the new scheme,
a driver writer need only put his new name in his v4l2_device structure.
No numbers to allocate. No videodev.c changes. Instant gratification. No
limits.
Perhaps you are suggesting a proprietary interface get its own major.
Then it goes around V4L2 completely. That would be quite inconvenient.
I'm thinking of extensions that would be done as (or within) V4L2 device
drivers. A single V4L2 driver can call v4l2_register_device() multiple
times even for the same physical device in order to export more than one
API on the device. Someone might have their own thing they want to do.
For example, (I'm just making this up) someone might want to augment a
capture driver with a timecode interface that provides the most-recent
timecode data via read(). All he has to do is allocate a v4l2_device
structure for it, put "timecode" in as the device type string and
register it, and modify his read() method.
"Presto!" /dev/v4l2/buz0/timecode! (Once the device node is made.)
> > You wouldn't want your QuickCam and your Buz to get
> > mixed up. ;) And again, trouble to add more device types.
> Why not ? The video apps can pick a device
True, but a lot of people want to do 'vcat /dev/...'. There is an
advantage to device names that keep the same meaning.
> > That association [between devices on the same board] comes out in
> > the naming scheme, e.g:
>
> In v4l it comes via a single ioctl query, which also handles correctly
> the case where the answer is 'none of the above'.
Yes, like I said it can be done with an ioctl. There should probably be
such an ioctl in V4L2 in addition. It is a rather minor point.
> naming like /dev/video/buz0 is policy and entirely userspace
Yes, but there needs to be written policy that everybody sticks to so
applications will be able to enumerate the devices.
Michael reminds me that it should be pointed out that V4L2 only looks at
the last two parts of a device to identify the device. The 'higher'
names are ignored. For example, a device name could be
/dev/foo/bar/baz/buz0/video
and V4L2 will open the device just fine because it will only look at
'buz0' and 'video'. The '/dev/v4l2' proposal is just for consistency so
apps will be able to find the V4L2 devices easily. Maybe this can be
done with an environment variable instead?
> so people can change it as they like. You can happily ln -s /dev/video4
> /dev/tv for example
That won't work. You don't know what /dev/video4 is going to be in the
future. It's the TV today, but it could be the QuickCam or the VGA
grabber tomorrow, even if you don't change your hardware. There is an
advantage to device names that keep the same meaning.
Bill.
------------
To unsubscribe from this list send mail to majordomo@phunk.org with the
line "unsubscribe video4linux" without the quotes in the body of the
message.
List: linux-video
Subject: Re: [video4linux] V4L2: The Great Renaming
From: Alan Cox <alan () cymru ! net>
Date: 1998-11-04 1:50:36
> The issue is _name_ stability. The number is not relevant. Videodev
> might still number the devices internally (or not), that doesn't matter.
> Devices are accessed from user space by name, and the name needs to
> identify the device.
You are trying to set policy not implementation.
> The old way the name identifies the device is indirect. The name
> translates to a number, and the number is supposed to identify the
> device. That works for devices that are intrisically identifiable by
> number. Bad system for V4L2.
So the issue is number stability. If you have number stability you can
symlink any name policy you like.
> Simple user extensibility is an advantage in V4L2. With the new scheme,
> a driver writer need only put his new name in his v4l2_device structure.
> No numbers to allocate. No videodev.c changes. Instant gratification. No
> limits.
And the kernel interface is built entirely around number space.
> Perhaps you are suggesting a proprietary interface get its own major.
> Then it goes around V4L2 completely. That would be quite inconvenient.
But if its non standard its not part of v4l2 - by definition. So either
v4l2 is extended or it stays seperate..
> True, but a lot of people want to do 'vcat /dev/...'. There is an
> advantage to device names that keep the same meaning.
Number, naming is user policy.
> Yes, but there needs to be written policy that everybody sticks to so
> applications will be able to enumerate the devices.
If you are enumerating its easier to walk video0->videon than right code
to walk directory trees.
> That won't work. You don't know what /dev/video4 is going to be in the
> future. It's the TV today, but it could be the QuickCam or the VGA
> grabber tomorrow, even if you don't change your hardware. There is an
> advantage to device names that keep the same meaning.
Thats why you want stable numbering. I agree with that bit, stable
numbering means stable namespace means any symlink you find handy.
Alan
------------
To unsubscribe from this list send mail to majordomo@phunk.org with the
line "unsubscribe video4linux" without the quotes in the body of the
message.
List: linux-video
Subject: Re: [video4linux] V4L2: The Great Renaming
From: Bill Dirks <bill.dirks () rendition ! com>
Date: 1998-11-04 4:40:13
Alan Cox wrote:
> > The issue is _name_ stability. The number is not relevant. Videodev
> > might still number the devices internally (or not), that doesn't matter.
> > Devices are accessed from user space by name, and the name needs to
> > identify the device.
>
> You are trying to set policy not implementation.
I think that terminology is a bit obfuscated.
> > The old way the name identifies the device is indirect. The name
> > translates to a number, and the number is supposed to identify the
> > device. That works for devices that are intrisically identifiable by
> > number. Bad system for V4L2.
>
> So the issue is number stability. If you have number stability you can
> symlink any name policy you like.
If I have a name stability, I can symlink any additional name policy.
> And the kernel interface is built entirely around number space.
I would like to restate the issue, and the proposed solution:
Names are numbers. Numbers are names. The words are clouding the issue.
Let's use a new word. What we have are "tags" that we use to identify
devices.
There are two sets of tags. User-space tags and kernel-space tags.
User-mode code sees only the user-space tags. Kernel code uses only
kernel-space tags. The user tags are the device node names, and the
kernel tags are major/minor numbers.
Device nodes are the junction between the two sets of tags. A device
node makes the connection from a particular user tag to a particular
kernel tag. That connection is set when the node is created and remains
fixed.
The problem in v4l and V4L2, as Alan points out, is that these systems
use kernel tags which are completely arbitary, and-- this is killer--
change around. This is what we are referring to as "instablility".
And that instability of kernel tags reflects right through the rigid
user/kernel junction to the user tags.
So kernel tag instability is the source of the problem. Clearly, we need
to remove the kernel tag instability. But how?
The proposed method is to use a new system of kernel tags based on the
name of the driver and the name of the type of device. So far so good,
that removes the kernel tag instability. But there is a problem: the
user/kernel tag mapping implementation depends on a major/minor type of
kernel tag. The proposed solution is to use the kernel tag itself
embedded in the user tag. Kernel code _can_ see the user tag if it wants
to, so that is a workable way to make the user/kernel connection.
Unfortunately, that creams the separation of user tags and kernel tags
we had before. The administrator doesn't have complete control over the
user tags anymore. Well, what is lost? It seems to me with the
traditional system a given major/minor will always have the same
pre-defined dev node name in most cases, anyway.
I think, taken together, the advantages of the proposed scheme outwiegh
the disadvantages.
Note that devfs, in a way, tries to solve the same kind of problem, and
comes up with the same solution-- use the kernel tag as the user tag.
> Thats why you want stable numbering. I agree with that bit, stable
> numbering means stable namespace means any symlink you find handy.
Yes. Have another idea?
> > Perhaps you are suggesting a proprietary interface get its own major.
> > Then it goes around V4L2 completely. That would be quite inconvenient.
>
> But if its non standard its not part of v4l2 - by definition.
> So either v4l2 is extended or it stays seperate..
False dichotomy.
V4L2 is a 3rd-party extensible system. One example is private ioctls.
Another is private mmap()ed buffer types. There are more examples. A
rather happy fallout of the new /dev scheme is the easy extensibility in
the device type space too. Such a driver registers with
v4l2_register_device(), goes through videodev, adds to the V4L2 dev
namespace, probably uses a lot of the pre-defined V4L2 symbols. It's a
V4L2 device. It's kind of like user-defined classes in C++. V4L2 is more
than the 'official' ioctls and symbols.
And remember that device type extensibility was not just inconvenient
for 3rd parties, it was a _real_ problem, even for me.
Bill.
------------
To unsubscribe from this list send mail to majordomo@phunk.org with the
line "unsubscribe video4linux" without the quotes in the body of the
message.
List: linux-video
Subject: Re: [video4linux] V4L2: The Great Renaming
From: Alan Cox <alan () cymru ! net>
Date: 1998-11-04 5:01:10
> embedded in the user tag. Kernel code _can_ see the user tag if it wants
> to, so that is a workable way to make the user/kernel connection.
You can't assume the name in a d_entry passed to the driver will happen
to match a name in /dev btw or that names will continue to be available
to open methods (they arent in 2.0.x for instance)
The major/minor thing exists because setting device names shouldnt be
up to the kernel. A kernel shouldnt enforce such things [hence the
unix mantra 'implementation not policy'].
So we have a fundamental first case to consider, which is the 'I load
things in arbitary order, which one is my tv'. Thats a 1hour fix, and
sort of on my list
insmod bttv unit=4
and support for unit passing in the register function. Then I dont care
what you call it, although one name set has to be easily enumerable - like
/dev/video*.
> And remember that device type extensibility was not just inconvenient
> for 3rd parties, it was a _real_ problem, even for me.
But the right way to handle such events is to add them to the API after
deciding they dont fit the current logic. Otherwise you get this ever
growing mess of almost compatible objects.
The unix philosophy is very simple - as far as possible one type of hammer
one type of nail.
That means new categories of device dont want to just get shoved in, but
considered and then added in the best place becoming part of the API and yes
they'll need a set of minor numbers allocated if its a totally new part of
V4l - but it'll also need an API specificying too so thats fine.
The reason and situation you want device specific ioctls is for those
drivers that have some fun feature not generally in the API and not
useful to a generic API - reading the hauppauge eeprom being a classic
example. Anyone can open a hauppauge card and drive it. You dont have to
know about the extra features for it to be useful.
Alan
------------
To unsubscribe from this list send mail to majordomo@phunk.org with the
line "unsubscribe video4linux" without the quotes in the body of the
message.