Adding an interface to evdev for tablet orientation

Adding an interface to evdev for tablet orientation

[Hans de Goede]

Hi All,

Many accelerometers used in tablets not only offer acceleration
data along 3 axis, but also have a notion of the orientation of
the tablet (right side up, upside down, rotated 90 degrees left/right),
currently there is no way to export this info via evdev.

I think we need to add an axis/switch/? to the linux/uapi/input.h
definitions to support this, as it is useful info to have, and the hw
is likely a more reliable source of this info then deducting it from
the accelerometer readings as is done in e.g. :

https://github.com/hadess/iio-sensor-proxy/blob/master/src/orientation.c#L60

3 questions:

1) Do people agree that it is a good idea to export the hardware's
notation of the orientation through evdev ?

2) What sort of evdev events should orientation changes send, events
on a new axis, or switch events, or ... ?

3) The accelerometer hardware I've been looking at sofar typically
generates a hw interrupt for orientation changes, where as reading
the actual acceleration axis typically is a contineous process
requiring polling. The current iio-sensor-proxy code (which also
handles evdev accelerometers) leaves the evdev node closed and
only opens it on a change kevent, which means that we need to
generate change kevents on orientation changes. Another approach
would be to have 2 separate evdev nodes, one for the orientation
function, and on opening that we enable the irq), and one for
reading accel values and on opening this one we start polling.

Regards,

Hans

Re: Adding an interface to evdev for tablet orientation

[Bastien Nocera]

Hey Hans,

On Thu, 2015-08-06 at 15:19 +0200, Hans de Goede wrote:
> Hi All,
> 
> Many accelerometers used in tablets not only offer acceleration
> data along 3 axis, but also have a notion of the orientation of
> the tablet (right side up, upside down, rotated 90 degrees 
> left/right),
> currently there is no way to export this info via evdev.
> 
> I think we need to add an axis/switch/? to the linux/uapi/input.h
> definitions to support this, as it is useful info to have, and the hw
> is likely a more reliable source of this info then deducting it from
> the accelerometer readings as is done in e.g. :
> 
> https://github.com/hadess/iio-sensor-proxy/blob/master/src/orientatio
> n.c#L60
> 
> 3 questions:
> 
> 1) Do people agree that it is a good idea to export the hardware's
> notation of the orientation through evdev ?

If the hardware/firmware exports it, definitely.

> 2) What sort of evdev events should orientation changes send, events
> on a new axis, or switch events, or ... ?
> 
> 3) The accelerometer hardware I've been looking at sofar typically
> generates a hw interrupt for orientation changes, where as reading
> the actual acceleration axis typically is a contineous process
> requiring polling. The current iio-sensor-proxy code (which also
> handles evdev accelerometers) leaves the evdev node closed and
> only opens it on a change kevent, which means that we need to
> generate change kevents on orientation changes.

That's how the pegatron accelerometer worked in the WeTab (see the asus
ACPI driver).

>  Another approach
> would be to have 2 separate evdev nodes, one for the orientation
> function, and on opening that we enable the irq), and one for
> reading accel values and on opening this one we start polling.

I'd simply export the orientation metadata as a sysfs property, which
would be consumed and proxied by iio-sensor-proxy to the desktop.

Cheers

Re: Adding an interface to evdev for tablet orientation

[Hans de Goede]

Hi,

On 16-08-15 21:58, Bastien Nocera wrote:
> Hey Hans,
>
> On Thu, 2015-08-06 at 15:19 +0200, Hans de Goede wrote:
>> Hi All,
>>
>> Many accelerometers used in tablets not only offer acceleration
>> data along 3 axis, but also have a notion of the orientation of
>> the tablet (right side up, upside down, rotated 90 degrees
>> left/right),
>> currently there is no way to export this info via evdev.
>>
>> I think we need to add an axis/switch/? to the linux/uapi/input.h
>> definitions to support this, as it is useful info to have, and the hw
>> is likely a more reliable source of this info then deducting it from
>> the accelerometer readings as is done in e.g. :
>>
>> https://github.com/hadess/iio-sensor-proxy/blob/master/src/orientatio
>> n.c#L60
>>
>> 3 questions:
>>
>> 1) Do people agree that it is a good idea to export the hardware's
>> notation of the orientation through evdev ?
>
> If the hardware/firmware exports it, definitely.
>
>> 2) What sort of evdev events should orientation changes send, events
>> on a new axis, or switch events, or ... ?
>>
>> 3) The accelerometer hardware I've been looking at sofar typically
>> generates a hw interrupt for orientation changes, where as reading
>> the actual acceleration axis typically is a contineous process
>> requiring polling. The current iio-sensor-proxy code (which also
>> handles evdev accelerometers) leaves the evdev node closed and
>> only opens it on a change kevent, which means that we need to
>> generate change kevents on orientation changes.
>
> That's how the pegatron accelerometer worked in the WeTab (see the asus
> ACPI driver).
>
>>   Another approach
>> would be to have 2 separate evdev nodes, one for the orientation
>> function, and on opening that we enable the irq), and one for
>> reading accel values and on opening this one we start polling.
>
> I'd simply export the orientation metadata as a sysfs property, which
> would be consumed and proxied by iio-sensor-proxy to the desktop.

Interesting, so you're suggesting to not add any new evdev event
types for this at all, and to instead use a sysfs attribute +
change kevents on orientation changes so that userspace will know
when to re-read the sysfs attribute ?

Dmitry what is your take on this ?

Regards,

Hans

Re: Adding an interface to evdev for tablet orientation

[Bastien Nocera]

On Sun, 2015-08-16 at 22:12 +0200, Hans de Goede wrote:
> 
<snip>
> Interesting, so you're suggesting to not add any new evdev event
> types for this at all, and to instead use a sysfs attribute +
> change kevents on orientation changes so that userspace will know
> when to re-read the sysfs attribute ?

Yes, the changes to the iio-sensor-proxy code would be minimal (read
from the sysfs property if it exists instead of the raw data).

> Dmitry what is your take on this ?
> 
> Regards,
> 
> Hans
> --
> To unsubscribe from this list: send the line "unsubscribe linux
> -input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html