d-bus method for setting the auto-show option

[Rafael de Pelegrini Soares]

Hi all! Thanks a lot for this nice piece of software.

I'm trying to get a better experience with reversible ultrabooks like the lenovo yoga 11s. When it is in the tablet mode the keyboard should be disabled and onboard should enter on the auto-show mode. When in the regular laptop mode, it should be disabled. This should all be done by some service reading the sensors present in the device. In such service, we could call a d-bus method for enabling/disabling the "auto-show option on when editing text".

I can try to implement this option, just need some directions on which files to inspect.

All the best.

[Jules (juleskondo)]

I am too experiencing this issue. I'll keep an eye on this.

[marmuta (marmuta)]

Onboard's D-Bus service is in Onboard/OnboardGtk.py, class ServiceOnboardKeyboard. It's all python and not too hard to extend. We just have to keep in mind that the interface can't change in incompatible ways after release.

Something like a PauseAutoShow property perhaps. I think the main switch for auto-show should stay untouched, since it's persistent (saved to gsettings). PauseAutoShow would then act on top of i: if auto_show.enabled and not pause_auto_show: do_auto_show ...

If there is a halfway standardized way to get the tablet mode I could imagine adding the whole thing directly to Onboard too. I don't have access to one of these tablet/notebook hybrids, though. Are any D-Bus events generated when switching modes (dbus-monitor)?

[marmuta (marmuta)]

Trunk hides Onboard on physical key-press now. That's not quite what you had in mind yet, but should be an improvement nonetheless.

[Ritesh Raj Sarraf (rrs)]

https://extensions.gnome.org/extension/992/onboard-integration/

I am assuming you are aware of this ?

It, in combination with onboard, gives a perfect experience.

And then the following:
https://extensions.gnome.org/extension/993/slide-for-keyboard/

adds the missing bit.

[Ritesh Raj Sarraf (rrs)]

I think the logic for autoshow of the keyoard should be :

if (soft-keyboard-enabled && textInputField is active):
show onboard.

On many modern devices now (like the Yogas), they come with sensors to detect orientation. And then tools like iio-proxy-daemon, can tap on those signals and do certain tasks

[marmuta (marmuta)]

Thanks for the links, Ritesh. I wasn't aware of the shell extensions. I'd love to try them, but have no idea how to get them installed (on Ubuntu 15.10). The website silently fails to download. Any idea were the source is located?
This could potentially close bug #1306220.

> I think the logic for autoshow of the keyoard should be :
>
> if (soft-keyboard-enabled && textInputField is active):
> show onboard.
This is how it's already supposed to work in most desktop environments. The "if (soft-keyboard-enabled" part is only disabled in GNOME shell and GNOME classic because Onboard would clash with the built-in keyboard there. If you want Onboard to show up when GNOME's "Screen Keyboard" setting is turned on, then remove "--not-show-in=GNOME,GNOME-Classic:GNOME" from /etc/xdg/autostart/onboard-autostart.desktop.
For the second part "&& textInputField is active)" there is Onboard's Preferences->General->Auto show... .

> On many modern devices now (like the Yogas), they come with sensors to detect orientation.
> And then tools like iio-proxy-daemon, can tap on those signals and do certain tasks
There is some support for screen rotation, see bug #911821. We had it mostly working on the Nexus7 before. What Onboard detects is the change in screen resolution. Basically you (or the iio-proxy-daemon package, if it existed) would need to take care of the actual screen rotation (e.g. by running xrandr) and Onboard should already notice and do the right thing. Only drawback I remember is that the transition isn't very pretty. Maybe just try it, and let us know how it goes.

[Ritesh Raj Sarraf (rrs)]

Hello,

On Wed, 2015-12-02 at 11:01 +0000, marmuta wrote:
> Thanks for the links, Ritesh. I wasn't aware of the shell extensions.
> I'd love to try them, but have no idea how to get them installed (on
> Ubuntu 15.10). The website silently fails to download. Any idea were
> the source is located?
> This could potentially close bug #1306220.
>

Those are GNOME Shell Extensions. Since you are on Ubuntu (Unity), it
may not work.

I have extracted the source and shared it at the following link:

https://github.com/rickysarraf/onboard-extension

> > I think the logic for autoshow of the keyoard should be :
> >
> > if (soft-keyboard-enabled && textInputField is active):
> > show onboard.
> This is how it's already supposed to work in most desktop
> environments. The "if (soft-keyboard-enabled" part is only disabled
> in GNOME shell and GNOME classic because Onboard would clash with the
> built-in keyboard there. If you want Onboard to show up when GNOME's
> "Screen Keyboard" setting is turned on, then remove  "--not-show-
> in=GNOME,GNOME-Classic:GNOME" from /etc/xdg/autostart/onboard-
> autostart.desktop.
> For the second part "&& textInputField is active)" there is Onboard's
> Preferences->General->Auto show... .
>

Yeah!! I guess GNOME Upstream still thinks they do the best designs.
And that their design decisions are always correct. Perhaps a very good
reason, why Linux still sucks as a generic desktop product.

I already filed a bug with GNOME Upstream expressing my concern of them
being technically very monolithic.

https://bugzilla.gnome.org/show_bug.cgi?id=741351

I am hopeful things might change. Not sure when though.

> > On many modern devices now (like the Yogas), they come with sensors
> > to detect orientation.
> > And then tools like iio-proxy-daemon, can tap on those signals and
> > do certain tasks
> There is some support for screen rotation, see bug #911821. We had it
> mostly working on the Nexus7 before. What Onboard detects is the
> change in screen resolution. Basically you (or the iio-proxy-daemon
> package, if it existed) would need to take care of the actual screen
> rotation (e.g. by running xrandr) and Onboard should already notice
> and do the right thing. Only drawback I remember is that the
> transition isn't very pretty. Maybe just try it, and let us know how
> it goes.
>

I already am maintaining iio-sensor-proxy for Debian. So you may soon
see it on Ubuntu, as an obvious effect.

https://packages.qa.debian.org/i/iio-sensor-proxy.html

And yes, the current dependency is on xrandr extensions. For GNOME (+
Lenovo Yoga 2 13, what I use), this already works. But the iio-sensor-
proxy daemon only taps sensor data and accordingly informs the state
over dbus. Interested parties (in this case, Mutter Window Manager) act
on those events, and thus you see screen orientation change when you
tilt the Lenovo Yoga. FY: You'll need GNOME 3.18 to try this out.

My immediate goal is to see if I can get onboard a possible 1st class
replacement for Caribou. And onboard as also a 1st class soft keyboard
for generic Desktop Environments.

If you get the GNOME SHell Extension improvements into onboard upstream
itself, it'd definite...

[marmuta (marmuta)]

Thank you, that worked. I just had to change metadata.json to
"shell-version": [
    "3.16", "3.18"
  ],
as Wily apparently still has gnome-shell 3.16. I suppose that's why the gnome extension website didn't want to install before. It would have been nice to get notified of the version mismatch, though... And yes, I did switch to the gnome-shell session before trying.

The onboard-integration extension does indeed work, however I feel there's room for improvement. The extension switches to caribou for the overview, which is quite clever, but that means Onboard isn't fully integrated yet. Worse though, there's no keyboard for password prompts (e.g. for gparted), so bug #1306220 is not quite fixed yet.

Further, due to the extension showing and hiding Onboard, the auto-show behavior is is different from Onboard's. This wouldn't necessarily be a bad thing, but now, like GNOME's keyboard, Onboard gets stuck hanging around a lot when widgets have long lost focus. At the moment I feel our auto-show does a slightly better job. Maybe things changed already in GNOME shell 3.18, though, I haven't tried there.

Onboard's own auto-show should better be disabled too in preferences, because it is now overruled by D-Bus commands, which seems to lead to jerky transparency effects when showing/hiding.

I think one quick improvement could be to drop the D-Bus show/hide commands and leave auto-show to Onboard. For full integration in overview and password dialogs we would probably have to figure out how GNOME's keyboard does it.

> I already am maintaining iio-sensor-proxy for Debian. So you may soon
> see it on Ubuntu, as an obvious effect.Ah, good to hear.
Ah, good to hear. If I get a chance to try it, I will.

> My immediate goal is to see if I can get onboard a possible 1st class
> replacement for Caribou.
I think the Onboard team (me and Francesco, lately) would definitely support this. Ideally we would be able to simply select one out of a number of available keyboards. I feel this will be an uphill battle, though.

> If you get the GNOME SHell Extension improvements into onboard upstream itself, it'd definite...
@Francesco, what do you think? Hypothetically, would a suggests dependency to a new, say, onboard-gnome package make sense? We would need to get permission from the original extension author of course and then see what can be done for better integration.

[Francesco Fumanti (frafu)]

On 2015-12-04 00:22, marmuta wrote:
> I think the Onboard team (me and Francesco, lately) would definitely support this.

+1

>> My immediate goal is to see if I can get onboard a possible 1st class
>> replacement for Caribou.
> Ideally we would be able to simply select one out of a number of available keyboards. I feel this will be an uphill battle, though.

Once Onboard plays nicely with GNOME, it might be easier to get support from Upstream GNOME for it, as Onboard could be seen as a temporary solution until caribou has been improved.

>> If you get the GNOME SHell Extension improvements into onboard upstream itself, it'd definite...
> @Francesco, what do you think? Hypothetically, would a suggests dependency to a new, say, onboard-gnome package make sense? We would need to get permission from the original extension author of course and then see what can be done for better integration.

I am now taking the use case of people into account, that are installing GNOME alongside unity in Ubuntu.

If I get it right, according to the debian policy, a package (the onboard package) should work also if a suggest dependency (the onboard-gnome package, once it exists) is not installed. But, I suppose that onboard will not work properly in GNOME without the onboard-gnome extension. So, the onboard-gnome package should probably rather be a Recommends, if not even a Depends. A depends on the onboard-gnome package in the default onboard package might not be possible as I don't expect an onboard-gnome package to enter the main repository.

That does not mean that we cannot add a suggest; as a hint for the maintainers of the GNOME metapackage package to add a Depends on onboard-gnome in the GNOME metapackage package. In fact, I think the right place for the onboard-gnome dependency is the GNOME metapackage in this use case.

I would also suggest to add a few sentences about it in the Readme of Onboard.

Finally, we can also contact the people maintaining the GNOME metapackage about it, once the onboard-gnome package is available.

[Ritesh Raj Sarraf (rrs)]

On Fri, 2015-12-04 at 11:59 +0000, Francesco Fumanti wrote:
> On 2015-12-04 00:22, marmuta wrote:
> > I think the Onboard team (me and Francesco, lately) would
> > definitely support this.
>
> +1
>
> > > My immediate goal is to see if I can get onboard a possible 1st
> > > class
> > > replacement for Caribou.
> > Ideally we would be able to simply select one out of a number of
> > available keyboards. I feel this will be an uphill battle, though.
>
> Once Onboard plays nicely with GNOME, it might be easier to get
> support
> from Upstream GNOME for it, as Onboard could be seen as a temporary
> solution until caribou has been improved.
>

Yes. I guess so. Or rather I'd like to see it more as, "2 available
choices".

> > > If you get the GNOME SHell Extension improvements into onboard
> > > upstream itself, it'd definite...
> > @Francesco, what do you think? Hypothetically, would a suggests
> > dependency to a new, say, onboard-gnome package make sense? We
> > would need to get permission from the original extension author of
> > course and then see what can be done for better integration.
>
> I am now taking the use case of people into account, that are
> installing
> GNOME alongside unity in Ubuntu.
>
> If I get it right, according to the debian policy, a package (the
> onboard package) should work also if a suggest dependency (the
> onboard-
> gnome package, once it exists) is not installed. But, I suppose that
> onboard will not work properly in GNOME without the onboard-gnome
> extension. So, the onboard-gnome package should probably rather be a
> Recommends, if not even a Depends. A depends on the onboard-gnome
> package in the default onboard package might not be possible as I
> don't
> expect an onboard-gnome package to enter the main repository.
>
> That does not mean that we cannot add a suggest; as a hint for the
> maintainers of the GNOME metapackage package to add a Depends on
> onboard-gnome in the GNOME metapackage package. In fact, I think the
> right place for the onboard-gnome dependency is the GNOME metapackage
> in
> this use case.
>
> I would also suggest to add a few sentences about it in the Readme of
> Onboard.
>
> Finally, we can also contact the people maintaining the GNOME
> metapackage about it, once the onboard-gnome package is available.
>

So, I'm assuming you guys are okay with the code/logic of what the
shell extensions are doing ? And that you'll add the same into onboard,
as a gnome plugin/enhancement/extension ?

And then, individual distributions will decide on how they want to
build the relationship of the packages, which will be mostly in line
with what you've described above ?

--
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."

[marmuta (marmuta)]

> So, I'm assuming you guys are okay with the code/logic of what the
> shell extensions are doing ? And that you'll add the same into onboard,
>as a gnome plugin/enhancement/extension ?
Again, I'm principally for adding some kind of GNOME shell integration to the Onboard's project, but I feel this particular extension isn't ready yet. I've listed most of the issues I have with the existing code in #8. To summarize, I believe we'd need (highest to lowest importance):
  - Onboard at password prompts
  - Onboard in overview
  - to keep Onboard's auto-show

> And then, individual distributions will decide on how they want to
> build the relationship of the packages, which will be mostly in line
> with what you've described above ?
We would add Debian packaging, as Francesco described above, to the Onboard project. I consider this mainly a suggestion, though. Ubuntu happens to mostly pick our packaging up as is, but in general distributions are free to ignore this and provide their own.

The question for me is now, who's going to improve the extension? While I'm willing to help, I'm reluctant to do this kind of desktop specific work myself. Would you like to contact the original author or perhaps even try yourself?

[Francesco Fumanti (frafu)]

@ Ritesh Raj Sarraf

I don't have the knowledge to judge whether the extension is in good shape or not. According to marmuta's tests, the extension is not really ready yet, and I do agree with marmuta that the gnome-integration of Onboard is welcome under the condition that it is behaving and working properly in the various areas of the GNOME desktop environment.

To reiterate marmuta's last paragraph here above, we need somebody that works on the extension in order to improve it and that communicates with him about it.

The question about packaging it for the distribution will probably be a lesser problem that can be solved later.

[Ritesh Raj Sarraf (rrs)]

On Sun, 2015-12-06 at 23:11 +0000, marmuta wrote:
> > So, I'm assuming you guys are okay with the code/logic of what the
> > shell extensions are doing ?  And that you'll add the same into
> onboard,
> >as a gnome plugin/enhancement/extension ?
> Again,  I'm principally for adding some kind of GNOME shell
> integration to the Onboard's project, but I feel this particular
> extension isn't ready yet. I've listed most of the issues I have with
> the existing code in #8. To summarize, I believe we'd need (highest
> to lowest importance):
>   - Onboard at password prompts
>   - Onboard in overview
>   - to keep Onboard's auto-show
>

Agreed. And that is why I've filed the other bug with GNOME. Like I've
explained there, there is no simple way of disabling a component in
favor of another. And the side-effect of those are what you've listed
above.

> > And then, individual distributions will decide on how they want to
> > build the relationship of the packages, which will be mostly in
> line
> > with what you've described above ?
> We would add Debian packaging, as Francesco described above, to the
> Onboard project. I consider this mainly a suggestion, though. Ubuntu
> happens to mostly pick our packaging up as is, but in general
> distributions are free to ignore this and provide their own.
>
> The question for me is now, who's going to improve the extension?
> While
> I'm willing to help, I'm reluctant to do this kind of desktop
> specific
> work myself. Would you like to contact the original author or perhaps
> even try yourself?

My first attempt was to push it to you guys. :-)
I'm surprised though that, as upstream, you aren't keen in ensuring
proper integration of your project into major Desktop Shells.

Onboard is pretty good. But I did not know about it. I only explored it
because I was fed up with Caribou, in its current state. I don't think
many (GNOME) users would be knowing about Onboard. And from what I've
grokked so far, neither is it a KDE project.

I recently moved to GNOME (10+ years I was using KDE) because of its
Touchscreen support. Diving into GNOME internals is definitely on my
list, but I don't know when I'd do that.

I think the best right now is to leave it as is. Until me, or the
original author, or someone else, comes back to you with a proper patch
and assurance to maintain it.

--
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."

[Francesco Fumanti (frafu)]

> My first attempt was to push it to you guys. :-)
> I'm surprised though that, as upstream, you aren't keen in ensuring
> proper integration of your project into major Desktop Shells.

It is more a problem of lack of resources than of willingness to do it. For quite some time, there has only been marmuta working on Onboard's code. In this situation, I think that it is better to concentrate on Onboard's integration into the desktop we are actively using, than trying to target to many desktops, resulting in a bad integration because we don't have the necessary resources.

[marmuta (marmuta)]

> I'm surprised though that, as upstream, you aren't keen in ensuring
> proper integration of your project into major Desktop Shells.
This is one way to see it. Or one can see it as a single desktop environment erecting barriers of entry that don't exist in any of the others. We aim to keep Onboard usable across desktops and I do even test on GNOME shell and classic to fix things there as they crop up. Where I've drawn the line in the past, was when GNOME made it impossible for anything but extensions to type into password dialogs.

> Onboard is pretty good.
Glad you like it, if you find any issues just let us know.
> But I did not know about it.
As I see it, It's not necessarily on us to promote Onboard for GS. The GNOME people seemed content with what they had in the past, and we went out of our way to allow happy coexistence with their keyboard. If there's ever a change of mind and renewed interest in alternative keyboards, we'll be ready to support them.

> I think the best right now is to leave it as is. Until me, or the
> original author, or someone else, comes back to you with a proper patch
> and assurance to maintain it.
As I mentioned to Francesco, I'd even offer to maintain it. We'd just need an extension that works initially. Original author and license (preferably GPLv3) stay honoured of course.

[Simon Schumann (simon-schumann)]

Hi Guys,

I'm the author of the two Gnome Shell extensions mentioned above, the sole reason I didn't reply on this thread so far is that I wasn't are of it. (Thanks to Ritesh Raj Sarraf for leaving a note on my github repo!)

The repos are here:
https://github.com/schuhumi/gnome-shell-extension-onboard-integration
https://github.com/schuhumi/gnome-shell-extension-slide-for-keyboard

While "slide for keyboard" is a very sound implementation, onboard integration is a little hacky..

A few notes about where it's at:
 - The bug where no keyboard is shown in password entry fields (like wifi password) has been fixed a week ago
 - The extension is programmed to show Caribou for all text fields that are part of the Gnome Shell itself. The reason is that Onboard doesn't work in places like the aktivity overview (it is not being shown). This is an Onboard bug! I didn't focus much on finding the culprint though as typing in your wifi password or the name of the application you're searching for is fine to do with Caribou.
 - Show/Hide doesn't work perfectly as it is not so easy to switch between Caribou and Onboard on the fly while keeping track of what is visible etc.

I'm not totally happy with the current state either, but I'm very willing to work with you guys to improve the situation. Especially with
> I think the Onboard team (me and Francesco, lately) would definitely support this.
One of the things that comes to my mind is implementing dbus flags that indicate whether Onboard is visible or not (maybe they're already there, but I certainly couldn't find them), as far as I remember that was one of the problems I ran into when writing the extension.

One more question on the side: How's Onboard support for Wayland? It doesn't seem to work for me (only question marks on all keys and the position on the screen isn't right either)

[marmuta (marmuta)]

Hi Simon, welcome and thanks for the official github links.

> I'm not totally happy with the current state either,
> but I'm very willing to work with you guys to improve the situation.
Sounds great. I've tried the latest from git and could indeed enter passwords since you're switching to GNOME's keyboard there too now.

> The reason is that Onboard doesn't work in places like the
> aktivity overview (it is not being shown). This is an Onboard
> bug! I didn't focus much on finding the culprint though as
> typing in your wifi password or the name of the application
> you're searching for is fine to do with Caribou.
I agree that falling back to Caribou mostly does the job now. However, I believe we'd need to push a little further if we want to offer Onboard as, quoting Ritesh, a "1st class replacement for Caribou".

AFAIK regular applications, and that's what Onboard is, can't be shown in overview and password dialogs. You call this a bug and you might be right, but then it's one we can't fix from Onboard. As I understand it, only shell extensions have the ability to place windows in overview and password screens. Obviously, the Caribou integration does that successfully already, so we know it is possible somehow. We'd need to figure out how to create those windows from JavaScript and then possibly re-parent Onboard into them. Maybe using Xembed, that's what Onboard supports with "onboard --xid", but I'm Not sure if that can work on Wayland.

> One of the things that comes to my mind is implementing
> dbus flags that indicate whether Onboard is visible or not
There's a read-only D-Bus property "Visible" you can query. Onboard's README has an example. https://bazaar.launchpad.net/~onboard/onboard/trunk/view/head:/README#L65

> One more question on the side: How's Onboard support for Wayland?
Good question. It shouldn't immediately crash anymore, but is otherwise pretty much unusable in Wayland. There's plenty of core functionality that relies on X extensions - XTest, XKb, XInput, you name it. Finding replacements on Wayland or MIR will be quite an effort. We were hoping to drag it out until there's at least a clear (and mature) winner we can focus on. I suppose "1st class replacement for Caribou" wouldn't go far without Wayland support, though.

[Ritesh Raj Sarraf (rrs)]

Hi @marumata,

I just tried onboard 1.3 in Debian.

Were there any reasons why the 2nd extension [1] was not included into onboard? I think this one too is a good addition. And, in parts, it does try to address the "onboard not available in overview" mode.

[1] https://extensions.gnome.org/extension/993/slide-for-keyboard/

[marmuta (marmuta)]

Ritesh, no special reason, other than that extension already existed. If Simon doesn't mind, I'll still add it to gnome-shell-extension-onboard.

I would be surprised if the extension addressed the "onboard not available in overview" issue, though. In my testing, showing Onboard wasn't possible at all in the overview, only at password prompts, and there it became unresponsive. Our extension does what Simon's here does
https://github.com/schuhumi/gnome-shell-extension-onboard-integration
that is, showing Caribou whenever Onboard can't do it.

I believe we can improve on this only with a clutter frontend. I had actually worked on this for a while, but it stalled at maybe 50% progress. It's a huge can of worms.

[marmuta (marmuta)]

@Ritesh, I've added the edge-drag gesture to trunk. There is a new preferences dialog too, where it can be turned off. To reach the dialog run gnome-shell-extension-prefs and click the settings icon of Onboard Indicator.

Thanks for the suggestion.

[RussianNeuroMancer (russianneuromancer)]

> I've added the edge-drag gesture to trunk.
Is it possible to build new development snapshot in PPA to actually test it out? Since Onboard extension is doesn't work in Wayland session for now, I hope it will be alternative way to call Onboard in Wayland.

[marmuta (marmuta)]

Snapshot will be ready soon.

I haven't even tried the extension in Wayland yet, because Onboard itself is still unusable there. I've been making progress in 1.3. Theoretically typing with the new uinput backend should work in Wayland. The problem is, that the keyboard window is getting focused on click, and any key-strokes generated go to Onboard itself. We need gdk_wayland_window_set_accept_focus to be implemented. That function is still a stub, I just checked again.
https://git.gnome.org/browse/gtk+/tree/gdk/wayland/gdkwindow-wayland.c#n3102

[marmuta (marmuta)]

Francesco uploaded revision 2195 of trunk to the Snapshots PPA for xenial, yakkety and zesty. You can find it at
https://launchpad.net/~onboard/+archive/ubuntu/snapshots

[RussianNeuroMancer (russianneuromancer)]

Thanks for upload! Gesture is working, Wayland is not tested yet, but seems like this doesn't make sense until gdk_wayland_window_set_accept_focus implemented:
> That function is still a stub, I just checked again.

[marmuta (marmuta)]

Thanks for testing. Good to hear the gesture works.

[RussianNeuroMancer (russianneuromancer)]

By the way, isn't https://wiki.linuxfoundation.org/accessibility/d-bus is solution of this bugreports?

[marmuta (marmuta)]

We're already using AT-SPI2 on D-Bus for auto-show, word-suggestions and auto-capitalization, but I'm not sure it can help with detecting tablet-mode. At least I haven't found anything in that direction.

/etc/acpi/events/ seems more promising. As I understand it, devices can generate key-strokes on rotation and/or changing from/to tablet-mode. One can then run arbitrary scripts when that happens. See for example
https://bugs.launchpad.net/ubuntu/+source/acpid/+bug/1210823

There doesn't seem to exist a standardized interface for all possible devices, though. Each might have its own set of events. We probably can't easily add that part to Onboard.

Unless someone runs tests on a convertible device, that is. Perhaps dbus-monitor can uncover some action when tablet-mode is entered/left.

What we could do is add PauseAutoshow() (as mentioned in #2) to Onboard's D-Bus interface, ready to be called from scripts in /etc/acpi/events/.

[Ritesh Raj Sarraf (rrs)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Mon, 2016-12-05 at 14:58 +0000, marmuta wrote:
> We're already using AT-SPI2 on D-Bus for auto-show, word-suggestions and
> auto-capitalization, but I'm not sure it can help with detecting tablet-
> mode. At least I haven't found anything in that direction.
>

Yes. I use this mode, here, on Debian too.

> /etc/acpi/events/ seems more promising. As I understand it, devices can
> generate key-strokes on rotation and/or changing from/to tablet-mode. One can
> then run arbitrary scripts when that happens. See for example
> https://bugs.launchpad.net/ubuntu/+source/acpid/+bug/1210823
>

Umm.. I'm not sure if acpi events really trap that event.

On my Debian box, these are the contents. And these are all provided by Laptop
Mode Tools, which is only involved for power savings.

rrs@learner:/var/tmp$ ls /etc/acpi/events/
lm_ac_adapter  lm_battery  lm_lid
2016-12-05 / 23:42:07 ♒♒♒  ☺

> There doesn't seem to exist a standardized interface for all possible
> devices, though. Each might have its own set of events. We probably
> can't easily add that part to Onboard.
>
> Unless someone runs tests on a convertible device, that is. Perhaps
> dbus-monitor can uncover some action when tablet-mode is entered/left.
>
> What we could do is add PauseAutoshow() (as mentioned in #2) to
> Onboard's D-Bus interface, ready to be called from scripts in
> /etc/acpi/events/.

I don't have the full context, but as I understand, you are looking for a way to
determine if the convertible is in normal or table mode.

Are you looking for something like the following ?

Connected to D-Bus.

Received reply from :1.5
  Arguments: [Variant(QString): "normal"]
Received reply from :1.5
  Arguments: [Variant(QString): "right-up"]
Received reply from :1.5
  Arguments: [Variant(QString): "bottom-up"]
Received reply from :1.5
  Arguments: [Variant(QString): "normal"]

iio-sensor-proxy can provide orientation information over dbus, provided your
device has the supported sensors.

PS: I have a convertible laptop (Lenovo Yoga 2 13). If there is anything I can
help with to improve onboard, please let me know. But the OS running on it will
be Debian.

- --
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEQCVDstmIVAB/Yn02pjpYo/LhdWkFAlhFr/0ACgkQpjpYo/Lh
dWlLfQ/+IG9b9Vp30QHeBnsjcHKfhpbda1rm6Nfk3aN8Y9GegNM/5JkePr8muBzu
6DKrtkI0v6BY5LMSM5RoDLKF4RYdvG0RCWOD1OZ7LXkrvyHewm5Nz0Rczky+KqFM
HPqdlDZBfAGMqfJUOUc6E7JwvC1pm+xlGLIxjBauc20vz6l83Hd787VemDsoTHPO
4qm08NEScRTh6b8yl/cIdojbSMhRPVAPBZkp28WAr12lyf9/3ssKrwKeFVHgFSns
Wi/ETaktFvc4oJfDlR1a3KgnNSmxna9b0PtfhCbg73mvBpGMYcaOWB+3dtX5eDp3
jLjnUKvlHOYfDvTuFO/VdKnIB/ZiqB3AnuyuNbYpJNVb/gMBjhalcIn0PuCx3Znt
yEtIe7aLHroPvkubvbpj1z7sAeifS27Okg73rxRTSngmy03odryjJoiOqpzNXpw4
twdG9zbL2RFx1u6GINMSaxDK+/iSSCbG1Kn3sMCYL6dY1Y+xY+2wueycHbMcQKe8
FhUI5cLQ3nVtkI3fR5juO1XLsG3Y96mewctKQqKjvHF2pDgOIZEnD1zSM9R1jhCm
ACVT6x+IHneNARD04OEhv91StGqkyzqBU9zdRymhzSi2WIdHCqSdHxYjkQmmj9E7
GcPKnaiz9Y0aFT+hfYkR8FjuI7FbsdurZh18WvnmE6WvYSrzP9s=
=DHgZ
-----END PGP SIGNATURE-----

[marmuta (marmuta)]

> Yes. I use this mode, here, on Debian too.
Do you mean you can query if your system is in tablet-mode through AT-SPI?

> Umm.. I'm not sure if acpi events really trap that event.
I'm not sure either, it just seemed like a logical place to look at.

There's a bit more stuff in /etc/acpi/events on my Ubuntu Zesty system
ll /etc/acpi/events/
total 36K
-rw-r--r-- 1 root root 271 Mai 1 2013 asus-keyboard-backlight-down
-rw-r--r-- 1 root root 265 Mai 1 2013 asus-keyboard-backlight-up
-rw-r--r-- 1 root root 73 Mai 1 2013 asus-wireless-off
-rw-r--r-- 1 root root 72 Mai 1 2013 asus-wireless-on
-rw-r--r-- 1 root root 223 Mai 1 2013 ibm-wireless
-rw-r--r-- 1 root root 67 Mai 1 2013 lenovo-undock
-rw-r--r-- 1 root root 423 Apr 3 2014 powerbtn
-rw-r--r-- 1 root root 277 Mai 1 2013 thinkpad-cmos
-rw-r--r-- 1 root root 222 Mai 1 2013 tosh-wireless

Also, the bug report I linked above uses scripts in this directory for exactly what we need - calling stuff when tablet-mode is entered or left.

> Are you looking for something like the following ?
>
> Connected to D-Bus.
>
> Received reply from :1.5
> Arguments: [Variant(QString): "normal"]
> Received reply from :1.5
> Arguments: [Variant(QString): "right-up"]
Possibly, this output seems to be related more to device orientation though. I'm not sure that's sufficient to detect the laptop-mode/tablet-mode switch. What object, interface and property is this coming from? You should be able to find that printed somewhere above that snippet.

I've been reading a bit. The Yoga 2 is advertised as having four distinct modes: Laptop, Tablet, Tent, Stand. I'm unclear about how much of that can be detected by software, but if there exist one or more hardware switches supported by the linux kernel, then I believe they would have to be visible in /dev/input.

Apparently there used to exist a /proc/acpi/event, but that has been deprecated and replaced by evdev devices in /dev/input.

acpid reads from /dev/input/event* and maps key-strokes generated by system buttons to actions and scripts in /etc/acpi/events/.

I would try the following:
sudo systemctl stop acpid # shutdown acpid
sudo acpid --foreground --debug --logevents # restart with logging

That should give a log of events being received and actions executed.
Then fold the device to laptop configuration and back to tablet-mode. Does it print anything interesting in either case?

There's also kacpimon you can try. Maybe that one catches more events, I'm not sure.
sudo systemctl stop acpid # shutdown acpid
sudo kacpimon
Same, move screen to laptop-mode and back to tablet-mode and see if there is anything helpful in the output (or attach everything here).

[Ritesh Raj Sarraf (rrs)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Mon, 2016-12-05 at 21:23 +0000, marmuta wrote:
> > Yes. I use this mode, here, on Debian too.
>
> Do you mean you can query if your system is in tablet-mode through AT-SPI?
>

No. I meant I use these tools for a soft keyboard working across applications
from different toolkits.

> > Umm.. I'm not sure if acpi events really trap that event.
>
> I'm not sure either, it just seemed like a logical place to look at.
>
> There's a bit more stuff in /etc/acpi/events on my Ubuntu Zesty system
> ll /etc/acpi/events/
> total 36K
> -rw-r--r-- 1 root root 271 Mai  1  2013 asus-keyboard-backlight-down
> -rw-r--r-- 1 root root 265 Mai  1  2013 asus-keyboard-backlight-up
> -rw-r--r-- 1 root root  73 Mai  1  2013 asus-wireless-off
> -rw-r--r-- 1 root root  72 Mai  1  2013 asus-wireless-on
> -rw-r--r-- 1 root root 223 Mai  1  2013 ibm-wireless
> -rw-r--r-- 1 root root  67 Mai  1  2013 lenovo-undock
> -rw-r--r-- 1 root root 423 Apr  3  2014 powerbtn
> -rw-r--r-- 1 root root 277 Mai  1  2013 thinkpad-cmos
> -rw-r--r-- 1 root root 222 Mai  1  2013 tosh-wireless
>
> Also, the bug report I linked above uses scripts in this directory for
> exactly what we need - calling stuff when tablet-mode is entered or
> left.
>

Yes. This goes with the assumption that acpid will be a dependency. I, for
example, have built my setup without the acpid daemon.

For events, I simply rely on udev.

>
> > Are you looking for something like the following ?
> >
> > Connected to D-Bus.
> >
> > Received reply from :1.5
> >   Arguments: [Variant(QString): "normal"]
> > Received reply from :1.5
> >   Arguments: [Variant(QString): "right-up"]
>
> Possibly, this output seems to be related more to device orientation though.
> I'm not sure that's sufficient to detect the laptop-mode/tablet-mode switch.
> What object, interface and property is this coming from? You should be able to
> find that printed somewhere above that snippet.
>

net.hadess.SensorProxy over the system bus.
And the property is: AccelerometerOrientation

Currently, it does not have any such property like, say, DeviceMode. Maybe
something iio-sensor-proxy could add ?

> I've been reading a bit. The Yoga 2 is advertised as having four
> distinct modes: Laptop, Tablet, Tent, Stand. I'm unclear about how much
> of that can be detected by software, but if there exist one or more
> hardware switches supported by the linux kernel, then I believe they
> would have to be visible in /dev/input.
>

None to the best of my knowledge.

> Apparently there used to exist a /proc/acpi/event, but that has been
> deprecated and replaced by evdev devices in /dev/input.
>
> acpid reads from /dev/input/event* and maps key-strokes generated by
> system buttons to actions and scripts in /etc/acpi/events/.
>

±

There is this key code (mentioned above) that is registered when getting into
tablet mode. But that is pretty much it. No similar stuff when switching back to
normal mode.

Below are the list of events. NOthing reliable to base assumptions on.

KERNEL[19987.255649] add      /devices/pci0000:00/0000:00:14.0/usb2/2-4 (usb)
KERNEL[19987.256792] add      /devices/pci0000:00/0000:0...

[Ritesh Raj Sarraf (rrs)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Tue, 2016-12-06 at 14:08 +0530, Ritesh Raj Sarraf wrote:
> ±
>
> There is this key code (mentioned above) that is registered when getting into
> tablet mode. But that is pretty much it. No similar stuff when switching back
> to
> normal mode.

I think this may be related to:

[20367.857101] atkbd serio0: Unknown key pressed (translated set 2, code 0xbe on
isa0060/serio0).
[20367.857106] atkbd serio0: Use 'setkeycodes e03e <keycode>' to make it known.
[20367.866192] atkbd serio0: Unknown key released (translated set 2, code 0xbe
on isa0060/serio0).
[20367.866197] atkbd serio0: Use 'setkeycodes e03e <keycode>' to make it known.
2016-12-06 / 14:08:52 ♒♒♒  ☺

which is triggered only when getting into Table Mode.

- --
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEQCVDstmIVAB/Yn02pjpYo/LhdWkFAlhGeWkACgkQpjpYo/Lh
dWn4Hw/+JBP/z66zYWaVQrpVJT80P9ehqY1b04mulPzaOhJsmgNLiDvxpjtcA+89
NWP0OSt+jpPYygr26rtKIN4rh42gsD129bQ+O21gwZi/DK66uIkzlkcMpfZb3xfp
4eFoNz4XZzq8CZBo3hFrlMw0r9AW6YoHJRb5S4E3YkWrPB97rLsTaZPWu2eFdSpX
CpWsxYXhie6QFHGUWzHA5AQEGVVaQZa3BQULcS7R3Tj+l2jtSK0l5jYAvwwkabsZ
dE/emltamg01rTRcGxp57AXRUeAFji/ECDassNG95LLRJDZcd+H8Bpon9lz0x3fP
upzJE9dJXrX9wYNMVgjYXYUDZcNOSO4FixpDZ0Vo36NWMYzdFyGyRIJGuTl/v359
JkncYyCFpBOa1d6iTwj7CeetVSHlcYFGwLwEPu09RXML2fio92jwhKIL7DhYomuh
q5Wu6RPUoVj+LC6zrFoxVLREJyVRJFubWndPE69VbCKE1XZ66HtpN3SbrCSmRxYC
J7pXk1ACMufOdYPmhkDG3mw/OiDQdFbGwGmKPGWNYle6/Ayz7f1qfymUbFHzB/yU
SI8jERV3RgwbTj8m5LVoSCtuv8OPiis1aewVdlk7lGkKMEhax5FlpOFdwCRzPQz4
lgdX1V6Wbug4qix4CMWE9kWq7+S7eoarr2vTfK6HYEqBvYGsTiQ=
=WhXf
-----END PGP SIGNATURE-----

[RussianNeuroMancer (russianneuromancer)]

By the way, there is discussion about mode detection in Toolkit section: https://wiki.gnome.org/Design/OS/Touchscreen

Also, intel-vbtn driver (used on Dell Venue 11 Pro 7140 tablet) developer talks that he could implements docking/undocking event in his driver, but now it's not implemented yet.

[marmuta (marmuta)]

There was an update to https://bugs.launchpad.net/bugs/989419 today, which had me thinking if tablet-mode could be detected by a disabled/missing keyboard device. I came across this for the Yoga 2 before:
"The keyboard and touch pad are automatically locked when the screen is opened beyond 190 degrees (approximately).".
Is this possibly done in "hardware" or still by some (Windows) driver reading a sensor in software?

@Ritesh, could you check if the list of evdev or xinput devices changes between tablet- and laptop mode?
$ sudo evtest
$ xinput

[marmuta (marmuta)]

Also I skimmed through some of the kernel 4.9 sources but haven't found anything potentially useful yet.
intel-vbtn.c really seems to handle power buttons only.
acpi/button.c which creates the "Lid Switch" evdev appears to only handle lid switches with two positions, open and closed, for laptops presumably.
drivers/platform/x86/ideapad-laptop.c references the Yoga 2 and exposes a number of sensors, but AFAICT nothing concerning detection of tablet-mode.

@RussianNeuroMancer https://wiki.gnome.org/Design/OS/Touchscreen talks about detecting keyboard devices to detect the mode. Do we know that this is sufficient? Could you too check if the list of devices changes between tablet and laptop-mode?
$ sudo evtest
$ xinput

[Ritesh Raj Sarraf (rrs)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Sat, 2016-12-10 at 17:00 +0000, marmuta wrote:
> There was an update to https://bugs.launchpad.net/bugs/989419 today, which had
> me thinking if tablet-mode could be detected by a disabled/missing keyboard
> device. I came across this for the Yoga 2 before:
> "The keyboard and touch pad are automatically locked when the screen is opened
> beyond 190 degrees (approximately).".

I've tried hard to find a simple way. But unfortunately, no. I've not been able
to come up with anything. And this is just for my hardware. I'm not sure if
other variants, and other hardware, will have different issues.

> Is this possibly done in "hardware" or still by some (Windows) driver reading
> a sensor in software?
>

Initially, when I was investigating the iio sensor support for the kernel, I
believe reading somewhere that the 4 modes (Normal, Tent, Tablet, ....) were
done in Lenovo Software, and NOT by Windows. Which could be true, because this
laptop was factory installed with Windows 8.

> @Ritesh, could you check if the list of evdev or xinput devices changes
> between tablet- and laptop mode?
> $ sudo evtest
> $ xinput

Here are the outputs. No device listings change.

rrs@learner:~$ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ ELAN Touchscreen id=9 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=13 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
    ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
    ↳ Power Button id=6 [slave keyboard (3)]
    ↳ Video Bus id=7 [slave keyboard (3)]
    ↳ Power Button id=8 [slave keyboard (3)]
    ↳ Lenovo EasyCamera id=10 [slave keyboard (3)]
    ↳ Ideapad extra buttons id=11 [slave keyboard (3)]
    ↳ AT Translated Set 2 keyboard id=12 [slave keyboard (3)]
2016-12-11 / 00:06:33 ♒♒♒ ☺
rrs@learner:~$ Now switching to Tablet Mode^C
2016-12-11 / 00:06:47 ♒♒♒ ☹ => 130
rrs@learner:~$ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ ELAN Touchscreen id=9 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=13 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
    ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
    ↳ Power Button id=6 [slave keyboard (3)]
    ↳ Video Bus id=7 [slave keyboard (3)]
    ↳ Power Button id=8 [slave keyboard (3)]
    ↳ Lenovo EasyCamera id=10 [slave keyboard (3)]
    ↳ Ideapad extra buttons id=11 [slave keyboard (3)]
    ↳ AT Translated Set 2 keyboard id=12 [slave keyboard (3)]
2016-12-11 / 00:07:14 ♒♒♒ ☺
...

[Ritesh Raj Sarraf (rrs)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Sat, 2016-12-10 at 17:17 +0000, marmuta wrote:
> Also I skimmed through some of the kernel 4.9 sources but haven't found
> anything potentially useful yet.
> intel-vbtn.c really seems to handle power buttons only.
> acpi/button.c which creates the "Lid Switch" evdev appears to only handle lid
> switches with two positions, open and closed, for laptops presumably.
> drivers/platform/x86/ideapad-laptop.c references the Yoga 2 and exposes a
> number of sensors, but AFAICT nothing concerning detection of tablet-mode.

Here's something very interesting I've found.

rrs@learner:~$ sudo evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0: AT Translated Set 2 keyboard
/dev/input/event1: Power Button
/dev/input/event2: Lid Switch
/dev/input/event3: Power Button
/dev/input/event4: Video Bus
/dev/input/event5: SynPS/2 Synaptics TouchPad
/dev/input/event6: Ideapad extra buttons
/dev/input/event7: PC Speaker
/dev/input/event8: HDA Digital PCBeep
/dev/input/event9: HDA Intel PCH Mic
/dev/input/event10: HDA Intel PCH Front Headphone
/dev/input/event11: HDA Intel HDMI HDMI/DP,pcm=3
/dev/input/event12: HDA Intel HDMI HDMI/DP,pcm=7
/dev/input/event13: HDA Intel HDMI HDMI/DP,pcm=8
/dev/input/event14: ELAN Touchscreen
/dev/input/event15: Lenovo EasyCamera
Select the device event number [0-15]: 6
Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x0 product 0x0 version 0x0
Input device name: "Ideapad extra buttons"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 1 (KEY_ESC)
    Event code 148 (KEY_PROG1)
    Event code 149 (KEY_PROG2)
    Event code 186 (KEY_F16)
    Event code 192 (KEY_F22)
    Event code 193 (KEY_F23)
    Event code 202 (KEY_PROG3)
    Event code 203 (KEY_PROG4)
    Event code 212 (KEY_CAMERA)
    Event code 227 (KEY_SWITCHVIDEOMODE)
    Event code 238 (KEY_WLAN)
    Event code 240 (KEY_UNKNOWN)
    Event code 248 (KEY_MICMUTE)
  Event type 4 (EV_MSC)
    Event code 4 (MSC_SCAN)
Properties:
Testing ... (interrupt to exit)
±Event: time 1481395850.563699, type 4 (EV_MSC), code 4 (MSC_SCAN), value 42
Event: time 1481395850.563699, type 1 (EV_KEY), code 193 (KEY_F23), value 1
Event: time 1481395850.563699, -------------- SYN_REPORT ------------
Event: time 1481395850.563722, type 1 (EV_KEY), code 193 (KEY_F23), value 0
Event: time 1481395850.563722, -------------- SYN_REPORT ------------
Event: time 1481395868.265979, type 4 (EV_MSC), code 4 (MSC_SCAN), value 43
Event: time 1481395868.265979, type 1 (EV_KEY), code 192 (KEY_F22), value 1
Event: time 1481395868.265979, -------------- SYN_REPORT ------------
Event: time 1481395868.266000, type 1 (EV_KEY), code 192 (KEY_F22), value 0
Event: time 1481395868.266000, -------------- SYN_REPORT ------------

±Event: time 1481395988.012878, type 4 (EV_MSC), code 4 (MSC_SCAN), value 42
Event: time 1481395988.012878, type 1 (EV_KEY), code 193 (KEY_F23), value 1
Event: time 1481395988.012878, -------------- SYN_REPORT ------------
Event: time 1481395988.012888, type 1 (EV_KEY), code 193 (KEY_F23), value 0
Event: time 1481395988.012888, -------------- SY...

[marmuta (marmuta)]

Hmm, interesting. Do these ideapad key-strokes arrive in xinput? That's where we could receive them in Onboard.

That's for the ideapad device:
$ xinput test-xi2 11 # Note the device id may change here, better check with "xinput"

and that one for the core keyboard:
$ xinput test-xi2 3

I hoped to locate the source of the codes 192 and 193 in drivers/platform/x86/ideapad-laptop.c, but can't seem to find it. I only looked at the vanilla kernel, though. Maybe the debian and ubuntu add patches.

For curiosity, is there anything interesting in these sysfs folders. Key-strokes are a start, but I'd prefer a status bit. That way we could query what state the system is in when Onboard starts and won't have to wait for the next key-stroke.
/sys/kernel/debug/ideapad/cfg
/sys/kernel/debug/ideapad/status

> And this is just for my hardware. I'm not sure if
> other variants, and other hardware, will have different issues.
True, but I could imagine pushing this onto users, at least until we find a better, more standardized way to detect convertible modes. If we allow configuration of the keyboard device that has to be present and/or hotkeys that announce switching modes, then it becomes at least possible to do.

> I believe reading somewhere that the 4 modes (Normal, Tent, Tablet, ....)
> were done in Lenovo Software, and NOT by Windows.
Right, some Lenovo (UEFI?) firmware would likely be responsible. Maybe they use a combination of 190 degree lid switch and acceleration/gyro sensors to distinguish the 4 modes.

[marmuta (marmuta)]

Came across SW_TABLET_MODE in the kernel. There are a bunch of drivers that send this, one of them thinkpad_acpi.c. Are you by chance able to load that kernel module (according to the documentation probably not)?
$ sudo modprobe thinkpad_acpi

This creates a flag in
/sys/devices/platform/thinkpad_acpi/hotkey_tablet_mode
that could be queried, and also sends sysfs events (for udev I guess) and hotkey events through evdev when the mode changes.

From the source:
 TP_HKEY_EV_TABLET_TABLET = 0x5009, /* tablet swivel up */
 TP_HKEY_EV_TABLET_NOTEBOOK = 0x500a, /* tablet swivel down */

[Ritesh Raj Sarraf (rrs)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Sun, 2016-12-11 at 00:09 +0000, marmuta wrote:
> Hmm, interesting. Do these ideapad key-strokes arrive in xinput? That's
> where we could receive them in Onboard.
>
> That's for the ideapad device:
> $ xinput test-xi2 11   # Note the device id may change here, better check with
> "xinput"
>
> and that one for the core keyboard:
> $ xinput test-xi2 3
>

Here's the output you asked for:

rrs@learner:~/rrs-home/Community/linux-upstream_GIT (broken-mmc)$ xinput test-
xi2 3
Virtual core keyboard                    id=3 [master keyboard
(2)]
 Reporting 1 classes:
  Class originated from: 12. Type: XIKeyClass
  Keycodes supported: 248

EVENT type 9 (FocusIn)
    device: 3 (3)
    windows: root 0xe5 event 0x2800001 child 0x0
    mode: NotifyNormal (detail NotifyNonlinear)
    flags:  [same screen]
    buttons:
    modifiers: locked 0 latched 0 base 0 effective: 0
    group: locked 0 latched 0 base 0 effective: 0
    root x/y:  1498.00 / 822.00
    event x/y: 1411.00 / 671.00
EVENT type 10 (FocusOut)
    device: 3 (3)
    windows: root 0xe5 event 0x2800001 child 0x0
    mode: NotifyGrab (detail NotifyNonlinear)
    flags:  [same screen]
    buttons:
    modifiers: locked 0 latched 0 base 0 effective: 0
    group: locked 0 latched 0 base 0 effective: 0
    root x/y:  1498.00 / 822.00
    event x/y: 1411.00 / 671.00
EVENT type 9 (FocusIn)
    device: 3 (3)
    windows: root 0xe5 event 0x2800001 child 0x0
    mode: NotifyUngrab (detail NotifyNonlinear)
    flags:  [same screen]
    buttons:
    modifiers: locked 0 latched 0 base 0 effective: 0
    group: locked 0 latched 0 base 0 effective: 0
    root x/y:  1498.00 / 822.00
    event x/y: 1411.00 / 671.00
EVENT type 14 (RawKeyRelease)
    device: 3 (12)
    detail: 36
    valuators:

EVENT type 3 (KeyRelease)
    device: 3 (12)
    detail: 36
    flags:
    root: 1498.00/822.00
    event: 1411.00/671.00
    buttons:
    modifiers: locked 0 latched 0 base 0 effective: 0
    group: locked 0 latched 0 base 0 effective: 0
    valuators:
    windows: root 0xe5 event 0x2800001 child 0x0
EVENT type 13 (RawKeyPress)
    device: 3 (12)
    detail: 126
    valuators:

EVENT type 2 (KeyPress)
    device: 3 (12)
    detail: 126
    flags:
    root: 1498.00/822.00
    event: 1411.00/671.00
    buttons:
    modifiers: locked 0 latched 0 base 0 effective: 0
    group: locked 0 latched 0 base 0 effective: 0
    valuators:
    windows: root 0xe5 event 0x2800001 child 0x0
EVENT type 1 (DeviceChanged)
    device: 3 (11)
    reason: SlaveSwitch
 Reporting 1 classes:
  Class originated from: 11. Type: XIKeyClass
  Keycodes supported: 248

EVENT type 13 (RawKeyPress)
    device: 3 (11)
    detail: 201
    valuators:

EVENT type 10 (FocusOut)
    device: 3 (3)
    windows: root 0xe5 event 0x2800001 child 0x0
    mode: NotifyGrab (detail NotifyAncestor)
    flags:  [same screen]
    buttons:
    modifiers: locked 0 latched 0 base 0 effective: 0
    group: locked 0 latched 0 base 0 effective: 0
    root x/y:  1498.00 / 822.00
    event x/y: 1411.00 / 671.00
EVENT type 14 (RawKeyRelease)
    device: 3 (11)
    detail: 201
    valuators:

EVENT type 9 (FocusIn)
    device: 3...

[Ritesh Raj Sarraf (rrs)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Sun, 2016-12-11 at 00:37 +0000, marmuta wrote:
> Came across SW_TABLET_MODE in the kernel. There are a bunch of drivers that
> send this, one of them thinkpad_acpi.c. Are you by chance able to load that
> kernel module (according to the documentation probably not)?
> $ sudo modprobe thinkpad_acpi
>

Wow. I wasn't aware they added support for Lenovo Yogas into this driver.
Initially (maybe more than a year ago), this driver wouldn't have any effect on
Yoga. Now its different.

[ 9988.198752] Non-volatile memory driver v1.3
[ 9988.201892] thinkpad_acpi: ThinkPad ACPI Extras v0.25
[ 9988.201894] thinkpad_acpi: http://ibm-acpi.sf.net/
[ 9988.201895] thinkpad_acpi: ThinkPad BIOS 96CN31WW(V1.17), EC unknown
[ 9988.201897] thinkpad_acpi: Lenovo Lenovo Yoga 2 13, model 20344
[ 9988.281520] thinkpad_acpi: Standard ACPI backlight interface available, not
loading native one
[ 9988.281759] thinkpad_acpi: Console audio control enabled, mode: monitor (read
only)
[ 9988.282273] input: ThinkPad Extra Buttons as
/devices/platform/thinkpad_acpi/input/input18
2016-12-11 / 16:05:39 ♒♒♒  ☺

> This creates a flag in
> /sys/devices/platform/thinkpad_acpi/hotkey_tablet_mode
> that could be queried, and also sends sysfs events (for udev I guess) and
> hotkey events through evdev when the mode changes.
>

That isn't available. So I got you the following.

rrs@learner:~/rrs-home/Community/linux-upstream_GIT (broken-mmc)$ tree
/sys/devices/platform/thinkpad_acpi/
/sys/devices/platform/thinkpad_acpi/
├── cmos_command
├── driver -> ../../../bus/platform/drivers/thinkpad_acpi
├── driver_override
├── input
│   └── input19
│       ├── capabilities
│       │   ├── abs
│       │   ├── ev
│       │   ├── ff
│       │   ├── key
│       │   ├── led
│       │   ├── msc
│       │   ├── rel
│       │   ├── snd
│       │   └── sw
│       ├── device -> ../../../thinkpad_acpi
│       ├── event16
│       │   ├── dev
│       │   ├── device -> ../../input19
│       │   ├── power
│       │   │   ├── async
│       │   │   ├── autosuspend_delay_ms
│       │   │   ├── control
│       │   │   ├── runtime_active_kids
│       │   │   ├── runtime_active_time
│       │   │   ├── runtime_enabled
│       │   │   ├── runtime_status
│       │   │   ├── runtime_suspended_time
│       │   │   └── runtime_usage
│       │   ├── subsystem -> ../../../../../../class/input
│       │   └── uevent
│       ├── id
│       │   ├── bustype
│       │   ├── product
│       │   ├── vendor
│       │   └── version
│       ├── modalias
│       ├── name
│       ├── phys
│       ├── power
│       │   ├── async
│       │   ├── autosuspend_delay_ms
│       │   ├── control
│       │   ├── runtime_active_kids
│       │   ├── runtime_active_time
│       │   ├── runtime_enabled
│       │   ├── runtime_status
│       │   ├── runtime_suspended_time
│       │   └── runtime_usage
│       ├── properties
│       ├── subsystem -> ../../../../../class/input
│       ├── uevent
│       └── uniq
├── modalias
├── power
│   ├── async
│   ├── autosuspend_delay_ms
│   ├── control
│   ├── runtime_active_kids
│   ├── runtime_active_time
│   ├── runtime_enabled
│   ├── runtime_status
│...

[RussianNeuroMancer (russianneuromancer)]

> intel-vbtn.c really seems to handle power buttons only.
Patches necessary for Dell Venue 11 Pro 7140 is here:
https://bugzilla.kernel.org/show_bug.cgi?id=102281#c78
https://bugzilla.kernel.org/show_bug.cgi?id=102281#c83
Hopefully it doesn't take long time for merging it.

> Could you too check if the list of devices changes between tablet and laptop-mode?
I doesn't have keyboard dock for my tablet, however I have access to Thinkpad Helix 1gen and DEXP Ursus 10XW.

About DEXP devices. They produce many tablets with keyboard, please take a look:
http://dexp.club/Products/Planshety?Archive=True&ViewType=Table&Operacionnaya-sistema=38428
http://dexp.club/Products/Planshety?Archive=True&ViewType=Table&Operacionnaya-sistema=40425
http://dexp.club/Products/Planshety?ViewType=Table&Operacionnaya-sistema=38428
http://dexp.club/Products/Planshety?ViewType=Table&Operacionnaya-sistema=40425
14 tablets with keyboards as you can see. All of them works in exactly same way - folio with keyboard and touchpad is USB device.

Test on DEXP Ursus 10XW tablet:
evtest1, xinput1 - folio with keyboard is not attached yet.
evtest2, xinput2 - folio with keyboard attached.
evtest3, xinput3 - folio with keyboard deattached.
Here is logs:
Shrotly, when folio with keyboard is attached, HID 0911:2188 device appear in evtest and xinput output, when folio with keyboard is deattached - device simply disappear from evtest and xinput.

Test on Thinkpad Helix 1gen:
/sys/devices/platform/thinkpad_acpi/hotkey_tablet_mode flag works as expected (0 with keyboard, 1 without it).

Well, to sum up things I guess there is no easy way to determine if keyboard is attached or not: USB device in DEXP case, hotkey_tablet_mode flag in Helix case, ThinkPad Extra Buttons in Yoga case, intel-vbtn in Venue 11 Pro 7140 case, etc.
Maybe you should contact Unity 8 and Gnome Shell developers to discuss how to do that in more universal way? Something like iio-sensor-proxy (or maybe ask iio-sensor-proxy developers to add support for that?) that could be useful not only for onboard but also for DEs. I pretty sure Unity 8 will benefit from automatic mode detection. Gnome Shell could use that for their own onscreen keyboard too.

By the way I find that disabling "auto-show" option is not working, after tablet reboot (and possible after re-login or onboard restart) this option always reset to enabled state. Do I need to fill separate bugreport about that?

[RussianNeuroMancer (russianneuromancer)]

Link to logs: https://yadi.sk/d/7d8AYqcL33QW4R

[marmuta (marmuta)]

Thank you both. I've been searching and experimenting some more and slowly feel more confident about all the bits and pieces. My current plan is to

1) rely on acpid for the SW_TABLET_MODE switch
2) allow for optional additional hotkey events from xinput, e.g. for ideapad-laptop, where SW_TABLET_MODE isn't available
3) read the current state of tablet mode from (very few) known sysfs paths
4) detect connected keyboard devices with udev (has been requested elsewhere)

I believe only a single source will be strictly necessary, but the more the better, because some will work better than others.

2) will be available only on X, the others on Wayland/MIR too

> Here's the output you asked for:
> rrs@learner:~/rrs-home/Community/linux-upstream_GIT (broken-mmc)$ xinput test-xi2 3
That's promising. Keys 200/201 are XF86TouchpadOn/XF86TouchpadOff.

> root@learner:/sys/kernel/debug/ideapad# cat status
> And this status is wrong. Because my wifi is on.
Thanks. Touchpad status might have been interesting too, but I realized that you need root to read from debugfs anyway. Won't help us at the moment.

> So though the driver (thinkpad_acpi) loaded, it still doesn't seem to be meant
> for Yoga series.
Yes, looks like it. Still, I want to believe that either thinkpad_acpi will get Yoga support, or ideapad-laptop learns to send SW_TABLET_MODE. In the meantime we'll try the xinput events.

> About DEXP devices. They produce many tablets with keyboard, please take a look:
Thank you, but I get only 404 errors.

> Link to logs: https://yadi.sk/d/7d8AYqcL33QW4R
Couldn't download, do you have to be a member? You could just attach it here to the bug report. I don't think I need more information at the moment, though. Maybe later when I have more working code.

> Patches necessary for Dell Venue 11 Pro 7140 is here:
> https://bugzilla.kernel.org/show_bug.cgi?id=102281#c78
> https://bugzilla.kernel.org/show_bug.cgi?id=102281#c83
The second link indicates it will send SW_TABLET_MODE in the future. That's good news. I suspect if/when ideapad-laptop.c will get tablet mode detection it will go that route as well.

> By the way I find that disabling "auto-show" option is not working
Is that on GNOME Shell? The extension always enables auto-show on startup. The idea was to match the behavior of the built-in keyboard. This should probably be done only once on first start, though. Now that there is a gsettings schema for the extension I can just store a flag there. Yes, a bug report would be helpful.

[RussianNeuroMancer (russianneuromancer)]

> Thank you, but I get only 404 errors.
They updated web-site few days ago, and also removed eight old tablets from catalogue, so I not sure how to show old tablets to you now. Anyway, you can take a look at current models here: http://dexp.club/catalog/b2c531e0a6434e77/?alias=planshety&f%5Bs6%5D=91py

> Couldn't download, do you have to be a member?
No.

> You could just attach it here to the bug report.
Attached.

> Is that on GNOME Shell?
Yes.

> Yes, a bug report would be helpful.
Ok, filled: https://bugs.launchpad.net/onboard/+bug/1650810

[marmuta (marmuta)]

So, at long last, Onboard has tablet mode detection and external keyboard device detection now. I eventually finished implementing 1) - 4) of comment #43.

However, before I offer this for testing I would like to add one more thing, a read/write D-Bus property "tablet-mode". This I believe is what the initial bug reporter wanted.

[marmuta (marmuta)]

OK, bug #1648543 delayed things a bit, but I think I'm done done now. There is a new D-Bus property AutoShowPaused, that when set to true, unconditionally blocks auto-show. 'TabletMode' seemed too fuzzy for the very specific purpose here, so I dropped it in favor of the original name in #2.

If you can, please test the new settings in Preferences->Auto-show, tabs Convertible devices and/or external Keyboards.

@Francesco, whenever you find the time, please create a new snapshot of rev. 2207. Thanks in advance.

'Convertible devices', aka Tablet-mode detection, is enabled by default and covers points 1) to 3) of post #43.
Ritesh, you may need to enter hotkey values 70 and 71 into the entries. There's no need for acpid in that case. Other systems with working SW_TABLET_MODE switch don't need any configuration but require running acpid. Supported devices should hide the keyboard and stop auto-show when leaving tablet-mode, and resume auto-show when entering tablet-mode.

The 'External keyboards' tab is perhaps less relevant for this bug report, but I'm still interested if it works for you. In particular, does the list show more or less correctly detected keyboard devices? Are there any duplicate entries? As a heads-up, some mice will report as keyboards. I haven't found a way to filter them out, but you should be able to ignore them by setting the checkmark.
The idea is: plug an external keyboard in -> Onboard keyboard should disappear and auto-show gets disabled. Remove external keyboard -> auto-show resumes.

[Francesco Fumanti (frafu)]

I just uploaded revision 2207 of trunk for xenial, yakkety and zesty to the Snapshots PPA. It should be available soon. The packages for trusty and precise will probably follow tomorrow.

[Ritesh Raj Sarraf (rrs)]

Dear @marmuta,

Thanks a ton. This is working fantastic. I just tried @frafu's PPA sources, rebuilt for Debian Unstable. Everything seems to be working fine.

I'm just curious how you came up with the number 70/71 for my setup ?

[Ritesh Raj Sarraf (rrs)]

Regarding the SW_TABLET_MODE for Lenovo Yoga series, here's some thought.

In normal mode.

root@learner:/sys/kernel/debug/ideapad# cat status
Backlight max: 16
Backlight now: 3
BL power value: On
=====================
Radio status: Off(0)
Wifi status: Off(0)
BT status: Off(0)
3G status: Off(0)
=====================
Touchpad status:On(1)
Camera status: On(1)

In tablet mode.

root@learner:/sys/kernel/debug/ideapad# cat status
Backlight max: 16
Backlight now: 3
BL power value: On
=====================
Radio status: Off(0)
Wifi status: Off(0)
BT status: Off(0)
3G status: Off(0)
=====================
Touchpad status:Off(0)
Camera status: On(1)

I'll check other drivers on how they are populating SW_TABLET_MODE. In my opinion, leveraging Touchpad status for populating SW_TABLET_MODE should be fine.

[marmuta (marmuta)]

Glad it works for you, thanks for testing, Ritesh.

> I'm just curious how you came up with the number 70/71 for my setup ?
Honestly, I don't know anymore. What I think I did was to remap two keys on my USB keyboard with setkeycodes, in order to emulate TouchPadOn/Off manually. Then 'xinput test-xi2 3' and Onboard's GlobalKeyListener both gave me 70/71. Those values seemed odd, but hey they worked.

However, now I'm apparently unable to reproduce this. setkeycodes from my notes does nothing, and when I remap keys with UDev hwdb (instructions in /lib/udev/hwdb.d/60-keyboard.hwdb) 'xinput test-xi2 3' gives me 200/201. Ahd frankly, that makes more sense, as those are the keycodes from your output in comment #39.

So, I don't really know why it works with 70/71. If it ever happens not to anymore, try 200/201. Meanwhile, I'm wondering if Onboard uses hotkeys at all for tablet-mode switching, or if any of the two other approaches have started working. 'onboard -ddebug', while going tablet and back, would clear that up, mainly the HardwareSensorTracker entries. You could attach the output here, or just look at mainly the HardwareSensorTracker entries yourself.

> I'll check other drivers on how they are populating SW_TABLET_MODE.
> In my opinion, leveraging Touchpad status for populating SW_TABLET_MODE
> should be fine.
Yes, possibly. If it turns out that Touchpad status is the only way the firmware allows to detect tablet-mode, then they might as well bake that into the ideapad-laptop driver and send SW_TABLET_MODE.

[Ritesh Raj Sarraf (rrs)]

Here are the logs with 70/71 fed in the configuration setting.

rrs@learner:~$ onboard -ddebug
22:34:57.944 INFO Config gsettings schema for 'org.gnome.Mousetweaks' is not installed
22:34:57.948 INFO ClickSimulator 'CSMousetweaks0' selected for mousetweaks up to version 3.8.
22:34:57.949 DEBUG Config Desktop environment: GNOME_Shell
22:34:57.952 DEBUG Config command line: ['/usr/bin/onboard', '-ddebug']
22:34:57.952 DEBUG Config lauched by, process: '['/bin/bash', '']'
22:34:57.952 DEBUG Config lauched by, detected: 0
22:34:57.952 INFO ConfigUtils Looking for system defaults in ['/home/rrs/.config/onboard/onboard-defaults.conf', '/etc/xdg/onboard/onboard-defaults.conf', '/usr/share/onboard/onboard-defaults.conf', '/etc/onboard/onboard-defaults.conf']
22:34:57.953 INFO ConfigUtils Loading system defaults from ['/usr/share/onboard/onboard-defaults.conf']
22:34:57.953 INFO ConfigUtils Found system default '[window.landscape] dock-expand=True'
22:34:57.953 INFO ConfigUtils Found system default '[window] docking-enabled=True'
22:34:57.954 INFO ConfigUtils Found system default '[window] force-to-top=True'
22:34:57.954 INFO ConfigUtils Found system default '[auto-show] enabled=False'
22:34:57.954 INFO ConfigUtils Found system default '[main] layout=Compact'
22:34:57.954 INFO ConfigUtils Found system default '[main] theme=Nightshade'
22:34:57.954 INFO ConfigUtils Found system default '[main] key-label-font=Ubuntu'
22:34:57.954 INFO ConfigUtils Found system default '[main] superkey-label='
22:34:57.954 INFO ConfigUtils Found system default '[main] superkey-label-independent-size=True'
22:34:57.954 INFO ConfigUtils Found system default '[main] xembed-onboard=True'
22:34:57.954 INFO ConfigUtils Found system default '[main] xembed-aspect-change-range=[0, 1.6]'
22:34:57.954 INFO ConfigUtils Found system default '[main] xembed-unity-greeter-offset-x=85.0'
22:34:57.954 INFO ConfigUtils Found system default '[main] xembed-background-color='#0000007F''
22:34:57.955 INFO ConfigUtils Found system default '[main] xembed-background-image-enabled=True'
22:34:57.988 INFO Config Theme candidates ['/usr/share/onboard/themes/Nightshade.theme', '', '', 'Nightshade', 'Classic Onboard']
22:34:57.988 INFO Config Loading theme from '/usr/share/onboard/themes/Nightshade.theme'
22:34:57.990 DEBUG Config Leaving init
22:34:58.019 WARNING HardwareSensorTracker Failed to connect to acpid, SW_TABLET_MODE detection disabled. ('/var/run/acpid.socket': [Errno 2] No such file or directory)
22:34:58.023 INFO GlobalKeyListener listening to keyboard devices: [('Video Bus', 7, '0000:0006:4'), ('Lenovo EasyCamera', 10, '04F2:B40F:4'), ('Ideapad extra buttons', 11, '0000:0000:4'), ('AT Translated Set 2 keyboard', 12, '0001:0001:4')]
22:34:58.024 DEBUG AutoShow enable_tablet_mode_detection True <Onboard.HardwareSens...

[Ritesh Raj Sarraf (rrs)]

only values 70/71 have worked for me. nothing else has worked. just tested

[marmuta (marmuta)]

Hmm, doesn't look like it's working as intended. Auto-hide on key-press is interfering. I missed to blacklist the keycodes for tablet-mode detection, will do that. For the time being please disable Preference->Auto-show->"Hide when typing on a physical keyboard".

Then, there are no incoming key-presses 70 or 71, just 200 and 201. Please try 200/201 in preferences please, or more likely 201/200. 200 is touchpad on, which I believe means tablet-mode off.

>Meanwhile, I'm wondering if Onboard uses hotkeys at all for tablet-mode
> switching, or if any of the two other approaches have started working.
Nope, they haven't. No SW_TABLET_MODE or sysfs paths, as expected.

One more time onboard -ddebug and going tablet and back would be helpful, even if it appears to work now.
There should be entries
 AutoShow can_show_keyboard: locks=[] tablet_mode=True
and
 AutoShow can_show_keyboard: locks=[] tablet_mode=False
if it does.

[marmuta (marmuta)]

> only values 70/71 have worked for me. nothing else has worked. just tested
That's rather weird, can't imagine why that is at the moment. However, even where it appears to work, I expect this to only pause auto-show for 30 minutes, as that is what auto-hide on key-press does (by default).

Please try disabling auto-hide on key-press and have 201/200 as hotkeys for tablet-mode detection.

[Ritesh Raj Sarraf (rrs)]

Fantastic. Now the onboard behavior is deterministic. I fed in 201/200 along with "auto-hide on key-press disabled" and everything is working perfect now. Please see logs below.

rrs@learner:~$ onboard -ddebug
15:57:01.003 INFO Config gsettings schema for 'org.gnome.Mousetweaks' is not installed
15:57:01.007 INFO ClickSimulator 'CSMousetweaks0' selected for mousetweaks up to version 3.8.
15:57:01.008 DEBUG Config Desktop environment: GNOME_Shell
15:57:01.010 DEBUG Config command line: ['/usr/bin/onboard', '-ddebug']
15:57:01.010 DEBUG Config lauched by, process: '['/bin/bash', '']'
15:57:01.010 DEBUG Config lauched by, detected: 0
15:57:01.011 INFO ConfigUtils Looking for system defaults in ['/home/rrs/.config/onboard/onboard-defaults.conf', '/etc/xdg/onboard/onboard-defaults.conf', '/usr/share/onboard/onboard-defaults.conf', '/etc/onboard/onboard-defaults.conf']
15:57:01.011 INFO ConfigUtils Loading system defaults from ['/usr/share/onboard/onboard-defaults.conf']
15:57:01.012 INFO ConfigUtils Found system default '[window.landscape] dock-expand=True'
15:57:01.012 INFO ConfigUtils Found system default '[window] docking-enabled=True'
15:57:01.012 INFO ConfigUtils Found system default '[window] force-to-top=True'
15:57:01.012 INFO ConfigUtils Found system default '[auto-show] enabled=False'
15:57:01.012 INFO ConfigUtils Found system default '[main] layout=Compact'
15:57:01.012 INFO ConfigUtils Found system default '[main] theme=Nightshade'
15:57:01.012 INFO ConfigUtils Found system default '[main] key-label-font=Ubuntu'
15:57:01.013 INFO ConfigUtils Found system default '[main] superkey-label='
15:57:01.013 INFO ConfigUtils Found system default '[main] superkey-label-independent-size=True'
15:57:01.013 INFO ConfigUtils Found system default '[main] xembed-onboard=True'
15:57:01.013 INFO ConfigUtils Found system default '[main] xembed-aspect-change-range=[0, 1.6]'
15:57:01.013 INFO ConfigUtils Found system default '[main] xembed-unity-greeter-offset-x=85.0'
15:57:01.013 INFO ConfigUtils Found system default '[main] xembed-background-color='#0000007F''
15:57:01.013 INFO ConfigUtils Found system default '[main] xembed-background-image-enabled=True'
15:57:01.046 INFO Config Theme candidates ['/usr/share/onboard/themes/Nightshade.theme', '', '', 'Nightshade', 'Classic Onboard']
15:57:01.047 INFO Config Loading theme from '/usr/share/onboard/themes/Nightshade.theme'
15:57:01.048 DEBUG Config Leaving init
15:57:01.082 WARNING HardwareSensorTracker Failed to connect to acpid, SW_TABLET_MODE detection disabled. ('/var/run/acpid.socket': [Errno 2] No such file or directory)
15:57:01.086 INFO GlobalKeyListener listening to keyboard devices: [('Video Bus', 7, '0000:0006:4'), ('Lenovo EasyCamera', 10, '04F2:B40F:4'), ('Ideapad extra buttons', 11, '0000:0000:4'), ('AT Translated Set 2 keyboard', 12,...

[Ritesh Raj Sarraf (rrs)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Fri, 2017-01-27 at 00:21 +0000, marmuta wrote:
> Hmm, doesn't look like it's working as intended. Auto-hide on key-press
> is interfering. I missed to blacklist the keycodes for tablet-mode
> detection, will do that. For the time being please disable Preference
> ->Auto-show->"Hide when typing on a physical keyboard".

I picked revision 2216 to test if it fixes the blacklist problem.
But it throws an exception.

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/Onboard/XInput.py", line 395, in _on_device_event
    callback(ev)
  File "/usr/lib/python3/dist-packages/Onboard/GlobalKeyListener.py", line 175, in _on_device_event
    self.emit("key-press", event)
  File "/usr/lib/python3/dist-packages/Onboard/utils.py", line 1314, in emit
    callback(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/Onboard/AutoHide.py", line 67, in _on_key_press
    s = self._key_listener.get_key_event_string(event)
AttributeError: 'GlobalKeyListener' object has no attribute 'get_key_event_string'

- --
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEQCVDstmIVAB/Yn02pjpYo/LhdWkFAliLLa8ACgkQpjpYo/Lh
dWm98Q/9HwT/Esikc9KtzY13TJ3i7SjzHo27QmviG0eskoSsSW/+bmfTpYQ3grRb
b9MtpPx9GpTSGa7gcALtdfbggPZdKPml7kUptfpi1NYvd6XgjVAYJcjeg4IAMmoR
svab9Heb5icsutSGGAifv5X1v850xCc4eP/Ol2fG6eYCBNzbI0r+ax+RLminTXGZ
EJ1eAQ3W7K3iKCRdlGGIcjUrABr/oH8HdzPvGFDvhUC3/t2bbo6HYoqnK/0SXFxl
dk6qZQFZGoCQ161AsMqT8tLuUJHBvlmOs7kYjLObgrHcmyGOv/BBLz3hcAazRkam
1AmJxn2Xg8A5MnB/EDX0PlcjqmJ6RgbWxkM+Erj7+tWi3EXF47GNrv5APbVLLDa/
ixaSIxhFxZ1eDG+XkERkFiElKu4CZJn59YWAecjAwIc0kUby52ltf/kcpFui3KPv
3c0siyj5WBG8HvLIlFltdsYf+foZhAPTQc9xdeCheMqnnXRh3vul4BV+QMNGNu1k
wKEYwxoBxl/QOHrj91Rrjm5k/DPq2qzyDiNGybj6fdlfE3pJqEcl4XpmB1TAUHKb
idvmGnczUU9eg7ubLn9qGA5EyUl0e5R7k4okDUoNAnQjAQJfrBSYy5ISOwyl0oEZ
fOTA1cxzQePIGkBn46RcBvBsS9VMrndbaj3n4pT8L3YyDMXTMZA=
=ohqH
-----END PGP SIGNATURE-----

[Ritesh Raj Sarraf (rrs)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

You may want to ignore the previous comment/exception, if you're not sure why it
would happen. Because after a reboot, things seem to be fine. I am surprised
though. The only onbard related stuff running is the onboard.py process. I had
killed it and ran onboard -ddebug and it threw that exception.

And now, the same packages, seem to be working fine. Including the functionality
for auto-show/hide.

On Fri, 2017-01-27 at 16:53 +0530, Ritesh Raj Sarraf wrote:
> On Fri, 2017-01-27 at 00:21 +0000, marmuta wrote:
> > Hmm, doesn't look like it's working as intended. Auto-hide on key-press
> > is interfering. I missed to blacklist the keycodes for tablet-mode
> > detection, will do that. For the time being please disable Preference
> > ->Auto-show->"Hide when typing on a physical keyboard".
>
> I picked revision 2216 to test if it fixes the blacklist problem.
> But it throws an exception.
>
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/Onboard/XInput.py", line 395, in
> _on_device_event
>     callback(ev)
>   File "/usr/lib/python3/dist-packages/Onboard/GlobalKeyListener.py", line
> 175, in _on_device_event
>     self.emit("key-press", event)
>   File "/usr/lib/python3/dist-packages/Onboard/utils.py", line 1314, in emit
>     callback(*args, **kwargs)
>   File "/usr/lib/python3/dist-packages/Onboard/AutoHide.py", line 67, in
> _on_key_press
>     s = self._key_listener.get_key_event_string(event)
> AttributeError: 'GlobalKeyListener' object has no attribute
> 'get_key_event_string'
>
>
>
>
- --
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEQCVDstmIVAB/Yn02pjpYo/LhdWkFAliLU6cACgkQpjpYo/Lh
dWkEbA//TetMaExwcds+XtuG0yY0Pl8lfVTNZB1/XQUiDNBa0Qo6K/Kw6gUvrn+A
OswVw6DINGwRcrINgvdKpmSJqFdigMcvaL4gJ3iNo8WtJZAvY4yvPwEfzAHabsiC
BTYBiL8bpnMaX6pFvP0kdjcKXz/R2i9DBzXuRgXUx6YADle59fdVG4p0RAY0sdDN
1lzMjJu0GM4wmwl+3OhJChTMMR0dE369GLZZuM3rbiiUPt0KrODZP4U3Y3MFlWHM
UeYpbkqqy1tRAuOTWjYOEOnz0kKYIJ9s1cr2oPfqIPdair/QL5mjVvZ85p9Nb2EQ
RVihFeyWDQRjzEABX1sHzi9VIS/bkl6Zp8IHLD/Fhxb/6uqyrnjQ9a5FPXOIGDdp
oUW3pN8ws1S9swDcKUbg5FNSjatAcYLTnAWTPslgjCQS4gXneMsTGszj5aQ4NWGS
MM3IIpOasrGNrhtzSGUZRt0w9W493Uz7gCEPU5AnGL9O4gKKUY/LkaPIkDukohmg
pv5i0pFoQLZn9G2aCPo0zdYF7YQWWJMAufKrp8GQfUNsTbVBNDhpxMv324Eznek4
Ceybmc10INVprMApv/tCnvUsAzwBTIeglartvNkjy7gQYA1MNrmYGjP8v3dHV0/R
jo/BjmKoiree4jeGS8icibZMOsbvXghmTPwixwwM/pShT4W53X4=
=dh+s
-----END PGP SIGNATURE-----

[marmuta (marmuta)]

> Fantastic. Now the onboard behavior is deterministic. I fed in 201/200 along
> with "auto-hide on key-press disabled" and everything is working perfect now.
> Please see logs below.
Yep, much better, that's how it was supposed to look, great.

The one issue that's left is, that Onboard doesn't know in which state it is in the beginning, only after the first switch occurs. There's not much I can do, unless somehow a sysfs path with that information appears. The code checks the two paths I know, but they are not supported by ideapad-laptop driver. I could easily add another one, though, in case anything changes.

> I picked revision 2216 to test if it fixes the blacklist problem.
> But it throws an exception.
Yes, I split two changes up into separate commits that weren't totally self-contained. rev. 2217 came right after and should have fixed that particular exception. I'm still working on some issues with auto-show and firefox, so there might be more shakiness in the immediate future. I hope to iron those out before the release next month.

Btw., I realized blacklisting tablet-mode keys for auto-hide on keypress may not be enough in your case. There's still that ± key being sent along with global key press 201. Maybe I have to restrict auto-hide to alpha-numeric keys and modifiers or something. Or somehow decide which source devices are "real" keyboards, if that is possible. Not sure yet. So, you probably have to keep "Hide when typing on a physical keyboard" off for a bit longer.

[Ritesh Raj Sarraf (rrs)]

@marmuta. Can you please share your fix in revision 2217 ?

I thought of looking at ideapad-laptop driver today. I kinda have a hacky solution working locally. I would appreciate if you share revision 2217 so that I can do a full test. If it looks okay, I may try pushing it to the Linux kernel. It is a hacky trick but maybe they'll accept it.

00:37:35.527 INFO AutoShow can_hide_keyboard: locks=[]
00:37:35.527 DEBUG HardwareSensorTracker Opening '/sys/devices/platform/hp-wmi/tablet' failed: [Errno 2] No such file or directory: '/sys/devices/platform/hp-wmi/tablet'
00:37:35.528 INFO HardwareSensorTracker read tablet_mode=False from '/sys/bus/platform/devices/VPC2004:00/tablet_mode' with pattern '1'
00:37:35.528 INFO AutoShow can_show_keyboard: locks=[] tablet_mode=False
00:37:35.528 DEBUG AutoShow request_keyboard_visible(False): lock_visible=False can_hide=True can_show=False
00:37:36.496 INFO HardwareSensorTracker global key press 23 received
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/Onboard/XInput.py", line 395, in _on_device_event
    callback(ev)
  File "/usr/lib/python3/dist-packages/Onboard/GlobalKeyListener.py", line 175, in _on_device_event
    self.emit("key-press", event)
  File "/usr/lib/python3/dist-packages/Onboard/utils.py", line 1314, in emit
    callback(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/Onboard/AutoHide.py", line 67, in _on_key_press
    s = self._key_listener.get_key_event_string(event)
AttributeError: 'GlobalKeyListener' object has no attribute 'get_key_event_string'
00:37:36.581 DEBUG OnboardGtk keyboard state changed to 0x0
00:37:36.581 DEBUG Onboard.Keyboard set_modifiers(0) False None False
00:37:36.738 INFO AutoShow can_hide_keyboard: locks=[]
00:37:36.738 DEBUG HardwareSensorTracker Opening '/sys/devices/platform/hp-wmi/tablet' failed: [Errno 2] No such file or directory: '/sys/devices/platform/hp-wmi/tablet'
00:37:36.739 INFO HardwareSensorTracker read tablet_mode=False from '/sys/bus/platform/devices/VPC2004:00/tablet_mode' with pattern '1'
00:37:36.739 INFO AutoShow can_show_keyboard: locks=[] tablet_mode=False
00:37:36.740 DEBUG AutoShow request_keyboard_visible(True): lock_visible=False can_hide=True can_show=False

I'm also not sure if that sysfs path would apply to the entire Yoga series. But that's something to think about later.

root@learner:/sys/kernel/debug/ideapad# cat status
Backlight max: 16
Backlight now: 3
BL power value: On
=====================
Radio status: Off(0)
Wifi status: Off(0)
BT status: Off(0)
3G status: Off(0)
=====================
Touchpad status:Off(0)
SW_TABLET_MODE: On(1)
Camera status: On(1)

root@learner:/sys/kernel/debug/ideapad# cat status
Backlight max: 16
Backlight now: 3
BL power value: On
=====================
Radio status: Off(0)
Wifi status: Off(0)
BT status: Off(0)
3G status: Off(0)
=====================
Touchpad status:On(1)
SW_TABLET_MODE: Off(0)
Camera status: On(1)

rrs@learner:~$ cat /sys/bus/platform/devices/VPC2004:00/tablet_mode
0
2017-01-29 / 00:44:22 ♒♒♒ ☺

rrs@learner:~/r...

[marmuta (marmuta)]

> @marmuta. Can you please share your fix in revision 2217 ?
It was commit 2215 and 2216, actually, sorry. I have 2217 only locally here and I can't recommend it yet, but the error isn't supposed to be happening in 2216 anymore.

The debug output doesn't seem to show rev. 2216, though. That
 "HardwareSensorTracker global key press 23 received"
should print both keycode and keyval (aka. keysym) now.

Did you
bzr branch lp:onboard # initially
cd onboard

bzr pull # for getting the latest sources

Then either
./setup.py build
./onboard # must run from source directory
or
debuild binary # for packages, install with dpkg -i
?

> rrs@learner:~$ cat /sys/bus/platform/devices/VPC2004:00/tablet_mode
> 0
Cool :) but wouldn't VPC2004:00 be prone to change? Is it available from elsewhere, similar to
/sys/devices/platform/thinkpad_acpi/hotkey_tablet_mode
?

I see you already found org.onboard.auto-show tablet-mode-state-file in gsettings :)

I can't say much about the kernel changes, that's up to the kernel people. I feel the Yoga firmware must have a dedicated path to determine tablet-mode, but if no one knows the correct way, than your approach seems like the second best thing to do. I wish you luck getting it accepted.

[Ritesh Raj Sarraf (rrs)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Sat, 2017-01-28 at 21:04 +0000, marmuta wrote:
> > @marmuta. Can you please share your fix in revision 2217 ?
>
> It was commit 2215 and 2216, actually, sorry. I have 2217 only locally here
> and I can't recommend it yet, but the error isn't supposed to be happening in
> 2216 anymore.
>
> The debug output doesn't seem to show rev. 2216, though. That
>  "HardwareSensorTracker global key press 23 received"
> should print both keycode and keyval (aka. keysym) now.
>

Oh!. I had only handpicked revision 2216 and not 2215.

> Did you
> bzr branch lp:onboard   # initially
> cd onboard
>
> bzr pull # for getting the latest sources
>
> Then either
> ./setup.py build
> ./onboard    # must run from source directory
> or
> debuild binary  # for packages, install with dpkg -i
> ?
>

Did it now. Thanks for mentioning it. I've now built it with your latest changes
in master, i.e. rev. 2219

It seems to be working fine with the exception that on first trigger of the
mode, it doesn't detect. Perhaps because, for the ideapad driver, no acpi event
is generated, nor do I have acpid installed.

Jan 29 15:28:32 learner org.onboard.Onboard[11716]: 15:28:32.703 WARNING HardwareSensorTracker: Failed to connect to acpid, SW_TABLET_MODE detection disabled. ('/var/run/acpid.socket': [Errn
Jan 29 15:28:33 learner gnome-shell[11870]: JS LOG: loading default theme (Adwaita)

But after the first invocation, onboard shows perfectly in tablet mode, in text input fields.

By the way, I was wondering if having a "Debug" checkbox in the onboard config
gui window would make sense ? Otherwise, users need to ensure that the running
instance of onboard is killed, before running in debug mode. Would you be okay
to add such a feature ? Should I file a separate bug report for it ?

> > rrs@learner:~$ cat /sys/bus/platform/devices/VPC2004:00/tablet_mode
> > 0
>
> Cool :) but wouldn't VPC2004:00 be prone to change? Is it available from
> elsewhere, similar to
> /sys/devices/platform/thinkpad_acpi/hotkey_tablet_mode
> ?
>

I just checked into the ideapad sources and that device id string (VPC2004) is
hardcoded. So I'm assuming that'll remain the same.

Other than that path, there's nowhere else is sysfs where it writes, that could
be useful from an unprivileged user point of view.

> I see you already found in
> gsettings :)
>
> I can't say much about the kernel changes, that's up to the kernel
> people. I feel the Yoga firmware must have a dedicated path to determine
> tablet-mode, but if no one knows the correct way, than your approach
> seems like the second best thing to do. I wish you luck getting it
> accepted.
>

I am not very hopeful either but I will still send it to the mailing lists. If
it is outrightly rejected, a counter patch could be to just expose the touchpad
on/off state in sysfs (non /s/k/debug path) and then onboard could still rely on
that ?

- --
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEQCVDstmIVAB/Yn02pjpYo/LhdWkFAliNxjIACgkQpjpYo/Lh
dWmoKg//Z5NYZ7jPavXTlsPRjxruh5AGeG8dreqgWUyBmGJ1Cub5KRVXbdwHmi3c...

[marmuta (marmuta)]

> It seems to be working fine with the exception that on first trigger
> of the mode, it doesn't detect. Perhaps because, for the ideapad
> driver, no acpi event is generated, nor do I have acpid installed.
Yes, with only the sysfs path available, the decision 'tablet-mode or not' is made at the next focus event (assuming you have cleared the hotkey values in preferences). With acpid running and SW_TABLET_MODE sent by the driver, you should get immediate reaction again, like with hotkeys. Asynchronous and synchronous sources are meant to complement each other, but if only one is available it'll degrade gracefully (barring bugs).

> By the way, I was wondering if having a "Debug" checkbox in the onboard
> config gui window would make sense ? Otherwise, users need to ensure that
> the running instance of onboard is killed, before running in debug mode.
You would still need to run Onboard from a terminal to see/redirect the output, won't you? There are multiple levels of debug output too, info, debug, atspi, event and you can specify a range of levels, e.g. -datspi-atspi. What use case do you have in mind for a debug checkbox?

> I just checked into the ideapad sources and that device id string (VPC2004)
> is hardcoded. So I'm assuming that'll remain the same.
I see, however the string comes from the ideapad_device_ids array. To me that looks like there could be multiple device ids in the future and therefore multiple paths to check for tablet-mode. thinkpad_acpi and hp-wmi have just a single path for all supported devices. Basically one path per driver rather than per device:
/sys/devices/platform/hp-wmi/tablet
/sys/devices/platform/thinkpad_acpi/hotkey_tablet_mode

Something like
/sys/devices/platform/ideapad-laptop/tablet_mode
seems more in line with the other drivers and we in Onboard wouldn't have to update the detection for each newly supported device by ideapad-laptop.

> Other than that path, there's nowhere else is sysfs where it writes, that
> could be useful from an unprivileged user point of view.
Yes, agreed, else we couldn't read it from Onboard. However, maybe the sysfs stuff can be copied from one of the other drivers?

> If it is outrightly rejected, a counter patch could be to just expose the
> touchpad on/off state in sysfs (non /s/k/debug path) and then onboard could
> still rely on that ?
If there is no other way then yes, I would add it. Although, you can already configure custom files with
gsettings set org.onboard.auto-show tablet-mode-state-file "/sys/..."
and a
gsettings set org.onboard.auto-show tablet-mode-state-file-pattern "0"
that negates the value of the file.

[marmuta (marmuta)]

From #58:
> Btw., I realized blacklisting tablet-mode keys for auto-hide on
> keypress may not be enough in your case. There's still that ± key
> being sent along with global key press 201. Maybe I have to
> restrict auto-hide to alpha-numeric keys and modifiers or something.
> Or somehow decide which source devices are "real" keyboards, if that
> is possible. Not sure yet. So, you probably have to keep "Hide when
> typing on a physical keyboard" off for a bit longer.

Ritesh, I finally came around doing this and I settled on detecting "real" keyboard devices. This means that you should be able to keep "Hide when typing..." enabled and ideapad-laptop would not trigger auto-hide-on-key-press.
That was the last missing piece, I believe.

We're going to release Onboard 1.4 very soon. If you have news from the driver people, let me know. I can still add that sysfs path.

[Ritesh Raj Sarraf (rrs)]

On Sun, 2017-02-12 at 10:38 +0000, marmuta wrote:
> Ritesh, I finally came around doing this and I settled on detecting "real"
> keyboard devices. This means that you should be able to keep "Hide when
> typing..." enabled and ideapad-laptop would not trigger auto-hide-on-key-
> press.
> That was the last missing piece, I believe.
>

Yes. Thanks for adding it.

> We're going to release Onboard 1.4 very soon. If you have news from the
> driver people, let me know. I can still add that sysfs path.

Having it configurable via gsettings is enough.

I have attached the final patch that I had proposed, but for whatever reasons,
the maintainer isn't convinced that that interface is needed.

For other Yoga users, you should be able to use this patch. The patch enables a
user-readable sysfs interface for the toucpad state (instead of creating a
tablet interface based on touchpad state). This sysfs interface can be
configured in Onboard through the gsettings interface.

--
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."

[marmuta (marmuta)]

OK. Thanks for the patch, too bad it wasn't accepted. I'll point people here when I hear from other Ideapad users.

[Ritesh Raj Sarraf (rrs)]

Attached is v4 of the Linux kernel patch for Lenovo Yoga series hybrid laptops.

--
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System

Lenovo Yoga (many variants: Yoga, Yoga2 Pro, Yoga2 13, Yoga3 Pro, Yoga 3
14 etc) has multiple modles that are a hybrid laptop, working in laptop
mode as well as tablet mode.

Currently, there is no easy interface to determine the touchpad status,
which in case of the Yoga family of machines, can also be useful to
assume tablet mode status.
Note: The ideapad-laptop driver does not provide a SW_TABLET_MODE either

For a detailed discussion on why we want either of the interfaces,
please see:
https://bugs.launchpad.net/onboard/+bug/1366421/comments/43

This patch adds a sysfs interface for read/write access under:
/sys/bus/platform/devices/VPC2004\:00/touchpad_mode

v4:
Use kstrtobool because supported values are boolean

v3:
Include Darren Hart's comments
Changed sysfs inteface from "touchpad_mode" to "touchpad"

v2:
Include Andy Shevchenko's comments

Signed-off-by: Ritesh Raj Sarraf <email address hidden>
---
 .../ABI/testing/sysfs-platform-ideapad-laptop | 8 +++++
 drivers/platform/x86/ideapad-laptop.c | 34 ++++++++++++++++++++++
 2 files changed, 42 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-platform-ideapad-laptop b/Documentation/ABI/testing/sysfs-platform-ideapad-laptop
index b31e782bd985..5d24f1e8e6ef 100644
--- a/Documentation/ABI/testing/sysfs-platform-ideapad-laptop
+++ b/Documentation/ABI/testing/sysfs-platform-ideapad-laptop
@@ -17,3 +17,11 @@ Description:
    * 2 -> Dust Cleaning
    * 4 -> Efficient Thermal Dissipation Mode

+What: /sys/devices/platform/ideapad/touchpad
+Date: Feb 2017
+KernelVersion: 4.11
+Contact: "Ritesh Raj Sarraf <email address hidden>"
+Description:
+ Control touchpad mode.
+ * 1 -> Switched On
+ * 0 -> Switched Off
diff --git a/drivers/platform/x86/ideapad-laptop.c b/drivers/platform/x86/ideapad-laptop.c
index f46ece2ce3c4..b35954707e11 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -423,9 +423,43 @@ static ssize_t store_ideapad_fan(struct device *dev,

 static DEVICE_ATTR(fan_mode, 0644, show_ideapad_fan, store_ideapad_fan);

+
+static ssize_t touchpad_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct ideapad_private *priv = dev_get_drvdata(dev);
+ unsigned long result;
+
+ if (read_ec_data(priv->adev->handle, VPCCMD_R_TOUCHPAD, &result))
+ return sprintf(buf, "-1\n");
+ return sprintf(buf, "%lu\n", result);
+}
+
+static ssize_t touchpad_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct ideapad_private *priv = dev_get_drvdata(dev);
+ int ret;
+ bool state;
+
+ ret = kstrtobool(buf, &state);
+ if (ret)
+ return ret;
+
+ ret = write_ec_cmd(priv->adev->handle, VPCCMD_W_TOUCHPAD, state);
+ if (ret < 0)
+ return -EIO;
+ return count;
+}
+
+static DEVICE_ATTR_RW(touchpad);
+
 static struct attribute *ideapad_attributes[] = {
  &dev_attr_camera_power.attr,
  &dev_attr_fan_mode.attr,
+ &dev_attr_touchpad.attr,
  NULL
 };

--
2.11.0