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

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

[Jan-Marek Glogowski]

Hi

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've installed Windows on the Notebook and the brightness keys are
working there. The device manager - as on Linux - just lists the FUJ02E3
ACPI device.

I compiled the git fujitsu-notebook driver with debugging and 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 tried to read Windows ACPI events via ETW, but there wasn't any event,
which could be associated with a key press, but brightness was changing
(it seems I just got some error handling events).

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.

ATB

Jan-Marek Glogowski

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

[Jonathan Woithe]

Hi Jan-Marek

On Tue, Jun 14, 2016 at 10:48:32AM +0200, Jan-Marek Glogowski wrote:
> 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).

> 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.

> I compiled the git fujitsu-notebook driver ...

I assume this was "fujitsu-laptop".

> ... 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).

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

> 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.

> 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).

> 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.

Regards
  jonathan

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

[Jan-Marek Glogowski]

Hi Jonathan

Am 17.06.2016 um 01:46 schrieb Jonathan Woithe:
> On Tue, Jun 14, 2016 at 10:48:32AM +0200, Jan-Marek Glogowski wrote:
>> 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).
> 
>> 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.

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 compiled the git fujitsu-notebook driver ...
> 
> I assume this was "fujitsu-laptop".

Yup

>> ... 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).
> 
> For clarity, which buttons are the "non-working combinations"?  Is it just
> the brightness/touchpad buttons, or are there others which are behaving
> similarly?

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.

>> 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.
> 
>> 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).

> 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.

>> 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.

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.

Thanks for your input

Regards,

Jan-Marek

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

[Jonathan Woithe]

Hi Jan-Marek

On Fri, Jun 17, 2016 at 11:20:31AM +0200, Jan-Marek Glogowski wrote:
> 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).

No problem, that's what I understood from your original description.

> 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.

Thanks.

> >> 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).

Hmm, it sounds like they changed quite a bit. :-(

> > 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.

I'm not surprised.  If there was another HID it's reasonable to expect it to
be listed on the other systems.

> > 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.
> 
> Unloading doesn't help.

Again, no surprises.

> 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.  I'm going from memory here, but
I don't think the S7020 that I have includes the intel backlight control
hardware.  This was the motivation for the initial implementation of the
fujitsu-laptop module which utilised the ACPI brightness controller.  It's
been a while since I did those investigations though: I'll see if I can find
my notes.

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

This may be the easiest approach, at least in the short term.

> 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.

Let's see what comes back, at least in response to the touchpad button.  If
they do issue a BIOS update it will be interesting to see whether the
brightness control is affected in any way.  I suspect it won't be, but you
never know.

Regards
  jonathan

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

[Michał Kępień]

> 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.

> 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.

-- 
Best regards,
Michał Kępień

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

[Michał Kępień]

> > 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

-- 
Best regards,
Michał Kępień

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

[Jan-Marek Glogowski]

Am 22.06.2016 um 09:15 schrieb Michał Kępień:
>> 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.

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.

>> 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.

Yup

Regards,

Jan-Marek

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

[Jan-Marek Glogowski]

Am 22.06.2016 um 09:32 schrieb Michał Kępień:
>>> 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

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.

Regards,

Jan-Marek

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

[Jonathan Woithe]

On Wed, Jun 22, 2016 at 09:32:13AM +0200, Micha?? K??pie?? wrote:
> > > 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?

For the newer hardware which seems to rely on non-ACPI methods to control
the brightness, I suspect not (I meant to mention this thought in my
response quoted above but got distracted and forgot about it).  Especially
when the vendor keeps changing their interfaces.

> 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.

When there is an alternative avenue to achieve the desired effect through
existing userspace solutions - as is the case in the situation putlined
above - then there seems little point in trying to duplicate the
functionality in the kernel.  Brightness control on the console these days
would be needed by very few people.

I am wondering whether an approach similar to the above might work for the
OP as a permanent solution.

Regards
  jonathan

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

[Jonathan Woithe]

On Wed, Jun 22, 2016 at 12:18:44PM +0200, Jan-Marek Glogowski wrote:
> Am 22.06.2016 um 09:32 schrieb Micha?? K??pie??:
> > 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.

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
  jonathan

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

[Jan-Marek Glogowski]

Am 22.06.2016 um 12:53 schrieb Jonathan Woithe:
> On Wed, Jun 22, 2016 at 12:18:44PM +0200, Jan-Marek Glogowski wrote:
>> Am 22.06.2016 um 09:32 schrieb Micha?? K??pie??:
>>> 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.
> 
> 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.

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).

> Regards

Jan-Marek

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

[Michał Kępień]

> 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.

Okay, so as I suspected, pure ACPI brightness control isn't working,
it's just userspace reacting to input events generated by
fujitsu-laptop.  That's what I was curious about, thanks.

-- 
Best regards,
Michał Kępień

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

[Michał Kępień]

> 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.

-- 
Best regards,
Michał Kępień

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

[Jan-Marek Glogowski]

Am 22.06.2016 um 14:39 schrieb Michał Kępień:
>> 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.

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.

> 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)?

Regards,

Jan-Marek

[PATCH 0/2] fujitsu-laptop: Debugging cleanup

[Michał Kępień]

Jonathan,

> > 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(-)

-- 
1.7.10.4

[PATCH 1/2] fujitsu-laptop: Use module name in debug messages

[Michał Kępień]

vdbg_printk() always prefixes the log messages it generates with
"FUJ02B1", which can be misleading, because it might have been called
while handling a notify for ACPI device FUJ02E3 or during module
initialization etc.  Employ pr_fmt() to prefix debug messages with the
module name instead and thus avoid confusion.

Reported-by: Jan-Marek Glogowski <glogow@fbihome.de>
Signed-off-by: Michał Kępień <kernel@kempniu.pl>
---
 drivers/platform/x86/fujitsu-laptop.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/x86/fujitsu-laptop.c b/drivers/platform/x86/fujitsu-laptop.c
index ce41bc3..04e633d 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -136,7 +136,7 @@
 #ifdef CONFIG_FUJITSU_LAPTOP_DEBUG
 #define vdbg_printk(a_dbg_level, format, arg...) \
 	do { if (dbg_level & a_dbg_level) \
-		printk(FUJLAPTOP_DEBUG "%s: " format, __func__ , ## arg); \
+		printk(KERN_DEBUG pr_fmt("%s: " format), __func__, ## arg); \
 	} while (0)
 #else
 #define vdbg_printk(a_dbg_level, format, arg...) \
-- 
1.7.10.4

[PATCH 2/2] fujitsu-laptop: Remove unused macros

[Michał Kępień]

FUJLAPTOP_* macros were introduced by 20b9373, but have never been used
except FUJLAPTOP_DEBUG, which was made redundant by the previous patch.

ACPI_VIDEO_NOTIFY_* macros were also introduced by 20b9373, but they
have not been needed since 1696d9d.

Signed-off-by: Michał Kępień <kernel@kempniu.pl>
---
 drivers/platform/x86/fujitsu-laptop.c |   10 ----------
 1 file changed, 10 deletions(-)

diff --git a/drivers/platform/x86/fujitsu-laptop.c b/drivers/platform/x86/fujitsu-laptop.c
index 04e633d..7a345f9 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -88,9 +88,6 @@
 
 #define ACPI_FUJITSU_NOTIFY_CODE1     0x80
 
-#define ACPI_VIDEO_NOTIFY_INC_BRIGHTNESS     0x86
-#define ACPI_VIDEO_NOTIFY_DEC_BRIGHTNESS     0x87
-
 /* FUNC interface - command values */
 #define FUNC_RFKILL	0x1000
 #define FUNC_LEDS	0x1001
@@ -121,13 +118,6 @@
 #define RINGBUFFERSIZE 40
 
 /* Debugging */
-#define FUJLAPTOP_LOG	   ACPI_FUJITSU_HID ": "
-#define FUJLAPTOP_ERR	   KERN_ERR FUJLAPTOP_LOG
-#define FUJLAPTOP_NOTICE   KERN_NOTICE FUJLAPTOP_LOG
-#define FUJLAPTOP_INFO	   KERN_INFO FUJLAPTOP_LOG
-#define FUJLAPTOP_DEBUG    KERN_DEBUG FUJLAPTOP_LOG
-
-#define FUJLAPTOP_DBG_ALL	  0xffff
 #define FUJLAPTOP_DBG_ERROR	  0x0001
 #define FUJLAPTOP_DBG_WARN	  0x0002
 #define FUJLAPTOP_DBG_INFO	  0x0004
-- 
1.7.10.4

Re: [PATCH 0/2] fujitsu-laptop: Debugging cleanup

[Jonathan Woithe]

On Thu, Jun 23, 2016 at 12:02:46PM +0200, Micha?? K??pie?? wrote:
> 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 <jwoithe@just42.net>

Regards
  jonathan

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

[Michał Kępień]

> > 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).

> 
> The diff between e7x4 and e7x6 DSDT is ~43k lines or 1.3MB
> And the DSDT of 736 and 756 is identical.
> 
> > 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)?

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

-- 
Best regards,
Michał Kępień

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

[Jan-Marek Glogowski]

Am 23.06.2016 um 13:18 schrieb Michał Kępień:
>>> 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.

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?

> 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.

> 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).

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.

>> The diff between e7x4 and e7x6 DSDT is ~43k lines or 1.3MB
>> And the DSDT of 736 and 756 is identical.
>>
>>> 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)?
> 
> 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
> 

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

[Michał Kępień]

> > 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.
> 
> 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.

> 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.html

> > 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.
> 
> > 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).
> 
> 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.

No need to do that, at least for now.  The sole fact that something
works on Windows is not much of a help if we don't know the technology
used behind the scenes.

-- 
Best regards,
Michał Kępień

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

[Jan-Marek Glogowski]

Am 23.06.2016 um 14:35 schrieb Michał Kępień:
>>> 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.
>>
>> 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.

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.

>>> 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.

>>> 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).

Regards,

Jan-Marek

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

[Michał Kępień]

> > 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.

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

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

Right, you are going to need that.

> 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.
> 
> >>> 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.

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.

-- 
Best regards,
Michał Kępień

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

[Jan-Marek Glogowski]

Am 23.06.2016 um 15:31 schrieb Michał Kępień:
>>> 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.
> 
> If that button is supposed to be handled by ACPI, then yes, this should
> help.

I'm not sure if it's supposed to be handled by ACPI and not completely
in HW, like in the Haswell line, but I get Notify events for the fujitsu
driver.

>> I'm currently to recompiling my Ubuntu kernel, as it doesn't set
>> CONFIG_ACPI_CUSTOM_METHOD
> 
> Right, you are going to need that.
> 
>> 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.
>>
>>>>> 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.
> 
> Just use the ACPI debug object.  Everything you need is in the
> documentation I have already referred you to (method-customizing.txt).

Ups. Sorry - too much parallel stuff going on today.
I'll really read the document and not just skim through it (which I did
after realizing my kernel misses the needed modules.

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

Yup.

Regards,

Jan-Marek

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

[Jan-Marek Glogowski]

Am 23.06.2016 um 14:35 schrieb Michał Kępień:
>>> 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.
>>
>> 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.
> 
>> 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
> 
>>> 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.
>>
>>> If that value is 0, it's
>>> obviously a vendor bug as it would prevent the ACPI video device from
>>> being notified. 

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.

>>> 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.

Jan-Marek

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

[Michał Kępień]

> Hmm - so I got
> [  561.809723] [ACPI Debug 64952760]  Integer 0x0000000000000000
> for my Store (BSWF, Debug) call.

This is the core issue.

> 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?

> 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 :-(

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.

> 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.

> 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.

> 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.

> >>> 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.

Sorry, the above sentence does not parse for me.

> 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.

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

-- 
Best regards,
Michał Kępień

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

[Jan-Marek Glogowski]

Am 24.06.2016 um 09:12 schrieb Michał Kępień:
>> Hmm - so I got
>> [  561.809723] [ACPI Debug 64952760]  Integer 0x0000000000000000
>> for my Store (BSWF, Debug) call.
> 
> This is the core issue.
> 
>> 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?

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?

>> 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 :-(
> 
> Did you mean _L21?  I assume you were talking about Skylakes above, but
> _L11 is not used on these.

Yup.

> 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.

>> 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.

My _L21:

DefinitionBlock ("", "DSDT", 2, "FUJ   ", "FJNB293 ", 0x010A0000)
{
    External (AHKF)
    External (BSWF)
    External (DSEN)
    External (DSWF)
    External (GINT)
    External (IRBC)
    External (IRBF)
    External (LCDA)
    External (RFHF)
    External (RFSW)
    External (\_SB.FEXT)
    External (\_SB.PCI0.GFX0.DD1F._DCS)
    External (WSEF)

    External (\FSMI, MethodObj)
    External (\_GPE.SWPC, MethodObj)
    External (\_SB.FEXT.SIRB, MethodObj)
    External (\_SB.PCI0.GFX0.DD1F.BLNF, MethodObj)

    Method (\_GPE._L21, 0, NotSerialized)  // _Lxx: Level-Triggered GPE
    {
        Store (0xDEADBEAF, Debug)
        Store (Zero, DSWF)
        If (LEqual (\_SB.PCI0.GFX0.DD1F._DCS, 0x1F))
        {
            Store (One, LCDA)
        }
        Else
        {
            Store (Zero, LCDA)
        }
        Store (LCDA, Debug)

        FSMI (0x89, Zero, Zero)

        Store (DSEN, Debug)
        Store (DSWF, Debug)

        If (LAnd (LEqual (And (DSEN, 0x03), Zero), DSWF))
        {
            Store (One, Debug)
            SWPC ()
        }

        Store (BSWF, Debug)
        If (BSWF)
        {
            \_SB.PCI0.GFX0.DD1F.BLNF ()
        }

        Store (RFHF, Debug)
        If (RFHF)
        {
            Store (One, WSEF)
            Notify (\_SB.FEXT, 0x80)
            Store (ShiftRight (RFHF, One), RFSW)
            Store (Zero, RFHF)
        }

        Store (AHKF, Debug)
        If (AHKF)
        {
            Notify (\_SB.FEXT, 0x80)
        }

        Store (IRBF, Debug)
        If (IRBF)
        {
            If (LEqual (IRBC, 0xFD00))
            {
                Store (One, GINT)
            }
            Else
            {
                \_SB.FEXT.SIRB (IRBC)
            }

            Notify (\_SB.FEXT, 0x80)
            Store (Zero, IRBF)
        }
    }
}

dmesg output

Press brightness
[ 4924.223692] [ACPI Debug 65675410]  Integer 0x00000000DEADBEAF
[ 4924.224258] [ACPI Debug 65675982]  Integer 0x0000000000000000
[ 4924.228018] [ACPI Debug 65679741]  Integer 0x0000000000000000
[ 4924.228065] [ACPI Debug 65679791]  Integer 0x0000000000000000
[ 4924.228175] [ACPI Debug 65679901]  Integer 0x0000000000000000
[ 4924.228250] [ACPI Debug 65679977]  Integer 0x0000000000000000
[ 4924.228325] [ACPI Debug 65680052]  Integer 0x0000000000000000
[ 4924.228400] [ACPI Debug 65680127]  Integer 0x0000000000000000
Press touchpad
[ 4942.346856] [ACPI Debug 16690175]  Integer 0x00000000DEADBEAF
[ 4942.347414] [ACPI Debug 16690739]  Integer 0x0000000000000000
[ 4942.351169] [ACPI Debug 16694492]  Integer 0x0000000000000000
[ 4942.351216] [ACPI Debug 16694542]  Integer 0x0000000000000000
[ 4942.351327] [ACPI Debug 16694653]  Integer 0x0000000000000000
[ 4942.351403] [ACPI Debug 16694730]  Integer 0x0000000000000000
[ 4942.351479] [ACPI Debug 16694806]  Integer 0x0000000000000008
[ 4942.351572] [ACPI Debug 16694898]  Integer 0x0000000000000000
Press brightness
[ 4943.381885] [ACPI Debug 17725230]  Integer 0x00000000DEADBEAF
[ 4943.382553] [ACPI Debug 17725902]  Integer 0x0000000000000000
[ 4943.386264] [ACPI Debug 17729614]  Integer 0x0000000000000000
[ 4943.386310] [ACPI Debug 17729662]  Integer 0x0000000000000000
[ 4943.386418] [ACPI Debug 17729771]  Integer 0x0000000000000000
[ 4943.386495] [ACPI Debug 17729848]  Integer 0x0000000000000000
[ 4943.386569] [ACPI Debug 17729922]  Integer 0x0000000000000008
[ 4943.386621] [ACPI Debug 17729975]  Integer 0x0000000000000000

>> 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.

Yup - I didn't actually look at the Haswell ACPI handling.

>> 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.
> 
>>>>> 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.
> 
> 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

>> 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.

So for you the FSMI call changes the BSWF value.

> 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.

Regards,

Jan-Marek

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

[Michał Kępień]

> >> 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?
> 
> 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?

Correct.  It is either 1 ("brightness down") or 2 ("brightness up").
Though I still fail to understand your point regarding OSYS processing.
It looks pretty clear to me: Haswells send notifications to the ACPI
video object on "newer" systems and fall back to GBLS/SBLL for
everything else; Skylakes do not have the fallback branch.

> >> 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 :-(
> > 
> > Did you mean _L21?  I assume you were talking about Skylakes above, but
> > _L11 is not used on these.
> 
> Yup.
> 
> > 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.

Understood, thanks for clarifying.

> >> 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.
> 
> My _L21:
> 
> (...)

All clear now, thanks.

> >> 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)
> }

Ah, okay, got it.  This means I can probably prepare an experimental
patch to support the touchpad button.

> 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.

Well, yes, but two questions still remain:

 1) Why are no brightness-related notifications sent to either the ACPI
    video device or FEXT (i.e. why is BSWF constant)?

 2) You wrote "call another function from the driver to know if the
    brightness level went up or down".  The question is _which_ function
    to call - I do not see it, do you?

> And they added the 0x02000000 and 0x04000000 values to the bitmask they
> generate when you call S000 with Arg0 = 0
> 
> >> 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.
> 
> So for you the FSMI call changes the BSWF value.

Yes.

> > 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 am not sure what the Intel driver has to do with this, but hey, who am
I to tell them how their hardware works?

> I'll point them to this thread.

Please do, I will be happy to help.

> 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.

-- 
Best regards,
Michał Kępień

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

[Jan-Marek Glogowski]

Am 24.06.2016 um 12:20 schrieb Michał Kępień:
>> 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?
> 
>> I'll point them to this thread.
> 
> Please do, I will be happy to help.
> 
>> 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.

There is a key event in input.h called KEY_TOUCHPAD_TOGGLE.

Calling the S000 function as

call_fext_func(FUNC_RFKILL, 0x0, 0x0, 0x0) should give you the indicator
mask
call_fext_func(FUNC_RFKILL, 0x1, 0x0, 0x0) should give you the touchpad
and brightness indicator and actually reset both indicator states

From the asl, valid first parameters are 0x01 (touch + bright), 0x04
(rfkill) and 0x05 (? something else regarding RF, as it also uses FSMI 0x91)

Regards,

Jan-Marek

P.S. after rebuilding my kernel I can finally build external modules
again. Building the deb-pkg target on amd64 for i386 kernel, results in
the correct kernel, but amd64-compiled tools needed for modpost.

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

[Jan-Marek Glogowski]

Am 24.06.2016 um 12:20 schrieb Michał Kępień:
>> 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 :-)

[ 1256.079552] [ACPI Debug 61578415]  Integer 0x00000000DEADBEAF
[ 1256.080002] [ACPI Debug 61578870]  Integer 0x0000000000000001
[ 1256.083691] [ACPI Debug 61582559]  Integer 0x0000000000000004
[ 1256.083739] [ACPI Debug 61582609]  Integer 0x0000000000000000
[ 1256.083849] [ACPI Debug 61582720]  Integer 0x0000000000000001
[ 1256.084242] [ACPI Debug 61583112]  Integer 0x0000000000000000
[ 1256.084318] [ACPI Debug 61583189]  Integer 0x0000000000000001
[ 1256.084406] [ACPI Debug 61583276]  Integer 0x0000000000000000
[ 1256.649955] [ACPI Debug 62148830]  Integer 0x00000000DEADBEAF
[ 1256.650405] [ACPI Debug 62149284]  Integer 0x0000000000000001
[ 1256.653997] [ACPI Debug 62152876]  Integer 0x0000000000000004
[ 1256.654043] [ACPI Debug 62152925]  Integer 0x0000000000000000
[ 1256.654152] [ACPI Debug 62153034]  Integer 0x0000000000000002
[ 1256.654549] [ACPI Debug 62153431]  Integer 0x0000000000000000
[ 1256.654625] [ACPI Debug 62153507]  Integer 0x0000000000000001
[ 1256.654712] [ACPI Debug 62153595]  Integer 0x0000000000000000

I'll port the patches to my Ubuntu Wily i915 module, and then weekend,
sunshine… :-)

Regards,

Jan-Marek

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

[Michał Kępień]

> 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*.  Please, make it more
complicated, I mean, sending i8042 interrupts when keys are pressed is
so 1985 and it simply cannot work reliably.

-- 
Best regards,
Michał Kępień

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

[Jonathan Woithe]

On Fri, Jun 24, 2016 at 10:17:37PM +0200, Micha?? K??pie?? wrote:
> > 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.

That's great news.  Thanks to all who have pursued this issue.  At least now
we have some understanding as to what's going on behind the scenes on this
hardware, even it if it rather convoluted.

> ...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?

Regards
  jonathan

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

[Michał Kępień]

> > ...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.

> 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.

> 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.

-- 
Best regards,
Michał Kępień

[PATCH] fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models

[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.

Reported-by: Jan-Marek Glogowski <glogow@fbihome.de>
Signed-off-by: Michał Kępień <kernel@kempniu.pl>
---

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(+)

diff --git a/drivers/platform/x86/fujitsu-laptop.c b/drivers/platform/x86/fujitsu-laptop.c
index ce41bc3..ef28447 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -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;
-- 
1.7.10.4

[PATCH] Register KEY_TOUCHPAD_TOGGLE with input device

[Jan-Marek Glogowski]

Probably just squash that into

[PATCH] fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models

Signed-off-by: Jan-Marek Glogowski <glogow@fbihome.de>
---
 fujitsu-laptop.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/platform/x86/fujitsu-laptop.c b/drivers/platform/x86/fujitsu-laptop.c
index 695bd5e..42319c8 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -884,6 +884,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);
-- 
1.9.1

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

[Jan-Marek Glogowski]

Am 25.06.2016 um 11:15 schrieb Michał Kępień:
>>> ...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.
> 
>> 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.

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.

>> 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

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

[Michał Kępień]

> >> 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.

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.

> 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.

Using a single byte to hold a keycode is a limitation of the X11
protocol and there are other platform drivers using KEY_TOUCHPAD_TOGGLE,
so unless Fujitsu clues us in on some magical way to set the touchpad
state, I am not sure anything more can/should be done in the kernel.
Note that GMOU/SMOU ACPI methods were removed in Skylake firmware.  If
you really want to avoid using helper software, patch your kernel to
generate a different event when Fn+F4 is pressed.

-- 
Best regards,
Michał Kępień

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

[Jan-Marek Glogowski]

Am 27.06.2016 um 13:16 schrieb Michał Kępień:
>>>> 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.
> 
> 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?
How is this normally handled?

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

That would really be hackish, I guess ;-)

Probably I'll go with a patch to the X11 evdev driver for remapping:
http://www.thenautilus.net/cgit/xf86-input-evdev/commit/?h=code-remap-2.9.2
as XF86XK_TouchpadToggle is already mapped to 199 in my xmodmap.

Regards,

Jan-Marek

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

[Jonathan Woithe]

On Mon, Jun 27, 2016 at 01:40:09PM +0200, Jan-Marek Glogowski wrote:
> Am 27.06.2016 um 13:16 schrieb Micha?? K??pie??:
> >>> 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.
> > 
> > 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?

To keep everything clear it would be best if a fresh patch were submitted
which included the fix and addressed a comment I'll write in a minute.  Add
Tested-by to that and we can take it from there.

Regards
  jonathan

Re: [PATCH] fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models

[Jonathan Woithe]

On Sun, Jun 26, 2016 at 09:41:35AM +0200, Micha?? K??pie?? wrote:
> 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).

Regards
  jonathan

> 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 <glogow@fbihome.de>
> Signed-off-by: Micha?? K??pie?? <kernel@kempniu.pl>
> ---
> 
> 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(+)
> 
> diff --git a/drivers/platform/x86/fujitsu-laptop.c b/drivers/platform/x86/fujitsu-laptop.c
> index ce41bc3..ef28447 100644
> --- a/drivers/platform/x86/fujitsu-laptop.c
> +++ b/drivers/platform/x86/fujitsu-laptop.c
> @@ -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;
> -- 
> 1.7.10.4

-- 

Re: [PATCH] fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models

[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.
> > :
> 
> 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).

Will do, thanks for the review.

-- 
Best regards,
Michał Kępień

[PATCH v2] fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models

[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.

Reported-and-tested-by: Jan-Marek Glogowski <glogow@fbihome.de>
Signed-off-by: Michał Kępień <kernel@kempniu.pl>
---

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(+)

diff --git a/drivers/platform/x86/fujitsu-laptop.c b/drivers/platform/x86/fujitsu-laptop.c
index ce41bc3..37ef75e 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -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;
-- 
1.7.10.4

Re: [PATCH v2] fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models

[Jonathan Woithe]

On Mon, Jun 27, 2016 at 03:19:41PM +0200, Micha?? K??pie?? wrote:
> 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 <glogow@fbihome.de>
> Signed-off-by: Micha?? K??pie?? <kernel@kempniu.pl>

A nitpick: in the patch, rather than "some models", perhaps explicitly
mention some of them.  For example:

  On some models (first seen on the Skylake-based Lifebook E736/E746/E756),
  the touchpad ...

I know this pushes the comment to 3 lines, but it results in a solid
indication in the code as to where and why the change was first needed.

Otherwise, all good.

Regards
  jonathan

> ---
> 
> 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(+)
> 
> diff --git a/drivers/platform/x86/fujitsu-laptop.c b/drivers/platform/x86/fujitsu-laptop.c
> index ce41bc3..37ef75e 100644
> --- a/drivers/platform/x86/fujitsu-laptop.c
> +++ b/drivers/platform/x86/fujitsu-laptop.c
> @@ -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;
> -- 
> 1.7.10.4

[PATCH v3] fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models

[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.

Reported-and-tested-by: Jan-Marek Glogowski <glogow@fbihome.de>
Signed-off-by: Michał Kępień <kernel@kempniu.pl>
---

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(+)

diff --git a/drivers/platform/x86/fujitsu-laptop.c b/drivers/platform/x86/fujitsu-laptop.c
index ce41bc3..36cd743 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -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;
-- 
1.7.10.4

Re: [PATCH v3] fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models

[Jonathan Woithe]

On Tue, Jun 28, 2016 at 09:25:50AM +0200, Micha?? K??pie?? wrote:
> 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 <glogow@fbihome.de>
> Signed-off-by: Micha?? K??pie?? <kernel@kempniu.pl>

Thanks for the revision and your patience.

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

Regards
  jonathan

> ---
> 
> 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(+)
> 
> diff --git a/drivers/platform/x86/fujitsu-laptop.c b/drivers/platform/x86/fujitsu-laptop.c
> index ce41bc3..36cd743 100644
> --- a/drivers/platform/x86/fujitsu-laptop.c
> +++ b/drivers/platform/x86/fujitsu-laptop.c
> @@ -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;
> -- 
> 1.7.10.4

-- 

Re: [PATCH 0/2] fujitsu-laptop: Debugging cleanup

[Darren Hart]

On Thu, Jun 23, 2016 at 08:05:35PM +0930, Jonathan Woithe wrote:
> On Thu, Jun 23, 2016 at 12:02:46PM +0200, Micha?? K??pie?? wrote:
> > 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 <jwoithe@just42.net>

Queued to testing for 4.8.

> 
> Regards
>   jonathan
> 

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH v3] fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models

[Darren Hart]

On Tue, Jun 28, 2016 at 08:49:22PM +0930, Jonathan Woithe wrote:
> On Tue, Jun 28, 2016 at 09:25:50AM +0200, Micha?? K??pie?? wrote:
> > 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 <glogow@fbihome.de>
> > Signed-off-by: Micha?? K??pie?? <kernel@kempniu.pl>
> 
> Thanks for the revision and your patience.
> 
> Acked-by: Jonathan Woithe <jwoithe@just42.net>

Queued to testing for 4.8, thanks.

-- 
Darren Hart
Intel Open Source Technology Center

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

[Jani Nikula]

On Mon, 27 Jun 2016, Jan-Marek Glogowski <glogow@fbihome.de> wrote:
> Am 25.06.2016 um 11:15 schrieb Michał Kępień:
>>>> ...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.
>> 
>>> 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.
>
> 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/cover.1465810007.git.jani.nikula@intel.com



>
> 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.
>
>>> 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

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Jani Nikula]

On Wed, 29 Jun 2016, Jani Nikula <jani.nikula@intel.com> wrote:
> On Mon, 27 Jun 2016, Jan-Marek Glogowski <glogow@fbihome.de> wrote:
>> Am 25.06.2016 um 11:15 schrieb Michał Kępień:
>>>>> ...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.
>>> 
>>>> 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.
>>
>> 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! ;)

Okay, I pushed the first three patches, and updated the other two
[1]. Please test.

BR,
Jani.


[1] https://patchwork.freedesktop.org/series/4783/

>
> 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/cover.1465810007.git.jani.nikula@intel.com
>
>
>
>>
>> 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.
>>
>>>> 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

-- 
Jani Nikula, Intel Open Source Technology Center