@@ -8,22 +8,36 @@ def main():
88 device = uinput .Device ()
99
1010 btns = uinput .KeyCapabilities (device )
11- btns .add (uinput .BTN_LEFT )
12- btns .add (uinput .BTN_RIGHT )
13- btns .add (uinput .BTN_MIDDLE )
11+ for btn in (uinput .BTN_LEFT , uinput .BTN_RIGHT , uinput .BTN_MIDDLE ):
12+ btns .add (btn )
1413
1514 rel_axes = uinput .RelativeAxisCapabilities (device )
16- rel_axes .add (uinput .REL_X )
17- rel_axes .add (uinput .REL_Y )
18- rel_axes .add (uinput .REL_WHEEL )
15+ for rel_axis in (uinput .REL_X , uinput .REL_Y , uinput .REL_WHEEL ):
16+ rel_axes .add (rel_axis )
1917
2018 device .activate ()
2119 time .sleep (1 )
20+ # This magic sleep needs to be taken under X because of the way
21+ # how X assigns handlers for new devices:
22+
23+ # 1. Kernel creates an evdev device.
24+
25+ # 2. A dbus signal "DeviceAdded" is sent.
26+
27+ # 3. X's handler assigner catches the dbus event and assigns a
28+ # handler for the new device.
29+
30+ # Now the "problem" is in the asynchronous nature of this whole
31+ # process. Kernel is totally happy once it has created the evdev
32+ # device, but X cannot assign a handler for the new device before
33+ # it receives the dbus signal. Without this delay, kernel would
34+ # generate events before a handler is assigned. Perhaps a better
35+ # way would be to listen to the dbus inside the library?
2236
2337 for i in range (20 ):
2438 rel_axes .move_by (uinput .REL_X , 5 , False )
2539 rel_axes .move_by (uinput .REL_Y , 5 )
26- time .sleep (0.01 )
40+ time .sleep (0.01 ) # Just to show the pointer motion.
2741
2842 btns .click (uinput .BTN_LEFT )
2943
0 commit comments