Re: v4l2 + kernel

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



OK - this whole thing is starting to get seriously ugly again.  So far
we have two options:

Gerd: 1 registration method, move all responsibility to the driver (very
intrusive at all levels).
Michael: retain both registration methods (results in overly complex
videodev.c).

I would like to propose a third method, which may contain the best of
both worlds (although it may also be hopelessly impractical):

1) Retain only 1 registration method (Gerd's fops method).
2) Remove all v4l1 compatibility into a separate module.
3) Have the compatibility module register distinct devices for v4l1
compatibily.

What will change:
1) v4l1 drivers will not change.
2) v4l2 drivers must do their own userspace copying (probably a single
helper function in videodev that v4l2 modules must call).
3) applications will see two devices for every v4l2 device - one the
native v4l2 device, and the other a completely separate device
registered by the compatibility layer.
4) some sort of a hook will be required in videodev to inform the
compatibility layer that a non-v4l1 capable device has just registered.

The only disadvantage of this is that we now get two devices (and the
consequent user confusion) for every v4l2 device).  The main advantage
is that it is minimally intrusive, and completely modularises the
compatibility layer.

Comments?

-justin





[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