Can't change keyboard backlight timeout on AC

[Venemo]

Hi,

Not sure if I'm posting this in the right place, but would appreciate any help. I've got an XPS 13 9370, installed Fedora on it, and then updated the bios to 1.3.2 (downloaded from fwupd).

The problem: when the device is on AC power, the keyboard backlight always goes out in 3 seconds. So I tried two things:

• echo "1h" > /sys/class/leds/dell::kbd_backlight/stop_timeout - but this works only on battery power. As soon as I plug in the charger, the keyboard backlight dims in 3 seconds.
• smbios-keyboard-ctl --set-mode - but this gives me the same output as the guy in issue Running smbios-keyboard-ctl gives UnicodeDecodeError in _common.py #41

[superm1]

What kernel are you running on? Libsmbios interface doesn't work on some newer kernels by default.

[Venemo]

@superm1 I tried 4.16 and 4.17 and got the same results. Like I said I also tried the alternative, but that doesn't work correctly either.

[Venemo]

So while I recognize that this is not libsmbios's fault, I would just like to know what is the correct way to set the keyboard backlight timeout of the laptop on AC. Thank you.

[Venemo]

I booted into Ubuntu 16.04 with an older kernel. Here is what I get:

root@ubuntu:~# smbios-keyboard-ctl --set-timeout-ac 1h
Traceback (most recent call last):
  File "/usr/sbin/smbios-keyboard-ctl", line 713, in <module>
    sys.exit( main() )
  File "/usr/sbin/smbios-keyboard-ctl", line 680, in main
    raise RunTimeKeyboardErr("This system doesn't support AC timeout" )
__main__.RunTimeKeyboardErr: This system doesn't support AC timeout
root@ubuntu:~# 

Apparently there is no way to change the timeout on AC on this laptop. I also tried this:

root@ubuntu:~# smbios-keyboard-ctl --set-mode
Setting USER Selectable Keyboard Mode

 Supported USER Selectable Modes: 
	Option	Mode
------------------------------------------------
	0	Always OFF
	6	Auto: Input-activity-based On (illumination level 50%); input-activity based Off
	8	Auto: Input-activity-based On (illumination level 100%); input-activity based Off

 Note: some modes might need the keyboard set at specific illumination levels

Select Mode: 

It does not even give me the option to set it to always on.

EDIT: I also tried to reflash older bios versions, but they all give me the same result.

[superm1]

I didn't get a chance to comment on this more over the weekend but it's a bit of a more complicated scenario going on.

Let me try to explain.

• In Ubuntu 16.04 the kernel only contains dcdbas which both the kernel modules and libsmbios use. The libsmbios in the repositories for Ubuntu 16.04 doesn't properly support timeouts on AC. That was fixed in a newer libsmbios.
• In Ubuntu 18.04 it contains a kernel with dell-smbios-wmi, dell-smbios-smm, and dcdbas. It also contains a newer libsmbios in the repositories that can set timesouts on AC and battery both properly. However due to WMI command filtering it's not allowed to run. You would need to either unbind dell-smbios-wmi or unload it to cause libsmbios to fall back to dcdbas.

Now in the kernel with Ubuntu 18.04+ it has support to set both battery and AC timeouts. Depending on when you call it (if power supply is plugged in or not) will affect which one it uses.
https://github.com/torvalds/linux/blob/master/drivers/platform/x86/dell-laptop.c#L1593

So I think what you want to do is set the timeout on AC while you have AC plugged in from the kernel side.

[Venemo]

@superm1 For the results that I posted above I didn't use the package versions from old Ubuntu, I simply used the latest release deb files from GitHub. But I will try your suggestion and boot into Ubuntu 18.04 as well to see what happens.

[Venemo]

All right, I now booted into Ubuntu 18.04 but encountered the same problem as on Fedora 28. Whatever I write into /sys/class/leds/dell::kbd_backlight/stop_timeout it will only work on battery power, not on AC.

EDIT: regardless of whether or not I'm on battery power or AC when I write the file

[superm1]

Can you please try to go into BIOS setup and change the settings manually? Do they get lost when you do this?

[Venemo]

The BIOS setup only offers 3 options: off, dim, bright. It is currently set to bright. There is no way to set any kind of timeout in the BIOS setup UI.

[Venemo]

@superm1 Did I just catch a bug in the BIOS?

[superm1]

Yes it's possible that it's a bug with the embedded controller (very unlikely BIOS), but I would be fairly surprised since after Linux got support for separate AC/battery readings I don't believe this has changed.

[Venemo]

@superm1 I'm just guessing here. Could be a bug in the kernel driver? Do you maybe have any more suggestions on how fix this?

[superm1]

OK so I looked a little closer and the way that the system determines if AC timeout should be offered is via the presence of the SMBIOS token 0x451. I don't see it present on that platform.

Can you please try using Dell Command Configure to see if you can set it from there? I don't think you'll be able to, but it would be a good confirmation. If you can set it from there then we are looking at a bug in the implementation of detecting AC support is available.
http://www.dell.com/support/manuals/us/en/04/command-configure-v3.3/dellcommandconfigure-cli-3.3/--kbdbacklighttimeoutac?guid=guid-478420bf-054b-4aab-b8e3-23b924419b6f&lang=en-us

There are RPM's and DEB's available for it.

If you can't set it there either but you DO see different options related to AC and battery in BIOS setup, then I would recommend you contact support.

[Venemo]

Sorry, can you please point me to the rpm package? I found this page, but it only has a deb package: http://www.dell.com/support/home/us/en/19/drivers/driversdetails?driverId=TN4RG

I don't see different options for this in the BIOS setup, just the single option that I mentioned to you previously. Does this mean that on AC the laptop will forever shut down the keyboard backlight in 3 seconds?

[superm1]

Here are RPMs:
http://www.dell.com/support/home/us/en/04/Drivers/DriversDetails?driverId=11P8H

If you don't see options in BIOS setup that usually means that it's the same for battery and AC.

[Venemo]

Found the RPM here, I think: http://en.community.dell.com/techcenter/enterprise-client/w/wiki/7532.dell-command-configure

[Venemo]

Thanks! This is what I got:

[root@timur-xps ~]# /opt/dell/dcc/cctk --kbdbacklighttimeoutac=15m

The option 'KbdBacklightTimeoutAc' is not available or cannot be configured
through this tool.
[root@timur-xps ~]# /opt/dell/dcc/cctk --kbdbacklighttimeoutac=never

The option 'KbdBacklightTimeoutAc' is not available or cannot be configured
through this tool.
[root@timur-xps ~]# 

EDIT: also tried this:

[root@timur-xps ~]# /opt/dell/dcc/cctk --keyboardbacklightonacpower=disable

The option 'KeyboardBacklightOnAc' is not available or cannot be configured
through this tool.
[root@timur-xps ~]# /opt/dell/dcc/cctk --keyboardbacklightonacpower=enable

The option 'KeyboardBacklightOnAc' is not available or cannot be configured
through this tool.
[root@timur-xps ~]# 

[Venemo]

This one seems to be equivalent to what's in the BIOS setup: --keyboardillumination= which works with off, dim or bright.

However on AC the backlight still turns off in 3 seconds, regardless of how I set this.

[Venemo]

@superm1 By the way can you reproduce this problem with a 9370 or is this somehow unique to my machine?

In the BIOS setup I also tried to reset to factory defaults, but that did not have any effect on the keyboard backlight either.

[Venemo]

I can confirm that smbios-token-ctl -i 0x451 returns nothing, so the 0x451 token is not present on this machine.

[Venemo]

Even though token 0x451 is missing, the system still seems to differentiate between AC and battery timeout. Currently whatever I set to stop_timeout only applies on battery.

I came up with this quick hack:

diff --git a/drivers/platform/x86/dell-laptop.c b/drivers/platform/x86/dell-laptop.c
index c52c6723374b..a2add2374c56 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -1590,13 +1590,10 @@ static ssize_t kbd_led_timeout_store(struct device *dev,
 
 	new_state = state;
 
-	if (kbd_timeout_ac_supported && power_supply_is_system_supplied() > 0) {
-		new_state.timeout_value_ac = value;
-		new_state.timeout_unit_ac = unit;
-	} else {
-		new_state.timeout_value = value;
-		new_state.timeout_unit = unit;
-	}
+	new_state.timeout_value_ac = value;
+	new_state.timeout_unit_ac = unit;
+	new_state.timeout_value = value;
+	new_state.timeout_unit = unit;
 
 	ret = kbd_set_state_safe(&new_state, &state);
 	if (ret)

This would basically make it set the necessary values regardless of whether it thinks it can. (If this works, then the right way to do it would be to add a new field to quirk_entry and then add a quirk_dell_xps13_9370 quirk setting that field to true.)

@superm1 Do you think this is worth trying or would this corrupt my system?

[Venemo]

Okay, I patched my kernel with the above and now I can set the timeout for both AC and battery at the same time. So the conclusion is that even though the BIOS doesn't expose the necessary token, the machine can still set the AC timeout.

[Venemo]

I will try to create a non-hacky kernel patch tomorrow.

[superm1]

Sounds like then this is a BIOS bug after all. Can up please report it to support?

[Venemo]

How do I report it to support? And what should I tell them?

No offence, but I doubt that the support person will be able to discuss kernel patches.

[superm1]

Understood the concern. Are you US based?
Contact information is here http://www.dell.com/support/incidents-online/us/en/04
There is a dedicated group that does Linux support that you should get directed into. I don't expect them to produce a kernel patch, but I would expect they can sort out notifying sustaining BIOS team to fix the missing token in a future maintenance BIOS release.

You should notify them that the platform isn't working with Dell Command Configure. You can also share this bug over the email and BIOS team should be able to see technical details you found with missing token.

Keep in mind it will take a few months to get fixed this approach but it's the right way to fix it (rather than kernel patch for quirks). If you want to do that still you can too though.

[Venemo]

Thank you Mario for guiding me through this.
I live in Budapest, Hungary. The laptop was purchased in Vienna, Austria. (I specifically wanted the Linux version which isn't sold here.) Unfortunately my German is too rusty for such a conversation, but I could try to contact them in English. Wouldn't it be easier if you simply forwarded this to the BIOS team internally?

I agree that fixing the BIOS is ultimately the correct solution! But there is also value in solving the issue for people who want to use the machine now.

By the way, were you able to reproduce my findings on another 9370?

[Venemo]

In the meantime I've submitted a kernel patch here:
https://www.spinics.net/lists/platform-driver-x86/msg15668.html

[superm1]

Sounds good. Since we know this isn't an libsmbios bug I'll close this.

To prioritize accordingly relative to all the other issues it's better for customers to raise problems that affect them to support.

Yes I see the same behavior using fw 1.3.3.

[pali]

Hi @superm1, can you forward this problem internally to relevant Dell team? Users who buy products outside of USA are not allowed to report these BIOS issue nor any other software relevant. Just HW replacement issues.

We really do not want to have "hacks" in kernel forever just because vendor is not aware that there is a bug in firmware...

[superm1]

Pali fwiw I totally agree and don't want to see hacks in the kernel for this either.

I have already sent this to right people internally as well. The voice of the customer is the most important thing though which is why I asked for it to be filed with support as well.

[pali]

The voice of the customer is the most important thing though which is why I asked for it to be filed with support as well.

In this case, can Dell provides contact also for products bought outside of USA?

I read lot of posts on dell forum (and outside too) of frustrated Dell users about non-working keyboard debouncing on Linux (now it is fixed; there were BIOS update for lot of Latitude machines) and the only thing what happen was HW replacing one keyboard with another (which of course did not help). And I was told that "normal" users cannot report or open Dell BIOS/firmware issue... So if voice of the customer is most important, there is really need to know where to report such problem.

[Venemo]

Indeed as @pali says it would be nice to know what the proper place is for reporting Linux issues to Dell. Yes, I did find the Dell Linux forum, but that does not seem to be something that their developers actively monitor.

While we are at it:
I really appreciate Dell supporting Linux on their ultrabooks, and that is why I purchased this machine. However there are several issues still. I am willing to work on it, so don't mean this just as a complaint, but am genuinely interested in helping out. Can you point me to the right direction with regards to where to report and/or how to fix the below problems?

• The kernel detects two touchpads instead of just one (on 9350, 9360 and 9370), causing weird mouse pointer behavior in Xorg. (The recommended "solution" is to blacklist the psmouse module. Which is surely easier than fixing it.)
• The QCA6174 wireless firmware crashes when the AP changes bandwidth. Fortunately there was already an ath10k patch that I could fix to actually compile.
• As a bonus, ath10k can also hang the entire system completely when there is a firmware crash.
• A suspend-resume cycle can bork the Bluetooth device.
• Default sleep mode is s2idle and not deep. Resulting in high power consumption during sleep.
• Last, but not least: sometimes the laptop just randomly freezes. It gets to a state when not even the kernel's "magic sysrq" will work. Maybe an i915 issue, or maybe a hardware defect? Googling for it finds only some nonsensical stuff.

Sorry for the long post.

[superm1]

@Venemo

Yes, I did find the Dell Linux forum, but that does not seem to be something that their developers actively monitor.

Yes typically social media team monitors web forums and relays information to developers as needed. Sorry to hear there may be gaps here.

so don't mean this just as a complaint, but am genuinely interested in helping out. Can you point me to the right direction with regards to where to report and/or how to fix the below problems?

I'll do my best on what I know.

Regarding two touchpads:
This is because the touchpad is electrically wired such that it can operate in two different modes (PS2 or I2C). I2C is better performance and preferred operating mode. Unfortunately kernel doesn't remove the PS2 node even though it's no longer in use. In Xorg this can cause problems with syndaemon attaching to wrong touchpad.
See this bug for more information:
https://bugs.freedesktop.org/show_bug.cgi?id=101470

Regarding the firmware issues with QCA6174:
These are the kinds of cases that support needs to hear about. It's the same firmware used in both OSes and it's entirely possible there are problems happening in both too. Mentioning in the forums is appropriate.

s2idle/deep
This is intentional in latest upstream kernel. If you're getting too much power consumption you have some bad policy set in kernel. You should use powertop --autotune or a well configured TLP to help with any bad configurations. If you want to help with this one, please join in here:
https://bugzilla.kernel.org/show_bug.cgi?id=199689

random freezes:
Depends on how frequently this is happening for what I would point at for it and what workload is occurring at the time whether I would suspect a driver, firmware or hardware.

[Venemo]

Thanks @superm1 your answer means a great deal to me (especially considering that you are on vacation)!

Regarding two touchpads

Yes, that is what I suspected. In fact dmesg shows a message about it:

[    1.459828] psmouse serio1: synaptics: Your touchpad (PNP: DLL07e6 PNP0f13) says it can support a different bus. If i2c-hid and hid-rmi are not used, you might want to try setting psmouse.synaptics_intertouch to 1 and report this to linux-input@vger.kernel.org.

But actually the "real" touchpad is indeed picked up by i2c-hid.

Regarding the firmware issues with QCA6174

Already reported on the forum too.
This is not a firmware issue per se, but rather a driver problem (ie. the driver not handling the firmware correctly). The bandwidth switch problem is at least fixed by the ath10k patch I linked.

What remains is that if the firmware crashes (for whatever other reason) it will take the whole system with it. Reproducible by simulating some firmware crashes. After the 3rd crash, wifi stops working. I can turn it off in Gnome. When I turn it on again, the whole system hangs completely. (The symptoms are the same as the "random freeze" described below.)

echo hard > /sys/kernel/debug/ieee80211/phy0/ath10k/simulate_fw_crash

s2idle/deep

This one bothers me the least of all, so I haven't really looked into it yet. I will join the conversation in the bug report you linked! Looks like some work went into it on the tlp side at least. What is the advantage of using s2idle over deep?

random freezes

Depends on how frequently this is happening for what I would point at for it and what workload is occurring at the time whether I would suspect a driver, firmware or hardware.

Very hard to say. It can occour any time (even when I'm just web browsing or coding), but it feels like it happens more often when there is GPU load (eg. a game). Happens several times every day.

The symptoms: the computer stops responding to any input (not even the "magic sysrq"), and the last 1 second of music is looped forever. The display freezes, sometimes stays as it was, sometimes red bars appear, sometimes it goes blank (regardless of whether it's the internal or an external display). Since these are the same symptoms as the ath10k driver issue, it could be some sort of kernel hang as well. But not sure.

I've seen the same symptom in other computers caused by inadequate cooling, fried GPU, or motherboard defect. Googling suggests it's a memory issue. I did a memory check with the BIOS recovery tool, and also with memtest86, neither found any problem with the memory.

EDIT: according to smartctl the SSD had 112 unsafe shutdowns, so that is the total number of times the XPS froze for me during the 2 weeks I've had it so far.

[superm1]

Regarding two touchpads

Feel free to comment on the bug on this. It hasn't seen attention in a long time.

This one bothers me the least of all, so I haven't really looked into it yet. I will join the conversation in the bug report you linked! Looks like some work went into it on the tlp side at least. What is the advantage of using s2idle over deep?

The biggest advantage is a much faster resume from a sleep state. The biggest disadvantage is that if you have a device misbehave (either by user error, device error or policy) it can cause a much larger battery drain on the system.

I anticipate to see a lot more machines adopt s2idle (and possibly even DROP deep support) so it's important to find and fix core issues (both kernel bugs and policy problems) now while on machines that can switch between both modes.

random freezes

112 times sounds really high. I would recommend to contact support on this.

[Venemo]

@superm1

Regarding two touchpads

I started a discussion about it on the fedora-kernel list, see here. You are right, the psmouse device does not send any data, so it isn't the problem. Turns out that Fedora doesn't use syndaemon anymore, so it is most likely either a bug in libinput or in the touchpad kernel driver (or who knows where). Will let you know how this goes.

s2idle The biggest advantage is a much faster resume from a sleep state. The biggest disadvantage is that if you have a device misbehave (either by user error, device error or policy) it can cause a much larger battery drain on the system.

You sold me on it! Sounds like this is "just" a matter of configuring a correct system policy in tools like tlp. In fact, now that they fixed your bug, is there anything left in tlp that makes it undesireable to use with the XPS?

random freezes 112 times sounds really high. I would recommend to contact support on this.

I'm now 99.99% sure it's a hardware defect, and will get a replacement. (Still within the 30 days, so it's just a matter of walking to the store.)

[superm1]

Will let you know how this goes.

Awesome, thanks for having that conversation.

You sold me on it! Sounds like this is "just" a matter of configuring a correct system policy in tools like > tlp. In fact, now that they fixed your bug, is there anything left in tlp that makes it undesireable to use > with the XPS?

In my opinion default kernel policy can still need some work. I really feel the goal should be to accomplish good performance WITHOUT tlp.
If you can provide feedback on that kernel bugzilla to the things asked it would help.

[superm1]

Just to close the loop on this issue as reported by the OP, this was confirmed to be fixed in BIOS 1.4.0.