
I’m using the lampy with both the built-in touchscreen and an external mouse. I often find myself in situations where interacting with the touchscreen changes the position of the mouse pointer, which then requires me to reposition it manually. This disrupts my workflow, especially since I primarily use the mouse for interacting with a second screen. I suggest implementing a feature where the touchscreen and mouse inputs are treated as separate inputs, so the touchscreen interaction does not affect the mouse pointer’s position. If it’s not possible to register these inputs as two separate devices, another solution could be to save the current mouse position before touchscreen interaction, temporarily move the pointer to the touchscreen interaction point, and then restore the mouse position afterward. This functionality could also be an optional setting.
The same functionallity can be seen on other consoles like grandMA.

Hi Emil,
I understand the wish for this feature, unfortunately we have no way to implement this, as the Linux subsystem we use only supports one mouse pointer, which will always follow the touch.
As the underlaying linux system handles all of this, we also have no way of saving and recalling positions.

https://wiki.archlinux.org/title/Multi-pointer_X#xinput_utility
Couldn’t you use something like that? (I don’t know what Linux you are using)
The more manual approach I could think about has to do with this:
https://www.baeldung.com/linux/mouse-events-input-event-interface
My idea is to check for touchscreen events and when one happened set the cursor back to the last mouse event. (Setting it back could be perhaps done with a virtual input device)

I’m very aware of the multi pointer x input settings; however these tutorials do not directly apply to us as we set the configuration from within c++ and using configuration files would make configurability a lot more difficult (eg adding a setting in the UI for the behavior), especially as these files are not saved persistently.
The manual approach interferes with the event handling system of the framework we use.
Please do not get me wrong - I understand the wish and motivation behind this feature request; implementation and testing however would most likely consume most, if not entire development time of a feature release and as such it would probably be the sole feature in a yearly update.
I’m leaving this thread open to votes; however I do not have an ETA.