PyUserInput
PyUserInput copied to clipboard
PyKeyboard issue
Hi, and thanks for this incredible software. I'm trying to send "CTRL_l + 1" (a shortcut for Push-to-Talk) to the Mumble client (http://mumble.sourceforge.net/) but nothing happens, if I send ALT + o it opens the Configure menu so it is targeting the right window. Am I missing something? I'm on a Raspberry Pi if that is of any difference.
import subprocess, os, time, pykeyboard
os.environ['DISPLAY'] = ':0.0'
subprocess.Popen('XAUTHORITY=/home/pi/.Xauthority DISPLAY=:0 /usr/bin/xdotool search --onlyvisible --name Mumble windowactivate', shell=True)
k = pykeyboard.PyKeyboard()
k.press_key(k.control_l_key)
k.press_key('1')
time.sleep(2)
k.release_key('1')
k.release_key(k.control_l_key)
You could try xbindkeys --multikey
or our own event class to test if
it is sending the expected keycodes, and compare to manually pressing
the desired combination.
On Sun, Mar 2, 2014 at 11:58 AM, Niclas Hallgren [email protected] wrote:
Hi, and thanks for this incredible software. I'm trying to send "CTRL_l + 1" (a shortcut for Push-to-Talk) to the Mumble client (http://mumble.sourceforge.net/) but nothing happens, if I send ALT + o it opens the Configure menu so it is targeting the right window. Am I missing something? I'm on a Raspberry Pi if that is of any difference.
import subprocess, os, time, pykeyboard
os.environ['DISPLAY'] = ':0.0' subprocess.Popen('XAUTHORITY=/home/pi/.Xauthority DISPLAY=:0 /usr/bin/xdotool search --onlyvisible --name Mumble windowactivate', shell=True)
k = pykeyboard.PyKeyboard() k.press_key(k.control_l_key) k.press_key('1') time.sleep(2) k.release_key('1') k.release_key(k.control_l_key) — Reply to this email directly or view it on GitHub.
Thanks for the fast answer! I tried with xbindkeys --multikey
on the RPi (using keyboard) but it only seems to log the first key pressed. I changed the hotkey to Alt + t but the output from xbindkeys is:
"(Scheme function)"
m:0x8 + c:64
Alt + Alt_L
I get the same output from the python script so I think that the problem is outside your software but do you have any ideas on what else I could try?
@nickehallgren I haven't worked with an RPi, does it have xev
available?
@SavinaRoja Yes and the output for ALT + t is below, but if I understand it correctly it just shows the Alt_L and not the t
KeyPress event, serial 43, synthetic NO, window 0x1600001,
root 0x43, subw 0x0, time 632669, (-366,92), root:(912,492),
state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
FocusOut event, serial 46, synthetic NO, window 0x1600001,
mode NotifyGrab, detail NotifyAncestor
FocusIn event, serial 46, synthetic NO, window 0x1600001,
mode NotifyUngrab, detail NotifyAncestor
KeymapNotify event, serial 46, synthetic NO, window 0x0,
keys: 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
KeyRelease event, serial 46, synthetic NO, window 0x1600001,
root 0x43, subw 0x0, time 634381, (-366,92), root:(912,492),
state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
Ok, an update. I changed the hotkey back to CTRL + 1 and this is the output from xev with the local keyboard:
KeyPress event, serial 43, synthetic NO, window 0x1600001,
root 0x43, subw 0x0, time 2316237, (60,244), root:(1340,644),
state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 46, synthetic NO, window 0x1600001,
root 0x43, subw 0x0, time 2316557, (60,244), root:(1340,644),
state 0x4, keycode 10 (keysym 0x31, 1), same_screen YES,
XLookupString gives 1 bytes: (31) "1"
XmbLookupString gives 1 bytes: (31) "1"
XFilterEvent returns: False
KeyRelease event, serial 46, synthetic NO, window 0x1600001,
root 0x43, subw 0x0, time 2316677, (60,244), root:(1340,644),
state 0x4, keycode 10 (keysym 0x31, 1), same_screen YES,
XLookupString gives 1 bytes: (31) "1"
XFilterEvent returns: False
KeyRelease event, serial 46, synthetic NO, window 0x1600001,
root 0x43, subw 0x0, time 2316965, (60,244), root:(1340,644),
state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
and this from python with the code from the first post (shorter sleep):
KeyPress event, serial 43, synthetic NO, window 0x1600001,
root 0x43, subw 0x0, time 2370975, (60,244), root:(1340,644),
state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 46, synthetic NO, window 0x1600001,
root 0x43, subw 0x0, time 2371015, (60,244), root:(1340,644),
state 0x4, keycode 10 (keysym 0x31, 1), same_screen YES,
XLookupString gives 1 bytes: (31) "1"
XmbLookupString gives 1 bytes: (31) "1"
XFilterEvent returns: False
KeyRelease event, serial 46, synthetic NO, window 0x1600001,
root 0x43, subw 0x0, time 2371133, (60,244), root:(1340,644),
state 0x4, keycode 10 (keysym 0x31, 1), same_screen YES,
XLookupString gives 1 bytes: (31) "1"
XFilterEvent returns: False
KeyRelease event, serial 46, synthetic NO, window 0x1600001,
root 0x43, subw 0x0, time 2371139, (60,244), root:(1340,644),
state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
Both match perfectly, so why does it not trigger the hotkey shortcut?
On Ubuntu 13.10 everything works perfectly so it seems to be an issue on the RPi (running Raspbian)
Just a thought, sometimes applications don't respond to keys if the interval between press and release is really short. If you put a 0.1 second delay between press and release of "1", does it help at all? I will spend some time reading about RPi and try to be of more use.
Edit: Just compared the interval between your local keyboard events and the PyKeyboard generated events, they are not significantly different, so my idea just now is probably irrelevant.
@SavinaRoja In my tests I have a 2 second sleep between press and release. Today I compiled the newest Mumble client (1.2.5) to see if that made any difference (the Ubuntu client was 1.2.5) but there was no difference.
When I read the README before compiling I found this:
Global Keyboard Events
======================
On Linux, Mumble supports reading the kernel input devices. To use this,
make sure mumble can open /dev/input/event* for reading. To test it out,
that should only require:
sudo chmod a+r /dev/input/event*
However, be aware that this will most likely only last until the next reboot
(at which point devfs is recreated) and you also allow any program run by any
user to monitor the physical keyboard.
Without this, Mumble will continously poll the mouse and keyboard state for
changes, which will use a tiny bit of processing power.
That gave me the idea to remove the keyboard from the RPi and after that my script started to work. The icon that shows that PTT is pressed (goes red) should be stable (as is when using the keyboard) but now it blinks like the "1" key is released in between. Might be because of the continuously keyboard polling from Mumble, but it should not be that cpu intensive. I have not yet checked if it really interrupts the microphone because I didn't have one but I will try that tomorrow.
Ok, now everything works. After a clean install, RPi firmware updated and broken USB sound card replaced I now have a working system. Your excellent software is working as I was expecting it to do so I would like to thank you again for your effort and support. Thank you!