Some buttons on the Fujitsu u7[25]7 laptops are not working

Some buttons on the Fujitsu u7[25]7 laptops are not working

[Jan-Marek Glogowski]

Hi everybody,

I (not so) recently got new Fujitsu Skylake hardware (u7[25]7) from our HW service provider to replace the e7x6 series and finally found some time to start fixing the issues on Linux.
So just like 1 1/2 years ago some buttons don't work.

And again the brightness buttons are broken - that's on current Ubuntu Bionic AKA some 4.13 kernel, which should have all the i915 patches I backported to fix these problems for us (AKA LiMux) in 2016.

But the appended patch at least fixes the rfkill button and emits a keycode for the microphone mute button.

I'm still pondering about the microphone mute. Should this be handled like the all the other volume buttons, which seem to work without touching the fujitsu-laptop.c driver? I have no idea how these other buttons are forwarded to the sound drivers.
And I'm still wondering about the ECO button, which is still handled via FUNC 0x1002, which was previously just used for extra HW buttons.

So please have a look at my preliminary patch. I don't have the HW with me on the weekend, so won't be able to answer questions regarding the HW before Monday.

Thanks and have a nice WE

Jan-Marek

P.S. this patch not only toggles the rfkill led but correctly sets the software rfkill status (which IMHO is as important as the correct led status).
P.P.S. if someone has a good idea how to "route" the touchpad toggle key to the touchpad drivers without involving the userspace via evrouter, that would be nice too.


From 13df42d4ebaca4e72e28037694c3655480d988cd Mon Sep 17 00:00:00 2001
From: Jan-Marek Glogowski <glogow@fbihome.de>
Date: Fri, 19 Jan 2018 21:48:22 +0100
Subject: [PATCH] Emit some more button events

Seems Fujitsu continues to move HW functionality into software.
These are my observations from the U727.

Fn+F1 is now a button to mute the microphone.
Fn+F5 is now the rfkill button.
Fn+F9 is now labeled ECO and emits a FUNC 0x1002 (args 0x1, 0x0,
0x0) returned 0x40000413

So in addition to the still working KEY_TOUCHPAD_TOGGLE, we now
have to emit KEY_RFKILL for BIT(5) and KEY_MICMUTE for BIT(29).

Emitting the KEY_RFKILL will also correctly toggle the
corresponding led.
---
 fujitsu-laptop.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/fujitsu-laptop.c b/fujitsu-laptop.c
index e31ecfa..f784e89 100644
--- a/fujitsu-laptop.c
+++ b/fujitsu-laptop.c
@@ -462,6 +462,8 @@ static const struct key_entry keymap_default[] = {
        { KE_KEY, KEY4_CODE, { KEY_PROG4 } },
        { KE_KEY, KEY5_CODE, { KEY_RFKILL } },
        { KE_KEY, BIT(26),   { KEY_TOUCHPAD_TOGGLE } },
+       { KE_KEY, BIT(5),    { KEY_RFKILL } },
+       { KE_KEY, BIT(29),   { KEY_MICMUTE } },
        { KE_END, 0 }
 };

@@ -915,7 +917,7 @@ static void acpi_fujitsu_laptop_release(struct acpi_device *device)
 static void acpi_fujitsu_laptop_notify(struct acpi_device *device, u32 event)
 {
        struct fujitsu_laptop *priv = acpi_driver_data(device);
-       int scancode, i = 0;
+       int scancode, i = 0, funcret;
        unsigned int irb;

        if (event != ACPI_FUJITSU_NOTIFY_CODE1) {
@@ -949,9 +951,15 @@ static void acpi_fujitsu_laptop_notify(struct acpi_device *device, u32 event)
         * E736/E746/E756), the touchpad toggle hotkey (Fn+F4) is
         * handled in software; its state is queried using FUNC_FLAGS
         */
-       if ((priv->flags_supported & BIT(26)) &&
-           (call_fext_func(device, FUNC_FLAGS, 0x1, 0x0, 0x0) & BIT(26)))
-               sparse_keymap_report_event(priv->input, BIT(26), 1, true);
+       if (priv->flags_supported & (BIT(26) | BIT(5) | BIT(29))) {
+               funcret = call_fext_func(device, FUNC_FLAGS, 0x1, 0x0, 0x0);
+               if (funcret & BIT(29))
+                       sparse_keymap_report_event(priv->input, BIT(29), 1, true);
+               else if (funcret & BIT(26))
+                       sparse_keymap_report_event(priv->input, BIT(26), 1, true);
+               else if (funcret & BIT(5))
+                       sparse_keymap_report_event(priv->input, BIT(5), 1, true);
+       }
 }

 /* Initialization */
-- 
2.7.4

Re: Some buttons on the Fujitsu u7[25]7 laptops are not working

[Jonathan Woithe]

Hi Jan-Marek

On Fri, Jan 19, 2018 at 11:40:11PM +0100, Jan-Marek Glogowski wrote:
> I (not so) recently got new Fujitsu Skylake hardware (u7[25]7) from our HW
> service provider to replace the e7x6 series and finally found some time to
> start fixing the issues on Linux.  So just like 1 1/2 years ago some
> buttons don't work.
> 
> And again the brightness buttons are broken - that's on current Ubuntu
> Bionic AKA some 4.13 kernel, which should have all the i915 patches I
> backported to fix these problems for us (AKA LiMux) in 2016.
> 
> But the appended patch at least fixes the rfkill button and emits a
> keycode for the microphone mute button.
> 
> I'm still pondering about the microphone mute.  Should this be handled
> like the all the other volume buttons, which seem to work without touching
> the fujitsu-laptop.c driver?  I have no idea how these other buttons are
> forwarded to the sound drivers.  And I'm still wondering about the ECO
> button, which is still handled via FUNC 0x1002, which was previously just
> used for extra HW buttons.

Regarding the volume buttons, as you have observed fujitsu-laptop hasn't
ever had to deal with them before.  On the Fujitsu hardware I have access to
the volume and mute buttons are handled through the standard ACPI subsystem:
fujitsu-laptop doesn't play any part.  The ACPI actions generated are
"volumeup", "volumedown" and "mute".  These can be bound to userspace mixer
tools to effect the desired outcome.

Does your new hardware emit keycodes for the volume buttons (which would
presumedly be picked up by ACPI)?  If so it's a bit odd that they'd include
this functionality and yet leave the mute out of it.  Still, if that's what
they've done then that's what we have to work with.

I guess the question is whether it is necessary to add the mute handling to
fujitsu-laptop, or whether a more appropriate change is to allow APCI to
handle it natively.  That in turn comes down to what the hardware can
actually do.

> So please have a look at my preliminary patch.  I don't have the HW with
> me on the weekend, so won't be able to answer questions regarding the HW
> before Monday.

I would be interested to read Michel's take on the apparent need for these
changes too.

> P.S.  this patch not only toggles the rfkill led but correctly sets the
> software rfkill status (which IMHO is as important as the correct led
> status).

Agreed.

> P.P.S.  if someone has a good idea how to "route" the touchpad toggle key
> to the touchpad drivers without involving the userspace via evrouter, that
> would be nice too.

Sorry, I can't help with that.

> From: Jan-Marek Glogowski <glogow@fbihome.de>
> Date: Fri, 19 Jan 2018 21:48:22 +0100
> Subject: [PATCH] Emit some more button events
> 
> Seems Fujitsu continues to move HW functionality into software.
> These are my observations from the U727.
> 
> Fn+F1 is now a button to mute the microphone.
> Fn+F5 is now the rfkill button.
> Fn+F9 is now labeled ECO and emits a FUNC 0x1002 (args 0x1, 0x0,
> 0x0) returned 0x40000413

For reference, on the S7020 F1 and F5 have no "Fn" function while F9 is
"volume up.  There is no ambiguity regarding F1 and F5 at least with this
hardware so this patch shouldn't create conflict there.  If the newly moved
ECO function were to be hooked it would probably need to be done dependent
on model.

> So in addition to the still working KEY_TOUCHPAD_TOGGLE, we now
> have to emit KEY_RFKILL for BIT(5) and KEY_MICMUTE for BIT(29).
> 
> Emitting the KEY_RFKILL will also correctly toggle the
> corresponding led.
> ---
>  fujitsu-laptop.c | 16 ++++++++++++----
>  1 file changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/fujitsu-laptop.c b/fujitsu-laptop.c
> index e31ecfa..f784e89 100644
> --- a/fujitsu-laptop.c
> +++ b/fujitsu-laptop.c
> @@ -462,6 +462,8 @@ static const struct key_entry keymap_default[] = {
>         { KE_KEY, KEY4_CODE, { KEY_PROG4 } },
>         { KE_KEY, KEY5_CODE, { KEY_RFKILL } },
>         { KE_KEY, BIT(26),   { KEY_TOUCHPAD_TOGGLE } },
> +       { KE_KEY, BIT(5),    { KEY_RFKILL } },
> +       { KE_KEY, BIT(29),   { KEY_MICMUTE } },
>         { KE_END, 0 }
>  };
> 
> @@ -915,7 +917,7 @@ static void acpi_fujitsu_laptop_release(struct acpi_device *device)
>  static void acpi_fujitsu_laptop_notify(struct acpi_device *device, u32 event)
>  {
>         struct fujitsu_laptop *priv = acpi_driver_data(device);
> -       int scancode, i = 0;
> +       int scancode, i = 0, funcret;
>         unsigned int irb;
> 
>         if (event != ACPI_FUJITSU_NOTIFY_CODE1) {
> @@ -949,9 +951,15 @@ static void acpi_fujitsu_laptop_notify(struct acpi_device *device, u32 event)
>          * E736/E746/E756), the touchpad toggle hotkey (Fn+F4) is
>          * handled in software; its state is queried using FUNC_FLAGS
>          */
> -       if ((priv->flags_supported & BIT(26)) &&
> -           (call_fext_func(device, FUNC_FLAGS, 0x1, 0x0, 0x0) & BIT(26)))
> -               sparse_keymap_report_event(priv->input, BIT(26), 1, true);
> +       if (priv->flags_supported & (BIT(26) | BIT(5) | BIT(29))) {
> +               funcret = call_fext_func(device, FUNC_FLAGS, 0x1, 0x0, 0x0);
> +               if (funcret & BIT(29))
> +                       sparse_keymap_report_event(priv->input, BIT(29), 1, true);
> +               else if (funcret & BIT(26))
> +                       sparse_keymap_report_event(priv->input, BIT(26), 1, true);
> +               else if (funcret & BIT(5))
> +                       sparse_keymap_report_event(priv->input, BIT(5), 1, true);
> +       }
>  }

This looks reaonable to me.  However, I'm wondering whether the "else if"
construct is the right thing to use here.  If it were possible for the
hardware to flag more than one of these buttons at once then "funcret"
will obviously have more than one of the bits set.  The code above would
only report the key corresponding to the highest set bit.

Previously we only had to handle a single key so we have no prior experience
to draw on.

Regards
  jonathan

Re: Some buttons on the Fujitsu u7[25]7 laptops are not working

[Jan-Marek Glogowski]

Hi Jonathan,

Am 20.01.2018 um 00:45 schrieb Jonathan Woithe:
> On Fri, Jan 19, 2018 at 11:40:11PM +0100, Jan-Marek Glogowski wrote:
>> I'm still pondering about the microphone mute.  Should this be handled
>> like the all the other volume buttons, which seem to work without touching
>> the fujitsu-laptop.c driver?  I have no idea how these other buttons are
>> forwarded to the sound drivers.  And I'm still wondering about the ECO
>> button, which is still handled via FUNC 0x1002, which was previously just
>> used for extra HW buttons.
> 
> Regarding the volume buttons, as you have observed fujitsu-laptop hasn't
> ever had to deal with them before.  On the Fujitsu hardware I have access to
> the volume and mute buttons are handled through the standard ACPI subsystem:
> fujitsu-laptop doesn't play any part.  The ACPI actions generated are
> "volumeup", "volumedown" and "mute".  These can be bound to userspace mixer
> tools to effect the desired outcome.
> 
> Does your new hardware emit keycodes for the volume buttons (which would
> presumedly be picked up by ACPI)?  If so it's a bit odd that they'd include
> this functionality and yet leave the mute out of it.  Still, if that's what
> they've done then that's what we have to work with.

It does. Normal volume keys are handled by the keyboard driver, so probably some userspace program handles this.

> I guess the question is whether it is necessary to add the mute handling to
> fujitsu-laptop, or whether a more appropriate change is to allow APCI to
> handle it natively.  That in turn comes down to what the hardware can
> actually do.

???

>> From: Jan-Marek Glogowski <glogow@fbihome.de>
>> Date: Fri, 19 Jan 2018 21:48:22 +0100
>> Subject: [PATCH] Emit some more button events
>>
>> Seems Fujitsu continues to move HW functionality into software.
>> These are my observations from the U727.
>>
>> Fn+F1 is now a button to mute the microphone.
>> Fn+F5 is now the rfkill button.
>> Fn+F9 is now labeled ECO and emits a FUNC 0x1002 (args 0x1, 0x0,
>> 0x0) returned 0x40000413
> 
> For reference, on the S7020 F1 and F5 have no "Fn" function while F9 is
> "volume up.  There is no ambiguity regarding F1 and F5 at least with this
> hardware so this patch shouldn't create conflict there.  If the newly moved
> ECO function were to be hooked it would probably need to be done dependent
> on model.
> 
>> So in addition to the still working KEY_TOUCHPAD_TOGGLE, we now
>> have to emit KEY_RFKILL for BIT(5) and KEY_MICMUTE for BIT(29).
>>
>> Emitting the KEY_RFKILL will also correctly toggle the
>> corresponding led.
>> ---
>>  fujitsu-laptop.c | 16 ++++++++++++----
>>  1 file changed, 12 insertions(+), 4 deletions(-)
>>
>> diff --git a/fujitsu-laptop.c b/fujitsu-laptop.c
>> index e31ecfa..f784e89 100644
>> --- a/fujitsu-laptop.c
>> +++ b/fujitsu-laptop.c
>> @@ -462,6 +462,8 @@ static const struct key_entry keymap_default[] = {
>>         { KE_KEY, KEY4_CODE, { KEY_PROG4 } },
>>         { KE_KEY, KEY5_CODE, { KEY_RFKILL } },
>>         { KE_KEY, BIT(26),   { KEY_TOUCHPAD_TOGGLE } },
>> +       { KE_KEY, BIT(5),    { KEY_RFKILL } },
>> +       { KE_KEY, BIT(29),   { KEY_MICMUTE } },
>>         { KE_END, 0 }
>>  };
>>
>> @@ -915,7 +917,7 @@ static void acpi_fujitsu_laptop_release(struct acpi_device *device)
>>  static void acpi_fujitsu_laptop_notify(struct acpi_device *device, u32 event)
>>  {
>>         struct fujitsu_laptop *priv = acpi_driver_data(device);
>> -       int scancode, i = 0;
>> +       int scancode, i = 0, funcret;
>>         unsigned int irb;
>>
>>         if (event != ACPI_FUJITSU_NOTIFY_CODE1) {
>> @@ -949,9 +951,15 @@ static void acpi_fujitsu_laptop_notify(struct acpi_device *device, u32 event)
>>          * E736/E746/E756), the touchpad toggle hotkey (Fn+F4) is
>>          * handled in software; its state is queried using FUNC_FLAGS
>>          */
>> -       if ((priv->flags_supported & BIT(26)) &&
>> -           (call_fext_func(device, FUNC_FLAGS, 0x1, 0x0, 0x0) & BIT(26)))
>> -               sparse_keymap_report_event(priv->input, BIT(26), 1, true);
>> +       if (priv->flags_supported & (BIT(26) | BIT(5) | BIT(29))) {
>> +               funcret = call_fext_func(device, FUNC_FLAGS, 0x1, 0x0, 0x0);
>> +               if (funcret & BIT(29))
>> +                       sparse_keymap_report_event(priv->input, BIT(29), 1, true);
>> +               else if (funcret & BIT(26))
>> +                       sparse_keymap_report_event(priv->input, BIT(26), 1, true);
>> +               else if (funcret & BIT(5))
>> +                       sparse_keymap_report_event(priv->input, BIT(5), 1, true);
>> +       }
>>  }
> 
> This looks reaonable to me.  However, I'm wondering whether the "else if"
> construct is the right thing to use here.  If it were possible for the
> hardware to flag more than one of these buttons at once then "funcret"
> will obviously have more than one of the bits set.  The code above would
> only report the key corresponding to the highest set bit.

I'll change that.

> Previously we only had to handle a single key so we have no prior experience
> to draw on.

So I've continued playing with the HW:

# libinput debug-events 
-event6   DEVICE_ADDED     Fujitsu FUJ02E3                   seat0 default group1  cap:k
-event3   DEVICE_ADDED     Video Bus                         seat0 default group2  cap:k
-event0   DEVICE_ADDED     Power Button                      seat0 default group3  cap:k
-event1   DEVICE_ADDED     Lid Switch                        seat0 default group4  cap:S
-event4   DEVICE_ADDED     Generic USB Audio                 seat0 default group5  cap:kp scroll-nat
-event13  DEVICE_ADDED     FJ Camera: FJ Camera              seat0 default group6  cap:k
-event7   DEVICE_ADDED     HDA Intel PCH Headphone           seat0 default group7  cap:
-event8   DEVICE_ADDED     HDA Intel PCH HDMI/DP,pcm=3       seat0 default group7  cap:
-event9   DEVICE_ADDED     HDA Intel PCH HDMI/DP,pcm=7       seat0 default group7  cap:
-event10  DEVICE_ADDED     HDA Intel PCH HDMI/DP,pcm=8       seat0 default group7  cap:
-event11  DEVICE_ADDED     HDA Intel PCH HDMI/DP,pcm=9       seat0 default group7  cap:
-event12  DEVICE_ADDED     HDA Intel PCH HDMI/DP,pcm=10      seat0 default group7  cap:
-event2   DEVICE_ADDED     AT Translated Set 2 keyboard      seat0 default group8  cap:k
-event5   DEVICE_ADDED     ETPS/2 Elantech Touchpad          seat0 default group9  cap:pg  size 94x43mm tap(dl off) left scroll-nat scroll-2fg-edge dwt-on
-event6   KEYBOARD_KEY      +6.84s      KEY_MICMUTE (248) pressed
 event6   KEYBOARD_KEY      +6.84s      KEY_MICMUTE (248) released
-event2   KEYBOARD_KEY      +8.05s      KEY_MUTE (113) pressed
 event2   KEYBOARD_KEY      +8.22s      KEY_MUTE (113) released
 event2   KEYBOARD_KEY      +8.94s      KEY_VOLUMEDOWN (114) pressed
 event2   KEYBOARD_KEY      +9.09s      KEY_VOLUMEDOWN (114) released
 event2   KEYBOARD_KEY      +9.91s      KEY_VOLUMEUP (115) pressed
 event2   KEYBOARD_KEY     +10.06s      KEY_VOLUMEUP (115) released
-event6   KEYBOARD_KEY     +10.91s      KEY_RFKILL (247) pressed
 event6   KEYBOARD_KEY     +10.91s      KEY_RFKILL (247) released
 event6   KEYBOARD_KEY     +12.97s      KEY_TOUCHPAD_TOGGLE (530) pressed
 event6   KEYBOARD_KEY     +12.97s      KEY_TOUCHPAD_TOGGLE (530) released
-event3   KEYBOARD_KEY     +14.04s      KEY_BRIGHTNESSDOWN (224) pressed
 event3   KEYBOARD_KEY     +14.04s      KEY_BRIGHTNESSDOWN (224) released
 event3   KEYBOARD_KEY     +17.41s      KEY_BRIGHTNESSUP (225) pressed
 event3   KEYBOARD_KEY     +17.41s      KEY_BRIGHTNESSUP (225) released
-event6   KEYBOARD_KEY     +18.31s      KEY_PROG4 (203) pressed
-event2   KEYBOARD_KEY     +21.58s      KEY_LEFTMETA (125) pressed
 event2   KEYBOARD_KEY     +21.61s      *** (-1) pressed
 event2   KEYBOARD_KEY     +21.64s      *** (-1) released
 event2   KEYBOARD_KEY     +21.68s      KEY_LEFTMETA (125) released

These are Fn+F1 - Fn+F10

The last event2 is the "Switch output" button.

The main remaining problem is the missing release event for the ECO / KEY_PROG4.
Like all buttons the ACPI events are generated on release.
When releasing the button it, this results in:

[Mo Jan 22 08:37:09 2018] ACPI: \_SB_.FEXT: fujitsu_laptop: FUNC 0x1000 (args 0x4, 0x0, 0x0) returned 0x320
[Mo Jan 22 08:37:09 2018] ACPI: \_SB_.FEXT: fujitsu_laptop: Flags state     0x00000320
[Mo Jan 22 08:37:09 2018] ACPI: \_SB_.FEXT: fujitsu_laptop: FUNC 0x1002 (args 0x1, 0x0, 0x0) returned 0x40000413
[Mo Jan 22 08:37:09 2018] input input21: Push scancode into ringbuffer [0x413]
[Mo Jan 22 08:37:09 2018] ACPI: \_SB_.FEXT: fujitsu_laptop: FUNC 0x1002 (args 0x1, 0x0, 0x0) returned 0x0
[Mo Jan 22 08:37:09 2018] ACPI: \_SB_.FEXT: fujitsu_laptop: FUNC 0x1000 (args 0x1, 0x0, 0x0) returned 0x0

I don't know yet how to distinguish between a separate ECO button and the Fn button here.
Have to recheck with the old HW to see, if some support flags are different now. The button is definitely not in the BTNI mask:

[Mo Jan 22 08:29:02 2018] input: Fujitsu FUJ02E3 as /devices/LNXSYSTM:00/LNXSYBUS:00/FUJ02E3:00/input/input21
[Mo Jan 22 08:29:02 2018] fujitsu_laptop: ACPI: Fujitsu FUJ02E3 [FEXT]
[Mo Jan 22 08:29:02 2018] ACPI: \_SB_.FEXT: Flags supported 0x26020320
[Mo Jan 22 08:29:02 2018] ACPI: \_SB_.FEXT: BTNI: [0x10001]

Then there is the "radios" attribute, which is currently inverted for me. It contains "killed", if the radio is on and "on", if it's killed.

And pressing the brightness-up or -down buttons doesn't change the backlight in KDE5.
Guess I'm facing the "Xorg modeset = no backlight" problem everyone has (since 2016-06): https://bugs.freedesktop.org/show_bug.cgi?id=96572

> Regards
Jan-Marek

[PATCH][RfC] Some buttons on the Fujitsu u7[25]7 laptops are not working

[Jan-Marek Glogowski]

Hi everybody,

I'm replying to myself, so it's easier to follow the thread.
Finally I had some more time to look into the key event problems.

Am 22.01.2018 um 11:16 schrieb Jan-Marek Glogowski:
>> Does your new hardware emit keycodes for the volume buttons (which would
>> presumedly be picked up by ACPI)?  If so it's a bit odd that they'd include
>> this functionality and yet leave the mute out of it.  Still, if that's what
>> they've done then that's what we have to work with.
> 
> It does. Normal volume keys are handled by the keyboard driver, so probably some userspace program handles this.
> 
>> I guess the question is whether it is necessary to add the mute handling to
>> fujitsu-laptop, or whether a more appropriate change is to allow APCI to
>> handle it natively.  That in turn comes down to what the hardware can
>> actually do.

I'm still not following this. What you mean by "what the hardware can do"?

> The main remaining problem is the missing release event for the ECO / KEY_PROG4.
> Like all buttons the ACPI events are generated on release.
> When releasing the button it, this results in:
> 
> [Mo Jan 22 08:37:09 2018] ACPI: \_SB_.FEXT: fujitsu_laptop: FUNC 0x1000 (args 0x4, 0x0, 0x0) returned 0x320
> [Mo Jan 22 08:37:09 2018] ACPI: \_SB_.FEXT: fujitsu_laptop: Flags state     0x00000320
> [Mo Jan 22 08:37:09 2018] ACPI: \_SB_.FEXT: fujitsu_laptop: FUNC 0x1002 (args 0x1, 0x0, 0x0) returned 0x40000413
> [Mo Jan 22 08:37:09 2018] input input21: Push scancode into ringbuffer [0x413]
> [Mo Jan 22 08:37:09 2018] ACPI: \_SB_.FEXT: fujitsu_laptop: FUNC 0x1002 (args 0x1, 0x0, 0x0) returned 0x0
> [Mo Jan 22 08:37:09 2018] ACPI: \_SB_.FEXT: fujitsu_laptop: FUNC 0x1000 (args 0x1, 0x0, 0x0) returned 0x0
> 
> I don't know yet how to distinguish between a separate ECO button and the Fn button here.
> Have to recheck with the old HW to see, if some support flags are different now. The button is definitely not in the BTNI mask:

For the new u757 I get:
> [259964.060356] fujitsu_laptop: Flags supported: 0x26020320
> [259964.065143] fujitsu_laptop: BTNI: [0x10001]

For the old e736 I get:
> [ 3030.845786] fujitsu_laptop: Flag supported: 0x6020320
> [ 3030.850631] fujitsu_laptop: BTNI: [0x1010001]

BTNI difference seems to be the change from an RFKILL button to function key, but that is just a guess. The difference is actually two "button to key" changes, but since ECO still emits a button press event, maybe that's the single bit.
And I realized we never use the value from BTNI, except when deciding to register the "fujitsu::kblamps" led, FWIW.

> And pressing the brightness-up or -down buttons doesn't change the backlight in KDE5.
> Guess I'm facing the "Xorg modeset = no backlight" problem everyone has (since 2016-06): https://bugs.freedesktop.org/show_bug.cgi?id=96572

I fixed this for me (4.4 Ubuntu kernel) by using the old CADL patchset backported for 4.4 from Jani Nikular. The link is just an reference, as I have four patches from the original development: https://lists.freedesktop.org/archives/intel-gfx/2016-August/105351.html

Then I need some additional HDA pin quirks for the headset microphone: http://mailman.alsa-project.org/pipermail/alsa-devel/2018-January/131049.html

And I'll hopefully get a "rfkill-any" backport into Ubuntu 4.4: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1745130

I asked Fujitsu (via our supplier) if they can provide some specs for all this ACPI handling. No answer yet.

Sorry for the delay,
thanks for the reviews,
comments welcome,

Jan-Marek

----

From e599b80cc23810cad7837b71cdc3dba0a5334443 Mon Sep 17 00:00:00 2001
From: Jan-Marek Glogowski <glogow@fbihome.de>
Date: Fri, 19 Jan 2018 21:48:22 +0100
Subject: [PATCH] Emit MICMUTE and RFKILL key events

Seems Fujitsu continues to move HW functionality into software.
These are my observations from the U727 and U757.

Fn+F1 is now a button to mute the microphone.
Fn+F5 is now the rfkill button.
Fn+F9 is now labeled ECO and emits a FUNC 0x1002 (args 0x1, 0x0,
0x0) returned 0x40000413

So in addition to the still working KEY_TOUCHPAD_TOGGLE, we now
have to emit KEY_RFKILL for BIT(5) and KEY_MICMUTE for BIT(29).

Emitting the KEY_RFKILL will also correctly toggles the
corresponding led.

Signed-of-by: Jan-Marek Glogowski <glogow@fbihome.de>
---
 drivers/platform/x86/fujitsu-laptop.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/platform/x86/fujitsu-laptop.c b/drivers/platform/x86/fujitsu-laptop.c
index 2cfbd3f..088cc10 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -455,7 +455,9 @@ static const struct key_entry keymap_default[] = {
 	{ KE_KEY, KEY3_CODE, { KEY_PROG3 } },
 	{ KE_KEY, KEY4_CODE, { KEY_PROG4 } },
 	{ KE_KEY, KEY5_CODE, { KEY_RFKILL } },
+	{ KE_KEY, BIT(5),    { KEY_RFKILL } },
 	{ KE_KEY, BIT(26),   { KEY_TOUCHPAD_TOGGLE } },
+	{ KE_KEY, BIT(29),   { KEY_MICMUTE } },
 	{ KE_END, 0 }
 };
 
@@ -899,7 +901,7 @@ static void acpi_fujitsu_laptop_release(struct acpi_device *device)
 static void acpi_fujitsu_laptop_notify(struct acpi_device *device, u32 event)
 {
 	struct fujitsu_laptop *priv = acpi_driver_data(device);
-	int scancode, i = 0;
+	int scancode, i = 0, funcret;
 	unsigned int irb;
 
 	if (event != ACPI_FUJITSU_NOTIFY_CODE1) {
@@ -930,9 +932,15 @@ static void acpi_fujitsu_laptop_notify(struct acpi_device *device, u32 event)
 	 * E736/E746/E756), the touchpad toggle hotkey (Fn+F4) is
 	 * handled in software; its state is queried using FUNC_FLAGS
 	 */
-	if ((priv->flags_supported & BIT(26)) &&
-	    (call_fext_func(device, FUNC_FLAGS, 0x1, 0x0, 0x0) & BIT(26)))
-		sparse_keymap_report_event(priv->input, BIT(26), 1, true);
+	if (priv->flags_supported & (BIT(5) | BIT(26) | BIT(29))) {
+		funcret = call_fext_func(device, FUNC_FLAGS, 0x1, 0x0, 0x0);
+		if (funcret & BIT(5))
+			sparse_keymap_report_event(priv->input, BIT(5), 1, true);
+		if (funcret & BIT(26))
+			sparse_keymap_report_event(priv->input, BIT(26), 1, true);
+		if (funcret & BIT(29))
+			sparse_keymap_report_event(priv->input, BIT(29), 1, true);
+	}
 }
 
 /* Initialization */
-- 
2.1.4

Re: [PATCH][RfC] Some buttons on the Fujitsu u7[25]7 laptops are not working

[Jonathan Woithe]

On Fri, Feb 09, 2018 at 12:02:57PM +0100, Jan-Marek Glogowski wrote:
> Am 22.01.2018 um 11:16 schrieb Jan-Marek Glogowski:
> >> Does your new hardware emit keycodes for the volume buttons (which would
> >> presumedly be picked up by ACPI)?  If so it's a bit odd that they'd include
> >> this functionality and yet leave the mute out of it.  Still, if that's what
> >> they've done then that's what we have to work with.
> > 
> > It does. Normal volume keys are handled by the keyboard driver, so probably some userspace program handles this.
> > 
> >> I guess the question is whether it is necessary to add the mute handling to
> >> fujitsu-laptop, or whether a more appropriate change is to allow APCI to
> >> handle it natively.  That in turn comes down to what the hardware can
> >> actually do.
> 
> I'm still not following this. What you mean by "what the hardware can do"?

It's just a comment about how the mute button should be handled.  Since ACPI
appears to already handle the volume function without kernel intervention,
the question is whether it could also handle the mute function.  One would
be tempted to conclude that it can't or else the button events would already
be passed through (as are the volume buttons), but history has shown that
this may not necessarily be the case.

> > The main remaining problem is the missing release event for the ECO / KEY_PROG4.
> > Like all buttons the ACPI events are generated on release.
> > When releasing the button it, this results in:
> > 
> > [Mo Jan 22 08:37:09 2018] ACPI: \_SB_.FEXT: fujitsu_laptop: FUNC 0x1000 (args 0x4, 0x0, 0x0) returned 0x320
> > [Mo Jan 22 08:37:09 2018] ACPI: \_SB_.FEXT: fujitsu_laptop: Flags state     0x00000320
> > [Mo Jan 22 08:37:09 2018] ACPI: \_SB_.FEXT: fujitsu_laptop: FUNC 0x1002 (args 0x1, 0x0, 0x0) returned 0x40000413
> > [Mo Jan 22 08:37:09 2018] input input21: Push scancode into ringbuffer [0x413]
> > [Mo Jan 22 08:37:09 2018] ACPI: \_SB_.FEXT: fujitsu_laptop: FUNC 0x1002 (args 0x1, 0x0, 0x0) returned 0x0
> > [Mo Jan 22 08:37:09 2018] ACPI: \_SB_.FEXT: fujitsu_laptop: FUNC 0x1000 (args 0x1, 0x0, 0x0) returned 0x0
> > 
> > I don't know yet how to distinguish between a separate ECO button and the Fn button here.
> > Have to recheck with the old HW to see, if some support flags are different now. The button is definitely not in the BTNI mask:
> 
> For the new u757 I get:
> > [259964.060356] fujitsu_laptop: Flags supported: 0x26020320
> > [259964.065143] fujitsu_laptop: BTNI: [0x10001]
> 
> For the old e736 I get:
> > [ 3030.845786] fujitsu_laptop: Flag supported: 0x6020320
> > [ 3030.850631] fujitsu_laptop: BTNI: [0x1010001]
> 
> BTNI difference seems to be the change from an RFKILL button to function
> key, but that is just a guess.  The difference is actually two "button to
> key" changes, but since ECO still emits a button press event, maybe that's
> the single bit.

I cannot be sure since I only have a single example of Fujitsu hardware to
work with.  It seems entirely feasible that the bit change in BTNI is due to
the loss of the RFKILL button as a dedicated button.

> And I realized we never use the value from BTNI, except when deciding to
> register the "fujitsu::kblamps" led, FWIW.

It's useful for that purpose.

> > And pressing the brightness-up or -down buttons doesn't change the backlight in KDE5.
> > Guess I'm facing the "Xorg modeset = no backlight" problem everyone has (since 2016-06): https://bugs.freedesktop.org/show_bug.cgi?id=96572
> 
> I fixed this for me (4.4 Ubuntu kernel) by using the old CADL patchset
> backported for 4.4 from Jani Nikular.  The link is just an reference, as I
> have four patches from the original development:
> https://lists.freedesktop.org/archives/intel-gfx/2016-August/105351.html
> 
> Then I need some additional HDA pin quirks for the headset microphone:
> http://mailman.alsa-project.org/pipermail/alsa-devel/2018-January/131049.html
> 
> And I'll hopefully get a "rfkill-any" backport into Ubuntu 4.4:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1745130

So where does this leave us with fujitsu-laptop?  I *think* the backlight
issue is beyond our control.  Is that your take on the subject?

> >From e599b80cc23810cad7837b71cdc3dba0a5334443 Mon Sep 17 00:00:00 2001
> From: Jan-Marek Glogowski <glogow@fbihome.de>
> Date: Fri, 19 Jan 2018 21:48:22 +0100
> Subject: [PATCH] Emit MICMUTE and RFKILL key events
> 
> Seems Fujitsu continues to move HW functionality into software.
> These are my observations from the U727 and U757.
> 
> Fn+F1 is now a button to mute the microphone.
> Fn+F5 is now the rfkill button.
> Fn+F9 is now labeled ECO and emits a FUNC 0x1002 (args 0x1, 0x0,
> 0x0) returned 0x40000413
> 
> So in addition to the still working KEY_TOUCHPAD_TOGGLE, we now
> have to emit KEY_RFKILL for BIT(5) and KEY_MICMUTE for BIT(29).
> 
> Emitting the KEY_RFKILL will also correctly toggles the
> corresponding led.
> 
> Signed-of-by: Jan-Marek Glogowski <glogow@fbihome.de>
> ---
>  drivers/platform/x86/fujitsu-laptop.c | 16 ++++++++++++----
>  1 file changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/platform/x86/fujitsu-laptop.c b/drivers/platform/x86/fujitsu-laptop.c
> index 2cfbd3f..088cc10 100644
> --- a/drivers/platform/x86/fujitsu-laptop.c
> +++ b/drivers/platform/x86/fujitsu-laptop.c
> @@ -455,7 +455,9 @@ static const struct key_entry keymap_default[] = {
>  	{ KE_KEY, KEY3_CODE, { KEY_PROG3 } },
>  	{ KE_KEY, KEY4_CODE, { KEY_PROG4 } },
>  	{ KE_KEY, KEY5_CODE, { KEY_RFKILL } },
> +	{ KE_KEY, BIT(5),    { KEY_RFKILL } },
>  	{ KE_KEY, BIT(26),   { KEY_TOUCHPAD_TOGGLE } },
> +	{ KE_KEY, BIT(29),   { KEY_MICMUTE } },
>  	{ KE_END, 0 }
>  };
>  
> @@ -899,7 +901,7 @@ static void acpi_fujitsu_laptop_release(struct acpi_device *device)
>  static void acpi_fujitsu_laptop_notify(struct acpi_device *device, u32 event)
>  {
>  	struct fujitsu_laptop *priv = acpi_driver_data(device);
> -	int scancode, i = 0;
> +	int scancode, i = 0, funcret;
>  	unsigned int irb;
>  
>  	if (event != ACPI_FUJITSU_NOTIFY_CODE1) {
> @@ -930,9 +932,15 @@ static void acpi_fujitsu_laptop_notify(struct acpi_device *device, u32 event)
>  	 * E736/E746/E756), the touchpad toggle hotkey (Fn+F4) is
>  	 * handled in software; its state is queried using FUNC_FLAGS
>  	 */
> -	if ((priv->flags_supported & BIT(26)) &&
> -	    (call_fext_func(device, FUNC_FLAGS, 0x1, 0x0, 0x0) & BIT(26)))
> -		sparse_keymap_report_event(priv->input, BIT(26), 1, true);
> +	if (priv->flags_supported & (BIT(5) | BIT(26) | BIT(29))) {
> +		funcret = call_fext_func(device, FUNC_FLAGS, 0x1, 0x0, 0x0);
> +		if (funcret & BIT(5))
> +			sparse_keymap_report_event(priv->input, BIT(5), 1, true);
> +		if (funcret & BIT(26))
> +			sparse_keymap_report_event(priv->input, BIT(26), 1, true);
> +		if (funcret & BIT(29))
> +			sparse_keymap_report_event(priv->input, BIT(29), 1, true);
> +	}
>  }
>  
>  /* Initialization */

With the minor changes in place I do not think this patch will cause any
regressions for other Fujitsu systems since it is only adding meaning to
bits of the flags_supported field, and older system do not have those bits
set.  Any comments Michel?

Reviewed-by: Jonathan Woithe <jwoithe@just42.net>

Regards
  jonathan

Re: [PATCH][RfC] Some buttons on the Fujitsu u7[25]7 laptops are not working

[Jan-Marek Glogowski]

Am 09.02.2018 um 12:31 schrieb Jonathan Woithe:
> On Fri, Feb 09, 2018 at 12:02:57PM +0100, Jan-Marek Glogowski wrote:
>> Am 22.01.2018 um 11:16 schrieb Jan-Marek Glogowski:
>>> The main remaining problem is the missing release event for the ECO / KEY_PROG4.
>>> Like all buttons the ACPI events are generated on release.
>>> When releasing the button it, this results in:
>>>
>>> [Mo Jan 22 08:37:09 2018] ACPI: \_SB_.FEXT: fujitsu_laptop: FUNC 0x1000 (args 0x4, 0x0, 0x0) returned 0x320
>>> [Mo Jan 22 08:37:09 2018] ACPI: \_SB_.FEXT: fujitsu_laptop: Flags state     0x00000320
>>> [Mo Jan 22 08:37:09 2018] ACPI: \_SB_.FEXT: fujitsu_laptop: FUNC 0x1002 (args 0x1, 0x0, 0x0) returned 0x40000413
>>> [Mo Jan 22 08:37:09 2018] input input21: Push scancode into ringbuffer [0x413]
>>> [Mo Jan 22 08:37:09 2018] ACPI: \_SB_.FEXT: fujitsu_laptop: FUNC 0x1002 (args 0x1, 0x0, 0x0) returned 0x0
>>> [Mo Jan 22 08:37:09 2018] ACPI: \_SB_.FEXT: fujitsu_laptop: FUNC 0x1000 (args 0x1, 0x0, 0x0) returned 0x0
>>>
>>> I don't know yet how to distinguish between a separate ECO button and the Fn button here.
>>> Have to recheck with the old HW to see, if some support flags are different now. The button is definitely not in the BTNI mask:
>>
>> For the new u757 I get:
>>> [259964.060356] fujitsu_laptop: Flags supported: 0x26020320
>>> [259964.065143] fujitsu_laptop: BTNI: [0x10001]
The U model has the lid, the "fake ECO button as key" and a POWER button.

>> For the old e736 I get:
>>> [ 3030.845786] fujitsu_laptop: Flag supported: 0x6020320
>>> [ 3030.850631] fujitsu_laptop: BTNI: [0x1010001]
The E model has the same buttons then the U model and an additional RFKILL button

>> BTNI difference seems to be the change from an RFKILL button to function
>> key, but that is just a guess.  The difference is actually two "button to
>> key" changes, but since ECO still emits a button press event, maybe that's
>> the single bit.
> 
> I cannot be sure since I only have a single example of Fujitsu hardware to
> work with.  It seems entirely feasible that the bit change in BTNI is due to
> the loss of the RFKILL button as a dedicated button.
> 
>> And I realized we never use the value from BTNI, except when deciding to
>> register the "fujitsu::kblamps" led, FWIW.
> 
> It's useful for that purpose.
What I meant: the driver doesn't use the value returned by the function. I was hoping to find a way to distinguish the "fake ECO button" key from a real ECO button, so I could send a release immediately after a press event, which is already a release event, just like with the normal function keys.

I have just two different series E and U, so if you have other HW with other buttons, we can eventually decode the value. If the bit was the RFKILL button, then this doesn't help. If it was the ECO button, we can check that.

Currently I can just press the ECO key once, as its keycode is never removed from the ringbuffer.
From my POV we already have more buttons then bits in the BTNI value.

>>> And pressing the brightness-up or -down buttons doesn't change the backlight in KDE5.
>>> Guess I'm facing the "Xorg modeset = no backlight" problem everyone has (since 2016-06): https://bugs.freedesktop.org/show_bug.cgi?id=96572
>>
>> I fixed this for me (4.4 Ubuntu kernel) by using the old CADL patchset
>> backported for 4.4 from Jani Nikular.  The link is just an reference, as I
>> have four patches from the original development:
>> https://lists.freedesktop.org/archives/intel-gfx/2016-August/105351.html
>>
>> Then I need some additional HDA pin quirks for the headset microphone:
>> http://mailman.alsa-project.org/pipermail/alsa-devel/2018-January/131049.html
>>
>> And I'll hopefully get a "rfkill-any" backport into Ubuntu 4.4:
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1745130
> 
> So where does this leave us with fujitsu-laptop?  I *think* the backlight
> issue is beyond our control.  Is that your take on the subject?

This is just an information about the Linux state regarding the HW, if somebody wonders.
Nothing to do there for the fujitsu-laptop driver.

I still have two minor nuisances:
1. the "fake ECO button" key
2. the wrong /sys/devices/platform/fujitsu-laptop/radios state

fujitsu-laptop/radios is always "killed" for me, regardless of the rfkill state. Have to check, if this is eventually connected to the BIOS / EFI settings, which disables the HW.

> With the minor changes in place I do not think this patch will cause any
> regressions for other Fujitsu systems since it is only adding meaning to
> bits of the flags_supported field, and older system do not have those bits
> set.  Any comments Michel?
> 
> Reviewed-by: Jonathan Woithe <jwoithe@just42.net>
> 
> Regards
>   jonathan

Re: Some buttons on the Fujitsu u7[25]7 laptops are not working

[Michał Kępień]

> I'm still pondering about the microphone mute. Should this be handled like the all the other volume buttons, which seem to work without touching the fujitsu-laptop.c driver? I have no idea how these other buttons are forwarded to the sound drivers.

They are not forwarded to sound drivers.  Your desktop environment is
supposed to listen to these input events and apply the requested changes
to mixer settings.

> P.P.S. if someone has a good idea how to "route" the touchpad toggle key to the touchpad drivers without involving the userspace via evrouter, that would be nice too.

Like inside the kernel?  Erm, no, please, no.  Userspace is the place to
do this, same as for brightness hotkeys.  If you ask me, I would just
prefer the firmware to handle all hotkeys by itself, without even
notifying the OS, but this is the brave new world we live in and if the
firmware is only able to produce input events instead of changing
hardware state, let's at least not make these events trigger some sort
of inter-module interaction because that way lies madness.

-- 
Best regards,
Michał Kępień

Re: Some buttons on the Fujitsu u7[25]7 laptops are not working

[Michał Kępień]

> > From: Jan-Marek Glogowski <glogow@fbihome.de>
> > Date: Fri, 19 Jan 2018 21:48:22 +0100
> > Subject: [PATCH] Emit some more button events
> > 
> > Seems Fujitsu continues to move HW functionality into software.
> > These are my observations from the U727.
> > 
> > Fn+F1 is now a button to mute the microphone.
> > Fn+F5 is now the rfkill button.
> > Fn+F9 is now labeled ECO and emits a FUNC 0x1002 (args 0x1, 0x0,
> > 0x0) returned 0x40000413
> 
> For reference, on the S7020 F1 and F5 have no "Fn" function while F9 is
> "volume up.  There is no ambiguity regarding F1 and F5 at least with this
> hardware so this patch shouldn't create conflict there.  If the newly moved
> ECO function were to be hooked it would probably need to be done dependent
> on model.

Why?  The ECO key/hotkey is handled by fujitsu-laptop (ACPI).  Fn+F9 on
older models is handled by i8042 (like it should be).  I do not see any
conflict here.

-- 
Best regards,
Michał Kępień

Re: Some buttons on the Fujitsu u7[25]7 laptops are not working

[Michał Kępień]

> -event6   KEYBOARD_KEY      +6.84s      KEY_MICMUTE (248) pressed
>  event6   KEYBOARD_KEY      +6.84s      KEY_MICMUTE (248) released
> -event2   KEYBOARD_KEY      +8.05s      KEY_MUTE (113) pressed
>  event2   KEYBOARD_KEY      +8.22s      KEY_MUTE (113) released
>  event2   KEYBOARD_KEY      +8.94s      KEY_VOLUMEDOWN (114) pressed
>  event2   KEYBOARD_KEY      +9.09s      KEY_VOLUMEDOWN (114) released
>  event2   KEYBOARD_KEY      +9.91s      KEY_VOLUMEUP (115) pressed
>  event2   KEYBOARD_KEY     +10.06s      KEY_VOLUMEUP (115) released
> -event6   KEYBOARD_KEY     +10.91s      KEY_RFKILL (247) pressed
>  event6   KEYBOARD_KEY     +10.91s      KEY_RFKILL (247) released
>  event6   KEYBOARD_KEY     +12.97s      KEY_TOUCHPAD_TOGGLE (530) pressed
>  event6   KEYBOARD_KEY     +12.97s      KEY_TOUCHPAD_TOGGLE (530) released
> -event3   KEYBOARD_KEY     +14.04s      KEY_BRIGHTNESSDOWN (224) pressed
>  event3   KEYBOARD_KEY     +14.04s      KEY_BRIGHTNESSDOWN (224) released
>  event3   KEYBOARD_KEY     +17.41s      KEY_BRIGHTNESSUP (225) pressed
>  event3   KEYBOARD_KEY     +17.41s      KEY_BRIGHTNESSUP (225) released
> -event6   KEYBOARD_KEY     +18.31s      KEY_PROG4 (203) pressed
> -event2   KEYBOARD_KEY     +21.58s      KEY_LEFTMETA (125) pressed
>  event2   KEYBOARD_KEY     +21.61s      *** (-1) pressed
>  event2   KEYBOARD_KEY     +21.64s      *** (-1) released
>  event2   KEYBOARD_KEY     +21.68s      KEY_LEFTMETA (125) released
> 
> These are Fn+F1 - Fn+F10
> 
> The last event2 is the "Switch output" button.

These are usually "hardcoded" to emit Meta+P.

> The main remaining problem is the missing release event for the ECO / KEY_PROG4.
> Like all buttons the ACPI events are generated on release.
> When releasing the button it, this results in:
> 
> [Mo Jan 22 08:37:09 2018] ACPI: \_SB_.FEXT: fujitsu_laptop: FUNC 0x1000 (args 0x4, 0x0, 0x0) returned 0x320
> [Mo Jan 22 08:37:09 2018] ACPI: \_SB_.FEXT: fujitsu_laptop: Flags state     0x00000320

These two log lines seem unrelated to ECO as the FUNC call above seems
to be performed by radio_led_get().  Did you include these lines on
purpose?  If so, I am missing it.

> [Mo Jan 22 08:37:09 2018] ACPI: \_SB_.FEXT: fujitsu_laptop: FUNC 0x1002 (args 0x1, 0x0, 0x0) returned 0x40000413
> [Mo Jan 22 08:37:09 2018] input input21: Push scancode into ringbuffer [0x413]
> [Mo Jan 22 08:37:09 2018] ACPI: \_SB_.FEXT: fujitsu_laptop: FUNC 0x1002 (args 0x1, 0x0, 0x0) returned 0x0
> [Mo Jan 22 08:37:09 2018] ACPI: \_SB_.FEXT: fujitsu_laptop: FUNC 0x1000 (args 0x1, 0x0, 0x0) returned 0x0

Sigh, so it looks like Fujitsu reused the keycode, but changed the way
it is supposed to be handled.  What a great idea!

> Then there is the "radios" attribute, which is currently inverted for me. It contains "killed", if the radio is on and "on", if it's killed.
 
Please post the output of acpidump collected on one of these new
laptops.  It may help fixing this.

-- 
Best regards,
Michał Kępień

Re: [PATCH][RfC] Some buttons on the Fujitsu u7[25]7 laptops are not working

[Michał Kępień]

> > > I don't know yet how to distinguish between a separate ECO button and the Fn button here.
> > > Have to recheck with the old HW to see, if some support flags are different now. The button is definitely not in the BTNI mask:
> > 
> > For the new u757 I get:
> > > [259964.060356] fujitsu_laptop: Flags supported: 0x26020320
> > > [259964.065143] fujitsu_laptop: BTNI: [0x10001]
> > 
> > For the old e736 I get:
> > > [ 3030.845786] fujitsu_laptop: Flag supported: 0x6020320
> > > [ 3030.850631] fujitsu_laptop: BTNI: [0x1010001]
> > 
> > BTNI difference seems to be the change from an RFKILL button to function
> > key, but that is just a guess.  The difference is actually two "button to
> > key" changes, but since ECO still emits a button press event, maybe that's
> > the single bit.
> 
> I cannot be sure since I only have a single example of Fujitsu hardware to
> work with.  It seems entirely feasible that the bit change in BTNI is due to
> the loss of the RFKILL button as a dedicated button.

This bit was already set on older models which did have a "dedicated"
radio toggle button.  See e.g. log message for commit 4f62568c1fcf
("fujitsu-laptop: Support radio LED").

Bit 29 in flags_supported looks promising, though.  I have not seen it
set on any older model, so it might denote models without any
"dedicated" hardware hotkeys.

> > >From e599b80cc23810cad7837b71cdc3dba0a5334443 Mon Sep 17 00:00:00 2001
> > From: Jan-Marek Glogowski <glogow@fbihome.de>
> > Date: Fri, 19 Jan 2018 21:48:22 +0100
> > Subject: [PATCH] Emit MICMUTE and RFKILL key events
> > 
> > Seems Fujitsu continues to move HW functionality into software.
> > These are my observations from the U727 and U757.
> > 
> > Fn+F1 is now a button to mute the microphone.
> > Fn+F5 is now the rfkill button.
> > Fn+F9 is now labeled ECO and emits a FUNC 0x1002 (args 0x1, 0x0,
> > 0x0) returned 0x40000413
> > 
> > So in addition to the still working KEY_TOUCHPAD_TOGGLE, we now
> > have to emit KEY_RFKILL for BIT(5) and KEY_MICMUTE for BIT(29).
> > 
> > Emitting the KEY_RFKILL will also correctly toggles the
> > corresponding led.
> > 
> > Signed-of-by: Jan-Marek Glogowski <glogow@fbihome.de>
> > ---
> >  drivers/platform/x86/fujitsu-laptop.c | 16 ++++++++++++----
> >  1 file changed, 12 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/platform/x86/fujitsu-laptop.c b/drivers/platform/x86/fujitsu-laptop.c
> > index 2cfbd3f..088cc10 100644
> > --- a/drivers/platform/x86/fujitsu-laptop.c
> > +++ b/drivers/platform/x86/fujitsu-laptop.c
> > @@ -455,7 +455,9 @@ static const struct key_entry keymap_default[] = {
> >  	{ KE_KEY, KEY3_CODE, { KEY_PROG3 } },
> >  	{ KE_KEY, KEY4_CODE, { KEY_PROG4 } },
> >  	{ KE_KEY, KEY5_CODE, { KEY_RFKILL } },
> > +	{ KE_KEY, BIT(5),    { KEY_RFKILL } },
> >  	{ KE_KEY, BIT(26),   { KEY_TOUCHPAD_TOGGLE } },
> > +	{ KE_KEY, BIT(29),   { KEY_MICMUTE } },
> >  	{ KE_END, 0 }
> >  };
> >  
> > @@ -899,7 +901,7 @@ static void acpi_fujitsu_laptop_release(struct acpi_device *device)
> >  static void acpi_fujitsu_laptop_notify(struct acpi_device *device, u32 event)
> >  {
> >  	struct fujitsu_laptop *priv = acpi_driver_data(device);
> > -	int scancode, i = 0;
> > +	int scancode, i = 0, funcret;
> >  	unsigned int irb;
> >  
> >  	if (event != ACPI_FUJITSU_NOTIFY_CODE1) {
> > @@ -930,9 +932,15 @@ static void acpi_fujitsu_laptop_notify(struct acpi_device *device, u32 event)
> >  	 * E736/E746/E756), the touchpad toggle hotkey (Fn+F4) is
> >  	 * handled in software; its state is queried using FUNC_FLAGS
> >  	 */
> > -	if ((priv->flags_supported & BIT(26)) &&
> > -	    (call_fext_func(device, FUNC_FLAGS, 0x1, 0x0, 0x0) & BIT(26)))
> > -		sparse_keymap_report_event(priv->input, BIT(26), 1, true);
> > +	if (priv->flags_supported & (BIT(5) | BIT(26) | BIT(29))) {
> > +		funcret = call_fext_func(device, FUNC_FLAGS, 0x1, 0x0, 0x0);
> > +		if (funcret & BIT(5))
> > +			sparse_keymap_report_event(priv->input, BIT(5), 1, true);
> > +		if (funcret & BIT(26))
> > +			sparse_keymap_report_event(priv->input, BIT(26), 1, true);
> > +		if (funcret & BIT(29))
> > +			sparse_keymap_report_event(priv->input, BIT(29), 1, true);
> > +	}
> >  }
> >  
> >  /* Initialization */
> 
> With the minor changes in place I do not think this patch will cause any
> regressions for other Fujitsu systems since it is only adding meaning to
> bits of the flags_supported field, and older system do not have those bits
> set.  Any comments Michel?

While the patch does not seem to break anything, I cannot say I like how
we are approaching this.

All Jan-Marek wrote suggests that Fujitsu decided to transition from one
way of handling hotkeys to another.  We need to handle both of them.
Until we learned about the new U series models, it looked like the
touchpad toggle hotkey was an exception to the rule.  Given what we know
now, it looks more like a harbinger of further changes.

For me, adding support for the new systems in an elegant way would mean:

  - detecting models without dedicated hotkeys and forcing an immediate
    release event when a "press" is detected on such models; we can take
    a shot at bit 29 being the indicator, the worst that is going to
    happen is that we will get double release events on some machines,

  - keeping GIRB and S000 keymaps separate as these two hotkey handling
    methods are completely different: the former utilizes a ring buffer,
    the latter relies on setting bits in the return value of a function
    and clearing them after they have been "retrieved"; the two keymaps
    would then have to be merged into a single sparse keymap upon device
    instantiation.

However, it is Jonathan who is the module maintainer and Jan-Marek's
patch does not break stuff.  I am thus happy to present my vision after
this patch gets merged.

And just to repeat what I wrote in another message, I would really like
to take a look at the acpidump from one of these new laptops.

By the way, sorry about being late to the party, but severe lack of
spare time pretty much prevents me from following this list.  CC'ing me
directly increases the odds of eliciting a response.

-- 
Best regards,
Michał Kępień

Re: Some buttons on the Fujitsu u7[25]7 laptops are not working

[Jonathan Woithe]

On Sat, Feb 10, 2018 at 10:22:24PM +0100, Micha?? K??pie?? wrote:
> > > From: Jan-Marek Glogowski <glogow@fbihome.de>
> > > Date: Fri, 19 Jan 2018 21:48:22 +0100
> > > Subject: [PATCH] Emit some more button events
> > > 
> > > Seems Fujitsu continues to move HW functionality into software.
> > > These are my observations from the U727.
> > > 
> > > Fn+F1 is now a button to mute the microphone.
> > > Fn+F5 is now the rfkill button.
> > > Fn+F9 is now labeled ECO and emits a FUNC 0x1002 (args 0x1, 0x0,
> > > 0x0) returned 0x40000413
> > 
> > For reference, on the S7020 F1 and F5 have no "Fn" function while F9 is
> > "volume up.  There is no ambiguity regarding F1 and F5 at least with this
> > hardware so this patch shouldn't create conflict there.  If the newly moved
> > ECO function were to be hooked it would probably need to be done dependent
> > on model.
> 
> Why?  The ECO key/hotkey is handled by fujitsu-laptop (ACPI).  Fn+F9 on
> older models is handled by i8042 (like it should be).  I do not see any
> conflict here.

Ah yes.  Ok.

jonathan

Re: [PATCH][RfC] Some buttons on the Fujitsu u7[25]7 laptops are not working

[Jonathan Woithe]

Hi Michel

On Sat, Feb 10, 2018 at 10:23:30PM +0100, Micha?? K??pie?? wrote:
> > With the minor changes in place I do not think this patch will cause any
> > regressions for other Fujitsu systems since it is only adding meaning to
> > bits of the flags_supported field, and older system do not have those bits
> > set.  Any comments Michel?
> 
> While the patch does not seem to break anything, I cannot say I like how
> we are approaching this.
> 
> All Jan-Marek wrote suggests that Fujitsu decided to transition from one
> way of handling hotkeys to another.  We need to handle both of them.
> Until we learned about the new U series models, it looked like the
> touchpad toggle hotkey was an exception to the rule.  Given what we know
> now, it looks more like a harbinger of further changes.

You have raised a good point.

> For me, adding support for the new systems in an elegant way would mean:
> 
>   - detecting models without dedicated hotkeys and forcing an immediate
>     release event when a "press" is detected on such models; we can take
>     a shot at bit 29 being the indicator, the worst that is going to
>     happen is that we will get double release events on some machines,

The effect of a double release depends on the way the key events go on to be
handled.  If they trigger on key-down there will be no issue.  If they go on
key-up then each key will get pressed twice for each physical action.  I
guess time will tell.

>   - keeping GIRB and S000 keymaps separate as these two hotkey handling
>     methods are completely different: the former utilizes a ring buffer,
>     the latter relies on setting bits in the return value of a function
>     and clearing them after they have been "retrieved"; the two keymaps
>     would then have to be merged into a single sparse keymap upon device
>     instantiation.
> 
> However, it is Jonathan who is the module maintainer and Jan-Marek's
> patch does not break stuff.  I am thus happy to present my vision after
> this patch gets merged.

In the interests of making things work for owners of the newer systems in
the short term I am inclined to say we merge the patch from Jan-Marek, on
the understanding that the more extensive infrastructure changes will be
needed in order to handle this in a sane way into the future.  I don't think
the proposed patch will make it any harder to effect the changes you have in
mind, will it?

I'm all for elegant solutions, so I would welcome patches working towards
the broader ideas you outlined above.  Keeping both handling methods
separate does seem to be a good idea.

> By the way, sorry about being late to the party, but severe lack of
> spare time pretty much prevents me from following this list.  CC'ing me
> directly increases the odds of eliciting a response.

No problem - I too am quite busy at the moment so I totally understand.

Regards
  jonathan

Re: [PATCH][RfC] Some buttons on the Fujitsu u7[25]7 laptops are not working

[Jonathan Woithe]

On Fri, Feb 09, 2018 at 02:08:37PM +0100, Jan-Marek Glogowski wrote:
> Am 09.02.2018 um 12:31 schrieb Jonathan Woithe:
> >> And I realized we never use the value from BTNI, except when deciding to
> >> register the "fujitsu::kblamps" led, FWIW.
> > 
> > It's useful for that purpose.
>
> What I meant: the driver doesn't use the value returned by the function. 
> I was hoping to find a way to distinguish the "fake ECO button" key from a
> real ECO button, so I could send a release immediately after a press
> event, which is already a release event, just like with the normal
> function keys.

Right.  Michel has some ideas about how we might be able get around this in
the longer term.

> I have just two different series E and U, so if you have other HW with
> other buttons, we can eventually decode the value.  If the bit was the
> RFKILL button, then this doesn't help.  If it was the ECO button, we can
> check that.

I only have an S7020.  All its special function buttons are on Fn+Fx key
combinations and are therefore handled differently to the panel buttons. 
The S7020 does have five additional buttons (labelled 1-4, Enter) which can
be used for a boot PIN, with 1-4 (but not Enter) also seen by ACPI.  The
practical upshot is that while I can obviously test for regressions on old
hardware, I can't do any tests related to the function-specific buttons on
later models because the S7020 doesn't have any of those.  For example, on
the S7020 there is no "eco" button, and the RFKILL function is handled by a
physical switch.

This all means that the hardware I have will not provide any assistance in
the decoding of which you speak as far as I can tell.

> I still have two minor nuisances:
> 1. the "fake ECO button" key
> 2. the wrong /sys/devices/platform/fujitsu-laptop/radios state
> 
> fujitsu-laptop/radios is always "killed" for me, regardless of the rfkill
> state.  Have to check, if this is eventually connected to the BIOS / EFI
> settings, which disables the HW.

Ok.

Regards
  jonathan

Re: [PATCH][RfC] Some buttons on the Fujitsu u7[25]7 laptops are not working

[Michał Kępień]

> > For me, adding support for the new systems in an elegant way would mean:
> > 
> >   - detecting models without dedicated hotkeys and forcing an immediate
> >     release event when a "press" is detected on such models; we can take
> >     a shot at bit 29 being the indicator, the worst that is going to
> >     happen is that we will get double release events on some machines,
> 
> The effect of a double release depends on the way the key events go on to be
> handled.  If they trigger on key-down there will be no issue.  If they go on
> key-up then each key will get pressed twice for each physical action.  I
> guess time will tell.
> 
> >   - keeping GIRB and S000 keymaps separate as these two hotkey handling
> >     methods are completely different: the former utilizes a ring buffer,
> >     the latter relies on setting bits in the return value of a function
> >     and clearing them after they have been "retrieved"; the two keymaps
> >     would then have to be merged into a single sparse keymap upon device
> >     instantiation.
> > 
> > However, it is Jonathan who is the module maintainer and Jan-Marek's
> > patch does not break stuff.  I am thus happy to present my vision after
> > this patch gets merged.
> 
> In the interests of making things work for owners of the newer systems in
> the short term I am inclined to say we merge the patch from Jan-Marek, on
> the understanding that the more extensive infrastructure changes will be
> needed in order to handle this in a sane way into the future.  I don't think
> the proposed patch will make it any harder to effect the changes you have in
> mind, will it?

No worries, it will not.  There are, however, a couple of "procedural"
issues with Jan-Marek's patch which I listed below.

Jan-Marek, first, please ensure "checkpatch.pl --strict" run on your
patch does not report any issues (e.g. there is a typo in your SOB).

Once that is dealt with, please ensure that you:

  - Send your patch as a separate email, not as part of another message.
    Obviously this is okay to do for draft patches, like the ones you
    sent earlier in this thread, but not really for stuff you would
    actually like to see merged.  "git send-email" is your friend.

  - Make sure your subject line includes the "<subsystem>: <driver>:"
    prefix, i.e. "platform/x86: fujitsu-laptop:".

  - Rename "funcret" to "ret".  I know fujitsu-laptop is not yet
    consistent in naming such variables, but it soon will be, so please
    change it.

  - Not a technical issue, but rather one style-related (just my two
    cents): I would rephrase the subject and the commit log message to:

        platform/x86: fujitsu-laptop: Support Lifebook U7x7 hotkeys

	Generate input events for hotkeys present in Fujitsu Lifebook
	U727 and U757 laptops: Fn+F1 (KEY_MICMUTE) and Fn+F5
	(KEY_RFKILL).

    This is basically what the patch does.  The rest of what you wrote
    in the log message of your draft patch seems redundant to me.

> I'm all for elegant solutions, so I would welcome patches working towards
> the broader ideas you outlined above.  Keeping both handling methods
> separate does seem to be a good idea.

Okay, I will try to prepare something in this regard.

-- 
Best regards,
Michał Kępień

Re: Some buttons on the Fujitsu u7[25]7 laptops are not working

[Michał Kępień]

> > The main remaining problem is the missing release event for the ECO / KEY_PROG4.
> > Like all buttons the ACPI events are generated on release.
> > When releasing the button it, this results in:
> > 
> > [Mo Jan 22 08:37:09 2018] ACPI: \_SB_.FEXT: fujitsu_laptop: FUNC 0x1000 (args 0x4, 0x0, 0x0) returned 0x320
> > [Mo Jan 22 08:37:09 2018] ACPI: \_SB_.FEXT: fujitsu_laptop: Flags state     0x00000320
> 
> These two log lines seem unrelated to ECO as the FUNC call above seems
> to be performed by radio_led_get().  Did you include these lines on
> purpose?  If so, I am missing it.

Please disregard this, I just noticed these logs are also generated by a
call_fext_func() invocation inside acpi_fujitsu_laptop_notify().

-- 
Best regards,
Michał Kępień