Re: [RFCv2 PATCH 12/12] Remove audio.h, video.h and osd.h.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Nov 26, 2011 at 5:19 PM, Hans Verkuil <hverkuil@xxxxxxxxx> wrote:
> On Saturday, November 26, 2011 06:55:52 Oliver Endriss wrote:
>> On Friday 25 November 2011 23:06:34 Andreas Oberritter wrote:
>> > On 25.11.2011 17:51, Manu Abraham wrote:
>> > > On Fri, Nov 25, 2011 at 9:56 PM, Mauro Carvalho Chehab
>> > > <mchehab@xxxxxxxxxx> wrote:
>> > >> Em 25-11-2011 14:03, Andreas Oberritter escreveu:
>> > >>> On 25.11.2011 16:38, Mauro Carvalho Chehab wrote:
>> > >>>> Em 25-11-2011 12:41, Andreas Oberritter escreveu:
>> > >>>>> On 25.11.2011 14:48, Mauro Carvalho Chehab wrote:
>> > >>>>>> If your complain is about the removal of audio.h, video.h
>> > >>>>>
>> > >>>>> We're back on topic, thank you!
>> > >>>>>
>> > >>>>>> and osd.h, then my proposal is
>> > >>>>>> to keep it there, writing a text that they are part of a deprecated API,
>> > >>>>>
>> > >>>>> That's exactly what I proposed. Well, you shouldn't write "deprecated",
>> > >>>>> because it's not. Just explain - inside this text - when V4L2 should be
>> > >>>>> preferred over DVB.
>> > >>>>
>> > >>>> It is deprecated, as the API is not growing to fulfill today's needs, and
>> > >>>> no patches adding new stuff to it to it will be accepted anymore.
>> > >>>
>> > >>> Haha, nice one. "It doesn't grow because I don't allow it to." Great!
>> > >>
>> > >> No. It didn't grow because nobody cared with it for years:
>> > >>
>> > >> Since 2.6.12-rc2 (start of git history), no changes ever happened at osd.h.
>> > >>
>> > >> Excluding Hans changes for using it on a pure V4L device, and other trivial
>> > >> patches not related to API changes, the last API change on audio.h and video.h
>> > >> was this patch:
>> > >>        commit f05cce863fa399dd79c5aa3896d608b8b86d8030
>> > >>        Author: Andreas Oberritter <obi@xxxxxxxxxxx>
>> > >>        Date:   Mon Feb 27 00:09:00 2006 -0300
>> > >>
>> > >>            V4L/DVB (3375): Add AUDIO_GET_PTS and VIDEO_GET_PTS ioctls
>> > >>
>> > >>        (yet not used on any upstream driver)
>> > >>
>> > >> An then:
>> > >>        commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
>> > >>        Author: Linus Torvalds <torvalds@xxxxxxxxxxxxxxx>
>> > >>        Date:   Sat Apr 16 15:20:36 2005 -0700
>> > >>
>> > >>            Linux-2.6.12-rc2
>> > >>
>> > >> No changes adding support for any in-kernel driver were ever added there.
>> > >>
>> > >> So, it didn't grow over the last 5 or 6 years because nobody submitted
>> > >> driver patches requiring new things or _even_ using it.
>> > >>
>> > >>>
>> > >>>>>> but keeping
>> > >>>>>> the rest of the patches
>> > >>>>>
>> > >>>>> Which ones?
>> > >>>>
>> > >>>> V4L2, ivtv and DocBook patches.
>> > >>>
>> > >>> Fine.
>> > >>>
>> > >>>>>> and not accepting anymore any submission using them
>> > >>>>>
>> > >>>>> Why? First you complain about missing users and then don't want to allow
>> > >>>>> any new ones.
>> > >>>>
>> > >>>> I didn't complain about missing users. What I've said is that, between a
>> > >>>> one-user API and broad used APIs like ALSA and V4L2, the choice is to freeze
>> > >>>> the one-user API and mark it as deprecated.
>> > >>>
>> > >>> Your assumtion about only one user still isn't true.
>> > >>>
>> > >>>> Also, today's needs are properly already covered by V4L/ALSA/MC/subdev.
>> > >>>> It is easier to add what's missing there for DVB than to work the other
>> > >>>> way around, and deprecate V4L2/ALSA/MC/subdev.
>> > >>>
>> > >>> Yes. Please! Add it! But leave the DVB API alone!
>> > >>>
>> > >>>>>> , removing
>> > >>>>>> the ioctl's that aren't used by av7110 from them.
>> > >>>>>
>> > >>>>> That's just stupid. I can easily provide a list of used and valuable
>> > >>>>> ioctls, which need to remain present in order to not break userspace
>> > >>>>> applications.
>> > >>>>
>> > >>>> Those ioctl's aren't used by any Kernel driver, and not even documented.
>> > >>>> So, why to keep/maintain them?
>> > >>>
>> > >>> If you already deprecated it, why bother deleting random stuff from it
>> > >>> that people are using?
>> > >>>
>> > >>> There's a difference in keeping and maintaining something. You don't
>> > >>> need to maintain ioctls that haven't changed in years. Deleting
>> > >>> something is more work than letting it there to be used by those who
>> > >>> want to.
>> > >>
>> > >> Ok. Let's just keep the headers as is, just adding a comment that it is now
>> > >> considered superseded.
>> >
>> > Thank you! This is a step into the right direction.
>> >
>> > > http://dictionary.reference.com/browse/superseded
>> > >
>> > > to set aside or cause to be set aside as void, useless, or obsolete, usually
>> > > in favor of something mentioned; make obsolete: They superseded the
>> > > old statute with a new one.
>> > >
>> > > No, that's not acceptable. New DVB devices as they come will make use
>> > > of the API and API changes might be applied.
>> >
>> > Honestly, I think we all should accept this proposal and just hope that
>> > the comment is going to be written objectively.
>>
>> 'Hoping' is not enough for me anymore. I am deeply disappointed.
>> Mauro and Hans have severely damaged my trust, that v4ldvb APIs are
>> stable in Linux, and how things are handled in this project.
>>
>> So I request a public statement from the subsystem maintainer that
>> 1. The DVB Decoder API will not be removed.
>> 2. It can be updated if required (e.g. adding a missing function).
>> 3. New drivers are allowed to use this architecture.
>> 4. These driver will be accepted, if they follow the kernel standards.
>>
>> The reason is simple: I need to know, whether this project is still
>> worth investing some time, or it is better to do something else.
>
> 1) There are two APIs that do the same thing: the DVB decoder API and the
>   V4L2 API.
> 2) That's bad because it confuses driver developers and application developers
>   who have to support *two* APIs to do the same thing.
> 3) The DVB decoder API is used in only one DVB driver (av7110), and in one
>   V4L2 driver (ivtv). The latter is easily converted to V4L2 which leaves only
>   one driver, av7110.
> 4) A decoder API has nothing to do with DVB as a standard, it simply takes
>   the output of the DVB part of the hardware and decodes it to the output.
>   That's basic V4L2 functionality.


It does, with newer scrambling systems, the decoder is tightly tied to the
CA system(s) associated.

According to the CI+ specification:

"It is mandatory for the Application MMI to provide limited control
over the MPEG
decoders which enable the broadcast video and audio of the current service to
be presented, additionally a full frame I-frame may be used to provide rich
graphics backgrounds. The MMI Application may deny the application MMI
control of the MPEG decoder if a resource conflict results."

What you are talking about is FTA decoders which don't have any scrambling
control, but almost all newer DVB decoders supporting CI+ work that way.
If you look at any new digital TV/service, it comes with CI+ and many providers
switching over.

Because of a wrong decision, users cannot be denied using the same.
--
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


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux