[ATrpms-users] libmyth for fglrx

[Axel Thimm]

On Sun, Jun 24, 2007 at 11:29:39PM -0400, Kevin J. Cummings wrote:
> ATI has stated publicly that they don't support MythTV in their
> fglrx X11 driver.  [the reason being is that it hasn't worked for a
> while now and they feel no compelling reason to fix it anytime
> soon.]

That's not really nice by ATI. But it also affects other chipsets:

// define the following for the ATI Proprietary driver and the Intel
// IEGD driver for the i830M chipset (as of Oct 1st, 2006). Please
// report the problem to the driver developers as well, the more
// people report the bug in the driver the more likely it is to be
// fixed.
//#define USE_HACK_FOR_BROKEN_I420_SUPPORT_IN_DRIVER

(note that the switch has been renamed)

> > Until at least fglrx-8.33.6 there are wrong colors with xv
> > playback, E.g. faces look blue. In libs/libmythtv/videoout_xv.cpp
> > you can uncomment
> > 
> > #define USE_ATI_PROPRIETARY_DRIVER_XVIDEO_HACK

> (OK, long story short, I had to break a large number of dependencies
> from livna, which were shipped with my laptop, in order to provide
> the proper required RPMs to build this src.rpm.  Most notably,
> ffmpeg 2.5 seems to be incompatible with other software which
> requires version < 2.5!).

I think that's a myth, nothing seems to need < 2.5. This bug has
caused lots of grief between livna and the other repos supplying
similar packaging.

> So, my question:  Can either a seperate libmyth RPM be provided for
> systems running fglrx?  Or better yet, is there a way to turn this
> compile time check into a runtime check so that 2 versions of this RPM
> don't have to co-exist????  The define only seems to control the
> following code snippet:
> 
> #ifdef USE_ATI_PROPRIETARY_DRIVER_XVIDEO_HACK
>     swap(ids[0], ids[2]);
> #endif // USE_ATI_PROPRIETARY_DRIVER_XVIDEO_HACK

A runtime check would be best, of course, but that's a request to make
to the mythtv developers.

> MythTV seems to have worked around the problem by providing the "hack"
> fix.  Would it be better to have 2 RPMs (one for the broken ATI fglrx
> and the curent on fo everyone else?)

Providing alternative rpms is always difficult. How will smart/yum/apt
know which one to use? Both "libnormal" and "libmodified" will have to
provide the same sonames and are both candidates to fullfil any such
request from the depsolver.

Next is how will these two (libnormal vs lib) relate to each other?
How can an upgrade not swap one for the other? They can't coexist, so
they will have to carry "Conflicts:" or "Obsoletes:". The modified one
would have to "Provides:" the name of the unmodified one, which
triggers a bug in rpm (soome call it a feature) that automatically
obsoletes the provided resource. So it's quite a mess. :(

The only way out would be to strip the modified package from it's
virtual provides, shove it at a place the linker never looks in and
have a runtime ld.so.conf* switching to activate it. But this starts
to get out of hands and adding a GUI button upstream sounds like an
easier task.

> If someone wants me to, I'd be happy to file an RFE for this.

I would try to do so at the upstream level. ATM I don't see any sane
packaging method that won't be killing off the other camp and vice
versa.

I checked mythtv's tickets and no one ever requested to make the static
USE_* flagg to a runtime flag. Actually in the tickets it is only
mentioned once only, and in a different context, so most probably the
flag hasn't become runtime yet due to lack of demand?

If this gets into trunk ping me and I'll create new 0.21 packages for
you to test. Is that a deal?
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.atrpms.net/pipermail/atrpms-users/attachments/20070625/f0b9781c/attachment.bin