Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6

I recently got new Skylake hardware (e7x6) from Fujitsu. Compared to previous Haswell generation (e7x4), some of the Fn+X key combination stopped working. This includes the brightness and "touchpad dis-/enable" key combinations.

For the brightness control it's understandable, as this was handled by a ACPI device FUJ02B1, which is no longer available.

I don't know how the touchpad disable key was actually working, as I don't get any scan codes or ACPI events in userspace - probably I'm missing something here.

I compiled the git fujitsu-notebook driver ...

... can see ACPI notifications when any of the non-working combination is pressed like:

[  408.997023] FUJ02B1: call_fext_func: FUNC 0x1000 (args 0x4, 0x0, 0x0)
returned 0x100
[  408.997072] FUJ02B1: call_fext_func: FUNC 0x1002 (args 0x1, 0x0, 0x0)

returned 0x0

so these button states seems to be handled differently then all the other buttons. (FUNC 0x1002 is used to check the special button states).

BTW: the debug message is a little misleading, as all of them are prefixed 'FUJ02B1', even if the ACPI event is handled by the FUJ02E3 device.

I checked the DSTD from the old and new HW. The size has more then duplicated (414k => 955k) with a 43k diff. The diff for the FUJ02E3 device is just 356 lines, but I couldn't identify anything, which might relate to the keys.

Any help would be appreciated to get this fixed.

Quoted 7 lines

I recently got new Skylake hardware (e7x6) from Fujitsu. Compared to previous Haswell generation (e7x4), some of the Fn+X key combination stopped working. This includes the brightness and "touchpad dis-/enable" key combinations.

For the brightness control it's understandable, as this was handled by a ACPI device FUJ02B1, which is no longer available.

I see. Perhaps they've rolled this functionality into FUJ02E3 (which previously has handled everything except brightness control).

Quoted 3 lines

I don't know how the touchpad disable key was actually working, as I don't get any scan codes or ACPI events in userspace - probably I'm missing something here.

Maybe on the previous hardware generation the touchpad keys were controlled solely in hardware, and for some reason they've moved them to software in the latest generation.

Quoted 1 line

I compiled the git fujitsu-notebook driver ...

I assume this was "fujitsu-laptop".

Quoted 8 lines

... can see ACPI notifications when any of the non-working combination is pressed like:

[  408.997023] FUJ02B1: call_fext_func: FUNC 0x1000 (args 0x4, 0x0, 0x0)
returned 0x100
[  408.997072] FUJ02B1: call_fext_func: FUNC 0x1002 (args 0x1, 0x0, 0x0)

returned 0x0

Quoted 2 lines

so these button states seems to be handled differently then all the other buttons. (FUNC 0x1002 is used to check the special button states).

For clarity, which buttons are the "non-working combinations"? Is it just the brightness/touchpad buttons, or are there others which are behaving similarly?

Quoted 2 lines

BTW: the debug message is a little misleading, as all of them are prefixed 'FUJ02B1', even if the ACPI event is handled by the FUJ02E3 device.

Yes, good point. The use of "FUJ02B1" (via ACPI_FUJITSU_HID) would have been for convenience and possibly dates from before FUJ02E3 support was included in the driver. A case can certainly be made for a more generic descriptor.

Quoted 4 lines

I checked the DSTD from the old and new HW. The size has more then duplicated (414k => 955k) with a 43k diff. The diff for the FUJ02E3 device is just 356 lines, but I couldn't identify anything, which might relate to the keys.

Perhaps they've introduced a new backlight control device with a different HID (except you mentioned that only FUJ02E3 was listed even on other OSes, so I guess this is unlikely).

Quoted 1 line

Any help would be appreciated to get this fixed.

I don't have access to any of the newer Fujitsu hardware so I can't do much in relation to debugging the problem. Obviously the buttons concerned generate ACPI notifications. Without a FUJ02B1 and any obvious extension to FUJ02E3, my only thought at present is that they've taken backlight control out of ACPI (that is, based on the ACPI button notification they poke other hardware to effect the brightness control). It does seem a bit odd though.

In any case, we'd have to identify what is meant to be done (and what is done under other OSes) in reponse to these buttons.

I assume that the brightness buttons don't do anything when fujitsu-laptop is unloaded? I'm wondering whether the standard backlight driver might be operational on this hardware.

Just to make this clear. It's not "touchpad keys" but the "Fn + F4", which should toggle the touchpad functionality (is broken on Windows too).

I'm just talking about Fn + Brightness (Fn + (F6|F7)) and "touchpad dis-/enable" (Fn + F4) key events.
Not those real extra buttons, like ECO, RFkill, etc.

Quoted 4 lines

Quoted 4 lines

I checked the DSTD from the old and new HW. The size has more then duplicated (414k => 955k) with a 43k diff. The diff for the FUJ02E3 device is just 356 lines, but I couldn't identify anything, which might relate to the keys.

43k = lines. (I didn't find a way to normalize the DSTD to catch moved objects).

Quoted 3 lines

Perhaps they've introduced a new backlight control device with a different HID (except you mentioned that only FUJ02E3 was listed even on other OSes, so I guess this is unlikely).

The diff of the sorted device list is also 230 lines. I checked the devices, which start with F, but these don't seem interesting.

Quoted 8 lines

I don't have access to any of the newer Fujitsu hardware so I can't do much in relation to debugging the problem. Obviously the buttons concerned generate ACPI notifications. Without a FUJ02B1 and any obvious extension to FUJ02E3, my only thought at present is that they've taken backlight control out of ACPI (that is, based on the ACPI button notification they poke other hardware to effect the brightness control). It does seem a bit odd though.

Quoted 6 lines

In any case, we'd have to identify what is meant to be done (and what is done under other OSes) in reponse to these buttons.

I assume that the brightness buttons don't do anything when fujitsu-laptop is unloaded? I'm wondering whether the standard backlight driver might be operational on this hardware.

Unloading doesn't help.

A backlight device is available via /sys/class/backlight/intel_backlight and you can change brightness manually. AFAIK this device is provided by the i915 driver.

We'll use the KDE battery applet as a workaround, so users have a way to change the backlight.

OTOH a colleague told me our vendor has opened a service call with Fujitsu and was told Fujitsu is working on a fix - at least for the Touchpad button (quite probably a BIOS update).

If you don't have an additional ideas for me to check, I'll wait for a reply from Fujitsu.

Quoted 3 lines

A backlight device is available via /sys/class/backlight/intel_backlight and you can change brightness manually. AFAIK this device is provided by the i915 driver.

So perhaps the intent on other systems is to respond to the ACPI button notifications by manipulating the intel backlight hardware. If this is the case we'd need a way to do this from within the fujitsu-laptop driver in response to the buttons you've identified.

Quoted 8 lines

Quoted 3 lines

A backlight device is available via /sys/class/backlight/intel_backlight and you can change brightness manually. AFAIK this device is provided by the i915 driver.

So perhaps the intent on other systems is to respond to the ACPI button notifications by manipulating the intel backlight hardware. If this is the case we'd need a way to do this from within the fujitsu-laptop driver in response to the buttons you've identified.

Is implementing this in the kernel really worth the effort? I ended up using xbacklight bound (in my window manager) to the brightness hotkeys for both my Lifebook E744 and my Vostro V131, which has a royally borked ACPI backlight control implementation. It seems using userspace helpers for backlight control is the new normal [1]. Yes, you lose console brightness control; I can live with that, YMMV.

[1] https://www.spinics.net/lists/platform-driver-x86/msg07902.html

Am 22.06.2016 um 09:32 schrieb Micha?? K??pie??:

Quoted 8 lines

Is implementing this in the kernel really worth the effort? I ended up using xbacklight bound (in my window manager) to the brightness hotkeys for both my Lifebook E744 and my Vostro V131, which has a royally borked ACPI backlight control implementation. It seems using userspace helpers for backlight control is the new normal [1]. Yes, you lose console brightness control; I can live with that, YMMV.

[1] https://www.spinics.net/lists/platform-driver-x86/msg07902.html

The e7x6's DSTD misses the ACPI brightness control device (FUJ02B1), so the brightness part of the fujitsu-laptop driver isn't used and therefore - in addition to the direct brightness adjustment - generates no keycodes for the keys.

A userspace keycode handling solution would be totally sufficient. Would be nice, if it worked in kernel but that's clearly optional for me.

Quoted 10 lines

Am 22.06.2016 um 09:32 schrieb Micha?? K??pie??:

Quoted 8 lines

Is implementing this in the kernel really worth the effort? I ended up using xbacklight bound (in my window manager) to the brightness hotkeys for both my Lifebook E744 and my Vostro V131, which has a royally borked ACPI backlight control implementation. It seems using userspace helpers for backlight control is the new normal [1]. Yes, you lose console brightness control; I can live with that, YMMV.

[1] https://www.spinics.net/lists/platform-driver-x86/msg07902.html

Quoted 7 lines

The e7x6's DSTD misses the ACPI brightness control device (FUJ02B1), so the brightness part of the fujitsu-laptop driver isn't used and therefore - in addition to the direct brightness adjustment - generates no keycodes for the keys.

A userspace keycode handling solution would be totally sufficient. Would be nice, if it worked in kernel but that's clearly optional for me.

Since the newer hardware lacks an ACPI brightness controller and it is possible to have userspace deal with the brightness in these cases, it seems to me that the solution to the issue lies outside of the fujitsu-laptop module (which is focussed on the custom devices in the laptops). I am more than willing to be convinced otherwise, but at present this seems to be the prevailing line of thought.

Regards

Someone / Something has to generate the keycodes, even if we skip all brightness control. And I get an ACPI event for the FUJ02E3 when I press the keys, but I don't know what to do with it (AKA which DSTD function to call).

Quoted 4 lines

Someone / Something has to generate the keycodes, even if we skip all brightness control. And I get an ACPI event for the FUJ02E3 when I press the keys, but I don't know what to do with it (AKA which DSTD function to call).

Can you post a DSDT dump of your machine somewhere so that we can take a look?

I played with my Lifebook E744 a bit and there is a chance it is not as different from the Skylake machines as I originally imagined. Earlier in this thread, I already mentioned that pure ACPI brightness control doesn't work, just like it doesn't work on Skylakes. However, input events are correctly generated when Fn+F6 or Fn+F7 is pressed.

And I am
sure these events are generated by ACPI code as booting with acpi=off makes the input events disappear, while also causing brightness to be correctly adjusted. Thus, I can try to figure out which part of the ACPI code causes the input events to be generated. That information combined with your DSDT dump might help us in figuring out how to make it work for your machine. However, it might just as well turn out that Fujitsu switched to using WMI or some opaque vendor-specific magic.

Quoted 5 lines

I played with my Lifebook E744 a bit and there is a chance it is not as different from the Skylake machines as I originally imagined. Earlier in this thread, I already mentioned that pure ACPI brightness control doesn't work, just like it doesn't work on Skylakes. However, input events are correctly generated when Fn+F6 or Fn+F7 is pressed.

That's no mystery, because the brightness control ACPI device (AKA FUJ02B1 is available on e7x4 notebooks and the diriver also generates the keycodes in addition.

The diff between e7x4 and e7x6 DSDT is ~43k lines or 1.3MB And the DSDT of 736 and 756 is identical.

Quoted 8 lines

And I am
sure these events are generated by ACPI code as booting with acpi=off makes the input events disappear, while also causing brightness to be correctly adjusted. Thus, I can try to figure out which part of the ACPI code causes the input events to be generated. That information combined with your DSDT dump might help us in figuring out how to make it work for your machine. However, it might just as well turn out that Fujitsu switched to using WMI or some opaque vendor-specific magic.

The ACPI code doesn't generate the keycodes.
Look at the acpi_fujitsu_notify function in
drivers/platform/x86/fujitsu-laptop.c

And sure, without ACPI no ACPI driver will be loaded.

So without ACPI, the brightness buttons work correctly (not that's an option to run a laptop without ACPI)?

Quoted 9 lines

Quoted 5 lines

I played with my Lifebook E744 a bit and there is a chance it is not as different from the Skylake machines as I originally imagined. Earlier in this thread, I already mentioned that pure ACPI brightness control doesn't work, just like it doesn't work on Skylakes. However, input events are correctly generated when Fn+F6 or Fn+F7 is pressed.

That's no mystery, because the brightness control ACPI device (AKA FUJ02B1 is available on e7x4 notebooks and the diriver also generates the keycodes in addition.

No, at least not on Haswells. For proof, do an `rmmod fujitsu-laptop' on a Haswell machine and press Fn+F6 or Fn+F7. The input event will still be generated. What happens is that pressing Fn+F6 or Fn+F7 raises a certain GPE (General-Purpose Event; 0x11 on Haswells). This causes the corresponding ACPI method (_L11) to be called, which in turn sends notifications to both FUJ02B1 and the ACPI video device. On my Haswell machine, the former [1] effectively does nothing, because subsequent calls to GBLL keep returning the same brightness level, apparently ignoring key presses, but the latter [2] is enough because it causes acpi_video to generate an input event. For further proof, boot a 4.5+ kernel on a Haswell machine with command line parameter video.report_key_events=1. Brightness-related input events will not be generated any more.

I looked at the ACPI tables you sent me and it looks like brightness-related keys should be handled by ACPI method _L21 on Skylakes. As far as I can tell without playing with the hardware myself, the ACPI code doesn't strike me as outright broken, so the first step would be to confirm whether the relevant GPE is raised at all when you press brightness-related keys. To check it, launch the following command in a terminal:

watch -n 1 cat /sys/firmware/acpi/interrupts/gpe21

and press Fn+F6 or Fn+F7. The counter should get increased by one.

If it does, try overriding ACPI method _L21 [3] so that you can read the value of BSWF when the method is invoked.

If that value is 0, it's
obviously a vendor bug as it would prevent the ACPI video device from being notified. If the GPE count isn't increased when brightness-related keys are pressed, it means some hardware initialization may be required before these keys are handled. In that case we would likely be screwed without assistance from Fujitsu.

To sum up, I see no immediate reason for brightness control not to work on Skylakes, so you will have to get your hands a bit dirty to get to the bottom of this (and it might still not yield a solution).

Quoted 12 lines

The diff between e7x4 and e7x6 DSDT is ~43k lines or 1.3MB And the DSDT of 736 and 756 is identical.

Quoted 8 lines

And I am
sure these events are generated by ACPI code as booting with acpi=off makes the input events disappear, while also causing brightness to be correctly adjusted. Thus, I can try to figure out which part of the ACPI code causes the input events to be generated. That information combined with your DSDT dump might help us in figuring out how to make it work for your machine. However, it might just as well turn out that Fujitsu switched to using WMI or some opaque vendor-specific magic.

Quoted 8 lines

The ACPI code doesn't generate the keycodes.
Look at the acpi_fujitsu_notify function in
drivers/platform/x86/fujitsu-laptop.c

And sure, without ACPI no ACPI driver will be loaded.

So without ACPI, the brightness buttons work correctly (not that's an option to run a laptop without ACPI)?

Indeed. My understanding is that on an operating system without ACPI support, brightness is adjusted directly by the BIOS.

[1] Notify (\_SB.PCI0.LPCB.FJEX, 0x80)
[2] \_SB.PCI0.GFX0.LCD.BLNF ()
[3] see: Documentation/acpi/method-customizing.txt

Quoted 8 lines

I looked at the ACPI tables you sent me and it looks like brightness-related keys should be handled by ACPI method _L21 on Skylakes. As far as I can tell without playing with the hardware myself, the ACPI code doesn't strike me as outright broken, so the first step would be to confirm whether the relevant GPE is raised at all when you press brightness-related keys. To check it, launch the following command in a terminal:

Quoted 3 lines

watch -n 1 cat /sys/firmware/acpi/interrupts/gpe21

and press Fn+F6 or Fn+F7. The counter should get increased by one.

Yup - great. This works :-)
I would be interested to know, how you came to this conclusion. Is this encoded in the ssdt tables?

I really want to understand this. Should I
read the ACPI specs?

Quoted 2 lines

If it does, try overriding ACPI method _L21 [3] so that you can read the value of BSWF when the method is invoked.

I'll read [3] and report back later.

Quoted 7 lines

If that value is 0, it's
obviously a vendor bug as it would prevent the ACPI video device from being notified. If the GPE count isn't increased when brightness-related keys are pressed, it means some hardware initialization may be required before these keys are handled. In that case we would likely be screwed without assistance from Fujitsu.

Quoted 3 lines

To sum up, I see no immediate reason for brightness control not to work on Skylakes, so you will have to get your hands a bit dirty to get to the bottom of this (and it might still not yield a solution).

The brightness buttons work in Windows 7 with the Fujitsu button driver. Didn't check, if they even work without. I can get my hands on a Windows 7 laptop, but that'll take some time, if this additional info would help.

Quoted 8 lines

Quoted 8 lines

I looked at the ACPI tables you sent me and it looks like brightness-related keys should be handled by ACPI method _L21 on Skylakes. As far as I can tell without playing with the hardware myself, the ACPI code doesn't strike me as outright broken, so the first step would be to confirm whether the relevant GPE is raised at all when you press brightness-related keys. To check it, launch the following command in a terminal:

Quoted 7 lines

Quoted 3 lines

watch -n 1 cat /sys/firmware/acpi/interrupts/gpe21

and press Fn+F6 or Fn+F7. The counter should get increased by one.

Yup - great. This works :-)
I would be interested to know, how you came to this conclusion. Is this encoded in the ssdt tables?

First I figured out (using a command almost identical to the one I suggested to you) which GPE is used for signalling brightness-related key presses on my Haswell machine. This immediately led me to ACPI method _L11. I selectively commented out ACPI code from this method, recompiling and overriding it using /sys/kernel/debug/acpi/custom_method after every change until I figured out exactly which method invocation causes the key events to be generated. Once I knew that, I searched for a similar invocation in a Skylake DSDT dump. This led me to ACPI method _L21, which is very similar to Haswell's _L11.

Quoted 2 lines

Quoted 2 lines

If it does, try overriding ACPI method _L21 [3] so that you can read the value of BSWF when the method is invoked.

Quoted 10 lines

Quoted 10 lines

If that value is 0, it's
obviously a vendor bug as it would prevent the ACPI video device from being notified. If the GPE count isn't increased when brightness-related keys are pressed, it means some hardware initialization may be required before these keys are handled. In that case we would likely be screwed without assistance from Fujitsu.

To sum up, I see no immediate reason for brightness control not to work on Skylakes, so you will have to get your hands a bit dirty to get to the bottom of this (and it might still not yield a solution).

Quoted 9 lines

First I figured out (using a command almost identical to the one I suggested to you) which GPE is used for signalling brightness-related key presses on my Haswell machine. This immediately led me to ACPI method _L11. I selectively commented out ACPI code from this method, recompiling and overriding it using /sys/kernel/debug/acpi/custom_method after every change until I figured out exactly which method invocation causes the key events to be generated. Once I knew that, I searched for a similar invocation in a Skylake DSDT dump. This led me to ACPI method _L21, which is very similar to Haswell's _L11.

Thanks for this info. I guess I can also debug the "disable touchpad" button with this method.

I'm currently to recompiling my Ubuntu kernel, as it doesn't set CONFIG_ACPI_CUSTOM_METHOD

Reading _L21, there are quite a few calls to Notify (\_SB.FEXT, 0x80), which is exactly the notify function for the Fujitsu ACPI device.

Actually there are a few more GPEs, which emit Notify (\_SB.FEXT, 0x80) calls, which are caught by the fujitsu-notebook driver.

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

If it does, try overriding ACPI method _L21 [3] so that you can read the value of BSWF when the method is invoked.

What's the easiest way to report the value to userspace? I don't think I can add variables.

My idea was to add a Notify (\_SB.FEXT, 0x80) into the BSWF branch, and remove the Notify calls from all other branches.

Probably even start by removing all Notify calls to be sure the function actually is overwritten.

Quoted 10 lines

Quoted 9 lines

First I figured out (using a command almost identical to the one I suggested to you) which GPE is used for signalling brightness-related key presses on my Haswell machine. This immediately led me to ACPI method _L11. I selectively commented out ACPI code from this method, recompiling and overriding it using /sys/kernel/debug/acpi/custom_method after every change until I figured out exactly which method invocation causes the key events to be generated. Once I knew that, I searched for a similar invocation in a Skylake DSDT dump. This led me to ACPI method _L21, which is very similar to Haswell's _L11.

Quoted 2 lines

Thanks for this info. I guess I can also debug the "disable touchpad" button with this method.

If that button is supposed to be handled by ACPI, then yes, this should help.

Quoted 2 lines

I'm currently to recompiling my Ubuntu kernel, as it doesn't set CONFIG_ACPI_CUSTOM_METHOD

Right, you are going to need that.

Quoted 12 lines

Reading _L21, there are quite a few calls to Notify (\_SB.FEXT, 0x80), which is exactly the notify function for the Fujitsu ACPI device.

Actually there are a few more GPEs, which emit Notify (\_SB.FEXT, 0x80) calls, which are caught by the fujitsu-notebook driver.

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

If it does, try overriding ACPI method _L21 [3] so that you can read the value of BSWF when the method is invoked.

What's the easiest way to report the value to userspace? I don't think I can add variables.

Quoted 5 lines

My idea was to add a Notify (\_SB.FEXT, 0x80) into the BSWF branch, and remove the Notify calls from all other branches.

Probably even start by removing all Notify calls to be sure the function actually is overwritten.

Just use the ACPI debug object. Everything you need is in the documentation I have already referred you to (method-customizing.txt).

I would simply use the original _L21 method with a "Store (BSWF, Debug)" line inserted just before the "If (BSWF)" conditional expression.

Quoted 8 lines

Quoted 8 lines

I looked at the ACPI tables you sent me and it looks like brightness-related keys should be handled by ACPI method _L21 on Skylakes. As far as I can tell without playing with the hardware myself, the ACPI code doesn't strike me as outright broken, so the first step would be to confirm whether the relevant GPE is raised at all when you press brightness-related keys. To check it, launch the following command in a terminal:

Quoted 7 lines

Quoted 3 lines

watch -n 1 cat /sys/firmware/acpi/interrupts/gpe21

and press Fn+F6 or Fn+F7. The counter should get increased by one.

Yup - great. This works :-)
I would be interested to know, how you came to this conclusion. Is this encoded in the ssdt tables?

First I figured out (using a command almost identical to the one I suggested to you) which GPE is used for signalling brightness-related key presses on my Haswell machine. This immediately led me to ACPI method _L11. I selectively commented out ACPI code from this method, recompiling and overriding it using /sys/kernel/debug/acpi/custom_method after every change until I figured out exactly which method invocation causes the key events to be generated. Once I knew that, I searched for a similar invocation in a Skylake DSDT dump. This led me to ACPI method _L21, which is very similar to Haswell's _L11.

Quoted 2 lines

I really want to understand this. Should I
read the ACPI specs?

Well, I cannot stop you from doing that, but I would advise against it if you value your own mental health. Unless you have a very specific reason to do otherwise, just follow the code. If you would like to learn a bit more about GPEs specifically, I recommend this great blog post by Matthew Garrett:

    http://mjg59.livejournal.com/117532.htmlBSWF = Zero

Quoted 8 lines

Quoted 2 lines

If it does, try overriding ACPI method _L21 [3] so that you can read the value of BSWF when the method is invoked.

I'll read [3] and report back later.

Quoted 3 lines

If that value is 0, it's
obviously a vendor bug as it would prevent the ACPI video device from being notified.

Quoted 3 lines

Quoted 3 lines

To sum up, I see no immediate reason for brightness control not to work on Skylakes, so you will have to get your hands a bit dirty to get to the bottom of this (and it might still not yield a solution).

Hmm - so I got

[  561.809723] [ACPI Debug 64952760]  Integer 0x0000000000000000

for my Store (BSWF, Debug) call.

Then I had a look at the \_SB.PCI0.GFX0.LCD.BLNF () function in my ssdt7.dsl, and it sets "BSWF = Zero" as the 2nd last call. And it's the same in the ssdt6.dsl of the Haswell hardware, except there the call to BLNF is guarded by an "LGreaterEqual(OSYS, 0x07D6)" guard, so I guess for newer operating systems, all the functionality is also disabled on Haswell.

But BLNF also sets "AHKF |= One", which triggers this code path containing just a "Notify (\_SB.FEXT, 0x80)", but since it's actually never called, I get no notifications - how did I ever get notifications?

...

until I have pressed the "touchpad" button, which changes AHKF to 8 - permanently - and now I get notifications from all buttons, since all use _L11 :-(

So I actually never got any direct ACPI events from the brightness control, but this was just toggled because of the "touchpad" key, enabling the notifications…

And then I "instrumented" all if's by dumping the value just before the if => everything is always 0, except the permanent 8 in AHKF after pressing the "touchpad" button.

So - just for the sake of it, I had a look for some AHKF code and the button function S000 got new code to handle AHKF - both brightness (AKA BSWF AKA AHKF & One) and the touchpad (AKA AHKF & 0x08)

But this is just called, if you call the ACPI button function in the device driver.

Which leaves me with the problem, that BSWF is always 0.

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

To sum up, I see no immediate reason for brightness control not to work on Skylakes, so you will have to get your hands a bit dirty to get to the bottom of this (and it might still not yield a solution).

That's enough for today.

I'm quite sure Fujitsu changed the in-ACPI-HW-touchpad-disable-handling to be done by the driver.

I don't know, why / how the brightness keys are working in Windows.

Quoted 3 lines

Hmm - so I got

[  561.809723] [ACPI Debug 64952760]  Integer 0x0000000000000000

for my Store (BSWF, Debug) call.

This is the core issue.

Quoted 6 lines

Then I had a look at the \_SB.PCI0.GFX0.LCD.BLNF () function in my ssdt7.dsl, and it sets "BSWF = Zero" as the 2nd last call. And it's the same in the ssdt6.dsl of the Haswell hardware, except there the call to BLNF is guarded by an "LGreaterEqual(OSYS, 0x07D6)" guard, so I guess for newer operating systems, all the functionality is also disabled on Haswell.

Sorry, you lost me. What functionality do you think is disabled where, specifically?

Quoted 4 lines

But BLNF also sets "AHKF |= One", which triggers this code path containing just a "Notify (\_SB.FEXT, 0x80)", but since it's actually never called, I get no notifications - how did I ever get notifications?

Quoted 5 lines

...

until I have pressed the "touchpad" button, which changes AHKF to 8 - permanently - and now I get notifications from all buttons, since all use _L11 :-(

Did you mean _L21? I assume you were talking about Skylakes above, but _L11 is not used on these.

Also, what do you mean you "get notifications from all buttons"? Please clarify.

Quoted 7 lines

So I actually never got any direct ACPI events from the brightness control, but this was just toggled because of the "touchpad" key, enabling the notifications…

And then I "instrumented" all if's by dumping the value just before the if => everything is always 0, except the permanent 8 in AHKF after pressing the "touchpad" button.

What do you mean by "everything"? Please be specific, reading ACPI code is already hard as it is. I would guess you meant BSWF, RFHF, AHKF and IRBF, but guessing will not get us far.

Quoted 3 lines

So - just for the sake of it, I had a look for some AHKF code and the button function S000 got new code to handle AHKF - both brightness (AKA BSWF AKA AHKF & One) and the touchpad (AKA AHKF & 0x08)

I think you are missing the point. The fact that BLNF always sets some bit in AHKF is meaningless, because even if you got notified about that in some manner, you still wouldn't know whether brightness is supposed to be increased or decreased. The only way ACPI code makes that distinction is using BSWF, which is apparently broken.

Quoted 4 lines

But this is just called, if you call the ACPI button function in the device driver.

Which leaves me with the problem, that BSWF is always 0.

This looks awfully like the issue I had with a Dell machine and a certain hotkey [1]. It later turned out that ACPI variables are set to different values after a certain "magical" SMBIOS call is made. Meanwhile the same hotkey worked just fine on other models without any prior initialization. The case we are looking at here might be similar, i.e. something worked on Haswells without any initialization, but Skylakes require some special call before brightness-related key presses are properly reported.

Quoted 4 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

To sum up, I see no immediate reason for brightness control not to work on Skylakes, so you will have to get your hands a bit dirty to get to the bottom of this (and it might still not yield a solution).

Quoted 4 lines

That's enough for today.

I'm quite sure Fujitsu changed the in-ACPI-HW-touchpad-disable-handling to be done by the driver.

Sorry, the above sentence does not parse for me.

Quoted 1 line

I don't know, why / how the brightness keys are working in Windows.

Perhaps this is the time to explore the Windows path after all. My guess would be brightness-related hotkeys do not work on a Windows instance with no Fujitsu-supplied software.

BTW, I did some more fiddling with _L11 on my Haswell and it seems its code run before the BSWF check is identical to that found in _L21 on Skylakes. Moreover, BSWF equals 0 before the FSMI call.

Which means
that BSWF is written to by the processor in response to an SMM call. Which in turn means we will not be able to debug why it writes 0 and not 1 or 2 without assistance from Fujitsu or a successful attempt to figure out how the Fujitsu-supplied Windows software works.

Quoted 7 lines

Quoted 6 lines

Then I had a look at the \_SB.PCI0.GFX0.LCD.BLNF () function in my ssdt7.dsl, and it sets "BSWF = Zero" as the 2nd last call. And it's the same in the ssdt6.dsl of the Haswell hardware, except there the call to BLNF is guarded by an "LGreaterEqual(OSYS, 0x07D6)" guard, so I guess for newer operating systems, all the functionality is also disabled on Haswell.

Quoted 2 lines

Sorry, you lost me. What functionality do you think is disabled where, specifically?

Probably the day was too long.

I just saw, that the code path is the same for Haswell and Skylake, if OSYS >= 0x07D6
I missed that on Haswell BSWF is not 0, when a key is pressed, wight?

Quoted 4 lines

Quoted 4 lines

But BLNF also sets "AHKF |= One", which triggers this code path containing just a "Notify (\_SB.FEXT, 0x80)", but since it's actually never called, I get no notifications - how did I ever get notifications?

Quoted 8 lines

Quoted 5 lines

...

until I have pressed the "touchpad" button, which changes AHKF to 8 - permanently - and now I get notifications from all buttons, since all use _L11 :-(

Did you mean _L21? I assume you were talking about Skylakes above, but _L11 is not used on these.

Yup.

Quoted 2 lines

Also, what do you mean you "get notifications from all buttons"? Please clarify.

All three key combinations are handled via _L21.
I originally thought that "Notify (\_SB.FEXT, 0x80)" was generated for all of them, but I was wrong.

If I don't press the touchpad key, which sets AHKF to 0x8, AHKF stays at 0, and I don't get any notify call for the brightness keys. And since AHKF is stuck to 0x8, until a driver calls the S000 function, it seemed to me, that the brightness keys generate the notify events, which they "logically" don't do.

Quoted 8 lines

Quoted 7 lines

So I actually never got any direct ACPI events from the brightness control, but this was just toggled because of the "touchpad" key, enabling the notifications…

And then I "instrumented" all if's by dumping the value just before the if => everything is always 0, except the permanent 8 in AHKF after pressing the "touchpad" button.

Quoted 3 lines

What do you mean by "everything"? Please be specific, reading ACPI code is already hard as it is. I would guess you meant BSWF, RFHF, AHKF and IRBF, but guessing will not get us far.

My _L21:

(...)

Quoted 4 lines

Quoted 2 lines

I'm quite sure Fujitsu changed the in-ACPI-HW-touchpad-disable-handling to be done by the driver.

Sorry, the above sentence does not parse for me.

I wanted to express, that currently the only conclusion I took from all the reading and testing of ACPI code snippets is, that Fujitsu moved the former touchpad disable handling from "in hardware" to "to be handled by the driver", as there is now code in the S000 function:

// Brightness
If (And (AHKF, One))
{
Or (Local0, 0x02000000, Local0)
XOr (AHKF, One, AHKF)
}

// Touchpad
If (And (AHKF, 0x08))

{
    Or (Local0, 0x04000000, Local0)
    XOr (AHKF, 0x08, AHKF)
}

So you still have to call another function from the driver to know, if the brightness level went up or down, but a key indication is there.

And they added the 0x02000000 and 0x04000000 values to the bitmask they generate when you call S000 with Arg0 = 0

Quoted 6 lines

Quoted 1 line

I don't know, why / how the brightness keys are working in Windows.

Perhaps this is the time to explore the Windows path after all. My guess would be brightness-related hotkeys do not work on a Windows instance with no Fujitsu-supplied software.

Quoted 3 lines

BTW, I did some more fiddling with _L11 on my Haswell and it seems its code run before the BSWF check is identical to that found in _L21 on Skylakes. Moreover, BSWF equals 0 before the FSMI call.

So for you the FSMI call changes the BSWF value.

Quoted 5 lines

Which means
that BSWF is written to by the processor in response to an SMM call. Which in turn means we will not be able to debug why it writes 0 and not 1 or 2 without assistance from Fujitsu or a successful attempt to figure out how the Fujitsu-supplied Windows software works.

Hmm.

So I got a reply from my vendor CC some Fujitsu persons.

They claim the non-working brightness buttons is an error in an Intel driver and they are going to contact the Linux/Ubuntu community.

I'll point them to this thread.

No news yet about the touchpad key.

Quoted 4 lines

So I got a reply from my vendor CC some Fujitsu persons.

They claim the non-working brightness buttons is an error in an Intel driver and they are going to contact the Linux/Ubuntu community.

I am not sure what the Intel driver has to do with this, but hey, who am I to tell them how their hardware works?

Quoted 1 line

I'll point them to this thread.

Please do, I will be happy to help.

Quoted 1 line

No news yet about the touchpad key.

Let me think about a patch which would support it. I will get back to you once I have actual code.

Quoted 4 lines

So I got a reply from my vendor CC some Fujitsu persons.

They claim the non-working brightness buttons is an error in an Intel driver and they are going to contact the Linux/Ubuntu community.

I am not sure what the Intel driver has to do with this, but hey, who am I to tell them how their hardware works?

Got an other call from Fujitsu. They pointed me to the i915 patchset, fixing the bug: https://www.spinics.net/lists/intel-gfx/msg98326.html

I backported the patchset to my Ubuntu Xenial i915 module, and I have working brightness keys :-)

Quoted 5 lines

Got an other call from Fujitsu. They pointed me to the i915 patchset, fixing the bug: https://www.spinics.net/lists/intel-gfx/msg98326.html

I backported the patchset to my Ubuntu Xenial i915 module, and I have working brightness keys :-)

Great! Kudos to Fujitsu for getting back to you so quickly with a working solution.

...though if you think about it, the whole thing is absolutely hideous:
an *ACPI* driver requires cooperation from a *video* driver to notify the operating system about a *key press*.

Quoted 3 lines

...though if you think about it, the whole thing is absolutely hideous:
an *ACPI* driver requires cooperation from a *video* driver to notify the operating system about a *key press*.

Yeah. On one hand I'm utterly amazed. On the other, I've seen and read about other really bizarre things which go on in the BIOSes of computers over the years, so nothing really surprises me anymore. :-)

My understanding based on this latest information is that the patch to the i915 driver fixes the brightness control on these laptops and that no changes to fujitsu-laptop are required for this. Is this correct?

As to
the touch keys, it sounds like this might be a BIOS thing to - is it?

Haswell-based Fujitsu laptops (Lifebook E734/E744/E754) have a touchpad toggle hotkey (Fn+F4) which is handled transparently to the operating
system: while an ACPI notification is sent to FUJ02B1 when Fn+F4 is pressed, touchpad state is properly toggled without any explicit support for this operation in fujitsu-laptop.
:

Skylake-based models (Lifebook E736/E746/E756) also have that hotkey, but the touchpad is not toggled transparently to the operating system. When Fn+F4 is pressed, an ACPI notification is sent to FUJ02E3. A subsequent call to S000 (FUNC_RFKILL) can be used to determine whether the touchpad toggle hotkey was pressed so that an input event can be sent to userspace.

Relevant ACPI code:

    Method (_L21, 0, NotSerialized)
    {
        ...
        If (AHKF)
        {
            Notify (\_SB.FEXT, 0x80)
        }
        ...
    }

    Method (S000, 3, Serialized)
    {
        Name (_T_0, Zero)
        Local0 = Zero
        While (One)
        {
            _T_0 = Arg0
            If (_T_0 == Zero)
            {
                Local0 |= 0x04000000
                Local0 |= 0x02000000
                Local0 |= 0x00020000
                Local0 |= 0x0200
                Local0 |= 0x0100
                Local0 |= 0x20
            }
            ElseIf (_T_0 == One)
            {
                ...
                If (AHKF & 0x08)
                {
                Local0 |= 0x04000000
                AHKF ^= 0x08
                }
                ...
            } ...
            Break
        }
        Return (Local0)
    }

Pressing Fn+F4 raises GPE 0x21 and sets bit 3 in AHKF. This in turn results in bit 26 being set in the value returned by FUNC_RFKILL called with 1 as its first argument. On Skylake-based models, bit 26 is also set in the value returned by FUNC_RFKILL called with 0 as its first argument (this value is saved in fujitsu_hotkey->rfkill_supported upon module initialization), which suggests that this bit is set on models which do not handle touchpad toggling transparently to the operating system.

Note that bit 3 is cleared in AHKF once FUNC_RFKILL is called with 1 as its first argument, which requires fujitsu-laptop to handle this hotkey in a different manner than the other, GIRB-based hotkeys: two input events (press and release) are immediately sent once Fn+F4 is pressed.

Reported-by Jan-Marek Glogowski <[email protected]>

Signed-off-by Micha?? K??pie?? <[email protected]>

---

Darren, this patch needs both an Acked-by from Jonathan and a Tested-by from Jan-Marek before merging as I do not have the hardware to test it.

 drivers/platform/x86/fujitsu-laptop.c |    9 +++++++++
 1 file changed, 9 insertions(+)

drivers/platform/x86/fujitsu-laptop.c +9 -0

index ce41bc3..ef28447 100644
@@ -1060,6 +1060,15 @@ static void acpi_fujitsu_hotkey_notify(struct acpi_device *device, u32 event)
 			}
 		}
 
+		if ((fujitsu_hotkey->rfkill_supported & BIT(26)) &&
+		    (call_fext_func(FUNC_RFKILL, 0x1, 0x0, 0x0) & BIT(26))) {
+			keycode = KEY_TOUCHPAD_TOGGLE;
+			input_report_key(input, keycode, 1);
+			input_sync(input);
+			input_report_key(input, keycode, 0);
+			input_sync(input);
+		}
+
 		break;
 	default:
 		keycode = KEY_UNKNOWN;

Signature · 1 line

1.7.10.4

Quoted 6 lines

Haswell-based Fujitsu laptops (Lifebook E734/E744/E754) have a touchpad toggle hotkey (Fn+F4) which is handled transparently to the operating
system: while an ACPI notification is sent to FUJ02B1 when Fn+F4 is pressed, touchpad state is properly toggled without any explicit support for this operation in fujitsu-laptop.
:

I am happy with the patch code once the one-line fix from Jan-Marek is included. However, given the rather non-intuitive behaviour that the patch is dealing with I wonder whether a short (2 line) comment in the code might be justified. There is otherwise no obvious reason why the touchpad button code must interact with the rf kill hardware.

Please respin the patch with the above in mind (and inlude Jan-Marek's fix).

Haswell-based Fujitsu laptops (Lifebook E734/E744/E754) have a touchpad toggle hotkey (Fn+F4) which is handled transparently to the operating
system: while an ACPI notification is sent to FUJ02B1 when Fn+F4 is pressed, touchpad state is properly toggled without any explicit support for this operation in fujitsu-laptop.

Skylake-based models (Lifebook E736/E746/E756) also have that hotkey, but the touchpad is not toggled transparently to the operating system. :

Reported-and-tested-by Jan-Marek Glogowski <[email protected]>

Signed-off-by Micha?? K??pie?? <[email protected]>

---

Changes from v1:

- added KEY_TOUCHPAD_TOGGLE to the FUJ02E3 input device's key bitmap,

- added code comment.

 drivers/platform/x86/fujitsu-laptop.c |   13 +++++++++++++
 1 file changed, 13 insertions(+)

drivers/platform/x86/fujitsu-laptop.c +13 -0

index ce41bc3..37ef75e 100644
@@ -856,6 +856,7 @@ static int acpi_fujitsu_hotkey_add(struct acpi_device *device)
 	set_bit(fujitsu->keycode3, input->keybit);
 	set_bit(fujitsu->keycode4, input->keybit);
 	set_bit(fujitsu->keycode5, input->keybit);
+	set_bit(KEY_TOUCHPAD_TOGGLE, input->keybit);
 	set_bit(KEY_UNKNOWN, input->keybit);
 
 	error = input_register_device(input);

@@ -1060,6 +1061,18 @@ static void acpi_fujitsu_hotkey_notify(struct acpi_device *device, u32 event)
 			}
 		}
 
+		/* On some models, the touchpad toggle hotkey (Fn+F4) is
+		 * handled in software; its state is queried using FUNC_RFKILL
+		 */
+		if ((fujitsu_hotkey->rfkill_supported & BIT(26)) &&
+		    (call_fext_func(FUNC_RFKILL, 0x1, 0x0, 0x0) & BIT(26))) {
+			keycode = KEY_TOUCHPAD_TOGGLE;
+			input_report_key(input, keycode, 1);
+			input_sync(input);
+			input_report_key(input, keycode, 0);
+			input_sync(input);
+		}
+
 		break;
 	default:
 		keycode = KEY_UNKNOWN;

Signature · 1 line

1.7.10.4

Haswell-based Fujitsu laptops (Lifebook E734/E744/E754) have a touchpad toggle hotkey (Fn+F4) which is handled transparently to the operating
system: while an ACPI notification is sent to FUJ02B1 when Fn+F4 is pressed, touchpad state is properly toggled without any explicit support for this operation in fujitsu-laptop.

Skylake-based models (Lifebook E736/E746/E756) also have that hotkey, but the touchpad is not toggled transparently to the operating system. When Fn+F4 is pressed, an ACPI notification is sent to FUJ02E3. A subsequent call to S000 (FUNC_RFKILL) can be used to determine whether the touchpad toggle hotkey was pressed so that an input event can be sent to userspace.

Relevant ACPI code:

    Method (_L21, 0, NotSerialized)
    {
        ...
        If (AHKF)
        {
            Notify (\_SB.FEXT, 0x80)
        }
        ...
    }

    Method (S000, 3, Serialized)
    {
        Name (_T_0, Zero)
        Local0 = Zero
        While (One)
        {
            _T_0 = Arg0
            If (_T_0 == Zero)
            {
                Local0 |= 0x04000000
                Local0 |= 0x02000000
                Local0 |= 0x00020000
                Local0 |= 0x0200
                Local0 |= 0x0100
                Local0 |= 0x20
            }
            ElseIf (_T_0 == One)
            {
                ...
                If (AHKF & 0x08)
                {
                Local0 |= 0x04000000
                AHKF ^= 0x08
                }
                ...
            } ...
            Break
        }
        Return (Local0)
    }

Pressing Fn+F4 raises GPE 0x21 and sets bit 3 in AHKF. This in turn results in bit 26 being set in the value returned by FUNC_RFKILL called with 1 as its first argument. On Skylake-based models, bit 26 is also set in the value returned by FUNC_RFKILL called with 0 as its first argument (this value is saved in fujitsu_hotkey->rfkill_supported upon module initialization), which suggests that this bit is set on models which do not handle touchpad toggling transparently to the operating system.

Note that bit 3 is cleared in AHKF once FUNC_RFKILL is called with 1 as its first argument, which requires fujitsu-laptop to handle this hotkey in a different manner than the other, GIRB-based hotkeys: two input events (press and release) are immediately sent once Fn+F4 is pressed.

Reported-and-tested-by Jan-Marek Glogowski <[email protected]>

Signed-off-by Micha?? K??pie?? <[email protected]>

---

Changes from v2:

- edited code comment so that it defines "some models" more precisely.

Changes from v1:

- added KEY_TOUCHPAD_TOGGLE to the FUJ02E3 input device's key bitmap,

- added code comment.

 drivers/platform/x86/fujitsu-laptop.c |   14 ++++++++++++++
 1 file changed, 14 insertions(+)

drivers/platform/x86/fujitsu-laptop.c +14 -0

index ce41bc3..36cd743 100644
@@ -856,6 +856,7 @@ static int acpi_fujitsu_hotkey_add(struct acpi_device *device)
 	set_bit(fujitsu->keycode3, input->keybit);
 	set_bit(fujitsu->keycode4, input->keybit);
 	set_bit(fujitsu->keycode5, input->keybit);
+	set_bit(KEY_TOUCHPAD_TOGGLE, input->keybit);
 	set_bit(KEY_UNKNOWN, input->keybit);
 
 	error = input_register_device(input);

@@ -1060,6 +1061,19 @@ static void acpi_fujitsu_hotkey_notify(struct acpi_device *device, u32 event)
 			}
 		}
 
+		/* On some models (first seen on the Skylake-based Lifebook
+		 * E736/E746/E756), the touchpad toggle hotkey (Fn+F4) is
+		 * handled in software; its state is queried using FUNC_RFKILL
+		 */
+		if ((fujitsu_hotkey->rfkill_supported & BIT(26)) &&
+		    (call_fext_func(FUNC_RFKILL, 0x1, 0x0, 0x0) & BIT(26))) {
+			keycode = KEY_TOUCHPAD_TOGGLE;
+			input_report_key(input, keycode, 1);
+			input_sync(input);
+			input_report_key(input, keycode, 0);
+			input_sync(input);
+		}
+
 		break;
 	default:
 		keycode = KEY_UNKNOWN;

Signature · 1 line

1.7.10.4

Quoted 70 lines · Micha?? K??pie??

Haswell-based Fujitsu laptops (Lifebook E734/E744/E754) have a touchpad toggle hotkey (Fn+F4) which is handled transparently to the operating
system: while an ACPI notification is sent to FUJ02B1 when Fn+F4 is pressed, touchpad state is properly toggled without any explicit support for this operation in fujitsu-laptop.

Skylake-based models (Lifebook E736/E746/E756) also have that hotkey, but the touchpad is not toggled transparently to the operating system. When Fn+F4 is pressed, an ACPI notification is sent to FUJ02E3. A subsequent call to S000 (FUNC_RFKILL) can be used to determine whether the touchpad toggle hotkey was pressed so that an input event can be sent to userspace.

Relevant ACPI code:

    Method (_L21, 0, NotSerialized)
    {
        ...
        If (AHKF)
        {
            Notify (\_SB.FEXT, 0x80)
        }
        ...
    }

    Method (S000, 3, Serialized)
    {
        Name (_T_0, Zero)
        Local0 = Zero
        While (One)
        {
            _T_0 = Arg0
            If (_T_0 == Zero)
            {
                Local0 |= 0x04000000
                Local0 |= 0x02000000
                Local0 |= 0x00020000
                Local0 |= 0x0200
                Local0 |= 0x0100
                Local0 |= 0x20
            }
            ElseIf (_T_0 == One)
            {
                ...
                If (AHKF & 0x08)
                {
                Local0 |= 0x04000000
                AHKF ^= 0x08
                }
                ...
            } ...
            Break
        }
        Return (Local0)
    }

Pressing Fn+F4 raises GPE 0x21 and sets bit 3 in AHKF. This in turn results in bit 26 being set in the value returned by FUNC_RFKILL called with 1 as its first argument. On Skylake-based models, bit 26 is also set in the value returned by FUNC_RFKILL called with 0 as its first argument (this value is saved in fujitsu_hotkey->rfkill_supported upon module initialization), which suggests that this bit is set on models which do not handle touchpad toggling transparently to the operating system.

Note that bit 3 is cleared in AHKF once FUNC_RFKILL is called with 1 as its first argument, which requires fujitsu-laptop to handle this hotkey in a different manner than the other, GIRB-based hotkeys: two input events (press and release) are immediately sent once Fn+F4 is pressed.

Quoted 2 lines

Reported-and-tested-by Jan-Marek Glogowski <[email protected]>

Signed-off-by Micha?? K??pie?? <[email protected]>

Thanks for the revision and your patience.

Acked-by Jonathan Woithe <[email protected]>

Quoted 7 lines

Quoted 3 lines

...though if you think about it, the whole thing is absolutely hideous:
an *ACPI* driver requires cooperation from a *video* driver to notify the operating system about a *key press*.

Yeah. On one hand I'm utterly amazed. On the other, I've seen and read about other really bizarre things which go on in the BIOSes of computers over the years, so nothing really surprises me anymore. :-)

Yes, I am a rookie in this field, so perhaps I simply have not seen enough weirdness yet to just get over something like this.

Quoted 3 lines

My understanding based on this latest information is that the patch to the i915 driver fixes the brightness control on these laptops and that no changes to fujitsu-laptop are required for this. Is this correct?

This is my understanding as well.

Quoted 2 lines

As to
the touch keys, it sounds like this might be a BIOS thing to - is it?

Are you referring to the "touchpad toggle" key? If you are, I will soon post a patch adding support for this key so that Jan-Marek can test it. I just need to find some time to actually write it.

Quoted 6 lines

Quoted 2 lines

As to
the touch keys, it sounds like this might be a BIOS thing to - is it?

Are you referring to the "touchpad toggle" key? If you are, I will soon post a patch adding support for this key so that Jan-Marek can test it. I just need to find some time to actually write it.

This needs a small patch. But getting the keycode into X11 seems to be impossible, as X / xev can't handle keycodes > 255 (KEY_TOUCHPAD_TOGGLE).

I'm currently running evrouter, to call a script on the event, which dis-/enables the input device using xinput.

I would definitely prefer
any HW or kernel driver solution. I couldn't find a way to map the 530 keycode to something < 255 to suit xev and skip the evrouter. Maybe Fujitsu will offer a better solution.

Quoted 7 lines

Quoted 6 lines

Quoted 2 lines

As to
the touch keys, it sounds like this might be a BIOS thing to - is it?

Are you referring to the "touchpad toggle" key? If you are, I will soon post a patch adding support for this key so that Jan-Marek can test it. I just need to find some time to actually write it.

Quoted 5 lines

This needs a small patch. But getting the keycode into X11 seems to be impossible, as X / xev can't handle keycodes > 255 (KEY_TOUCHPAD_TOGGLE).

I'm currently running evrouter, to call a script on the event, which dis-/enables the input device using xinput.

So does my patch work after the set_bit() you suggested is added? You have not explicitly stated that, so I can only guess it works.

If you really want to avoid using helper software, patch your kernel to generate a different event when Fn+F4 is pressed.

Am 27.06.2016 um 13:16 schrieb Micha?? K??pie??:

Quoted 10 lines

Quoted 9 lines

Quoted 3 lines

Are you referring to the "touchpad toggle" key? If you are, I will soon post a patch adding support for this key so that Jan-Marek can test it. I just need to find some time to actually write it.

This needs a small patch. But getting the keycode into X11 seems to be impossible, as X / xev can't handle keycodes > 255 (KEY_TOUCHPAD_TOGGLE).

I'm currently running evrouter, to call a script on the event, which dis-/enables the input device using xinput.

Quoted 2 lines

So does my patch work after the set_bit() you suggested is added? You have not explicitly stated that, so I can only guess it works.

Yup - it works.

Should I add a Tested-by to the merged version?

Am 25.06.2016 um 11:15 schrieb Michał Kępień:

Quoted 15 lines

Quoted 7 lines

Quoted 3 lines

...though if you think about it, the whole thing is absolutely hideous:
an *ACPI* driver requires cooperation from a *video* driver to notify the operating system about a *key press*.

Yeah. On one hand I'm utterly amazed. On the other, I've seen and read about other really bizarre things which go on in the BIOSes of computers over the years, so nothing really surprises me anymore. :-)

Yes, I am a rookie in this field, so perhaps I simply have not seen enough weirdness yet to just get over something like this.

Quoted 3 lines

My understanding based on this latest information is that the patch to the i915 driver fixes the brightness control on these laptops and that no changes to fujitsu-laptop are required for this. Is this correct?

Quoted 1 line

This is my understanding as well.

Yup. AFAIK the patchset registers the active output ports of the graphic chip within ACPI, and this is checked by the brightness keys EC, so if the port of the display is disabled, the keys don't work.

So no additional change is needed, as long as it just has to work in X11.

And I just realized the events are generated on key release, which feels strange, but since we don't get press and release events, stuff like auto-repeat for brightness wouldn't work.

Quoted 6 lines

Quoted 2 lines

As to
the touch keys, it sounds like this might be a BIOS thing to - is it?

Are you referring to the "touchpad toggle" key? If you are, I will soon post a patch adding support for this key so that Jan-Marek can test it. I just need to find some time to actually write it.

This needs a small patch. But getting the keycode into X11 seems to be impossible, as X / xev can't handle keycodes > 255 (KEY_TOUCHPAD_TOGGLE).

I'm currently running evrouter, to call a script on the event, which dis-/enables the input device using xinput. I would definitely prefer any HW or kernel driver solution. I couldn't find a way to map the 530 keycode to something < 255 to suit xev and skip the evrouter. Maybe Fujitsu will offer a better solution.

Regards,

Jan-Marek

Quoted 18 lines · Jan-Marek Glogowski

Am 25.06.2016 um 11:15 schrieb Michał Kępień:

Quoted 16 lines

Quoted 7 lines

Quoted 3 lines

...though if you think about it, the whole thing is absolutely hideous:
an *ACPI* driver requires cooperation from a *video* driver to notify the operating system about a *key press*.

Yeah. On one hand I'm utterly amazed. On the other, I've seen and read about other really bizarre things which go on in the BIOSes of computers over the years, so nothing really surprises me anymore. :-)

Yes, I am a rookie in this field, so perhaps I simply have not seen enough weirdness yet to just get over something like this.

Quoted 3 lines

My understanding based on this latest information is that the patch to the i915 driver fixes the brightness control on these laptops and that no changes to fujitsu-laptop are required for this. Is this correct?

This is my understanding as well.

Quoted 3 lines

Yup. AFAIK the patchset registers the active output ports of the graphic chip within ACPI, and this is checked by the brightness keys EC, so if the port of the display is disabled, the keys don't work.

I take it you refer to series at [1]. Sadly, I haven't had the time to figure out a proper solution to patch 5/5 yet. Maarten, if you have a moment of inspiration, go for it! ;)

Anyway, someone somewhere thought it's a great idea to filter out backlight key events at the firmware (possibly AML) level if the flat panel is not active. It's not a decision in in either i915 or ACPI driver. In Linux, the obvious thing to have done is to defer all such policy to userspace. Just provide the mechanism, and the userspace will figure out what to do with the keypress. Seriously, someone could have used that information to change the brightness of the *external* display. But can't have that. </rant>. So in the driver we'll just have to tell ACPI what outputs are active. That's what the patches are about.

BR,
Jani.

[1] http://mid.gmane.org/[email protected]

Quoted 26 lines

So no additional change is needed, as long as it just has to work in X11.

And I just realized the events are generated on key release, which feels strange, but since we don't get press and release events, stuff like auto-repeat for brightness wouldn't work.

Quoted 6 lines

Quoted 2 lines

As to
the touch keys, it sounds like this might be a BIOS thing to - is it?

Are you referring to the "touchpad toggle" key? If you are, I will soon post a patch adding support for this key so that Jan-Marek can test it. I just need to find some time to actually write it.

This needs a small patch. But getting the keycode into X11 seems to be impossible, as X / xev can't handle keycodes > 255 (KEY_TOUCHPAD_TOGGLE).

I'm currently running evrouter, to call a script on the event, which dis-/enables the input device using xinput. I would definitely prefer any HW or kernel driver solution. I couldn't find a way to map the 530 keycode to something < 255 to suit xev and skip the evrouter. Maybe Fujitsu will offer a better solution.

Regards,

Jan-Marek

Quoted 8 lines

Quoted 3 lines

A backlight device is available via /sys/class/backlight/intel_backlight and you can change brightness manually. AFAIK this device is provided by the i915 driver.

So perhaps the intent on other systems is to respond to the ACPI button notifications by manipulating the intel backlight hardware. If this is the case we'd need a way to do this from within the fujitsu-laptop driver in response to the buttons you've identified.

Is implementing this in the kernel really worth the effort?

I ended up using xbacklight bound (in my window manager) to the brightness hotkeys for both my Lifebook E744 and my Vostro V131, which has a royally borked ACPI backlight control implementation. It seems using userspace helpers for backlight control is the new normal [1]. Yes, you lose console brightness control; I can live with that, YMMV.

Quoted 2 lines

BTW: the debug message is a little misleading, as all of them are prefixed 'FUJ02B1', even if the ACPI event is handled by the FUJ02E3 device.

Yes, good point. The use of "FUJ02B1" (via ACPI_FUJITSU_HID) would have been for convenience and possibly dates from before FUJ02E3 support was included in the driver. A case can certainly be made for a more generic descriptor.

vdbg_printk() was introduced by 20b9373, which is the same commit that adds FUJ02E3 support, so it has been the way it is now from the start. This patch series attempts to tidy things up a bit.

 drivers/platform/x86/fujitsu-laptop.c |   12 +-----------
 1 file changed, 1 insertion(+), 11 deletions(-)

Quoted 6 lines · Micha?? K??pie??

vdbg_printk() was introduced by 20b9373, which is the same commit that adds FUJ02E3 support, so it has been the way it is now from the start. This patch series attempts to tidy things up a bit.

 drivers/platform/x86/fujitsu-laptop.c |   12 +-----------
 1 file changed, 1 insertion(+), 11 deletions(-)

Yes, good idea. Both patches look good to me. I would like to note in passing that the removal of the unused defines in the second patch was in fact suggested as part of a broader cleanup series by Alan Jenkins an embarassingly long time ago. For various reasons I didn't get a chance to review and apply his patch series at the time. It is my aim to rectify this soon, but in the meantime this two patch series is good to go in. Thanks for the submission.

Acked-by Jonathan Woithe <[email protected]>

Regards
jonathan

I recently got new Skylake hardware (e7x6) from Fujitsu. Compared to previous Haswell generation (e7x4), some of the Fn+X key combination stopped working. This includes the brightness and "touchpad dis-/enable" key combinations.

For the brightness control it's understandable, as this was handled by a ACPI device FUJ02B1, which is no longer available. I don't know how the touchpad disable key was actually working, as I don't get any scan codes or ACPI events in userspace - probably I'm missing something here.

Quoted 4 lines

I recently got new Skylake hardware (e7x6) from Fujitsu. Compared to previous Haswell generation (e7x4), some of the Fn+X key combination stopped working. This includes the brightness and "touchpad dis-/enable" key combinations.

As you used the phrase "stopped working", I'm wondering whether you were ever able to get ACPI brightness control to work on a Haswell machine? It seems to be broken on my Lifebook E744 (BIOS version 1.19): pressing the brightness keys causes acpi_fujitsu_notify() to call GBLL, which always returns the same brightness level, even though it sets the highest bit in its return value (which denotes a brightness change). Also, calling set_lcd_level() with various values causes the value subsequently returned by GBLL to change, but the actual screen brightness is identical all the time.

Quoted 4 lines

For the brightness control it's understandable, as this was handled by a ACPI device FUJ02B1, which is no longer available. I don't know how the touchpad disable key was actually working, as I don't get any scan codes or ACPI events in userspace - probably I'm missing something here.

It looks like it is handled purely in hardware because I'm not getting any scan codes or ACPI events either on a Lifebook E744 and the hotkey works correctly.

Brightness control works for me with the Fujitsu e7x4 hardware and so does the "touchpad" button. These notebooks run Ubuntu 12.04 with 14.04 HWE AKA some 3.13 kernel and KDE4. No extra configuration needed.

But: the brightness buttons just generate key events, which are evaluated inside KDE, not in a terminal or the login screen, so the actual part of the driver, which handles the LCD brightness level, isn't working - at least not the driver version in 3.13.