Exception raised when button event contains unknown button

[minus7]

Pressing one of the buttons on the mouse triggers an event with a button id that is not present in the Button enum, raising a ValueError. I'm not sure how this could be handled properly with Python's Enum; maybe a UNKNOWN enum constant with its value set to the actual id, if that's possible, but that doesn't really sound like a clean solution.

Traceback (most recent call last):
  File "test.py", line 13, in <module>
    button = pointer_event.get_button()
  File "/home/minus/dev/mousebuttond/venv3/lib/python3.6/site-packages/libinput/event.py", line 512, in get_button
    return self._libinput.libinput_event_pointer_get_button(self._handle)
  File "/usr/lib/python3.6/enum.py", line 291, in __call__
    return cls.__new__(cls, value)
  File "/usr/lib/python3.6/enum.py", line 533, in __new__
    return cls._missing_(value)
  File "/usr/lib/python3.6/enum.py", line 546, in _missing_
    raise ValueError("%r is not a valid %s" % (value, cls.__name__))
ValueError: 280 is not a valid Button

[OzymandiasTheGreat]

That button is not defined in input.h, which is something I have not considered when I got the bright idea to add more meaning to return types than plain int would provide.
After thinking about this a bit more, I'm doing away with Key/Button enumerations. In the upcoming version all the key/button methods will just return integers. Mapping them to semantic names is better left to projects like python-evdev.

[minus7]

Imho, the enumerations are good to have (at very least since libinput has them as well). How about changing the ctypes retval to int and keeping enums (maybe as normal classes) so you can still use them like btn == Button.RIGHT.value (or respectively without .value)

[OzymandiasTheGreat]

libinput doesn't actually, it uses constants defined in input.h which is why decided to do away with these enumerations. I'd say it falls outside the scope of this project. Besides, while somewhat convenient, they create issues I don't have time to solve.

[whot]

the solution here is to use python-libevdev and run evbit() on it to map it to the libevdev.EV_KEY.BTN_LEFT constants where required. In the client, not in libinput.

libevdev also maps the unnamed ones, so you'll get KEY_1234 as event type where no symbolic name is defined.