Bugzilla Bug 220857

Similarities to this issue has indeed been up for discussion before but it does
seem like this one is new. 


I have a EPIA system with the VIA CLE266 chipset and while trying to compile
mythtv using the xvmc flag i get code that is unable to use the hardware
decompression. 

I noticed the following annoyances:
1) The firs time i compiled mythtv it linked against the via xvmc pro library
due to the fact that i have VIDEO_CARDS"via" but xorg pulls in openchrome
driver which is the one i use. MythTV enables the xvmc-vld feature but uses
the wrong library... 

The ebuild pulled eselect xvmc without forcing me to select anything and then
compiled mythtv. A "lsof | grep -i xvmc" during running mythfrontend and ldd
shows that myth is linked to via xvmc pro and not openchrome (I think it is
the pro thing that is the problem but i am unsure what the difference between
the openchromexvmc lib and the viaxvmc lib is). Therefore i tried recompiling
after using the eselect tool but this did not change things for me.

2) The ebuild pulls in eselect xvmc but compiles without xvmcw support thus
disabling the effect of the xvmcw. Is this a correct behaviour?

Sollution: (For me at least) 
I made a overlay of the ebuild and hard-coded the
configure flags to "--enable-xvmc --enable-xvmcw --xvmc-lib=openchrome" and
that made mythtv enable xvmc-vld and use the right lib.



Reproducible: Sometimes

Steps to Reproduce:
1. USE=xvmc VIDEO_CARDS=via emerge xorg
2. USE=xvmc VIDEO_CARDS=via emerge mythtv


Actual Results:  
mythtv linked agains via xvmc pro libs

Expected Results:  
myth linked against openchrome xvmc lib

(In reply to comment #0)
> Similarities to this issue has indeed been up for discussion before but it does
> seem like this one is new. 

Simply because upstream keeps changing around the code in their configure
script with regard to XvMC support. So we keep having to tweak the ebuild to
adjust between revisions.


> 
> The ebuild pulled eselect xvmc without forcing me to select anything 

Yes.. and? A lot of eselect modules work this way. The MythTV ebuild provides
instructions...

elog "Please set the proper XvMC provider with eselect xvmc"



> compiled mythtv. A "lsof | grep -i xvmc" during running mythfrontend and ldd
> shows that myth is linked to via xvmc pro and not openchrome (I think it is
> the pro thing that is the problem but i am unsure what the difference between
> the openchromexvmc lib and the viaxvmc lib is). Therefore i tried recompiling
> after using the eselect tool but this did not change things for me.
> 
> 2) The ebuild pulls in eselect xvmc but compiles without xvmcw support thus
> disabling the effect of the xvmcw. Is this a correct behaviour?

Per upstream, the proper options are...
    use xvmc && use video_cards_via && myconf="${myconf} --enable-xvmc \
        --enable-xvmc-pro --disable-xvmcw"

Which will disable xvmcw.


> 
> Sollution: (For me at least) 
> I made a overlay of the ebuild and hard-coded the
> configure flags to "--enable-xvmc --enable-xvmcw --xvmc-lib=openchrome" and
> that made mythtv enable xvmc-vld and use the right lib.


Not a solution for everyone because not everyone uses openchrome.

(In reply to comment #0)

> 
> Sollution: (For me at least) 
> I made a overlay of the ebuild and hard-coded the
> configure flags to "--enable-xvmc --enable-xvmcw --xvmc-lib=openchrome" and
> that made mythtv enable xvmc-vld and use the right lib.

Something about that seems wrong. libopenchrome.so does not seem like it would
be the XvMC provider. No other driver calls it that. Please provide an equery
files of the openchrome driver pkg.

(In reply to comment #1)
> > 
> > The ebuild pulled eselect xvmc without forcing me to select anything 
> 
> Yes.. and? A lot of eselect modules work this way. The MythTV ebuild provides
> instructions...
> 
> elog "Please set the proper XvMC provider with eselect xvmc"
> 

Does anything in that comment help anyone with anything? I saw the message and
that's why i tried recompiling after selecting a library. I don't think this
was the most important part of the bug description though. I tried to describe
what I did and not complain about the functionality so I'm sorry if i
redirected attention to the wrong place.

However, I still think it is confusing that "eselect xvmc" is a dependency when
it's obviously not needed since mythtv isn't linked to the wrapper library. I
tried studying the ebuild but I saw no combination of flags that would make
mythtv compile with xmvcw support. I'm no expert om ebuilds so I might be dead
wrong. I obviously don't need the wrapper library so I haven't tried getting it
to compile with xvmcw support using the provided ebuild. 

This is however not important for me. What was important was that my hardware
blurted out garbage when compiling with the setup that i used.

> > 
> > Sollution: (For me at least) 
> > I made a overlay of the ebuild and hard-coded the
> > configure flags to "--enable-xvmc --enable-xvmcw --xvmc-lib=openchrome" and
> > that made mythtv enable xvmc-vld and use the right lib.
> 
> 
> Not a solution for everyone because not everyone uses openchrome.
> 

I had an issue. I solved it myself and though that someone else might be happy
knowing. I provided build flags that worked for me to give everyone who is
reading this the possibility to figure out a solution that works for everyone.

Of course I know that hard-coding build flags for my specific case doesn't work
for everyone. I'm not an idiot you know...


I haven't been able to set any USE flags to fit my needs so I was expecting an
answer of the type: 

"Well, if you have that hardware and need those flags  you should have set USE
flag XXX to YYY" 

or something like:

"Ok, I guess there are more cases of hardware/software combinations than we are
allowing in this ebuild. Lets figure out a way of getting them all to work."

(In reply to comment #2)
> (In reply to comment #0)
> 
> > 
> > Sollution: (For me at least) 
> > I made a overlay of the ebuild and hard-coded the
> > configure flags to "--enable-xvmc --enable-xvmcw --xvmc-lib=openchrome" and
> > that made mythtv enable xvmc-vld and use the right lib.
> 
> Something about that seems wrong. libopenchrome.so does not seem like it would
> be the XvMC provider. No other driver calls it that. Please provide an equery
> files of the openchrome driver pkg.
> 

Ooops, my bad. I cutn pasted a from an outdated copy of my ebuild (After a
night of struggeling...) Sorry for the inconvenience.

The build-flags that i ended up using was:  "--enable-xvmc
--xvmc-lib=chromeXvMC" and my libchromeXvMC.so comes from the
x11-drivers/xf86-video-openchrome-0.2.901 ebuild. 

Again, sorry for the inconvenience.

Per, you are right.
All that needs to be done is to have the ebuild select '--enable-xvmcw
--disable-xvmc-vld' if the 'xvmc' USE flag is enabled.
The '--xvmc-lib' option is not needed at all in this case.

By enabling 'xvmcw', 'eselect-xvmc' can do it's work of handling the
configuration of /etc/X11/XvMCConfig, then at runtime the correct XvMC library
will be automatically loaded by MythTV.

This has the added bonus of being able to do away with the 'opengl-xvmc' and
'video_cards_via' USE flags and the ebuild hackery involved with trying to
support 4 different VIA XvMC libraries.

The above configure switches will also fix the problem of MythTV failing to
compile if any 'xvmc' USE flags are enabled when it tries to reference
functions in non-existent libraries (a la #222353), which will happen on
systems lacking the default 'xvmc-vld' libs.

Created an attachment (id=154347) [details]
mythtv-0.21_p1700.ebuild.diff

Created an attachment (id=154411) [details]
mythtv-0.21_p1700.ebuild.diff

Scratch previous diff, while it would work, it would check for the existence of
/etc/X11/XvMCConfig regardless of whether the 'xvmc' USE flag was enabled or
not.

New diff posted to rememdy :|

fixed in 0.21_p17435