-
-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
iio-sensor-proxy: init at 2.2 and nixos module #17303
Conversation
@peterhoeg, thanks for your PR! By analyzing the annotation information on this pull request, we identified @edolstra, @bjornfor and @offlinehacker to be potential reviewers |
|
||
options = { | ||
hardware.sensor.iio = { | ||
enable = mkEnableOption "Enable this option to support IIO sensors."; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mkEnableOption
expects the parameter to be the name of the module; it would generate a description of the form "Whether to enable Enable this option ...".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As we are passing a string to mkEnableOption
that string is used as the description, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, mkEnableOption name
generates a description of the form Whether to enable ${name}
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See https://github.com/NixOS/nixpkgs/blob/master/lib/options.nix#L27 for details.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are indeed right, thanks. Any comments on using the hardware.sensor namespace?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using hardware.sensor
makes sense to me. I have no better alternative, anyway.
b446872
to
50af719
Compare
so this module does not work yet or did you manage to send events? |
@Mic92 it still doesn't work - I haven't worked on it at all as I was just using it for screen rotating in the past on Arch Linux and have 2 shell aliases I use instead. |
2411384
to
2235969
Compare
@Mic92, it does work now. It probably always worked, but there is a kernel bug (supposedly fixed in 4.10) that makes the events only happen after suspend/resume. |
@globin, how do you feel about merging this for 17.03 when we know there are issues with certain hardware on kernel 4.9.x ? I would argue that it still makes sense to merge for those with good hardware and we could highlight it in the manual. |
This PR adds support for ```iio-sensor-proxy``` used by GNOME v3 and others for reading data from the accelerometer, gps, compass and similar sensors built into some relatively recent laptops. Additionally, there is a NixOS module exposed via hardware.sensor.iio for enabling services, udev rules and dbus services.
@peterhoeg you can add an assertion to exclude v4.9 (check if |
Actually, it does work for some hardware on 4.9, so I think we shouldn't
exclude that version, just because it requires suspend/resume.
It works on 4.10 for me here.
|
Motivation for this change
This PR adds support for
iio-sensor-proxy
used by GNOME v3 and others for reading data from the accelerometer, gps, compass and similar sensors built into some relatively recent laptops.This allows the computer to automatically rotate the screen, turn the brightness up/down in response to ambient light and so on.
Additionally, there is a NixOS module exposed via
hardware.sensor.iio
for enabling services, udev rules and dbus services.Now, while everything installs, can be configured and runs,
no events are actually being sent, so that needs to be sorted before this is merged, but I really wanted to see if this is the correct way of doing something like this. Specifically with regards to creating a new namespace under, but due to kernel issues in 4.9.x some hardware requires a suspend/resume cycle before events are being sent.hardware.sensor
On kernel 4.10 everything is fine!
Things done
(nix.useChroot on NixOS,
or option
build-use-chroot
innix.conf
on non-NixOS)
./result/bin/
)