> NO -- the tuner changes do not touch bttv -- they are all internal to
> the tuner code.
Good to know.
> If you have to remove some v4l1 support from tuner-core, that will
> simply be the removal of a few lines, and it can be easily done by hand.
>
> OTOH, If you push in the v4l1 removal first, and it conflicts with the
> pending tuner changes, that _will_ cause a problem. It will require for
> the entire patch series to be regenerated, and this will result in
> holding up Hans from moving forward with his work, until I have time to
> regenerate the entire series.
Let's see what'll happen at the merging stage. If you're saying that the
changes are all internal, conflicts shouldn't arrive.
You both should notice that bttv v4l1 tree touches on most i2c audio
drivers, converting driver APIs to V4L2. Currently, except for msp3400,
all other drivers support only V4L1 calls. A V4L2 userspace app won't be
able to properly configure audio on non-msp34xx bttv boards. This is the
main reason for doing this change.
> If you are going to push in the xc2028 stuff, the core changes should go
> in first, then you should alter your new patch as required. I do not
> expect this xc2028 driver to work with the devices that I have, and I
> believe that you are going to create a large confusion about firmware,
> not to mention that you do not have any legal rights to alter or
> distribute the firmware.
I'm not discussing firmwares. If this can't be solved on a clean way,
there's always the "dirty" way of having a script that extracts the
firmware from the windows driver. Several drivers, including the old
versions of ivtv and pvrusb2, as well as some newer ones, like opera1
uses this approach.
Yet, I really hope that we can have some official permission for
distributing Linux firmwares from all vendors.
> I wouldn't rush in the xc2028 stuff before the other changes.
If not committed, newer changes at tuner API will require more work, and
I don't want to spend my time re-basing it again.
The hybrid design phase 1 changes required me almost 6 hours to port the
driver, just to satisfy the newer API, without adding a single newer
functionality.
Converting it were nice, since I've discovered that there are several
bad things at the current hybrid design.
For example, I had to change several parameter exchanges at the driver
due to things like:
tuner_info("foo")
tuner_info internally depends of a var called "priv->i2c_propos". If you
don't have this declared, the compilation will fail.
So, it is required to add i2c_propos at the private structure, and to
rename the driver internal structure to "priv", even being a name that
doesn't mean anything inside a driver.
The tuner core required a hidden "priv" struct is really bad (*)
(*) Ok, the previous tuner_info call also had hidden parameters.
We should avoid this kind of design on newer code. We should, instead,
define tuner_info to be used like:
tuner_info(i2c_propos, "foo")
As the result of this kind of changes, I needed to add 6 newer fields to
my "priv" struct (in fact, struct xc2028_data), and rename it from the
nice "xc2028" name to the meaningless "priv", just to satisfy the newer
hybrid design.
Since there are more phases to happen, if the driver is not inserted on
core, it will mean that more rebase will be needed, for every newer
tuner redesign phase.
--
Cheers,
Mauro
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
