On Thu, May 19, 2016 at 3:50 AM, Zheng, Lv <lv.zheng@xxxxxxxxx> wrote: > Hi, > >> From: rjwysocki@xxxxxxxxx [mailto:rjwysocki@xxxxxxxxx] On Behalf Of >> Rafael J. Wysocki >> Subject: Re: [RFC PATCH 1/2] ACPI / button: Send "open" state after >> boot/resume [cut] >> > That's because of systemd implementation. >> > It contains code logic that: >> > When the lid state is closed, a re-checking mechanism is installed. >> > So if we do not send any notification after boot/resume and the old lid state >> is "closed". >> > systemd determines to suspend in the re-checking mechanism. >> >> If that really is the case, it is plain silly and I don't think we can >> do anything in the kernel to help here. > > [Lv Zheng] > The problem is: > If we just removed the 2 lines sending wrong lid state after boot/resume. > Problem couldn't be solved. > It could only be solved by changing both the systemd and the kernel (deleting the 2 lines). There are two things here, there's a kernel issue (sending the fake input events) and there's a user-visible problem. Yes, it may not be possible to fix the user-visible problem by fixing the kernel issue alone, but pretty much by definition we can only fix the kernel issue in the kernel. However, it looks like it may not be possible to fix the user-visible problem without fixing the kernel issue in the first place, so maybe we should do that and attach the additional user space patch to the bug entries in question? [cut] >> > I intentionally kept the _LID evaluation right after boot/resume. >> > Because I validated Windows behavior. >> > It seems Windows evaluates _LID right after boot. >> > So I kept _LID evaluated right after boot to prevent compliance issues. >> >> I don't quite see what compliance issues could result from skipping >> the _LID evaluation after boot. > > [Lv Zheng] > I'm not sure if there is a platform putting named object initialization code in _LID. > If you don't like it, we can stop evaluating _LID in the next version. Well, unless there is a well-documented reason for doing this, I'd at least try to see what happens if we don't. Doing things for unspecified reasons is not a very good idea overall IMO. [cut] >> > [Lv Zheng] >> > If we did this right now, many other userspace could be broken. >> > So we prepared the options to allow users to choose. >> >> Do we have any evidence that any other user space stacks are affected? > > [Lv Zheng] > I didn't know any of such affections except the systemd. So let's focus on this one until we actually find another example. -- 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
