[Intel-gfx] Brightness and "touchpad dis-/enable" keys not working for Fujitsu e7x6

[Jani Nikula]

On Wed, 29 Jun 2016, Jani Nikula <jani.nikula at intel.com> wrote:
> On Mon, 27 Jun 2016, Jan-Marek Glogowski <glogow at 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