Add blockless read loop feature at eventIO

[feefsan]

Added a blockless read loop feature to the eventIO module. That would help devs that need to constantly use devices' events info, e.g., moving a mouse with an analog stick.

[sezanzeb]

Thanks

e.g., moving a mouse with an analog stick.

Because the analog stick won't report new events when it is not moving anymore?

However, if your goal is to translate e.g. ABS_X to REL_X by just using some factor, then the rate of reading will affect the mouse speed. Do you have any guarantee that your while True loop runs roughly at the same speed on different computers? It just looks like it will iterate as fast as it possibly can.

Better you run a loop in your own code that sleeps to approximate a specific rate, like this, and remember the event yourself: https://github.com/sezanzeb/input-remapper/blob/main/inputremapper/injection/mapping_handlers/abs_to_rel_handler.py#L88. input-remapper can move a mouse with an analog stick perfectly fine like this.

Apart from that, as "blockless" I would rather understand a function that stops running when there is nothing left to consume.

[feefsan]

Hey, I appreciate the feedback! I'm gonna refactor my code in order to make it more adequate thanks to your kind comment.

Because the analog stick won't report new events when it is not moving anymore?

Yes. Using the aforementioned example, the read_loop() function does not yield any InputEvent after syncing when the analog stick is fully tilted (with any of the abs axes values of 0 or 255), stopping mouse movement. I thought that it'd be helpful to have a evdev method that yielded InputEvents constantly, regardless of being idle or not.

However, if your goal is to translate e.g. ABS_X to REL_X by just using some factor, then the rate of reading will affect the mouse speed. Do you have any guarantee that your while True loop runs roughly at the same speed on different computers? It just looks like it will iterate as fast as it possibly can.

Understood. I'm sorry if I'm being too newbish, but I thought it would be better if the dev using the interface has the read rate control by time.sleeping it after the commands they would put in their application. Honest question, is it better then controlling this rate ourselves? It is possible to set a fixed value higher than 0 in the timeout parameter in the select.select function though, and that would control the iteration rate.

Apart from that, as "blockless" I would rather understand a function that stops running when there is nothing left to consume.

I named it blockless because the original one uses a select.select infinite loop without setting the fourth parameter (the timeout one) to zero. Accordingly to (select) documentation (https://docs.python.org/3/library/select.html), omitting this parameter makes the function block until at least one file descriptor is ready, which is not the case here in this method (hence blockless).

[sezanzeb]

Thanks for your idea and commitment to contribute, but I fear this can't work. I'll close it now