Communicating tablet mode status to userspace

[Daniel Drake]

Hi,

For the upcoming OLPC touchscreen laptop we're trying to solve the
following problem: we want the on-screen keyboard to only activate
itself when the laptop is "folded over" into tablet mode where the
keyboard is physically obscured.

We already have an ebook mode switch which detects this, and the
driver is upstream. Its an input device that exposes this information
via the SW_TABLET_MODE switch.

The on-screen keyboard runs in the user environment, which means that
its not root - it can't access /dev/input/event nodes directly. X
doesn't treat switches as input devices, so this info is not available
through X.

I'm wondering if anyone has suggestions on the best way to solve this
problem. The most attractive option I have found would be to do
something similar to the accelerometer:
http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=src/accelerometer/accelerometer.c

Modify the kernel input driver to generate a uevent (in addition to
the evdev event) every time the switch state is changed, then write a
udev program to expose this info in a udev property.

The change event would (presumably) trigger libudev's udev_monitor,
which would be used by the on-screen keyboard software (maliit) to
change its behaviour according to the property value.

Does this sound like a sensible plan, would these udev and kernel
changes be acceptable? Or is there a better option that I'm missing?

Thanks
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Alan Cox]

Post by Daniel Drake
The change event would (presumably) trigger libudev's udev_monitor,
which would be used by the on-screen keyboard software (maliit) to
change its behaviour according to the property value.
Does this sound like a sensible plan, would these udev and kernel
changes be acceptable? Or is there a better option that I'm missing?

Seems reasonable to me - but remember that a device can be in both tablet
and non tablet modes at once to different users once you have a wireless
display.

ie it's really not "tablet mode" it's "does this particular interface
have a keyboard"



--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Dmitry Torokhov]

Post by Daniel Drake
Hi,
For the upcoming OLPC touchscreen laptop we're trying to solve the
following problem: we want the on-screen keyboard to only activate
itself when the laptop is "folded over" into tablet mode where the
keyboard is physically obscured.
We already have an ebook mode switch which detects this, and the
driver is upstream. Its an input device that exposes this information
via the SW_TABLET_MODE switch.
The on-screen keyboard runs in the user environment, which means that
its not root - it can't access /dev/input/event nodes directly. X
doesn't treat switches as input devices, so this info is not available
through X.
I'm wondering if anyone has suggestions on the best way to solve this
problem. The most attractive option I have found would be to do
http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=src/accelerometer/accelerometer.c
Modify the kernel input driver to generate a uevent (in addition to
the evdev event) every time the switch state is changed, then write a
udev program to expose this info in a udev property.
The change event would (presumably) trigger libudev's udev_monitor,
which would be used by the on-screen keyboard software (maliit) to
change its behaviour according to the property value.
Does this sound like a sensible plan, would these udev and kernel
changes be acceptable? Or is there a better option that I'm missing?

Why can't you change event device ownership to the local user? Then you
can read and act upon events.

Thanks.

[Greg KH]

Post by Dmitry Torokhov

Post by Daniel Drake
Hi,
For the upcoming OLPC touchscreen laptop we're trying to solve the
following problem: we want the on-screen keyboard to only activate
itself when the laptop is "folded over" into tablet mode where the
keyboard is physically obscured.
We already have an ebook mode switch which detects this, and the
driver is upstream. Its an input device that exposes this information
via the SW_TABLET_MODE switch.
The on-screen keyboard runs in the user environment, which means that
its not root - it can't access /dev/input/event nodes directly. X
doesn't treat switches as input devices, so this info is not available
through X.
I'm wondering if anyone has suggestions on the best way to solve this
problem. The most attractive option I have found would be to do
http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=src/accelerometer/accelerometer.c
Modify the kernel input driver to generate a uevent (in addition to
the evdev event) every time the switch state is changed, then write a
udev program to expose this info in a udev property.
The change event would (presumably) trigger libudev's udev_monitor,
which would be used by the on-screen keyboard software (maliit) to
change its behaviour according to the property value.
Does this sound like a sensible plan, would these udev and kernel
changes be acceptable? Or is there a better option that I'm missing?

Why can't you change event device ownership to the local user? Then you
can read and act upon events.

Yes, that's the best way. Also, you might want to check out the extcon
driver interface, that might provide the api you want for userspace.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Daniel Drake]

On Tue, Oct 2, 2012 at 5:36 PM, Dmitry Torokhov

Post by Dmitry Torokhov
Why can't you change event device ownership to the local user? Then you
can read and act upon events.

That would work, I guess.

However, it sounds like your suggesting that we add some custom rules
in OLPC's own builds and leave it at that. I'm not sure what
user/group we could use for a generic rule matching this hardware.

The disadvantage here is that it doesn't work as a global solution to
the problem - every embedded distro in the same situation would have
to add a custom rule thing, and "generic distros" would have no such
solution at this time.

Maybe not such a big deal while OLPC is the only user. But I did come
across another request for SW_TABLET_MODE access:
https://bugs.freedesktop.org/show_bug.cgi?id=43935

Or would a udev rule making the OLPC switch device (and potentially
similar devices on other platforms in future) world-readable on all
distros be accepted?

Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Greg KH]

Post by Daniel Drake
On Tue, Oct 2, 2012 at 5:36 PM, Dmitry Torokhov

Post by Dmitry Torokhov
Why can't you change event device ownership to the local user? Then you
can read and act upon events.

That would work, I guess.
However, it sounds like your suggesting that we add some custom rules
in OLPC's own builds and leave it at that. I'm not sure what
user/group we could use for a generic rule matching this hardware.

That shouldn't be a custom rule, other distros bind the keyboard / mouse
to the local user in order to handle the multi-seat situation properly.
That should all be done already in the console-kit logic (or whatever
handles it now.)

Have you looked into that?

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Kay Sievers]

Post by Greg KH

Post by Daniel Drake
On Tue, Oct 2, 2012 at 5:36 PM, Dmitry Torokhov

Post by Dmitry Torokhov
Why can't you change event device ownership to the local user? Then you
can read and act upon events.

That would work, I guess.
However, it sounds like your suggesting that we add some custom rules
in OLPC's own builds and leave it at that. I'm not sure what
user/group we could use for a generic rule matching this hardware.

That shouldn't be a custom rule, other distros bind the keyboard / mouse
to the local user in order to handle the multi-seat situation properly.
That should all be done already in the console-kit logic (or whatever
handles it now.)
Have you looked into that?

The usual model is not uid/gid, it's ACLs dynamically applied for
logged-in users with active sessions:
http://www.freedesktop.org/software/systemd/man/systemd-logind.service.html
http://cgit.freedesktop.org/systemd/systemd/tree/src/login/70-uaccess.rules

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Daniel Drake]

Post by Kay Sievers
The usual model is not uid/gid, it's ACLs dynamically applied for
http://www.freedesktop.org/software/systemd/man/systemd-logind.service.html
http://cgit.freedesktop.org/systemd/systemd/tree/src/login/70-uaccess.rules

Thanks, those were the pointers I needed.
I'll work with this approach.

Thanks
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Bastien Nocera]

Hey Daniel,

Post by Daniel Drake

Post by Kay Sievers
The usual model is not uid/gid, it's ACLs dynamically applied for
http://www.freedesktop.org/software/systemd/man/systemd-logind.service.html
http://cgit.freedesktop.org/systemd/systemd/tree/src/login/70-uaccess.rules

Thanks, those were the pointers I needed.
I'll work with this approach.

I think that there's a more generic approach to this, which would also
work with the tablet Thinkpads.

I would export the current "tablet mode" status through sysfs (which is
great if your driver keeps state), and send a uevent when the mode
changes (in addition to sending out that input event).

You'd probably need to tag your device in the udev database so that it
can be found and acted upon by user-space (probably a
gnome-settings-daemon plugin in your case).

Cheers

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Daniel Drake]

Post by Bastien Nocera
I think that there's a more generic approach to this, which would also
work with the tablet Thinkpads.
I would export the current "tablet mode" status through sysfs (which is
great if your driver keeps state), and send a uevent when the mode
changes (in addition to sending out that input event).

When we tried to add such an attibute in the past, Dmitry rejected it:
http://article.gmane.org/gmane.linux.drivers.platform.x86.devel/1089

Apart from that, what your suggesting doesn't seem very different from
the earlier outcome here. We seem to have reached a generic solution,
where udev would identify input devices that have SW_TABLET_MODE and
make them accessible to the current seat. Then gnome-settings-daemon
can monitor them for evdev events (similar to the udev event
monitoring that would be necessary in your proposal).

Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Bastien Nocera]

Post by Daniel Drake

Post by Bastien Nocera
I think that there's a more generic approach to this, which would also
work with the tablet Thinkpads.
I would export the current "tablet mode" status through sysfs (which is
great if your driver keeps state), and send a uevent when the mode
changes (in addition to sending out that input event).

http://article.gmane.org/gmane.linux.drivers.platform.x86.devel/1089
Apart from that, what your suggesting doesn't seem very different from
the earlier outcome here. We seem to have reached a generic solution,
where udev would identify input devices that have SW_TABLET_MODE and
make them accessible to the current seat. Then gnome-settings-daemon
can monitor them for evdev events (similar to the udev event
monitoring that would be necessary in your proposal).

If that's the way we're going, then we probably want to have the
tracking and storage of the state done in:
- a udev property (as I did for the accelerometer stuff)
or
- a system-wide D-Bus daemon (exactly like upower does for the lid
status, but obviously, upower seems like the wrong place to do this).

The udev property is easier to put in place, and if Kay doesn't mind it,
it's probably the route I'd go for. This also has the benefit of
allowing the same interface for the Thinkpads.

Cheers

--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Mark Brown]

Post by Daniel Drake
The disadvantage here is that it doesn't work as a global solution to
the problem - every embedded distro in the same situation would have
to add a custom rule thing, and "generic distros" would have no such
solution at this time.
Maybe not such a big deal while OLPC is the only user. But I did come
https://bugs.freedesktop.org/show_bug.cgi?id=43935

We went through the same routine with the jack status in ALSA too (which
has for a long time been reported as input events), where we've now
achieved the glorious triumph of three independant userspace ABIs for
reporting the same information.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html