lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 15 Jan 2021 14:45:31 -0800
From:   Stephen Boyd <swboyd@...omium.org>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Doug Anderson <dianders@...omium.org>
Cc:     Enric Balletbo i Serra <enric.balletbo@...labora.com>,
        Benson Leung <bleung@...omium.org>,
        LKML <linux-kernel@...r.kernel.org>, open list:
        HID CORE LAYER <linux-input@...r.kernel.org>,
        Guenter Roeck <groeck@...omium.org>, ;
Subject: Re: [PATCH] Input: cros_ec_keyb: Add support for a front proximity switch

Quoting Dmitry Torokhov (2021-01-07 11:46:48)
> 
> Yes, I understand that on some devices the proximity sensors are not
> true sensors but rather on/off signals, potentially derived from a
> multitude of sources. However there is still a benefit in exposing them
> as IIO proximity devices with limited reporting representing
> [near, infinity] range/values. This will mean that userspace needs to
> monitor only one set of devices (IIO) instead of both IIO and input, and
> will not require constantly expanding EV_SW set to account for
> ever-growing number of proximity sensors (lap, palm, general presence,
> etc).

Ok, no problem. I think I'll have to spin up a small driver to handle
this as an IIO proximity device and then register the IIO child device
from the cros ec driver. Let me see how that goes.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ