search

lvgl / lv_drivers

TFT and touch pad drivers for LVGL embedded GUI library
https://docs.lvgl.io/master/porting/index.html
MIT License
306 stars 314 forks source link

Add support for devices with KEY_POWER #163

Closed Johennes closed 3 years ago

Johennes commented 3 years ago

This makes it possible to automatically locate power buttons (which have KEY_POWER) via libinput. Additionally, a new LV_KEY_POWER key is introduced that is dispatched whenever KEY_POWER is pressed.

In order to handle LV_KEY_POWER, the client needs to register an indev with type LV_INDEV_TYPE_KEYPAD and set the feedback_cb callback. Additionally, the indev needs to be assigned a group with at least one element.

Note: This is a draft and I'd like to get feedback on it. The fact that a group has to be assigned feels a little odd but that was the only way to make feedback_cb be called. After having tried it out, I'm not sure if this is a good way to implement support for KEY_POWER. Maybe it'd be better if the client would supply a custom read_cb and handle the KEY_... events manually because in the case of KEY_POWER, we don't really need any of the group logic?

Fixes: #161

kisvegabor commented 3 years ago

Additionally, the indev needs to be assigned a group with at least one element.

Uh, it's really odd. I forgot about it. Usually, if there is a KEYPAD indev there are group(s) too but it's really no that logical.

Maybe it'd be better if the client would supply a custom readcb and handle the KEY... events manually because in the case of KEY_POWER, we don't really need any of the group logic?

If we can't give clean solution IMO it's better to leave it to the user as you suggested.

Johennes commented 3 years ago

If we can't give clean solution IMO it's better to leave it to the user as you suggested.

Ok, that sounds fair. I'll close this.