GNOME Bugzilla – Bug 615853
BadMatch when pressing keyboard volume keys while pointer in secondary X screen
Last modified: 2010-04-28 14:18:56 UTC
When I configure my laptop to use two separate X screens, move my mouse pointer to the secondary one and press any of the volume keys, gnome-settings-daemon receives a badmatch from X. This is the stacktrace when I run gdb on gnome-settings-daemon --sync --no-daemon --debug. Breakpoint is set to gdk_x_error:
+ Trace 221390
> # #19 ?? > from /usr/lib/gnome-settings-daemon-2.0/libmedia-keys.so That would quite probably be the most useful bit...
I know, but unfortunately Debian doesn't provide a debugging package for gnome-settings-daemon. Fortuantely, there is only one place where gdk_window_input_shape_combine_mask() gets called in the whole gsd code: gsd_media_keys_window_real_realize (), gsd-media-keys-window.c: 891 (looking at the sources for 2.28.1)
That code has been there for about two years, and only in the composited case: commit c125c5a50ad229ea386277c582a809681d4dbfb3 Author: Carlos Garnacho <carlosg@gnome.org> Date: Wed May 7 23:30:58 2008 +0000 New function, sets a fully transparent input shape, so that clicks go 2008-05-08 Carlos Garnacho <carlosg@gnome.org> * plugins/media-keys/gsd-media-keys-window.c (gsd_media_keys_window_real_realize): New function, sets a fully transparent input shape, so that clicks go through the media keys windows. Bug #531862. (gsd_media_keys_window_class_init): The usual glue. The docs for XShapeCombineMask are rubbish though, and don't say when it would fail with a BadMatch. Maybe the window needs to be forced as native?
Hm, but I am not running a composite window manager, just plain metacity.
With compositing enabled? :) If not, it's probably Federico's fault then.
Well, I am meant without compositing of course. :) Calling Federico then.
Seems to be a gtk bug: -8<---- GdkRegion * _gdk_windowing_get_shape_for_mask (GdkBitmap *mask) { GdkDisplay *display; Window window; GdkRegion *region; display = gdk_drawable_get_display (GDK_DRAWABLE (mask)); window = XCreateSimpleWindow (GDK_DISPLAY_XDISPLAY (display), GDK_SCREEN_XROOTWIN (gdk_display_get_default_screen (display)), -1, -1, 1, 1, 0, 0, 0); XShapeCombineMask (GDK_DISPLAY_XDISPLAY (display), window, ShapeBounding, 0, 0, GDK_PIXMAP_XID (mask), ShapeSet); ... -->8--- Note, it's creating the window for the default screen, but using a passed in mask which could be for a different screen. Probably just needs a gdk_drawable_get_screen call or similar.
Created attachment 158836 [details] minimal test case This is enough to reproduce the bug. Run it from :0 display to see it getting a BadMatch (you need more than one screen). If you have one display it will work fine.
(I mean, if you have one screen of course).
Created attachment 158840 [details] [review] Fix Tested fix: From a0a76cbc595d780d97fde2a5bc9126b8d7928ce8 Mon Sep 17 00:00:00 2001 From: Claudio Saavedra <csaavedra@igalia.com> Date: Fri, 16 Apr 2010 00:12:29 +0300 Subject: [PATCH] Use the proper screen in _gdk_windowing_get_shape_for_mask() Bug 615853 - BadMatch when pressing keyboard volume keys while pointer in secondary X screen _gdk_windowing_get_shape_for_mask() is using the default screen, not taking into account that its GdkBitmap could have been created for a different one, causing BadMatch errors. --- gdk/x11/gdkwindow-x11.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
Comment on attachment 158840 [details] [review] Fix Looks good
Thanks, committed to gtk-2-20 and master.
I have tried the patch from comment 11 with gtk 2.18.9, I can still reproduce the gnome-settings-daemon crash. The test case however is fine.
A stacktrace would be nice.
For the record, I home-brewed today a debian pacakge for 2.20.0-3 with this patch on top and the bug is fixed, so I suspect that you are probably hitting another bug that was fixed between 2.18.9 and this.
Yes, looks like another bug related to connecting a second monitor and making gnome-settings-daemon crash. I'll open a new bug later.