lvgl-micropython / lvgl_micropython

LVGL module for MicroPython
MIT License
63 stars 19 forks source link

Events firing multiple times #31

Closed TecDroiD closed 4 months ago

TecDroiD commented 5 months ago

Sorry for bothering you again..

Firstly, my current code:

import lvgl as lv
import time

click_counter = 0

def button_callback(event):
    """ called when button is clicked
    """
    global click_counter
    click_counter += 1
    target = event.get_target_obj()
    label = target.get_child(0)
    label.set_text(f"Clicked {click_counter}")

def labeled_button(scrn, text):
    """ create a labeled button
    """
    btn = lv.button(scrn)
    label = lv.label(btn)
    label.set_text(text)
    return btn

def create_mainview():
    """ this aims to create the main view for the application
    """
    scrn = lv.obj()
    scrn.set_style_bg_color(lv.color_hex(0x00ff00), 0)

    btn = labeled_button(scrn, "ClickMe")
    btn.add_event_cb(button_callback, lv.EVENT.CLICKED, None) # also tried PRESSED and RELELASED
    btn.align_to(scrn, lv.ALIGN.TOP_MID, 0, 0)

    kb = lv.keyboard(scrn)
    return scrn

def run():
    """ this runs the application itself
    """
    try:
        mainview = create_mainview()
        lv.screen_load(mainview)

        while True:
            time.sleep_ms(1)
            lv.tick_inc(1)
            lv.task_handler()
    except Exception as e:
        print(str(e))

Now the problem: Everytime, I press the button, my click counter counts at least two upwards (even when I use RELEASED). When I keep my finger on the button, it starts counting until i release the button).

I'd expect the event to fire only once when the button is released. So what's wrong here?

Also, clicking the Shift (ABC) on the screen-keyboard, it changes to high only for a fraction of a second and then back to decapitalized letters.

kdschlosser commented 5 months ago

That's because you have the refresh rate too high. You need to turn it down a bit. The refresh is also tied to when it checks for touch input. I would scale it back to 15ms or more.

This is the code block I am talking about.

        while True:
            time.sleep_ms(1)
            lv.tick_inc(1)
            lv.task_handler()
TecDroiD commented 5 months ago

Hey Kevin, basically, as far as i understand the pointer_framework, it shouldn't react unless press state changes. When i touch the screen, gt911 driver sends back (lv.PRESSED, x, y). As long as state didn't change, no action should take place- res in pointer_framework._read is set to False.. So basically, no event should fire and nothing should happen until i release the touchscreen.

I wrote a little program to test the GT911:

import application

import lvgl as lv
import display
lv.init()
_display = display.create_display()
_touch = display.create_touch()

#if "run" in application.__dict__:
#    application.run()
import time

old_state = _touch.RELEASED
while True:
    time.sleep_ms(1)
    val = _touch._get_coords()
    if val is not None:
        if old_state != val[0]:
            old_state = val[0]
            print(val)
    else:
        if old_state != _touch.RELEASED:
            old_state = _touch.RELEASED
            print(val)

This works well when I sleep for about 50ms- so GT911 seems to be slow. Okay.. but setting the sleep in my application as seen above does not have any effect besides a slower moving click counter.

Next thing I tried is adding a callback for ALL events on my screen and printed them. With a current sleep rate of 150 ms, I get about 5 times the pressed event.

In my opinion, something reads the gt911 frequently and too fast. Sadly, I don't know where this is implemented.

kdschlosser commented 5 months ago

When the touch gets pressed is when the state will change to pressed and then when it gets released to will change. while the screen is being pressed it should remain pressed. If the state from the GT911 driver changes from pressed to released while you are still touching the screen then that is a problem with the driver. If it doesn't and you are still getting the double callback then that is a problem in LVGL and it needs to be reported. Before we open an issue in LVGL about it we need to confirm where the issue is first.

You will need to edit the GT911 driver and add a couple of print statements in there for me.

    def _get_coords(self):
        self._i2c.read_mem(_STATUS_REG, buf=self._mv[:1])
        touch_cnt = self._buf[0] & 0x0F

        if self._buf[0] & 0x80 or touch_cnt < 6:
            self._buf[0] = 0x00
            self._i2c.write_mem(_STATUS_REG, buf=self._mv[:1])

        if touch_cnt == 1:
            self._i2c.read_mem(_POINT_1_REG, buf=self._mv)

            x = self._buf[0] + (self._buf[1] << 8)
            y = self._buf[2] + (self._buf[3] << 8)

            self._buf[0] = 0x00
            self._i2c.write_mem(_STATUS_REG, buf=self._mv[:1])
            print('touch pressed')
            return self.PRESSED, x, y
        print('touch released')

go ahead and upload the gt911 driver to the MCU.. If you have the driver baked into the firmware don't worry when you upload the new one it will override the one that is baked into the firmware.

Use this code below along with your normal driver setup and loop code.


count = 0

def callback(_):
    global count

    count += 1
    print('clicked', count)

button = lv.button(lv.screen_active())
button.center()
button.add_event_cb(callback, lv.EVENT.CLICKED, None)

watch and see if you get the double events and if those double events are happening because the touch driver is reporting that the touch has been released when you didn't release it.

kdschlosser commented 5 months ago

if you edit lv_conf.h in the lib folder. search for LV_DEF_REFR_PERIOD. If that is set to a 1 that might be too fast. 33 is the default amount.

As a note. The PRESSED and RELEASED are indev driver states, they are not the same as what is used in events. You also have RELEASED and PRESSED in the events as well but these are not good to be used to tell when the state of a button changes. That is what CLICKED is for in the events. pressed is literally that, when the screen is pressed. the event will keep on firing each loop so long as the display is pressed. Released will only fire a single time. CLICKED will only fire when the state changes on a control.

TecDroiD commented 5 months ago

okay. LV_DEF_REFR_PERIOD has never been changed and is still at 33. I'll try to set it up to 50 as soon as my computer is completely dry (did you ever sneeze while drinking something?)

here's the output your modification generated:

MicroPython v1.22.1-dirty on 2024-04-11; Generic ESP32S3 module with Octal-SPIRAM with ESP32S3
Type "help()" for more information.
>>> ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x1 (POWERON),boot:0x8 (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fce3810,len:0xf8c
load:0x403c9700,len:0xb3c
load:0x403cc700,len:0x2dd4
entry 0x403c989c
Touch Product id: bytearray(b'911\x00')
Touch Firmware version: 0x1060
Touch Vendor id: 0x0
Touch Configured width: 800
Touoch Configured height: 480
touch released
touch released
touch released
touch released
touch released
touch released
touch pressed
touch released
clicked 1
touch pressed
touch released
clicked 2
touch pressed
touch released
clicked 3
touch released
touch released
touch released
touch released
touch released
touch released
touch pressed
touch released
clicked 4
touch pressed
touch released
clicked 5
touch released
touch released
touch released
touch released
touch released
touch pressed
touch released
clicked 6
touch pressed
touch released
clicked 7
touch pressed
touch released
clicked 8
touch pressed
touch pressed
touch released
clicked 9
touch pressed
touch released
clicked 10
touch released
touch released

I pressed my button several times with different durations. sleep time in mainloop is 150ms

kdschlosser commented 5 months ago

It looks like when you released there is a single event that gets triggered like it is supposed to be working. If you are actually pressing and holding the button but it is still releasing then that would be an issue with the touch driver.

as you can see clicked only increments a single time when a release occurs. There is not multiple clicks occurring when a release happens.

touch pressed
touch released
clicked 1

touch pressed
touch released
clicked 2

touch pressed
touch released
clicked 3
touch released
touch released
touch released
touch released
touch released
touch released

touch pressed
touch released
clicked 4

touch pressed
touch released
clicked 5
touch released
touch released

see how they are in blocks. and each block only has a single increment of the click.

kdschlosser commented 5 months ago

Now the only thing that might be happening is your single touch might be getting interpreted as multiple. The driver is written so if there is more than one touch then all touches get ignored. I don't know which touch should be considered to be the correct one and that could cause things to jump around wildly which is why I ignore it as an invalid.

I am going to change that behavior I think. I will make it so that if there was a touch happening on the previous poll and then it changes to more than one touch I will recycle the last coords. Once there is a response of a single touch happening or no touch at all is when the state or coords will get updated.

Let me make that change. That might solve the issue you are having.

kdschlosser commented 5 months ago

OK I updated the driver. see if that helps with the problem.

kdschlosser commented 5 months ago

also change your mainloop code to be 33ms delay., 150ms is way to long.

TecDroiD commented 5 months ago

sadly, this didn't change anything. I tried to set LV_DEF_REFR_PERIOD to 50 - just for fun - but that didn't change much besides an annoying flickering..

kdschlosser commented 5 months ago

I am not sure why you are getting double events. according to what I am seeing from the output it looks like it is working properly.

Do me a favor and run that same test script above except this time press the display only a single time and release it only a single time. Paste the output here.

TecDroiD commented 5 months ago

Hi again, sorry.. I needed some time for other work.. so here's the result, all timers I know are set to 33 and I pressed my button for about half a second

�ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0xc (RTC_SW_CPU_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x403842ca
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fce3810,len:0xf8c
load:0x403c9700,len:0xb3c
load:0x403cc700,len:0x2dd4
entry 0x403c989c
Touch Product id: bytearray(b'911\x00')
Touch Firmware version: 0x1060
Touch Vendor id: 0x0
Touch resolution: width=800, height=480
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch released
touch pressed
touch released
clicked 1
touch pressed
touch released
clicked 2
touch released
touch released
kdschlosser commented 5 months ago

and you only pressed the button a single time?

The reason why I am asking is because if the refresh time is set to 33 milliseconds from the time you pressed the button until the last "released" in your log 165 milliseconds has passed and not 500.

TecDroiD commented 5 months ago

well.. i didn't measure the time but it felt like about half a second. .. i tried a little more precise for about a second and got 20 releases.

kdschlosser commented 5 months ago

OK so the issue is in the touch IC or the driver. We need to sort that out.. There are some settings that can be adjusted in the hardware for the IC that I am going to want you to change.


import gt911 as _gt911

gt911 = _gt911.GT911(i2c_bus)

hw = gt911.firmware_config

print('touch_press_level:', hw.touch_press_level)
print('touch_leave_level:', hw.touch_leave_level)
print('noise_reduction:', hw.noise_reduction)

set up the i2cBus and then ad this code after it. paste what gets output. I think we have an issue with the IC and the releasing of the touch. Lets see what is coded into the firmware and maybe we can adjust it.

TecDroiD commented 5 months ago

okay, here's the result Use Ctrl-] or Ctrl-x to exit this shell ESP-ROM:esp32s3-20210327 Build:Mar 27 2021 rst:0x1 (POWERON),boot:0x8 (SPI_FAST_FLASH_BOOT) SPIWP:0xee mode:DIO, clock div:1 load:0x3fce3810,len:0xf8c load:0x403c9700,len:0xb3c load:0x403cc700,len:0x2dd4 entry 0x403c989c Touch Product id: bytearray(b'911\x00') Touch Firmware version: 0x1060 Touch Vendor id: 0x0 Touch resolution: width=800, height=480 touch_press_level: 90 touch_leave_level: 70 noise_reduction: 10 touch released touch released

Sadly, I have only this single panel. Would be interesting to see how another one reacts..

kdschlosser commented 5 months ago

I have not had any issues with it using the GT911 I have here on my desk. There is another user which helped me develop this driver and his doesn't have this issue either. That is the reason why I am looking at the cause being from a firmware setting.

kdschlosser commented 5 months ago

The touch_press_level and touch_leave_level have a setting range of 0 to 255. I would start by adjusting those up to see what happens. set them to 150 and go from there...

import gt911 as _gt911

gt911 = _gt911.GT911(i2c_bus)

hw = gt911.firmware_config

hw.touch_press_level = 150
hw.touch_leave_level = 150

print('touch_press_level:', hw.touch_press_level)
print('touch_leave_level:', hw.touch_leave_level)
print('noise_reduction:', hw.noise_reduction)
hw.save()
kdschlosser commented 5 months ago

This code only needs to run a single time. the settings are saved to NV memory in the touch IC.

kdschlosser commented 5 months ago

You can write a GUI interface to adjust these settings if you want to, that's up to you. In the future I will probably write some kind of a framework for handling touch settings.

TecDroiD commented 5 months ago

Well.. firstly, it doesn't save the configuration. After rebooting the board, it's the defaults of 90 and 70 again. But also, value of 150 did not have any effect. I managed a friend to send me some other boards for testing. Maybe this helps. Currently, I have no idea what the problem may be besides some defective hardware. Sadly, I didn't save the preloaded firmware to test its behavior.

I'll try as soon as the boards arrived

kdschlosser commented 5 months ago

it doesn't save it at all? It should be...

So this is what I want you to do to test something for me.


import gt911 as _gt911

gt911 = _gt911.GT911(i2c_bus)

hw = gt911.firmware_config

hw.width= 300
hw.height= 200
hw.save()

import gc
del hw

gc.collect()
hw = gt911.firmware_config
print(hw.width, hw.height)
TecDroiD commented 5 months ago

okay, here we go.. I used this codefile

import i2c
import gt911 as gt9

i2c_bus = i2c.I2CBus( scl=20, sda=19, freq=100000, use_locks=False)

gt911 = gt9.GT911(i2c_bus)

hw = gt911.firmware_config
print("Setting resolution")
hw.width= 300
hw.height= 200
print(f"resolution set to {hw.width}, {hw.height}")
print ("saving ...")
hw.save()

print("cleanup")
import gc
del hw
gc.collect()

print("reload config")
hw = gt911.firmware_config
print(hw.width, hw.height)

and that's the result


>>> import testgt
Touch Product id: bytearray(b'911\x00')
Touch Firmware version: 0x1060
Touch Vendor id: 0x0
Touch resolution: width=800, height=480
Setting resolution
resolution set to 300, 200
saving ...
Touch Product id: bytearray(b'\x00t8\x00')
Touch Firmware version: 0x4166
Touch Vendor id: 0x5C
Touch resolution: width=23552, height=74
cleanup
reload config
800 480
kdschlosser commented 5 months ago

OK so something is getting boogered up with the firmware. I am going to have do look into that some more.

TecDroiD commented 4 months ago

got some question on gt911._get_coords() in line 117, ff, you reset the status register when bit 7 is set or bits 0:3 are smaller than 6, so less than 6 points are pressed. bit 7, as far as I understand, is set to 1 when gt911 is ready to be read. next, you handle the touch points, without regarding if the machine has readable data or not.. is this correct?

kdschlosser commented 4 months ago

I just updated the GT911 driver, see if that fixes the issue.

kdschlosser commented 4 months ago

I do not believe it is going to change the behavior but I do understand what you are getting at. The thing is if there is no readable data then the touch count is going to be zero. So there is a test that checks for that. I am checking to see if there is data waiting or if the touch count has been set if either of those things has taken place then I set that register to zero to clean that. Because I collected the touch count prior to resetting the register to zero I am able to check the count. Setting the register to zero has no effect on the registers that store the data. It is simply a marker for me to use to tell if the display has been touched or not.

What I am thinking is the verbiage they have used in the data sheet is not ideal. I am thinking that the status simply means that something has changed and I should only change what is getting returned if the status has been set to a one.

So the status can be a 1 and the touch count a zero and that would mean your finger has left the display. While you finger is on the display if the coordinates have not changed at all the status would be set to a zero and I should keep on returning the last data that was collected and not changing the state to released. I would only change the state to released if the status is set and there is no touch count.

This is how I am thinking the behavior might be for the driver.

TecDroiD commented 4 months ago

now there's something wrong in rgb_bus.c which doesn't allow me to compile:

_bus.c
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c: In function 'rgb_bus_trans_done_cb':
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:55:5: error: parameter 'callbacks' is initialized
55 |     esp_lcd_rgb_panel_event_callbacks_t callbacks = { .on_vsync = rgb_bus_trans_done_cb };
|     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:67:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
67 |     {
|     ^
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:226:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
226 |     {
|     ^
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:234:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
234 |     {
|     ^
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:243:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
243 |     {
|     ^
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:252:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
252 |     {
|     ^
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:276:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
276 |     {
|     ^
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:354:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
354 |     {
|     ^
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:440:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
440 |     {
|     ^
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:447:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
447 |     {
|     ^
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:484:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
484 |     {
|     ^
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:501:5: error: parameter 'mp_lcd_rgb_bus_type' is initialized
501 |     MP_DEFINE_CONST_OBJ_TYPE(
|     ^~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/lcd_types.h:7,
from /home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:6:
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:505:19: error: 'mp_lcd_rgb_bus_make_new' undeclared (first use in this function); did you mean 'mp_lcd_rgb_bus_type'?
505 |         make_new, mp_lcd_rgb_bus_make_new,
|                   ^~~~~~~~~~~~~~~~~~~~~~~
/home/tecdroid/git/lvgl_micropython/lib/micropython/py/obj.h:785:44: note: in definition of macro 'MP_DEFINE_CONST_OBJ_TYPE_EXPAND'
785 | #define MP_DEFINE_CONST_OBJ_TYPE_EXPAND(x) x
|                                            ^
/home/tecdroid/git/lvgl_micropython/lib/micropython/py/obj.h:789:179: note: in expansion of macro 'MP_DEFINE_CONST_OBJ_TYPE_NARGS_2'
789 | #define MP_DEFINE_CONST_OBJ_TYPE_NARGS(_1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11, _12, _13, _14, _15, _16, _17, _18, _19, _20, _21, _22, _23, _24, _25, _26, _27, _28, N, ...) MP_DEFINE_CONST_OBJ_TYPE_NARGS_##N
|                                                                                                                                                                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:501:5: note: in expansion of macro 'MP_DEFINE_CONST_OBJ_TYPE'
501 |     MP_DEFINE_CONST_OBJ_TYPE(
|     ^~~~~~~~~~~~~~~~~~~~~~~~
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:505:19: note: each undeclared identifier is reported only once for each function it appears in
505 |         make_new, mp_lcd_rgb_bus_make_new,
|                   ^~~~~~~~~~~~~~~~~~~~~~~
/home/tecdroid/git/lvgl_micropython/lib/micropython/py/obj.h:785:44: note: in definition of macro 'MP_DEFINE_CONST_OBJ_TYPE_EXPAND'
785 | #define MP_DEFINE_CONST_OBJ_TYPE_EXPAND(x) x
|                                            ^
/home/tecdroid/git/lvgl_micropython/lib/micropython/py/obj.h:789:179: note: in expansion of macro 'MP_DEFINE_CONST_OBJ_TYPE_NARGS_2'
789 | #define MP_DEFINE_CONST_OBJ_TYPE_NARGS(_1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11, _12, _13, _14, _15, _16, _17, _18, _19, _20, _21, _22, _23, _24, _25, _26, _27, _28, N, ...) MP_DEFINE_CONST_OBJ_TYPE_NARGS_##N
|                                                                                                                                                                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:501:5: note: in expansion of macro 'MP_DEFINE_CONST_OBJ_TYPE'
501 |     MP_DEFINE_CONST_OBJ_TYPE(
|     ^~~~~~~~~~~~~~~~~~~~~~~~
/home/tecdroid/git/lvgl_micropython/lib/micropython/py/obj.h:759:243: error: non-static initialization of a flexible array member
759 | #define MP_DEFINE_CONST_OBJ_TYPE_NARGS_2(_struct_type, _typename, _name, _flags, f1, v1, f2, v2) const _struct_type _typename = { .base = { &mp_type_type }, .name = _name, .flags = _flags, .slot_index_##f1 = 1, .slot_index_##f2 = 2, .slots = { v1, v2, } }
|                                                                                                                                                                                                                                                   ^
/home/tecdroid/git/lvgl_micropython/lib/micropython/py/obj.h:785:44: note: in definition of macro 'MP_DEFINE_CONST_OBJ_TYPE_EXPAND'
785 | #define MP_DEFINE_CONST_OBJ_TYPE_EXPAND(x) x
|                                            ^
/home/tecdroid/git/lvgl_micropython/lib/micropython/py/obj.h:789:179: note: in expansion of macro 'MP_DEFINE_CONST_OBJ_TYPE_NARGS_2'
789 | #define MP_DEFINE_CONST_OBJ_TYPE_NARGS(_1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11, _12, _13, _14, _15, _16, _17, _18, _19, _20, _21, _22, _23, _24, _25, _26, _27, _28, N, ...) MP_DEFINE_CONST_OBJ_TYPE_NARGS_##N
|                                                                                                                                                                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/tecdroid/git/lvgl_micropython/lib/micropython/py/obj.h:798:71: note: in expansion of macro 'MP_DEFINE_CONST_OBJ_TYPE_NARGS'
798 | #define MP_DEFINE_CONST_OBJ_TYPE(...) MP_DEFINE_CONST_OBJ_TYPE_EXPAND(MP_DEFINE_CONST_OBJ_TYPE_NARGS(__VA_ARGS__, _INV, 12, _INV, 11, _INV, 10, _INV, 9, _INV, 8, _INV, 7, _INV, 6, _INV, 5, _INV, 4, _INV, 3, _INV, 2, _INV, 1, _INV, 0)(mp_obj_type_t, __VA_ARGS__))
|                                                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:501:5: note: in expansion of macro 'MP_DEFINE_CONST_OBJ_TYPE'
501 |     MP_DEFINE_CONST_OBJ_TYPE(
|     ^~~~~~~~~~~~~~~~~~~~~~~~
/home/tecdroid/git/lvgl_micropython/lib/micropython/py/obj.h:759:243: note: (near initialization for 'mp_lcd_rgb_bus_type')
759 | #define MP_DEFINE_CONST_OBJ_TYPE_NARGS_2(_struct_type, _typename, _name, _flags, f1, v1, f2, v2) const _struct_type _typename = { .base = { &mp_type_type }, .name = _name, .flags = _flags, .slot_index_##f1 = 1, .slot_index_##f2 = 2, .slots = { v1, v2, } }
|                                                                                                                                                                                                                                                   ^
/home/tecdroid/git/lvgl_micropython/lib/micropython/py/obj.h:785:44: note: in definition of macro 'MP_DEFINE_CONST_OBJ_TYPE_EXPAND'
785 | #define MP_DEFINE_CONST_OBJ_TYPE_EXPAND(x) x
|                                            ^
/home/tecdroid/git/lvgl_micropython/lib/micropython/py/obj.h:789:179: note: in expansion of macro 'MP_DEFINE_CONST_OBJ_TYPE_NARGS_2'
789 | #define MP_DEFINE_CONST_OBJ_TYPE_NARGS(_1, _2, _3, _4, _5, _6, _7, _8, _9, _10, _11, _12, _13, _14, _15, _16, _17, _18, _19, _20, _21, _22, _23, _24, _25, _26, _27, _28, N, ...) MP_DEFINE_CONST_OBJ_TYPE_NARGS_##N
|                                                                                                                                                                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/tecdroid/git/lvgl_micropython/lib/micropython/py/obj.h:798:71: note: in expansion of macro 'MP_DEFINE_CONST_OBJ_TYPE_NARGS'
798 | #define MP_DEFINE_CONST_OBJ_TYPE(...) MP_DEFINE_CONST_OBJ_TYPE_EXPAND(MP_DEFINE_CONST_OBJ_TYPE_NARGS(__VA_ARGS__, _INV, 12, _INV, 11, _INV, 10, _INV, 9, _INV, 8, _INV, 7, _INV, 6, _INV, 5, _INV, 4, _INV, 3, _INV, 2, _INV, 1, _INV, 0)(mp_obj_type_t, __VA_ARGS__))
|                                                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:501:5: note: in expansion of macro 'MP_DEFINE_CONST_OBJ_TYPE'
501 |     MP_DEFINE_CONST_OBJ_TYPE(
|     ^~~~~~~~~~~~~~~~~~~~~~~~
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:54:17: error: old-style parameter declarations in prototyped function definition
54 |     static bool rgb_bus_trans_done_cb(esp_lcd_panel_handle_t panel, const esp_lcd_rgb_panel_event_data_t *event_data, void *user_data)
|                 ^~~~~~~~~~~~~~~~~~~~~
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:512: error: expected '{' at end of input
/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/rgb_bus.c:501:5: error: no return statement in function returning non-void [-Werror=return-type]
501 |     MP_DEFINE_CONST_OBJ_TYPE(
|     ^~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
[1288/1877] Building C object esp-idf/main_esp32s3/CMakeFiles/__idf_main_esp32s3.dir/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/esp32_src/i80_bus.c.obj
[1289/1877] Building C object esp-idf/main_esp32s3/CMakeFiles/__idf_main_esp32s3.dir/home/tecdroid/git/lvgl_micropython/ext_mod/lcd_bus/modlcd_bus.c.obj
[1290/1877] Building C object esp-idf/main_esp32s3/CMakeFiles/__idf_main_esp32s3.dir/home/tecdroid/git/lvgl_micropython/lib/micropython/lib/oofatfs/ff.c.obj
[1291/1877] Building C object esp-idf/main_esp32s3/CMakeFiles/__idf_main_esp32s3.dir/__/__/frozen_content.c.obj
[1292/1877] Building C object esp-idf/main_esp32s3/CMakeFiles/__idf_main_esp32s3.dir/home/tecdroid/git/lvgl_micropython/lib/lvgl/src/core/lv_obj_id_builtin.c.obj
[1293/1877] Building C object esp-idf/main_esp32s3/CMakeFiles/__idf_main_esp32s3.dir/home/tecdroid/git/lvgl_micropython/lib/lvgl/src/core/lv_obj_class.c.obj
[1294/1877] Building C object esp-idf/main_esp32s3/CMakeFiles/__idf_main_esp32s3.dir/__/modespnow.c.obj
[1295/1877] Building C object esp-idf/main_esp32s3/CMakeFiles/__idf_main_esp32s3.dir/home/tecdroid/git/lvgl_micropython/lib/lvgl/src/core/lv_group.c.obj
[1296/1877] Building C object esp-idf/main_esp32s3/CMakeFiles/__idf_main_esp32s3.dir/home/tecdroid/git/lvgl_micropython/lib/lvgl/src/core/lv_obj_event.c.obj
[1297/1877] Building C object esp-idf/main_esp32s3/CMakeFiles/__idf_main_esp32s3.dir/home/tecdroid/git/lvgl_micropython/lib/lvgl/src/core/lv_obj_draw.c.obj
[1298/1877] Building C object esp-idf/main_esp32s3/CMakeFiles/__idf_main_esp32s3.dir/home/tecdroid/git/lvgl_micropython/lib/lvgl/src/core/lv_obj.c.obj
[1299/1877] Building C object esp-idf/main_esp32s3/CMakeFiles/__idf_main_esp32s3.dir/home/tecdroid/git/lvgl_micropython/lib/micropython/lib/littlefs/lfs2.c.obj
[1300/1877] Building C object esp-idf/main_esp32s3/CMakeFiles/__idf_main_esp32s3.dir/__/__/lv_mp.c.obj
ninja: build stopped: subcommand failed.
ninja failed with exit code 1, output of the command is in the /home/tecdroid/git/lvgl_micropython/lib/micropython/ports/esp32/build-ESP32_GENERIC_S3-SPIRAM_OCT/log/idf_py_stderr_output_192825 and /home/tecdroid/git/lvgl_micropython/lib/micropython/ports/esp32/build-ESP32_GENERIC_S3-SPIRAM_OCT/log/idf_py_stdout_output_192825
-e See https://github.com/micropython/micropython/wiki/Build-Troubleshooting
make: *** [Makefile:66: all] Fehler 1
make: Verzeichnis „/home/tecdroid/git/lvgl_micropython/lib/micropython/ports/esp32“ wird verlassen
TecDroiD commented 4 months ago

just found that you pushed an rgb_bus update in between which didn't compile. a9f26c10885d4e1a2332cc1d31fc8f329615a1e9 compiles but doesn't have any effect on the behavior

TecDroiD commented 4 months ago

I modified gt911.py a little.

    def _get_coords(self):
        self._i2c.read_mem(_STATUS_REG, buf=self._mv[:1])
        touch_cnt = self._buf[0] & 0x0F
        status = self._buf[0] & 0x80

        if not status:
            return self.__last_state, self.__x, self.__y

        ...

this seems to work although I'm not shure if that fires multiple RELEASED events..

kdschlosser commented 4 months ago

when you press and hold the screen you should see multiple pressed events and when you release it you should see a stream of released events.

when I say events I am talking about the events comming from the indev driver not the events getting triggered in LVGL.

TecDroiD commented 4 months ago

Well, basically, GT911 driver does not fire events but replies the current status. LVGL is then able to intereprete status changes. (at least, to my current understanding.. still reading through the code..)

The buffer status flag in 0x814e is low as long as there is no valid data to read. This doesn't mean that there has happened nothing. It just tells you that the chip isn't currently ready to be read.

So I'd suggest __get_coords() to do the following:

by the way, what does bit 4 mean on status register? isn't that for "something has been touched" ? GT911 datasheet doesn't describe those things deeply.. or I'm -again- too stupid to find this..

kdschlosser commented 4 months ago

I am thinking the same thing as well I will update the driver to work in that manner.

kdschlosser commented 4 months ago

bits 0 through 3 is the touch count and 4, 5 and 6 deal with specialty modes like gestures and soft buttons.

kdschlosser commented 4 months ago

I just pushed some changes hopefully it will take care of the problems. Give it a shot and lemme know.

TecDroiD commented 4 months ago

this works great :) I'd like to do some experiment with some more widgets and will close the issue then

kdschlosser commented 4 months ago

FANTASTIC!!! That is what I like to hear.

Took a bit to nail down the exact issue. With both of us sharing thought on it we figured out what the cause was and we were able to fix it. 2 brains are better than one.

TecDroiD commented 4 months ago

Well, that's true :) feels good working that way ... and I learned much more about the internals of lvgl and micropython than any tutorial could give.

However. There is one thing i found with sliders. They only react after the screen has been removed. To my mind, that's a completely different problem to this issue so I will open a new one to help keeping things clean.

For me, this issue is done :)