Script 'mail_helper' called by obssrc Hello community, here is the log from the commit of package xwayland for openSUSE:Factory checked in at 2025-09-26 22:24:12 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Comparing /work/SRC/openSUSE:Factory/xwayland (Old) and /work/SRC/openSUSE:Factory/.xwayland.new.11973 (New) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "xwayland" Fri Sep 26 22:24:12 2025 rev:44 rq:1307067 version:24.1.8 Changes: -------- --- /work/SRC/openSUSE:Factory/xwayland/xwayland.changes 2025-06-23 14:56:38.424244174 +0200 +++ /work/SRC/openSUSE:Factory/.xwayland.new.11973/xwayland.changes 2025-09-26 22:24:49.974795615 +0200 @@ -1,0 +2,9 @@ +Thu Sep 25 08:37:02 UTC 2025 - Bjørn Lie <[email protected]> + +- Add upstream bugfix patches: + * U_randr_Do_not_leak_provider_property.patch + * U_xwayland_Dispatch_tablet_tool_tip_events.patch + * U_glamor_Fix_dual_blend_on_GLES3.patch + * U_xwayland_Dont_run_key_behaviors_and_actions.patch + +------------------------------------------------------------------- New: ---- U_glamor_Fix_dual_blend_on_GLES3.patch U_randr_Do_not_leak_provider_property.patch U_xwayland_Dispatch_tablet_tool_tip_events.patch U_xwayland_Dont_run_key_behaviors_and_actions.patch ----------(New B)---------- New: * U_xwayland_Dispatch_tablet_tool_tip_events.patch * U_glamor_Fix_dual_blend_on_GLES3.patch * U_xwayland_Dont_run_key_behaviors_and_actions.patch New:- Add upstream bugfix patches: * U_randr_Do_not_leak_provider_property.patch * U_xwayland_Dispatch_tablet_tool_tip_events.patch New: * U_randr_Do_not_leak_provider_property.patch * U_xwayland_Dispatch_tablet_tool_tip_events.patch * U_glamor_Fix_dual_blend_on_GLES3.patch New: * U_glamor_Fix_dual_blend_on_GLES3.patch * U_xwayland_Dont_run_key_behaviors_and_actions.patch ----------(New E)---------- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Other differences: ------------------ ++++++ xwayland.spec ++++++ --- /var/tmp/diff_new_pack.m87adS/_old 2025-09-26 22:24:50.798830303 +0200 +++ /var/tmp/diff_new_pack.m87adS/_new 2025-09-26 22:24:50.798830303 +0200 @@ -1,7 +1,7 @@ # # spec file for package xwayland # -# Copyright (c) 2025 SUSE LLC +# Copyright (c) 2025 SUSE LLC and contributors # # All modifications and additions to the file contributed by third parties # remain the property of their copyright owners, unless otherwise agreed @@ -31,6 +31,10 @@ Source0: %{url}/archive/individual/xserver/%{name}-%{version}.tar.xz Source1: %{url}/archive/individual/xserver/%{name}-%{version}.tar.xz.sig Source2: xwayland.keyring +Patch0: U_randr_Do_not_leak_provider_property.patch +Patch1: U_xwayland_Dispatch_tablet_tool_tip_events.patch +Patch2: U_glamor_Fix_dual_blend_on_GLES3.patch +Patch3: U_xwayland_Dont_run_key_behaviors_and_actions.patch BuildRequires: meson BuildRequires: ninja ++++++ U_glamor_Fix_dual_blend_on_GLES3.patch ++++++ >From 810fa68549225bad1f839fbce517e3fceb97f785 Mon Sep 17 00:00:00 2001 From: Icenowy Zheng <[email protected]> Date: Sat, 14 Dec 2024 01:07:31 +0800 Subject: [PATCH] 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 <[email protected]> (cherry picked from commit eba15f1ba75bc041d54693ebc62a8b9957b8b033) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2041> --- glamor/glamor_composite_glyphs.c | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/glamor/glamor_composite_glyphs.c b/glamor/glamor_composite_glyphs.c index 428303091d..13af727ffb 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, -- GitLab ++++++ U_randr_Do_not_leak_provider_property.patch ++++++ >From 9a6399682bc37ede3693d8873c485acaef6aa359 Mon Sep 17 00:00:00 2001 From: Olivier Fourdan <[email protected]> Date: Mon, 23 Jun 2025 15:34:14 +0200 Subject: [PATCH] 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 <[email protected]> (cherry picked from commit c34f59ee152def40343c68fbdc3ee8f71a0d9575) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2041> --- randr/rrproviderproperty.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/randr/rrproviderproperty.c b/randr/rrproviderproperty.c index 3deb0cbfdb..00e27556b1 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) { -- GitLab ++++++ U_xwayland_Dispatch_tablet_tool_tip_events.patch ++++++ >From 69e440a282ceb8d9d093fd69cf1fc5389c46a784 Mon Sep 17 00:00:00 2001 From: Vlad Zahorodnii <[email protected]> Date: Fri, 20 Jun 2025 15:59:55 +0300 Subject: [PATCH] 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 <[email protected]> (cherry picked from commit 60f0bfe852b988b3c4351483720e3c72c75f7405) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2041> --- hw/xwayland/xwayland-input.c | 26 +++++++++++++------------- hw/xwayland/xwayland-input.h | 5 +++-- 2 files changed, 16 insertions(+), 15 deletions(-) diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c index 53cc5144bb..d5bce37835 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 d40bca08a4..0a742f0179 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; -- GitLab ++++++ U_xwayland_Dont_run_key_behaviors_and_actions.patch ++++++ >From 482623371fe661cb1ce1565abfc38d2ba30a6f6e Mon Sep 17 00:00:00 2001 From: Julian Orth <[email protected]> Date: Sat, 11 Jan 2025 17:50:12 +0100 Subject: [PATCH] xwayland: Don't run key behaviors and actions Consider the following keymap: ```xkb xkb_keymap { xkb_keycodes { <compose> = 135; }; xkb_symbols { key <compose> { [ SetGroup(group = +1) ] }; }; }; ``` When the user presses the compose key, the following happens: 1. The compositor forwards the key to Xwayland. 2. Xwayland executes the SetGroup action and sets the base_group to 1 and the effective group to 1. 3. The compositor updates its own state and sends the effective group, 1, to Xwayland. 4. Xwayland sets the locked group to 1 and the effective group to 1 + 1 = 2. This is wrong since pressing compose should set the effective group to 1 but to X applications the effective group appears to be 2. This commit makes it so that Xwayland completely ignores the key behaviors and actions of the keymap and only updates the modifier and group components in response to the wayland modifiers events. Signed-off-by: Julian Orth <[email protected]> (cherry picked from commit 45c1d22ff6fe484b0088128a997e33b81bc8282d) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2060> --- hw/xwayland/xwayland-input.c | 7 +++++-- include/inputstr.h | 2 ++ xkb/xkbActions.c | 9 ++++++--- xkb/xkbPrKeyEv.c | 2 +- 4 files changed, 14 insertions(+), 6 deletions(-) diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c index d5bce37835..51efdb5fb8 100644 --- a/hw/xwayland/xwayland-input.c +++ b/hw/xwayland/xwayland-input.c @@ -1284,11 +1284,12 @@ keyboard_handle_modifiers(void *data, struct wl_keyboard *keyboard, old_state = dev->key->xkbInfo->state; new_state = &dev->key->xkbInfo->state; + new_state->base_group = 0; + new_state->latched_group = 0; new_state->locked_group = group & XkbAllGroupsMask; new_state->base_mods = mods_depressed & XkbAllModifiersMask; + new_state->latched_mods = mods_latched & XkbAllModifiersMask; new_state->locked_mods = mods_locked & XkbAllModifiersMask; - XkbLatchModifiers(dev, XkbAllModifiersMask, - mods_latched & XkbAllModifiersMask); XkbComputeDerivedState(dev->key->xkbInfo); @@ -1676,6 +1677,7 @@ add_device(struct xwl_seat *xwl_seat, dev->public.devicePrivate = xwl_seat; dev->type = SLAVE; dev->spriteInfo->spriteOwner = FALSE; + dev->ignoreXkbActionsBehaviors = TRUE; return dev; } @@ -3597,6 +3599,7 @@ InitInput(int argc, char *argv[]) mieqInit(); + inputInfo.keyboard->ignoreXkbActionsBehaviors = TRUE; xwl_screen->input_registry = wl_display_get_registry(xwl_screen->display); wl_registry_add_listener(xwl_screen->input_registry, &input_listener, xwl_screen); diff --git a/include/inputstr.h b/include/inputstr.h index 24dd48841e..269399e1d2 100644 --- a/include/inputstr.h +++ b/include/inputstr.h @@ -631,6 +631,8 @@ typedef struct _DeviceIntRec { DeviceSendEventsProc sendEventsProc; struct _SyncCounter *idle_counter; + + Bool ignoreXkbActionsBehaviors; /* TRUE if keys don't trigger behaviors and actions */ } DeviceIntRec; typedef struct { diff --git a/xkb/xkbActions.c b/xkb/xkbActions.c index 5e9a6b6d6e..8dd9d7da01 100644 --- a/xkb/xkbActions.c +++ b/xkb/xkbActions.c @@ -1368,9 +1368,12 @@ XkbHandleActions(DeviceIntPtr dev, DeviceIntPtr kbd, DeviceEvent *event) (event->type == ET_ButtonPress)); if (pressEvent) { - if (keyEvent) - act = XkbGetKeyAction(xkbi, &xkbi->state, key); - else { + if (keyEvent) { + if (kbd->ignoreXkbActionsBehaviors) + act.type = XkbSA_NoAction; + else + act = XkbGetKeyAction(xkbi, &xkbi->state, key); + } else { act = XkbGetButtonAction(kbd, dev, key); key |= BTN_ACT_FLAG; } diff --git a/xkb/xkbPrKeyEv.c b/xkb/xkbPrKeyEv.c index d2c7e33f42..53a31b7272 100644 --- a/xkb/xkbPrKeyEv.c +++ b/xkb/xkbPrKeyEv.c @@ -68,7 +68,7 @@ XkbProcessKeyboardEvent(DeviceEvent *event, DeviceIntPtr keybd) /* do anything to implement the behavior, but it *does* report that */ /* key is hardwired */ - if (!(behavior.type & XkbKB_Permanent)) { + if (!keybd->ignoreXkbActionsBehaviors && !(behavior.type & XkbKB_Permanent)) { switch (behavior.type) { case XkbKB_Default: /* Neither of these should happen in practice, but ignore them -- GitLab
