From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 56276C4363D for ; Tue, 6 Oct 2020 13:04:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0B03820FC3 for ; Tue, 6 Oct 2020 13:04:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726105AbgJFNEe (ORCPT ); Tue, 6 Oct 2020 09:04:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50830 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725891AbgJFNEd (ORCPT ); Tue, 6 Oct 2020 09:04:33 -0400 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e3e3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4A849C061755; Tue, 6 Oct 2020 06:04:33 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: andrzej.p) with ESMTPSA id 7ECB0299E5B Subject: Re: [PATCH v4 7/7] Input: Add "inhibited" property To: Dmitry Torokhov Cc: linux-pm@vger.kernel.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-input@vger.kernel.org, linux-tegra@vger.kernel.org, patches@opensource.cirrus.com, ibm-acpi-devel@lists.sourceforge.net, platform-driver-x86@vger.kernel.org, "Rafael J . Wysocki" , Len Brown , Jonathan Cameron , Hartmut Knaack , Lars-Peter Clausen , Peter Meerwald-Stadler , Kukjin Kim , Krzysztof Kozlowski , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Vladimir Zapolskiy , Sylvain Lemieux , Laxman Dewangan , Thierry Reding , Jonathan Hunter , Barry Song , Michael Hennerich , Nick Dyer , Hans de Goede , Ferruh Yigit , Sangwon Jee , Peter Hutterer , Henrique de Moraes Holschuh , kernel@collabora.com, Patrik Fimml References: <2336e15d-ff4b-bbb6-c701-dbf3aa110fcd@redhat.com> <20200608112211.12125-1-andrzej.p@collabora.com> <20200608112211.12125-8-andrzej.p@collabora.com> <20201005181014.GL1009802@dtor-ws> From: Andrzej Pietrasiewicz Message-ID: Date: Tue, 6 Oct 2020 15:04:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20201005181014.GL1009802@dtor-ws> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org Hi Dmitry, W dniu 05.10.2020 o 20:10, Dmitry Torokhov pisze: > Hi Andrzej, > > On Mon, Jun 08, 2020 at 01:22:11PM +0200, Andrzej Pietrasiewicz wrote: >> @@ -284,8 +284,11 @@ static int input_get_disposition(struct input_dev *dev, >> case EV_KEY: >> if (is_event_supported(code, dev->keybit, KEY_MAX)) { >> >> - /* auto-repeat bypasses state updates */ >> - if (value == 2) { >> + /* >> + * auto-repeat bypasses state updates but repeat >> + * events are ignored if the key is not pressed >> + */ >> + if (value == 2 && test_bit(code, dev->key)) { >> disposition = INPUT_PASS_TO_HANDLERS; >> break; >> } > > Is this chunk really part of inhibit support? I'd think we cancel > autorepeat timer when we are releasing a key, no? > When I look at it now it seems to me the chunk might be redundant. But let me explain what I had in mind when adding it. It is a matter of what we do with input events generated while a device is inhibited. If ->open()/->close() are not provided by the driver then inhibiting amounts to merely ignoring input events from a device while it remains active. What else can you do if the driver does not provide a method to prepare the device for generating events/ to stop generating events? In this special case a user might trigger a repeated event while the device is inhibited, then the user keeps holding the key down and the device is uninhibited. Do we pass anything to handlers then? In my opinion we should not. Such an event is "illegal" in a sense that it was generated at a time when nobody wanted any events from the device. Hence the test to let only those auto-repeat events through for which a key is actually pressed. However, what I see now is that if a device is inhibited, no key will ever reach neither the "1" nor "2" state because of the "if" in the very beginning of input_handle_event(). Regards, Andrzej