It was always the intention of the DRI2 protocol that there's at most
one instance of each attachment, and that's how it was implemented in
Mesa.
Since that wasn't enforced though, there might be other clients in the
wild which (e.g. accidentally) request the same attachment multiple
times. So starting to a raise a protocol error in this case now risks
breaking such clients.
Instead, just deduplicate the attachments using a bit-set.
This has a couple of desirable side effects:
* destroy_buffer cannot be called multiple times for the same
DRI2BufferPtr.
* The client cannot cause the server to allocate a buffers array with
more entries than there are attachments (currently 11).
Signed-off-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2228>
This works as intended — the (fake) front buffer needs to be added
only if the client didn't request it in the first place — even if the
client requests the same attachment multiple times. This ensures we
never try to access more than (count + 1) entries of the buffers array.
Fixes: ff6c7764c2 ("DRI2: Implement protocol for DRI2GetBuffersWithFormat")
Signed-off-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2228>
We use the pkgconfig file to indicate the availability of the command
line options, add the newly added clipboard option there as well.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2223>
registry_global() queues DRM lease devices before the root window is
available and initializes the queued entry immediately after malloc().
Return early on allocation failure to avoid dereferencing a NULL
pointer.
Signed-off-by: Mikhail Dmitrichenko <m.dmitrichenko222@gmail.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2217>
Xwayland initializes glamor on top of an EGL display, but some fatal
exit paths bypass the normal screen close sequence. In particular, this
can happen through xwl_give_up() after the Wayland compositor goes away,
or through ddxGiveUp() after early startup failures such as keymap
compilation failure.
A relevant excerpt from the ASan report:
Direct leak of 368 byte(s) in 1 object(s) allocated from:
#0 in calloc
#1 in dri2_display_create ../src/egl/drivers/dri2/egl_dri2.c:1014
#2 in dri2_initialize ../src/egl/drivers/dri2/egl_dri2.c:874
#3 in eglInitialize ../src/egl/main/eglapi.c:697
#4 in xwl_glamor_gbm_init_egl ../hw/xwayland/xwayland-glamor-gbm.c:1739
#5 in xwl_glamor_init ../hw/xwayland/xwayland-glamor.c:242
#6 in xwl_screen_init ../hw/xwayland/xwayland-screen.c:1121
#7 in AddScreen ../dix/dispatch.c:3999
#8 in InitOutput ../hw/xwayland/xwayland.c:437
#9 in dix_main ../dix/main.c:190
...
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 in calloc
#1 in _eglCreateArray ../src/egl/main/eglarray.c:69
#2 in _eglLinkConfig ../src/egl/main/eglconfig.c:85
#3 in dri2_add_config ../src/egl/drivers/dri2/egl_dri2.c:457
#4 in drm_add_configs_for_visuals ../src/egl/drivers/dri2/platform_drm.c:563
#5 in dri2_initialize_drm ../src/egl/drivers/dri2/platform_drm.c:706
#6 in dri2_initialize ../src/egl/drivers/dri2/egl_dri2.c:892
#7 in eglInitialize ../src/egl/main/eglapi.c:697
...
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>
