* Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 @ 2016-06-14 8:48 Jan-Marek Glogowski 2016-06-16 23:46 ` Jonathan Woithe 2016-06-22 7:15 ` Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 Michał Kępień 0 siblings, 2 replies; 49+ messages in thread From: Jan-Marek Glogowski @ 2016-06-14 8:48 UTC (permalink / raw) To: Jonathan Woithe; +Cc: platform-driver-x86 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-14 8:48 Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 Jan-Marek Glogowski @ 2016-06-16 23:46 ` Jonathan Woithe 2016-06-17 9:20 ` Jan-Marek Glogowski 2016-06-23 10:02 ` [PATCH 0/2] fujitsu-laptop: Debugging cleanup Michał Kępień 2016-06-22 7:15 ` Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 Michał Kępień 1 sibling, 2 replies; 49+ messages in thread From: Jonathan Woithe @ 2016-06-16 23:46 UTC (permalink / raw) To: Jan-Marek Glogowski; +Cc: platform-driver-x86 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-16 23:46 ` Jonathan Woithe @ 2016-06-17 9:20 ` Jan-Marek Glogowski 2016-06-21 8:12 ` Jonathan Woithe 2016-06-23 10:02 ` [PATCH 0/2] fujitsu-laptop: Debugging cleanup Michał Kępień 1 sibling, 1 reply; 49+ messages in thread From: Jan-Marek Glogowski @ 2016-06-17 9:20 UTC (permalink / raw) To: Jonathan Woithe; +Cc: platform-driver-x86 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-17 9:20 ` Jan-Marek Glogowski @ 2016-06-21 8:12 ` Jonathan Woithe 2016-06-22 7:32 ` Michał Kępień 0 siblings, 1 reply; 49+ messages in thread From: Jonathan Woithe @ 2016-06-21 8:12 UTC (permalink / raw) To: Jan-Marek Glogowski; +Cc: platform-driver-x86 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-21 8:12 ` Jonathan Woithe @ 2016-06-22 7:32 ` Michał Kępień 2016-06-22 10:18 ` Jan-Marek Glogowski 2016-06-22 10:46 ` Jonathan Woithe 0 siblings, 2 replies; 49+ messages in thread From: Michał Kępień @ 2016-06-22 7:32 UTC (permalink / raw) To: Jonathan Woithe; +Cc: Jan-Marek Glogowski, platform-driver-x86 > > 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ń ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-22 7:32 ` Michał Kępień @ 2016-06-22 10:18 ` Jan-Marek Glogowski 2016-06-22 10:53 ` Jonathan Woithe 2016-06-22 10:46 ` Jonathan Woithe 1 sibling, 1 reply; 49+ messages in thread From: Jan-Marek Glogowski @ 2016-06-22 10:18 UTC (permalink / raw) To: Michał Kępień, Jonathan Woithe; +Cc: platform-driver-x86 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-22 10:18 ` Jan-Marek Glogowski @ 2016-06-22 10:53 ` Jonathan Woithe 2016-06-22 11:23 ` Jan-Marek Glogowski 0 siblings, 1 reply; 49+ messages in thread From: Jonathan Woithe @ 2016-06-22 10:53 UTC (permalink / raw) To: Jan-Marek Glogowski; +Cc: Micha?? K??pie??, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-22 10:53 ` Jonathan Woithe @ 2016-06-22 11:23 ` Jan-Marek Glogowski 2016-06-22 12:39 ` Michał Kępień 0 siblings, 1 reply; 49+ messages in thread From: Jan-Marek Glogowski @ 2016-06-22 11:23 UTC (permalink / raw) To: Jonathan Woithe; +Cc: Micha?? K??pie??, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-22 11:23 ` Jan-Marek Glogowski @ 2016-06-22 12:39 ` Michał Kępień 2016-06-22 13:22 ` Jan-Marek Glogowski 0 siblings, 1 reply; 49+ messages in thread From: Michał Kępień @ 2016-06-22 12:39 UTC (permalink / raw) To: Jan-Marek Glogowski; +Cc: Jonathan Woithe, platform-driver-x86 > 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ń ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-22 12:39 ` Michał Kępień @ 2016-06-22 13:22 ` Jan-Marek Glogowski 2016-06-23 11:18 ` Michał Kępień 0 siblings, 1 reply; 49+ messages in thread From: Jan-Marek Glogowski @ 2016-06-22 13:22 UTC (permalink / raw) To: Michał Kępień; +Cc: Jonathan Woithe, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-22 13:22 ` Jan-Marek Glogowski @ 2016-06-23 11:18 ` Michał Kępień 2016-06-23 12:08 ` Jan-Marek Glogowski 0 siblings, 1 reply; 49+ messages in thread From: Michał Kępień @ 2016-06-23 11:18 UTC (permalink / raw) To: Jan-Marek Glogowski; +Cc: Jonathan Woithe, platform-driver-x86 > > 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ń ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-23 11:18 ` Michał Kępień @ 2016-06-23 12:08 ` Jan-Marek Glogowski 2016-06-23 12:35 ` Michał Kępień 0 siblings, 1 reply; 49+ messages in thread From: Jan-Marek Glogowski @ 2016-06-23 12:08 UTC (permalink / raw) To: Michał Kępień; +Cc: Jonathan Woithe, platform-driver-x86 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 > ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-23 12:08 ` Jan-Marek Glogowski @ 2016-06-23 12:35 ` Michał Kępień 2016-06-23 13:17 ` Jan-Marek Glogowski 2016-06-23 17:23 ` Jan-Marek Glogowski 0 siblings, 2 replies; 49+ messages in thread From: Michał Kępień @ 2016-06-23 12:35 UTC (permalink / raw) To: Jan-Marek Glogowski; +Cc: Jonathan Woithe, platform-driver-x86 > > 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ń ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-23 12:35 ` Michał Kępień @ 2016-06-23 13:17 ` Jan-Marek Glogowski 2016-06-23 13:31 ` Michał Kępień 2016-06-23 17:23 ` Jan-Marek Glogowski 1 sibling, 1 reply; 49+ messages in thread From: Jan-Marek Glogowski @ 2016-06-23 13:17 UTC (permalink / raw) To: Michał Kępień; +Cc: Jonathan Woithe, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-23 13:17 ` Jan-Marek Glogowski @ 2016-06-23 13:31 ` Michał Kępień 2016-06-23 13:42 ` Jan-Marek Glogowski 0 siblings, 1 reply; 49+ messages in thread From: Michał Kępień @ 2016-06-23 13:31 UTC (permalink / raw) To: Jan-Marek Glogowski; +Cc: Jonathan Woithe, platform-driver-x86 > > 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ń ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-23 13:31 ` Michał Kępień @ 2016-06-23 13:42 ` Jan-Marek Glogowski 0 siblings, 0 replies; 49+ messages in thread From: Jan-Marek Glogowski @ 2016-06-23 13:42 UTC (permalink / raw) To: Michał Kępień; +Cc: Jonathan Woithe, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-23 12:35 ` Michał Kępień 2016-06-23 13:17 ` Jan-Marek Glogowski @ 2016-06-23 17:23 ` Jan-Marek Glogowski 2016-06-24 7:12 ` Michał Kępień 1 sibling, 1 reply; 49+ messages in thread From: Jan-Marek Glogowski @ 2016-06-23 17:23 UTC (permalink / raw) To: Michał Kępień; +Cc: Jonathan Woithe, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-23 17:23 ` Jan-Marek Glogowski @ 2016-06-24 7:12 ` Michał Kępień 2016-06-24 9:22 ` Jan-Marek Glogowski 0 siblings, 1 reply; 49+ messages in thread From: Michał Kępień @ 2016-06-24 7:12 UTC (permalink / raw) To: Jan-Marek Glogowski; +Cc: Jonathan Woithe, platform-driver-x86 > 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ń ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-24 7:12 ` Michał Kępień @ 2016-06-24 9:22 ` Jan-Marek Glogowski 2016-06-24 10:20 ` Michał Kępień 0 siblings, 1 reply; 49+ messages in thread From: Jan-Marek Glogowski @ 2016-06-24 9:22 UTC (permalink / raw) To: Michał Kępień; +Cc: Jonathan Woithe, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-24 9:22 ` Jan-Marek Glogowski @ 2016-06-24 10:20 ` Michał Kępień 2016-06-24 11:39 ` Jan-Marek Glogowski 2016-06-24 15:43 ` Jan-Marek Glogowski 0 siblings, 2 replies; 49+ messages in thread From: Michał Kępień @ 2016-06-24 10:20 UTC (permalink / raw) To: Jan-Marek Glogowski; +Cc: Jonathan Woithe, platform-driver-x86 > >> 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ń ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-24 10:20 ` Michał Kępień @ 2016-06-24 11:39 ` Jan-Marek Glogowski 2016-06-24 15:43 ` Jan-Marek Glogowski 1 sibling, 0 replies; 49+ messages in thread From: Jan-Marek Glogowski @ 2016-06-24 11:39 UTC (permalink / raw) To: Michał Kępień; +Cc: Jonathan Woithe, platform-driver-x86 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-24 10:20 ` Michał Kępień 2016-06-24 11:39 ` Jan-Marek Glogowski @ 2016-06-24 15:43 ` Jan-Marek Glogowski 2016-06-24 20:17 ` Michał Kępień 1 sibling, 1 reply; 49+ messages in thread From: Jan-Marek Glogowski @ 2016-06-24 15:43 UTC (permalink / raw) To: Michał Kępień Cc: Jonathan Woithe, platform-driver-x86, Jani Nikula 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-24 15:43 ` Jan-Marek Glogowski @ 2016-06-24 20:17 ` Michał Kępień 2016-06-25 8:50 ` Jonathan Woithe 0 siblings, 1 reply; 49+ messages in thread From: Michał Kępień @ 2016-06-24 20:17 UTC (permalink / raw) To: Jan-Marek Glogowski; +Cc: Jonathan Woithe, platform-driver-x86, Jani Nikula > 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ń ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-24 20:17 ` Michał Kępień @ 2016-06-25 8:50 ` Jonathan Woithe 2016-06-25 9:15 ` Michał Kępień 0 siblings, 1 reply; 49+ messages in thread From: Jonathan Woithe @ 2016-06-25 8:50 UTC (permalink / raw) To: Micha?? K??pie??; +Cc: Jan-Marek Glogowski, platform-driver-x86, Jani Nikula 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-25 8:50 ` Jonathan Woithe @ 2016-06-25 9:15 ` Michał Kępień 2016-06-26 7:41 ` [PATCH] fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models Michał Kępień 2016-06-27 8:32 ` Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 Jan-Marek Glogowski 0 siblings, 2 replies; 49+ messages in thread From: Michał Kępień @ 2016-06-25 9:15 UTC (permalink / raw) To: Jonathan Woithe; +Cc: Jan-Marek Glogowski, platform-driver-x86, Jani Nikula > > ...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ń ^ permalink raw reply [flat|nested] 49+ messages in thread
* [PATCH] fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models 2016-06-25 9:15 ` Michał Kępień @ 2016-06-26 7:41 ` Michał Kępień 2016-06-27 8:03 ` [PATCH] Register KEY_TOUCHPAD_TOGGLE with input device Jan-Marek Glogowski 2016-06-27 12:48 ` [PATCH] fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models Jonathan Woithe 2016-06-27 8:32 ` Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 Jan-Marek Glogowski 1 sibling, 2 replies; 49+ messages in thread From: Michał Kępień @ 2016-06-26 7:41 UTC (permalink / raw) To: Jonathan Woithe, Darren Hart, Jan-Marek Glogowski Cc: platform-driver-x86, linux-kernel 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 ^ permalink raw reply related [flat|nested] 49+ messages in thread
* [PATCH] Register KEY_TOUCHPAD_TOGGLE with input device 2016-06-26 7:41 ` [PATCH] fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models Michał Kępień @ 2016-06-27 8:03 ` Jan-Marek Glogowski 2016-06-27 12:48 ` [PATCH] fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models Jonathan Woithe 1 sibling, 0 replies; 49+ messages in thread From: Jan-Marek Glogowski @ 2016-06-27 8:03 UTC (permalink / raw) To: Michał Kępień, Jonathan Woithe, Darren Hart Cc: platform-driver-x86, linux-kernel 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 ^ permalink raw reply related [flat|nested] 49+ messages in thread
* Re: [PATCH] fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models 2016-06-26 7:41 ` [PATCH] fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models Michał Kępień 2016-06-27 8:03 ` [PATCH] Register KEY_TOUCHPAD_TOGGLE with input device Jan-Marek Glogowski @ 2016-06-27 12:48 ` Jonathan Woithe 2016-06-27 12:55 ` Michał Kępień 2016-06-27 13:19 ` [PATCH v2] " Michał Kępień 1 sibling, 2 replies; 49+ messages in thread From: Jonathan Woithe @ 2016-06-27 12:48 UTC (permalink / raw) To: Micha?? K??pie?? Cc: Darren Hart, Jan-Marek Glogowski, platform-driver-x86, linux-kernel 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 -- ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models 2016-06-27 12:48 ` [PATCH] fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models Jonathan Woithe @ 2016-06-27 12:55 ` Michał Kępień 2016-06-27 13:19 ` [PATCH v2] " Michał Kępień 1 sibling, 0 replies; 49+ messages in thread From: Michał Kępień @ 2016-06-27 12:55 UTC (permalink / raw) To: Jonathan Woithe Cc: Darren Hart, Jan-Marek Glogowski, platform-driver-x86, linux-kernel > > 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ń ^ permalink raw reply [flat|nested] 49+ messages in thread
* [PATCH v2] fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models 2016-06-27 12:48 ` [PATCH] fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models Jonathan Woithe 2016-06-27 12:55 ` Michał Kępień @ 2016-06-27 13:19 ` Michał Kępień 2016-06-28 1:06 ` Jonathan Woithe 1 sibling, 1 reply; 49+ messages in thread From: Michał Kępień @ 2016-06-27 13:19 UTC (permalink / raw) To: Jonathan Woithe, Darren Hart Cc: Jan-Marek Glogowski, platform-driver-x86, linux-kernel 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 ^ permalink raw reply related [flat|nested] 49+ messages in thread
* Re: [PATCH v2] fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models 2016-06-27 13:19 ` [PATCH v2] " Michał Kępień @ 2016-06-28 1:06 ` Jonathan Woithe 2016-06-28 7:25 ` [PATCH v3] " Michał Kępień 0 siblings, 1 reply; 49+ messages in thread From: Jonathan Woithe @ 2016-06-28 1:06 UTC (permalink / raw) To: Micha?? K??pie?? Cc: Darren Hart, Jan-Marek Glogowski, platform-driver-x86, linux-kernel 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* [PATCH v3] fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models 2016-06-28 1:06 ` Jonathan Woithe @ 2016-06-28 7:25 ` Michał Kępień 2016-06-28 11:19 ` Jonathan Woithe 0 siblings, 1 reply; 49+ messages in thread From: Michał Kępień @ 2016-06-28 7:25 UTC (permalink / raw) To: Jonathan Woithe, Darren Hart Cc: Jan-Marek Glogowski, platform-driver-x86, linux-kernel 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 ^ permalink raw reply related [flat|nested] 49+ messages in thread
* Re: [PATCH v3] fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models 2016-06-28 7:25 ` [PATCH v3] " Michał Kępień @ 2016-06-28 11:19 ` Jonathan Woithe 2016-06-28 17:50 ` Darren Hart 0 siblings, 1 reply; 49+ messages in thread From: Jonathan Woithe @ 2016-06-28 11:19 UTC (permalink / raw) To: Micha?? K??pie?? Cc: Darren Hart, Jan-Marek Glogowski, platform-driver-x86, linux-kernel 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 -- ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH v3] fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models 2016-06-28 11:19 ` Jonathan Woithe @ 2016-06-28 17:50 ` Darren Hart 0 siblings, 0 replies; 49+ messages in thread From: Darren Hart @ 2016-06-28 17:50 UTC (permalink / raw) To: Jonathan Woithe Cc: Micha?? K??pie??, Jan-Marek Glogowski, platform-driver-x86, linux-kernel 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-25 9:15 ` Michał Kępień 2016-06-26 7:41 ` [PATCH] fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models Michał Kępień @ 2016-06-27 8:32 ` Jan-Marek Glogowski 2016-06-27 11:16 ` Michał Kępień 2016-06-29 13:59 ` Jani Nikula 1 sibling, 2 replies; 49+ messages in thread From: Jan-Marek Glogowski @ 2016-06-27 8:32 UTC (permalink / raw) To: Michał Kępień, Jonathan Woithe Cc: platform-driver-x86, Jani Nikula 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-27 8:32 ` Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 Jan-Marek Glogowski @ 2016-06-27 11:16 ` Michał Kępień 2016-06-27 11:40 ` Jan-Marek Glogowski 2016-06-29 13:59 ` Jani Nikula 1 sibling, 1 reply; 49+ messages in thread From: Michał Kępień @ 2016-06-27 11:16 UTC (permalink / raw) To: Jan-Marek Glogowski; +Cc: Jonathan Woithe, platform-driver-x86, Jani Nikula > >> 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ń ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-27 11:16 ` Michał Kępień @ 2016-06-27 11:40 ` Jan-Marek Glogowski 2016-06-27 12:40 ` Jonathan Woithe 0 siblings, 1 reply; 49+ messages in thread From: Jan-Marek Glogowski @ 2016-06-27 11:40 UTC (permalink / raw) To: Michał Kępień Cc: Jonathan Woithe, platform-driver-x86, Jani Nikula 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-27 11:40 ` Jan-Marek Glogowski @ 2016-06-27 12:40 ` Jonathan Woithe 0 siblings, 0 replies; 49+ messages in thread From: Jonathan Woithe @ 2016-06-27 12:40 UTC (permalink / raw) To: Jan-Marek Glogowski; +Cc: Micha?? K??pie??, platform-driver-x86, Jani Nikula 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-27 8:32 ` Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 Jan-Marek Glogowski 2016-06-27 11:16 ` Michał Kępień @ 2016-06-29 13:59 ` Jani Nikula 2016-06-29 15:38 ` Jani Nikula 1 sibling, 1 reply; 49+ messages in thread From: Jani Nikula @ 2016-06-29 13:59 UTC (permalink / raw) To: Jan-Marek Glogowski, Michał Kępień, Jonathan Woithe Cc: intel-gfx, Lankhorst, Maarten, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-29 13:59 ` Jani Nikula @ 2016-06-29 15:38 ` Jani Nikula 0 siblings, 0 replies; 49+ messages in thread From: Jani Nikula @ 2016-06-29 15:38 UTC (permalink / raw) To: Jan-Marek Glogowski, Michał Kępień, Jonathan Woithe Cc: platform-driver-x86, intel-gfx, Lankhorst, Maarten 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-22 7:32 ` Michał Kępień 2016-06-22 10:18 ` Jan-Marek Glogowski @ 2016-06-22 10:46 ` Jonathan Woithe 1 sibling, 0 replies; 49+ messages in thread From: Jonathan Woithe @ 2016-06-22 10:46 UTC (permalink / raw) To: Micha?? K??pie??; +Cc: Jan-Marek Glogowski, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* [PATCH 0/2] fujitsu-laptop: Debugging cleanup 2016-06-16 23:46 ` Jonathan Woithe 2016-06-17 9:20 ` Jan-Marek Glogowski @ 2016-06-23 10:02 ` Michał Kępień 2016-06-23 10:02 ` [PATCH 1/2] fujitsu-laptop: Use module name in debug messages Michał Kępień ` (2 more replies) 1 sibling, 3 replies; 49+ messages in thread From: Michał Kępień @ 2016-06-23 10:02 UTC (permalink / raw) To: Jonathan Woithe, Darren Hart Cc: Jan-Marek Glogowski, platform-driver-x86, linux-kernel 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* [PATCH 1/2] fujitsu-laptop: Use module name in debug messages 2016-06-23 10:02 ` [PATCH 0/2] fujitsu-laptop: Debugging cleanup Michał Kępień @ 2016-06-23 10:02 ` Michał Kępień 2016-06-23 10:02 ` [PATCH 2/2] fujitsu-laptop: Remove unused macros Michał Kępień 2016-06-23 10:35 ` [PATCH 0/2] fujitsu-laptop: Debugging cleanup Jonathan Woithe 2 siblings, 0 replies; 49+ messages in thread From: Michał Kępień @ 2016-06-23 10:02 UTC (permalink / raw) To: Jonathan Woithe, Darren Hart Cc: Jan-Marek Glogowski, platform-driver-x86, linux-kernel 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 ^ permalink raw reply related [flat|nested] 49+ messages in thread
* [PATCH 2/2] fujitsu-laptop: Remove unused macros 2016-06-23 10:02 ` [PATCH 0/2] fujitsu-laptop: Debugging cleanup Michał Kępień 2016-06-23 10:02 ` [PATCH 1/2] fujitsu-laptop: Use module name in debug messages Michał Kępień @ 2016-06-23 10:02 ` Michał Kępień 2016-06-23 10:35 ` [PATCH 0/2] fujitsu-laptop: Debugging cleanup Jonathan Woithe 2 siblings, 0 replies; 49+ messages in thread From: Michał Kępień @ 2016-06-23 10:02 UTC (permalink / raw) To: Jonathan Woithe, Darren Hart Cc: Jan-Marek Glogowski, platform-driver-x86, linux-kernel 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 ^ permalink raw reply related [flat|nested] 49+ messages in thread
* Re: [PATCH 0/2] fujitsu-laptop: Debugging cleanup 2016-06-23 10:02 ` [PATCH 0/2] fujitsu-laptop: Debugging cleanup Michał Kępień 2016-06-23 10:02 ` [PATCH 1/2] fujitsu-laptop: Use module name in debug messages Michał Kępień 2016-06-23 10:02 ` [PATCH 2/2] fujitsu-laptop: Remove unused macros Michał Kępień @ 2016-06-23 10:35 ` Jonathan Woithe 2016-06-28 17:49 ` Darren Hart 2 siblings, 1 reply; 49+ messages in thread From: Jonathan Woithe @ 2016-06-23 10:35 UTC (permalink / raw) To: Micha?? K??pie?? Cc: Darren Hart, Jan-Marek Glogowski, platform-driver-x86, linux-kernel 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH 0/2] fujitsu-laptop: Debugging cleanup 2016-06-23 10:35 ` [PATCH 0/2] fujitsu-laptop: Debugging cleanup Jonathan Woithe @ 2016-06-28 17:49 ` Darren Hart 0 siblings, 0 replies; 49+ messages in thread From: Darren Hart @ 2016-06-28 17:49 UTC (permalink / raw) To: Jonathan Woithe Cc: Micha?? K??pie??, Jan-Marek Glogowski, platform-driver-x86, linux-kernel 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-14 8:48 Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 Jan-Marek Glogowski 2016-06-16 23:46 ` Jonathan Woithe @ 2016-06-22 7:15 ` Michał Kępień 2016-06-22 10:07 ` Jan-Marek Glogowski 1 sibling, 1 reply; 49+ messages in thread From: Michał Kępień @ 2016-06-22 7:15 UTC (permalink / raw) To: Jan-Marek Glogowski; +Cc: Jonathan Woithe, platform-driver-x86 > 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ń ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-22 7:15 ` Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 Michał Kępień @ 2016-06-22 10:07 ` Jan-Marek Glogowski 2016-06-22 11:31 ` Michał Kępień 0 siblings, 1 reply; 49+ messages in thread From: Jan-Marek Glogowski @ 2016-06-22 10:07 UTC (permalink / raw) To: Michał Kępień; +Cc: Jonathan Woithe, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 2016-06-22 10:07 ` Jan-Marek Glogowski @ 2016-06-22 11:31 ` Michał Kępień 0 siblings, 0 replies; 49+ messages in thread From: Michał Kępień @ 2016-06-22 11:31 UTC (permalink / raw) To: Jan-Marek Glogowski; +Cc: Jonathan Woithe, platform-driver-x86 > 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ń ^ permalink raw reply [flat|nested] 49+ messages in thread
end of thread, other threads:[~2016-06-29 15:38 UTC | newest] Thread overview: 49+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-06-14 8:48 Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 Jan-Marek Glogowski 2016-06-16 23:46 ` Jonathan Woithe 2016-06-17 9:20 ` Jan-Marek Glogowski 2016-06-21 8:12 ` Jonathan Woithe 2016-06-22 7:32 ` Michał Kępień 2016-06-22 10:18 ` Jan-Marek Glogowski 2016-06-22 10:53 ` Jonathan Woithe 2016-06-22 11:23 ` Jan-Marek Glogowski 2016-06-22 12:39 ` Michał Kępień 2016-06-22 13:22 ` Jan-Marek Glogowski 2016-06-23 11:18 ` Michał Kępień 2016-06-23 12:08 ` Jan-Marek Glogowski 2016-06-23 12:35 ` Michał Kępień 2016-06-23 13:17 ` Jan-Marek Glogowski 2016-06-23 13:31 ` Michał Kępień 2016-06-23 13:42 ` Jan-Marek Glogowski 2016-06-23 17:23 ` Jan-Marek Glogowski 2016-06-24 7:12 ` Michał Kępień 2016-06-24 9:22 ` Jan-Marek Glogowski 2016-06-24 10:20 ` Michał Kępień 2016-06-24 11:39 ` Jan-Marek Glogowski 2016-06-24 15:43 ` Jan-Marek Glogowski 2016-06-24 20:17 ` Michał Kępień 2016-06-25 8:50 ` Jonathan Woithe 2016-06-25 9:15 ` Michał Kępień 2016-06-26 7:41 ` [PATCH] fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models Michał Kępień 2016-06-27 8:03 ` [PATCH] Register KEY_TOUCHPAD_TOGGLE with input device Jan-Marek Glogowski 2016-06-27 12:48 ` [PATCH] fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models Jonathan Woithe 2016-06-27 12:55 ` Michał Kępień 2016-06-27 13:19 ` [PATCH v2] " Michał Kępień 2016-06-28 1:06 ` Jonathan Woithe 2016-06-28 7:25 ` [PATCH v3] " Michał Kępień 2016-06-28 11:19 ` Jonathan Woithe 2016-06-28 17:50 ` Darren Hart 2016-06-27 8:32 ` Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 Jan-Marek Glogowski 2016-06-27 11:16 ` Michał Kępień 2016-06-27 11:40 ` Jan-Marek Glogowski 2016-06-27 12:40 ` Jonathan Woithe 2016-06-29 13:59 ` Jani Nikula 2016-06-29 15:38 ` Jani Nikula 2016-06-22 10:46 ` Jonathan Woithe 2016-06-23 10:02 ` [PATCH 0/2] fujitsu-laptop: Debugging cleanup Michał Kępień 2016-06-23 10:02 ` [PATCH 1/2] fujitsu-laptop: Use module name in debug messages Michał Kępień 2016-06-23 10:02 ` [PATCH 2/2] fujitsu-laptop: Remove unused macros Michał Kępień 2016-06-23 10:35 ` [PATCH 0/2] fujitsu-laptop: Debugging cleanup Jonathan Woithe 2016-06-28 17:49 ` Darren Hart 2016-06-22 7:15 ` Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6 Michał Kępień 2016-06-22 10:07 ` Jan-Marek Glogowski 2016-06-22 11:31 ` Michał Kępień
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.