Button callback in button example not always firing

[zborro]

Hi,

At the beginning I would like to say that I appreciate your hard work working on this project. Truly amazing.

The issue I have is that I have built button example just to test it, but when I click on the button, the callback is not always fired. Sometimes it works, sometimes it doesn't. Please take a look at the log below. Notice that coordinates don't change, but the button sometimes won't receive event. It doesn't matter how long I press mouse button down.

Looking at the code I'm unable to say where the problem lies. I tried to play around with sleep time (documentation says it should be between 1 and 10 milliseconds) - no luck. As for lv_conf.h and lv_drv_conf.h, I just copied templates and enabled them with ifdef.

Clicked on: Point { x: 123, y: 130 }
Button received event: Pressed
Button received event: Pressing
Button received event: Released
Button received event: ShortClicked
Button received event: Clicked
Clicked on: Point { x: 123, y: 130 }
Clicked on: Point { x: 123, y: 130 }
Clicked on: Point { x: 123, y: 130 }
Clicked on: Point { x: 123, y: 130 }
Clicked on: Point { x: 123, y: 130 }
Clicked on: Point { x: 123, y: 130 }
Clicked on: Point { x: 123, y: 130 }

If there's anything I can help with please let me know.

EDIT: I didn't state it, but I checked plain LVGL button demo too and from what I can tell it hasn't this issue.

[nia-e]

Hi, thanks for the issue report!

Was this on latest master or version 0.6.2? This was a known issue on 0.6.2 that (I thought) has since been fixed. If on latest master, can you rerun with LV_LOG_LEVEL_INFO and provide those logs?

[zborro]

Thanks for fast reply!

0.6.2

Was it reported? If so, I need to improve my search skills. I'm going to test master soon.

[nia-e]

Not reported, just turned out to be a small issue with the timer. A lot of (quite important) bugfixes have been published since 0.6.2 so expect a new stable version soon-ish

[zborro]

Ok, here are logs with INFO enabled and on master*:

[Info]  (0.000, +0)      lv_init: begin         (in lv_obj.c line #102)
[Info]  (0.000, +0)      lv_obj_create: begin   (in lv_obj.c line #206)
[Info]  (0.000, +0)      lv_obj_create: begin   (in lv_obj.c line #206)
[Info]  (0.000, +0)      lv_obj_create: begin   (in lv_obj.c line #206)
[Info]  (0.000, +0)      lv_btn_create: begin   (in lv_btn.c line #51)
[Info]  (0.000, +0)      lv_label_create: begin         (in lv_label.c line #75)
[Info]  (0.000, +0)      lv_obj_update_layout: Layout update begin      (in lv_obj_pos.c line #314)
[Info]  (0.000, +0)      lv_obj_update_layout: Layout update begin      (in lv_obj_pos.c line #314)
[Info]  (0.000, +0)      lv_obj_update_layout: Layout update begin      (in lv_obj_pos.c line #314)
[Info]  (0.000, +0)      lv_obj_update_layout: Layout update begin      (in lv_obj_pos.c line #314)
Clicked on: Point { x: 79, y: 123 }
Clicked on: Point { x: 79, y: 123 }
Clicked on: Point { x: 79, y: 123 }
[Info]  (3.673, +3673)   indev_proc_press: pressed at x:79 y:123        (in lv_indev.c line #819)
Button received event: Pressed
Button received event: Pressing
[Info]  (3.711, +38)     indev_proc_release: released   (in lv_indev.c line #967)
Button received event: Released
Button received event: ShortClicked
Button received event: Clicked
[Info]  (3.711, +0)      lv_obj_update_layout: Layout update begin      (in lv_obj_pos.c line #314)
[Info]  (3.711, +0)      lv_obj_update_layout: Layout update begin      (in lv_obj_pos.c line #314)
Clicked on: Point { x: 79, y: 123 }
[Info]  (4.734, +1023)   indev_proc_press: pressed at x:79 y:123        (in lv_indev.c line #819)
Button received event: Pressed
Button received event: Pressing
[Info]  (4.772, +38)     indev_proc_release: released   (in lv_indev.c line #967)
Button received event: Released
Button received event: ShortClicked
Button received event: Clicked
[Info]  (4.772, +0)      lv_obj_update_layout: Layout update begin      (in lv_obj_pos.c line #314)
[Info]  (4.772, +0)      lv_obj_update_layout: Layout update begin      (in lv_obj_pos.c line #314)
Clicked on: Point { x: 79, y: 123 }
Clicked on: Point { x: 79, y: 123 }
[Info]  (5.873, +1101)   indev_proc_press: pressed at x:79 y:123        (in lv_indev.c line #819)
Button received event: Pressed
Button received event: Pressing
[Info]  (5.911, +38)     indev_proc_release: released   (in lv_indev.c line #967)
Button received event: Released
Button received event: ShortClicked
Button received event: Clicked
[Info]  (5.911, +0)      lv_obj_update_layout: Layout update begin      (in lv_obj_pos.c line #314)
[Info]  (5.911, +0)      lv_obj_update_layout: Layout update begin      (in lv_obj_pos.c line #314)

You see, the first two clicks got lost. The third, although on the same coords fires the callback. It repeats. I believe this is enough.

Now I'm not sure if I'm truly on master, but I believe so:

$ awk 'f{print} /dependencies/{f=1}' Cargo.toml
cstr_core = "0.2.6"
embedded-graphics = "0.7.1"
embedded-graphics-simulator = "0.4.1"
log = "0.4.17"
log4rs = "1.2.0"
lvgl = { git = "https://github.com/lvgl/lv_binding_rust/", version = "0.6.2" }
lvgl-sys = { git = "https://github.com/lvgl/lv_binding_rust/", version = "0.6.2" }

$ grep 'lv_binding_rust' Cargo.lock
source = "git+https://github.com/lvgl/lv_binding_rust/#a340b5ff1f4c25a6b87241264cecd55f48368f40"
source = "git+https://github.com/lvgl/lv_binding_rust/#a340b5ff1f4c25a6b87241264cecd55f48368f40"
source = "git+https://github.com/lvgl/lv_binding_rust/#a340b5ff1f4c25a6b87241264cecd55f48368f40"

My setup is: Arch Linux with i3-wm. Versions of SDL libraries:

$ pacman -Q | grep -i sdl
sdl2 2.26.5-1
sdl2_image 2.6.3-1
sdl2_ttf 2.20.2-1

[zborro]

I added dependencies with explicit --rev too, just to make sure it's that revision:

$ awk 'f{print} /dependencies/{f=1}' Cargo.toml
cstr_core = "0.2.6"
embedded-graphics = "0.7.1"
embedded-graphics-simulator = "0.4.1"
log = "0.4.17"
log4rs = "1.2.0"
lvgl = { git = "https://github.com/lvgl/lv_binding_rust/", rev = "a340b5ff1f4c25a6b87241264cecd55f48368f40", version = "0.6.2" }
lvgl-sys = { git = "https://github.com/lvgl/lv_binding_rust/", rev = "a340b5ff1f4c25a6b87241264cecd55f48368f40", version = "0.6.2" }

$ grep 'lv_binding_rust' Cargo.lock
source = "git+https://github.com/lvgl/lv_binding_rust/?rev=a340b5ff1f4c25a6b87241264cecd55f48368f40#a340b5ff1f4c25a6b87241264cecd55f48368f40"
source = "git+https://github.com/lvgl/lv_binding_rust/?rev=a340b5ff1f4c25a6b87241264cecd55f48368f40#a340b5ff1f4c25a6b87241264cecd55f48368f40"
source = "git+https://github.com/lvgl/lv_binding_rust/?rev=a340b5ff1f4c25a6b87241264cecd55f48368f40#a340b5ff1f4c25a6b87241264cecd55f48368f40"

The issue is still there:

Clicked on: Point { x: 164, y: 105 }
Clicked on: Point { x: 164, y: 105 }
Clicked on: Point { x: 164, y: 105 }
Clicked on: Point { x: 164, y: 105 }
Clicked on: Point { x: 164, y: 105 }
Clicked on: Point { x: 164, y: 105 }
[Info]  (14.713, +2622)  indev_proc_press: pressed at x:164 y:105       (in lv_indev.c line #819)
Button received event: Pressed
Button received event: Pressing

[nia-e]

Can I see your code (assuming from your Cargo.toml that you're on a separate project and not using cargo run --example ... here)? The button example was altered slightly since 0.6.2, namely the fix for the issue was to modify the event loop to this:

let start = Instant::now();
lvgl::task_handler();
window.update(&sim_display);

/* ... */

sleep(Duration::from_millis(15));
lvgl::tick_inc(Instant::now().duration_since(start));

Note that also you can just specify lvgl = { git = "https://github.com/lvgl/lv_binding_rust/", branch = "master" } in Cargo.toml to get the master branch

[zborro]

Sure. Here you go: https://github.com/zborro/lvgl-rust-button-click-issue-112

(I got button example from master, not 0.6.2 btw), I used diff to see and the only difference was number of millis)

I see you're quite responsive, which is fantastic! But I need to take care of something else now. I'll be back in couple of hours, though.

[nia-e]

Hmm, I ran it and didn't experience the same issues - also Arch, but KDE on X11. I unfortunately also have to go in a bit (starting to get outside of my work hours in my timezone) but I'll test out i3 tomorrow and see if I can replicate the issue.

Meanwhile, maybe try using the sdl example as a base? I've had far fewer issues with that and generally the code tends to be simpler as the main event loop is almost entirely handled by the SDL2 driver. Regardless, this is clearly serious and I'll try to get it fixed ASAP.

Edit: I got it to replicate, but only on very low millisecond times for the frame duration. Still can't dig into this right now, but I have some suspicions. The SDL example still works fine at low ms values so I assume the bug may result from how embedded-graphics handles click events (that is, slowly). Still, will see what I can do.

[zborro]

Thanks for confirming.
I'll test with SDL later on. Perhaps I need to do something, because it doesn't compile right away:

error[E0425]: cannot find function `sdl_init` in crate `lvgl_sys`
error[E0425]: cannot find value `sdl_display_flush` in crate `lvgl_sys`
error[E0425]: cannot find value `sdl_mouse_read` in crate `lvgl_sys`

[nia-e]

Ah, make sure USE_SDL is set to 1 in lv_drv_conf.h. This will be done automatically once #82 gets merged but that is still a bit off.

[nia-e]

To be clear, the docs will be expanded and updated in time for the next release. It's probably my first priority once I get some bugfixing done.

[zborro]

I think I can confirm that with SDL it works flawlessly.

There are two other issues, though:

• it doesn't play well with i3 when resolution is set 240x240
• setting resolution to higher value makes it segfaults with thread 'main' has overflowed its stack

Not to mention the issue with high CPU usage I noticed. Is there any place where we can continue such discussions? I don't want this ticket to contain offtop.

[nia-e]

I opened #113 for the overflow; it's a known issue but also one that's been quite headache inducing and with increased attention on this crate it's worth having the fix somewhere obvious. For performance, try building with --release and if that still doesn't give good performance open a new issue for that.

[zborro]

Thanks.

While trying to confirm that --release will help I got another SIGSEGV. Debug build for the same code works well.

➜  app112 git:(master) ✗ ./target/release/app112
[Info]  (0.000, +0)      lv_init: begin         (in lv_obj.c line #102)
[Info]  (0.000, +0)      lv_obj_create: begin   (in lv_obj.c line #206)
[Info]  (0.000, +0)      lv_obj_create: begin   (in lv_obj.c line #206)
[Info]  (0.000, +0)      lv_obj_create: begin   (in lv_obj.c line #206)
[Info]  (0.000, +0)      lv_btn_create: begin   (in lv_btn.c line #51)
[Info]  (0.000, +0)      lv_label_create: begin         (in lv_label.c line #75)
[Info]  (0.000, +0)      lv_obj_update_layout: Layout update begin      (in lv_obj_pos.c line #314)
[Info]  (0.000, +0)      lv_obj_update_layout: Layout update begin      (in lv_obj_pos.c line #314)
[Info]  (0.000, +0)      lv_obj_update_layout: Layout update begin      (in lv_obj_pos.c line #314)
[Info]  (0.000, +0)      lv_obj_update_layout: Layout update begin      (in lv_obj_pos.c line #314)
[1]    137664 segmentation fault (core dumped)  ./target/release/app112

I checked it too (the repo I created) on other machine with Ubuntu, but also i3-wm - also segfault. Now I'm checking it on Debian in VirtualBox, that will take while.

Trace doesn't tell much more:

[Trace] (0.000, +0)      lv_obj_update_layout: Layout update end        (in lv_obj_pos.c line #317)
[Trace] (0.000, +0)      event_send_core: Sending event 18 to 0x55f1494785b0 with 0x7ffd67c93550 param  (in lv_event.c line #428)
[Trace] (0.000, +0)      event_send_core: Sending event 20 to 0x55f1494785b0 with 0x55f1494772c8 param  (in lv_event.c line #428)
[Trace] (0.000, +0)      event_send_core: Sending event 21 to 0x55f1494785b0 with 0x55f1494772c8 param  (in lv_event.c line #428)
[Trace] (0.000, +0)      event_send_core: Sending event 26 to 0x55f1494785b0 with 0x7ffd67c93350 param  (in lv_event.c line #428)
[1]    139755 segmentation fault (core dumped)  ./target/release/app112

I compiled release version with debug symbols and it segfaults too. Unfortunately GDB isn't very helpful:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()

[nia-e]

Don't worry, I'll take a look with LLDB tomorrow - it offers much better traces than GDB since rustc uses LLVM internally. C interop is pain. Push your new code to that repository and I'll take a look

[zborro]

I didn't use LLDB before. This is what it teels. It looks like accessing null pointer or something of that sort.

[Trace] (0.000, +0)      event_send_core: Sending event 26 to 0x5555557495b0 with 0x7ffffffe0d80 param  (in lv_event.c line #428)
Process 146582 stopped
* thread #1, name = 'app112', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
    frame #0: 0x0000000000000000
error: memory read failed for 0x0

I'm installing the VM already, so at least I will come back here to say whether it also segfaults under Debian with Gnome.

[nia-e]

Unfortunately this sort of stuff is very difficult to debug remotely. If the code fails on Arch, though, it should fail on my system too so I'll build and look into it.

[zborro]

Just to let you know - under Gnome over Wayland on Debian VM it doesn't crash. I have also checked i3-wm under same VM and it doesn't crash either.

There are still lot of moving parts here that might be our culprit, but I would look into whether switching from Wayland to Xorg causes the problem to appear.

Hopefully you find this useful. Since I don't want to meddle into your plans anymore I'm leaving it as for now. Thanks.

[nia-e]

Don't worry, this is useful info. Just send over your code so I can build and test it, as the sdl example in this crate alone seems to run fine for me ^^ or send me an optimized binary with debug = true

[zborro]

Sure, I created crash branch in the repository posted above, which you can use to try to reproduce behavior I'm facing. Thanks.

[zborro]

yet another update: I noticed lv_drv_conf.h contains dimensions too, so I changed these in source file to be aligned. It's commited now. It still crashes, but at least now it isn't so glitched it was.

[nia-e]

Enabling the alloc feature seems to fix the segfault. Will need to investigate more as to why that is, since that's definitely not intended (though making it enabled by default might be a good call). It's 1 AM right now though so I won't be touching LLDB anymore for the night 😅

[nia-e]

As for the initial issue, needless to say I did not take my own advice of going to bed. See #114 and let me know if it fixes the issue.

[zborro]

Hah. I checked it and issue seems to be gone. Thanks a lot for fixing it!

[nia-e]

Perfect! I'll close this for now and see what's up with the segfaulting when alloc isn't enabled... some other time. If I can't fix it soon, I'll open a separate issue to track it.

[zborro]

Sure. I was about to add that I get two new compilation warnings with your code but that's really minor. Given that I'm already here maybe you have some low hanging fruits for me so I can actually give something in return. I have to say that I perceive your help and attitude to be excellent!

😸

warning: variable `latest_touch_point` is assigned to, but never used
warning: variable does not need to be mutable

[nia-e]

Damnit, I missed those. I'll fix that in the next PR I open. If you want to help out, bug reports are very useful; I'm very very bad at QA. Other than that, feel free to look around some recent issues where I ask for feedback if you have any ideas e.g. #109 and such.

I appreciate the compliments :D this is a bit of a passion project for me, initially as part of a different project I was doing where I needed LVGL (https://git.haecceity.cc/nia/mxboot) and now I guess I'm maintaining this. It's a lot of fun and I'm glad to help people out

[zborro]

If you don't mind... #116

I'll look around how can I help with either bug reports or issues.