linux-kernel - Re: [PATCH v3 03/11] iio: Add channel for Position Relative

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:   Wed, 18 Apr 2018 10:32:27 +0100
From:   Jonathan Cameron <Jonathan.Cameron@...wei.com>
To:     Eugen Hristev <eugen.hristev@...rochip.com>
CC:     Jonathan Cameron <jic23@...nel.org>,
        <ludovic.desroches@...rochip.com>, <alexandre.belloni@...tlin.com>,
        <linux-arm-kernel@...ts.infradead.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-iio@...r.kernel.org>, <linux-input@...r.kernel.org>,
        <nicolas.ferre@...rochip.com>, <dmitry.torokhov@...il.com>,
        <robh@...nel.org>
Subject: Re: [PATCH v3 03/11] iio: Add channel for Position Relative

On Tue, 17 Apr 2018 10:30:46 +0300
Eugen Hristev <eugen.hristev@...rochip.com> wrote:

> On 15.04.2018 22:29, Jonathan Cameron wrote:
> > On Tue, 10 Apr 2018 11:57:49 +0300
> > Eugen Hristev <eugen.hristev@...rochip.com> wrote:
> >   
> >> Add new channel type for relative position on a pad.
> >>
> >> These type of analog sensor offers the position of a pen
> >> on a touchpad, and is represented as a voltage, which can be
> >> converted to a position on X and Y axis on the pad.
> >> The channel will hand the relative position on the pad in both directions.
> >>
> >> The channel can then be consumed by a touchscreen driver or
> >> read as-is for a raw indication of the touchpen on a touchpad.
> >>
> >> Signed-off-by: Eugen Hristev <eugen.hristev@...rochip.com>
> >> ---
> >> Changes in v2:
> >>   - modified channel name to relative position as suggested.
> >>   - modified kernel version to 4.18 (presumable)
> >>
> >>   Documentation/ABI/testing/sysfs-bus-iio | 12 ++++++++++++
> >>   drivers/iio/industrialio-core.c         |  1 +
> >>   include/uapi/linux/iio/types.h          |  1 +
> >>   tools/iio/iio_event_monitor.c           |  2 ++
> >>   4 files changed, 16 insertions(+)
> >>
> >> diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
> >> index 6a5f34b..42a9287 100644
> >> --- a/Documentation/ABI/testing/sysfs-bus-iio
> >> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> >> @@ -190,6 +190,18 @@ Description:
> >>   		but should match other such assignments on device).
> >>   		Units after application of scale and offset are m/s^2.
> >>   
> >> +What:		/sys/bus/iio/devices/iio:deviceX/in_positionrelative_x_raw
> >> +What:		/sys/bus/iio/devices/iio:deviceX/in_positionrelative_y_raw
> >> +KernelVersion:	4.18
> >> +Contact:	linux-iio@...r.kernel.org
> >> +Description:
> >> +		Relative position in direction x or y on a pad (may be
> >> +		arbitrarily assigned but should match other such assignments on
> >> +		device).
> >> +		Units after application of scale and offset are milli percents
> >> +		from the pad's size in both directions. Should be calibrated by
> >> +		the consumer.  
> > I know the milli percent comes form the humidity equivalent, but I wonder
> > if we are right to follow that.  10^-5 is a pretty random base unit (though
> > I got argued into it being a standard choice for humidity sensors IIRC...
> > 
> > What do people think?  We could go with 1 for full range or just percent perhaps?
> > 
> > I'm not that fussed about staying consistent with humidity - we are unlikely
> > to end up with sensors doing both anytime soon so there shouldn't be
> > any confusion...
> > 
> > Jonathan  
> Hello Jonathan,
> 
> For my specific use case, percents are not enough, as this would mean 
> the resolution will be pretty low. If we have a touchpanel of a higher 
> resolution, having the position only ranged 0 to 100 is pretty bad.
> Having millipercents means we can have a resolution up to 100,000 points 
> in range, which is fine for the hardware as of this moment.
> Of course, specific drivers reporting these channels can define a 
> specific range if they desire (report just in the first percent if you 
> wish (0-1000) or so, which would mean a lower resolution.
> Centi-percent would work fine as well I believe (0-10,000 range), but to 
> keep consistent with your suggestion regarding relative humidity, I 
> picked this larger scale.
> In my specific case, since we have a 12 bit ADC, range is 0-4096 for 
> this value.
> Calibrating these values to the actual size of the touchpanel is left 
> for the consumer to do (map 4096x4096 to the actual resolution)
> 
> If you have a better idea than milli-percents I can change it, no problem.
> 

It doesn't actually matter what the defined 'base units' are from a question
of what we can represent.  That is just handled by suppling an appropriate
SCALE for the channel.  All this is about is trying to provide something
consistent rather than having any effect on the actual range.  Will let
this sit a while longer...

Jonathan

> Eugen
> >> +
> >>   [...]  
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html