Linus,

Please pull from:
        ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git master

We have 300+ patches this time, covering lots of drivers improvements and fixes.

Also, there are several core changes:
	- Unified support for Hybrid tuners on both V4L and DVB core;
	- videobuf split into PCI DMA S/G specific and a generic module;
	- added a videobuf handler for drivers that need vmalloc'ed memory like 
	  USB devices).

And some driver additions:
	- cx23885 driver;
	- ivtv framebuffer driver;
	- tcm825x driver.

I still have two cx88-alsa patches pending, at devel tree. Those two are 
dependent from -ALSA merge. So, I should send you a pull request later, after 
being sure that you've already pulled from alsa.

Cheers,
Mauro.

---

 Documentation/dvb/faq.txt                          |    2 +-
 Documentation/video4linux/CARDLIST.bttv            |    1 +
 Documentation/video4linux/CARDLIST.cx23885         |    5 +
 Documentation/video4linux/CARDLIST.saa7134         |    5 +-
 drivers/media/Kconfig                              |   70 +-
 drivers/media/common/Kconfig                       |    2 +-
 drivers/media/common/ir-functions.c                |    1 -
 drivers/media/common/ir-keymaps.c                  |   62 +-
 drivers/media/common/saa7146_core.c                |   34 +-
 drivers/media/common/saa7146_fops.c                |    5 +-
 drivers/media/common/saa7146_i2c.c                 |   23 +-
 drivers/media/common/saa7146_vbi.c                 |    9 +-
 drivers/media/common/saa7146_video.c               |   11 +-
 drivers/media/dvb/bt8xx/bt878.c                    |    1 -
 drivers/media/dvb/bt8xx/bt878.h                    |    7 +-
 drivers/media/dvb/bt8xx/dvb-bt8xx.c                |    1 -
 drivers/media/dvb/cinergyT2/cinergyT2.c            |    8 +-
 drivers/media/dvb/dvb-core/dmxdev.c                |    1 -
 drivers/media/dvb/dvb-core/dvb_ca_en50221.c        |   93 +-
 drivers/media/dvb/dvb-core/dvb_demux.c             |    ...
[ message continues ]

the chances of the em28xx are not accepted from my side since the latest code
which supports way more hardware is offtree for various reasons.

The em28xx which is maintained from my side is far ahead what's in the
kernel at the moment. There is some advanced code available which
pulls away the dependency from v4l-dvb of several modules.
I will provide a patch for upstream within the next 2-3 days.
The em28xx driver which is in the kernel only supports analogue TV.
Although the hardware is capable of analogue TV and digital TV, the
updated tree which is currently available on mcentral.de supports way
more devices than the inkernel driver, and it doesn't depend on code
which is broken and breaks support
for several of those devices.
Upcoming device revisions will also depend on the latest changes which are
available on mcentral.de.

Markus
-

[ message continues ]

To point to more changes within the available driver which hasn't been merged
within the last 1 1/2 years:
* it supports non usbaudio based video devices.
* has support for dvb-t/atsc
* allows multiple device node access in case of analogue TV
* has teletext/VBI support for PAL.
* it supports modules which are now in userspace instead of
kernelspace due disagreements with some developers for 1 1/2 years.
* I do not agree with certain developers who do not have any experience
with certain parts of the code for redoing it a 4th time now. My patience
is over, which includes the company support in my back to get those
devices supported.

Markus
-

[ message continues ]

Do you plan on maintaining your own private driver tree for all of eternity?
-

[ message continues ]

I plan to tidy it up for inclusion and put everything together to get
it work properly.
The code which is in the kernel is around 5 % done, the code which is
available on mcentral.de is around 50% done. It still requires some
work to get _all_ devices supported, and keeping the development
process in an endless loop and depending on people who have no idea
and don't care about certain requirements is no option.
The upcoming devices which use other chips and which have more
features will at least also use those drivers. I expect that it will
pump up the driver to support more than 100 devices within the next
year.

Markus
-

[ message continues ]

I looked at this recently, and I'm not sure the core em28xx code was
really that different (at least, pre-userspace). Most of the core
changes seemed to be related to Markus' driver having (semi-working)
VBI support. I haven't tried this recently; I disabled it a while back
because it had a bug that caused a kernel panic half the time when
attempting to record something with MythTV.

The in-kernel driver looks mostly sound, though I can't test it
myself. (One other interesting thing that was added in Markus' driver
is various v4l1 ioctls, which may be useful to some people.)

Incidentally, I notice you appear to be developing userspace drivers

Are you threatening to deliberately sabotage company support for these
devices by v4l/linuxtv in favour of your userspace drivers?

Also, I'm not sure reworking the non-userspace version of the code to
a mergable state is actually that hard. (I'm cleaning up bits of it in
my spare time, because I may have to port it to newer kernels myself
in the future and it's annoying to work with as-is.) Eliminating the
need for changes to the core v4l/dvb code appears to be the easy bit;
the main difficulty is finding and fixing the unexpected breakages due
to the interesting coupling between bits of the code. (The other
difficulty is keeping track of whether analog or digital firmware is
currently loaded in the xc3028 in hybrid devices; I'm using an iffy
solution, but I think better ones exist.) As I recall, the changes to
core code were the major roadblock in the way of merging.

Aidan
-

[ message continues ]

Yes, for example VLC doesn't support v4l2 yet.
Here is a patch I back ported to 2.6.17 last year.
http://www.pixelbeat.org/patches/linux-2.6.17-em28xx-v4l1.diff
I didn't try to get it merged as I thought Markus would do it,
but looks like that's unlikely now.

Also here is a patch to allow shared access to the video device
(so you can have a separate tuner program to VLC for example):

It is necessary if Markus wants to stop people merging code back from
his in-kernel driver fork. Call me a cynic, but I'm confused about Markus'
motives in all this.

Markus, please do the right thing and just merge your code!
(and please don't reply this giving reasons you won't/can't do this).

Pádraig.
-

[ message continues ]

The tvp5150 as well as several other drivers have some slight changes
in it to get some devices work.
My motivation behind it is that since I don't agree with certain
linuxtv development paths and it makes it alot easier to handle

Merge the bridging code and the issue is done, the other guys should
go their own paths with their own drivers if they want so. Time will
show what will be better in the end.
There are not so many devices out there which have newer requirements,
although the em28xx is a good example for at least one device which
doesn't fit.

If someone's looking for another disagreement between developers
(which my code is not part of):
http://thread.gmane.org/gmane.linux.drivers.dvb/36583

Markus
-

[ message continues ]

On Thu, 11 Oct 2007 01:00:39 +0200
"Markus Rechberger" <mrechberger@gmail.com> wrote:

Please don't send 900 line emails to which you have added only an additional

Until your attempt to get the userspace-driver work merged into the kernel
is successful (and from my reading of last month's discussion it is nowhere
near that), we should continue to maintain the present driver.

If you choose to not participate in that maintenance then others will need
to do their best in this regard.

What we should not and will not do is to permit the current driver to be
held hostage to your attempt to force a controversial and apparently
unwelcome change into the tree.


-

[ message continues ]

It makes no sense to keep the kernel driver uptodate, it would make
more sense to support the latest driver (which some people are
supporting).
I just had a look at the driver downloads it makes around 600
downloads for september for this driver. If someone's interested in
those stats I can give access to it privatly.
The current option for people who own such a device is to take the
driver from mcentral.de.

Markus
-

[ message continues ]

It makes heaps of sense to keep the in-tree driver up to date if the

But that ignores all of last month's discussion and the various
reservations which various people have expressed.

Please take my advise, based upon my experience in kernel development: I
don't expect that we'll be merging the mcentral.de driver in anything like
its present form.


Well that's a shame.  But we have n,000 drivers in-tree which work OK
without doing unusual and disturbing user/kernel splits.
-

[ message continues ]

There were discussions since the beginning of 2006 which lead nowhere.
It finally turned out to be a personal issue between developers and to
stop those useless discussions and to not having to rely on an
incomplete API and not having to strip off the sample drivers the

ahm, there are more problems than you might think about...
* broken drivers (eg saa7115, incomplete driver tvp5150)
* limited API which is managed by a few (DVB/V4L)
* having to deal with people who disagree alot

I submitted the patches RFCs and didn't get proper comments back then
this doesn't motivate me in any way to continue the work and spend any
efforts in getting companies to release their sample drivers.

As pointed out it's possible to release the complete driver in
userland even as binary driver if someone wants to, unless someone
kicks out usbfs. But the conversion would take a while. And regarding
the plans of the other drivers I pointed out what my plans are.

Markus
-

[ message continues ]

On Thu, Oct 11, 2007 at 07:09:47AM +0200, Markus Rechberger wrote:
 
 > It makes no sense to keep the kernel driver uptodate, it would make
 > more sense to support the latest driver (which some people are
 > supporting).
 > I just had a look at the driver downloads it makes around 600
 > downloads for september for this driver.
 
600 downloads a month may seem like a lot to you for one driver.
But think about how many people are running distribution kernels
rather than kernels they built themselves.  Typically none of
these people will even know your driver exists, let alone go
running after it to download/build it.

From an end-user perspective, out of tree drivers are a nuisance.
Time and time again, I get bug reports from users claiming
some bug is in the kernel, where the problem is actually that
they're running some out of tree driver that hasn't been 
updated to run on the latest kernels.

It's really in everyones (including yours) best interests
to get drivers merged into mainline.

	Dave

-- 
http://www.codemonkey.org.uk
-

[ message continues ]

(please read through it ... )

I didn't comment this one yet, so here a few further details. Note I'm
not looking forward to annoy other developers I want to get that
driver completly done.

some background information on the further userspace idea:
http://lists.freebsd.org/pipermail/freebsd-multimedia/2007-September/007497.html

short overview, this driver has moved a massive amount to userspace:
libtuner/
        (libtuner.so) User-mode drivers for tuners, demodulators, and anything
else that constitutes the "frontend".

So how is this related to my project? This project can reuse all the
userspace demods and tuner code which I have as they are including the
floating point stuff.

I had a discussion with Hans Verkuil (the IVTV maintainer) about my
requirements and his answer was:

2:06 <hverkuil> - However, it is a fact that the relationship between
you and the linux(tv) community are strained to put it mildly. I
remain convinced that none of this has any technical basis but has all
to do with personality conflicts. To be honest, right now I think
there is no solution in sight. This is a valid reason to consider
stopping.

the reason why I take the em28xx as hostage is, well I started with it
and I work with that company and I don't see a way how to implement
the latest devices without terrible hacks (and there are around 60
devices supported only by the current available driver and it will
double that number since customers will change several chips on those
boards)

Due those "personal" conflicts I don't see how I can discuss it with
the linuxtv people who are against me, I even tried to discuss this
with Mauro (who never worked with a company in that area actually so
he doesn't seem to understand what I try to achive, at least I haven't
heard any technical reason why that work should be bad).

Without any help to take aside those personal issues I don't see how
this can be solved.
I pulled all my linux opensource projects offline till this is cleared
up I ...
[ message continues ]

Um, please ask next time when you want to quote from a private 
discussion.

To put it in perspective: I meant here that stopping the em28xx 
development using GPL is a consideration, not to take em28xx hostage. 
My first point in that same discussion was this:

"hverkuil: - It is pointless to worry about what others might do with 
your GPL code. Anyone can take it at any time and who knows, they might 
succeed. Then again, they might not. In any case, it shouldn't be a 
reason to consider stopping."

The only people you are hurting by taking em28xx offline are the 
end-users and yourself, I'm sorry to say.

Regards,



-

[ message continues ]

Yes, but continuing as before keeping it aside of everything also
hurts. I'm convinced that the roadmap which I aim at is fine there is
code which works and which is valueable for other projects.
What's the idea behind a forced separation? - One and the same code is
also used as it is in Windows drivers. If someone wants to commit his
free time in fixing or improving that work he's welcome to do so by
touching it once 3 targets are affected. The roadmap also includes OSX
which would be the 4th target.

What's the value of having those shareable components which have a
full implementation limited to linux which only supports a limited
subset of those features (and it requires a rewrite to get it fit into
the kernel, so those features will very likely get stripped off - this
is the current way how it's done)?

Markus
-

[ message continues ]

It is a bit naive for you to believe you can remove your GPL
distributed work from the internet by deleting it from your server.

If your kernel driver work would be merged into the kernel it
would retain your copyrights and Signed-off-by: attributions,
so it would be visible for everyone that it is your work. If
you can't live with that, then why on earth did you join a
project developing software released under the GPL? Why did
you release your own software under the GPL?

Since you seem obsessed with keeping control over your
work it is funny that you mention BSD, as the BSD license
is even less restrictive than the GPL.


Johannes
-

[ message continues ]

Well, I've talked to various people, and none of the main kernel people 
end up being at all interested in a kernel that has external dependencies 
on binary blobs for tuners.

So right now it seems like while I would personally want to have more 
vendors supprt their own drivers, if that in this case means that we'd 
have to have user-space and unmaintainable binaries to tune the cards, 
everybody seems to hate that idea. 

As such, the old and decrepit em28xx driver seems more useful to people, 
since at least it supports the limited set of hardware on its own.

		Linus
-

[ message continues ]

For me the reason is that some drivers in the kernel which that driver
depends on are broken now. Those drivers got broken by several people
who disagree with me.
My conclusion after providing patches to fix those things is that I
won't run after those people anymore. I'm not going to have further
discussions with those people about it since there are enough other
outstanding things to do with that driver. After 1 1/2 years I'm just

it does not since it's broken and feature limited. On the other side
it requires a firmware from userspace too so I don't think it matters
at all if the algorithm is done in kernelspace or userspace since it
depends on such a blob (and I cannot get the source for that firmware,
if someone's interested in that he has to disassemble the firmware).

Markus
-

[ message continues ]

I have a device which works perfectly with it if you add the vendor and
product ID to the list. I don't really call that broken. And it doesn't
need a firmware.

Please think that a lot of persons do not have enough knowledge to
compile out of tree drivers, and that a lot more do not even know about

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net
-

[ message continues ]

Aurelien,

the device you're using is around 2 years old. You're one of the lucky
ones, I have tonns of support mails in my mail account from people who
own almost a similar device but with different videodecoders which are
not fully supported in the kernel or which worked and got broken
during the time.
It took me around 4 hours to debug such an issue last years remotly
with an enduser (which includes that noone cared to ask me if I'm fine
with such an update, neither did someone ask people who own such
devices that they should test the changes).
Please also take other devices and upcoming devices into account,
since i'm willing to spend that time and since I'm in contact with

this is what all is about, the project does not depend on certain
broken drivers anymore. And people who initially disagreed without
having any solution nor contributed any code can continue to play
their game without having an impact on that driver anymore.

Markus
-

[ message continues ]

markus,

its the same old story you are telling over and over again.

of course there might be a huge community builded up the
last month @ mcentral,
of course your driver supports newer devices,

BUT

the same old story is - and you always miss that part

we discussed a lot on your changes and also ACCEPTED those
for merging, if you would have changed your UNNECCESSARY touching
of dvb-core. its proven that things could work without that
nacked change to dvb core. but, you decided to stop discussion then,
and went away to perform your own tree/userspace thing.

as linus and andrew stated within this thread they think they will not 
merge your code like it is cause of different reasons,
i am wondering a bit whats your next step is.

regards
marcel

ps. as linus tells from time to time
"It's not just black and white - there's also grey"

-

[ message continues ]

I didn't read a clean statement about it. If so I won't continue to
pull out opensource drivers from that company.
Marcel, you haven't been and you are not into that topic otherwise
you'd write about missing parts and address codeparts which I have
mentioned in the past which are not ok in the kernel and how to solve
that best.
I remember the mail [1] where you (and Michael) tried to point me to
something that doesn't work out. Please get into the whole topic which
includes studying the requirements and what parts I'm complaining
about.

Markus

(just for the record, although it's not relevant anymore)
http://threebit.net/mail-archive/video4linux/msg07548.html
-

[ message continues ]

saving my time instead of commenting your code does not mean i am not 
into it. as far as i remember i did say, that the api mixup within
dvb-core is NOT wanted and there are solutions for other devices,
that show it can be done otherwise. i must admit it would be a different
way but the only answer you said was "No, i wont do that"

please go back through the irc logs on linuxtv.org and find the 
as you may remember, i also offered you to ack a MERGE AS IS base for
your code in a private conversation on irc.

the main topics in there have been:
merge your stuff
wait for multiproto applied (as i still think it is a better solution)
rework your stuff to work with multiproto

your answer was afair "i will not allow anyone to modify my code after a 
merge"

that showed me, others did recognise meanwhile too, that you are NOT 
able to discuss different things or opinions for real, but you take
your proposals as the "one and only". this can not work, and will not
work.

i will leave this discussion again, as discussing with you mostly just 
leads into the old story of how stupid linuxtv devs are...

YOU LEFT linuxtv to build up your own - proceed further with that 
strategy _or_ come back to a level where you are open for different 
suggestions than yours.

HTH

-

[ message continues ]

I would like to see where I wrote that.
I remember that I stated out merge it as it is and modify it
afterwards because then you have to take care about the requirements
which are implemented and which some are not aware of. (There are also
heavy discussions about that ... think we shouldn't rediscuss it and
if someone wants to rediscuss it please put together a wikisite about

I am although I won't drop parts of my code in favour of someone who
has different ideas which are not even more complete or don't add some
extra value to it.

Markus
-

[ message continues ]

I agree I am lucky, but the fact is that the in-kernel driver supports
*some* devices, and *works* correctly for them. On the other side, your
driver supports more devices, but it is and *out-of-tree* driver.

Please either work to get your change merged, or stop complaining about
changes done to the in-kernel driver.

Moreover if you get a closer look at v4l-dvb git, you will see that the
changes proposed by Mauro are not em28xx specific, and is actually the
same change done on a lot of of v4l/dvb drivers.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net
-

[ message continues ]