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=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,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 ABA47C433DF for ; Wed, 10 Jun 2020 13:52:33 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7B331207C3 for ; Wed, 10 Jun 2020 13:52:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="O9yR3wVC"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="RNgBmriM" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7B331207C3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=tGZ+hW9PmChuCi7wLxomCeznvCH2wDfuKaujb9t9KJc=; b=O9yR3wVChcMvHN4tOx4kMZYET s2Yl1uSI9UbecEMH+3Kx2ugdd2Mplj91T6XBzuvh2jvTJgl9FSQrZPI12HxLV0uVWFd7mUDLIDa8W K5ndEzv9fJbNijklmbcl8sNzGbt5Z5SWl87tCUoVYUXjf2X/xCDvapn/oPzeCABakjz/yKi5fmZsz 0gDoTvIjrtJ1uybwcxs6dFaZOcGQ04Yz572GSNtZoPU0bjFiuGMy4dOJfJT6DiouyT+LwmJR/cBUd m8v7xLVnvU3vmO04JjsV7/bTgFSMrMYLi2LBR8YCw9w+L4L9dKcJLnMC8XQlnjdisG8ucHRDX4URA nPeG4N5MA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jj19V-0000fL-6B; Wed, 10 Jun 2020 13:52:25 +0000 Received: from us-smtp-1.mimecast.com ([207.211.31.81] helo=us-smtp-delivery-1.mimecast.com) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jj19S-0000er-1a for linux-arm-kernel@lists.infradead.org; Wed, 10 Jun 2020 13:52:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591797140; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YL2CUX+ytcqKztbtjkEaTAotWFK6JYYqCnPu2fBEOuA=; b=RNgBmriM4ahFUxcS7Fg9c2XAKyovRc1vbF3yWBevYkrsDtYMZYq+0YkfnznkHE7+87EJiz 8cG3QCQqdrGNc0n8sVym0ptbpk5JY0AId2TxhStM8tX/tw86bzhGaE0OS+2A4XTehSFOHL SbVZ2Gna7dWtJJxjK6K+HwBkthAcMJ4= Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com [209.85.218.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-295-2_wIwCg6NFKGp-BQuPJqTw-1; Wed, 10 Jun 2020 09:52:18 -0400 X-MC-Unique: 2_wIwCg6NFKGp-BQuPJqTw-1 Received: by mail-ej1-f69.google.com with SMTP id hj12so1138123ejb.13 for ; Wed, 10 Jun 2020 06:52:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=YL2CUX+ytcqKztbtjkEaTAotWFK6JYYqCnPu2fBEOuA=; b=oSTQ40G3V4I4Z7D6Fm3yEOpkiFGK6eNDfHPCpCHOvHhV9Ey62iiW77w0ddZVHn9iQd qoEaU6yFmKaIg+5qgjqYlbzsOCjHrABgcjnYh0Ns6SEjdXrZ27fV5z5J/yzvwN176HGq Gh/GdFWKYOCX6VTPxvlA20rQhkca7S+PRWGhfaKYORscOZ1xFswULWBalL+Z+Ix99sxH rWXHhMYgViLuF83HVBwZkfk835vz5iHOptXD84Q7kZJHib/WEZm/8aiEJ8DBIMRJcxz/ bsCdUHdZRJMUmBk9wJa9EHOtPE1cNrQrcYz4eh1wyijEmunH6p83Lg8r8TJ77SPgtHwx ktMA== X-Gm-Message-State: AOAM530Pi0vtpXKgqBHegOkz5gEGc8ok6NfalzGmRo9Ltpojkn+DpYOG pOPBlGATrfrQCK1/m7jLeIdoCyvLYz6I30aXPWaY4L8+7Gal1dVOVWS09v1VQT3tsAY4z5nabhB mWsuhBEvdhz36ELzxcOjGyk/xzOXYZLLdm+M= X-Received: by 2002:a50:b2e1:: with SMTP id p88mr2582791edd.198.1591797137515; Wed, 10 Jun 2020 06:52:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxEJek1TXZYUkZ6pG2p869jbxR9ODYMKVkeJa1/sT8kaPG7Zk4zmYdct4EtD9GIM7FcH0rbNA== X-Received: by 2002:a50:b2e1:: with SMTP id p88mr2582761edd.198.1591797137192; Wed, 10 Jun 2020 06:52:17 -0700 (PDT) Received: from x1.localdomain (2001-1c00-0c0c-fe00-d2ea-f29d-118b-24dc.cable.dynamic.v6.ziggo.nl. [2001:1c00:c0c:fe00:d2ea:f29d:118b:24dc]) by smtp.gmail.com with ESMTPSA id dm1sm16655504ejc.99.2020.06.10.06.52.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 Jun 2020 06:52:16 -0700 (PDT) Subject: Re: [PATCH v4 0/7] Support inhibiting input devices To: "Rafael J. Wysocki" References: <2336e15d-ff4b-bbb6-c701-dbf3aa110fcd@redhat.com> <20200608112211.12125-1-andrzej.p@collabora.com> <964ca07a-3da5-101f-7edf-64bdeec98a4b@redhat.com> From: Hans de Goede Message-ID: Date: Wed, 10 Jun 2020 15:52:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200610_065222_313128_E6A3D0ED X-CRM114-Status: GOOD ( 27.48 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Collabora Kernel ML , Nick Dyer , linux-iio@vger.kernel.org, Platform Driver , ibm-acpi-devel@lists.sourceforge.net, Laxman Dewangan , Peter Meerwald-Stadler , Peter Hutterer , Fabio Estevam , Linux Samsung SoC , Krzysztof Kozlowski , Jonathan Hunter , ACPI Devel Maling List , Kukjin Kim , NXP Linux Team , linux-input@vger.kernel.org, Len Brown , Michael Hennerich , Linux PM , Sascha Hauer , Sylvain Lemieux , Henrique de Moraes Holschuh , Vladimir Zapolskiy , Lars-Peter Clausen , linux-tegra , Linux ARM , Barry Song , Ferruh Yigit , patches@opensource.cirrus.com, Dmitry Torokhov , "Rafael J . Wysocki" , Linux Kernel Mailing List , Andrzej Pietrasiewicz , Thierry Reding , Sangwon Jee , Pengutronix Kernel Team , Hartmut Knaack , Shawn Guo , Jonathan Cameron Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, On 6/10/20 12:38 PM, Rafael J. Wysocki wrote: > On Wed, Jun 10, 2020 at 11:50 AM Hans de Goede wrote: >> A different, but related issue is how to make devices actually use the >> new inhibit support on the builtin keyboard + touchpad when say the lid >> is closed. Arguably this is an userspace problem, but it is a tricky >> one. Currently on most modern Linux distributions suspend-on-lid-close >> is handled by systemd-logind and most modern desktop-environments are >> happy to have logind handle this for them. >> >> But most knowledge about input devices and e.g. heurisitics to decide >> if a touchpad is internal or external are part of libinput. Now we could >> have libinput use the new inhibit support (1), but then when the lid >> closes we get race between whatever process is using libinput trying >> to inhibit the touchpad (which must be done before to suspend to disable >> it as wakeup source) and logind trying to suspend the system. >> >> One solution here would be to move the setting of the inhibit sysfs >> attr into logind, but that requires adding a whole bunch of extra >> knowledge to logind which does not really belong there IMHO. >> >> I've been thinking a bit about this and to me it seems that the kernel >> is in the ideal position to automatically inhibit some devices when >> some EV_SW transitions from 0->1 (and uninhibit again on 1->0). The >> issue here is to chose on which devices to enable this. I believe >> that the auto inhibit on some switches mechanism is best done inside >> the kernel (disabled by default) and then we can have a sysfs >> attr called auto_inhibit_ev_sw_mask which can be set to e.g. >> (1 << SW_LID) to make the kernel auto-inhibit the input-device whenever >> the lid is closed, or to ((1 << SW_LID) | (1 << SW_TABLET_MODE)) to >> inhibit both when the lid is closed or when switched to tablet mode. > > I agree that the kernel is the right place to handle this, but it > requires some extra knowledge about dependencies between devices. > > It'd be kind of like power resources in ACPI, so for each state of a > "master" device (in principle, there may be more states of it than > just two) there would be a list of "dependent" intput devices that > need to be inhibited when the "master" device goes into that state. So a big part of the reason to punt the decision on which input devices to enable this auto-inhibit is that we don't really have information about those relationsships / device-links you are suggesting here. libinput is already doing inhibiting inside userspace for e.g. the tablet-mode switch but it relies on heuristics + quirk tables to decide which keyboards should be inhibited and which not. E.g. for a 360 degree hinges 2-in-1 we want to disable the builtin keyboard, when folded into in tablet mode, but not any external ones. Mostly the builtin kbd will be PS2 but I have one such 2-in-1 here in my home office with a USB kbd ... In general of the master devices there will be only 1, there will be only 1 lid switch and only 1 tablet-mode switch. So my idea with the auto_inhibit_ev_sw_mask, is for it to be a per input-device setting. So using your terms, all input devices with the (1 << SW_LID) bit set in their auto_inhibit_ev_sw_mask will be dependents of the (master) device which actually is reporting the SW_LID bit. The idea here is for this to work the same as how the rfkill code from net/rfkill/input.c works, except instead of binding e.g. KEY_WLAN to toggling the sw-state of rfkill devices with a type of RFKILL_TYPE_WLAN. This will bind SW_LID to inhibiting input devices with the SW_LID bit set in their auto_inhibit_ev_sw_mask. Regards, Hans _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel