Comment 62 for bug 1366421

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