[mythtv-users] to Beirdo re ticket #10336

Michael T. Dean mtdean at thirdcontact.com
Mon Feb 20 22:29:27 UTC 2012


Fixed as much of the broken formatting as I could...  You should 
probably configure your mail client to send text-only messages to this 
list since it's sending multipart messages with HTML that's formatted 
such that it's not useful in replies and completely broken plain text 
"conversions" of the message you're composing that just run everything 
together.  
http://www.gossamer-threads.com/lists/mythtv/users/505077#505077 and 
http://www.gossamer-threads.com/lists/mythtv/users/505079#505079 , for 
example...

On 02/20/2012 05:52 AM, Yianni Vidalis wrote:
>   >  Date: Mon, 20 Feb 2012 02:01:37 -0800
>> From: gjhurlbu
>>>          libGLESv2.so.2 =>  /usr/lib64/libGLESv2.so.2 (0x00007fd9fadf7000)
>> First: why do you have OpenGL ES installed?
> rpm -qf /usr/lib64/libGLESv2.so.2
> reports it's included in Mesa-7.11-11.1.2.x86_64, which is from the main (OSS) repo of opensuse 12.1

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.

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 
using it.)

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

All the above tells you just some of the variables involved and what we 
don't know.  In other words, there are so many possible things that are 
broken that until we find out what, specifically, is happening, there's 
nothing we can do.  So, at this point, we need to (need you to) 
investigate how your system is working, what's being used by what (how 
is the X server configured/compiled, how is Mesa configured/compiled, 
are you using middle men (such as Gallium or EGL), are you using 
compositing window managers that

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

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.  This implies that you and pennguin may be able to 
discuss commonalities and differences to try to narrow down the issue.  
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.

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.

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


More information about the mythtv-users mailing list