[gentoo-desktop] Re: OpenGL Issue -- "failed to create drawable" (pyglet, python)

[Duncan]

Corey Richardson posted on Sun, 24 Apr 2011 21:03:06 -0400 as excerpted:

> (I was directed to this mailing list from someone in #gentoo. Redirect
> me if this is the wrong place. Thank you!)

FWIW, this list seems as good as any.  The topic is reasonably desktop 
related.  The down side is that this is a relatively low-traffic list so 
you might not get anyone that can be of much help.  The general user list 
is FAR higher traffic.  You may or may not get better results there.

> I'm trying to use pyglet, a python library for multimedia (commonly used
> as a game library) using OpenGL. When running any sort of script
> utilizing pyglet, the following happens:
>
> "failed to create drawable" is printed to the shell twice The window
> pyglet opens is completely black, and hangs. To close the window I need
> to kill the python process.
>
> I've chatted with the Pyglet devs and determined that the error is in
> OpenGL and not pyglet. After googling around for this error, the only
> other instance I saw was someone using nouveau that needed some sort of
> driver upgrade.
>
> The output of glxinfo is attached, as well as the output from "eix
> media-libs/mesa", the implementation of OpenGL on my system.
>
> I tried reemerging mesa with -gallium in the USE, which had the same
> result as before except instead of a hang a Segmentation Fault was
> generated. When I emerged mesa back with gallium, it emitted an
> informational blurb that gallium only worked with i915 and another intel
> card, among the intels (with some other vendor's cards, but they didn't
> pertain to me). I am using an intel i915, and I believe my system is
> properly configured for that card. I would love to see the output of
> glxinfo from someone who has a working OpenGL for the i915.
>
> A simple test case (if you would like to test on your own system) is:
>
> python -c "import pyglet as p;w=p.window.Window();p.app.run();"
>
> This requires dev-python/pyglet to be emerged. It's a small library and
> is pure-python, so it should only take ~30 seconds.

Eh... not so here.  The library itself might only take that, but portage 
says I have USE flag conflicts, which will certainly require > 30s to 
resolve.  

As most desktop users I expect, I have USE=alsa set.  That's a pyglet USE 
flag that according to the portage error, triggers a dependency on alsa-
lib with USE=alisp.  USE=alisp is certainly going to be rather less 
commonly enabled, either in general or for alsa-libs itself, and it's not 
enabled here, thus thus the conflict.

Of course, I might be able to set that, but I haven't checked, perhaps 
that'll cascade into another dependency.

The point is, for most users, it's going to be a rather larger job than 
the 30-second trivial emerge you suggested it might be.  I might still do 
it, tho; haven't decided yet.

> I am using AwesomeWM, if that is of consequence.

It shouldn't be in and of itself.  Only if you are using a WM that uses 
OpenGL for various effects (as does, say kwin, I'm a kde guy), and you 
have those and thus the OpenGL requirment enabled, might it be 
interesting, and I'm not familiar with AwesomeWM so don't know if that 
applies or not.

> So, how can I further debug this error, and hopefully fix it? Request
> more information if you need it. Thank you for your time

> OpenGL vendor string: Mesa Project
> OpenGL renderer string: Software Rasterizer

This is highly suspect.  I'm running a Radeon here, with the native 
kernel/mesa/X freedomware drivers not the proprietary stuff, but I've seen 
others point to this bit of glxinfo output to see if the system's properly 
running hardware OpenGL or is relying on Mesa's software renderer only, as 
well, so I believe it's a reliable indicator, regardless of hardware.

Here's what my Radeon system (with hardware OpenGL active) says, for 
comparison:

OpenGL vendor string: Advanced Micro Devices, Inc.
OpenGL renderer string: Mesa DRI R600 (RV730 9495) 20090101  TCL DRI2

Those should specify the hardware maker (Intel in your case) and possibly 
driver specific hardware and driver details. (Here, it's using the r600 
sub-driver from the radeon driver, that subdriver supports the r6xx/r7xx 
class chips, including the rv730 chip that's in my hardware, a Radeon 
hd4650 based card.  The Intel driver may report different details, but it 
should definitely **NOT** say "Software Rasterizer", which indicates that 
it's falling back to the mesa in-CPU software emulation code.)

*BUT*, that's with the "classic" driver (tho in kms mode).  The gallium 
driver for the r6xx/r7xx class radeons isn't as mature as for the earlier 
r3xx-r5xx class radeons and intel hardware, and I've not experimented much 
with it and know relatively little about it at this point.  Gallium's on 
my list to investigate further, but meanwhile, it's /possible/ (not likely 
as it'd cause confusion, but possible) that the gallium glxinfo results 
print software rasterizer here as well.  When I get a chance to screw with 
it some more I guess I'll know for sure, but meanwhile, I *SUSPECT* that 
your posted strings indicate mesa fallback emulation rendering, NOT real 
hardware OpenGL.

If that's the case as I suspect, I believe we have your problem.  Many 
OpenGL apps simply refuse to run with only the mesa software fallback, or, 
in your case, appear to run, but simply black-background.

Back to the glxinfo output.  Note that *other* bits of the output, like 
the OpenGL version string just below the above, still correspond to the 
mesa version.  Again, here's mine, next mesa version but very similar to 
yours, and can't be used to see whether hardware or software OpenGL is 
enabled:

OpenGL version string: 2.1 Mesa 7.10.2

My netbook has Intel graphics, but I'm not as familiar with them as I am 
the Radeons and am a bit fuzzy on which model it is (gma450, i915, i945, I 
think I've seen all three numbers in different places but don't know how 
they relate to each other), except that it's from the pre-poulsbo era.  
I'll try to post its output as a followup, since that'll be at least 
somewhat more directly comparable to what yours should be.

> [I] media-libs/mesa
>      Installed versions:  7.10.1(11:58:19 PM 04/23/2011)(classic gallium
>      nptl video_cards_intel -debug -gles -hardened -kernel_FreeBSD -llvm
>      -motif -pic -selinux -video_cards_mach64 -video_cards_mga
>      -video_cards_nouveau -video_cards_r128 -video_cards_radeon(tho I
don't believe likely due to the confusion it'd create because of the 
previous use of those lines to check for it
>      -video_cards_savage -video_cards_sis -video_cards_tdfx
>      -video_cards_via -video_cards_vmware)


OK, looks like you have intel hardware configured here.  And you have 
classic and gallium USE flags enabled too.  Good.

One thing I don't see you mention, is switching between the classic and 
gallium OpenGL implementations.  Again, I've not played with gallium much, 
and it may be that this doesn't apply to intel at all, but at least for 
radeons, eselect mesa is used to list and switch between the classic and 
gallium drivers.  You mention trying with gallium, but not specifically 
switching to the classic drivers and trying that.  Perhaps that's why you 
got the segfault with mesa emerged -gallium, as if you hadn't eselect mesa 
switched to the classic drivers, it could have tried to load libraries 
that didn't exist in that case, thus triggering a segfault.

Maybe gallium's not working correctly on your hardware (at least with your 
current software, kernel/xorg-server/mesa/ddx versions, ddx refers to the 
x-driver, xf86-video-intel in your case) and you need to switch to the 
classic implementation?

I'll do a followup with the netbook's glxinfo if I remember, but the above 
should give you some pointers to investigate, meanwhile.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman