linux-kernel - Re: [PATCH v2 3/5] iio: Add channel type for attention

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] [day] [month] [year] [list]

Message-ID: <20241030165051.000023a1@Huawei.com>
Date: Wed, 30 Oct 2024 16:50:51 +0000
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: David Lechner <dlechner@...libre.com>
CC: Ricardo Ribalda <ribalda@...omium.org>, Jonathan Cameron
	<jic23@...nel.org>, Jiri Kosina <jikos@...nel.org>, Benjamin Tissoires
	<bentiss@...nel.org>, Srinivas Pandruvada
	<srinivas.pandruvada@...ux.intel.com>, Lars-Peter Clausen <lars@...afoo.de>,
	Harvey Yang <chenghaoyang@...gle.com>, <linux-input@...r.kernel.org>,
	<linux-iio@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 3/5] iio: Add channel type for attention

On Tue, 29 Oct 2024 17:26:06 -0500
David Lechner <dlechner@...libre.com> wrote:

> On 10/29/24 9:38 AM, Jonathan Cameron wrote:
> > On Tue, 29 Oct 2024 13:20:06 +0100
> > Ricardo Ribalda <ribalda@...omium.org> wrote:
> >   
> >> Hi Jonathan
> >>
> >> On Mon, 28 Oct 2024 at 21:34, Jonathan Cameron <jic23@...nel.org> wrote:  
> >>>
> >>> On Mon, 28 Oct 2024 10:12:23 +0000
> >>> Ricardo Ribalda <ribalda@...omium.org> wrote:
> >>>    
> >>>> Add a new channel type representing if the user's attention state to the
> >>>> the system. This usually means if the user is looking at the screen or
> >>>> not.
> >>>>
> >>>> Signed-off-by: Ricardo Ribalda <ribalda@...omium.org>
> >>>> ---
> >>>>  Documentation/ABI/testing/sysfs-bus-iio | 7 +++++++
> >>>>  drivers/iio/industrialio-core.c         | 1 +
> >>>>  include/uapi/linux/iio/types.h          | 1 +
> >>>>  tools/iio/iio_event_monitor.c           | 2 ++
> >>>>  4 files changed, 11 insertions(+)
> >>>>
> >>>> diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
> >>>> index 89943c2d54e8..d5a2f93bd051 100644
> >>>> --- a/Documentation/ABI/testing/sysfs-bus-iio
> >>>> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> >>>> @@ -2339,3 +2339,10 @@ KernelVersion: 6.10
> >>>>  Contact:     linux-iio@...r.kernel.org
> >>>>  Description:
> >>>>               The value of current sense resistor in Ohms.
> >>>> +
> >>>> +What:                /sys/.../iio:deviceX/in_attention_raw
> >>>> +KernelVersion:       6.13
> >>>> +Contact:     linux-iio@...r.kernel.org
> >>>> +Description:
> >>>> +             Boolean value representing the user's attention to the system.
> >>>> +             This usually means if the user is looking at the screen or not.    
> >>>
> >>> Hmm. I should have thought of this when I replied to suggest a new channel type.
> >>> The question is 'units' for a decision.
> >>>
> >>> Last time we hit something like this where processing is used to make a decision
> >>> we decided to at least allow for the concept of 'certainty'.
> >>>
> >>> The idea being that smarter sensors would tell us something about how sure they
> >>> are that the attention is on the device.
> >>> The analogy being with activity detection. See in_activity_walking_input
> >>> in Documentation/ABI/testing/sysfs-bus-iio
> >>>
> >>> Do you think that would be appropriate here as well?  For this device
> >>> it would take the values 0 and 100 rather than 0 and 1.    
> >>
> >> For the particular device that I want to support, they are giving me a
> >> value of 1 and 0, and the example from usb.org seems to work the same
> >> way (Logical Maximum of 1)
> >> https://www.usb.org/sites/default/files/hutrr107-humanpresenceattention_1.pdf
> >>
> >> I have no problem multiplying my value by 100 if you think there will
> >> be a use case for that. It will not have a major performance impact on
> >> the driver.  
> > Same was true (0 or 1) for the activity classification but I'm not
> > keen on certainty :)  So lets' copy that precedence and *100
> > 
> >   
> And I assume we would want this to be in_attention_input (processed),
> not in_attention_raw.
Good point. Yes.
>