On Mon, 27 Jun 2016, Jan-Marek Glogowski <glogow@xxxxxxxxxx> 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@xxxxxxxxx > > 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 -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
