[ATrpms-users] libmyth for fglrx

[Kevin J. Cummings]

Axel Thimm wrote:
> 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)

I did not know that.  Googling did not show this to me.  I found my
information by searching the ATI Linux forums (and eventually the
solution by searching the MythTV Wiki).

>>> 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.

Boo, hiss!  my dependencies are a mess right now.  I had to break them
by erasing some livna packages by using "rpm --erase --nodeps" so I coul
install the ATRpms versions! Why would someone put in explicit
dependencies to restrict ffmpeg to be < 2.5 if it wasn't needed?  Bad
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.

I figured as much.  I think that the Myth Devs would probably prefer it
if the video drivers got it right in the first place!  Which is why I
was asking here.

>> 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.

Which is why I chose to ask here first before blindly filing an RFE for
ATRpms.  I guess I will have to rebuild it myself every time until the
fglrx driver gets fixed.  B^(

>> 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 was assuming that just providing a 2nd package (say libmyth-fglrx) and
have the user rpm --erase libmyth (maybe with --nodeps) and install the
replacement by hand.  Perhaps even uninstall the mythtv-suite meta
package to prevent the old libmyth from being brought back in by
updates.  Maybe I haven't thought things through far enough.

> 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?

Do you have the MythTV ticket number for the one which resulted in this
flag being added?  I suppose I can go and try and search for it myself.

> If this gets into trunk ping me and I'll create new 0.21 packages for
> you to test. Is that a deal?

Sounds good to me.   Thanks Axel!

-- 
Kevin J. Cummings
kjchome at rcn.com
cummings at kjchome.homeip.net
cummings at kjc386.framingham.ma.us
Registered Linux User #1232 (http://counter.li.org)