valpackett / evscript Goto Github PK

I had an xcape setup in which I use caps_lock and semicolon as hyper keys and I can't refer to them as key functions. Can they be added to to the stdlib to allow people who use the spacecadet modifiers?

Hi, I would like to help with the feature to allow multiple keys remappings like <super>c to <ctrl>c or <alt>Left to <ctrl>Left, those are impossible to remap under Wayland with xkb. Do you think this is possible with evscript and what is the approach for this?

Hi! Not sure if I'm doing something wrong here, as I'm not too versed in ioctl in general.

I built evscript and installed it using the instructions in the README in this repo, but running it seems to give me a panic. I'm using the stock xcape-like config that was provided in the README as well.

% cat ~/better_xcape.dyon 
//! [events]
//! keys = ['ESC', 'LEFTSHIFT', '9', '0']
fn main() ~ evdevs, uinput {
    should_esc := false
    should_lshift := false
    should_rshift := false
    loop {
        evts := next_events(evdevs)
        for i len(evts) {
            evt := evts[i]
            xcape(mut should_esc, evt, KEY_CAPSLOCK(), [KEY_ESC()])
            xcape(mut should_lshift, evt, KEY_LEFTSHIFT(), [KEY_LEFTSHIFT(), KEY_9()])
            xcape(mut should_rshift, evt, KEY_RIGHTSHIFT(), [KEY_LEFTSHIFT(), KEY_0()])
        }
    }
}


% RUST_BACKTRACE=1 evscript -f ~/better_xcape.dyon -d /dev/input/event3
thread 'main' panicked at 'ioctl: Sys(EINVAL)', src/libcore/result.rs:916:5
stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: <unknown>
  14: <unknown>
  15: <unknown>
  16: __libc_start_main
  17: <unknown>

Would love to contribute but I'm not sure where to start trying to diagnose this. I see that EINVAL means that one of the parameters to the ioctl function was invalid but I'm not sure where to go from there.

Although I see you've done an impressive job containing this program, I think it's possible to do even better, at least, on Linux. Instead of setuid root, perhaps setgid input for handling /dev/input/*? As for /dev/uinput, I'm not sure - this article adds a new group uinput as well as udev rules, but I don't think you can setgid a program for multiple groups, correct? I don't think assigning /dev/uinput to group input would be the best choice - isn't it for reading from input devices, and not writing?

Any thoughts?

Hi,

Just ran the example, but I can't really get it to work, if I tap caps it does indeed send escape, but it also lights up and then works as a caps lock key. If I use it on left_ctrl it doesn't work. Should it work like xcape ? (havn't used it in a while, before i was using caps2esc on linux).

SpaceFN is a concept that uses the spacebar as an additional mod key, see https://geekhack.org/index.php?topic=51069.0

Currently there doesn't appear to be a clean implementation under Linux. As a result implementing this could be a real demonstration of how useful evscript can be. Do you think that is possible?

btw) this doesn't work well when using xcape as xcape lacks rollover detection (see topic I link to above).

Thanks for your solution, the xcape functionality works like a charm.

I am generally not too much into uinput in general, but would it be completely infeasible to implement an ability to remap keys?

Despite not being a rust nor dyon expert, I can kinda get a sense for conditionally emiting key presses and release. But is it infeasible to intercept uinput and modify it? (required for remapping)

I wanted to package evscript for NixOS, but it seems as cargo vendor failes with:

error: failed to sync

Caused by:
  found duplicate version of package `libc v0.2.34` vendored from two sources:

	source 1: https://github.com/rust-lang/libc#7c1297c9
	source 2: registry https://github.com/rust-lang/crates.io-index

Unfortunately, I'm no Rust user myself, and so I wondered whether you could maybe update the Cargo.Lock for me, please? NixOS requires a valid Cargo.Lock as otherwise it could not guarantee the required reproducibility of a build.

sfackler/rust-openssl#987

stCarolas ~/evscript
% cargo build --release

   Compiling openssl v0.9.24                                                                                                                      
   Compiling serde_urlencoded v0.4.3                                                                                                              
   Compiling hyper v0.10.13                                                                                                                       
   Compiling num v0.1.42                                                                                                                          
error: failed to run custom build command for `openssl v0.9.24`                                                                                   
process didn't exit successfully: `/home/stCarolas/evscript/target/release/build/openssl-06a9c873cac216a9/build-script-build` (exit code: 101)
--- stderr
thread 'main' panicked at 'Unable to detect OpenSSL version', /home/stCarolas/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/build.rs:16:14
note: Run with `RUST_BACKTRACE=1` for a backtrace.

warning: build failed, waiting for other jobs to finish...
error: build failed                                                                                                                               
                                                                                                                                                  
(101) stCarolas ~/evscript
% openssl version
OpenSSL 1.1.1 FIPS  11 Sep 2018

openssl-devel is also installed

Hi.
I just discovered this project and it sounds extremely promising.
However, I really can't make it run.
I copied the example in the README in a file named "test".
This is what it outputs
❯ evscript -f test -d /dev/input/event/1 thread 'main' panicked at 'evdev open(): Sys(ENOENT)', src/libcore/result.rs:1165:5 note: run with RUST_BACKTRACE=1environment variable to display a backtrace.

If I try with using RUST_BACKTRACE=full

❯ export RUST_BACKTRACE=full
❯ evscript -f test -d /dev/input/event/1 thread 'main' panicked at 'evdev open(): Sys(ENOENT)', src/libcore/result.rs:1165:5 stack backtrace: 0: 0x55e84acbccb4 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h4c5e39dd6bf38933 1: 0x55e84acd9b5c - core::fmt::write::h94b22f3cbda6422c 2: 0x55e84acbaa97 - std::io::Write::write_fmt::he7e02466cb3dc860 3: 0x55e84acbf1de - std::panicking::default_hook::{{closure}}::h077f2d0f0f4550db 4: 0x55e84acbeed1 - std::panicking::default_hook::hcc1ceebfaf9d0a58 5: 0x55e84acbf8db - std::panicking::rust_panic_with_hook::h328d8e7ed959397b 6: 0x55e84acbf47e - std::panicking::continue_panic_fmt::h745b12464b662c8f 7: 0x55e84acbf366 - rust_begin_unwind 8: 0x55e84acd5b8e - core::panicking::panic_fmt::hdb91b8826feb6fc9 9: 0x55e84acd5c87 - core::result::unwrap_failed::haba3c6d5a6de1991 10: 0x55e84aaf6678 - <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T,I>>::from_iter::h55f5e3626a98043f 11: 0x55e84aafb546 - evscript::main::h56bd2ac18487527c 12: 0x55e84ab04863 - std::rt::lang_start::{{closure}}::h869c81dbafb8a017 13: 0x55e84acbf303 - std::panicking::try::do_call::h81508b6a18a6e157 14: 0x55e84acc1dea - __rust_maybe_catch_panic 15: 0x55e84acbfdbd - std::rt::lang_start_internal::hfccf8c6e859ea61a 16: 0x55e84aaffdb2 - main 17: 0x7f7aac4e0153 - __libc_start_main 18: 0x55e84aad70ae - _start 19: 0x0 - <unknown>

I am on wayland, precisely sway. Don't really know what I should do. Can you help me? Thanks

they also moved away from github:

replacing:
rusty-sandbox = { git = "https://github.com/myfreeweb/rusty-sandbox", branch = "master" }

with:
rusty-sandbox = 0.1.0

worked

Doing everything using documentation I have this error:

Ξ ~/evscript git:(master) ▶ evscript -f ev.dyon -d /dev/input/event19

--- ERROR ---
In ev.dyon:

Type mismatch (#200):
Expected [], found {}
9,19: for i len(evts) {
9,19: ^