Polaris Gen1: Control power mode LED and what it does

[caravelaPortuguesa]

Hello,
I'm looking for a way to, if possible, control the power mode lights.
If not possible, just being able to read the value is enough.
Then I want to use that value in user mode to change the tcc profile without the need for a password. <- This one I know how.

I already know tuxedo-keyboard locks the power mode value to the bottom LED ON.
It also appears like tuxedo-keyboard is opened through a keyboard shortcut that is activated here: https://github.com/tuxedocomputers/tuxedo-keyboard/blob/master/src/uniwill_keyboard.h#L253
(I figured that out because I saw this a few days ago made by the user brunoais: tuxedocomputers/tuxedo-control-center#101)

I already asked support e-mail but I got this as answers:

Our main developer asked if you could post your question on Github, since that makes it easier for him too.
The short version is:

• The LED cannot be controlled! Why the EC Controller or the Control Center under Windows behave differently, my colleague will be able to answer that better.
• It should be possible to remap the button, so that instead of the Tuxedo Control Center, something else can be opened.

Do you confirm the LED cannot be controlled and that it's status cannot be read?
Can the button be remapped to open a different program instead of just pressing some keys?

[tuxedoxt]

Yes, the support answer is correct. These LEDs can unfortunately, as far as we know, not be controlled separately. This was at one point actually also confirmed by the ODM. Still, I tried to look for it anyways ^^ however, so far without success. If you find a way I'd be very interested.

The LEDs seem to change depending on which ODM power profile is chosen. This can be read and possibly mapped (see ec ram address 0x0751 if you tumble around in the driver). For the moment we only use one profile, more or less, to allow fan control.

The key event from the button is, as you discovered, caught in the driver and thrown as a key code combo. This is currently not configurable. You could possibly catch this combo and throw a new one of your choice or modify the driver.

[caravelaPortuguesa]

I'll see if I can figure out. From what it seems, support relayed to me it cannot be done. You say it might be doable. You mention ODM (original device manufacturer(?)) says it cannot be done. Did I get that right?
However, that can't be right. How does the software in windows know which power profile to be in? Even if just to make that icon appear in the screen? I wonder if the ODM is hiding something.
What does tuxedo-keyboard do to turn the LED changing off and fixed at 1 LED on, btw?

[tuxedoxt]

Some things can be done, some not, let's keep things separate.

• The LEDs themselves cannot be directly controlled without affecting other things.
• The ODM power profiles can be set and read. This indirectly changes the LEDs (as far as we know hardcoded through EC)

What does tuxedo-keyboard do to turn the LED changing off and fixed at 1 LED on, btw?

It sets (at least) one bit connected to the ODM power profiles to allow us a way to manually control the fans. This indirectly affects the LEDs.

We'd rather connect the LEDs to our TCC profiles for example, but again, as far as we know and confirmed by the ODM this is not possible.

[caravelaPortuguesa]

1. Do the bits have to be set in such way that 1 LED is ON so the fans can be controlled and override ODM's power profile?
2. So I have where to start with, what are the bits that control the LED (which also activate ODM power profiles)? (not knowing is OK but I'm not sure if that's the case)

[brunoais]

Hello! I noticed this discussion and I have something to add.
I've been trying to get tuxedo_keyboard to work with different power modes and I have been trying to reverse-engineer how the LED for the power mode work and I think I got it.
Power mode is in the address 0x0751 like @tuxedoxt mentions. It's actually 2 bits at 0x80 and 0x10.
0x80 is LED off
0x10 is both LED on
^ Set both at 0 and you get 1 LED on. That's the reason why the button is at 1 LED on when tuxedo_keyboard starts and in some ioctl calls.
The other bits control other features I didn't focus on. One of them being the manual mode. I don't know which one is the manual mode yet.

Here's the catch. Unlike what @tuxedoxt mentioned. It appears like the ODM lied. If the mode is changed by pressing the button, the fan profile changes to a predefined one until an order is done otherwise. Because tccd keeps giving orders otherwise, it doesn't matter at all. If the fans or the CPU profile changes, it's completely unnoticeable. I made a while True: pass in python in multiprocess to test under load. The power mode LED changes seem to do nothing.
I compared with tccd on and tccd off. Also with this driver installed and this driver not installed.

You can find my WIP here: https://github.com/brunoais/tuxedo-keyboard/tree/power_mode_works
So far, there's a sysfs file at: /sys/devices/platform/tuxedo_keyboard/uw_kbd_bl_color/power_mode.
You can read the current power mode and write the power mode you want, using it. You can make it blink using that:

while true; do echo "2" > power_mode; sleep 0.5; echo "0" > power_mode; sleep 0.5; done;

Or an interesting ramp up:
while true; do echo "0" > power_mode; sleep 0.2; echo "1" > power_mode; sleep 0.5; echo "2" > power_mode; sleep 1; echo "1" > power_mode; sleep 1; done;
(I show you only to exemplify the full control)

I just finished the ioctl changes.

The only thing I still want to make is a file stream to write power mode changes, so programs can readblock on them and receive
I was thinking to make it on /sys/devices/platform/tuxedo_keyboard/uw_kbd_bl_color/power_mode_notify. Afterwards, create the PR.

Ideally, this would allow hooking 3-5 modes to tuxedo-control-center profiles. 3-5 because if you use blinking, you can squeeze extra 2. However, officially, I think 3 should be the choice and leave the extra 2 to more expert users.
If I were to decide on that, it would be a driver parameter. However, this would require proper locks and threads. It would definitely be something for later.

The thing that bothers me now the most is the way tccd changes profiles. It should be a pipe "file" instead of the need to restart it every time. That restart process causes the fans to ramp up unnecessarily.

[caravelaPortuguesa]

Tuxedo, is brunoais claim true? Were you able to confirm it?

[caravelaPortuguesa]

Tuxedo, any updates?

[brunoais]

Try mentioning tuxedo like so: @tuxedoxt

[tuxedoxt]

Hello,

yeah @brunoais claims alot 😁

As stated, and I repeat, writing different modes is very much possible and by doing so the LEDs seem to change accordingly.

• The LEDs themselves cannot be directly controlled without affecting other things.
• The ODM power profiles can be set and read. This indirectly changes the LEDs (as far as we know hardcoded through EC)

As far as I know this aaaalways affects power limits as well. However feel free to prove it wrong, always interesting to see which cases still exists. You can attempt to verify this by putting load on the CPU (eg stress --cpu) and change the profile somehow. On Polaris AMD version you can check the package power with https://github.com/ocerman/zenmonitor for example. Otherwise you can get a hint from the currently chosen clock speed.

We are looking to incorporate ODM power profile choice to the TCC profiles as long as we can keep our fan control. This still needs some work however.

So I have where to start with, what are the bits that control the LED (which also activate ODM power profiles)? (not knowing is OK but I'm not sure if that's the case)

Also as stated the address is 0x0751. From memory there are three modes 0x00, 0x10, 0xa0 (all are not available on all devices, most lightweight devices only have two). We basically set neither of these (or 0x00) but basically the 0x40 bit to allow manual fan control.

Careful when writing around in these areas. Some regions might make more persistent and surprising changes ^^

[brunoais]

However feel free to prove it wrong,

Here I show a video where the power profile changes but TCC still has full control over the fans (had to be cut due to file size constraints):

https://user-images.githubusercontent.com/639467/117719354-34633780-b1d5-11eb-8389-e6886e9734ae.mp4
https://user-images.githubusercontent.com/639467/117719368-3927eb80-b1d5-11eb-9bea-5f91c1e105a5.mp4
https://user-images.githubusercontent.com/639467/117719379-3e853600-b1d5-11eb-9a4e-d64e4c140d14.mp4

Here's the full video before being cut (remove the .log extension from the files):

performance not affected.mp4.7z.001.log
performance not affected.mp4.7z.002.log
performance not affected.mp4.7z.003.log

ODM power profile choice to the TCC profiles as long as we can keep our fan control.

Is what I shown enough to prove that? From what it seemed to me, TCC had full control over the fans during the experiment. Power mode didn't do anything about how they were turning. It was all TCC. Feel free to explain me wrong ;).

I forgot to check with zenmonitor so I went to do it in a new recording.
https://user-images.githubusercontent.com/639467/117723033-c9682f80-b1d9-11eb-82a8-f4f76f44fc92.mp4
In manual mode, it appears like the LED gets changed but nothing happens to the PC besides the power mode LED (you can see in the current setting in the "Power mode" terminal window).

From memory there are three modes 0x00, 0x10, 0xa0

In Polaris 17 I have (nvidia and AMD), it's actually 0x00, 0x10, 0x90 but either 0x90 and 0x80 give the same result in all aspects I could test by reverse-engineering. What does the 0x20 bit do? I really wish I had the manual at this point but I can't find it anywhere.

most lightweight devices only have two

Oh! Any more information so I can code that down? For now, I have the 3 power modes hardcoded because I don't know how to detect them.
You can find the code here: https://github.com/brunoais/tuxedo-keyboard/tree/power_mode_works
It is still not clean, btw.

Some regions might make more persistent and surprising changes ^^

Agreed. I accidentally set a bit to make fans go 100%. Makes me want to assign that feature to Fn+ 1 just like my previous PC. Took me quite some tries to single out the two bits that control the power mode. I actually didn't expect that none set is not the lowest power mode and is the medium instead.
I still want that manual....

BTW, I already make use of power modes in my PC. I have a python script (as root) that selects the TCC profile to use automatically based on power mode set and time of day by reading from /dev/tuxedo/user_events. If it's integrated with TCC, I hope it's an optional (through very welcome) feature.

[tuxedoxt]

However feel free to prove it wrong,

Here I show a video where the power profile changes but TCC still has full control over the fans (had to be cut due to file size constraints):

I was referring to the individual LED controlling of the original topic 🙄

However if it does manage to maintain fan control while changing power modes that would be good news for the simultaneous odm power profile use. I see the videos, there do seem to be some weirdness there regarding combination of LED and cpu frequency not budging though. Fan control is hard to say since I believe TCC shows the speed it believes it sets currently.

Best way to check if power limit stays while fan control is active would probably be to change the hardcoded profile we currently set to 0xa0 instead of 0x00 and verify that performance now is limited. See https://github.com/tuxedocomputers/tuxedo-keyboard/blob/master/src/tuxedo_io/tongfang_wmi.h#L283-L285

For now, I have the 3 power modes hardcoded because I don't know how to detect them.

I still want that manual....

Welcome to the club 😁

There are two or three modes depending on model. Also looking for a place to read it out. Can be seen in bios settings or the windows odm control center application, of course. Please let me know if you find something. Otherwise it needs to be mapped per model.

[brunoais]

I was referring to the individual LED controlling of the original topic roll_eyes

My misunderstanding. Thankfully/hopefully we are on the same page now.

However if it does manage to maintain fan control while changing power modes that would be good news for the simultaneous odm power profile use. I see the videos, there do seem to be some weirdness there regarding combination of LED and cpu frequency not budging though. Fan control is hard to say since I believe TCC shows the speed it believes it sets currently.

🤔... I don't know how to read the actual current fan speeds. Do you know and can you provide me the EC addresses for that? I can quick and dirty make a sys file to expose it and include that info in a following test.

Best way to check if power limit stays while fan control is active would probably be to change the hardcoded profile we currently set to 0xa0 instead of 0x00 and verify that performance now is limited. See https://github.com/tuxedocomputers/tuxedo-keyboard/blob/master/src/tuxedo_io/tongfang_wmi.h#L283-L285

I actually removed that writting in my version. In my version, nothing is set at 0x0751 at the time the driver is initialized.
https://github.com/brunoais/tuxedo-keyboard/blob/power_mode_works/src/tuxedo_io/tongfang_wmi.h#L277
tccd is the one writting to it and flip the bit to start manual mode. tccd would also overwrite the power-mode in those ioctl call if it wasn't for the bit filter I wrote which prevents the overwrite, through an ioctl. I do know tccd overwrites the mode because I checked with a log write.

Welcome to the club grin

So you are also stuck without a manual... I thought due to being an OEM, you'd have access to one.
Are you open to share what you have already reverse-engineered?
So far, I got the power mode bits and the touchpad bits for the Polaris 17 (TongFang GK7NR0R).

There are two or three modes depending on model. Also looking for a place to read it out. Can be seen in bios settings or the windows odm control center application, of course. Please let me know if you find something. Otherwise it needs to be mapped per model.

In order to have an initial functional version to propose here, I would need the list or I would need you to (later) add a commit with the list configured so it can be coded down.

As for the code itself. I wouldn't allow a copy from userspace to directly to the EC using ioctl. I would prefer to just give a selection of options each one acting individually and then the driver being responsible to translate to hardware. Same basics as I did for power mode or the keyboard control. There's 3 modes; 0, 1 and 2 and not 0x00, 0x10, 0x90. 0,1 and 2 which also correlate to the number of LED that are turned on.

Also... I think there should also be a cleanup in terms of .h having code and not just the headers and then having .c with most of the code. I think it's starting to become a mess. Unfortunately, I don't know how that impacts the compilation of a linux module.

[brunoais]

Meanwhile, I made a video showcasing different settings on TCC and me changing power modes. During that process, nothing visibly happens when power mode changes. Changes only happen when the profile is changed.

power_mode_changes_did_nothing.mp4

My suspicion is that those two bits make changes to the choice of fan speed and CPU frequency but TCC overrides them by setting its own. I only have 1 machine (and only have money for 1 machine) so I can't execute these tests on other machines with my version of the driver for comparison.

[caravelaPortuguesa]

Brunoais,
What should I do to install your version instead?

[brunoais]

@caravelaPortuguesa
Don't. I really recommend you not to. Neither have I installed the driver in case it would cause a problem. When I boot my PC the driver loaded is the stable version from this repository.
I'm still not done testing and it can break at any time requiring you to reboot your PC to fix it.

Do NOT do it

unless you are willing to deal with such potential issues and having dmesg in hand to debug or fix what happened.

Having said that, assuming you understand the risks, the compilation procedure is the same as in this repository. Just run make and then you can run the convenience script reloadModules.sh to reload the drivers in order.