Open tfischer4765 opened 1 year ago
I renamed the ticket because in hindsight, the original title was a bit non-descriptive of what I was looking to achieve
Following.
I like the way you described this Need as it would address a number of possibilities. My particular need is to simply not use Polling for Touchevents. Based on your description, it appears the GUISlice may not have the ability (yet) to handle an IRQ action from any of the touch drivers. Since the XPT2046 seems to be more prevalent, would it difficult to coordinate development with the PS driver to achieve at least one good working scenario?
Unfortunately my skills are limited... still learning, but would offer to help in any way to achieve this.
I, too, want to intercept touch events from my XPT2046. I read through the code and it does not seem to support this feature. I guess I will clone the repo and create a PR as soon as I got a working implementation...
The vast majority of touch drivers will grab any interrupt pins a touch controller provides, rendering it inaccessible to user code.
Touch events often need a generalized processing additionally to gui-related processing, e.g. for haptic feedback or backlight control. Conversely, wether or not touch events should be processed by the GUI often depends on overall device state, e.g. one might not want a touch to register as a button press if the backlight was turned off at the time.
GUIslice currently doesn't provide a convenient, non-hacky possibility for user code to be notified of touch events. Any solutions I have been able to find either required modified drivers or extensive modifications in the library code. Various workarounds like setting a semaphore in a GUIslice callback proved to sluggish to give a good user experience.
GUIslice should provide a way to register a general touch listener that has the possibility to advise how the touch event is to be treated. Here's a quick and dirty example how I would envision it(beware of hacked together pseudocode):