-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Add structs defined in linux/input.h #616
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
Conversation
a9ccb11
to
2f8a5b0
Compare
So mips64 and powerpc64 doesn't like And musl targets don't have |
Ah there's an issue about what to do for |
I would be surprised if I also tried running test suite locally with |
I personally don't know much about linux header files and whether or not they should be included. This can't merge until the CI is green though, and I don't have a particular preference on how that's done. |
25344a4
to
941d897
Compare
941d897
to
60d9322
Compare
CI is green now. |
@bors: r+ Looks great, thanks! |
📌 Commit 92fac1d has been approved by |
🔒 Merge conflict |
☔ The latest upstream changes (presumably #618) made this pull request unmergeable. Please resolve the merge conflicts. |
Note that those types were redeclared in my evdev crate. ioctl has been
deprecated for a long time, all the functionality was merged into nix
and the types belong in their own crate somewhere.
…On Thu, Jun 15, 2017, at 10:29, bors wrote:
🔒 Merge conflict
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#616 (comment)
--
cmr
http://octayn.net/
+16038524272
|
I still think that these structs (and constants) should be defined in libc. evdev crate looks nice and I will probably switch to using it, but it's on higher level than libc, and at least for me, libc looks like logical place when you are looking for these definitions. |
Was there consensus on what to do with this? |
Yes this is fine, sorry for the delay! @Arvamer feel free to ping me whenever a PR is updated, unfortunately GitHub doesn't send out notifications for that :( |
@bors: r+ |
📌 Commit 495d22a has been approved by |
Add structs defined in linux/input.h I was using definitions for these structs from `ioctl` but because @cmr decide to deprecate his crate (and yanked all versions :() I think that `libc` is the best place for them. In original C header, primitive types uses aliases like `__u16` or `__s32`; for now I replaced them with Rust's counterparts but I'm not sure if it is ok, especially because tests were failing for `u64` (`unsigned long long` vs `unsigned long` on x86_64). Also, should I do something special with union in `ff_effect`? I would like also to add all constants form `linux/input.h` and `linux/input-event-codes.h` if this PR will be accepted.
☀️ Test successful - status-appveyor, status-travis |
These aren't actually used anywhere yet, but this is likely a first step in any world! Also note that these types are unstable currently.
I was using definitions for these structs from
ioctl
but because @cmr decide to deprecate his crate (and yanked all versions :() I think thatlibc
is the best place for them.In original C header, primitive types uses aliases like
__u16
or__s32
; for now I replaced them with Rust's counterparts but I'm not sure if it is ok, especially because tests were failing foru64
(unsigned long long
vsunsigned long
on x86_64). Also, should I do something special with union inff_effect
?I would like also to add all constants form
linux/input.h
andlinux/input-event-codes.h
if this PR will be accepted.