Carlos Garnacho authored 4 years ago and Olivier Fourdan committed 4 years ago

In this pretty Wine/Proton specific kludge, we try to handle confining grabs
on InputOnly windows by trying to find the InputOutput window that the pointer
would get visually confined to.

The grabbing window and the visible window come from different clients, so
we used to simply resort to the pointer focus. This is troublesome though, as
the call may happen very soon at a time that the toplevel wasn't yet mapped by
the Wayland compositor, so the pointer focus may well be out of date soon.

In these situations, it does seem that even though the confining grab happens
too early to have the wayland surface mapped, the xserver view of the WindowPtr
does already reflect the size. Use this to find out the better window to
assign the confining grab to, one whose geometry fully contains the InputOnly
window's.

Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>

xwl_seat_maybe_lock_on_hidden_cursor() checks that the value of
cursor_confinement_window is not NULL, yet there is no code path
that could lead to this.

Remove the test for cursor_confinement_window being set, it's useless.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>

When an X11 client issues a ConfinePointer wit ha hidden cursor,
Xwayland may translate that as a pointer lock.

However, if the pointer is located on another window at the time,
the request may be ignored, even if the pointer later enters the window.

To avoid that issue, check again if locking the pointer with a hidden
cursor is needed when pointer enters a surface.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>

When an X11 client has an active grab on the pointer, all events are
reported relative to the window with the grab.

For Xwayland, if an X11 client has a grab with a pointer confinement
active, while pointer focus is on another window, motion events should
not be reported to the client with the grab, because that sets the X11
client appart, the events would be reported when the pointer is on any
X11 window but not on Wayland native surfaces.

Therefore, if the pointer is confined on a window and that window
differs from the actual pointer focus window, just pretend we lost
pointer focus to another window.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: #962


Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>

If a client issues a grab on the pointer while the cursor is on another
X11 window, and then hides the cursor, we may end up locking the pointer
onto that other window.

Then a button click might end up moving the focus away from the window
which issued the grab, leaving the whole setup in a mixed up state.

Typically, if the pointer is on another X11 window, we should not try to
lock the pointer, so that it can be moved back to the window which
actually issues the grab (and hence the pointer confinement). Typically,
this is the same as an X11 client issuing a pointer grab while the
cursor is on another Wayland native window.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: #962


Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>

Mostly http->https conversions, but also replaces gitweb.fd.o
with gitlab.fd.o, and xquartz.macosforge.org with xquartz.org.

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

Christopher Chavez authored 4 years ago and Peter Hutterer committed 4 years ago

Signed-off-by: Christopher Chavez <chrischavez@gmx.us>

Tobias Stoeckmann authored 4 years ago and Adam Jackson committed 4 years ago

On systems with ACPI but disabled APM (e.g. --disable-linux-apm)
the code does not compile due to preprocessor directives.

If APM is disabled, the final return statement is considered to
be part of ACPI's last if-statement, leading to a function which
has no final return statement at all.

I have refactored the code so ACPI and APM are independent of each
other.

Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>

Mutter recently added headless tests, and when running those tests the
Wayland compositor runs for a very short time.

Xwayland is spawned by the Wayland compositor and upon startup will
query the various Wayland protocol supported by the compositor.

To do so, it will do a roundtrip to the Wayland server waiting for
events it expects.

If the Wayland compositor terminates before Xwayland has got the replies
it expects, it will loop indefinitely calling `wl_display_roundtrip()`
continuously.

To avoid that issue, add a new `xwl_screen_roundtrip()` that checks for
the returned value from `wl_display_roundtrip()` and fails if it is
negative.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Roman Gilg <subdiff@gmail.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>

Since we now only work with UTF-8 (or ISO8859-1) text in the clipboard,
we don't need to setlocale().

This avoids including Xdefs.h, which means we avoid all the issues with
_XSERVER64 effecting how types are defined by that.

All helper client code now uses xcb, so calling XSetAuthorization() is
no longer needed.

This is the last reference to libX11 from helper clients, so linking
with x11-xcb and libX11 is no longer required.

Also drop (unneeded?) linking with libXau.

Also drop installing these prerequistes on AppvVeyor.

Also move prototypes for functions in winauth.c from win.h into a new
header, winauth.h, and include that where needed.

Convert clipboard integration code from libX11 to xcb

This drops support for COMPOUND_TEXT.  Presumably some ancient
(pre-2000) clients exist which support that, but not UTF8_STRING, but we
don't have an example to test with. (Given the nature of the thing, the
users of those clients probably work in CJK languages)

Supporting COMPOUND_TEXT would also involve writing (or extracting from
Xlib) support for the ISO 2022 encoding.

v2:
Fix the length of text property set by a SelectionRequest

The length of the text property is not neccessarily the same as the
length of the clipboard text before it is d2u converted (specifically,
if that contains any '\r\n' sequences, it will be shorter as they are
now just '\n')

Always use CF_UNICODETEXT clipboard format.  Windows will automatically
down-convert to CF_TEXT for clients which request that.

This is subtly different in one way: if CF_TEXT is requested, we now
post CF_UNICODETEXT and it is converted to CF_TEXT *in the locale of the
requesting process*.  Previously, we would convert to CF_TEXT *in our
locale* and post that.

It looks like the code in the !X_HAVE_UTF8_STRING case didn't actually
work correctly, but fortunately that has never been true...

The original Win32 clipboard API is widely regarded as terrible, since
it relies on clients co-operatively managing the clipboard viewer chain,
and a single buggy client can break it for all other clients.

The last Windows version only supporting that API was Windows XP (5.1),
EOLed in 2014.

(This requires MinGW-w64 w32api 6.0.0 or later for
Add/RemoveClipboardListener correctly exported by the x86_64 user32
implib)

XChangeProperty() requests larger than the ~16MB permitted even with
BigReq will fail BadLength

Also, relax the timeout mechanism so it allows 1 second between events,
rather than 1 second for the entire transfer, as transfers of large
pastes can take more than 1 second.

Also, prefer UTF8_STRING encoding to COMPOUND_TEXT encoding

This option was implemented before the drivers were split in ≈2006,
and e.g. XWin still supports it.

With this commit, Xorg regains support, so that the following configuration can
be used to set the repeat rate for all keyboard devices without having to modify
Xorg command-line flags or having to automate xset(1):

Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "de"
        Option "XkbVariant" "neo"
	Option "AutoRepeat" "250 30"
EndSection

Signed-off-by: Michael Stapelberg <stapelberg@google.com>

Adam Jackson authored 6 years ago and Adam Jackson committed 4 years ago

Initialized to a constant value, never modified, never varied by device.

Signed-off-by: Adam Jackson <ajax@redhat.com>

Adam Jackson authored 6 years ago and Adam Jackson committed 4 years ago

Initialized to a constant value, never modified, never varied by device.

Signed-off-by: Adam Jackson <ajax@redhat.com>

The GLX_ARB_create_context path (with which this should all get unified,
someday, sigh) already enforces this, but the classic path does not.
It's effectively assumed by the implementation anyway, so let's enforce
it rather than do crashy things.

Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>

Vasily Khoruzhick authored 5 years ago and Adam Jackson committed 5 years ago

glxProbeDriver() concatenates __DRI_DRIVER_GET_EXTENSIONS with driver name
to get symbol name for get_extension function. Unfortunately that doesn't
work for drivers that have hyphen in their name, e.g. sun4i-drm --
get_extensions() for these uses underscore instead.

As result dlsym() doesn't find get_extension() function and AIGLX
initialization fails resulting in following message in Xorg.0.log:

(EE) AIGLX error: sun4i-drm does not export required DRI extension

Replace all non-alpha-numeric characters with underscore to fix the issue.

Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>

We were only calling xwl_present_unrealize_window for the toplevel
window, but the list can contain entries from child windows as well,
in which case we were leaving dangling pointers to freed memory.

Closes: #1000


Fixes: c5067fea "xwayland: Use single frame callback for Present
                     flips and normal updates"
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>

Yuriy Vasilev authored 5 years ago and Adam Jackson committed 5 years ago

Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Yuriy Vasilev <uuvasiliev@yandex.ru>

Yuriy Vasilev authored 5 years ago and Adam Jackson committed 5 years ago

This allow x-server to run with -depth 16.

Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Yuriy Vasilev <uuvasiliev@yandex.ru>

mntmn authored 5 years ago and Olivier Fourdan committed 5 years ago

Recently, rooted Xwayland crashes on wlroots-based compositors, because
wlroots removed the deprecated wl_shell protocol.
This MR fixes this by changing the code in question to the xdg-shell
protocol. My motivation do this: on etnaviv-based embedded platforms,
rooted Xwayland is much faster and doesn't cause UI rendering bugs
compared to rootless Xwayland.

Signed-off-by: Lukas F. Hartmann <lukas@mntre.com>

This code block was moved from a function that returns 0 for failure to a
function that returns 0 for Success in commit
649293f6. Change the return value to
BadValue to match the other checks in _XkbSetMapChecks.

Set nTypes to xkb->map->num_types when XkbKeyTypesMask is not set, to
allow requests with the XkbKeyTypesMask flag unset in stuff->present to
succeed.

Fixes a potential heap smash when client->swapped is true, because the
remainder of the request will not be swapped after "return 0", but
_XkbSetMap will be called anyway (because 0 is Success).

Signed-off-by: Peter Harris <pharris@opentext.com>

The server swaps part of the request in _XkbSetMapChecks instead of
SProcXkbSetMap (presumably because walking the XkbSetMap request is hard,
and we don't want to maintain another copy of that code).

Swap the first time _XkbSetMapChecks is called, not the second time.

Signed-off-by: Peter Harris <pharris@opentext.com>

xwayland: Remove unnecessary xwl_window_is_toplevel() check from xwl_output_set_window_randr_emu_props()

Since the recent fix to call xwl_output_set_window_randr_emu_props() from
ensure_surface_for_window(), it is now only called on a toplevel window,
so the is-toplevel check is not necessary for the
xwl_output_set_window_randr_emu_props() case.

This commit moves the check to xwl_output_set_randr_emu_prop_callback()
so that we only do it when we are walking over all Windows of a client
to update the property on a change of the emulated resolution.

Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

For window-manager managed windows, xwl_realize_window is only called for
the window-manager's decoration window and not for the actual client window
on which we should set the _XWAYLAND_RANDR_EMU_MONITOR_RECTS prop.

Usualy this is not a problem since we walk all client windows to update
the property when the resolution is changed through a randr call.

But for apps which first do the randr change and only then create their
window this does not work, and our xwl_output_set_window_randr_emu_props
call in xwl_realize_window is a no-op as that is only called for the wm
decoration window and not for the actual client's window.

This commit fixes this by making ensure_surface_for_window() call
xwl_output_set_window_randr_emu_props on the first and only child of
window-manager managed windows.

Note this also removes the non-functional xwl_output_set_window_randr_emu_props
call from xwl_realize_window, which was intended to do this, but does not
work.

This fixes apps using the ogre3d library always running at the
monitors native resolution.

Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Some clients, which use vidmode to change the resolution when going fullscreen,
create an override-redirect window and never trigger the screen->ResizeWindow
callback we rely on to do the xwl_window_check_resolution_change_emulation().

This causes us to not apply a viewport to them, causing the fullscreen window
to not fill the entire monitor.

This commit adds a call to xwl_window_check_resolution_change_emulation()
at the end of ensure_surface_for_window() to fix this. Note that
ensure_surface_for_window() exits early without creating an xwl_window
for new windows which will not be backed by a wayland surface and which
thus will not have an xwl_window.

This fixes ClanLib-0.6.x and alleggl-4.4.x using apps not properly
fullscreening.

Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

The code building the mode-list does the following to deal with screen
rotation:

    if (need_rotate || xwl_output->rotation & (RR_Rotate_0 | RR_Rotate_180)) {
        mode_width = xwl_output->width;
        mode_height = xwl_output->height;
    } else {
        mode_width = xwl_output->height;
        mode_height = xwl_output->width;
    }

This means we need to do something similar in xwl_output_set_emulated_mode()
to determine if the mode being set is the actual (not-emulated) output mode
and we this should remove any emulated modes set by the client.

All callers of xwl_output_set_emulated_mode always pass a mode pointer
to a member of xwl_output->randr_output->modes, so we do not need to
duplicate this code, instead we can simply check that the passed in mode
is modes[0] which always is the actual output mode.

Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Not only hook the ResizeWindow method of the screen (which really is
MoveAndResize) but also hook the MoveWindow method for checking if we
need to setup a viewport for resolution change emulation.

Our resolution change emulation check if the windows origin matches
the monitors origin and the windows origin can also be changed by just
a move without being resized.

Also checking on a move becomes esp. important when we move to checking
on changes to the top-level non-window-manager client (X11)Window instead
of on changes to the xwl_window later on in this patch series.

Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

The recent change to use the top-level non-window-manager Window drawable
coordinates from xwl_window_check_resolution_change_emulation() in
combination with only calling it on a resize when the top-level window
is moved breaks things with mutter/gnome-shell.

When fullscreening a X11 window, mutter moves its window-decoration Window
wrapping the top-level Window to the monitor's origin coordinates (e.g. 0x0)
last. This updates the top-level's drawable coordinates, but as the
actual MoveWindow is called on the wrapper Window and not on the toplevel
we do not call xwl_window_check_resolution_change_emulation() and we never
enable the viewport.

This commit fixes this by also calling
xwl_window_check_resolution_change_emulation() if the Window being moved
is an xwl_window itself.

Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

When a reparented window is resized directly check the emulation instead of
doing this only when the window manager parent window is resized, what might
never happen.

For that to work we need to make sure that we compare the current size of the
client toplevel when looking for an emulated mode.

Changes by Hans de Goede:
- Remove xwl_window x, y, width and height members as those are no longer used.
- Add check for xwl_window_from_window() returning NULL.

Signed-off-by: Roman Gilg <subdiff@gmail.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Make window_get_none_wm_owner return the first non-wm-window instead of the
owner (client) of the first non-wm-window and rename it to
window_get_client_toplevel to match its new behavior.

This is a preparation patch for switching to using the drawable coordinates
in xwl_window_should_enable_viewport()

Changes by Hans de Goede:
- Split this change out into a separate patch for easier reviewing
- Rename window_get_none_wm_owner to window_get_client_toplevel to match
  its new behavior

Signed-off-by: Roman Gilg <subdiff@gmail.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>