Em 24-06-2011 09:20, Devin Heitmueller escreveu: > Also, it screws up the ability for users to get fixes through the > media_build tree (unless you are increasing the revision constantly > with every merge you do). Patches merged, and media_build modified in order to use the V4L2 stack version, instead of the kernel one. So, while I'm using a 2.6.32 kernel: $ uname -a Linux pedra 2.6.32-131.0.15.el6.x86_64 #1 SMP Tue May 10 15:42:40 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux Driver reports version 3.0.0: $ v4l2-ctl -D Driver Info (not using libv4l2): Driver name : vivi Card type : vivi Bus info : vivi-000 Driver version: 3.0.0 Capabilities : 0x05000001 Video Capture Read/Write Streaming It may be a good idea to increment the extraver number to be, for example, 3.0.99 (or to just decrement 1 number), in order to reflect that this driver is not the vanilla 3.0.0, but, instead, a backported one, otherwise, it will report the version from the last git backport we merge at media_tree.git. If we just subtract 1, we'll have (right now): $ v4l2-ctl -D Driver Info (not using libv4l2): Driver name : vivi Card type : vivi Bus info : vivi-000 Driver version: 2.255.255 Capabilities : 0x05000001 Video Capture Read/Write Streaming Which looks somewhat weird, but, after the 3.1 merge window, it will be 3.0.255, with would be nice. So, if we go this way, the better is to wait until 3.1-rc1 before applying it. Comments? PS.: The media_build is not optimized in the sense that a version increment will make it recompile everything. I'll likely fix it if it bothers me enough ;) Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
