RFC: Present Screen rotation as counter

RFC: Present Screen rotation as counter

[Gwendal Grignou]

Today, on chromebook, to detect screen orientation (portrait,
landscape, inverted portrait, inverted landscape), chrome is polling
lid accelerometer data and calculating the orientation.
To save power, I want the embedded controller (EC) to forward an event
when the lid acceleration detects an orientation change.
To convey that information, I would like to define a rotary encoder
with 4 regions, the counter increases when the screen is rotated
clockwise, (decreases when rotated counter-clockwise) and would
increment by 4 on a full rotation.
The EC knows the accelerometer placement relative to the screen, so we
can define landscape as count % 4 equals to 0.
Would such a counter fit into the counter subsystem?

Regards,
Gwendal.

Re: RFC: Present Screen rotation as counter

[William Breathitt Gray]

[-- Attachment #1: Type: text/plain, Size: 2455 bytes --]

On Wed, Apr 08, 2020 at 12:22:10AM -0700, Gwendal Grignou wrote:
> Today, on chromebook, to detect screen orientation (portrait,
> landscape, inverted portrait, inverted landscape), chrome is polling
> lid accelerometer data and calculating the orientation.
> To save power, I want the embedded controller (EC) to forward an event
> when the lid acceleration detects an orientation change.
> To convey that information, I would like to define a rotary encoder
> with 4 regions, the counter increases when the screen is rotated
> clockwise, (decreases when rotated counter-clockwise) and would
> increment by 4 on a full rotation.
> The EC knows the accelerometer placement relative to the screen, so we
> can define landscape as count % 4 equals to 0.
> Would such a counter fit into the counter subsystem?
> 
> Regards,
> Gwendal.

The Counter subsystem is capable of representing this using a design
that looks something like this:

        Count                Synapse        Signal
        -----                -------        ------
+---------------------+
| Data: Orientation   |     EC Event       _______________
| Function: Rotate    |  <-------------   / Accelerometer \
|                     |                  ___________________
+---------------------+

Note: I'm calling the function "Rotate" here just to represent the
increase/decrease behavior of a rotary device, but perhaps a more
generic name for this function would be better here for other devices as
well.

Essentially, within the Generic Counter paradigm, the Signal in this
case is the accelerometer data. The Synapse is the EC event
(clockwise/counter-clockwise movement detected) that fires when the EC
notices the accelerometer placement changed relative to the screen.
Finally, the Count is the orientation of the screen.

We can have the Count value be an unsigned integer (0-4) to represent
each orientation, or an angle (90 degrees, 180 degrees, etc.) if you
want it to be more abstract -- it's up to you.

By the way, although I'm labeling the Signal and Synapses here as
Accelerometer and EC Event respectively, the counter driver you write
does not need to actually present these raw data values to the user --
I'm just including it here in the drawing to exemplify the paradigm; the
user of this counter driver will likely only care about the Count: the
current orientation value of the screen.

William Breathitt Gray

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: RFC: Present Screen rotation as counter

[Jonathan Cameron]

On Wed, 8 Apr 2020 14:02:56 -0400
William Breathitt Gray <vilhelm.gray@gmail.com> wrote:

> On Wed, Apr 08, 2020 at 12:22:10AM -0700, Gwendal Grignou wrote:
> > Today, on chromebook, to detect screen orientation (portrait,
> > landscape, inverted portrait, inverted landscape), chrome is polling
> > lid accelerometer data and calculating the orientation.
> > To save power, I want the embedded controller (EC) to forward an event
> > when the lid acceleration detects an orientation change.
> > To convey that information, I would like to define a rotary encoder
> > with 4 regions, the counter increases when the screen is rotated
> > clockwise, (decreases when rotated counter-clockwise) and would
> > increment by 4 on a full rotation.
> > The EC knows the accelerometer placement relative to the screen, so we
> > can define landscape as count % 4 equals to 0.
> > Would such a counter fit into the counter subsystem?
> > 
> > Regards,
> > Gwendal.  
> 
> The Counter subsystem is capable of representing this using a design
> that looks something like this:
> 
>         Count                Synapse        Signal
>         -----                -------        ------
> +---------------------+
> | Data: Orientation   |     EC Event       _______________
> | Function: Rotate    |  <-------------   / Accelerometer \
> |                     |                  ___________________
> +---------------------+
> 
> Note: I'm calling the function "Rotate" here just to represent the
> increase/decrease behavior of a rotary device, but perhaps a more
> generic name for this function would be better here for other devices as
> well.
> 
> Essentially, within the Generic Counter paradigm, the Signal in this
> case is the accelerometer data. The Synapse is the EC event
> (clockwise/counter-clockwise movement detected) that fires when the EC
> notices the accelerometer placement changed relative to the screen.
> Finally, the Count is the orientation of the screen.
> 
> We can have the Count value be an unsigned integer (0-4) to represent
> each orientation, or an angle (90 degrees, 180 degrees, etc.) if you
> want it to be more abstract -- it's up to you.
> 
> By the way, although I'm labeling the Signal and Synapses here as
> Accelerometer and EC Event respectively, the counter driver you write
> does not need to actually present these raw data values to the user --
> I'm just including it here in the drawing to exemplify the paradigm; the
> user of this counter driver will likely only care about the Count: the
> current orientation value of the screen.

Seems like a practical solution to me.

Brainstorming... Feel free to ignore :)

One possible alternative if staying in IIO would have been to do this
in a similar fashion to activity classification.   In that we defined
a set of activities as taking a 'probability' value/percentage so
we had a set of activity channels that would report 0 if not true and 100
if definitely true. Which was which was indicated by a modifier (running,
walking etc).

So the equivalent here would be to define states as
'portrait' 'landscape', 'inverted portrait' and 'inverted landscape'
each of which is a modifier of some base channel type - not sure what we'd call
that (pose perhaps?)

Then you can use the events from the embedded controller to both update
the value that would be read from the four resulting channels and also to
trigger an iio event (it's a simple rising value with a threshold of 50%)

The reason we went this way for activities is that the reality is the controller
is making some determination of a state being 'likely'.  The same is true
for orientation, particularly if the device is flat on a table.  So
if you wanted to be cleverer in future you could report say 60% chance
of portrait and 20% landscape for example allowing userspace to decide
what thresholds to set dependant on what the application is doing...

Anyhow, this is just brainstorming.  There is some logic to the counter
option - but I do see one issue.  If you want to also distinguish
'flat on table' or 'face down on table' I'm not sure how you do it?

Jonathan

> 
> William Breathitt Gray