From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 29 05:33:34 2021 Received: (at 39341) by debbugs.gnu.org; 29 Apr 2021 09:33:34 +0000 Received: from localhost ([127.0.0.1]:54841 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lc338-0006gs-GH for submit@debbugs.gnu.org; Thu, 29 Apr 2021 05:33:34 -0400 Received: from eggs.gnu.org ([209.51.188.92]:54194) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lc331-0006gA-AS; Thu, 29 Apr 2021 05:33:29 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:39037) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lc32v-0003x6-0e; Thu, 29 Apr 2021 05:33:21 -0400 Received: from [2a01:e0a:19b:d9a0:9576:8bbf:4795:82ee] (port=37274 helo=meije) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lc32t-0005h1-BO; Thu, 29 Apr 2021 05:33:20 -0400 From: Mathieu Othacehe To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: bug#39341: Installer using 100% of a CPU core References: <87a766u9et.fsf@gmail.com> <87h7juf3dk.fsf@gnu.org> <20210426143225.fljn47jmgj5hhmra@pelzflorian.localdomain> <87fszdav22.fsf@gnu.org> <20210426161459.rfgxir2n5ya73vmv@pelzflorian.localdomain> <878s546mhs.fsf@gnu.org> <20210427123209.jyqw77edsbt5qhdj@pelzflorian.localdomain> <8735vbwh9q.fsf@gnu.org> <20210428070210.g3lntjoek5y6hyi7@pelzflorian.localdomain> <87sg3asexh.fsf@gnu.org> Date: Thu, 29 Apr 2021 11:33:17 +0200 In-Reply-To: <87sg3asexh.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Wed, 28 Apr 2021 15:43:06 +0200") Message-ID: <8735v91llu.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 39341 Cc: 39341@debbugs.gnu.org, 39341-done@debbugs.gnu.org, "pelzflorian \(Florian Pelz\)" , Maxim Cournoyer X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --=-=-= Content-Type: text/plain Hey Ludo, Your recent patch is just revealing an issue we always had with this Kmscon patch. Basically, without the "unlink" called you introduced, the FIFO fd was added only to the first discovered input and the keyboard layout was only applied to that very input. Conveniently, that input was always the main user keyboard I guess. The attached patch fixes that issue by registering the FIFO on the first input, but applying the keyboard layout to all the inputs. Thanks, Mathieu --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-gnu-kmscon-Fix-layout-setup.patch From 1a0fddd844ced62c802db0d6d133af45880435f0 Mon Sep 17 00:00:00 2001 From: Mathieu Othacehe Date: Thu, 29 Apr 2021 11:11:32 +0200 Subject: [PATCH] gnu: kmscon: Fix layout setup. Kmscon may discover multiple inputs, corresponding to multiple devices. This means that the uxkb_dev_keymap_update function may be called multiple times, and the FIFO is registered on each input poll loop. When a new layout is written on the FIFO by the installer, the first input picking up the message, will apply the new layout. However, that input may not be the input that the user is currently using. To fix it, register the FIFO on the first input poll loop, but apply the new layout on all the inputs in the uxkb_keymap_update_handler function. * gnu/packages/patches/kmscon-runtime-keymap-switch.patch (uxkb_keymap_update_handler): Apply the new layout to all the inputs. (uxkb_dev_keymap_update): Register the FIFO fd only on the first input poll loop. --- .../kmscon-runtime-keymap-switch.patch | 29 ++++++++++++++----- 1 file changed, 22 insertions(+), 7 deletions(-) diff --git a/gnu/packages/patches/kmscon-runtime-keymap-switch.patch b/gnu/packages/patches/kmscon-runtime-keymap-switch.patch index 480aaecad2..abff9c460d 100644 --- a/gnu/packages/patches/kmscon-runtime-keymap-switch.patch +++ b/gnu/packages/patches/kmscon-runtime-keymap-switch.patch @@ -132,7 +132,7 @@ index 925c755..8fe08f8 100644 #include #include "shl_hook.h" #include "shl_llog.h" -@@ -178,6 +181,95 @@ static void timer_event(struct ev_timer *timer, uint64_t num, void *data) +@@ -178,6 +181,110 @@ static void timer_event(struct ev_timer *timer, uint64_t num, void *data) shl_hook_call(dev->input->hook, dev->input, &dev->repeat_event); } @@ -171,7 +171,23 @@ index 925c755..8fe08f8 100644 + + llog_info(dev->input, "HANDLER CALLED %s|%s|%s\n", + model, layout, variant); -+ uxkb_desc_init(dev->input, model, layout, variant, options, NULL); ++ ++ struct uterm_input *input = dev->input; ++ struct shl_dlist *iter; ++ ++ /* Apply the new layout to all the inputs. */ ++ shl_dlist_for_each(iter, &input->devices) { ++ struct uterm_input_dev *dev; ++ dev = shl_dlist_entry(iter, ++ struct uterm_input_dev, ++ list); ++ uxkb_desc_init(dev->input, model, layout, variant, options, NULL); ++ dev->state = xkb_state_new(dev->input->keymap); ++ if (!dev->state) { ++ llog_error(dev->input, "cannot create XKB state"); ++ return; ++ } ++ } + + /* The client will now close the FIFO. Close it too, and re-create a + * FIFO so other clients can eventually connect. */ @@ -180,11 +196,6 @@ index 925c755..8fe08f8 100644 + dev->rupdate_fd = -1; + uxkb_dev_keymap_update(dev); + -+ dev->state = xkb_state_new(dev->input->keymap); -+ if (!dev->state) { -+ llog_error(dev->input, "cannot create XKB state"); -+ return; -+ } +} + +int uxkb_dev_keymap_update(struct uterm_input_dev *dev) @@ -193,6 +204,10 @@ index 925c755..8fe08f8 100644 + char *file; + int pid = getpid(); + ++ /* Add the FIFO fd only to the first input poll loop. */ ++ if (dev->rupdate_fd > 0) ++ return 0; ++ + ret = asprintf(&file, INPUT_KEYMAP_UPDATE_FILE, pid); + if (ret < 0) + return ret; -- 2.31.1 --=-=-=--