Jurgis

I agree with what you are saying, but I can't think of a use case where the current behavior is desired. Most of the applications use the `is_rx = false`...

Thanks for the workaround, I will keep that as an option for unit tests. However, I think that we still have some kind of miscommunication. What I'm proposing is: change...

I could do that. However, since python-can is supposed to be interface-agnostic, it would be wise to firstly define what `is_rx` and `is_confirm` mean at the API level for all...

Yeah, so if loopback/echo frames are enabled, is interface-specific. Some interfaces don't support it at all, some have it enabled by default (gs_usb), some have parameters to enable it (socketcan)....

Hey, sorry for the long silence. I tried making a PR for this, but there's just too much inconsistency between interfaces and fixing that would be a major breaking change....

I also stumbled on this problem. You can solve it by using unstable `package.forced-target` option (added in https://github.com/rust-lang/cargo/pull/9030) in `Cargo.toml` instead of setting target in `.cargo/config.toml`. It's nightly only, but...

For a while I've been using gstreamer plugin to interface libcamera with Rust, which is quite simple to setup with `gstreamer-rs`, but it only supports basic streaming without any configuration...

Yes, having a C API would make Rust bindings much easier as most of the FFI bridge can be auto-generated with [bindgen](https://github.com/rust-lang/rust-bindgen). This produces a list of unsafe functions that...

I tried wrapping C++ into Rust directly with [cxx](https://github.com/dtolnay/cxx) but it turned out to be way more boilerplate than writing a C wrapper. So I went ahead with C wrapper...

I'm trying out `drone` and hit the same issue. I think it is a really nice project, but being unix only is a really big limitation. Rust has a ton...