Open lukasz-zaroda opened 3 years ago
Hi.. it can... if you use the config overlays... The idea is basically that you have a base configuration and can overlay it for a small time with additional/different configs. The overlay is basically sent to the input pipe via the command line and the same is done to reset it. (the input pipe runs as a server and the command line pushes the overlay with a short running tcpip connection into it or resets it) To trigger this you can either use an external call or simply trigger a shell execution upon button press from the input itself.
So for your example you probably have to set the knob as device and each state is a device event upon device event you basically (each knob must send a different input value) you execute a script which first rests the state of the overlays and then sends the overlay appropriate for the knob position.
To define such an eval output to trigger external commands you can do following output: eval1: name: eval1 type: eval
in the rules section
there you can do everything you want to:
see also
src/main/resources/config_examples/devices.yaml
I hope that explains it.
Werner
Am Mo., 30. Nov. 2020 um 11:39 Uhr schrieb Łukasz Zaroda < notifications@github.com>:
Some devices (like Virpil Throttles) have a special multi-state knob, that allows to change modes on the device, so the same button could serve multiple purposes based on the currently selected mode. This knob basically acts like 5 buttons, where always one of them is continuously pressed. Can this program handle mode switching? So could I map the same button, to different actions, based on the state of other buttons?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/werpu/input_pipe/issues/1, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEBQ45FJHHGZNF4IHG7LTLSSNY5ZANCNFSM4UHMGZNQ .
For an explanation on the overlays:
check out the overlays section in the readme documentation for a deeper explanation.
The permanently pressed might be a problem... because the overlay should only be changed upon state change and the permanently pressed might issue recurring events. I need to check that. I assume there is one event in the event chain which is triggered once (probably button pressed or so). I have to test that though. If not I will add something like a once flag which checks for recurringly issued events and ignores them.
Thanks for that. I didn't have time to play with this little program yet, but it looks like something that I need. I like how simple and flexible it is, I'm almost tempted to learn gtk to provide some GUI for it, lol . When I'll have some time I'll surely test it, and if it'll work as expected I may even create an AUR package for it.
Also, I realized that I'm not really sure if this knob really works as continuously pressed button, it looks like that in Virpil's configuration app though. I will test it in near future, and other buttons/features of this thing https://virpil-controls.eu/vpc-mongoost-50cm2-throttle.html if you are interested in feedback.
Well simply test it out and let me know if you need an extension to handle continous inputs. (the evdev output would be interesting for me)
as for a gtk gui... i never came around to do it, more like lack of time. I am not far off from ui programming but it simply was a lack of time that I have yet to provide one.
I programmed this thing to handle my rather complicated self built arcade stick which has 4 sticks 20 buttons and 2 spinners and one trackball, so some functionality still might is missing, one of them definitely is a ui for easier graphical configuration :-(
It works differently than I though. I used evtest and that's the output of going through all the modes and back:
Testing ... (interrupt to exit)
Event: time 1606857674.747733, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90038
Event: time 1606857674.747733, type 1 (EV_KEY), code 743 (BTN_TRIGGER_HAPPY40), value 0
Event: time 1606857674.747733, -------------- SYN_REPORT ------------
Event: time 1606857674.755304, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90039
Event: time 1606857674.755304, type 1 (EV_KEY), code 744 (?), value 1
Event: time 1606857674.755304, -------------- SYN_REPORT ------------
Event: time 1606857676.517275, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90039
Event: time 1606857676.517275, type 1 (EV_KEY), code 744 (?), value 0
Event: time 1606857676.517275, -------------- SYN_REPORT ------------
Event: time 1606857676.522275, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9003a
Event: time 1606857676.522275, type 1 (EV_KEY), code 745 (?), value 1
Event: time 1606857676.522275, -------------- SYN_REPORT ------------
Event: time 1606857678.029658, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9003a
Event: time 1606857678.029658, type 1 (EV_KEY), code 745 (?), value 0
Event: time 1606857678.029658, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9003b
Event: time 1606857678.029658, type 1 (EV_KEY), code 746 (?), value 1
Event: time 1606857678.029658, -------------- SYN_REPORT ------------
Event: time 1606857679.172259, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9003b
Event: time 1606857679.172259, type 1 (EV_KEY), code 746 (?), value 0
Event: time 1606857679.172259, -------------- SYN_REPORT ------------
Event: time 1606857679.177900, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9003c
Event: time 1606857679.177900, type 1 (EV_KEY), code 747 (?), value 1
Event: time 1606857679.177900, -------------- SYN_REPORT ------------
Event: time 1606857680.601226, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9003c
Event: time 1606857680.601226, type 1 (EV_KEY), code 747 (?), value 0
Event: time 1606857680.601226, -------------- SYN_REPORT ------------
Event: time 1606857680.609221, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9003b
Event: time 1606857680.609221, type 1 (EV_KEY), code 746 (?), value 1
Event: time 1606857680.609221, -------------- SYN_REPORT ------------
Event: time 1606857681.344197, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9003b
Event: time 1606857681.344197, type 1 (EV_KEY), code 746 (?), value 0
Event: time 1606857681.344197, -------------- SYN_REPORT ------------
Event: time 1606857681.351589, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9003a
Event: time 1606857681.351589, type 1 (EV_KEY), code 745 (?), value 1
Event: time 1606857681.351589, -------------- SYN_REPORT ------------
Event: time 1606857682.094199, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9003a
Event: time 1606857682.094199, type 1 (EV_KEY), code 745 (?), value 0
Event: time 1606857682.094199, -------------- SYN_REPORT ------------
Event: time 1606857682.100577, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90039
Event: time 1606857682.100577, type 1 (EV_KEY), code 744 (?), value 1
Event: time 1606857682.100577, -------------- SYN_REPORT ------------
Event: time 1606857682.619603, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90039
Event: time 1606857682.619603, type 1 (EV_KEY), code 744 (?), value 0
Event: time 1606857682.619603, -------------- SYN_REPORT ------------
Event: time 1606857682.626606, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90038
Event: time 1606857682.626606, type 1 (EV_KEY), code 743 (BTN_TRIGGER_HAPPY40), value 1
Event: time 1606857682.626606, -------------- SYN_REPORT ------------
So I guess I could just script overlays. Thanks!
Some devices (like Virpil Throttles) have a special multi-state knob, that allows to change modes on the device, so the same button could serve multiple purposes based on the currently selected mode. This knob basically acts like 5 buttons, where always one of them is continuously pressed. Can this program handle mode switching? So could I map the same button, to different actions, based on the state of other buttons?