The order and way include macros were structured was chaotic, with no
real common thread between files. Try to tidy up the mess with some
common scheme, to make things look less messy.
Commit 840378ae68 changed the code to use XmbTextPropertyToTextList()
instead of gdk_text_property_to_utf8_list_for_display(), but didn't
take into account that the replacement returns text in the current
locale's encoding, while any callers (rightfully) expect UTF8.
Fix this by converting the text if necessary.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/227
They are X11 specific functions, used for X11 code. They have been
improved per jadahl's suggestion to use gdk_x11_lookup_xdisplay and
gdk_x11_display_error_trap_* functions, instead of current code.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
- Moved xdisplay, name and various atoms from MetaDisplay
- Moved xroot, screen_name, default_depth and default_xvisual
from MetaScreen
- Moved some X11 specific functions from screen.c and display.c
to meta-x11-display.c
https://bugzilla.gnome.org/show_bug.cgi?id=759538
Commits 6dbec6f8, 734402e1 and f041b35b introduced memory leaks by
switching to returning copies instead of the original buffers but
forgetting to free those original buffers.
Some error cases were also not freeing the ->prop buffer as they
should.
https://bugzilla.gnome.org/show_bug.cgi?id=642652
Some of the mutter code using these properties expects them to be
null-terminated whereas xcb does not use null-terminated strings:
http://xcb.freedesktop.org/XcbRationale/
This was in some cases resulting in the WM_CLASS property containing
garbage data which broke application matching, caused the hot-corner and
window-switcher to stop working, or was exposed as text in the UI.
https://bugzilla.gnome.org/show_bug.cgi?id=759658
Both Window and XSyncCounter are XIDs which on 64 bit X clients are 8
bytes wide. But the values on the wire are 32 bit so, for these types,
we always copy 4 bytes into results->prop. As such copying them out
with a cast such as *(Window *) means that we are actually reading 8
bytes which depending on whether the higher addressed 4 bytes are zero
means that sometimes this works while others it gives us a bogus
value.
https://bugzilla.gnome.org/show_bug.cgi?id=756074
It seems the largest possible value is to be passed, so actually pass
that instead. Note that even though the name of the xcb_get_property
parameter is called 'long_length' its actually a uint32_t.
https://bugzilla.gnome.org/show_bug.cgi?id=751136
It's been long enough. We can mandate support for these, at least
at build-time. The code doesn't actually compile without either
of these, so just consider that unsupported.
This is specifically about managing X11 windows, not necessarily
running as an X11 compositor. By that I mean that this code is
still used for XWayland windows, and event handling is still and
modesetting / monitor management is still in core/.
This is also a fairly conservative move. We don't move anything
like screen.c or bell.c in here, even though those are really
only for X11 clients.
