[systemd-devel] [RFC PATCH v3 2/5] ACPI: button: Extends complement switch event support for all modes

2017-05-26 Thread Lv Zheng
Surface Pro 3 is a typical platform where suspend/resume loop problem
can be seen.

The problem is due to a systemd 229 bug:
1. "ignore": always can trigger endless suspend/resume loop
2. "open": sometimes suspend/resume loop can be stopped
3. "method": always can trigger endless susped/resume loop
The buggy systemd unexpectedly waits for an explicit "open" event after
boot/resume or it will suspends. However even when kernel can send a
faked "open" to it, its state machine is still wrong, systemd may not
respond "close" events arrived after "open" or may suddenly suspend
without seeing any instant events.

Recent systemd 233 has fixed this issue:
1. "ignore": everything works fine;
2. "open": no suspend/resume cycle, but sometimes cannot suspend the
   platform again after the first resume;
3. "method": no suspend/resume cycle, but always cannot suspend the
 platform again after the first resume.
The conclusion is: for suspend/resume cycle issue, "ignore" mode fixes
everything, but current "method" mode is still buggy.
Differences are because button driver only implements complement switch
events for "ignore" mode. Without complement switch events, firmware
triggered "close" cannot be delivered to userspace (confirmed by
evemu-record).

The root cause of the lid state issues is the variation of the platform
firmware implementations:
1. Some platforms send "open" events to OS and the events arrive before
   button driver is resumed;
2. Some platforms send "open" events to OS, but the events arrive after
   button driver is resumed, ex., Samsung N210+;
3. Some platforms never send "open" events to OS, but send "open" events to
   update the cached _LID return value, and the update events arrive before
   button driver is resumed;
4. Some platforms never send "open" events to OS, but send "open" events to
   update the cached _LID return value, but the update events arrive after
   button driver is resumed, ex., Surface Pro 3;
5. Some platforms never send "open" events, _LID returns value sticks to
   "close", ex., Surface Pro 1.

Let's check the docking external display issues (see links below):
1. For case 1, both "method"/"ignore" modes can work correctly;
2. For case 2/4/5, both "method"/"ignore" modes cannot work correctly;
3. For case 3, "method" can work correctly while "ignore" mode cannot.
The conclusion is: for docking external display issue, though the issue
still needs graphics layer (graphics drivers or desktop managers) to be
improved to ensure no breakages for case 2/4/5 platforms, there is a case
where "method" mode plays better.

Thus ACPI subsystem has been pushed to revert back to "method" mode due to
regression rule and case 3 (platforms reported on the links should all be
case 3 platforms), and libinput developers have volunteered to help to
provide workarounds when graphics layer is not fixed or systemd is not
updated.

Thus this patch extends the complement switch event support to other modes
using new indication: generating complement switch event for BIOS notified
"close". So that when button driver is reverted back to "method" mode, it
won't act worse than "ignore" mode on fixed systemd.

Tested with systemd 233, all modes worked fine (no suspend/resume loop and
can suspend any times) after applying this patch.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=195455
  https://bugzilla.redhat.com/show_bug.cgi?id=1430259
Cc: 
Cc: Benjamin Tissoires 
Cc: Peter Hutterer 
Signed-off-by: Lv Zheng 

Signed-off-by: Lv Zheng 
---
 drivers/acpi/button.c | 116 +-
 1 file changed, 57 insertions(+), 59 deletions(-)

diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
index 874ba60..a72f5bf 100644
--- a/drivers/acpi/button.c
+++ b/drivers/acpi/button.c
@@ -108,6 +108,7 @@ struct acpi_button {
unsigned long pushed;
int last_state;
ktime_t last_time;
+   bool last_is_bios;
bool suspended;
 };
 
@@ -144,78 +145,71 @@ static int acpi_lid_notify_state(struct acpi_device 
*device,
struct acpi_button *button = acpi_driver_data(device);
int ret;
ktime_t next_report;
-   bool do_update;
 
/*
-* In lid_init_state=ignore mode, if user opens/closes lid
-* frequently with "open" missing, and "last_time" is also updated
-* frequently, "close" cannot be delivered to the userspace.
-* So "last_time" is only updated after a timeout or an actual
-* switch.
+* Ignore frequently replayed switch events.
+*
+* AML tables can put Notify(LID, xxx) in a notification method,
+* and handling the hardware events by executing the entry methods
+* (ex., _Qxx) may cause the notification method to be invoked
+* several times.
+* This check doesn't 

[systemd-devel] [RFC PATCH v3 1/5] ACPI: button: Add indication of BIOS notification and faked events

2017-05-26 Thread Lv Zheng
This patch adds a parameter to acpi_lid_notify_state() so that it can act
differently against BIOS notification and kernel faked events.

Cc: 
Cc: Benjamin Tissoires 
Cc: Peter Hutterer 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/button.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
index 6d5a8c1..874ba60 100644
--- a/drivers/acpi/button.c
+++ b/drivers/acpi/button.c
@@ -138,7 +138,8 @@ static int acpi_lid_evaluate_state(struct acpi_device 
*device)
return lid_state ? 1 : 0;
 }
 
-static int acpi_lid_notify_state(struct acpi_device *device, int state)
+static int acpi_lid_notify_state(struct acpi_device *device,
+int state, bool bios_notify)
 {
struct acpi_button *button = acpi_driver_data(device);
int ret;
@@ -360,7 +361,8 @@ int acpi_lid_open(void)
 }
 EXPORT_SYMBOL(acpi_lid_open);
 
-static int acpi_lid_update_state(struct acpi_device *device)
+static int acpi_lid_update_state(struct acpi_device *device,
+bool bios_notify)
 {
int state;
 
@@ -368,17 +370,17 @@ static int acpi_lid_update_state(struct acpi_device 
*device)
if (state < 0)
return state;
 
-   return acpi_lid_notify_state(device, state);
+   return acpi_lid_notify_state(device, state, bios_notify);
 }
 
 static void acpi_lid_initialize_state(struct acpi_device *device)
 {
switch (lid_init_state) {
case ACPI_BUTTON_LID_INIT_OPEN:
-   (void)acpi_lid_notify_state(device, 1);
+   (void)acpi_lid_notify_state(device, 1, false);
break;
case ACPI_BUTTON_LID_INIT_METHOD:
-   (void)acpi_lid_update_state(device);
+   (void)acpi_lid_update_state(device, false);
break;
case ACPI_BUTTON_LID_INIT_IGNORE:
default:
@@ -398,7 +400,7 @@ static void acpi_button_notify(struct acpi_device *device, 
u32 event)
case ACPI_BUTTON_NOTIFY_STATUS:
input = button->input;
if (button->type == ACPI_BUTTON_TYPE_LID) {
-   acpi_lid_update_state(device);
+   acpi_lid_update_state(device, true);
} else {
int keycode;
 
-- 
2.7.4

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Run a separate instance of systemd-networkd in a namespace?

2017-05-26 Thread Dmitrii Sutiagin

Hi everyone,

I'm trying to set up a VPN in a namespace, so I could use my base 
network connection as usual and at the same time spawn console or 
browser in that namespace where VPN is running. So far I've sorted out 
everything except DNS resolution. Inside namespace there is no 
systemd-networkd, so if my /etc/resolv.conf does not contain a valid 
external DNS server then DNS inside the namespace does not work. And 
since VPN tries to dynamically update /etc/resolv.conf (and with latest 
vpnc-script updates - actually communicates with systemd-resolved via 
busctl), I should not hardcode values in there. Openconnect inside a 
namespace is able to (somehow) talk with root namespace's 
systemd-networkd via busctl but systemd-resolved reports that "link X is 
not known", which is probably expected - this link is inside the 
namespace. So my ask is - can I somehow use systemd-resolved with such 
setup? I tried starting a separate process of systemd-resolved inside 
namespace directly and got:


-
...
Failed to register name: File exists
Could not create manager: File exists
-

Can I somehow change the dbus name used by resolved, and this way I 
could edit vpnc-script to use the modified name..? Looks like it's not 
possible but maybe I overlooked something.


Please share your thoughts!

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Systemd -- Using Environment variable in a Unit file from Environment File

2017-05-26 Thread Raghavendra. H. R
Hi All,

I'm in the situation where path of my server changes due to version change.
I don't want to modify my systemd unit file everytime, instead I want to go
ahead with my environement file for modification.

My Env file system.env contains environment variables

system.env

SERVER_PATH=/home/raghu/TAP/server/V110

In my systemd unit file I have included this enviroment file.

Tap.service

[Unit]
Description=Starting TAP server

[Service]
EnvironmentFile=/home/raghu/system.env
*WorkingDirectory=${SERVER_PATH}*
*ExecStart=/home/raghu/TAP/out  "./server.js"*

[Install]
WantedBy=multi-user.target

I'm stuck with the below error

*error: Cannot find module '/server.js'*

${SERVER_PATH} is not set to my WorkingDirectory. Instead of using this
variable, if I give the absolute path, my unit file works well.

Need help in resoling this issue.

--
Regards,

Raghavendra. H. R
(Raghu)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel