search

dell / libsmbios

library for interacting with Dell SMBIOS tables
Other
192 stars 39 forks source link

Can't change keyboard backlight timeout on AC #48

Closed Venemo closed 6 years ago

Venemo commented 6 years ago

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:

superm1 commented 6 years ago

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

Venemo commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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.

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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

Venemo commented 6 years ago

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 commented 6 years ago

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

superm1 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

Venemo commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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

Venemo commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

superm1 commented 6 years ago

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

Venemo commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

superm1 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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?

Sorry for the long post.

superm1 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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