ryankurte / rust-streamdeck Goto Github PK

Hello, first off I wanted to thank you so much for the implementation- playing around with this has been my first real stepping stone into Rust, and you've made it pretty easy!

During my tinkering, I've been trying to use some local images I had laying around, and noticed that some of them would silently fail. Namely, the ones that weren't already square. The images crate provides a resize_exact method for DynamicImage that works for resizing these in a local vendored copy of the code- do you think it would be worth adding an option to use it? If so, I could probably contribute a PR. If not, I could also contribute a PR updating the documentation to specify that only 1:1 AR images should be used. Either way, thank you!

The version on crates.io is 0.4.8, but the source code is only 0.4.7

Hi, I get the error on the title using one of the followings:

streamdeck-cli --serial CL1234567890 get-buttons
streamdeck-cli --vid 0fd9 get-buttons

However, it did connect using the "--pid" option:
streamdeck-cli --pid 0063 get-buttons
Connected to device (vid: 0fd9 pid: 0063 serial: CL1234567890)

Cheers.

the original v2 and xl use a different protocol and i don't have any devices to test this.

Elgato have snuck out a new revision of the mini with product id 0x0090

The only difference is in the get_feature_request call for retrieving the serial number, which you do not appear to be doing, so I expect you can treat it exactly the same as the older revision of the mini.

I do not need this myself, simply sharing the knowledge from javascript land for someone who does

I thought having a built-in way to automatically detect attached stream decks could be useful for people trying to make custom streamdeck clients (including myself). This way they would not need to deal with Hidapi. I ran into this problem yesterday when I tried updating the library to 0.8.0 (and by extension updating Hidapi) and found that my HIDapi streamdeck detection code had broken. A built-in way to automatically detect attached stream decks would address headaches like this.

I would be willing to take a shot at this if needed. I was wondering why this had not been implemented before. They all use the same VID and the PIDs are documented. The code does not seem too complicated (keyword: seem). Is there a reason this feature has not been implemented?

Thx

To support multiple simultaneously connected streamdeck devices, I'd like to use udev rules which starts a per device application which uses this library.

Currently we instantiate the systemd service per pid, but I'd like to switch that over to per device instances. This way we can use systemd.resource-control to allow that process just a certain access profile.

To simplify this I'd love to see a StreamDeck connect_with_device method, which either takes a HidDevice or perferably just a path to the usb device, and then just checks which kind of streamdeck this is based on the pid it sees from the HidDevice.

We could do this dance in the application but I'd love to see this feature in the library.

I was having trouble getting this library to connect to a V2 original streamdeck (via StreamDuck project)

Other tools (streamdeck-ui and deckmaster) both work fine

Eventually I ran this (trimmed down from #6)

$ cat src/main.rs 
use hidapi::HidApi;

fn main() {
    let hid = HidApi::new().expect("could not connect to hidapi");
    for device in hid.device_list() {
        println!(
            "Found to connect to {:?}. vid: {:?}, pid: {:?}, serial: {:?}",
            device.product_string(),
            device.vendor_id(),
            device.product_id(),
            device.serial_number(),
        );
    }
}

This outputs Some("Stream Deck MK.2"). vid: 4057, pid: 128, ... which is 0x0080

#4 added the V2 it as 0x006d - but, weirdly, these values are consistent with the streamdeck Go library
https://github.com/muesli/streamdeck/blob/26adec9a4636e6062f886aefc84444af55a21bc9/streamdeck.go#L29

If I change it to 0x0080 everything seems to work perfectly, but.. I have no idea why the PID is 0x80

Not sure what I'm doing wrong. Hopefully if we can resolve this, it could be turned into a nice example.

I'm using HidApi to search for my Streamdeck, and then connecting to it from there.

My code looks like the following:

    let hid = HidApi::new().expect("could not connect to hidapi");
    let device = hid
        .device_list()
        .filter(|item| item.product_id() == XL)
        .next()
        .expect("Could not find Streamdeck");

    println!(
        "Attempting to connect to {:?}. vid: {:?}, pid: {:?}, serial: {:?}",
        device.product_string(),
        device.vendor_id(),
        device.product_id(),
        device.serial_number(),
    );

    let mut deck = StreamDeck::connect(device.vendor_id(), device.product_id(), None)
        .expect("could not connect to StreamDeck");

But whenever I run it I get back:

➜  streamdeck-agent git:(master) ✗ RUST_BACKTRACE=full cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.06s
     Running `target/debug/streamdeck-agent`
Attempting to connect to Some("Stream Deck XL"). vid: 4057, pid: 108, serial: Some("CLXXXXXXX")
thread 'main' panicked at 'could not connect to StreamDeck: Hid(InitializationError)', src/main.rs:26:20
stack backtrace:
   0:     0x55822ad72444 - backtrace::backtrace::libunwind::trace::h90669f559fb267f0
                               at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
   1:     0x55822ad72444 - backtrace::backtrace::trace_unsynchronized::hffde4e353d8f2f9a
                               at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
   2:     0x55822ad72444 - std::sys_common::backtrace::_print_fmt::heaf44068b7eaaa6a
                               at src/libstd/sys_common/backtrace.rs:77
   3:     0x55822ad72444 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h88671019cf081de2
                               at src/libstd/sys_common/backtrace.rs:59
   4:     0x55822ad8a74c - core::fmt::write::h4e6a29ee6319c9fd
                               at src/libcore/fmt/mod.rs:1052
   5:     0x55822ad70667 - std::io::Write::write_fmt::hf06b1c86d898d7d6
                               at src/libstd/io/mod.rs:1426
   6:     0x55822ad745d5 - std::sys_common::backtrace::_print::h404ff5f2b50cae09
                               at src/libstd/sys_common/backtrace.rs:62
   7:     0x55822ad745d5 - std::sys_common::backtrace::print::hcc4377f1f882322e
                               at src/libstd/sys_common/backtrace.rs:49
   8:     0x55822ad745d5 - std::panicking::default_hook::{{closure}}::hc172eff6f35b7f39
                               at src/libstd/panicking.rs:204
   9:     0x55822ad742c1 - std::panicking::default_hook::h7a68887d113f8029
                               at src/libstd/panicking.rs:224
  10:     0x55822ad74c3a - std::panicking::rust_panic_with_hook::hb7ad5693188bdb00
                               at src/libstd/panicking.rs:472
  11:     0x55822ad74820 - rust_begin_unwind
                               at src/libstd/panicking.rs:380
  12:     0x55822ad89c11 - core::panicking::panic_fmt::hb1f3e14b86a3520c
                               at src/libcore/panicking.rs:85
  13:     0x55822ad89a33 - core::option::expect_none_failed::he6711468044f7162
                               at src/libcore/option.rs:1199
  14:     0x55822acfc4a8 - core::result::Result<T,E>::expect::h42b271c894e69dc2
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libcore/result.rs:991
  15:     0x55822acfd2c1 - streamdeck_agent::main::hfc6bf6dfee7fcc46
                               at src/main.rs:26
  16:     0x55822acfdf50 - std::rt::lang_start::{{closure}}::hc3f82a756dc7500e
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/rt.rs:67
  17:     0x55822ad74703 - std::rt::lang_start_internal::{{closure}}::hb26e39676675046f
                               at src/libstd/rt.rs:52
  18:     0x55822ad74703 - std::panicking::try::do_call::he4701ab6e48d80c0
                               at src/libstd/panicking.rs:305
  19:     0x55822ad77067 - __rust_maybe_catch_panic
                               at src/libpanic_unwind/lib.rs:86
  20:     0x55822ad750e0 - std::panicking::try::hd3de25f3cb7024b8
                               at src/libstd/panicking.rs:281
  21:     0x55822ad750e0 - std::panic::catch_unwind::h86c02743a24e3d92
                               at src/libstd/panic.rs:394
  22:     0x55822ad750e0 - std::rt::lang_start_internal::h9cf8802361ad86c2
                               at src/libstd/rt.rs:51
  23:     0x55822acfdf29 - std::rt::lang_start::h69c7f105ba132008
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/rt.rs:67
  24:     0x55822acfd83a - main
  25:     0x7f4889441e0b - __libc_start_main
  26:     0x55822acfb40a - _start
  27:                0x0 - <unknown>

I've tried this with passing the Serial number through, and without. I'm at a bit of a loss 😞

As an aside - I am able to connect via streamdeck-ui, with their udev rules, as well as your udev rules, so I don't think that is the issue.

Add a radius (or better named) option to blank out the corners of images and backgrounds when drawing to match the shape of the streamdeck transparencies.

Running the following on my streamdeck mini (revised version) sets the top left button's colour

cargo run -- --pid 0090 set-colour 1 --b 100 --g 100 --r 100

However, running the equivalent command against the Mk2 sets the 2nd from left button:

cargo run -- --pid 0080 set-colour 1 --b 100 --g 100 --r 100