Re: [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

From: Bastien Nocera <hadess@hadess.net>
To: "Zheng, Lv" <lv.zheng@intel.com>
Cc: "Brown, Len" <len.brown@intel.com>,
	"systemd-devel@lists.freedesktop.org"
	<systemd-devel@lists.freedesktop.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"Wysocki, Rafael J" <rafael.j.wysocki@intel.com>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Lv Zheng <zetalog@gmail.com>,
	Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	Lennart Poettering <mzxreary@0pointer.de>,
	"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>
Subject: Re: [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI
Date: Tue, 20 Jun 2017 00:08:47 +0200	[thread overview]
Message-ID: <1497910127.2559.1.camel@hadess.net> (raw)
In-Reply-To: <1AE640813FDE7649BE1B193DEA596E886CED1419@SHSMSX101.ccr.corp.intel.com>

On Mon, 2017-06-19 at 01:43 +0000, Zheng, Lv wrote:
> <snip>
> > 
> > If you implement it in such a way that GNOME settings daemon
> > behaves weirdly, you'll get my revert
> > request in the mail. Do. Not. Ever. Lie.
> 
> First, I don't know what should be reverted...
> I have 2 solutions here for review, and Benjamin has 1.
> And none of them has been upstreamed.
> We are just discussing.

The discussion is getting tiring quite frankly. We've been over this
for nearly a year now, and with no end in sight.

> However we need to get 1 of them upstreamed in next cycle.
> 
> I think users won't startup gnome-setting-daemon right after resume.
> It should have already been started.
> 
> There is only 1 platform may see delayed state update after resume.
> Let's see if there is a practical issue.
> 1. Before suspend, the "lid state" is "close", and
> 2. After resume, the state might remain "close" for a while
>    Since libinput won't deliver close to userspace,
>    and gnome-setting-daemon listens to key switches, there is no
> wrong behavior.

It doesn't. It listens to UPower, which tells user-space whether there
is a lid switch, and whether it's opened or closed.

> 3. Then after several seconds, "open" arrives.
>    gnome-setting-daemon re-arrange monitors and screen layouts in
> response to the new event.

Just how is anyone supposed to know that there is an event coming?

> So there is no problem. IMO, there is no need to improve for post-
> resume case.
> 
> Users will just startup gnome-setting-daemon once after boot.
> And it's likely that when it is started, the state is correct.

You cannot rely on when gnome-settings-daemon will be started to make
*any* decision. Certainly not decisions on how the kernel should
behave.

> IMO, there might be a chance to improve for post-boot case using
> Benjamin's approach.
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel