Communicating tablet mode status to userspace

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

Re: Communicating tablet mode status to userspace

[Alan Cox]

> 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"

Re: Communicating tablet mode status to userspace

[Dmitry Torokhov]

On Tue, Oct 02, 2012 at 04:27:07PM -0600, Daniel Drake wrote:
> 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?

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

Thanks.

-- 
Dmitry

Re: Communicating tablet mode status to userspace

[Greg KH]

On Tue, Oct 02, 2012 at 04:36:41PM -0700, Dmitry Torokhov wrote:
> On Tue, Oct 02, 2012 at 04:27:07PM -0600, Daniel Drake wrote:
> > 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?
> 
> 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

Re: Communicating tablet mode status to userspace

[Daniel Drake]

On Tue, Oct 2, 2012 at 5:36 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> 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

Re: Communicating tablet mode status to userspace

[Greg KH]

On Wed, Oct 03, 2012 at 08:52:31AM -0600, Daniel Drake wrote:
> On Tue, Oct 2, 2012 at 5:36 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > 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

Re: Communicating tablet mode status to userspace

[Kay Sievers]

On Wed, Oct 3, 2012 at 5:05 PM, Greg KH <greg@kroah.com> wrote:
> On Wed, Oct 03, 2012 at 08:52:31AM -0600, Daniel Drake wrote:
>> On Tue, Oct 2, 2012 at 5:36 PM, Dmitry Torokhov
>> <dmitry.torokhov@gmail.com> wrote:
>> > 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

Re: Communicating tablet mode status to userspace

[Daniel Drake]

On Wed, Oct 3, 2012 at 9:23 AM, Kay Sievers <kay@vrfy.org> wrote:
> 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

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

Thanks
Daniel

Re: Communicating tablet mode status to userspace

[Mark Brown]

On Wed, Oct 03, 2012 at 08:52:31AM -0600, Daniel Drake wrote:

> 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

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.

Re: Communicating tablet mode status to userspace

[Bastien Nocera]

Hey Daniel,

On Wed, 2012-10-03 at 10:04 -0600, Daniel Drake wrote:
> On Wed, Oct 3, 2012 at 9:23 AM, Kay Sievers <kay@vrfy.org> wrote:
> > 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
> 
> 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

Re: Communicating tablet mode status to userspace

[Daniel Drake]

On Fri, Oct 5, 2012 at 9:50 AM, Bastien Nocera <hadess@hadess.net> wrote:
> 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

Re: Communicating tablet mode status to userspace

[Bastien Nocera]

On Fri, 2012-10-05 at 10:11 -0600, Daniel Drake wrote:
> On Fri, Oct 5, 2012 at 9:50 AM, Bastien Nocera <hadess@hadess.net> wrote:
> > 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).

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