Make get_event nonblocking

[whot]

Note, I'm going by the documentation here, not by the code.

I'm surprised that you opted to block on get_event - that seems not ideal for anything but the most basic tools that just need to pull events off and process them. libinput is primarily designed to be integrated into compositors with their own event loops, making this nonblocking would be an important feature here.

[OzymandiasTheGreat]

I combined file descriptor watching and event retrieval into a single method, therefor get_event blocks when select would block.
Honestly, I didn't see a need to expose file descriptor through python. In case blocking is undesired, there's a timeout parameter, same as select.
Of course there may be use cases I haven't considered, where this approach is sub-optimal. If you can illustrate such a use case for me, I'll make the changes.
I do doubt anybody wants to write a compositor in python, altho that's not a reason not to support this 😀

[whot]

yeah, I think the compositor in python is a bit of a niche use-case :) but you can imagine e.g. games that need direct access to the devices and have their own event loops.

afaict the only way to check if there are events is to call get_event - but that may block. And the timeout is in seconds, so the minimum block time is 1s, that's way too long.

[OzymandiasTheGreat]

Ok, now I get this.
I'll make get_event non-blocking, guess I'll have to expose file descriptor as well.
As for the timeout, there's an error in the documentation, it's supposed to be a float, as in fractional seconds.

[whot]

there is libinput_next_event_type() that returns LIBINPUT_EVENT_NONE if no event is waiting. That at least gets rid of the blocking issue, but without the fd you'd still have to resort to polling which isn't ideal.

On that note: if you don't have libinput_next_event_type() exposed in python, then you don't need the NONE event type, nothing else uses it.

[OzymandiasTheGreat]

Oh I completely forgot about that function. This would require far less modification to existing code, I think I'll just implement next_event_type.