Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#983675: wev: Emits "invalid version" error at startup and consumes 100% CPU

151 views
Skip to first unread message

Ben Harris

unread,
Feb 28, 2021, 5:50:03 AM2/28/21
to
Package: wev
Version: 1.0.0-2
Severity: important
X-Debbugs-Cc: bj...@bjh21.me.uk

Dear Maintainer,

When run with no arguments, "wev" emits an error message and then
hangs. "top" shows its CPU usage as 100.0% and on my laptop the fan
starts up suggesting a lot of CPU usage. The precise error message
depends on which Wayland compositor wev running under.

Under GNOME Shell (gnome-shell 3.38.3-2):

wl_registry@2: error 0: invalid version for global wl_seat (17): have 5, wanted 6

Under Weston (weston 9.0.0-2):

wl_registry@2: error 0: invalid version for global xdg_wm_base (18): have 1, wanted 2

I think that, even if wev can't run under a particular compositor, it
should not consume 100% of a CPU thread while doing so. I have tagged
this bug as "important" because it seems that this makes wev useless
under two major Wayland compositors.

-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages wev depends on:
ii libc6 2.31-9
ii libwayland-client0 1.18.0-2~exp1.1
ii libxkbcommon0 1.0.3-2

wev recommends no packages.

wev suggests no packages.

-- no debconf information

Dominique MARTINET

unread,
Oct 4, 2022, 10:40:03 PM10/4/22
to
I'd also like to use wev under weston.

For this particular error (invalid version for global xdg_wm_base (18):
have 1, wanted 2), we don't actually need xdg_wm_base version two in wev
(the only API we use here is xdg_wm_base_get_xdg_surface()) and the API
is backwards compatible, so just downgrading the requested version from
2 to 1 as follow fixes wev for me:

----
From bdbad4e1e58d090654e2f5e804659bb8709f2f45 Mon Sep 17 00:00:00 2001
From: Dominique Martinet <dominique...@atmark-techno.com>
Date: Wed, 5 Oct 2022 11:19:27 +0900
Subject: [PATCH] protocols: lower xdg_wm_base requirement to 1

We do not need anything in API v2, and using the older v1 API makes wev
work on weston <= 9

diff --git a/wev.c b/wev.c
index 9d25491ba4b5..b0e7005b166b 100644
--- a/wev.c
+++ b/wev.c
@@ -811,7 +811,7 @@ static void registry_global(void *data, struct wl_registry *wl_registry,
{ &wl_compositor_interface, 4, (void **)&state->compositor },
{ &wl_seat_interface, 6, (void **)&state->seat },
{ &wl_shm_interface, 1, (void **)&state->shm },
- { &xdg_wm_base_interface, 2, (void **)&state->wm_base },
+ { &xdg_wm_base_interface, 1, (void **)&state->wm_base },
{ &wl_data_device_manager_interface, 3,
(void **)&state->data_device_manager },
};
----

Note upgrading weston to version 10 or above would also fix the issue.

I'm not bothering to send this patch upstream as it would likely be
rejected (on the grounds of upstream weston already been upgraded), but
it would be great if we could add this patch to the debian stable
package.
(it's not needed for testing onwards, but it won't cause any harm there
either as far as I understand)


Thank you,
--
Dominique
0 new messages