On Wed, 8 Apr 2020 14:02:56 -0400 William Breathitt Gray <vilhelm.gray@xxxxxxxxx> 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
