Currently, when started fullscreen, Xwayland rootful would use a default
resolution of "640x480" and apply a viewport to match the actual output
resolution.
That's quite counter intuitive, because when started fullscreen, one
would expect the default Xwayland root size to match the logical size
of the output where it is placed, unless of course, a geometry is
explicitly specified from the command line.
Fix the default resolution to be driven from the window size instead,
even when started fullscreen, so that one can start Xwayland rootful
and fullscreen and get the optimal resolution by default.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2196>
Xwayland does not support indirect GLX contexts and enabling them will
crash the xserver.
Refuse to start if indirect GLX contexts are enabled on the command
line.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1745>
The design document hw/xfree86/doc/ddxDesign.xml states that:
| AddScreen() should only fail because of programming errors or
| failure to allocate resources (like memory).
| All configuration problems should be detected BEFORE this point.
Different command line options errors are detected in xwl_screen_init()
and can cause AddScreen() to fail, which is not compliant with the
specification.
Move all command line checks out of xwl_screen_init() in a separate
function that will take care of verifying the command line options and
bail out with meaningful error messages.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1745>
Add a new commmand line option to enable the Xwayland
clipboard selection bridge when running in rootful mode.
By default, clipboard selection bridge is disabled to keep the default
of having Xwayland rootful running isolated from the rest of the
applications.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2139>
Commit 34934c37d6 restored calling register_damage() in
xwl_realize_window() before ensure_surface_for_window().
However if register_damage() succeeds and ensure_surface_for_window()
returns NULL, it would exit without "unregistering" the damage hook.
The X11 window, however, may still get damages reports, in which case
xwl_window_from_window() would return NULL, causing a NULL pointer
dereference in damage_report().
To avoid the issue, make sure we unregister the damage report if
ensure_surface_for_window() has failed, and add an early exit in
damage_report() if xwl_window is NULL.
v2: unregister_damage() unconditionally if ensure_surface_for_window()
failed (Michel Dänzer)
Fixes: commit 34934c37d6 ("revert: register damage before ensure_surface_for_window")
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/work_items/1886
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2190>
Commit 0e08e5083 ("xwayland: prevent X11 get enter event when pointer is
over Wayland client") introduced a pointer crossing count to avoid
sending spurious pointer enter events when the pointer is withing a
Wayland native surface.
However, that change breaks tablet devices, as the pointer enter count
is only updated from the wl_pointer enter/leave events, a slave X11
device such as a tablet pointer would report a lost focus and the event
wrongly sent to the root window.
To avoid the issue, revert partially commit 0e08e5083 to return FALSE
as before for the slave devices. The rest of the logic from commit
0e08e5083 remains unchanged, so that we do not send spurious
XCrossingEvents for the pointer device when it's within a native Wayland
surface.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/work_items/1884
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2180>
The window name buffer after XWDFileHeader is fixed at
XWD_WINDOW_NAME_LEN (60 bytes). sprintf could overflow when
hostname is close to maximum length and combined with the
prefix "Xvfb " + display + screen number.
Switch to snprintf to guarantee we never write beyond the
allocated buffer.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Mikhail Dmitrichenko <m.dmitrichenko222@gmail.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2172>
Now that the Intel driver is no longer the default case, we don't
need to maintain a long list of entries to override the default.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2168>
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../hw/vfb/InitOutput.c:416:13:
warning[-Wanalyzer-possible-null-dereference]:
dereference of possibly-NULL ‘ppix’
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2161>
When Xwayland is used rootful with hidpi, a viewport is in effect and a
scale applied.
This is however "transparent" to the Xserver which uses unscaled
coordinates, so to set the fake cursor position with a viewport and a
scale applied, we need to factor the scale to the coordinates before
passing the coordinate to the Wayland compositor through the method
zwp_locked_pointer_v1_set_cursor_position_hint().
Failing to do that will introduce a shift when warping the cursor
position.
v2: Use an xwl_window instead of an xwl_seat to improve readability
(Michel)
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1875
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2145>
There've been reports downstream of Xwayland segfaulting in the function
xwl_present_execute() because xwl_window_get_damage_region() returned an
invalid pointer:
#10 RegionUninit at ../include/regionstr.h:165
#11 RegionEmpty at ../include/regionstr.h:194
#12 xwl_present_execute at ../hw/xwayland/xwayland-present.c:1138
#13 xwl_present_pixmap at ../hw/xwayland/xwayland-present.c:1274
#14 present_pixmap at ../present/present.c:249
#15 proc_present_pixmap_common at ../present/present_request.c:166
#16 proc_present_pixmap at ../present/present_request.c:186
#17 Dispatch at ../dix/dispatch.c:550
#18 dix_main at ../dix/main.c:277
The most likely reason for this is that window_get_damage() returned
NULL, which might happen if xwl_window_update_surface_window() didn't
call register_damage().
To avoid that issue, move the call to register_damage() back to
xwl_realize_window before calling ensure_surface_for_window().
This reverts commit 07f6032627.
See-also: https://bugzilla.redhat.com/2329815
See-also: https://bugzilla.redhat.com/2428249
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1862
Signed-off-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2135>
Replaces Xwayland's server-specific implementation, but leaves Xorg's
since it sets global variables in the xfree86 ddx layer. Also leaves
Xephyr's differently-spelled "-verbosity" for backwards compatibility.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2131>
Changes message issued for too many clocks from the confusing:
"29.0" is not a valid keyword in this section.
to the more obvious:
More than 128 Clocks defined.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2130>
It will take some time for a new libpciaccess to be released and
even then bumping the dependency for libpciaccess isn't attractive.
If an older libpciaccess is used just add a static inline define.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2038>
Xwayland has no way to affect the keymap of the compositor. If clients
modify the keymap, it will stay out of sync with the compositor until
some unspecified time in the future when the compositor sends the keymap
again, which might be never, requiring Xwayland to be restarted.
Signed-off-by: Julian Orth <ju.orth@gmail.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1953>
The previous change is not enough, as WM_KILLFOCUS can apparently be
sent to the window losing focus after WM_ACTIVATE has been sent to
the window gaining focus.
Try using WM_SETFOCUS instead, as that has the correct ordering and seems
more logical.
The test "!pWin || !pWin->overrideRedirect" is confusingly written: It's
true if:
(a) pWin is NULL (= X window doesn't exist, shouldn't happen), or
(b) pWin->overrideRedirect is FALSE
i.e. the intended effect is "don't give focus to override redirect windows"
There seem to be some cases where this still isn't quite correct: A
reproduction isn't known, but it seems to be related to minimizing a
maximized Windows window, and having window activation move to a
maximized X window beneath it.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/736>
In the multiwindow WM, we need to cancel the X input focus if the
Windows input focus has gone to the desktop, or another application's
window.
We could maybe avoid some unneeded work by not doing this if the
WM_KILLFOCUS wParam is another window owned by us, which is immediately
going to be given the X input focus.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/736>
This version of the spec (latest as of 27.12.2021) adds a variable
`$XDG_STATE_HOME` that may be used for log files, as described:
```
...
$XDG_STATE_HOME defines the base directory relative to which user-specific
state files should be stored. If $XDG_STATE_HOME is either not set or
empty, a default equal to $HOME/.local/state should be used.
The $XDG_STATE_HOME contains state data that should persist between
(application) restarts, but that is not important or portable enough to
the user that it should be stored in $XDG_DATA_HOME. It may contain:
actions history (logs, history, recently used files, …)
...
```
- https://specifications.freedesktop.org/basedir/0.8/
Signed-off-by: Edênis Freindorfer Azevedo <edenisfa@gmail.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/836>
This change replaces the default "/dev/dri/card0" by a loop which
searches for the first compatible device.
This change avoids the error below which happens on some ARM boards:
(EE) No devices detected.
(EE)
Fatal server error:
(EE) no screens found(EE)
(EE)
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1496>
Present calls drmmode_set_mode_major() as part of ms_present_unflip(),
which leads to a crash due to the recursive attempt to force present to
unflip when it already is.
Fix it by simply skipping the forced present unflip when present itself is
unflipping. This also speeds up drmmmode_prepare_modeset() when present
isn't even flipping to begin with.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1791
Fixes: 899c87af1 ("modesetting: unflip before any setcrtc() calls")
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1793>
Use intel ddx only on pre-gen4 hw, newer ones will fall back to modesetting.
Instead of defaulting to the Intel driver for all Intel hardware, only
default it for older hardware for which it has shown to be better for.
Note that Debian/Fedora and their derivatives, as well as the yocto project
have been carrying this patch for many years:
192254841aee515e44b0
so this simply aligns xserver upstream with Linux distributions.
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Co-authored-by: Balló György <ballogyor@gmail.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1887>
