search

lvgl / lv_drivers

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

Libinput and fbdev improvements for unl0kr #280

Open calebccff opened 1 year ago

calebccff commented 1 year ago

Add a framebuffer quirk to force the display to refresh after every draw, this is needed for some quirky panels and DRM/fbdev emulation setups. It requires that the display buffer is set to the same size as the whole framebuffer so that the entire display can be flushed at once if needed, otherwise there is tearing.

Also use pthreads and a small circular queue to stop the libinput driver from dropping inputs. The LVGL tickrate can't always keep up and this ensures that inputs aren't dropped.

The keypad support needs to be tested.

Cc: @Johennes

calebccff commented 1 year ago

Totally forgot to push :sweat_smile: sorry for the wait. The touch/pointer handling was actually pretty broken... Anyways, hopefully this is good to go now!

Johennes commented 1 year ago

Thanks for updating the PR @calebccff and sorry for the delay. I will take a look at this and test it within unl0kr but I won't manage before next week, unfortunately.

calebccff commented 11 months ago

Rebased on master and picked up Johannes' fixes (Thanks a lot for that!). Should be good to go! Tested again with unl0kr.

I added a new commit to properly handle typing with two thumbs by injecting some fake events, with this you can type as fast as you want with your thumbs and not miss an input which is really nice for unl0kr. See the commit description for more details.

I get that this is a bit of a hack, I'm happy to drop it if it blocks the rest of the series.

Johennes commented 11 months ago

Rebased on master and picked up Johannes' fixes (Thanks a lot for that!). Should be good to go! Tested again with unl0kr.

I added a new commit to properly handle typing with two thumbs by injecting some fake events, with this you can type as fast as you want with your thumbs and not miss an input which is really nice for unl0kr. See the commit description for more details.

I get that this is a bit of a hack, I'm happy to drop it if it blocks the rest of the series.

The slot stuff is clever!

One possible issue I'm seeing is that you're writing state->slots from both the polling thread and the LVGL input handler. The locking is avoiding concurrent writes. But depending on how fast events enter and leave the queue, I think it's possible for later multi-touch events to already have overridden the slots array filled by earlier ones before you could use it?

I guess generally it'd be nice if LVGL itself supported multi-touch but the event injection strikes me as an acceptable workaround until then (especially given that we already do some event rewriting with is_relative).

Johennes commented 11 months ago

One possible issue I'm seeing is that you're writing state->slots from both the polling thread and the LVGL input handler. The locking is avoiding concurrent writes. But depending on how fast events enter and leave the queue, I think it's possible for later multi-touch events to already have overridden the slots array filled by earlier ones before you could use it?

Actually, I think you can work around that by doing the event injection when reading from libinput as opposed to when consuming the cached events. The slots array is guaranteed to only be filled by events preceding the current one at that point.

Johennes commented 11 months ago

Actually, I think you can work around that by doing the event injection when reading from libinput as opposed to when consuming the cached events. The slots array is guaranteed to only be filled by events preceding the current one at that point.

This has been implemented, too, now.

Johennes commented 11 months ago

@kisvegabor this is now done from our end and ready for your review. I've tested it in unl0kr with touch, pointer and keyboard devices. Once we make another unl0kr release, I'll start working on porting this into lvgl master.