From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans de Goede Subject: Re: [PATCHv2 0/7] Support inhibiting input devices Date: Mon, 18 May 2020 09:36:28 +0200 Message-ID: <4eb8f557-370f-03bb-9a1d-3652d0ac8b08@redhat.com> References: <20200506002746.GB89269@dtor-ws> <20200515164943.28480-1-andrzej.p@collabora.com> <842b95bb-8391-5806-fe65-be64b02de122@redhat.com> <20200517225510.GA205823@koala> <20200518024034.GL89269@dtor-ws> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <20200518024034.GL89269@dtor-ws> Content-Language: en-US Sender: linux-acpi-owner@vger.kernel.org To: Dmitry Torokhov , Peter Hutterer Cc: Andrzej Pietrasiewicz , linux-input@vger.kernel.org, linux-acpi@vger.kernel.org, linux-iio@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@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 List-Id: linux-tegra@vger.kernel.org Hi, On 5/18/20 4:40 AM, Dmitry Torokhov wrote: > Hi Hans, Peter, > > On Mon, May 18, 2020 at 08:55:10AM +1000, Peter Hutterer wrote: >> On Fri, May 15, 2020 at 08:19:10PM +0200, Hans de Goede wrote: >>> Hi Andrezj, >>> >>> On 5/15/20 6:49 PM, Andrzej Pietrasiewicz wrote: >>>> Userspace might want to implement a policy to temporarily disregard input >>>> from certain devices, including not treating them as wakeup sources. >>>> >>>> An example use case is a laptop, whose keyboard can be folded under the >>>> screen to create tablet-like experience. The user then must hold the laptop >>>> in such a way that it is difficult to avoid pressing the keyboard keys. It >>>> is therefore desirable to temporarily disregard input from the keyboard, >>>> until it is folded back. This obviously is a policy which should be kept >>>> out of the kernel, but the kernel must provide suitable means to implement >>>> such a policy. >>> >>> Actually libinput already binds together (inside libinput) SW_TABLET_MODE >>> generating evdev nodes and e.g. internal keyboards on devices with 360° >>> hinges for this reason. libinput simply closes the /dev/input/event# >>> node when folded and re-opens it when the keyboard should become active >>> again. Thus not only suppresses events but allows e.g. touchpads to >>> enter runtime suspend mode which saves power. Typically closing the >>> /dev/input/event# node will also disable the device as wakeup source. >>> >>> So I wonder what this series actually adds for functionality for >>> userspace which can not already be achieved this way? >> >> Thanks Hans. To expand on this: >> libinput has heuristics to guess which input devices (keyboards, touchpads) >> are built-in ones. When the tablet mode switch is on, we disable these >> devices internally (this is not visible to callers), and re-enable it again >> later when the tablet mode switch is off again. > > I think that is great that libinput has tried solving this for the > tablet mode, but unfortunately libinput only works for users of > libinput, leaving cases such as: > > 1. In-kernel input handlers, such as SysRq, VT and others > 2. Systems that do not rely on libinput for userspace handing (Android, > Chrome OS) > 3. Systems with policies that are more complex than tablet mode only. > > Because of libinput's inability to affect the kernel, and the presence > of "always on" input handlers (sysrq, VT keyboard, potentially others), > while libinput may control whether consumers receive events from certain > input devices, it will not allow power savings that an explicit > "inhibit" allows when coming from dedicated power policy manager. Ok, the sysrq and vt keyboard handlers keeping the device open and thus make it keep using power is a valid reason for a separate inhibit mechanism. > I think pushing policy decisions into a library, and trying to have all > clients agree with it, is much harder and leaks unnecessary knowledge > into quite a few layers. A dedicated power policy manager, that is not > only responsible for input device, but power state of the system as a > whole, is a very viable architecture. Well AFAIK the kernel-policy has always been to leave policy decisions up to userspace as much as possible, but this just adds a mechanism to implement the policy so that is fine. >> This is done for keyboards and touchpads atm (and I think pointing sticks) >> and where the heuristics fail we have extra quirks in place. For example >> the Lenovo Yogas tend to disable the keyboard mechanically in tablet mode >> but buttons (e.g. volume keys) around the screen send events through the >> same event node. So on those devices we don't disable the keyboard. >> >> We've had this code for a few years now and the only changes to it have been >> the various device quirks for devices that must not suspend the keyboard, >> it's otherwise working as expected. >> >> If we ever have a device where we need to disable parts of the keyboard >> only, we could address this with EVIOCSMASK but so far that hasn't been >> necessary. >> >> I agree with Hans, right now I don't see the usefulness of this new sysfs >> toggle. For it to be really useful you'd have to guarantee that it's >> available for 100% of the devices and that's IMO unlikely to happen. > > The inhibiting of the events works for 100% of input devices, the power > savings work for the ones that implement it. It is responsibility of > folds shipping the systems to make sure drivers they use support inhibit > if they believe it will help their battery life. > >> >> Cheers, >> Peter >> >>> I also noticed that you keep the device open (do not call the >>> input_device's close callback) when inhibited and just throw away >>> any events generated. This seems inefficient and may lead to >>> the internal state getting out of sync. What if a key is pressed >>> while inhibited and then the device is uninhibited while the key >>> is still pressed? Now the press event is lost and userspace >>> querying the current state will see the pressed key as being >>> released. > > This is a good point. We should look into signalling that some events > have been dropped (via EV_SYN/SYN_DROPPED) so that clients are aware of > it. > >>> >>> On top of this you add special inhibit and uninhibit callbacks >>> and implement those for just a few devices. How do these differ >>> from just closing the device and later opening it again ? > > I believe majority will simply reuse open/close callbacks. In Chrome OS > we have dedicated inhibit/uninhibit, but I would like to allow using > open/close as alternatives. Ack, maybe some driver flag to just call close on inhibit and open on unhibit (also taking input_device.users into account of course) ? >>> Also using a sysfs property for this is very weird given that the >>> rest of the evdev interface is using ioctls for everything... > > This is not evdev interface, it is at the level above evdev (so that it > can affect all handlers, not only evdev). As such it is not bound by > evdev interface. Ok I can see how on some systems the process implementing the policy of when to inhibit would be separate from the process which has the device open. But in e.g. the libinput case it would be good if libinput could activate any potential power-savings by setting the inhibit flag. The problem with sysfs interfaces is that they typically require root rights and that they are not really compatible with FD passing. libinput runs as a normal user, getting a fd to the /dev/input/event# node passed by systemd-logind. As said I can see the reason for wanting a sysfs attribute for this, can we perhaps have both a sysfs interface and an ioctl? Note both could share the same boolean in the kernel, it would be up to userspace to not try and write to both. E.g. chrome-os would use the sysfs attr, libinput would use the ioctl. Regards, Hans 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.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 D1A63C433E0 for ; Mon, 18 May 2020 07:36:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A07A420715 for ; Mon, 18 May 2020 07:36:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="arMuVYrw" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727012AbgERHgh (ORCPT ); Mon, 18 May 2020 03:36:37 -0400 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:56467 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726895AbgERHgg (ORCPT ); Mon, 18 May 2020 03:36:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1589787393; 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=lxahqT/LB/gKtsCv/S2+hQFfwmIb9ycLMKz+VyULbsI=; b=arMuVYrwCqfWoMDXL0PHyDHQhX4zwsTpG5PkOK7kDR1DpeGnX69jpk+w7/PonKT4UDTKSr 0CkPxQADIIMMBKBzRt1NtooS3651AuLH+0ZYfbAz82scX32ghWWPpuraE45M2Fz3frhFWY PyDP41/J+ldqtwzP06GHCtoDt/W0SQ0= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-458-Thp3nS2wN9uM1gLQpcNmiQ-1; Mon, 18 May 2020 03:36:31 -0400 X-MC-Unique: Thp3nS2wN9uM1gLQpcNmiQ-1 Received: by mail-wr1-f69.google.com with SMTP id y7so5220909wrd.12 for ; Mon, 18 May 2020 00:36:31 -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=lxahqT/LB/gKtsCv/S2+hQFfwmIb9ycLMKz+VyULbsI=; b=iOyrJ02FGxq80U6qqb6cOMfmqM2NrMYweB1uQKhQqwoFN38AaWC+XKDUVxPqaozB1F hNs8nxGJTT/Ka7nAcjHQpG9uR4q4t4eC7mC4SZqQhVRQrap/FJmdTjyqDEKNTSa9BYmI s2R9yUj1X2e257EfT1bUGDdIlHGaG56Rv/UMlOoy/340HYz42SRLh4uhHl6u2o77mni/ QrxV1isMTU8vvQg2NgXD5oa+ippYmr8AQ2qLiQEKLME9moW86PiZWECcedrehqqw6S7a +EjFb8/zl42MSwNjZMgmPMTF77KbX/t7J0m/53vQ/7fjE+FMhsjtQl6DSqFRnclJArdD OCxw== X-Gm-Message-State: AOAM533qPGg6jgDRCyhbQ6OLH2PsftlCu8AkNsxwP9Cl9rqtigZvH1pf /D3paqvFXB5fI0K5IK1Rz+2prMon/uIxPRAbNHC5ybnpPrPH6aV918HEY48xHtQxPePCPr/yFEw /5CsA0GKzDj22hVCNrdDeeQ== X-Received: by 2002:adf:eb47:: with SMTP id u7mr8924136wrn.14.1589787390562; Mon, 18 May 2020 00:36:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzz0SpVMXYaTfwKekGOfJXbmR9UFXcUMo3vR6hnkieQoqI8Z+UsfvdG56sJulcbF8oH7Hmmxg== X-Received: by 2002:adf:eb47:: with SMTP id u7mr8924093wrn.14.1589787390194; Mon, 18 May 2020 00:36:30 -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 f123sm15586970wmf.44.2020.05.18.00.36.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 May 2020 00:36:29 -0700 (PDT) Subject: Re: [PATCHv2 0/7] Support inhibiting input devices To: Dmitry Torokhov , Peter Hutterer Cc: Andrzej Pietrasiewicz , linux-input@vger.kernel.org, linux-acpi@vger.kernel.org, linux-iio@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@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 , Ferruh Yigit , Sangwon Jee , Henrique de Moraes Holschuh , kernel@collabora.com, Peter Hutterer , Benjamin Tissoires References: <20200506002746.GB89269@dtor-ws> <20200515164943.28480-1-andrzej.p@collabora.com> <842b95bb-8391-5806-fe65-be64b02de122@redhat.com> <20200517225510.GA205823@koala> <20200518024034.GL89269@dtor-ws> From: Hans de Goede Message-ID: <4eb8f557-370f-03bb-9a1d-3652d0ac8b08@redhat.com> Date: Mon, 18 May 2020 09:36:28 +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: <20200518024034.GL89269@dtor-ws> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org Hi, On 5/18/20 4:40 AM, Dmitry Torokhov wrote: > Hi Hans, Peter, > > On Mon, May 18, 2020 at 08:55:10AM +1000, Peter Hutterer wrote: >> On Fri, May 15, 2020 at 08:19:10PM +0200, Hans de Goede wrote: >>> Hi Andrezj, >>> >>> On 5/15/20 6:49 PM, Andrzej Pietrasiewicz wrote: >>>> Userspace might want to implement a policy to temporarily disregard input >>>> from certain devices, including not treating them as wakeup sources. >>>> >>>> An example use case is a laptop, whose keyboard can be folded under the >>>> screen to create tablet-like experience. The user then must hold the laptop >>>> in such a way that it is difficult to avoid pressing the keyboard keys. It >>>> is therefore desirable to temporarily disregard input from the keyboard, >>>> until it is folded back. This obviously is a policy which should be kept >>>> out of the kernel, but the kernel must provide suitable means to implement >>>> such a policy. >>> >>> Actually libinput already binds together (inside libinput) SW_TABLET_MODE >>> generating evdev nodes and e.g. internal keyboards on devices with 360° >>> hinges for this reason. libinput simply closes the /dev/input/event# >>> node when folded and re-opens it when the keyboard should become active >>> again. Thus not only suppresses events but allows e.g. touchpads to >>> enter runtime suspend mode which saves power. Typically closing the >>> /dev/input/event# node will also disable the device as wakeup source. >>> >>> So I wonder what this series actually adds for functionality for >>> userspace which can not already be achieved this way? >> >> Thanks Hans. To expand on this: >> libinput has heuristics to guess which input devices (keyboards, touchpads) >> are built-in ones. When the tablet mode switch is on, we disable these >> devices internally (this is not visible to callers), and re-enable it again >> later when the tablet mode switch is off again. > > I think that is great that libinput has tried solving this for the > tablet mode, but unfortunately libinput only works for users of > libinput, leaving cases such as: > > 1. In-kernel input handlers, such as SysRq, VT and others > 2. Systems that do not rely on libinput for userspace handing (Android, > Chrome OS) > 3. Systems with policies that are more complex than tablet mode only. > > Because of libinput's inability to affect the kernel, and the presence > of "always on" input handlers (sysrq, VT keyboard, potentially others), > while libinput may control whether consumers receive events from certain > input devices, it will not allow power savings that an explicit > "inhibit" allows when coming from dedicated power policy manager. Ok, the sysrq and vt keyboard handlers keeping the device open and thus make it keep using power is a valid reason for a separate inhibit mechanism. > I think pushing policy decisions into a library, and trying to have all > clients agree with it, is much harder and leaks unnecessary knowledge > into quite a few layers. A dedicated power policy manager, that is not > only responsible for input device, but power state of the system as a > whole, is a very viable architecture. Well AFAIK the kernel-policy has always been to leave policy decisions up to userspace as much as possible, but this just adds a mechanism to implement the policy so that is fine. >> This is done for keyboards and touchpads atm (and I think pointing sticks) >> and where the heuristics fail we have extra quirks in place. For example >> the Lenovo Yogas tend to disable the keyboard mechanically in tablet mode >> but buttons (e.g. volume keys) around the screen send events through the >> same event node. So on those devices we don't disable the keyboard. >> >> We've had this code for a few years now and the only changes to it have been >> the various device quirks for devices that must not suspend the keyboard, >> it's otherwise working as expected. >> >> If we ever have a device where we need to disable parts of the keyboard >> only, we could address this with EVIOCSMASK but so far that hasn't been >> necessary. >> >> I agree with Hans, right now I don't see the usefulness of this new sysfs >> toggle. For it to be really useful you'd have to guarantee that it's >> available for 100% of the devices and that's IMO unlikely to happen. > > The inhibiting of the events works for 100% of input devices, the power > savings work for the ones that implement it. It is responsibility of > folds shipping the systems to make sure drivers they use support inhibit > if they believe it will help their battery life. > >> >> Cheers, >> Peter >> >>> I also noticed that you keep the device open (do not call the >>> input_device's close callback) when inhibited and just throw away >>> any events generated. This seems inefficient and may lead to >>> the internal state getting out of sync. What if a key is pressed >>> while inhibited and then the device is uninhibited while the key >>> is still pressed? Now the press event is lost and userspace >>> querying the current state will see the pressed key as being >>> released. > > This is a good point. We should look into signalling that some events > have been dropped (via EV_SYN/SYN_DROPPED) so that clients are aware of > it. > >>> >>> On top of this you add special inhibit and uninhibit callbacks >>> and implement those for just a few devices. How do these differ >>> from just closing the device and later opening it again ? > > I believe majority will simply reuse open/close callbacks. In Chrome OS > we have dedicated inhibit/uninhibit, but I would like to allow using > open/close as alternatives. Ack, maybe some driver flag to just call close on inhibit and open on unhibit (also taking input_device.users into account of course) ? >>> Also using a sysfs property for this is very weird given that the >>> rest of the evdev interface is using ioctls for everything... > > This is not evdev interface, it is at the level above evdev (so that it > can affect all handlers, not only evdev). As such it is not bound by > evdev interface. Ok I can see how on some systems the process implementing the policy of when to inhibit would be separate from the process which has the device open. But in e.g. the libinput case it would be good if libinput could activate any potential power-savings by setting the inhibit flag. The problem with sysfs interfaces is that they typically require root rights and that they are not really compatible with FD passing. libinput runs as a normal user, getting a fd to the /dev/input/event# node passed by systemd-logind. As said I can see the reason for wanting a sysfs attribute for this, can we perhaps have both a sysfs interface and an ioctl? Note both could share the same boolean in the kernel, it would be up to userspace to not try and write to both. E.g. chrome-os would use the sysfs attr, libinput would use the ioctl. Regards, Hans 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,URIBL_BLOCKED,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 5938EC433DF for ; Mon, 18 May 2020 07:36:59 +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 271A120715 for ; Mon, 18 May 2020 07:36:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="lwecSyvI"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="dneOSLRo"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="arMuVYrw"; dkim=neutral (0-bit key) header.d=redhat.com header.i=@redhat.com header.b="ZyisDmrW" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 271A120715 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=Qa9h+z69i28Qqf7+nLg2bTcjV4kR7ehB8fbduFpacU8=; b=lwecSyvIlIve0bH2kTaOOxAzz ZfJqNeSHIfRM48ofX1SBWzRZkxpP1hJRizV+cH8P6wssP0cXC8zPW70nlKvHCll11XEFMe/nznudf QrPHKCNaxuk6BbCooTuz7E6d8RCSIlmJFgRF16SMspd/Kw4Y+EF7xf9o3xnRox1ZutKCr2qBJQVC7 asf+R0b70Fidgo63PynweKjbWcFByNUk0IqTXGjbpw+g4E6WV6DNDs/aB4q2aBR19GfkeNdIOyWcF 8mGfg+EM885P/2TMZYZCJ7XEC2qYaxRbomZtxvok17C8oeGMqwQAX5usSFeNk0h8BO6KKJT4hYsmk el6Htos5g==; 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 1jaaKY-0005SK-Qd; Mon, 18 May 2020 07:36:58 +0000 Received: from merlin.infradead.org ([205.233.59.134]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jaaKW-0005S0-ON for linux-arm-kernel@bombadil.infradead.org; Mon, 18 May 2020 07:36:56 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description; bh=lxahqT/LB/gKtsCv/S2+hQFfwmIb9ycLMKz+VyULbsI=; b=dneOSLRobyVVLViiaYLaNc8plh pZTxsWrSonKrDZh38H89Ufw8i6h3sho38B7AmgZL6d6clyMHneB4EFLcJvwRYwSA8/X2RJIU0uuAz Y31sR5Shh6YYZaaMcuha8cMneAMglF9kFk9UheGS5xFGo0/KS+FJcunTrYlWIMOiWE81qeoQHARbB Gr9r3ksjeO5voL0/qgERN7fEzJrA8v2Mhhg70nZ6q5NiG51HqfWSNmHn+xVVpAcLnwmVsJ/b/i/ZE gRmpYPWpONzzyeZiOi4blFP+CaiKa6vH4r5FFL947VoygISuX5G0rzrYTQRGdoyd0XwTGlGJPGWG6 dJvYm3Dw==; Received: from us-smtp-1.mimecast.com ([207.211.31.81] helo=us-smtp-delivery-1.mimecast.com) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jaaKT-0002Oo-M3 for linux-arm-kernel@lists.infradead.org; Mon, 18 May 2020 07:36:56 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1589787393; 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=lxahqT/LB/gKtsCv/S2+hQFfwmIb9ycLMKz+VyULbsI=; b=arMuVYrwCqfWoMDXL0PHyDHQhX4zwsTpG5PkOK7kDR1DpeGnX69jpk+w7/PonKT4UDTKSr 0CkPxQADIIMMBKBzRt1NtooS3651AuLH+0ZYfbAz82scX32ghWWPpuraE45M2Fz3frhFWY PyDP41/J+ldqtwzP06GHCtoDt/W0SQ0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1589787411; 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=lxahqT/LB/gKtsCv/S2+hQFfwmIb9ycLMKz+VyULbsI=; b=ZyisDmrWQkQcNn8Z4Ft+XW5LxooAVL36qDH2z/jWjWi3TZ+J3pKfUwVXqNGkmEjpNOl0kM 9YfXT4jMYRWBdmt3K3fFyXzHkuQbg8JaxHi+WtizTkkxI/O2H/A9Q+hXkZ8stLc+EV4zMp kT1wH9Ubg5btBEGp5WS3fbeuzrqC8yY= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-37-hriNnyZRMVuHx-UlkZ4-yg-1; Mon, 18 May 2020 03:36:31 -0400 X-MC-Unique: hriNnyZRMVuHx-UlkZ4-yg-1 Received: by mail-wr1-f72.google.com with SMTP id h12so5217512wrr.19 for ; Mon, 18 May 2020 00:36:31 -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=lxahqT/LB/gKtsCv/S2+hQFfwmIb9ycLMKz+VyULbsI=; b=SpvQ1XXqojiZg3f6EytBjYhzpcmCK0jLPvPlaLZqR63xZU175AqszLa/XKbCC7JDXC EZQtA5GBmAu7bid9wb+pqMsKOfKxCLhxOusKsMaMC94HyEBwzVxfbhKfEAdTN01WGCM/ Odwts1VAJT5w8Sk9Ym9C1I7fzlmNp8rPhr18g4Cj023W/1xBCu3e4uq/PmPtLh9O/68L evbqRj2UPo9K76C1K9aTBKv6RiHlQEG+hoOgwxjC5lDHp766OJS7GbLAbp7GkFFhpgEW uU5bd2cXeO6VxeN+obvUDWMg6nNIbzwaDezSRnAeb+UrhZm/JG3VZHIAoe1UpjE195IH 0HoQ== X-Gm-Message-State: AOAM532XrtUwc4K56f0YaYZkb+lqejFR//BkDtI+aRA8RuHTwD2/7szh BqMtzjtVm/PzJVv6EjrD30+SAnfx7ljA+Veuj8bPhse8nRVALl/pbbVE6iM0zUChaoZBJI9cs6U iDC/uV3vlrDq+Rk1U80k4LEn3ueVRHbSrorM= X-Received: by 2002:adf:eb47:: with SMTP id u7mr8924125wrn.14.1589787390561; Mon, 18 May 2020 00:36:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzz0SpVMXYaTfwKekGOfJXbmR9UFXcUMo3vR6hnkieQoqI8Z+UsfvdG56sJulcbF8oH7Hmmxg== X-Received: by 2002:adf:eb47:: with SMTP id u7mr8924093wrn.14.1589787390194; Mon, 18 May 2020 00:36:30 -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 f123sm15586970wmf.44.2020.05.18.00.36.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 May 2020 00:36:29 -0700 (PDT) Subject: Re: [PATCHv2 0/7] Support inhibiting input devices To: Dmitry Torokhov , Peter Hutterer References: <20200506002746.GB89269@dtor-ws> <20200515164943.28480-1-andrzej.p@collabora.com> <842b95bb-8391-5806-fe65-be64b02de122@redhat.com> <20200517225510.GA205823@koala> <20200518024034.GL89269@dtor-ws> From: Hans de Goede Message-ID: <4eb8f557-370f-03bb-9a1d-3652d0ac8b08@redhat.com> Date: Mon, 18 May 2020 09:36:28 +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: <20200518024034.GL89269@dtor-ws> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com 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: Nick Dyer , linux-iio@vger.kernel.org, Benjamin Tissoires , platform-driver-x86@vger.kernel.org, ibm-acpi-devel@lists.sourceforge.net, Laxman Dewangan , Peter Meerwald-Stadler , kernel@collabora.com, Fabio Estevam , linux-samsung-soc@vger.kernel.org, Krzysztof Kozlowski , Jonathan Hunter , linux-acpi@vger.kernel.org, Kukjin Kim , NXP Linux Team , linux-input@vger.kernel.org, Len Brown , Peter Hutterer , Michael Hennerich , Sascha Hauer , Sylvain Lemieux , Henrique de Moraes Holschuh , Vladimir Zapolskiy , Lars-Peter Clausen , linux-tegra@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Barry Song , Ferruh Yigit , patches@opensource.cirrus.com, "Rafael J . Wysocki" , Andrzej Pietrasiewicz , Thierry Reding , Sangwon Jee , Pengutronix Kernel Team , Hartmut Knaack , Shawn Guo , Jonathan Cameron Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org SGksCgpPbiA1LzE4LzIwIDQ6NDAgQU0sIERtaXRyeSBUb3Jva2hvdiB3cm90ZToKPiBIaSBIYW5z LCBQZXRlciwKPiAKPiBPbiBNb24sIE1heSAxOCwgMjAyMCBhdCAwODo1NToxMEFNICsxMDAwLCBQ ZXRlciBIdXR0ZXJlciB3cm90ZToKPj4gT24gRnJpLCBNYXkgMTUsIDIwMjAgYXQgMDg6MTk6MTBQ TSArMDIwMCwgSGFucyBkZSBHb2VkZSB3cm90ZToKPj4+IEhpIEFuZHJlemosCj4+Pgo+Pj4gT24g NS8xNS8yMCA2OjQ5IFBNLCBBbmRyemVqIFBpZXRyYXNpZXdpY3ogd3JvdGU6Cj4+Pj4gVXNlcnNw YWNlIG1pZ2h0IHdhbnQgdG8gaW1wbGVtZW50IGEgcG9saWN5IHRvIHRlbXBvcmFyaWx5IGRpc3Jl Z2FyZCBpbnB1dAo+Pj4+IGZyb20gY2VydGFpbiBkZXZpY2VzLCBpbmNsdWRpbmcgbm90IHRyZWF0 aW5nIHRoZW0gYXMgd2FrZXVwIHNvdXJjZXMuCj4+Pj4KPj4+PiBBbiBleGFtcGxlIHVzZSBjYXNl IGlzIGEgbGFwdG9wLCB3aG9zZSBrZXlib2FyZCBjYW4gYmUgZm9sZGVkIHVuZGVyIHRoZQo+Pj4+ IHNjcmVlbiB0byBjcmVhdGUgdGFibGV0LWxpa2UgZXhwZXJpZW5jZS4gVGhlIHVzZXIgdGhlbiBt dXN0IGhvbGQgdGhlIGxhcHRvcAo+Pj4+IGluIHN1Y2ggYSB3YXkgdGhhdCBpdCBpcyBkaWZmaWN1 bHQgdG8gYXZvaWQgcHJlc3NpbmcgdGhlIGtleWJvYXJkIGtleXMuIEl0Cj4+Pj4gaXMgdGhlcmVm b3JlIGRlc2lyYWJsZSB0byB0ZW1wb3JhcmlseSBkaXNyZWdhcmQgaW5wdXQgZnJvbSB0aGUga2V5 Ym9hcmQsCj4+Pj4gdW50aWwgaXQgaXMgZm9sZGVkIGJhY2suIFRoaXMgb2J2aW91c2x5IGlzIGEg cG9saWN5IHdoaWNoIHNob3VsZCBiZSBrZXB0Cj4+Pj4gb3V0IG9mIHRoZSBrZXJuZWwsIGJ1dCB0 aGUga2VybmVsIG11c3QgcHJvdmlkZSBzdWl0YWJsZSBtZWFucyB0byBpbXBsZW1lbnQKPj4+PiBz dWNoIGEgcG9saWN5Lgo+Pj4KPj4+IEFjdHVhbGx5IGxpYmlucHV0IGFscmVhZHkgYmluZHMgdG9n ZXRoZXIgKGluc2lkZSBsaWJpbnB1dCkgU1dfVEFCTEVUX01PREUKPj4+IGdlbmVyYXRpbmcgZXZk ZXYgbm9kZXMgYW5kIGUuZy4gaW50ZXJuYWwga2V5Ym9hcmRzIG9uIGRldmljZXMgd2l0aCAzNjDD g+KAmsOCwrAKPj4+IGhpbmdlcyBmb3IgdGhpcyByZWFzb24uIGxpYmlucHV0IHNpbXBseSBjbG9z ZXMgdGhlIC9kZXYvaW5wdXQvZXZlbnQjCj4+PiBub2RlIHdoZW4gZm9sZGVkIGFuZCByZS1vcGVu cyBpdCB3aGVuIHRoZSBrZXlib2FyZCBzaG91bGQgYmVjb21lIGFjdGl2ZQo+Pj4gYWdhaW4uIFRo dXMgbm90IG9ubHkgc3VwcHJlc3NlcyBldmVudHMgYnV0IGFsbG93cyBlLmcuIHRvdWNocGFkcyB0 bwo+Pj4gZW50ZXIgcnVudGltZSBzdXNwZW5kIG1vZGUgd2hpY2ggc2F2ZXMgcG93ZXIuIFR5cGlj YWxseSBjbG9zaW5nIHRoZQo+Pj4gL2Rldi9pbnB1dC9ldmVudCMgbm9kZSB3aWxsIGFsc28gZGlz YWJsZSB0aGUgZGV2aWNlIGFzIHdha2V1cCBzb3VyY2UuCj4+Pgo+Pj4gU28gSSB3b25kZXIgd2hh dCB0aGlzIHNlcmllcyBhY3R1YWxseSBhZGRzIGZvciBmdW5jdGlvbmFsaXR5IGZvcgo+Pj4gdXNl cnNwYWNlIHdoaWNoIGNhbiBub3QgYWxyZWFkeSBiZSBhY2hpZXZlZCB0aGlzIHdheT8KPj4KPj4g VGhhbmtzIEhhbnMuIFRvIGV4cGFuZCBvbiB0aGlzOgo+PiBsaWJpbnB1dCBoYXMgaGV1cmlzdGlj cyB0byBndWVzcyB3aGljaCBpbnB1dCBkZXZpY2VzIChrZXlib2FyZHMsIHRvdWNocGFkcykKPj4g YXJlIGJ1aWx0LWluIG9uZXMuIFdoZW4gdGhlIHRhYmxldCBtb2RlIHN3aXRjaCBpcyBvbiwgd2Ug ZGlzYWJsZSB0aGVzZQo+PiBkZXZpY2VzIGludGVybmFsbHkgKHRoaXMgaXMgbm90IHZpc2libGUg dG8gY2FsbGVycyksIGFuZCByZS1lbmFibGUgaXQgYWdhaW4KPj4gbGF0ZXIgd2hlbiB0aGUgdGFi bGV0IG1vZGUgc3dpdGNoIGlzIG9mZiBhZ2Fpbi4KPiAKPiBJIHRoaW5rIHRoYXQgaXMgZ3JlYXQg dGhhdCBsaWJpbnB1dCBoYXMgdHJpZWQgc29sdmluZyB0aGlzIGZvciB0aGUKPiB0YWJsZXQgbW9k ZSwgYnV0IHVuZm9ydHVuYXRlbHkgbGliaW5wdXQgb25seSB3b3JrcyBmb3IgdXNlcnMgb2YKPiBs aWJpbnB1dCwgbGVhdmluZyBjYXNlcyBzdWNoIGFzOgo+IAo+IDEuIEluLWtlcm5lbCBpbnB1dCBo YW5kbGVycywgc3VjaCBhcyBTeXNScSwgVlQgYW5kIG90aGVycwo+IDIuIFN5c3RlbXMgdGhhdCBk byBub3QgcmVseSBvbiBsaWJpbnB1dCBmb3IgdXNlcnNwYWNlIGhhbmRpbmcgKEFuZHJvaWQsCj4g Q2hyb21lIE9TKQo+IDMuIFN5c3RlbXMgd2l0aCBwb2xpY2llcyB0aGF0IGFyZSBtb3JlIGNvbXBs ZXggdGhhbiB0YWJsZXQgbW9kZSBvbmx5Lgo+IAo+IEJlY2F1c2Ugb2YgbGliaW5wdXQncyBpbmFi aWxpdHkgdG8gYWZmZWN0IHRoZSBrZXJuZWwsIGFuZCB0aGUgcHJlc2VuY2UKPiBvZiAiYWx3YXlz IG9uIiBpbnB1dCBoYW5kbGVycyAoc3lzcnEsIFZUIGtleWJvYXJkLCBwb3RlbnRpYWxseSBvdGhl cnMpLAo+IHdoaWxlIGxpYmlucHV0IG1heSBjb250cm9sIHdoZXRoZXIgY29uc3VtZXJzIHJlY2Vp dmUgZXZlbnRzIGZyb20gY2VydGFpbgo+IGlucHV0IGRldmljZXMsIGl0IHdpbGwgbm90IGFsbG93 IHBvd2VyIHNhdmluZ3MgdGhhdCBhbiBleHBsaWNpdAo+ICJpbmhpYml0IiBhbGxvd3Mgd2hlbiBj b21pbmcgZnJvbSBkZWRpY2F0ZWQgcG93ZXIgcG9saWN5IG1hbmFnZXIuCgpPaywgdGhlIHN5c3Jx IGFuZCB2dCBrZXlib2FyZCBoYW5kbGVycyBrZWVwaW5nIHRoZSBkZXZpY2Ugb3BlbiBhbmQgdGh1 cwptYWtlIGl0IGtlZXAgdXNpbmcgcG93ZXIgaXMgYSB2YWxpZCByZWFzb24gZm9yIGEgc2VwYXJh dGUgaW5oaWJpdCBtZWNoYW5pc20uCgo+IEkgdGhpbmsgcHVzaGluZyBwb2xpY3kgZGVjaXNpb25z IGludG8gYSBsaWJyYXJ5LCBhbmQgdHJ5aW5nIHRvIGhhdmUgYWxsCj4gY2xpZW50cyBhZ3JlZSB3 aXRoIGl0LCBpcyBtdWNoIGhhcmRlciBhbmQgbGVha3MgdW5uZWNlc3Nhcnkga25vd2xlZGdlCj4g aW50byBxdWl0ZSBhIGZldyBsYXllcnMuIEEgZGVkaWNhdGVkIHBvd2VyIHBvbGljeSBtYW5hZ2Vy LCB0aGF0IGlzIG5vdAo+IG9ubHkgcmVzcG9uc2libGUgZm9yIGlucHV0IGRldmljZSwgYnV0IHBv d2VyIHN0YXRlIG9mIHRoZSBzeXN0ZW0gYXMgYQo+IHdob2xlLCBpcyBhIHZlcnkgdmlhYmxlIGFy Y2hpdGVjdHVyZS4KCldlbGwgQUZBSUsgdGhlIGtlcm5lbC1wb2xpY3kgaGFzIGFsd2F5cyBiZWVu IHRvIGxlYXZlIHBvbGljeSBkZWNpc2lvbnMKdXAgdG8gdXNlcnNwYWNlIGFzIG11Y2ggYXMgcG9z c2libGUsIGJ1dCB0aGlzIGp1c3QgYWRkcyBhIG1lY2hhbmlzbSB0bwppbXBsZW1lbnQgdGhlIHBv bGljeSBzbyB0aGF0IGlzIGZpbmUuCgo+PiBUaGlzIGlzIGRvbmUgZm9yIGtleWJvYXJkcyBhbmQg dG91Y2hwYWRzIGF0bSAoYW5kIEkgdGhpbmsgcG9pbnRpbmcgc3RpY2tzKQo+PiBhbmQgd2hlcmUg dGhlIGhldXJpc3RpY3MgZmFpbCB3ZSBoYXZlIGV4dHJhIHF1aXJrcyBpbiBwbGFjZS4gRm9yIGV4 YW1wbGUKPj4gdGhlIExlbm92byBZb2dhcyB0ZW5kIHRvIGRpc2FibGUgdGhlIGtleWJvYXJkIG1l Y2hhbmljYWxseSBpbiB0YWJsZXQgbW9kZQo+PiBidXQgYnV0dG9ucyAoZS5nLiB2b2x1bWUga2V5 cykgYXJvdW5kIHRoZSBzY3JlZW4gc2VuZCBldmVudHMgdGhyb3VnaCB0aGUKPj4gc2FtZSBldmVu dCBub2RlLiBTbyBvbiB0aG9zZSBkZXZpY2VzIHdlIGRvbid0IGRpc2FibGUgdGhlIGtleWJvYXJk Lgo+Pgo+PiBXZSd2ZSBoYWQgdGhpcyBjb2RlIGZvciBhIGZldyB5ZWFycyBub3cgYW5kIHRoZSBv bmx5IGNoYW5nZXMgdG8gaXQgaGF2ZSBiZWVuCj4+IHRoZSB2YXJpb3VzIGRldmljZSBxdWlya3Mg Zm9yIGRldmljZXMgdGhhdCBtdXN0IG5vdCBzdXNwZW5kIHRoZSBrZXlib2FyZCwKPj4gaXQncyBv dGhlcndpc2Ugd29ya2luZyBhcyBleHBlY3RlZC4KPj4KPj4gSWYgd2UgZXZlciBoYXZlIGEgZGV2 aWNlIHdoZXJlIHdlIG5lZWQgdG8gZGlzYWJsZSBwYXJ0cyBvZiB0aGUga2V5Ym9hcmQKPj4gb25s eSwgd2UgY291bGQgYWRkcmVzcyB0aGlzIHdpdGggRVZJT0NTTUFTSyBidXQgc28gZmFyIHRoYXQg aGFzbid0IGJlZW4KPj4gbmVjZXNzYXJ5Lgo+Pgo+PiBJIGFncmVlIHdpdGggSGFucywgcmlnaHQg bm93IEkgZG9uJ3Qgc2VlIHRoZSB1c2VmdWxuZXNzIG9mIHRoaXMgbmV3IHN5c2ZzCj4+IHRvZ2ds ZS4gRm9yIGl0IHRvIGJlIHJlYWxseSB1c2VmdWwgeW91J2QgaGF2ZSB0byBndWFyYW50ZWUgdGhh dCBpdCdzCj4+IGF2YWlsYWJsZSBmb3IgMTAwJSBvZiB0aGUgZGV2aWNlcyBhbmQgdGhhdCdzIElN TyB1bmxpa2VseSB0byBoYXBwZW4uCj4gCj4gVGhlIGluaGliaXRpbmcgb2YgdGhlIGV2ZW50cyB3 b3JrcyBmb3IgMTAwJSBvZiBpbnB1dCBkZXZpY2VzLCB0aGUgcG93ZXIKPiBzYXZpbmdzIHdvcmsg Zm9yIHRoZSBvbmVzIHRoYXQgaW1wbGVtZW50IGl0LiBJdCBpcyByZXNwb25zaWJpbGl0eSBvZgo+ IGZvbGRzIHNoaXBwaW5nIHRoZSBzeXN0ZW1zIHRvIG1ha2Ugc3VyZSBkcml2ZXJzIHRoZXkgdXNl IHN1cHBvcnQgaW5oaWJpdAo+IGlmIHRoZXkgYmVsaWV2ZSBpdCB3aWxsIGhlbHAgdGhlaXIgYmF0 dGVyeSBsaWZlLgo+IAo+Pgo+PiBDaGVlcnMsCj4+ICAgICBQZXRlcgo+Pgo+Pj4gSSBhbHNvIG5v dGljZWQgdGhhdCB5b3Uga2VlcCB0aGUgZGV2aWNlIG9wZW4gKGRvIG5vdCBjYWxsIHRoZQo+Pj4g aW5wdXRfZGV2aWNlJ3MgY2xvc2UgY2FsbGJhY2spIHdoZW4gaW5oaWJpdGVkIGFuZCBqdXN0IHRo cm93IGF3YXkKPj4+IGFueSBldmVudHMgZ2VuZXJhdGVkLiBUaGlzIHNlZW1zIGluZWZmaWNpZW50 IGFuZCBtYXkgbGVhZCB0bwo+Pj4gdGhlIGludGVybmFsIHN0YXRlIGdldHRpbmcgb3V0IG9mIHN5 bmMuIFdoYXQgaWYgYSBrZXkgaXMgcHJlc3NlZAo+Pj4gd2hpbGUgaW5oaWJpdGVkIGFuZCB0aGVu IHRoZSBkZXZpY2UgaXMgdW5pbmhpYml0ZWQgd2hpbGUgdGhlIGtleQo+Pj4gaXMgc3RpbGwgcHJl c3NlZD8gIE5vdyB0aGUgcHJlc3MgZXZlbnQgaXMgbG9zdCBhbmQgdXNlcnNwYWNlCj4+PiBxdWVy eWluZyB0aGUgY3VycmVudCBzdGF0ZSB3aWxsIHNlZSB0aGUgcHJlc3NlZCBrZXkgYXMgYmVpbmcK Pj4+IHJlbGVhc2VkLgo+IAo+IFRoaXMgaXMgYSBnb29kIHBvaW50LiBXZSBzaG91bGQgbG9vayBp bnRvIHNpZ25hbGxpbmcgdGhhdCBzb21lIGV2ZW50cwo+IGhhdmUgYmVlbiBkcm9wcGVkICh2aWEg RVZfU1lOL1NZTl9EUk9QUEVEKSBzbyB0aGF0IGNsaWVudHMgYXJlIGF3YXJlIG9mCj4gaXQuCj4g Cj4+Pgo+Pj4gT24gdG9wIG9mIHRoaXMgeW91IGFkZCBzcGVjaWFsIGluaGliaXQgYW5kIHVuaW5o aWJpdCBjYWxsYmFja3MKPj4+IGFuZCBpbXBsZW1lbnQgdGhvc2UgZm9yIGp1c3QgYSBmZXcgZGV2 aWNlcy4gSG93IGRvIHRoZXNlIGRpZmZlcgo+Pj4gZnJvbSBqdXN0IGNsb3NpbmcgdGhlIGRldmlj ZSBhbmQgbGF0ZXIgb3BlbmluZyBpdCBhZ2FpbiA/Cj4gCj4gSSBiZWxpZXZlIG1ham9yaXR5IHdp bGwgc2ltcGx5IHJldXNlIG9wZW4vY2xvc2UgY2FsbGJhY2tzLiBJbiBDaHJvbWUgT1MKPiB3ZSBo YXZlIGRlZGljYXRlZCBpbmhpYml0L3VuaW5oaWJpdCwgYnV0IEkgd291bGQgbGlrZSB0byBhbGxv dyB1c2luZwo+IG9wZW4vY2xvc2UgYXMgYWx0ZXJuYXRpdmVzLgoKQWNrLCBtYXliZSBzb21lIGRy aXZlciBmbGFnIHRvIGp1c3QgY2FsbCBjbG9zZSBvbiBpbmhpYml0IGFuZApvcGVuIG9uIHVuaGli aXQgKGFsc28gdGFraW5nIGlucHV0X2RldmljZS51c2VycyBpbnRvIGFjY291bnQgb2YgY291cnNl KSA/Cgo+Pj4gQWxzbyB1c2luZyBhIHN5c2ZzIHByb3BlcnR5IGZvciB0aGlzIGlzIHZlcnkgd2Vp cmQgZ2l2ZW4gdGhhdCB0aGUKPj4+IHJlc3Qgb2YgdGhlIGV2ZGV2IGludGVyZmFjZSBpcyB1c2lu ZyBpb2N0bHMgZm9yIGV2ZXJ5dGhpbmcuLi4KPiAKPiBUaGlzIGlzIG5vdCBldmRldiBpbnRlcmZh Y2UsIGl0IGlzIGF0IHRoZSBsZXZlbCBhYm92ZSBldmRldiAoc28gdGhhdCBpdAo+IGNhbiBhZmZl Y3QgYWxsIGhhbmRsZXJzLCBub3Qgb25seSBldmRldikuIEFzIHN1Y2ggaXQgaXMgbm90IGJvdW5k IGJ5Cj4gZXZkZXYgaW50ZXJmYWNlLgoKT2sgSSBjYW4gc2VlIGhvdyBvbiBzb21lIHN5c3RlbXMg dGhlIHByb2Nlc3MgaW1wbGVtZW50aW5nIHRoZSBwb2xpY3kKb2Ygd2hlbiB0byBpbmhpYml0IHdv dWxkIGJlIHNlcGFyYXRlIGZyb20gdGhlIHByb2Nlc3Mgd2hpY2ggaGFzIHRoZQpkZXZpY2Ugb3Bl bi4gQnV0IGluIGUuZy4gdGhlIGxpYmlucHV0IGNhc2UgaXQgd291bGQgYmUgZ29vZCBpZgpsaWJp bnB1dCBjb3VsZCBhY3RpdmF0ZSBhbnkgcG90ZW50aWFsIHBvd2VyLXNhdmluZ3MgYnkgc2V0dGlu Zwp0aGUgaW5oaWJpdCBmbGFnLgoKVGhlIHByb2JsZW0gd2l0aCBzeXNmcyBpbnRlcmZhY2VzIGlz IHRoYXQgdGhleSB0eXBpY2FsbHkgcmVxdWlyZQpyb290IHJpZ2h0cyBhbmQgdGhhdCB0aGV5IGFy ZSBub3QgcmVhbGx5IGNvbXBhdGlibGUgd2l0aCBGRApwYXNzaW5nLiBsaWJpbnB1dCBydW5zIGFz IGEgbm9ybWFsIHVzZXIsIGdldHRpbmcgYSBmZCB0byB0aGUKL2Rldi9pbnB1dC9ldmVudCMgbm9k ZSBwYXNzZWQgYnkgc3lzdGVtZC1sb2dpbmQuCgpBcyBzYWlkIEkgY2FuIHNlZSB0aGUgcmVhc29u IGZvciB3YW50aW5nIGEgc3lzZnMgYXR0cmlidXRlIGZvcgp0aGlzLCBjYW4gd2UgcGVyaGFwcyBo YXZlIGJvdGggYSBzeXNmcyBpbnRlcmZhY2UgYW5kIGFuIGlvY3RsPwoKTm90ZSBib3RoIGNvdWxk IHNoYXJlIHRoZSBzYW1lIGJvb2xlYW4gaW4gdGhlIGtlcm5lbCwgaXQgd291bGQgYmUKdXAgdG8g dXNlcnNwYWNlIHRvIG5vdCB0cnkgYW5kIHdyaXRlIHRvIGJvdGguIEUuZy4gY2hyb21lLW9zCndv dWxkIHVzZSB0aGUgc3lzZnMgYXR0ciwgbGliaW5wdXQgd291bGQgdXNlIHRoZSBpb2N0bC4KClJl Z2FyZHMsCgpIYW5zCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KbGludXgtYXJtLWtlcm5lbCBtYWlsaW5nIGxpc3QKbGludXgtYXJtLWtlcm5lbEBsaXN0 cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGlu Zm8vbGludXgtYXJtLWtlcm5lbAo=