[mythtv-users] to Beirdo re ticket #10336

Yianni Vidalis yiannividalis at hotmail.com
Tue Feb 21 08:19:32 UTC 2012



> Date: Mon, 20 Feb 2012 17:29:27 -0500
> From: mtdean at thirdcontact.com
> To: mythtv-users at mythtv.org
> Subject: Re: [mythtv-users] to Beirdo re ticket #10336
> 
> Note that OpenGL ES is "OpenGL for Embedded Systems" ( 
> http://en.wikipedia.org/wiki/OpenGL_ES ). It is, for all practical 
> purposes, a cut-down version of OpenGL that, basically, only supports 
> pixel shaders, and is meant for use on embedded systems, such as cell 
> phones and handheld gaming systems.
> 
> Mesa provides support for OpenGL ES. It is only available when Mesa is 
> compiled with the configure arguments "--enable-gles-overlay" or 
> "--enable-gles1 --enable-gles2" (see http://www.mesa3d.org/opengles.html 
> ). This means that someone (packager? you?) made a decision to force 
> Mesa to include OpenGL ES (embedded systems) support on your desktop 
> (non-embedded) build of Mesa. (Perhaps that someone was someone who had 
> no idea what OpenGL ES was and said, "Oh, I better include that in case 
> someone wants it!" This is the type of thing that happens, often, on 
> certain distros that let the user decide how to configure the packages 
> on their systems, because doing so is often letting the person least 
> qualified to know what they need choose what they get.) Note, also, 
> that Mesa's OpenGL ES implementation is dependent on Gallium ( 
> http://wiki.freedesktop.org/wiki/Software/gallium ) and/or EGL ( 
> http://en.wikipedia.org/wiki/EGL_%28OpenGL%29 and 
> http://www.mesa3d.org/egl.html ), both middle-men that may be getting in 
> the way of MythTV's attempt to use OpenGL.


Ok, that user was not me!

Every package on my systems is installed from rpm, only mythtv is of development

version that requires compiling. So, opengles has arrived from the official opensuse

 repository. Apparently, opengles was included on May 16, 2011

 http://rpmfind.net/linux/RPM/opensuse/12.1/x86_64/Mesa-7.11-11.1.2.x86_64.html 

 

I will try to find the respective source package to recompile and see how it goes.

I'll email the packager, too.

 

Last July I had come across the same - probably worse - problem when I was trying 

to solve something different:

 

 http://www.gossamer-threads.com/lists/mythtv/users/486263#486263 

 

The last post is mine.At that time I had switched to the Factory repo, which

broke opengl. What I didn't realise was that being factory at the time,

I would eventually find it in front of me on the next distro upgrade....

 

 

 

 

> 
> Note, also, that Qt gets compiled against *one* OpenGL implementation 
> (or none). If you've compiled Qt to use OpenGL ES (by compiling Qt with 
> configure argument "--opengl es" or "--opengl" (or without specifying 
> "--opengl" at all) where Qt decides that ES is the best implementation 
> of Qt you have available), then you'd be using the Mesa implementation 
> of OpenGL ES. This may factor into your statement, "I know it's my OS 
> that's to blame, but no matter what, so far only MythTV is affected" ( 
> http://www.gossamer-threads.com/lists/mythtv/users/505072#505072 ) in 
> such a way that MythTV may be the only application that's affected 
> because MythTV is the only Qt-based application with which you're using 
> OpenGL, but it's still not a MythTV bug.
> 
> Furthermore, when your X server is compiled, it is compiled with support 
> for a certain type of acceleration. This may be GLX-based acceleration 
> (traditional acceleration support--and, likely, what most people using 
> MythTV have, see http://en.wikipedia.org/wiki/GLX). Or, it could be 
> EGL-based acceleration. As a matter of fact, you may not even be using 
> X. Your distro may be using Wayland, instead, where Wayland is a "throw 
> the baby out with the bathwater" approach to fixing some issues with X. 
> (Though NVIDIA's drivers don't support Wayland, so you're likely not 


My distro is using xorg-x11 ver. 7.6. No mention of Wayland.

 

 

 

> Note, also, that Qt 4.8 seems to handle OpenGL very differently from Qt 
> 4.7 and below--to the point that it looks like 4.8 uses OpenGL even when 
> we tell it not to. Qt 4.8 also has support for Wayland


Does this mean I should try to upgrade to 4.8 or that I should stay as far

away from it if I come across it?

 

 

> What we do know:
> 
> Since #10336 was fixed--and MythTV no longer attempts to compile support 
> for OpenGL ES if Qt doesn't support OpenGL ES--your Qt is almost 
> definitely not compiled to use OpenGL ES (and MythTV isn't trying to use 
> OpenGL ES). We can (and need to) find out some information on what your 
> Qt /is/ compiled to use with:
> pkg-config --variable=qt_config QtOpenGL


On the affected pc, the command gives:

lex yacc warn_on uic resources qt warn_on release incremental link_prl 

def_files_disabled exceptions no_mocdepend release stl qt_no_framework 

system-sqlite release shared dll largefile stl mmx 3dnow sse sse2 sse3

 ssse3 sse4_1 sse4_2 avx dylib create_prl link_prl depend_includepath 

QTDIR_build nostrip qt_install_headers qt warn_on depend_includepath 

qmake_cache target_qt hide_symbols bsymbolic_functions create_libtool 

create_pc explicitlib x11 opengl x11lib x11inc moc thread shared dll


Which is identical to the output of a 11.4 opensuse (not affected):

lex yacc warn_on uic resources qt warn_on release incremental link_prl

 def_files_disabled exceptions no_mocdepend release stl qt_no_framework

 system-sqlite release shared dll largefile stl mmx 3dnow sse sse2 sse3

 ssse3 sse4_1 sse4_2 avx dylib create_prl link_prl depend_includepath 

QTDIR_build nostrip qt_install_headers qt warn_on depend_includepath 

qmake_cache target_qt hide_symbols bsymbolic_functions create_libtool 

create_pc explicitlib x11 opengl x11lib x11inc moc thread shared dll

 

> 
> For some reason, Qt's OpegGL classes are unable to retrieve 
> Vendor/Renderer/Version information from your OpenGL implementation. It 
> seems like--though here I'm just guessing since you're not providing 
> mythfrontend log output from all the tests you're doing, so I'm relying 
> on old logs from when your system was incorrectly trying to use OpenGL 
> as well as pennguin's logs (though he's on Arch)--your OpenGL 
> implementation also reports that it doesn't support certain extensions 
> that we rely on (things like, "OpenGL: Multi-texturing not supported. 
> Certain OpenGL features will not work" and "OpenGL: GL_EXT_vertex_array 
> extension not supported. This may not work"). However, for some reason, 
> the OpenGL implementation is reporting that it is using direct rendering 
> (meaning that it's using hardware acceleration), though the capabilities 
> it reports look more limited than even 10-yr old GPUs.
> 
> openSUSE 12.1 seems to break OpenGL use in MythTV; whereas, the previous 
> version of openSUSE worked. This implies that something was changed in 
> openSUSE 12.1. Also, some unknown version of ArchLinux seems to break 
> OpenGL use in MythTV.

 

Searching in archlinux 

http://www.archlinux.org/packages/?sort=&arch=x86_64&repo=Multilib&q=mesa&maintainer=&last_update=&flagged=&limit=50

 

I found that it uses Mesa 7.11.2-3 (mine is 7.11-11.1.2).

There are GLES libraries present, too.

 

 

 

 This implies that you and pennguin may be able to 
> discuss commonalities and differences to try to narrow down the issue. 
I don't have his email, and apparently he doesn't read the lists - at least 

he didn't answer the posts I made to try and stop in vain the devs (see: Beirdo) 

from locking the ticket ;)

 

> I happen to know that LinHES ( 
> https://wiki.archlinux.org/index.php/LinHES ) is based around 
> ArchLinux. That means you and/or pennguin could try to talk with the 
> LinHES developers/packagers to try to see what they may be doing 
> differently--or, even, if they may have noticed the same problem and 
> haven't found a fix for it, yet. They may also be more knowledgeable 
> about the underpinnings of ArchLinux and what may have changed, 
> recently, in Arch to break MythTV's use of OpenGL.

 

I'll try and experiment with my setup, and see how it goes from there.

 

I wonder how the official packages of 0.24.2-2.1 (available from packman

http://packman.links2linux.org/package/mythtv-0_24/281340) are 

compiled for 12.1 and if they excibit any problem...

 

 


> 
> So, basically, at this point it looks like someone configured the system 
> (that someone being packagers or whoever is choosing how to compile and 
> integrate things--which may not be packagers on some distros) 
> incorrectly such that the various parts don't work together properly. 
> We need to find out what's broken so we can find out what needs 
> fixing--and where. I need you to do as much as possible to figure out 
> what's broken, since it's your system and you can see how it's working, 
> ask for information on openSUSE forums/lists/etc, test various changes, 
> and so on. And, the hours it took me to go through all the various 
> threads and get the various references, search the Internet, and figure 
> some of what we do and what we don't know has pretty much taken up all 
> the time I have available for working on MythTV, today, which means I 
> won't be able to fix any of the other bugs that have been well defined, 
> that I know how to fix, and that need to be fixed before release.

 

I appreciate it and I apologise.


> 
> Or, put another way, you probably know as much as--or more than--I do 
> about what might be broken: I really don't know what's going on, 
> either. If the above makes it seem otherwise, that's only because many 
> hours of Google and Bing searches (today and before) gave me some things 
> to mention in this email.
> 
> Mike

 

 

Thanks,

 

Yianni. 		 	   		  


More information about the mythtv-users mailing list