From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
"Zheng, Lv" <lv.zheng@intel.com>,
Jiri Eischmann <jeischma@redhat.com>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"
Date: Mon, 15 May 2017 15:05:31 +0200 [thread overview]
Message-ID: <20170515130531.GC11762@mail.corp.redhat.com> (raw)
In-Reply-To: <CAJZ5v0iD33i4B+gFvKLOnLKB557eLx1yzFCJeiR6hghD9fmKeQ@mail.gmail.com>
On May 15 2017 or thereabouts, Rafael J. Wysocki wrote:
> On Mon, May 15, 2017 at 11:37 AM, Benjamin Tissoires
> <benjamin.tissoires@redhat.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@redhat.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@redhat.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@redhat.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?
>
Yes, reverting these 2 patches restores the pre v4.11 kernel behavior.
Cheers,
Benjamin
next prev parent reply other threads:[~2017-05-15 13:05 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-10 16:12 [PATCH 0/2] acpi/button: revert v4.10 behavior Benjamin Tissoires
2017-05-10 16:12 ` [PATCH 1/2] Revert "ACPI / button: Remove lid_init_state=method mode" Benjamin Tissoires
2017-05-11 0:58 ` Zheng, Lv
2017-05-11 1:19 ` Zheng, Lv
2017-05-11 10:12 ` Benjamin Tissoires
2017-05-12 5:08 ` Zheng, Lv
2017-05-12 9:50 ` Benjamin Tissoires
2017-05-15 4:54 ` Zheng, Lv
2017-05-15 7:42 ` Benjamin Tissoires
2017-05-16 5:05 ` Zheng, Lv
2017-05-10 16:12 ` [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open" Benjamin Tissoires
2017-05-11 0:59 ` Zheng, Lv
2017-05-11 9:45 ` Benjamin Tissoires
2017-05-12 2:36 ` Zheng, Lv
2017-05-12 21:50 ` Rafael J. Wysocki
2017-05-15 7:45 ` Benjamin Tissoires
2017-05-15 9:17 ` Rafael J. Wysocki
2017-05-15 9:37 ` Benjamin Tissoires
2017-05-15 11:01 ` Rafael J. Wysocki
2017-05-15 13:05 ` Benjamin Tissoires [this message]
2017-05-16 5:33 ` Zheng, Lv
2017-05-16 5:47 ` Zheng, Lv
2017-05-16 7:15 ` Benjamin Tissoires
2017-05-16 8:30 ` Zheng, Lv
2017-05-16 10:10 ` Benjamin Tissoires
2017-05-17 7:32 ` Zheng, Lv
2017-05-17 11:54 ` Peter Hutterer
2017-05-17 14:16 ` Benjamin Tissoires
2017-05-24 8:08 ` Benjamin Tissoires
2017-05-24 23:01 ` Rafael J. Wysocki
2017-05-25 6:17 ` Zheng, Lv
2017-05-26 7:39 ` Peter Hutterer
2017-05-27 19:23 ` Rafael J. Wysocki
2017-05-11 0:09 ` [PATCH 0/2] acpi/button: revert v4.10 behavior Rafael J. Wysocki
2017-05-11 9:33 ` Benjamin Tissoires
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170515130531.GC11762@mail.corp.redhat.com \
--to=benjamin.tissoires@redhat.com \
--cc=jeischma@redhat.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lv.zheng@intel.com \
--cc=rafael@kernel.org \
--cc=rjw@rjwysocki.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).