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