evdev / libinput: support KEY_POWER

[Johennes]

Some devices have dedicated power buttons that emit the KEY_POWER scan code. Here's an example from the power button on my laptop:

Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x0 product 0x1 version 0x0
Input device name: "Power Button"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 116 (KEY_POWER)
Properties:
Testing ... (interrupt to exit)
Event: time 1631010379.405744, type 1 (EV_KEY), code 116 (KEY_POWER), value 1
Event: time 1631010379.405744, -------------- SYN_REPORT ------------
Event: time 1631010379.405837, type 1 (EV_KEY), code 116 (KEY_POWER), value 0
Event: time 1631010379.405837, -------------- SYN_REPORT ------------

As an addendum to #153 and #155, it would be nice if:

1. the libinput driver could automatically recognize power-button devices
2. the evdev / libinput drivers could handle KEY_POWER

For 1, we'd just have to add another case to the libinput_capability enum and a corresponding capability check (just like we do for the other device types in #157).

For 2, performing the shutdown is as easy as

#include <sys/reboot.h>
sync();
reboot(RB_POWER_OFF);

However, I am not sure how to best integrate this into the existing drivers. :thinking:

We could add a new case to LV_INDEV_TYPE_POWER to the lv_indev_type_t enum in lvgl but that might mean quite invasive changes.

Alternatively, we could just use LV_INDEV_TYPE_KEYPAD for power button devices and handle the key in indev_keypad_proc. It'll feel a little odd to refer to the device as "keypad" but after all the kernel treats it as a keyboard, too, because it can send keys so maybe that's the best approach.

[kisvegabor]

Interesting idea but I like it. It sounds like a generic method to shout down a device.

Alternatively, we could just use LV_INDEV_TYPE_KEYPAD for power button devices and handle the key in indev_keypad_proc. It'll feel a little odd to refer to the device as "keypad" but after all the kernel treats it as a keyboard, too, because it can send keys so maybe that's the best approach.

It's really invasive a little but I have and other idea too. :slightly_smiling_face: We can treat it as LV_KEY_POWER. If the user registers a feedback_cb on hte input device the callback will be called on every event generated by that indev. The great thing in that feedback_cb is called regardless to the focused widget.

What do you think?

[Johennes]

Ah, I wasn't aware of feedback_cb. Agreed, that seems much better. This way the client code can decide what to do with power key presses. :+1:

[kisvegabor]

Do you think we still should have LV_KEY_POWER in LVGL?

[Johennes]

Yeah, I think that's a good idea. :+1:

I can send a PR when I have time.

[Johennes]

Following the discussion on #163, there seems to be no good / non-invasive way to add this into lv_drivers at the moment. Since this is only a very small use case for my app, I'll close it for now. Thanks for helping to brainstorm it.

[kisvegabor]

Thank you too! :slightly_smiling_face: