Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is there a way to create events out of string names? #1

Open
t184256 opened this issue Jul 21, 2018 · 7 comments
Open

Is there a way to create events out of string names? #1

t184256 opened this issue Jul 21, 2018 · 7 comments

Comments

@t184256
Copy link

t184256 commented Jul 21, 2018

I like the coverage of both evdev and uinput functionality in one package, but I miss a way to create events from names akin to evdev_rs::enums::EventType::from_str. Is there one?

@arcnmx
Copy link
Owner

arcnmx commented Jul 21, 2018

The closest functionality currently is enabling the with-serde feature, you'll get serialize/deserialize for the enum types from/into strings by their name.

@t184256
Copy link
Author

t184256 commented Jul 22, 2018

Thanks for the hint! I'm new to Rust and didn't know about serde yet. Sorry if that is common knowledge.

That actually works better than I could've expected, aside from the minor gripe of having to follow your enum names instead of conventional linux constant names. Feel free to close that if you don't plan to address that though.

And thanks for a nice library! If you'd like to see how a newbie handles your crate with no examples and no prior Rust knowledge, you may check out https://github.com/t184256/irwir

@arcnmx
Copy link
Owner

arcnmx commented Jul 22, 2018

I'll leave it open, as it's reasonable to offer this in some way, considering that libevdev offers similar functionality via libevdev_event_code_get_name and such. I'm not sure when/if I'll get around to it, and in general the symbol names may not be the best user-facing names to use (not that my rustified versions are any better), but it certainly seems like it could be available if you want it!

And good job so far! My apologies for the lack of examples and the library being rough right now. The intention is that the *Handle interface is a {type-,}safe wrapper around evdev/uinput, but still a rather low level interface that just mirrors the ioctls. A higher level interface is planned that would expose something less awkward like an iterator or stream of Events, but that's not available yet - which is why you're seeing a bit of friction around using libc's input_event and such. Looks like you found your way around it well enough though, feel free to let me know if you have any other questions or issues.

The only real example or use of the library that I know of right now is this, which is far from a good example, and most of it is plumbing to hook it up to tokio so it can be used async.

@t184256
Copy link
Author

t184256 commented Jul 22, 2018

in general the symbol names may not be the best user-facing names to use (not that my rustified versions are any better)

Neither of them is particularly good-looking in a config, but the first are as canonical as it gets, and that's something.

Also, your shortening is nice, but a bit inconsistent: EventKind::Key but Key::KeyF1.

My apologies for the lack of examples and the library being rough right now.

Hey, I didn't say it was bad and it wasn't! I'm pretty sure a seasoned Rustacean would find it easy to use. And whatever minor friction I had from the low-level stuff sure beats trying to marry evdev and uinput on my own.

A VFIO KVM switch using DDC/CI

Man, you're doing the God's job! Shame I don't have VFIO setup anymore to test it, that sounds super sweet.

feel free to let me know if you have any other questions or issues.

Great, I'd consider it to be an invitation to open other non-issues like this as I progress further.

@arcnmx
Copy link
Owner

arcnmx commented Jul 22, 2018

Neither of them is particularly good-looking in a config, but the first are as canonical as it gets, and that's something.

Agreed.

Also, your shortening is nice, but a bit inconsistent: EventKind::Key but Key::KeyF1.

Yeah, I've been meaning to fix that... I think I just didn't want to deal with changing the keys that started with digits at the time ._.

@arcnmx
Copy link
Owner

arcnmx commented Nov 24, 2018

I've taken care of the redundant KeyF1 -> F1 names, however a way to translate to/from the symbol names is still not yet provided. I'm not sure if I'm up to implementing it, but I'd welcome any PR that adjusts src/keys.rs into a macro that generates the appropriate conversions.

@lilydjwg
Copy link

The closest functionality currently is enabling the with-serde feature, you'll get serialize/deserialize for the enum types from/into strings by their name.

It doesn't work for HashMap keys :-(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants