lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 15 May 2017 13:01:02 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Benjamin Tissoires <benjamin.tissoires@...hat.com>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        "Zheng, Lv" <lv.zheng@...el.com>,
        Jiri Eischmann <jeischma@...hat.com>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

On Mon, May 15, 2017 at 11:37 AM, Benjamin Tissoires
<benjamin.tissoires@...hat.com> wrote:
> On May 15 2017 or thereabouts, Rafael J. Wysocki wrote:
>> On Mon, May 15, 2017 at 9:45 AM, Benjamin Tissoires
>> <benjamin.tissoires@...hat.com> wrote:
>> > On May 12 2017 or thereabouts, Rafael J. Wysocki wrote:
>> >> On Friday, May 12, 2017 02:36:20 AM Zheng, Lv wrote:
>> >> > Hi,
>> >> >
>> >> > > From: Benjamin Tissoires [mailto:benjamin.tissoires@...hat.com]
>> >> > > Subject: Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"
>> >> > >
>> >> > > On May 11 2017 or thereabouts, Zheng, Lv wrote:
>> >> > > > Hi,
>> >> > > >
>> >> > > > > From: Benjamin Tissoires [mailto:benjamin.tissoires@...hat.com]
>> >> > > > > Subject: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"
>> >> > > > >
>> >> > > > > This reverts commit 77e9a4aa9de10cc1418bf9a892366988802a8025.
>> >> > > > >
>> >> > > > > Even if the method implementation can be buggy on some platform,
>> >> > > > > the "open" choice is worse. It breaks docking stations basically
>> >> > > > > and there is no way to have a user-space hwdb to fix that.
>> >> > > > >
>> >> > > > > On the contrary, it's rather easy in user-space to have a hwdb
>> >> > > > > with the problematic platforms. Then, libinput (1.7.0+) can fix
>> >> > > > > the state of the LID switch for us: you need to set the udev
>> >> > > > > property LIBINPUT_ATTR_LID_SWITCH_RELIABILITY to 'write_open'.
>> >> > > > >
>> >> > > > > When libinput detects internal keyboard events, it will
>> >> > > > > overwrite the state of the switch to open, making it reliable
>> >> > > > > again. Given that logind only checks the LID switch value after
>> >> > > > > a timeout, we can assume the user will use the internal keyboard
>> >> > > > > before this timeout expires.
>> >> > > > >
>> >> > > > > For example, such a hwdb entry is:
>> >> > > > >
>> >> > > > > libinput:name:*Lid Switch*:dmi:*svnMicrosoftCorporation:pnSurface3:*
>> >> > > > >  LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=write_open
>> >> > > >
>> >
>> > [...]
>> >
>> >>
>> >> Well, if it worked in a specific way that users depended on before the commit in
>> >> question and now it works differently, then it does break things.
>> >>
>> >> Benjamin, my understanding is that this is the case, is it correct?
>> >
>> > That is correct. This patch I reverted introduces regression for professional
>> > laptops that expect the LID switch to be reported accurately.
>>
>> And from a user's perspective, what does not work any more?
>
> If you boot or resume your laptop with the lid closed on a docking
> station while using an external monitor connected to it, both internal
> and external displays will light on, while only the external should.
>
> There is a design choice in gdm to only provide the greater on the
> internal display when lit on, so users only see a gray area on the
> external monitor. Also, the cursor will not show up as it's by default
> on the internal display too.
>
> To "fix" that, users have to open the laptop once and close it once
> again to sync the state of the switch with the hardware state.

OK

Yeah, that sucks.

So without the Lv's patch the behavior (on the systems in question) is
as expected, right?

Thanks,
Rafael

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ