All of lore.kernel.org
 help / color / mirror / Atom feed
* What to do with videodev.h
@ 2011-01-26  8:26 Hans de Goede
  2011-01-26  9:07 ` Mauro Carvalho Chehab
  0 siblings, 1 reply; 5+ messages in thread
From: Hans de Goede @ 2011-01-26  8:26 UTC (permalink / raw)
  To: Linux Media Mailing List

Hi All,

With v4l1 support going completely away, the question is
raised what to do with linux/videodev.h .

Since v4l1 apps can still use the old API through libv4l1,
these apps will still need linux/videodev.h to compile.

So I see 3 options:
1) Keep videodev.h in the kernel tree even after we've dropped
the API support at the kernel level (seems like a bad idea to me)
2) Copy videodev.h over to v4l-utils as is (under a different name)
and modify the #include in libv4l1.h to include it under the
new name
3) Copy the (needed) contents of videodev.h over to libv4l1.h

I'm not sure where I stand wrt 2 versus 3. Comments anyone?

Regards,

Hans

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: What to do with videodev.h
  2011-01-26  8:26 What to do with videodev.h Hans de Goede
@ 2011-01-26  9:07 ` Mauro Carvalho Chehab
  2011-01-26  9:47   ` Hans Verkuil
  0 siblings, 1 reply; 5+ messages in thread
From: Mauro Carvalho Chehab @ 2011-01-26  9:07 UTC (permalink / raw)
  To: Hans de Goede; +Cc: Linux Media Mailing List

Hi Hans,

Em 26-01-2011 06:26, Hans de Goede escreveu:
> Hi All,
> 
> With v4l1 support going completely away, the question is
> raised what to do with linux/videodev.h .
> 
> Since v4l1 apps can still use the old API through libv4l1,
> these apps will still need linux/videodev.h to compile.
> 
> So I see 3 options:
> 1) Keep videodev.h in the kernel tree even after we've dropped
> the API support at the kernel level (seems like a bad idea to me)

That's a bad idea.

> 2) Copy videodev.h over to v4l-utils as is (under a different name)
> and modify the #include in libv4l1.h to include it under the
> new name
> 3) Copy the (needed) contents of videodev.h over to libv4l1.h

I would do (3). This provides a clearer signal that V4L1-only apps need
to use libv4l1, or otherwise will stop working.

Of course, the better is to remove V4L1 support from those old apps.
There are a number of applications that support both API's. So, it
is time to remove V4L1 support from them.

> I'm not sure where I stand wrt 2 versus 3. Comments anyone?

Cheers,
Mauro

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: What to do with videodev.h
  2011-01-26  9:07 ` Mauro Carvalho Chehab
@ 2011-01-26  9:47   ` Hans Verkuil
  2011-01-26 11:36     ` Mauro Carvalho Chehab
  0 siblings, 1 reply; 5+ messages in thread
From: Hans Verkuil @ 2011-01-26  9:47 UTC (permalink / raw)
  To: Mauro Carvalho Chehab; +Cc: Hans de Goede, Linux Media Mailing List

> Hi Hans,
>
> Em 26-01-2011 06:26, Hans de Goede escreveu:
>> Hi All,
>>
>> With v4l1 support going completely away, the question is
>> raised what to do with linux/videodev.h .
>>
>> Since v4l1 apps can still use the old API through libv4l1,
>> these apps will still need linux/videodev.h to compile.
>>
>> So I see 3 options:
>> 1) Keep videodev.h in the kernel tree even after we've dropped
>> the API support at the kernel level (seems like a bad idea to me)
>
> That's a bad idea.
>
>> 2) Copy videodev.h over to v4l-utils as is (under a different name)
>> and modify the #include in libv4l1.h to include it under the
>> new name
>> 3) Copy the (needed) contents of videodev.h over to libv4l1.h
>
> I would do (3). This provides a clearer signal that V4L1-only apps need
> to use libv4l1, or otherwise will stop working.

I agree with this.

> Of course, the better is to remove V4L1 support from those old apps.
> There are a number of applications that support both API's. So, it
> is time to remove V4L1 support from them.

So who is going to do that work? That's the problem...

But ensuring that they no longer compile is a good start :-)

Although most have a private copy of videodev.h as part of their sources.

Regards,

     Hans

>> I'm not sure where I stand wrt 2 versus 3. Comments anyone?
>
> Cheers,
> Mauro
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Hans Verkuil - video4linux developer - sponsored by Cisco


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: What to do with videodev.h
  2011-01-26  9:47   ` Hans Verkuil
@ 2011-01-26 11:36     ` Mauro Carvalho Chehab
  2011-01-26 14:31       ` Devin Heitmueller
  0 siblings, 1 reply; 5+ messages in thread
From: Mauro Carvalho Chehab @ 2011-01-26 11:36 UTC (permalink / raw)
  To: Hans Verkuil; +Cc: Hans de Goede, Linux Media Mailing List, Devin Heitmueller

Em 26-01-2011 07:47, Hans Verkuil escreveu:
>> Hi Hans,
>>
>> Em 26-01-2011 06:26, Hans de Goede escreveu:
>>> Hi All,
>>>
>>> With v4l1 support going completely away, the question is
>>> raised what to do with linux/videodev.h .
>>>
>>> Since v4l1 apps can still use the old API through libv4l1,
>>> these apps will still need linux/videodev.h to compile.
>>>
>>> So I see 3 options:
>>> 1) Keep videodev.h in the kernel tree even after we've dropped
>>> the API support at the kernel level (seems like a bad idea to me)
>>
>> That's a bad idea.
>>
>>> 2) Copy videodev.h over to v4l-utils as is (under a different name)
>>> and modify the #include in libv4l1.h to include it under the
>>> new name
>>> 3) Copy the (needed) contents of videodev.h over to libv4l1.h
>>
>> I would do (3). This provides a clearer signal that V4L1-only apps need
>> to use libv4l1, or otherwise will stop working.
> 
> I agree with this.
> 
>> Of course, the better is to remove V4L1 support from those old apps.
>> There are a number of applications that support both API's. So, it
>> is time to remove V4L1 support from them.
> 
> So who is going to do that work? That's the problem...
> 
> But ensuring that they no longer compile is a good start :-)
> 
> Although most have a private copy of videodev.h as part of their sources.

The ones that don't have videodev.h will compile-break on distros. So distros
will need to do something to keep it working, or they'll just drop those
pre-historic beasts. It is the Evolution Theory working for software:
to adapt or to be extinguished ;)

The ones that are shipped with videodev.h and weren't converted to libv4l
might eventually stay there for a longer time, as people will only notice
when a bug will be reported. If we know what are those apps, then we can
add a blacklist at linuxtv and/or contact interested parties on fixing/removing
them.

We should touch the tools that we care of. Maybe Devin could change tvtime,
we should remove V4L1 driver from xawtv3/xawtv4.

Regards,
Mauro

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: What to do with videodev.h
  2011-01-26 11:36     ` Mauro Carvalho Chehab
@ 2011-01-26 14:31       ` Devin Heitmueller
  0 siblings, 0 replies; 5+ messages in thread
From: Devin Heitmueller @ 2011-01-26 14:31 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Hans Verkuil, Hans de Goede, Linux Media Mailing List

On Wed, Jan 26, 2011 at 6:36 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> We should touch the tools that we care of. Maybe Devin could change tvtime,
> we should remove V4L1 driver from xawtv3/xawtv4.

Yeah, I have some tvtime work planned, and dropping v4l1 was
definitely on the list.  I actually dropped the private versions of
videodev.h/videodev2.h from my repo, so I won't have much choice.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2011-01-26 14:31 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-01-26  8:26 What to do with videodev.h Hans de Goede
2011-01-26  9:07 ` Mauro Carvalho Chehab
2011-01-26  9:47   ` Hans Verkuil
2011-01-26 11:36     ` Mauro Carvalho Chehab
2011-01-26 14:31       ` Devin Heitmueller

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.