On some ATI-cards with the FGLRX driver, mythtv shows a blue, smurf-like image. Basically it switches the red and blue color channel. This is a known issue (see URL) and has a fix (see URL) This ebuild-patch and patch-file makes this hack into a USE-flag. Reproducible: Always Steps to Reproduce: 1. find and install an ATI Radeon X1650 (others seem to have the same problem) 2. install mythtv 3. watch whatever Actual Results: Strange colors, people look like smurfs Expected Results: good colors!
Created attachment 128164 [details, diff] patch to activate the fglrx-hack should be in portage/media-tv/mythtv/files
Created attachment 128166 [details] adapted mythtv-0.20.1_p13344 ebuild
Created attachment 128172 [details, diff] diff from the original ebuild to the adapted one
As per MythTV upstream policy, they won't suppose any Gentoo users if we apply patches that are not approved by them. As such, this patch would need to get at least mentioned in a MythTV ticket and referenced here, along with some sort of MythTV developer support. Additionally, it's typically frowned upon by Gentoo policy to have conditional patches based on USE flags, especially cryptic ones such as fglrxhack. How is a user other then you suppose to know when/how to enable that? No matter how descriptive the use.local.desc is. Furthermore, ATI cards are just plain not officially supported with MythTV and not even recommended to be used. Prior to building a MythTV box it's always recommended to browse their recommended hardware list. You will see ATI cards are not recommended, this is primarily because ATI themselves states that there are known issues with their cards and they are not supported on MythTV. http://support.ati.com/ics/support/default.asp?deptID=894&task=knowledge&questionID=26907 This is going to be something you're going to have to keep in your own personal overlay.
> As per MythTV upstream policy, they won't suppose any Gentoo users if we apply > patches that are not approved by them. As such, this patch would need to get at > least mentioned in a MythTV ticket and referenced here, along with some sort of > MythTV developer support. I DON'T agree on this. If look at my patch, you'll see that the only thing it does is to uncomment the "#define USE_ATI_PROPRIETARY_DRIVER_XVIDEO_HACK" line that is already in the official code. So this hardly qualifies as a "patch". I could just as well add a -D option to the compile-phase. > Additionally, it's typically frowned upon by Gentoo policy to have conditional > patches based on USE flags, especially cryptic ones such as fglrxhack. How is a > user other then you suppose to know when/how to enable that? No matter how > descriptive the use.local.desc is. Ok, you have a point there. Actually I just wanted to publish my modified ebuild so others could just use it without the need to write it themselves.
(In reply to comment #5) > > As per MythTV upstream policy, they won't suppose any Gentoo users if we apply > > patches that are not approved by them. As such, this patch would need to get at > > least mentioned in a MythTV ticket and referenced here, along with some sort of > > MythTV developer support. > I DON'T agree on this. If look at my patch, you'll see that the only thing it > does is to uncomment the "#define USE_ATI_PROPRIETARY_DRIVER_XVIDEO_HACK" line > that is already in the official code. So this hardly qualifies as a "patch". I > could just as well add a -D option to the compile-phase. > And it's still a hack that changes their shipping sources. They have been upset about one line changes before that did less then this hack, so I don't care what you agree or disagree with, the fact is that upstream does not want their sources modified without being told about it, and then they need to give it a nod of approval. Clearly they haven't given the hack the nod of approval for full time use because then it would always be enabled.
> > Additionally, it's typically frowned upon by Gentoo policy to have conditional > > patches based on USE flags, especially cryptic ones such as fglrxhack. How is a > > user other then you suppose to know when/how to enable that? No matter how > > descriptive the use.local.desc is. > Ok, you have a point there. Actually I just wanted to publish my modified > ebuild so others could just use it without the need to write it themselves. > Thanks, Niels. ++
(in reply to comment #6) > Clearly they haven't given the hack the nod of approval for full time use > because then it would always be enabled. No, because that would make every other card smurf-like but whatever; don't commit this patch to the portage tree, just leave it here for people to find
