Buttons do nothing
b0wter opened this issue · comments
I'm running Xubuntu 20.04 and I've used the precooked Ubuntu script to get things started. Everything works flawlessly and the application detects my Stream Deck, allows me to change pages, change its brightness and set button images.
However, no matter how I configure the buttons nothing actually happens when I press them. Commands are not run, key presses are not written to a terminal and neither is the contents of "write text".
Have I missed something obvious? Is there a way to enable console logging so that I can see what goes wrong?
I think so. I am running awesome wm and most of my stuff is rub/started by using scripts or direct command invocation.
However, I've written myself a small cli tool that does the job instead. I don't have a gui but I don't mind, since I prefer editing config files 😅
I'm having the same issue after getting things compiled and installed on Fedora 31. I'm able to communicate with the Streamdeck unit and assign keys/pictures/etc., however pressing the keys produces no noticeable result.
If there was perhaps some debugging options or command line options to help troubleshoot, that would be most helpful in trying to determine where the issue could be. For instance, it would be helpful just to see if the system even sees the keypress and if the program is even attempting to run an action. I know this project hasn't seen much activity, but please consider adding at least some detailed console output to help aid troubleshooting/bug requests.
So, I wanted to add something here.
I've noticed that I can sometimes get ONE keypress to work, but then it is like everything is ignored after that. I've checked system logs and SELinux and whatnot to make sure there wasn't anything odd with that.
For example, if I set a command to run vlc (/usr/bin/vlc) to a button, if I exit/close streamdeck-ui, then start it back up, if I press that key, it runs the command and I get VLC. But, after that, nothing. It is like after capturing a keypress, it does nothing more. Having said that, I have to hotkeys set in OBS that work MAYBE once after startup, but mostly don't work at all. It feels kinda random. I wonder if the application would be better designed to have a daemon pieces that listens for events that is separate from the UI portion so that actions/events could be debugged/tested separately.
All that aside, if there is a way I can get better debugging/feedback/verbose output, that would greatly help again. Thanks for the application. I feel like it feels a needed gap, but right now, I'm not getting much use out of it. I'm hoping that will change.
I hate to just keeping updating here (sorry for the SPAM, everyone), but I managed to come up with a solution that works for now.
I've created scripts on my system to execute (as opposed to doing keys) that just execute something like the following crudely:
#!/bin/sh
HOTKEY=$(basename $0 | awk -F'-' '{print $2}')
echo ${HOTKEY}
if [ "${HOTKEY}x" != "x" ]; then
/usr/bin/xdotool key --delay 60 ctrl+shift+${HOTKEY}
fi
The KEY here appears to be inserting the 'delay 60'. Any delay less than that and for whatever reason, it would not work. Once I added the 60, everything started working. I also figured that having it execute certain commands that don't FULLY exit cleanly hangs everything up and nothing works after that. I hope this helps someone!
I just want to confirm that I've got the same issue. The device is recognized and setting up the buttons works, but the buttons don't seem to be running the hotkey combos I've added.
That sounds like the same situation I ran into. I got around it by using commands that inject the key combinations (but only worked right with the delay). I hope this helps you as that was my point in commenting so much.
Yup! I haven't been able to try your scripting solution yet (less experienced with scripts), but I wanted to confirm another instance of this issue.
Basically, the command you would want is:
/usr/bin/xdotool key --delay 60
NOTE: I'm running Fedora, so the path to 'xdokey' might need to be adjusted. For '<KEYCOMBO'>, you can use practically anything (as long as it is set in OBS or whatever app and not taken by something else.
For instance, Ctrl+Shift+e would be:
ctrl+shift+e
So, the command line would be:
/usr/bin/xdotool key --delay 60 ctrl+shift+e
It's best to just test out the command line in a terminal to make sure it works before putting it into a script or trying it in the app.
I hope this helps take you in the right direction.
That helps a ton and works perfectly! Thanks so much!
Running Kubuntu 20.04, installed the software with pip3 after following the other instructions. I can only get a command exeuted once upon button press, and it appears to "lock up" after that.
I am now launching the code manually to try ot understand where the problem is.
HELP!!!!
Ok, here are my findings: for the 15-key StreamDeck, it will launch commands just fine unless there is something in the Press Keys field that is ill-formed? It simply gets caught in the for-loops somewhere and never returns.
So there needs to be a check for ill-formed strings in that field.
Another interereting bit -- if I unplug Stream Deck and plug it back in gain, it resets things. But the bug still persists.
Try simply unplugging and replugging USB... this is working as designed so far.
I installed this today and had this same unresponsive button problem after first test worked fine. I tried mexigabacho's workaround and unplugged re-plugged the USB while troubleshooting that and the Deck started to work without any delay code or mexigabacho commands.
Still not copy exactly to the Windows UI but I can see daylight and that is all I need to keep plugging or unplugging for that matter.
I would like to understand the why here, but all I have is how. It is working great for now.
System: Kernel: 5.4.0-48-generic x86_64 bits: 64 compiler: gcc v: 9.3.0 Desktop: Cinnamon 4.6.7
wm: muffin dm: LightDM Distro: Linux Mint 20 Ulyana base: Ubuntu 20.04 focal
Adding my experiences with the same issue:
1. Silent Fatal Errors
The whole tool appears to silently break if anything goes wrong, e.g. providing a 'command' which the application cannot execute. So to try to get anything working, you either have to un- then replug the device or kill streamdeck-ui after any change if a 'command', 'key-press' or 'write-text' action does not happen to make sure the application is actually in a working state for the next try.
2. Workaround for Key Inputs
@mexigabacho helped indeed by suggesting to use another tool as a workaround for the 'press-keys' and 'write-text' features, which so far silently fail in 100% of cases on my system if executed outside of streamdeck-ui itself. However, for anyone using Wayland for their desktop environment, xdotool will not work. I used ydotool instead, which seems to work with the basic tests I have done so far (pressing keys and moving the mouse cursor).
3. Inconsistent Behaviour
'write-text' and 'press-keys' only work in streamdeck-ui itself for me. Tested with 'press-keys' = 'ctrl+v' and 'write-text' = 'test string'. I am usually executing 'streamdeck' from Bash, but also tried to run it from a *.desktop file. The behaviour is identical. For some reason the 'command' feature is unaffected by this.
All the above information applies to running streamdeck-ui without setting QT_QPA_PLATFORM=wayland. This results in the following warning when launching streamdeck-ui:
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
This means streamdeck is probably running in the fallback X mode of Wayland.
I tried setting QT_QPA_PLATFORM=wayland using export QT_QPA_PLATFORM=wayland and unset XDG_SESSION_TYPE instead. This resulted in a different output when starting streamdeck-ui:
QSocketNotifier: Can only be used with threads started with QThread
However, like this, 'write-text' and 'press-keys' also didn't work inside of streamdeck anymore. Only the 'command' feature was still working in- and outside of streamdeck-ui.
I guess there might be an issue with input-handling in the used libraries, esp. when mixing X and Wayland.
I hate to just keeping updating here (sorry for the SPAM, everyone), but I managed to come up with a solution that works for now.
I've created scripts on my system to execute (as opposed to doing keys) that just execute something like the following crudely:
#!/bin/sh HOTKEY=$(basename $0 | awk -F'-' '{print $2}') echo ${HOTKEY} if [ "${HOTKEY}x" != "x" ]; then /usr/bin/xdotool key --delay 60 ctrl+shift+${HOTKEY} fiThe KEY here appears to be inserting the 'delay 60'. Any delay less than that and for whatever reason, it would not work. Once I added the 60, everything started working. I also figured that having it execute certain commands that don't FULLY exit cleanly hangs everything up and nothing works after that. I hope this helps someone!
Hey, it would be great to get an example of how to use this! :D Thanks
Closing this as a duplicate of #97 and will resolve that issue.