Adding an interface to evdev for tablet orientation

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 ?

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.

Hey Hans,

Quoted 13 lines · 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. :

Quoted 7 lines

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.

Quoted 10 lines

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).

Quoted 4 lines

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
--
To unsubscribe from this list: send the line "unsubscribe linux -input" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html