Lvgl input sink

[faxe1008]

The goal of this change is to allow for the zephyr device notion to be mappable to the lvgl indev concept.
Previously this was done for kscan devices to allow for touch input. However LVGL offers more input devices for HMIs which only have hardware input capabilites (buttons, encoder, keypad) https://docs.lvgl.io/latest/en/html/porting/indev.html.

In theory today using those lvgl concepts is possible put it requires user app code to "plumb" together this mapping and set it up correctly. Since we are already providing the "compatiblity" layer between kscan devices and the lvgl pointer indev I figured that we might as well generalize the mechanism to accomodate it for the other ones.

This PR is my attempt to create a compile time mapping of the zephyr device tree to lvgl indevs. Things that I am still not completely sure about:

• Currently one "mapping" entry is created for each input device in the device tree if the corresponding Kconfig option is set. If CONFIG_LV_Z_BUTTON is set an mapping entry for each gpio-keys is created, which "wastes" memory since the the button might not be related to the HMI input but other functions. They will not do any harm however since the indev has to be configured to act on a lv_group_t or trigger a press on a given lv_coor_t.
• I attempted to have this change as backwards compatible as possible, so that also kscan devices still continue to work for pointer indev. However in the process I changed the bool Kconfig option to a choice to also allow input devices directly without proxying them through a kscan instance.
• General naming of things, sanity of msgq default sizes etc.

I would really love to hear some suggestions/comments on this especially by you @fabiobaltieri since you are the maintainer of the input subsystem :^).

[fabiobaltieri]

Hey so cool you are working on it! Haven't gone to the details but I think you overcomplicated things a fair bit for the sake of building on top of existing device definitions (gpio-keys and gpio-qdec).

This is what I had in mind instead (mind you I did not write any code, that's your project now :-))

• Define a new device type for the LVGL sink, similar to the longpress one (https://github.com/zephyrproject-rtos/zephyr/blob/main/dts/bindings/input/zephyr%2Cinput-longpress.yaml), either one per LVGL input type or just one and then resolve the type with a property. This would have a device property to tie to a specific input device, or none to listen for events from all devices.
• Now you can iterate over those with DT_INST_FOREACH_STATUS_OKAY (again same as https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/input/input_longpress.c), and get all the structures and callback instances you need.
• The new compatible node would be a good place to put all the settings you need, I think it may be a good idea to move swap-xy, invert-x, invert-y there and off Kconfig, but also you could have the absolute axis codes to listen to for encoders, button codes and x/y coordinates for buttons etc

At that point I don't really think you need the custom section anymore, so that would simplify things a bit. For the implementation and compatibility, maybe it make sense to move the kscan one in its own file and go from scratch with lvgl_input_sink.c? Just thinking that the two could coexist for a bit, we can mark the kscan one as deprecated and delete it down the road. How does that sound?

[faxe1008]

Thanks for the review :^).

you overcomplicated a fair bit for the sake of building on top of existing device definitions (gpio-keys and gpio-qdec).

Yeah, my goal was essentially to have most of the changes be in the lvgl module, but I guess the addition in zephyr can be conditional on CONFIG_LVGL.

The new compatible node would be a good place to put all the settings you need, I think it may be a good idea to move swap-xy, invert-x, invert-y there and off Kconfig,

That sounds great, felt a bit weird to have this as a Kconfig option in the first place. I'd like to have one device binding and give it a type property to decide on it's indev. Is there any sensible way to detect "mis-linkage" of the underlying device in the longpress example? Because it might not make sense for a user to have a pointer indev tied to a gpio-keys.

maybe it make sense to move the kscan one in its own file and go from scratch with lvgl_input_sink.c

Sounds good 👍

[fabiobaltieri]

Yeah, my goal was essentially to have most of the changes be in the lvgl module, but I guess the addition in zephyr can be conditional on CONFIG_LVGL.

You can have bindings in the module, I think if you create a dts/bindings directory they'll get detected automatically, though we may want to reconsider where is development happening. Let's open a separate conversation for that, easy enough to move it back and forth but let's not do it if it's not necessary. I'll open an issue about it.

That sounds great, felt a bit weird to have this as a Kconfig option in the first place. I'd like to have one device binding and give it a type property to decide on it's indev. Is there any sensible way to detect "mis-linkage" of the underlying device in the longpress example? Because it might not make sense for a user to have a pointer indev tied to a gpio-keys.

Not really, a device is just a device and can generate anything. Linux has the concept of capabilities where an input device has to declare what event it intends to generate and then the client can see if it's happy with it, but we did not port it over. It's not like there's anything like that in the rest of the rtos, you could link a wrong device phandle anywhere and the system would just crash. I'd say just add some strategic LOG_DBG and that should be enough to figure what's going on.

As for single binding with type vs multiple bindings: I'm thinking you may get a cleaner result with a binding per indev type, cause you'll probably have different properties for each type and you could more easily have some BUILD_CHECK for the specific type. Up to you though.

[faxe1008]

@fabiobaltieri thanks for the input 😄, I implemented your suggested changes over at:
zephyrproject-rtos/zephyr#60867