- edited description
Fan support
Issue #7
new
Throug the EC the fan speeds can be read out. There is a project on github which does so and it seems easy to just port this over to the kernel module:
Those values could be exported through hwmon and used in userspace :)
Comments (11)
-
reporter
-
reporter
work in progress: https://bitbucket.org/karolherbst/clevo-xsm-wmi/branch/fans
-
Very interesting. I had some ideas about extending the util with a daemon to adjust the keyboard colours based on cpu temp. Your work would make that much easier. Let me know when you feel it's ready to be pulled :)
-
reporter
well we could also expose the keyboard backlight in /sys/class/backlight/, but I have no clue what would be the best apporach here, because there are actually three regions
-
Hmm, it's possible to also expose the keyboard there as a whole per the ABI spec (https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight). But that only defines the brightness and it might confuse a lot of people since that directory is associated quite a bit with the brightness of the screen.
Keeping it separate as it is now is probably the best choice for now as this module is still open to a lot of change and keeping it separate sort of tells people that?
-
reporter
xpad does funny things, too, and they control all 4 LEDs through the brightness (maybe for this it could be split by byte? or something)
Anyway, I repushed my branch and added support for the GPU temperature, but the value is 6°C too high (verified with nvidia-settings)
-
I looked at xpad's code (which I assuming is https://github.com/torvalds/linux/blob/master/drivers/input/joystick/xpad.c#L1078). I'm not familiar with the xbox controllers, but from what I can tell it controls the LEDs on/off/blink state by a single byte (assuming, haven't checked that thoroughly) which it passes almost directly to the hardware.
Squashing 10 brightness levels, 3 colour regions of 8 colours each (or more should full colour support ever come to be) and the 8 modes into a byte doesn't seem easy to use to me (user wise). You'd have to have all the colour combinations in it I think? Think that gives uhh... 520 choices? Splitting it over multiple bytes would make it easier, but I don't think that's allowed by the ABI.
Anyway my thinking could be horribly wrong here. What do you think?
Regarding your branch, I tested it on my laptop. Once the GPU settles down a bit it's off by 8 degrees on both max and low performance modes (https://lynthium.com/2016-05-12_20-07-22.png). And it's at a solid 29c if the GPU is powered down (with the RPM becoming 0).
-
reporter
it was 26°C for me when the GPU was off.
I think there is an offset somewhere in the EC regs? Didn't check that, but thanks for checking. At least we know that the difference is different on different systems :D
-
reporter
there is also a delay in the EC for reading the temperature out, so the differences varies a little
-
reporter
well, let's see
#! 3*3 bits for the colors 4 bits for the brightness 4 bits for the mode so we need 17 bits in total. colors: 0x0: black 0x1: blue 0x2: red 0x3: magenta 0x4: green 0x5: cyan 0x6: yellow 0x7: white 0b 110 010 011 (0x193): yellow/red/magenta masks: 0x1c0: left 0x38: middle 0x7: right 0b 1000 (0x8): 8 brightness 8 mask: 0x1e00 0b 1000 (0x8): some mode mask: 0x1e000 mask of entire value range: 0x1ffff -
reporter
but yeah, that is ugly to deal with.
Another idea: we just expose the brightness over the keyboard_brightness subdev and use driver specific sysfs entries for the colors stuff. This way userspace can control the keyboard brightness and the brightness key events could just be forwarded to userspace.
- Log in to comment
