Andrew de Quincey wrote:
Felix Domke wrote:
Though I didn't test this, i strongly agree that we need this. I don't
think it should be user selectable, though (except for the "SIMPLE"
mode) - either the frontends supports a specific algorithm or not.
Otherwise i fear that user applications start to workaround frontend
driver bugs by selecting another algorithm...
What's the exact difference between HW and ADAPTIVE? Isn't "it's done in
hardware" the same as "it's done in the frontend driver", as far as the
API is concerned?
Some frontends support blindscanning, but require heavy software support
for this (Fujitsu mb86a15 for example). Such code is not really suitable
in the kernel (it sleeps, includes complicated algorithms etc.), so i
think the best would be to make it a userspace library with frontend
specific private ioctls, providing more or less direct register (or even
i2c) access. What do you think?
After a while, i would like to continue this discussion from where we
left off last time. In this regard i did some basic homework ( no code
yet )
but did come to the thoughts that a userspace library would be indeed
the solution. In such a case i was drawn to the conclusion that a
userspace i2c like extension which interfaces from the kernel to the
userspace in such a manner that it interfaces to the Host Bridge directly.
Why i would think that a generic i2c interface probably might not be the
solution is because almost all Host Bridges have General Purpose Input
Output (GPIO) for controlling some peripherals. for ex. frontends.
Under such a circumstance i made my ideas into block diagrams for easier
self explanation, without too many words.
But in any case i would like to make a small outline on the very same.
We could add just 2 IOCTL's to the existing API for making it compatible
with applications such that applications can choose between these two
and or switch between the interfaces.
Currently i came to a conclusion something like this.
http://www.thadathil.net/dvb/msg_transfer_interface/interface_desc.txt
There are other advantages more than what was discussed earlier on this
aspect than just tuning algorithms. Some of the advantages are
* we don't loose anything as all these communications that are exchanged
are low speed communications
* lesser bloat in kernel
* being in userspace, things can be easily debugged
* cards with lot of cross definitions can be easily implemented, without
the need of huge arrays in kernel
* the application can get a better control of the drivers (the frontend
thread could easily be in the application, rather being in the kernel)
But will need to keep the existing one as it is for compatibility reasons.
* userspace can handle math libraries compared to kernel.
* we can do tuning algorithms specific to frontends too.(such that we
can make use of the hardware features)
Yeah, I like this idea. If we keep on as we are, we're not really going to get
anywhere; it is becoming increasingly obvious that putting all the tuning
code in the kernel is hampering things a great deal. Many of the window
drivers I have examined have a similar architecture as well: raw device
access in kernel land, with the "interesting" stuff happening in userspace.
This way means we can support the old system so it provides minimum disruption
to existing users, but that we can also develop the more advanced stuff
required by others at the same time.
I also like the idea of an i2c-like communications (but not i2c itself). i2c
itself is a very neat idea well understood by many people, so it makes sense
to mimic it. Obviously we can't use the kernel i2c layer directly because we
don't want to impose a dependency like that, since not all DVB devices
support i2c.
I suppose there might be an argument that we should "emulate" an i2c host for
non-i2c based DVB cards - personally I don't like this since IMO it would be
overkill, but I thought I should mention it for completeness.
We could even do interesting things like have a python/perl interface to the
tuning system for rapid prototyping of tuning/frontend drivers - something
that sounds good to me.
Yeah sounds cool, i think we should go for the dip then..
Thanks,
Manu
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
