- Mar 22, 2023
-
-
Xwayland 23.1.0 final release Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com>
-
Olivier Fourdan authored
weston-info has been deprecated for quite some time, whereas wayland-info may not be available yet. So we use either, depending on what's actually available. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> (cherry picked from commit fc625fe1)
-
- Mar 09, 2023
-
-
Olivier Fourdan authored
Xwayland 23.1.0 release candidate 2. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com>
-
- Mar 08, 2023
-
-
Olivier Fourdan authored
Commit 3c07a01c (xwayland: Use xdg-output name for XRandR) changed the logic to use a fixed sized buffer allocated on the stack to pass to RROutputCreate() which would then copy it. Valgrind complains about this: == Conditional jump or move depends on uninitialised value(s) == at 0x49954B: MakeAtom (atom.c:87) == by 0x5108B3: RRMonitorCrtcName (rrmonitor.c:33) == by 0x510BBB: RRMonitorSetFromServer (rrmonitor.c:92) == by 0x511882: RRMonitorMakeList (rrmonitor.c:373) == by 0x512175: ProcRRGetMonitors (rrmonitor.c:634) == by 0x508091: ProcRRDispatch (randr.c:748) == by 0x4A860E: Dispatch (dispatch.c:546) == by 0x4B692F: dix_main (main.c:271) == by 0x431C90: main (stubmain.c:34) == Uninitialised value was created by a stack allocation == at 0x42122C: xwl_output_create (xwayland-output.c:816) This is actually harmless, but also simple to avoid by just initializing the content of the array with zeros, so let's just fix that. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Fixes: commit 3c07a01c - xwayland: Use xdg-output name for XRandR (cherry picked from commit 1209a1bb)
-
If we allocated with implicit modifiers, then we shouldn't use the modifier returned by gbm_bo when checking whether the modifier is supported or not, since it won't be if the compositor only advertises implicit modifiers, nor should we use the modifier when creating the Wayland buffer object, as it wasn't explicitly advertised. Fixes: c6f2598a ("xwayland: don't fall back to wl_drm with explicit modifier") Signed-off-by:
Jonas Ådahl <jadahl@gmail.com> (cherry picked from commit 4e20d96e)
-
Signed-off-by:
Jonas Ådahl <jadahl@gmail.com> (cherry picked from commit 9bd83c02)
-
This is preparing for cleaning up the macro mess. Signed-off-by:
Jonas Ådahl <jadahl@gmail.com> (cherry picked from commit af255b16)
-
If we're using implicit modifiers, we'll pass NULL and zero modifiers. Lets just use the legacy API directly instead. Signed-off-by:
Jonas Ådahl <jadahl@gmail.com> (cherry picked from commit 08b0ea09)
-
- Mar 03, 2023
-
-
To correctly render a window making use of SHAPE, a compositor must query the shape rectangles. This may not be a desirable feature for a Wayland compositor. Allow SHAPE to be turned off at runtime, so that the compositor can opt-out. Signed-off-by:
Simon Ser <contact@emersion.fr> (cherry picked from commit 21b3dad2)
-
The linux_dmabuf_v1 protocol doesn't guarantee any DRM node type: the compositor may send a primary node or a render node. Use drmDevice so that device comparisons are node-type-insensitive. Signed-off-by:
Simon Ser <contact@emersion.fr> Closes: xorg/xserver#1447 (cherry picked from commit 6f0b9dee)
-
Reviewed-by:
Olivier Fourdan <ofourdan@redhat.com> (cherry picked from commit 5a742ab8)
-
Olivier Fourdan authored
With wl_pointer.axis_v120 support, the wl_seat supported version has been bumped to 8, but Xwayland is still using MAP_SHARED which is prohibited, wl_seat version 7 and above enforces the use of MAP_PRIVATE for keymaps. Use MAP_PRIVATE for the keymaps mmap(). Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Closes: xorg/xserver#1512 Fixes: 3a02f56b - hook up wl_pointer.axis_v120 events (cherry picked from commit d5dd3f3c)
-
It's incorrect to strip an explicit modifier. Daniels' docs [1] states: > when importing a buffer, the user may supply `DRM_FORMAT_MOD_INVALID` as the > buffer modifier (or not supply a modifier) to indicate that the modifier is > unknown for whatever reason; this is only acceptable when the buffer has > not been allocated with an explicit modifier [1]: https://lore.kernel.org/dri-devel/20210905122742.86029-1-daniels@collabora.com/ Signed-off-by:
Simon Ser <contact@emersion.fr> (cherry picked from commit c6f2598a)
-
When the modifier is not supported by the compositor, and the DMA-BUF contains multiple planes, xwl_pixmap->buffer is NULL. Avoid crashing when calling wl_buffer_add_listener(). Signed-off-by:
Simon Ser <contact@emersion.fr> (cherry picked from commit 76a329e5)
-
Olivier Fourdan authored
With the addition of linux_dmabuf v4, the code adds dev_t in various places but did not include <sys/types.h>. While that works on glibc, it may fail to build on other libc implementations such as musl libc. Make sure to explicitly include <sys/types.h> where we use dev_t. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Closes: xorg/xserver#1445 Fixes: bddfe190 - Implement linux_dmabuf_feedback event handlers (cherry picked from commit 24171bb7)
-
- Feb 22, 2023
-
-
Olivier Fourdan authored
Xwayland 23.1.0 release candidate 1. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com>
-
- Feb 20, 2023
-
-
The increment sign wasn't taking into account when checking if the next value is past our current value. The result was that for negative increments, we kept looping indefinitely, locking up the server. Easiest to reproduce with the evdev driver which has a negative increment on the y axis. Fixes 0a22502c dix: switch scroll button emulation to multiples of increment Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit d2158d40)
-
- Feb 17, 2023
-
-
In preparation for a 23.1 release. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com>
-
(cherry picked from commit 001f0c89)
-
We're keeping it for unit tests, but we don't want to ship it from this branch. Also disable Xvfb in CI for ninja test. It's still built and used for unit tests as part of ninja dist, but we don't want to run XTS on Xvfb. (cherry picked from commit 0408fcb3)
-
Not used on this branch. (cherry picked from commit be7257c5)
-
Not used on this branch. (cherry picked from commit aa49cd5a)
-
(cherry picked from commit 9335ee79)
-
(cherry picked from commit 4f4b8e00)
-
(cherry picked from commit 69cc6a6c)
-
(cherry picked from commit 6cae4b39)
-
- Feb 16, 2023
-
-
The current algorithm triggers a bug in Xwayland when two devices have different granularity of scrolling. In Xwayland, the scroll increment is 1 and all physical devices scroll through the same (x)wayland pointer device. This may cause events to get lost when changing devices: - mouse scrolls by full increment, current value is 1.0 last scroll button was sent for valuator value 0.0, delta is 1.0 and we emulate a button event. - touchpad scrolls by partial increment, current value is 1.3 last scroll button was sent for valuator value 1.0, delta is 0.3 and no button event is emulated - mouse scrolls by full increment, current value is -0.7, last scroll button was sent for valuator value 1.0, delta is -0.7 and no button event is emulated Thus the wheel event appears to get lost. Xwayland cannot reliably detect this case because we don't see the physical devices. We can work around this by instead emulating buttons whenever we cross a multiple of increment. However, this has a drawback: high-resolution scroll devices can now trigger a button event storm by jittering across the multiple of increment. e.g. in the example above the touchpad moving from 1.3 to 1.0 would cause a click, despite this being a third of an increment. Fixes #1339 Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net> Acked-by:
Olivier Fourdan <ofourdan@redhat.com>
-
storeLastValuators() takes the index in the mask for the x and y axis. Completely pointless because any device that doesn't have x/y on 0 and 1, respectively, is going to break in fun ways anyway. And we only have two callers two this function, both of which hardcode 0 and 1. Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net>
-
- Feb 15, 2023
-
-
This enables fixing a deadlock case on the client side, where the client ends up blocked waiting for a Present event that will never come because the window was destroyed. The new PresentWindowDestroyed flag allows the client to avoid blocking indefinitely. Signed-off-by:
Adam Jackson <ajax@redhat.com> See-also: mesa/mesa#116 See-also: mesa/mesa#6685 Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com>
-
- Feb 13, 2023
-
-
This allows developers to setup Xwayland as a subproject of a Wayland compositor, and have it correctly pick up the features advertised in the dependency variables. Signed-off-by:
Simon Ser <contact@emersion.fr>
-
Remove the xwayland.pc.in file: - This avoids writing down each pkg-config variable twice: once in the Meson files to set the configuration data, once in the .pc.in file to print it. - We'll be able to re-use the same variables for use as a subproject. Signed-off-by:
Simon Ser <contact@emersion.fr>
-
Olivier Fourdan authored
If wl_output provides us with an output name, use that as well. If we have both xdg_output.name and wl_output.name (from version >= 4), prefer the latter. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com>#> See-also: wayland/wayland-protocols!189 Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com>
-
Olivier Fourdan authored
With the wl_output protocol, the actual bind to the interface is done in xwl_output_create(). Pass the version number from the registry so we can bind to the minimum version. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com>
-
Olivier Fourdan authored
Currently, Xwayland assigns sequential output names for XRandR. When an output is hotplugged, a new name is assigned sequentially (XWAYLAND0, XWAYLAND1, etc.). This is a problem because if a monitor is unplugged and plugged again, it will get a new name each time. Luckily, xdg-output provides us with a name for the outputs. Even though the protocol states that the name is not a reflection of the underlying DRM connector name, it is to remain consistent across sessions with the same hardware and software configuration. So we could use the xdg-output name for the XRandR reported name for the output. Doing so is a bit tricky though, because the output name is set at creation and is not supposed to change. The xdg-output event that provides us with the name will come at a later time. So we just allocate a default fixed size for the output name at creation and just replace the default output name with the xdg-output name when that is known. Also, historically, some X11 clients were expecting output names in Xwayland to be named XWAYLAND<x> and used that to check whether they were running on Xwayland. Those clients should now use the Xwayland X11 extension which is designed specifically for that purpose. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Closes: xorg/xserver#1353 See-also: xorg/xserver!954 Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com>
-
Olivier Fourdan authored
Since commit 204f10c2, we notify XRandR clients that the randr configuration has changes as soon as an new output is created. Yet, this might be premature, considering that at that point, we are still to receive the wl_output and xdg-output events that will most likely change the setup. So instead of calling RRTellChanged() from xwl_output_create(), wait until we get to call apply_output_change(), which occurs after the done events from both xdg-output and wl_output are received. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com>
-
Some drivers (e.g. AMD GFX8-) don't support explicit format modifiers. On these drivers, gbm_bo_create_with_modifiers() will fail. This results in "Error getting buffer" in the logs later on with all X11 windows staying invisible. Fallback to the modifier-less API gbm_bo_create() in that case. Signed-off-by:
Simon Ser <contact@emersion.fr>
-
Let's not give people any excuse for this spelling.
-