Hello Gerd, > IMHO the compatibility layer should'nt be mandatory. I think the best > way to handle that is to have a set of helper functions for code which > likely can be useful for multiple drivers (like translating formats > between v4l1 <=> v4l2) in a compat module. The v4l2 driver can use > all / some / none of these functions. If it wants to use these > functions, it simply calls them. I have no problems with your idea of using the "video_device + fops" device handling, but I don't understand the idea of removing the "v4l2-awareness" out of the videodevX-module. Just to get things right here: do you want to modify the original videodev1-module to let the v4l2 driver fit into there, or do you want to modify the videodev2/videodevX-module to let the v4l drivers fit into there? I always thought that it would be better to drop videodev1 and modify videodev2, so that v4l1 drivers and apps still work. At the moment (e.g. with videodevX/videodev2) there is minimum v4l-backward compatibility code at least in my v4l2 driver -- and that's good. All important stuff (ioctl translation, format translation, etc.) is done outside the v4l2 driver. Do you really mean to move the responsibility of being v4l-backward compatible deep down to a v4l2 driver, e.g. looking at the ioctls, formats and do the translation by calling helper functions? At the moment videodevX adds backward compatibility to any v4l2 without special help of the driver. With your proposal, we would have code duplication for v4l backward compatibility in every v4l2 driver around. Even good and robust v4l2 drivers, who are v4l1 aware through videodevX, would need to get tweaked to become v4l1 aware the way you want it. I don't think that's a wise idea. Please correct my if I am terribly wrong on something. > Gerd CU Michael.
