After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 756914 - Details screen just show 'Wayland' for graphics
Details screen just show 'Wayland' for graphics
Status: RESOLVED FIXED
Product: gnome-session
Classification: Core
Component: gnome-session
git master
Other Linux
: Normal normal
: ---
Assigned To: Session Maintainers
Session Maintainers
: 758016 (view as bug list)
Depends on:
Blocks: 773213 773216
 
 
Reported: 2015-10-21 13:49 UTC by Christian Fredrik Kalager Schaller
Modified: 2017-03-14 15:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
check-accelerated: Fix warnings on startup (1.07 KB, patch)
2016-10-11 11:40 UTC, Bastien Nocera
none Details | Review
check-accelerated: Print the renderer under Wayland as well (3.68 KB, patch)
2016-10-11 11:41 UTC, Bastien Nocera
none Details | Review
info: Get renderer from gnome-session under Wayland (2.79 KB, patch)
2016-10-11 11:43 UTC, Bastien Nocera
none Details | Review
check-accelerated: Print the renderer under Wayland as well (3.82 KB, patch)
2016-10-18 13:42 UTC, Bastien Nocera
none Details | Review
info: Get renderer from gnome-session under Wayland (5.72 KB, patch)
2016-10-18 14:13 UTC, Bastien Nocera
committed Details | Review
check-accelerated: Fix warnings on startup (1.07 KB, patch)
2016-10-20 17:53 UTC, Bastien Nocera
committed Details | Review
check-accelerated: Print the renderer under Wayland as well (3.81 KB, patch)
2016-10-20 17:53 UTC, Bastien Nocera
none Details | Review
check-accelerated: Print the renderer under Wayland as well (3.64 KB, patch)
2016-10-20 18:01 UTC, Bastien Nocera
committed Details | Review

Description Christian Fredrik Kalager Schaller 2015-10-21 13:49:57 UTC
When running under Wayland the 'Graphics' item in the details screen only says 'Wayland'. Would be nice if it said for instance 'Wayland - Intel Ivy Bridge' or 'X11 - Nvidia 970', so showing you both which graphics system you are using and which graphics hardware you have.
Comment 1 Bastien Nocera 2015-10-21 14:58:15 UTC
Mutter would need to expose that data, it's currently not available through the usual GL APIs. I'll reassign to mutter, and will fix the panel once mutter has the API to allow that.
Comment 2 Bastien Nocera 2015-11-12 16:14:04 UTC
*** Bug 758016 has been marked as a duplicate of this bug. ***
Comment 3 Matthias Clasen 2015-11-13 02:50:30 UTC
#include <gtk/gtk.h>
#include <epoxy/gl.h>

static void
on_map (GtkWidget *widget)
{
  GdkGLContext *context;

  context = gdk_window_create_gl_context (gtk_widget_get_window (widget), NULL);
  gdk_gl_context_make_current (context);
  g_print ("GL Vendor: %s\nGL Renderer: %s\nGL Version: %s\n",
           glGetString (GL_VENDOR),
           glGetString (GL_RENDERER),
           glGetString (GL_VERSION));
  gdk_gl_context_clear_current ();
  g_object_unref (context);
}

int
main (int argc, char *argv[])
{
  GtkWidget *win;

  gtk_init (NULL, NULL);
  win = gtk_window_new (GTK_WINDOW_TOPLEVEL);
  g_signal_connect_after (win, "map", G_CALLBACK (on_map), NULL);
  gtk_widget_show (win);
  gtk_main ();

  return 0;
}



Compile with: 

gcc -g -o testgl testgl.c `pkg-config --cflags --libs gtk+-3.0 epoxy`


This prints the following under Wayland here:

$ ./testgl
GL Vendor: Intel Open Source Technology Center
GL Renderer: Mesa DRI Intel(R) Ivybridge Mobile 
GL Version: 3.3 (Core Profile) Mesa 11.1.0-devel (git-5ae37ae)
Comment 4 Matthias Clasen 2015-11-13 02:51:38 UTC
So I think you can do this in the control center without even having different code paths for X or Wayland.
Comment 5 Bastien Nocera 2015-11-13 10:14:35 UTC
That doesn't work with EGL (requested in another bug) nor does it enumerate all the cards when using a dual-GPU setup. I'd rather mutter exported that information.
Comment 6 Matthias Clasen 2015-11-13 11:17:31 UTC
EGL doesn't expose any of this information, as far as I can see.

The best you can get out of drmGetVersion() is

Name: i915
Date: 20151010
Description: Intel Graphics
Comment 7 Jasper St. Pierre (not reading bugmail) 2015-11-13 17:20:23 UTC
(In reply to Bastien Nocera from comment #5)
> That doesn't work with EGL (requested in another bug) nor does it enumerate
> all the cards when using a dual-GPU setup. I'd rather mutter exported that
> information.

We don't have that information either. The proper EGL way to do this is EGLDevice to enumerate devices and libglvnd to do dispatch to the GL driver to figure out what the renderer will be in that case.
Comment 8 Ray Strode [halfline] 2015-11-13 19:37:29 UTC
i don't think libglvnd supports egl yet?  

There's a way to query display attributes posted here: 

http://lists.freedesktop.org/archives/mesa-dev/2015-July/thread.html#89783

But i don't think it's landed yet, and the only attribute it supports is the card device node .

Regardless, there's two tiers to shoot for:

1) parity with X11
2) better output above X11

1 may be a more near term goal than 2.
Comment 9 Bastien Nocera 2016-10-11 11:40:58 UTC
Created attachment 337404 [details] [review]
check-accelerated: Fix warnings on startup

The Wayland session is now named "gnome" not "gnome-wayland", so don't
try to run the X11-specific code when under Wayland.
Comment 10 Bastien Nocera 2016-10-11 11:41:04 UTC
Created attachment 337405 [details] [review]
check-accelerated: Print the renderer under Wayland as well

Based on sample code by Matthias Clasen <mclasen@redhat.com>

We'll use this in gnome-control-center when gnome-session cannot provide
a renderer, under Wayland, as the Wayland compositor runs after
gnome-session's startup.
Comment 11 Bastien Nocera 2016-10-11 11:43:09 UTC
Created attachment 337408 [details] [review]
info: Get renderer from gnome-session under Wayland

Now that gnome-session's acceleration helper can print the renderer
under Wayland, launch it locally. We need to launch it locally as
Wayland is not available at the time gnome-session would launch the
helper, as there's no Wayland compositor yet.
Comment 12 Bastien Nocera 2016-10-11 11:46:59 UTC
Would still be much easier to do in mutter directly, as we need to handle multiple cases:
- X11, get the GL or GLES renderer from gnome-session
- Wayland, get the GL or GLES renderer from the gnome-session helper
- X11/Wayland, get the GPUs available from switcheroo-control for dual-GPU systems:
  https://github.com/hadess/switcheroo-control

Would we have a way to simplify that?
Comment 13 Ting-Wei Lan 2016-10-11 12:22:58 UTC
(In reply to Bastien Nocera from comment #11)
> Created attachment 337408 [details] [review] [review]
> info: Get renderer from gnome-session under Wayland
> 
> Now that gnome-session's acceleration helper can print the renderer
> under Wayland, launch it locally. We need to launch it locally as
> Wayland is not available at the time gnome-session would launch the
> helper, as there's no Wayland compositor yet.

Does this work if gnome-session and gnome-control-center are compiled with different libexecdir? Some distributions don't like /usr/libexec and set it to /usr/lib/<pkgname> instead.
Comment 14 Bastien Nocera 2016-10-11 12:47:40 UTC
(In reply to Ting-Wei Lan from comment #13)
> (In reply to Bastien Nocera from comment #11)
> > Created attachment 337408 [details] [review] [review] [review]
> > info: Get renderer from gnome-session under Wayland
> > 
> > Now that gnome-session's acceleration helper can print the renderer
> > under Wayland, launch it locally. We need to launch it locally as
> > Wayland is not available at the time gnome-session would launch the
> > helper, as there's no Wayland compositor yet.
> 
> Does this work if gnome-session and gnome-control-center are compiled with
> different libexecdir? Some distributions don't like /usr/libexec and set it
> to /usr/lib/<pkgname> instead.

No, it doesn't.
Comment 15 Bastien Nocera 2016-10-11 12:52:18 UTC
I looked, and we can't detect it. Maybe gnome-session should run it after it has a compositor, but I'm not sure how we'd detect that.
Comment 16 Ting-Wei Lan 2016-10-13 07:29:57 UTC
(In reply to Bastien Nocera from comment #10)
> Created attachment 337405 [details] [review] [review]
> check-accelerated: Print the renderer under Wayland as well
> 
> Based on sample code by Matthias Clasen <mclasen@redhat.com>
> 
> We'll use this in gnome-control-center when gnome-session cannot provide
> a renderer, under Wayland, as the Wayland compositor runs after
> gnome-session's startup.

It doesn't work when gdk_window_create_gl_context fails. If the hardware or the driver doesn't support OpenGL 3, it is likely to fail.
Comment 17 Bastien Nocera 2016-10-13 09:03:04 UTC
(In reply to Ting-Wei Lan from comment #16)
> (In reply to Bastien Nocera from comment #10)
> > Created attachment 337405 [details] [review] [review] [review]
> > check-accelerated: Print the renderer under Wayland as well
> > 
> > Based on sample code by Matthias Clasen <mclasen@redhat.com>
> > 
> > We'll use this in gnome-control-center when gnome-session cannot provide
> > a renderer, under Wayland, as the Wayland compositor runs after
> > gnome-session's startup.
> 
> It doesn't work when gdk_window_create_gl_context fails. If the hardware or
> the driver doesn't support OpenGL 3, it is likely to fail.

It should show "Unknown". If not, you'll need to be more precise than that.
Comment 18 Ting-Wei Lan 2016-10-13 09:18:18 UTC
It shows '(null)' because there is no error checking.

$ gnome-session-check-accelerated

(gnome-session-check-accelerated:12011): Gdk-CRITICAL **: gdk_gl_context_make_current: assertion 'GDK_IS_GL_CONTEXT (context)' failed

(gnome-session-check-accelerated:12011): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
(null)
Comment 19 Bastien Nocera 2016-10-18 13:42:51 UTC
Created attachment 337942 [details] [review]
check-accelerated: Print the renderer under Wayland as well

Based on sample code by Matthias Clasen <mclasen@redhat.com>

We'll use this in gnome-control-center when gnome-session cannot provide
a renderer, under Wayland, as the Wayland compositor runs after
gnome-session's startup.

If OpenGL 3 is not supported (which is required for GTK+'s GL support),
then nothing is output.
Comment 20 Bastien Nocera 2016-10-18 13:43:34 UTC
(In reply to Ting-Wei Lan from comment #18)
> It shows '(null)' because there is no error checking.
> 
> $ gnome-session-check-accelerated
> 
> (gnome-session-check-accelerated:12011): Gdk-CRITICAL **:
> gdk_gl_context_make_current: assertion 'GDK_IS_GL_CONTEXT (context)' failed
> 
> (gnome-session-check-accelerated:12011): GLib-GObject-CRITICAL **:
> g_object_unref: assertion 'G_IS_OBJECT (object)' failed
> (null)

Can you please test with the patch from comment 19? It does error checking properly (or should).
Comment 21 Bastien Nocera 2016-10-18 14:13:43 UTC
Created attachment 337945 [details] [review]
info: Get renderer from gnome-session under Wayland

Now that gnome-session's acceleration helper can print the renderer
under Wayland, launch it locally. We need to launch it locally as
Wayland is not available at the time gnome-session would launch the
helper, as there's no Wayland compositor yet.

Note that this code expects the gnome-session helper scripts to live
in $libexecdir, but distributions can use
--with-gnome-session-libexecdir=DIR to pass another one.
Comment 22 Bastien Nocera 2016-10-18 14:17:24 UTC
(In reply to Ting-Wei Lan from comment #13)
> (In reply to Bastien Nocera from comment #11)
> > Created attachment 337408 [details] [review] [review] [review]
> > info: Get renderer from gnome-session under Wayland
> > 
> > Now that gnome-session's acceleration helper can print the renderer
> > under Wayland, launch it locally. We need to launch it locally as
> > Wayland is not available at the time gnome-session would launch the
> > helper, as there's no Wayland compositor yet.
> 
> Does this work if gnome-session and gnome-control-center are compiled with
> different libexecdir? Some distributions don't like /usr/libexec and set it
> to /usr/lib/<pkgname> instead.

And the patch in comment 21 should fix this particular problem.
Comment 23 Matthias Clasen 2016-10-18 14:37:50 UTC
thanks for pushing this forward, Bastien
Comment 24 Bastien Nocera 2016-10-19 10:42:52 UTC
*** Bug 758016 has been marked as a duplicate of this bug. ***
Comment 25 Ray Strode [halfline] 2016-10-20 14:21:17 UTC
Review of attachment 337404 [details] [review]:

::: tools/gnome-session-check-accelerated.c
@@ +108,3 @@
          * assume wayland will work
          */
+        if (g_strcmp0 (g_getenv ("XDG_SESSION_DESKTOP"), "gnome") == 0) {

well the X11 session can be called gnome too ...  Fallback is implemented by having a wayland session and x11 session with the same name. This should probably be XDG_SESSION_TYPE, "wayland"
Comment 26 Ray Strode [halfline] 2016-10-20 14:38:49 UTC
Review of attachment 337942 [details] [review]:

good enough! some possibilities below

::: tools/gnome-session-check-accelerated.c
@@ +115,3 @@
+
+        win = gtk_window_new (GTK_WINDOW_TOPLEVEL);
+        g_signal_connect_after (win, "map", G_CALLBACK (on_map), &renderer);

I think "realize" is a better signal handler than "map"?  Though, maybe you can avoid the signal handler entirely and just do:

gtk_widget_realize (win)
create_gl_context
make_current
glGetString
etc

or is there some trickery that's preventing realize from working?

@@ +134,3 @@
 
+        gtk_init (NULL, NULL);
+

as an aside, we should probably feed argc and argv to this, but I guess you're just moving code around

@@ +141,3 @@
         if (g_strcmp0 (g_getenv ("XDG_SESSION_DESKTOP"), "gnome") == 0) {
+                renderer_string = get_gtk_gles_renderer ();
+                g_print ("%s", renderer_string);

if we're adding a g_print should probably put G_SPAWN_STDOUT_TO_DEV_NULL in the gnome-session caller. Though looking closer, we actually started doing the g_print in bug 768292 so maybe it doesn't matter. just clutters up the log a little, and the log is already pretty cluttered.
Comment 27 Ray Strode [halfline] 2016-10-20 14:45:08 UTC
Review of attachment 337945 [details] [review]:

i sort of wonder if we should rename gnome-session-check-accelerated and make it live somewhere else now, but I can't think of a better place. anyway, seems okay.

::: panels/info/cc-info-panel.c
@@ +334,3 @@
+
+  if (!g_spawn_sync (NULL, (char **) argv, NULL, 0, NULL, NULL, &renderer, NULL, &status, NULL))
+    return NULL;

GSubprocess is the new cool, but I agree GSpawn is probably less code.
Comment 28 Bastien Nocera 2016-10-20 17:53:23 UTC
Created attachment 338113 [details] [review]
check-accelerated: Fix warnings on startup

The Wayland session is now named "gnome" not "gnome-wayland", so don't
try to run the X11-specific code when under Wayland.
Comment 29 Bastien Nocera 2016-10-20 17:53:28 UTC
Created attachment 338114 [details] [review]
check-accelerated: Print the renderer under Wayland as well

Based on sample code by Matthias Clasen <mclasen@redhat.com>

We'll use this in gnome-control-center when gnome-session cannot provide
a renderer, under Wayland, as the Wayland compositor runs after
gnome-session's startup.

If OpenGL 3 is not supported (which is required for GTK+'s GL support),
then nothing is output.
Comment 30 Bastien Nocera 2016-10-20 18:01:45 UTC
(In reply to Ray Strode [halfline] from comment #26)
> Review of attachment 337942 [details] [review] [review]:
> 
> good enough! some possibilities below
> 
> ::: tools/gnome-session-check-accelerated.c
> @@ +115,3 @@
> +
> +        win = gtk_window_new (GTK_WINDOW_TOPLEVEL);
> +        g_signal_connect_after (win, "map", G_CALLBACK (on_map), &renderer);
> 
> I think "realize" is a better signal handler than "map"?  Though, maybe you
> can avoid the signal handler entirely and just do:
> 
> gtk_widget_realize (win)
> create_gl_context
> make_current
> glGetString
> etc

That worked, and stopped the window showing up for a few milliseconds, making it pop up in the gnome-shell menu list.

> or is there some trickery that's preventing realize from working?
> 
> @@ +134,3 @@
>  
> +        gtk_init (NULL, NULL);
> +
> 
> as an aside, we should probably feed argc and argv to this, but I guess
> you're just moving code around

Yep, just moving code around here.

> @@ +141,3 @@
>          if (g_strcmp0 (g_getenv ("XDG_SESSION_DESKTOP"), "gnome") == 0) {
> +                renderer_string = get_gtk_gles_renderer ();
> +                g_print ("%s", renderer_string);
> 
> if we're adding a g_print should probably put G_SPAWN_STDOUT_TO_DEV_NULL in
> the gnome-session caller. Though looking closer, we actually started doing
> the g_print in bug 768292 so maybe it doesn't matter. just clutters up the
> log a little, and the log is already pretty cluttered.

This command is not launched at all on Wayland (after the session type fix), until gnome-control-center's Details panel is launched. So no extra garbage in the logs. The different code paths for X11 and Wayland are pretty awful here, where the *need* the helper to be launched for X11, and not at all for Wayland. In the long term, we'll just remove all this X11 code, and live with it until now.
Comment 31 Bastien Nocera 2016-10-20 18:01:58 UTC
Created attachment 338119 [details] [review]
check-accelerated: Print the renderer under Wayland as well

Based on sample code by Matthias Clasen <mclasen@redhat.com>

We'll use this in gnome-control-center when gnome-session cannot provide
a renderer, under Wayland, as the Wayland compositor runs after
gnome-session's startup.

If OpenGL 3 is not supported (which is required for GTK+'s GL support),
then nothing is output.
Comment 32 Bastien Nocera 2016-10-20 18:09:00 UTC
Attachment 338113 [details] pushed as 9055c11 - check-accelerated: Fix warnings on startup
Attachment 338119 [details] pushed as 6e474f9 - check-accelerated: Print the renderer under Wayland as well
Comment 33 Bastien Nocera 2016-10-20 18:11:04 UTC
Attachment 337945 [details] pushed as 83c8c57 in gnome-control-center - info: Get renderer from gnome-session under Wayland
Comment 34 Antoine Jacoutot 2017-03-14 12:44:49 UTC
Hi Bastien.

On a box without Wayland, I am getting this error:

panels/info/.libs/libinfo.a(cc-info-panel.o): In function `cc_info_panel_init':
cc-info-panel.c:(.text+0x2a4f): undefined reference to `GDK_IS_WAYLAND_DISPLAY'

That's a regression due to the fact that GDK_IS_WAYLAND_DISPLAY is now reachable if at least *one* of GDK_WINDOWING_X11 or GDK_WINDOWING_WAYLAND is defined.
Comment 35 Bastien Nocera 2017-03-14 13:15:26 UTC
(In reply to Antoine Jacoutot from comment #34)
> Hi Bastien.
> 
> On a box without Wayland, I am getting this error:
> 
> panels/info/.libs/libinfo.a(cc-info-panel.o): In function
> `cc_info_panel_init':
> cc-info-panel.c:(.text+0x2a4f): undefined reference to
> `GDK_IS_WAYLAND_DISPLAY'
> 
> That's a regression due to the fact that GDK_IS_WAYLAND_DISPLAY is now
> reachable if at least *one* of GDK_WINDOWING_X11 or GDK_WINDOWING_WAYLAND is
> defined.

Bug for the wrong module to mention this. In the future, would also be nice for you to run your test builds *before* releases. That code has been there since November...

Cherry-picked in 4825881b129bdde0eaa5419ece6198ebda420825, as it was already fixed for gnome-3-24 and master.
Comment 36 Antoine Jacoutot 2017-03-14 15:08:47 UTC
(In reply to Bastien Nocera from comment #35)
> (In reply to Antoine Jacoutot from comment #34)
> > Hi Bastien.
> > 
> > On a box without Wayland, I am getting this error:
> > 
> > panels/info/.libs/libinfo.a(cc-info-panel.o): In function
> > `cc_info_panel_init':
> > cc-info-panel.c:(.text+0x2a4f): undefined reference to
> > `GDK_IS_WAYLAND_DISPLAY'
> > 
> > That's a regression due to the fact that GDK_IS_WAYLAND_DISPLAY is now
> > reachable if at least *one* of GDK_WINDOWING_X11 or GDK_WINDOWING_WAYLAND is
> > defined.
> 
> Bug for the wrong module to mention this. In the future, would also be nice

I used this BZ URL because it was mentioned in the commit (c5c3e04a3cbebbae7ecba64deb83a31970d7665a); but yeah, not the same module, sorry about that, I just assumed.

> for you to run your test builds *before* releases. That code has been there
> since November...

Unfortunately, I'm not currently in a position to do regression testing.

> Cherry-picked in 4825881b129bdde0eaa5419ece6198ebda420825, as it was already
> fixed for gnome-3-24 and master.

Thank you very much for your timely fix.