Gerd Knorr wrote: > > Hi, > > I'm just browsing the v4l and v4l2 code. I'd like to see v4l2 early > in 2.5.x in the standard kernel and looking for a clever way to get > this done (and fix some videodev problems). > > I've seen my videodev patch from bttv 0.8.x made it into the videodevX > code. Now we have *three* methods to register a driver: > > (1) The very old one (video_device + function pointers) > (2) The bttv 0.8.x one (video_device + fops) > (3) The v4l2 one (v4l2_device). > > This is one to much. We have to keep (1) for backward compatibility > with the existing drivers in the kernel. I'd like to drop (3) and keep > (2) for the following reasons: > > * I think it's clever to simply use a struct file_operations directly. > Most of the fops functions in videodevX.c simply pass down the call > to the driver (the only exception is v4l2_video_ioctl), so why not > call the driver directly in the first place? Also we don't have to > fiddle with videodev if struct file_operations changes again for > some reason. > > * I'd like to have videodev.c just register drivers and hand out the > minor numbers and do _nothing_ else, i.e. do what soundcore does > for the sound drivers. videodev.c shouldn't care which API a driver > uses. All the v4l1 compatibility helper code which is in videodevX > right now should go to some other module (v4l1-compat.c or something > like that). Agreed. The only provisio being that there must be some way for a driver registering by method 2 to say if it is v4l1/v4l2 so that the compat layer can initialise for that device. We will also need a clean method for "alternative" names to id the compatible devices (the compatibility layer and actual driver will no longer be able to share the same minor number. > Plan as follows: > > * fix videodev.c. A patch is below. It does add register method (2) > to the kernel's videodev.c. It adds a lock to the register function > to fix a race. It allows drivers to ask for a specific device number. > This becomes important these days as people start using different > devices (bttv+usbcam) at the same time. Fixed module load order > being the only way to get a fixed special file -> device mapping > is not very nice [longer version of the patch which fixes all kernel > drivers is available too]. > IMHO this should go into 2.4.x. I think the base name for the device should also be passed in the "register" call - this will make it possible to also free the v4l1 drivers from arbitrary restrictions on minor numbers, and allow for more sensible devfs names. Will also have to look at the "type" parameter, as this changes meaning for v4l1/v4l2 - perhaps offset them, and use this to id v4l1/v4l2 devices? Also, fix the procfs stuff to be v4l2-aware. > * Fixes/cleanups in the v4l2 capture API. Major item on the TODO > list is the dma-to-userspace issue discussed here some time ago. > Also some minor byte order problems (15/16 bpp rgb is available > in little endian only, ...). Put the v4l2 capture API largely > as-is into the 2.5.x kernel then. The DMA issue is still a major question - the discussion ended on two completely divergent solutions, each with major advantages an disadvantages, and no definitive solution... This will need a bit more discussion (or possibly a decent all out brawl ;->). The byte order problems should be resolved shortly with the definition of more video formats for the big endian machines. > The vbi stuff can be dropped from v4l2 I think. The current vbi API > in 2.4.x is cloned from v4l2, and we certainly don't need exactly the > same API twice in the kernel. No. The only thing that is cloned is "struct vbi_format", and there will be no saving removing this - just namespace confusion. > What is the status of the other v4l2 API's? codec? effects? Any > existing drivers which use these? There was some work in this direction, but I am not sure what happened to it... -justin
