[linux-dvb] [ANNOUNCE] DVB API improvements End-user point of viwer

Mika Laitio lamikr at pilppa.org
Fri Sep 26 11:31:05 CEST 2008

> You can also find patched enduser applications on mcentral.de which can be used
> with other devices and provide extra features which are required in
> order to get devices
> work properly.
> There's gqradio patched to support lirc and digital audio
> automatically, same with vlc and tvtime
> (the last one also having different video output plugins which allow
> software rendering if xvideo
> hardware acceleration isn't available.
> Still one fact till now is that not all devices which have worked in
> v4l-dvb-experimental back in time
> are now supported by v4l-dvb on linuxtv.org and nor all the em28xx
> based devices are yet in the
> em28xx-new tree, whereas the second one is the result of heavy
> refactoring and better manufacturer
> support for some back then reverse engineered components (-which is
> good that they got replaced in order
> to raise the signal strength).

The problem here is that only a few developers knows about this, while 
there could be a hundred of thousands of end users. If some hardware like
HVR-4000 or AF9015 have been able to get working by developers let's say 
about 6 month ago, then that support should be available in the latest 
kernels and latest distros. It is really messy for them try to figure out
multiple different repositories which support their hardware and then
compile and try each of them separately to find out

a) which are supported with their kernel versions
b) differences in supported features and patches in each repository
c) how to get hardware A supported by repository X and hardware B 
supported by the repository Y work together with user app Z which requires 
patch C for hardware A and patch D for hardware B...

So the only solution is really to get things from development trees back 
to main v4l-dvb development repository which acts like a final barrier 
for checking co-existence of different works before things get merged to Linux 

For me it seems that this is now not happening because people argue from 
a) different ways the ways how to do things (this is good as there are often multiple
different requirements and possibilities for doing things)
b) How to make a good technical decision between multiple different 
choises after the discussion that satisfies everybody (this is the thing 
that is currently not happening)

As step (b) is now failing, the gap between main repository and 
development repositories get huge and messy.

What do you think, could think work better if there would be a couple of 
people who would actively try to find things that work for example in 
Mantis, multiproto, af915 and S2API trees  and then try to find a way for 
re-formatting those patches to form that would be acceptable to main 
repository. This would after all follow the spirit of GPL which encourages 
the evolment of work made by people, instead of making anybody to be the 
only owner of certain new work (that is in after all based to work made by 
others earlier)

Good thing in that would be that it would speeden up the 
merging of the development. Bad thing would be that in perfect world this 
"patch monkey" would not be needed at all because developers would them 
self send "signed of" patches with much faster frequency than what is 
currently happening. In addition this "I r

Afterwards it is easy to be wise, but maybe following development steps 
would have worked much better 2-1 years ago with multiproto tree for 

a) manu send patch (was done)
b) somebody reviweed it (was done)
c) discussion from a and b...
c) vote in the list whether some of the directions suggested with a, b and 
c steps is the way to go
d) announcement of the vote result
e) everybody agrees and somebody would have started to assist manu for 
getting agreed changes to DVB-V4L tree.
f) manu and others would have started to merge work from multiproto tree 
to V4L-DVB tree...

So instead of trying to make things work perfectly in development tree,
big steps should be agreed and then start working with smaller steps to 
get things faster merged back to main tree.


More information about the linux-dvb mailing list