xserver: Branch 'xwayland-24.1' - 3 commits

GitLab Mirror gitlab-mirror at kemper.freedesktop.org
Wed Jul 2 10:06:32 UTC 2025


 glamor/glamor_composite_glyphs.c |   22 +++++++++++++++++++++-
 hw/xwayland/xwayland-input.c     |   26 +++++++++++++-------------
 hw/xwayland/xwayland-input.h     |    5 +++--
 randr/rrproviderproperty.c       |    5 ++++-
 4 files changed, 41 insertions(+), 17 deletions(-)

New commits:
commit 810fa68549225bad1f839fbce517e3fceb97f785
Author: Icenowy Zheng <uwu at icenowy.me>
Date:   Sat Dec 14 01:07:31 2024 +0800

    glamor: Fix dual blend on GLES3
    
    The EXT_blend_func_extended extension on ESSL always requires explicit
    request to allow two FS out variables because of limitations of the ESSL
    language, which is mentioned as the No.6 issue of the extension's
    specification.
    
    Fix this by adding the extension request.
    
    The original behavior on GLES3 is slightly against the specification of
    GL_EXT_blend_func_extended extension, however Mesa and older version of
    PowerVR closed drivers will just ignore this issue. Newest PowerVR
    closed driver will bail out on this problem, so it deems a fix now.
    
    Fixes: ee107cd4911e ("glamor: support GLES3 shaders")
    Signed-off-by: Icenowy Zheng <uwu at icenowy.me>
    (cherry picked from commit eba15f1ba75bc041d54693ebc62a8b9957b8b033)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2041>

diff --git a/glamor/glamor_composite_glyphs.c b/glamor/glamor_composite_glyphs.c
index 428303091..13af727ff 100644
--- a/glamor/glamor_composite_glyphs.c
+++ b/glamor/glamor_composite_glyphs.c
@@ -178,6 +178,24 @@ glamor_glyph_add(struct glamor_glyph_atlas *atlas, DrawablePtr glyph_draw)
     return TRUE;
 }
 
+static const glamor_facet glamor_facet_composite_glyphs_es300 = {
+    .name = "composite_glyphs",
+    .version = 130,
+    .fs_extensions = ("#extension GL_EXT_blend_func_extended : enable\n"),
+    .vs_vars = ("in vec4 primitive;\n"
+                "in vec2 source;\n"
+                "out vec2 glyph_pos;\n"),
+    .vs_exec = ("       vec2 pos = primitive.zw * vec2(gl_VertexID&1, (gl_VertexID&2)>>1);\n"
+                GLAMOR_POS(gl_Position, (primitive.xy + pos))
+                "       glyph_pos = (source + pos) * ATLAS_DIM_INV;\n"),
+    .fs_vars = ("in vec2 glyph_pos;\n"
+                "out vec4 color0;\n"
+                "out vec4 color1;\n"),
+    .fs_exec = ("       vec4 mask = texture(atlas, glyph_pos);\n"),
+    .source_name = "source",
+    .locations = glamor_program_location_atlas,
+};
+
 static const glamor_facet glamor_facet_composite_glyphs_130 = {
     .name = "composite_glyphs",
     .version = 130,
@@ -454,7 +472,9 @@ glamor_composite_glyphs(CARD8 op,
                         if (glamor_glsl_has_ints(glamor_priv))
                             prog = glamor_setup_program_render(op, src, glyph_pict, dst,
                                                                glyphs_program,
-                                                               &glamor_facet_composite_glyphs_130,
+                                                               glamor_priv->is_gles ?
+                                                                   &glamor_facet_composite_glyphs_es300 :
+                                                                   &glamor_facet_composite_glyphs_130,
                                                                glamor_priv->glyph_defines);
                         else
                             prog = glamor_setup_program_render(op, src, glyph_pict, dst,
commit 69e440a282ceb8d9d093fd69cf1fc5389c46a784
Author: Vlad Zahorodnii <vlad.zahorodnii at kde.org>
Date:   Fri Jun 20 15:59:55 2025 +0300

    xwayland: Dispatch tablet tool tip events after frame events
    
    Xwayland dispatches tablet tool tip events immediately when they arrive.
    
    With compositors such as mutter and sway, it is not an issue because
    their libinput backends synthetize axis events before tip events. In
    other words, axis data and the tip status belong to different frames.
    
    On the other hand, kwin sends axis and tip events in a single frame
    (its libinput backend generates a single tip event with axis data
    attached to it). Since the tip events are dispatched immediately,
    they can have wrong information associated with them, for example tool
    position or pressure. It results in undesired "streaks" when the user
    presses the tablet tool against the tablet.
    
    See also https://bugs.kde.org/show_bug.cgi?id=479856.
    
    Signed-off-by: Vlad Zahorodnii <vlad.zahorodnii at kde.org>
    (cherry picked from commit 60f0bfe852b988b3c4351483720e3c72c75f7405)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2041>

diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
index 53cc5144b..d5bce3783 100644
--- a/hw/xwayland/xwayland-input.c
+++ b/hw/xwayland/xwayland-input.c
@@ -2183,22 +2183,17 @@ tablet_tool_down(void *data, struct zwp_tablet_tool_v2 *tool, uint32_t serial)
 {
     struct xwl_tablet_tool *xwl_tablet_tool = data;
     struct xwl_seat *xwl_seat = xwl_tablet_tool->seat;
-    ValuatorMask mask;
 
+    xwl_tablet_tool->tip = TRUE;
     xwl_seat->xwl_screen->serial = serial;
-
-    valuator_mask_zero(&mask);
-    QueuePointerEvents(xwl_tablet_tool->xdevice, ButtonPress, 1, 0, &mask);
 }
 
 static void
 tablet_tool_up(void *data, struct zwp_tablet_tool_v2 *tool)
 {
     struct xwl_tablet_tool *xwl_tablet_tool = data;
-    ValuatorMask mask;
 
-    valuator_mask_zero(&mask);
-    QueuePointerEvents(xwl_tablet_tool->xdevice, ButtonRelease, 1, 0, &mask);
+    xwl_tablet_tool->tip = FALSE;
 }
 
 static void
@@ -2321,7 +2316,7 @@ tablet_tool_button_state(void *data, struct zwp_tablet_tool_v2 *tool,
 {
     struct xwl_tablet_tool *xwl_tablet_tool = data;
     struct xwl_seat *xwl_seat = xwl_tablet_tool->seat;
-    uint32_t *mask = &xwl_tablet_tool->buttons_now;
+    uint32_t *mask = &xwl_tablet_tool->buttons;
     int xbtn = 0;
 
     /* BTN_0 .. BTN_9 */
@@ -2386,7 +2381,7 @@ tablet_tool_frame(void *data, struct zwp_tablet_tool_v2 *tool, uint32_t time)
 {
     struct xwl_tablet_tool *xwl_tablet_tool = data;
     ValuatorMask mask;
-    uint32_t released, pressed, diff;
+    uint32_t effective_buttons, released, pressed, diff;
     int button;
 
     valuator_mask_zero(&mask);
@@ -2402,9 +2397,14 @@ tablet_tool_frame(void *data, struct zwp_tablet_tool_v2 *tool, uint32_t time)
 
     valuator_mask_zero(&mask);
 
-    diff = xwl_tablet_tool->buttons_prev ^ xwl_tablet_tool->buttons_now;
-    released = diff & ~xwl_tablet_tool->buttons_now;
-    pressed = diff & xwl_tablet_tool->buttons_now;
+    effective_buttons = xwl_tablet_tool->buttons;
+    if (xwl_tablet_tool->tip) {
+        SetBit(&effective_buttons, 0);
+    }
+
+    diff = effective_buttons ^ xwl_tablet_tool->effective_buttons;
+    released = diff & ~effective_buttons;
+    pressed = diff & effective_buttons;
 
     button = 1;
     while (released) {
@@ -2424,7 +2424,7 @@ tablet_tool_frame(void *data, struct zwp_tablet_tool_v2 *tool, uint32_t time)
         pressed >>= 1;
     }
 
-    xwl_tablet_tool->buttons_prev = xwl_tablet_tool->buttons_now;
+    xwl_tablet_tool->effective_buttons = effective_buttons;
 
     while (xwl_tablet_tool->wheel_clicks) {
             if (xwl_tablet_tool->wheel_clicks < 0) {
diff --git a/hw/xwayland/xwayland-input.h b/hw/xwayland/xwayland-input.h
index d40bca08a..0a742f017 100644
--- a/hw/xwayland/xwayland-input.h
+++ b/hw/xwayland/xwayland-input.h
@@ -148,8 +148,9 @@ struct xwl_tablet_tool {
     double rotation;
     double slider;
 
-    uint32_t buttons_now,
-             buttons_prev;
+    uint32_t buttons;
+    Bool tip;
+    uint32_t effective_buttons;
 
     int32_t wheel_clicks;
 
commit 9a6399682bc37ede3693d8873c485acaef6aa359
Author: Olivier Fourdan <ofourdan at redhat.com>
Date:   Mon Jun 23 15:34:14 2025 +0200

    randr: Do not leak the provider property
    
    When changing the RandR provider property, if the property does not
    already exists, it is created.
    
    In case of error, however, it doesn't get freed, leading to a leak of
    the allocated property.
    
    Make sure to free the RandR property in case of error if was to be
    added.
    
    Found by OpenScanHub.
    
    Fixes: 3c3a4b767 - randr: Check for overflow in RRChangeProviderProperty()
    Signed-off-by: Olivier Fourdan <ofourdan at redhat.com>
    (cherry picked from commit c34f59ee152def40343c68fbdc3ee8f71a0d9575)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2041>

diff --git a/randr/rrproviderproperty.c b/randr/rrproviderproperty.c
index 3deb0cbfd..00e27556b 100644
--- a/randr/rrproviderproperty.c
+++ b/randr/rrproviderproperty.c
@@ -179,8 +179,11 @@ RRChangeProviderProperty(RRProviderPtr provider, Atom property, Atom type,
 
     if (mode == PropModeReplace || len > 0) {
         void *new_data = NULL, *old_data = NULL;
-        if (total_len > MAXINT / size_in_bytes)
+        if (total_len > MAXINT / size_in_bytes) {
+            if (add)
+                RRDestroyProviderProperty(prop);
             return BadValue;
+        }
         total_size = total_len * size_in_bytes;
         new_value.data = (void *) malloc(total_size);
         if (!new_value.data && total_size) {


More information about the xorg-commit mailing list