1 |
Corey Richardson posted on Sun, 24 Apr 2011 21:03:06 -0400 as excerpted: |
2 |
|
3 |
> (I was directed to this mailing list from someone in #gentoo. Redirect |
4 |
> me if this is the wrong place. Thank you!) |
5 |
|
6 |
FWIW, this list seems as good as any. The topic is reasonably desktop |
7 |
related. The down side is that this is a relatively low-traffic list so |
8 |
you might not get anyone that can be of much help. The general user list |
9 |
is FAR higher traffic. You may or may not get better results there. |
10 |
|
11 |
> I'm trying to use pyglet, a python library for multimedia (commonly used |
12 |
> as a game library) using OpenGL. When running any sort of script |
13 |
> utilizing pyglet, the following happens: |
14 |
> |
15 |
> "failed to create drawable" is printed to the shell twice The window |
16 |
> pyglet opens is completely black, and hangs. To close the window I need |
17 |
> to kill the python process. |
18 |
> |
19 |
> I've chatted with the Pyglet devs and determined that the error is in |
20 |
> OpenGL and not pyglet. After googling around for this error, the only |
21 |
> other instance I saw was someone using nouveau that needed some sort of |
22 |
> driver upgrade. |
23 |
> |
24 |
> The output of glxinfo is attached, as well as the output from "eix |
25 |
> media-libs/mesa", the implementation of OpenGL on my system. |
26 |
> |
27 |
> I tried reemerging mesa with -gallium in the USE, which had the same |
28 |
> result as before except instead of a hang a Segmentation Fault was |
29 |
> generated. When I emerged mesa back with gallium, it emitted an |
30 |
> informational blurb that gallium only worked with i915 and another intel |
31 |
> card, among the intels (with some other vendor's cards, but they didn't |
32 |
> pertain to me). I am using an intel i915, and I believe my system is |
33 |
> properly configured for that card. I would love to see the output of |
34 |
> glxinfo from someone who has a working OpenGL for the i915. |
35 |
> |
36 |
> A simple test case (if you would like to test on your own system) is: |
37 |
> |
38 |
> python -c "import pyglet as p;w=p.window.Window();p.app.run();" |
39 |
> |
40 |
> This requires dev-python/pyglet to be emerged. It's a small library and |
41 |
> is pure-python, so it should only take ~30 seconds. |
42 |
|
43 |
Eh... not so here. The library itself might only take that, but portage |
44 |
says I have USE flag conflicts, which will certainly require > 30s to |
45 |
resolve. |
46 |
|
47 |
As most desktop users I expect, I have USE=alsa set. That's a pyglet USE |
48 |
flag that according to the portage error, triggers a dependency on alsa- |
49 |
lib with USE=alisp. USE=alisp is certainly going to be rather less |
50 |
commonly enabled, either in general or for alsa-libs itself, and it's not |
51 |
enabled here, thus thus the conflict. |
52 |
|
53 |
Of course, I might be able to set that, but I haven't checked, perhaps |
54 |
that'll cascade into another dependency. |
55 |
|
56 |
The point is, for most users, it's going to be a rather larger job than |
57 |
the 30-second trivial emerge you suggested it might be. I might still do |
58 |
it, tho; haven't decided yet. |
59 |
|
60 |
> I am using AwesomeWM, if that is of consequence. |
61 |
|
62 |
It shouldn't be in and of itself. Only if you are using a WM that uses |
63 |
OpenGL for various effects (as does, say kwin, I'm a kde guy), and you |
64 |
have those and thus the OpenGL requirment enabled, might it be |
65 |
interesting, and I'm not familiar with AwesomeWM so don't know if that |
66 |
applies or not. |
67 |
|
68 |
> So, how can I further debug this error, and hopefully fix it? Request |
69 |
> more information if you need it. Thank you for your time |
70 |
|
71 |
> OpenGL vendor string: Mesa Project |
72 |
> OpenGL renderer string: Software Rasterizer |
73 |
|
74 |
This is highly suspect. I'm running a Radeon here, with the native |
75 |
kernel/mesa/X freedomware drivers not the proprietary stuff, but I've seen |
76 |
others point to this bit of glxinfo output to see if the system's properly |
77 |
running hardware OpenGL or is relying on Mesa's software renderer only, as |
78 |
well, so I believe it's a reliable indicator, regardless of hardware. |
79 |
|
80 |
Here's what my Radeon system (with hardware OpenGL active) says, for |
81 |
comparison: |
82 |
|
83 |
OpenGL vendor string: Advanced Micro Devices, Inc. |
84 |
OpenGL renderer string: Mesa DRI R600 (RV730 9495) 20090101 TCL DRI2 |
85 |
|
86 |
Those should specify the hardware maker (Intel in your case) and possibly |
87 |
driver specific hardware and driver details. (Here, it's using the r600 |
88 |
sub-driver from the radeon driver, that subdriver supports the r6xx/r7xx |
89 |
class chips, including the rv730 chip that's in my hardware, a Radeon |
90 |
hd4650 based card. The Intel driver may report different details, but it |
91 |
should definitely **NOT** say "Software Rasterizer", which indicates that |
92 |
it's falling back to the mesa in-CPU software emulation code.) |
93 |
|
94 |
*BUT*, that's with the "classic" driver (tho in kms mode). The gallium |
95 |
driver for the r6xx/r7xx class radeons isn't as mature as for the earlier |
96 |
r3xx-r5xx class radeons and intel hardware, and I've not experimented much |
97 |
with it and know relatively little about it at this point. Gallium's on |
98 |
my list to investigate further, but meanwhile, it's /possible/ (not likely |
99 |
as it'd cause confusion, but possible) that the gallium glxinfo results |
100 |
print software rasterizer here as well. When I get a chance to screw with |
101 |
it some more I guess I'll know for sure, but meanwhile, I *SUSPECT* that |
102 |
your posted strings indicate mesa fallback emulation rendering, NOT real |
103 |
hardware OpenGL. |
104 |
|
105 |
If that's the case as I suspect, I believe we have your problem. Many |
106 |
OpenGL apps simply refuse to run with only the mesa software fallback, or, |
107 |
in your case, appear to run, but simply black-background. |
108 |
|
109 |
Back to the glxinfo output. Note that *other* bits of the output, like |
110 |
the OpenGL version string just below the above, still correspond to the |
111 |
mesa version. Again, here's mine, next mesa version but very similar to |
112 |
yours, and can't be used to see whether hardware or software OpenGL is |
113 |
enabled: |
114 |
|
115 |
OpenGL version string: 2.1 Mesa 7.10.2 |
116 |
|
117 |
My netbook has Intel graphics, but I'm not as familiar with them as I am |
118 |
the Radeons and am a bit fuzzy on which model it is (gma450, i915, i945, I |
119 |
think I've seen all three numbers in different places but don't know how |
120 |
they relate to each other), except that it's from the pre-poulsbo era. |
121 |
I'll try to post its output as a followup, since that'll be at least |
122 |
somewhat more directly comparable to what yours should be. |
123 |
|
124 |
> [I] media-libs/mesa |
125 |
> Installed versions: 7.10.1(11:58:19 PM 04/23/2011)(classic gallium |
126 |
> nptl video_cards_intel -debug -gles -hardened -kernel_FreeBSD -llvm |
127 |
> -motif -pic -selinux -video_cards_mach64 -video_cards_mga |
128 |
> -video_cards_nouveau -video_cards_r128 -video_cards_radeon(tho I |
129 |
don't believe likely due to the confusion it'd create because of the |
130 |
previous use of those lines to check for it |
131 |
> -video_cards_savage -video_cards_sis -video_cards_tdfx |
132 |
> -video_cards_via -video_cards_vmware) |
133 |
|
134 |
|
135 |
OK, looks like you have intel hardware configured here. And you have |
136 |
classic and gallium USE flags enabled too. Good. |
137 |
|
138 |
One thing I don't see you mention, is switching between the classic and |
139 |
gallium OpenGL implementations. Again, I've not played with gallium much, |
140 |
and it may be that this doesn't apply to intel at all, but at least for |
141 |
radeons, eselect mesa is used to list and switch between the classic and |
142 |
gallium drivers. You mention trying with gallium, but not specifically |
143 |
switching to the classic drivers and trying that. Perhaps that's why you |
144 |
got the segfault with mesa emerged -gallium, as if you hadn't eselect mesa |
145 |
switched to the classic drivers, it could have tried to load libraries |
146 |
that didn't exist in that case, thus triggering a segfault. |
147 |
|
148 |
Maybe gallium's not working correctly on your hardware (at least with your |
149 |
current software, kernel/xorg-server/mesa/ddx versions, ddx refers to the |
150 |
x-driver, xf86-video-intel in your case) and you need to switch to the |
151 |
classic implementation? |
152 |
|
153 |
I'll do a followup with the netbook's glxinfo if I remember, but the above |
154 |
should give you some pointers to investigate, meanwhile. |
155 |
|
156 |
-- |
157 |
Duncan - List replies preferred. No HTML msgs. |
158 |
"Every nonfree program has a lord, a master -- |
159 |
and if you use the program, he is your master." Richard Stallman |