Re: [systemd-devel] Persistent address on "Lost carrier"

[Amish]

On Friday 16 June 2017 01:06 PM, Lennart Poettering wrote:

On Thu, 15.06.17 18:22, Amish (anon.am...@gmail.com) wrote:


Hmm, that wasn't the actual question though, was it? The point was just
to make networkd ignore carrier status (i.e. often there's no need to
remove addresses just because the interface is down for a moment), not
to stop managing halfway.

Adding an option "IgnoreCarrier=" or so would be OK I figure. Best way
to get it implemented is submitting a PR for it ;-)



Ok I am completely new to systemd.

So looking at the code and trying to figure out the flow.

I believe I have to add IgnoreCarrier option in link-config.[ch] file.

Function that handles "Lost/Gain Carrier" is in networkd-link.c

There are two struct here: one is "link_config" and other is "Link"

link-config is what will store boolean ignore_carrier. (or any 
configuration value)


Link is what stores actual link data. (carrier status)

I am kind of stuck at one place. Searched a lot - but could not figure out.

I could not find anyway to find underlying "link_config" associated with 
"Link".


For example:
Inside networkd-link.c how do I check this:

if (Link->link_config->ignore_carrier) {
// do nothing
}
else {
// continue existing code
}

Please also have a look at whatever I have done so far, here:
https://github.com/amishxda/systemd/commits/master

Thanks

Amish.

PS: Dont know if this list is right place to ask such questions.
But since its "-devel" mailing list I am posting here.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Lennart Poettering]

On Fri, 16.06.17 11:06, Bastien Nocera (had...@hadess.net) wrote:

> > Let's consider this case with delay:
> > After resume, gnome-setting-daemon queries SW_LID and got "close".
> > Then it lights up the wrong monitors.
> > Then I believe "open" will be delivered to it several seconds later.
> > Should gnome-setting-daemon light-up correct monitors this time?
> > So it just looks like user programs behave with a delay accordingly because 
> > of the "platform turnaround" delay.
> 
> 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.

Just to mention this:

the reason logind applies the timeout and doesn't immediately react to
lid changes is to be friendly to users, if they quickly close and
reopen the lid. It's not supposed to be a work-around around broken
input drivers.

I am very sure that input drivers shouldn't lie to userspace. If you
don't know the state of the switch, then you don#t know it, and should
clarify that to userspace somehow.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Bastien Nocera]

> On 16 Jun 2017, at 10:53, Zheng, Lv  wrote:
> 
> Hi,
> 
>> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
>> Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID 
>> switch exported by ACPI
>> 
>>> On Jun 16 2017 or thereabouts, Zheng, Lv wrote:
>>> Hi, Benjamin
>>> 
>>> Let me just say something one more time.
>>> 
 From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
>> 
>> [snip]
>>> 
>>> We can see:
>>> "logind" has already implemented a timeout, and will not respond lid 
>>> state
>>> unless it can be stable within this timeout period.
>>> I'm not an expert of logind, maybe this is because of 
>>> "HoldOffTimeoutSec"?
>>> 
>>> I feel "removing the input node for a period where its state is not 
>>> trustful"
>>> is technically identical to this mechanism.
>> 
>> but you'd be making kernel policy based on one userspace implementation.
>> e.g. libinput doesn't have a timeout period, it assumes the state is
>> correct when an input node is present.
> 
> Do you see practical issues?
 
 Yes, libinput can't rely on the LID switch information to disable
 touchpads/touchscreens that are potentially sending false positive.
>>> 
>>> "potential" doesn't mean "practical", right?
>> 
>> I was using potential to say that some actual devices are sending
>> rightful states, while others are not (we already named them a lot in
>> those countless threads). So potential here is from a user space
>> perspective where you are not sure if the state is reliable or not
>> (given we currently don't have this information about reliability).
>> 
>>> After applying my last version.
>>> There are no false-positives IMO.
>>> There are only delays for the reliable key events.
>>>   ^^
>>> While the "delay" is very common in computing world.
>> 
>> No, if there is a delay, there is a false positive, because the initial
>> state is wrong with respect to the device physical state.
>> 
>>> 
> After resume, SW_LID state could remain unreliable "close" for a while.
 
 This is not an option. It is not part of the protocol, having an
 unreliable state.
 
> But that's just a kind of delay happens in all computing programs.
> I suppose all power managing programs have already handled that.
> I confirmed no breakage for systemd 233.
> For systemd 229, it cannot handle it well due to bugs.
> But my latest patch series has worked the bug around.
> So I don't see any breakage related to post-resume incorrect state period.
> Do you see problems that my tests haven't covered?
 
 The problems are that you are not following the protocol. And if systemd
 233 works around it, that's good, but systemd is not the only listener
 of the LID switch input node, and you are still breaking those by
 refusing to follow the specification of the evdev protocol.
>>> 
>>> As you are talking about protocol, let me just ask once.
>>> 
>>> In computing world,
>>> 1. delay is very common
>>>   There are bus turnaround, network turnaround, ...
>>>   Even measurement itself has delay described by Shannon sampling.
>>>   Should the delay be a part of the protocol?
>> 
>> Please, you are either trolling or just kidding. If there are delays in
>> the "computing world", these has to be handled by the kernel, and not
>> exported to the user space if the kernel protocol says that the state is
>> reliable.
>> 
>>> 2. programs are acting according to rules (we call state machines)
>>>   States are only determined after measurement (like "quantum states")
>>>   I have Schroedinger's cat in my mind.
>>>   Events are determined as they always occur after measurement to trigger 
>>> "quantum jumps".
>>>   So for EV_SW protocol,
>>>   Should programs rely on the reliable "quantum jumps",
>>>   Or should programs rely on the unreliable "quantum states"?
>> 
>> No comments, this won't get us anywhere.
>> 
>>> 
>>> I think most UI programs care no about state stored in the input node,
>>> they only receive events raised from the input node.
>> 
>> Bullshit. When you launch such a program, you need to query the state
>> because you won't receive the event that happened way before the launch.
>> 
>>> Why should the kernel export a fade-in/fade-out input node to the UI 
>>> programs and ask them to change?
>>> 
>>> The only program that cares about the state stored in the input node is 
>>> libinput.
>>> So why should every user program be changed to make libinput easier?
>> 
>> No, all program that listen to LID switches input nodes care about the
>> state. We already told you that, you just don't listen:
>> 
>> - systemd cares about the state as it does polling on the input node in
>>  case it misses an event
>> - libinput cares about the state as previously mentioned
>> - gnome-setting-daemons cares about the state given it decides whether
>>  or not 

Re: [systemd-devel] [rsyslog] Rsyslog & newlines

[Renjith Vijayan]

Hi Lennart,

I tested this on Systemd v229 & observed this behavior.

Thanks,
RV

On Fri, Jun 16, 2017 at 1:03 PM, Lennart Poettering 
wrote:

> On Thu, 15.06.17 15:17, Renjith Vijayan (renjith...@gmail.com) wrote:
>
> > + Systemd-dev
> >
> > Hi,
> >
> > Does journal ignore the forwarding of logs ending with newline(\n) to
> > rsyslog? In my system there are some logs send directly via
> > sd_journal_send() API and ending with newline.
> > These logs are present in journal, but not in /var/log/messages.
> >
> > Rainer confirmed that rsyslog does accept logs with newline as seen in
> mail
> > below. So is this the case where journal not forwarding the logs due to
> > newline?
>
> Note that the behaviour of journald regarding embedded newlines
> changed a couple of times in the past. Have you tested this with a
> current systemd version?
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Benjamin Tissoires]

On Jun 16 2017 or thereabouts, Zheng, Lv wrote:
> Hi, Benjamin
> 
> Let me just say something one more time.
> 
> > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]

[snip]
> > > > >
> > > > > We can see:
> > > > > "logind" has already implemented a timeout, and will not respond lid 
> > > > > state
> > > > > unless it can be stable within this timeout period.
> > > > > I'm not an expert of logind, maybe this is because of 
> > > > > "HoldOffTimeoutSec"?
> > > > >
> > > > > I feel "removing the input node for a period where its state is not 
> > > > > trustful"
> > > > > is technically identical to this mechanism.
> > > >
> > > > but you'd be making kernel policy based on one userspace implementation.
> > > > e.g. libinput doesn't have a timeout period, it assumes the state is
> > > > correct when an input node is present.
> > >
> > > Do you see practical issues?
> > 
> > Yes, libinput can't rely on the LID switch information to disable
> > touchpads/touchscreens that are potentially sending false positive.
> 
> "potential" doesn't mean "practical", right?

I was using potential to say that some actual devices are sending
rightful states, while others are not (we already named them a lot in
those countless threads). So potential here is from a user space
perspective where you are not sure if the state is reliable or not
(given we currently don't have this information about reliability).

> After applying my last version.
> There are no false-positives IMO.
> There are only delays for the reliable key events.
>^^
> While the "delay" is very common in computing world.

No, if there is a delay, there is a false positive, because the initial
state is wrong with respect to the device physical state.

> 
> > > After resume, SW_LID state could remain unreliable "close" for a while.
> > 
> > This is not an option. It is not part of the protocol, having an
> > unreliable state.
> > 
> > > But that's just a kind of delay happens in all computing programs.
> > > I suppose all power managing programs have already handled that.
> > > I confirmed no breakage for systemd 233.
> > > For systemd 229, it cannot handle it well due to bugs.
> > > But my latest patch series has worked the bug around.
> > > So I don't see any breakage related to post-resume incorrect state period.
> > > Do you see problems that my tests haven't covered?
> > 
> > The problems are that you are not following the protocol. And if systemd
> > 233 works around it, that's good, but systemd is not the only listener
> > of the LID switch input node, and you are still breaking those by
> > refusing to follow the specification of the evdev protocol.
> 
> As you are talking about protocol, let me just ask once.
> 
> In computing world,
> 1. delay is very common
>There are bus turnaround, network turnaround, ...
>Even measurement itself has delay described by Shannon sampling.
>Should the delay be a part of the protocol?

Please, you are either trolling or just kidding. If there are delays in
the "computing world", these has to be handled by the kernel, and not
exported to the user space if the kernel protocol says that the state is
reliable.

> 2. programs are acting according to rules (we call state machines)
>States are only determined after measurement (like "quantum states")
>I have Schroedinger's cat in my mind.
>Events are determined as they always occur after measurement to trigger 
> "quantum jumps".
>So for EV_SW protocol,
>Should programs rely on the reliable "quantum jumps",
>Or should programs rely on the unreliable "quantum states"?

No comments, this won't get us anywhere.

> 
> I think most UI programs care no about state stored in the input node,
> they only receive events raised from the input node.

Bullshit. When you launch such a program, you need to query the state
because you won't receive the event that happened way before the launch.

> Why should the kernel export a fade-in/fade-out input node to the UI programs 
> and ask them to change?
> 
> The only program that cares about the state stored in the input node is 
> libinput.
> So why should every user program be changed to make libinput easier?

No, all program that listen to LID switches input nodes care about the
state. We already told you that, you just don't listen:

- systemd cares about the state as it does polling on the input node in
  case it misses an event
- libinput cares about the state as previously mentioned
- gnome-setting-daemons cares about the state given it decides whether
  or not lighting up the monitors depending on the state. And if you
  relaunch the daemon, it'll query the state to decide what is the best
  arrangement for the screens
- KDE should do the same (as it is not a daemon that can catch any
  events)

And I really don't know why I am telling you that. The rule is simple:
there is a kernel protocol, which is a contract between the kernel and
the user space. With such 

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

[Zheng, Lv]

Hi, Benjamin

Let me just say something one more time.

> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch 
> exported by ACPI
> 
> On Jun 16 2017 or thereabouts, Zheng, Lv wrote:
> > Hi,
> >
> > > From: linux-acpi-ow...@vger.kernel.org 
> > > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of
> Peter
> > > Hutterer
> > > Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID 
> > > switch exported by ACPI
> > >
> > > On Thu, Jun 15, 2017 at 07:33:58AM +, Zheng, Lv wrote:
> > > > Hi, Peter
> > > >
> > > > > From: Peter Hutterer [mailto:peter.hutte...@who-t.net]
> > > > > Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable 
> > > > > LID switch exported by ACPI
> > > > >
> > > > > On Thu, Jun 15, 2017 at 02:52:57AM +, Zheng, Lv wrote:
> > > > > > Hi, Benjamin
> > > > > >
> > > > > > > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> > > > > > > Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the 
> > > > > > > unreliable LID switch exported by
> ACPI
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > [Sorry for the delay, I have been sidetracked from this]
> > > > > > >
> > > > > > > On Jun 07 2017 or thereabouts, Lennart Poettering wrote:
> > > > > > > > On Thu, 01.06.17 20:46, Benjamin Tissoires 
> > > > > > > > (benjamin.tissoi...@redhat.com) wrote:
> > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > Sending this as a WIP as it still need a few changes, but it 
> > > > > > > > > mostly works as
> > > > > > > > > expected (still not fully compliant yet).
> > > > > > > > >
> > > > > > > > > So this is based on Lennart's comment in [1]: if the LID 
> > > > > > > > > state is not reliable,
> > > > > > > > > the kernel should not export the LID switch device as long as 
> > > > > > > > > we are not sure
> > > > > > > > > about its state.
> > > > > > > >
> > > > > > > > Ah nice! I (obviously) like this approach.
> > > > > > >
> > > > > > > Heh. Now I just need to convince Lv that it's the right approach.
> > > > > >
> > > > > > I feel we don't have big conflicts.
> > > > > > And I already took part of your idea into this patchset:
> > > > > > https://patchwork.kernel.org/patch/9771121/
> > > > > > https://patchwork.kernel.org/patch/9771119/
> > > > > > I tested my surface pros with Ubuntu, they are working as expected.
> > > > > >
> > > > > > > > > Note that systemd currently doesn't sync the state when the 
> > > > > > > > > input node just
> > > > > > > > > appears. This is a systemd bug, and it should not be handled 
> > > > > > > > > by the kernel
> > > > > > > > > community.
> > > > > > > >
> > > > > > > > Uh if this is borked, we should indeed fix this in systemd. Is 
> > > > > > > > there
> > > > > > > > already a systemd github bug about this? If not, please create 
> > > > > > > > one,
> > > > > > > > and we'll look into it!
> > > > > > >
> > > > > > > I don't think there is. I haven't raised it yet because I am not 
> > > > > > > so sure
> > > > > > > this will not break again those worthless unreliable LID, and if 
> > > > > > > we play
> > > > > > > whack a mole between the kernel and user space, things are going 
> > > > > > > to be
> > > > > > > nasty. So I'd rather have this fixed in systemd along with the
> > > > > > > unreliable LID switch knowledge, so we are sure that the kernel 
> > > > > > > behaves
> > > > > > > the way we expect it to be.
> > > > > >
> > > > > > This is my feeling:
> > > > > > We needn't go that far.
> > > > > > We can interpret "input node appears" into "default input node 
> > > > > > state".
> > > > >
> > > > > Sorry, can you clarify this bit please? I'm not sure what you mean 
> > > > > here.
> > > > > Note that there's an unknown amount of time between "device node 
> > > > > appearing
> > > > > in the system" and when a userspace process actually opens it and 
> > > > > looks at
> > > > > its state. By then, the node may have changed state again.
> > > >
> > > > We can see:
> > > > "logind" has already implemented a timeout, and will not respond lid 
> > > > state
> > > > unless it can be stable within this timeout period.
> > > > I'm not an expert of logind, maybe this is because of 
> > > > "HoldOffTimeoutSec"?
> > > >
> > > > I feel "removing the input node for a period where its state is not 
> > > > trustful"
> > > > is technically identical to this mechanism.
> > >
> > > but you'd be making kernel policy based on one userspace implementation.
> > > e.g. libinput doesn't have a timeout period, it assumes the state is
> > > correct when an input node is present.
> >
> > Do you see practical issues?
> 
> Yes, libinput can't rely on the LID switch information to disable
> touchpads/touchscreens that are potentially sending false positive.

"potential" doesn't mean "practical", right?
After applying my last version.
There are no false-positives IMO.
There are only delays for 

Re: [systemd-devel] Persistent address on "Lost carrier"

[Lennart Poettering]

On Thu, 15.06.17 18:22, Amish (anon.am...@gmail.com) wrote:

> > Hmm, that wasn't the actual question though, was it? The point was just
> > to make networkd ignore carrier status (i.e. often there's no need to
> > remove addresses just because the interface is down for a moment), not
> > to stop managing halfway.

Adding an option "IgnoreCarrier=" or so would be OK I figure. Best way
to get it implemented is submitting a PR for it ;-)

> Yes thats what I am looking for.

Well, you'd still use the tool outside of its intended usecase, so
ymmv...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev hwdb add unknown button

[Lennart Poettering]

On Fri, 09.06.17 10:23, Floris (jkflo...@dds.nl) wrote:
1;4602;0c
> I have an older ASUS R2E UMPC[1], which has a couple of media buttons. One
> button isn't recognized and print:
> 
> asus_laptop: Unknown key 9a pressed
> 
> I tried to add this button with an udev hwdb rule in
> /etc/udev/hwdb.d/99-keyboard.hwdb
> 
> evdev:name:Asus Laptop extra buttons:dmi:bvn*:bvr*:bd*:svnASUS:pn*pvr*
>  KEYBOARD_KEY_95=keyboard <-- This one is added for testing 
> purposes
>  KEYBOARD_KEY_9a=screen
> 
> 
> after an udevadm update and trigger, udevadm info /dev/input/event5 reports
> the buttons:
> ...
> E: ID_PATH_TAG=platform-asus_laptop
> E: KEYBOARD_KEY_6b=f21<-- This one is a 
> default udev hwdb rule
> E: KEYBOARD_KEY_95=keybaord
> E: KEYBOARD_KEY_9a=screen
> E: LIBINPUT_DEVICE_GROUP=19/0/0/0:asus_laptop
> ...
> 
> So far everything works as expected, but evtest doesn't show the remap of
> the 9a key
> ...
> type 4 (EV_MSC), code 4 (MSC_SCAN), value 95
> type 1 (EV_KEY), code 374 (KEY_KEYBOARD), value 1 <-- This one is 
> modified
> as expected
> ...
> type 4 (EV_MSC), code 4 (MSC_SCAN), value 9a
> type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 1  <-- Why isn't 
> this one
> modified?
> ...
> 
> Only after adding {KE_KEY, 0x9a, { KEY_SCREEN } }, to asus-laptop.c line 355
> [2] and rebuild the kernel module, I am able to remap and use the media
> button on the laptop.
> 
> Is this a flaw in the kernel module or in udev?

Not all input devices permit overriding the scancode mappings, and
maybe your laptop driver is one of them?

Other than that, the only thing I can suggest is checking whether
issuing the scancode redifinition ioctls directly without udev's
involvement works. Not sure which tool to use for that, but I am sure
there's one.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [rsyslog] Rsyslog & newlines

[Lennart Poettering]

On Thu, 15.06.17 15:17, Renjith Vijayan (renjith...@gmail.com) wrote:

> + Systemd-dev
> 
> Hi,
> 
> Does journal ignore the forwarding of logs ending with newline(\n) to
> rsyslog? In my system there are some logs send directly via
> sd_journal_send() API and ending with newline.
> These logs are present in journal, but not in /var/log/messages.
> 
> Rainer confirmed that rsyslog does accept logs with newline as seen in mail
> below. So is this the case where journal not forwarding the logs due to
> newline?

Note that the behaviour of journald regarding embedded newlines
changed a couple of times in the past. Have you tested this with a
current systemd version?

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Benjamin Tissoires]

On Jun 16 2017 or thereabouts, Zheng, Lv wrote:
> Hi,
> 
> > From: linux-acpi-ow...@vger.kernel.org 
> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Peter
> > Hutterer
> > Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID 
> > switch exported by ACPI
> > 
> > On Thu, Jun 15, 2017 at 07:33:58AM +, Zheng, Lv wrote:
> > > Hi, Peter
> > >
> > > > From: Peter Hutterer [mailto:peter.hutte...@who-t.net]
> > > > Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID 
> > > > switch exported by ACPI
> > > >
> > > > On Thu, Jun 15, 2017 at 02:52:57AM +, Zheng, Lv wrote:
> > > > > Hi, Benjamin
> > > > >
> > > > > > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> > > > > > Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable 
> > > > > > LID switch exported by ACPI
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > [Sorry for the delay, I have been sidetracked from this]
> > > > > >
> > > > > > On Jun 07 2017 or thereabouts, Lennart Poettering wrote:
> > > > > > > On Thu, 01.06.17 20:46, Benjamin Tissoires 
> > > > > > > (benjamin.tissoi...@redhat.com) wrote:
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > Sending this as a WIP as it still need a few changes, but it 
> > > > > > > > mostly works as
> > > > > > > > expected (still not fully compliant yet).
> > > > > > > >
> > > > > > > > So this is based on Lennart's comment in [1]: if the LID state 
> > > > > > > > is not reliable,
> > > > > > > > the kernel should not export the LID switch device as long as 
> > > > > > > > we are not sure
> > > > > > > > about its state.
> > > > > > >
> > > > > > > Ah nice! I (obviously) like this approach.
> > > > > >
> > > > > > Heh. Now I just need to convince Lv that it's the right approach.
> > > > >
> > > > > I feel we don't have big conflicts.
> > > > > And I already took part of your idea into this patchset:
> > > > > https://patchwork.kernel.org/patch/9771121/
> > > > > https://patchwork.kernel.org/patch/9771119/
> > > > > I tested my surface pros with Ubuntu, they are working as expected.
> > > > >
> > > > > > > > Note that systemd currently doesn't sync the state when the 
> > > > > > > > input node just
> > > > > > > > appears. This is a systemd bug, and it should not be handled by 
> > > > > > > > the kernel
> > > > > > > > community.
> > > > > > >
> > > > > > > Uh if this is borked, we should indeed fix this in systemd. Is 
> > > > > > > there
> > > > > > > already a systemd github bug about this? If not, please create 
> > > > > > > one,
> > > > > > > and we'll look into it!
> > > > > >
> > > > > > I don't think there is. I haven't raised it yet because I am not so 
> > > > > > sure
> > > > > > this will not break again those worthless unreliable LID, and if we 
> > > > > > play
> > > > > > whack a mole between the kernel and user space, things are going to 
> > > > > > be
> > > > > > nasty. So I'd rather have this fixed in systemd along with the
> > > > > > unreliable LID switch knowledge, so we are sure that the kernel 
> > > > > > behaves
> > > > > > the way we expect it to be.
> > > > >
> > > > > This is my feeling:
> > > > > We needn't go that far.
> > > > > We can interpret "input node appears" into "default input node state".
> > > >
> > > > Sorry, can you clarify this bit please? I'm not sure what you mean here.
> > > > Note that there's an unknown amount of time between "device node 
> > > > appearing
> > > > in the system" and when a userspace process actually opens it and looks 
> > > > at
> > > > its state. By then, the node may have changed state again.
> > >
> > > We can see:
> > > "logind" has already implemented a timeout, and will not respond lid state
> > > unless it can be stable within this timeout period.
> > > I'm not an expert of logind, maybe this is because of "HoldOffTimeoutSec"?
> > >
> > > I feel "removing the input node for a period where its state is not 
> > > trustful"
> > > is technically identical to this mechanism.
> > 
> > but you'd be making kernel policy based on one userspace implementation.
> > e.g. libinput doesn't have a timeout period, it assumes the state is
> > correct when an input node is present.
> 
> Do you see practical issues?

Yes, libinput can't rely on the LID switch information to disable
touchpads/touchscreens that are potentially sending false positive.

> If not, should we avoid over-engineering at this moment?

It's not over-engineering. You are changing the specification of the
input node EV_SW event. And if systemd-whatever-version works currently
with your current patch, as long as you do not stick to the protocol
specification, systemd-whatever-version+N can break this. They will
be legitimate to do so because the kernel is not following the protocol.

> 
> After resume, SW_LID state could remain unreliable "close" for a while.

This is not an option. It is not part of the protocol, having an
unreliable state.

> But that's just a kind of delay