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. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
