GNOME Bugzilla – Bug 754256
info: support getting renderer string from EGL/GLESv2
Last modified: 2016-04-09 04:10:20 UTC
See attached patch.
Created attachment 310214 [details] [review] info: support getting renderer string from EGL/GLESv2 Split out the routine to fetch the GLX renderer string into a helper program and add another one for EGL/GLESv2. We will still prefer the GLX version, but when it returns a bad string (like "Software Rasterizer"), we use the EGL one. This will produce good results on e.g. ARM Mali platforms.
Couldn't we reuse the gnome-session-is-accelerated helper from bug 686806 for that, instead of having 2 of those helpers?
The gnome-session-is-accelerated helper also doesn't know about EGL/GLES at all right now, and I was planning to add support for it there. How did you imagine that helper being used here? Maybe with the addition of a --print-renderer command line option? In any case, while I'm not in a rush to get this patch in, I don't know how much time I will be able to spend on the gnome-session work in the coming week, so perhaps we could do that as an additional step.
(In reply to Cosimo Cecchi from comment #3) > The gnome-session-is-accelerated helper also doesn't know about EGL/GLES at > all right now, That's what's in the other bug. > and I was planning to add support for it there. > How did you imagine that helper being used here? Maybe with the addition of > a --print-renderer command line option? Something like that, yes. > In any case, while I'm not in a rush to get this patch in, I don't know how > much time I will be able to spend on the gnome-session work in the coming > week, so perhaps we could do that as an additional step. Given that you can't even get in a EGL/GLES session right now (due to the missing support in gnome-session), is it worth breaking freezes for this?
(In reply to Bastien Nocera from comment #4) > (In reply to Cosimo Cecchi from comment #3) > > The gnome-session-is-accelerated helper also doesn't know about EGL/GLES at > > all right now, > > That's what's in the other bug. OK - which bug are you referring to here? > > and I was planning to add support for it there. > > How did you imagine that helper being used here? Maybe with the addition of > > a --print-renderer command line option? > > Something like that, yes. > > > In any case, while I'm not in a rush to get this patch in, I don't know how > > much time I will be able to spend on the gnome-session work in the coming > > week, so perhaps we could do that as an additional step. > > Given that you can't even get in a EGL/GLES session right now (due to the > missing support in gnome-session), is it worth breaking freezes for this? Cool; not at all worth breaking freezes for this, and I'll try to find some time to work on the gnome-session integration.
(In reply to Cosimo Cecchi from comment #5) > (In reply to Bastien Nocera from comment #4) > > (In reply to Cosimo Cecchi from comment #3) > > > The gnome-session-is-accelerated helper also doesn't know about EGL/GLES at > > > all right now, > > > > That's what's in the other bug. > > OK - which bug are you referring to here? bug 686806, mentioned in comment 2.
Created attachment 325620 [details] [review] info: remove unused code
Created attachment 325621 [details] [review] info: remove unused defines
Created attachment 325622 [details] [review] info: fetch renderer information from gnome-session Now that it's exported over DBus.
Review of attachment 325620 [details] [review]: Yeah.
Review of attachment 325621 [details] [review]: You can probably squash this in to the previous one.
Review of attachment 325622 [details] [review]: Looks good.
Attachment 325620 [details] pushed as 60e7c35 - info: remove unused code Attachment 325622 [details] pushed as 13beb5d - info: fetch renderer information from gnome-session Squashed and pushed to master