On Wed, 26 Jul 2006, Michael Krufky wrote: > Trent Piepho wrote: > > On Wed, 26 Jul 2006, Stone wrote: > >> The checkin that broke the VDR compile is this one: > >> > >> changeset: 4343:303b58b4c499 > >> parent: 4340:2d222384fff5 > >> user: Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxx> > >> date: Sun Jul 23 06:31:19 2006 -0300 > >> summary: Fix for compilation without V4L1 or V4L1_COMPAT > >> > >> It seems nobody has noticed there is a problem yet... > > > > Please try this patch and see if it fixes the problem for you. > > Why even provide such a patch? This will never me added to the kernel - > All you are doing is prolonging the inevitable problem. We are much > better off having the applications get fixed. I wasn't planing on trying to add that to the kernel. Telling someone to port VDR to to V4L2 is tantamount to telling them they can't compile VDR anymore. Anyone who could do the port is easily capable of turning the V4L1 header back on without any help from me. I'm not trying to argue for keeping V4L1 longer, but I think this change to videodev.h is maybe not perfect. Why are kernel sources allowed to include videodev.h _at all_ when V4L1 is off? Is it safe to disable V4L1 for userspace programs yet? Are the V4L2 versions of the encoder and decoder APIs finished and has there been enough time to port applications to them? What is the point of continuing to provide kernel support for the V4L1 API when userspace programs are no longer allowed to use V4L1? Why have the v4l1 compat module when user programs are not allowed to use it? Is the goal to allow old V4L1_binaries to be used, but not allow old V4L1 sources to compile? That's an odd choice, to provide more compatibility for binaries and sources. _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
