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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
