How to handle a USB interface with a transfer type of "Interrupt"?

[SteveSpencer]

My USB display/touchscreen has the following endpoints

     Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes

Now, I understand how to use the Transfer method to send data out to the first endpoint, which is how the data is sent to the display.

If I use SubmitRequest on the second endpoint, it will stall until data is available. Obviously, I can use SubmitAsyncRequest and a completion routine so that it does not block. Effectively, I am polling the device.

Here is where my ignorance becomes apparent. Is it possible to set an interrupt handler so that when data is available via the endpoint, a function can then submit a request to get it (and in my case, pass the data through to the CTouchScreenDevice) ?

If not, then I am left with polling the device (via SubmitAsyncRequest and a completion routine). What would be a suitable mechanism for this ?
At the moment, I do a SubmitAsyncRequest, and in the completion routine, do another one after processing the newly arrived data, so effectively the code is continually requesting the touch status. I don't think this is necessarily a good thing to do, but I am not sure how else to do it.

[rsta2]

Have a look on how the HID driver is doing this. In fact the device is polled by the USB driver in the lower layer on RPi 1-3, there is no other way. The completion routine is only called, when data arrives.

You can call the touchscreen ReportHandler from the USB completion routine. The USB HID touchscreen driver is doing this too, for example here.

There is no other way to do this.

[SteveSpencer]

Yes, that is the driver - and my device is the same age but still working.
The driver code doesn't match the protocol information I have, so I have done lots of experimenting to get it to work properly.

Apart from the one issue (which became apparent when I was using LVGL), things are working, and I managed to get the RLE compression for the display data working, so the amount of data being sent is significantly reduced in most cases. Once I figure out the problem I will submit a PR to provide driver code and my LVGL code.

I notice that the old version of LVGL is in addons. I will look at how much work getting v9 to compile and run would be, but not right now!

[rsta2]

Please let me do the LVGL update by myself. It must be in sync with my MiniSynth Pi project. I have this already on my list.

[rsta2]

The LVGL support has been updated to v9.2 on the develop branch.

[SteveSpencer]

Wow. That was fast. I have an app that uses LVGL 9, which was running on an ESP32. Using Circle I can now move it to a Pi Zero W. My reason for wanting to change it was so I could edit configuration data on a uSD card prior to deployment.
Although the h/w costs more, it gives me much more flexibility, which for non-commercial targets is a better fit.

Thanks.

[rsta2]

Actually I had expected more changes from LVGL 8.3.11 to 9.2.0, but luckily it wasn't that difficult. They renamed a lot of functions (e.g. lv_image_ instead of lv_img_), but I think the old names still work for compatibility. Yes, the RPi Zero W is a great device for bare metal apps. You are welcome.