On Wed, 29 Jun 2016, Jani Nikula <jani.nikula@xxxxxxxxx> wrote: > 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! ;) 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@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
