[Bug]: installation not persistant on reboot up5401ea

[d4nkIot]

Describe the bug

There are 2 scenarios where everything works perfectly on my Vivobook S 14 Flip (TP3402ZA)

1. during session after sudo ./install.sh
2. during troubleshoot via debug command in terminal

The issue is, if I restart the laptop, it stops working (nothing happens when touching the numpad numlock).
Then, when I either re-run installation or troubleshoot (start LOG=DEBUG), it starts working normally.
However if I close the debug in terminal, then the numpad stops working again.
Even more strange, if I stop debug while the backlight is lit up, actually it stays lit up permanently. The backlight will even be lit after a reboot, however nothing works (numbers, or numpad numlock).

Any idea what I am doing wrong?

Expected behavior

After installation, stays persistent through reboot.

Relevant log output

No response

Desktop

• Program version: Latest
• Distro: Arch Linux
• Kernel: 6.1.4-arch1-1

[ldrahnik]

Hello there,
it looks like driver's service has not started after the laptop restart. Everything that you described supports this scenario. Restart and run sudo systemctl status asus_touchpad_numpad and please let me know the result.

[d4nkIot]

Thanks for getting back so fast!

[d4nkIot]

and by the way..

Should the Main PID and Memory be changing this much after reinstalling with after a reboot to get it to work?
Also the error about python-pip3, is this problematic?

[ldrahnik]

@d4nkIot

vendor preset: disabled

If you see a Vendor preset: Disabled, it means when the service first installs it will be disabled on start-up and will have to be manually started.

[ldrahnik]

@d4nkIot Arch python pip3 package name (that error) should be fixed in master, thank you :)

[ldrahnik]

@d4nkIot What is your output for the command ls /etc/systemd/system/ -la | grep asus ?

[d4nkIot]

Interesting... did not think that about preset: disabled.
Now indeed even restarting service will make everything work again after a reboot (non working state).

Here was the output you asked for:

Any idea why the systemd service would not be preset: enabled after installation (or by manually enabling the service later)?
I am about to sleep, will check back tomorrow. Thanks again for the support!

[d4nkIot]

@ldrahnik good morning. regarding the preset: disabled on the service, I guess this should have no impact on this scenario. Is it not normal behavior for all services to default to this statue in Arch, due to the 99-default.preset file set to *disable ?

e.g., the other asus drivers work function normally on start with same preset (as well as all other services like NetworkManager, SDDM, etc):

[ldrahnik]

@d4nkIot You're right. Preset is not used/ignored in arch distro. Helped adding sleep to file asus_touchpad.service?

# For some operating systems with boot failure, adding this following property might resolve the issue  
#ExecStartPre=/bin/sleep 2

[ldrahnik]

@d4nkIot Look at systemd log file and attach result here please. Should be there all attempts of service start in case start failed.

[d4nkIot]

@ldrahnik adding sleep did not work unfortunately

[ldrahnik]

@d4nkIot For example like this sudo journalctl --since today | grep asus:

Jan 11 12:26:44 ZenbookUP5401EAUP5401EA5d04e179 systemd[1]: asus_touchpad_numpad_suspend.service: Succeeded.
Jan 11 12:26:44 ZenbookUP5401EAUP5401EA5d04e179 systemd[1]: asus_touchpad_numpad.service: Succeeded.

[d4nkIot]

last 7 reboots today (current session have not restarted service manually to get it to work)
previous session i manually restarted to get it to work before reboot

[d4nkIot]

here with this sudo journalctl --since today | grep asus:

[ldrahnik]

@d4nkIot Could you please try an attempt with reinstalled the driver with non-xorg-11 service. Do a change in install.sh like this: [line 13] wayland_or_x11="foobar"

Co we could exclude a problem with different type simple, idle, Environment rows.. and because of that variables another target graphical.target.

[d4nkIot]

and 1 more screenshot from log, showing the process start normally after force restart in session

[d4nkIot]

@d4nkIot Could you please try an attempt with reinstalled the driver with non-xorg-11 service. Do a change in install.sh like this: [line 13] wayland_or_x11="foobar"

Co we could exclude a problem with different type simple, idle, Environment rows.. and because of that variables another target graphical.target.

okay, let me check it in a moment

[ldrahnik]

@d4nkIot Why is on the last screenshot in the last non-yellow row written "...servic" and not "...service"? I guess service restart was called so it's just autocompleting on background?

[d4nkIot]

@ldrahnik apologies, my last message was very confusing even for myself -- i deleted it :)

I reinstalled, changed line 13 as you suggested, and uncommented ExecStartPre=/bin/sleep 2

Same behavior as before, only works with forced starting in session.

As for your question regarding why the previous screenshot is missing an 'e', i checked and it was indeed an autocomplete, sorry for the confusions. It did indeed start the .service ultimately.

[ldrahnik]

@d4nkIot No problem, unfortunately, I have no more ideas atm. Is weird that other asus services have no problem with starting after boot.

[ldrahnik]

@d4nkIot Please attach log file cat /var/log/asus_touchpad_numpad-driver/error.log, best with clear installed (reinstalled) driver and after reboot.

[d4nkIot]

yes very strange indeed.
here is 1 more screenshot of all 3 drivers after reboot (sorry for so many :D)

-yellow box is again where prior numpad driver is not working, but works after manually restarting service
-green box is the last mention of touchpad_numpad , whereas the other 2 (fliplock, wmi_hotkeys) cycle through start/stop few more times and successfully start and function in session
.. so my question is, what causes the fliplock and wmi_hotkeys to have status=1/failure, thus causing a restart job to successfully get them working

[d4nkIot]

@d4nkIot Please attach log file cat /var/log/asus_touchpad_numpad-driver/error.log, best with clear installed (reinstalled) driver and after reboot.

asus-touchpad_numpad-driver-error.log
here you go, cleared logfile before reinstall and reboot (only line 13 = foobar, not the uncommented exec=bin)

[ldrahnik]

@d4nkIot Here we go:

ERROR:Pad:Can't find touchpad (code: 0)
ERROR:Pad:Listening touchpad events unexpectedly failed

[d4nkIot]

here from logfile is result from restarting service to get it to work

INFO:Pad:Getting Device Enabled via xinput failed
Unable to connect to X server
INFO:Pad:Getting Device Enabled via xinput failed
Unable to connect to X server
INFO:Pad:Getting Device Enabled via xinput failed
Unable to connect to X server
INFO:Pad:Getting Device Enabled via xinput failed
INFO:Pad:Detecting keyboard from string: "N: Name="AT Translated Set 2 keyboard""
INFO:Pad:Set keyboard 4 from H: Handlers=sysrq kbd leds event4
INFO:Pad:Detecting touchpad from string: "N: Name="ASUE140D:00 04F3:31BC Touchpad""
INFO:Pad:Set touchpad device id 14 from S: Sysfs=/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-14/i2c-ASUE140D:00/0018:04F3:31BC.0001/input/input18
INFO:Pad:Set touchpad id 8 from H: Handlers=event8 mouse1
INFO:Pad:Touchpad min-max: x 0-3880, y 0-2299
INFO:Pad:Numpad min-max: x 200-3680, y 200-2219
Unable to connect to X server
INFO:Pad:Getting Device Enabled via xinput failed
Unable to connect to X server
INFO:Pad:Getting Device Enabled via xinput failed
Unable to connect to X server
INFO:Pad:Getting Device Enabled via xinput failed
Unable to connect to X server
INFO:Pad:Getting Device Enabled via xinput failed
Unable to connect to X server

[d4nkIot]

@ldrahnik hello. find 4 log cases here:
compiled error log.log

1. pulled latest master, reinstalled, cleared log, reboot = not working
2. restart service in same session = working
3. changed bin/sleep timer 2, reboot = not working
4. restart service in same session = working

when it doesn't work after reboot, the device is touchpad device ... input/input10
when it does work after restart service, the device is touchpad device ... input/input20
does it change because I am restart service? or is that normal?

[ldrahnik]

@d4nkIot Nice clear report, thank you. Attempts have been done using asus_touchpad.X11.service? Do you use x11 and not wayland, right? You can check via the command echo $XDG_SESSION_TYPE.

[ldrahnik]

@d4nkIot About input id's do not worry, when is driver started every time is created new input device for sending characters/numbers from NumberPad. Creating these devices like touchpad, mouse, touchscreen etc is done asynchronously, so sometimes is input higher, sometimes lower. Who comes first have better number..

[d4nkIot]

@ldrahnik correct, X11 on KDE with SDDM.
++ gotcha on the touchpad device numbering.

[ldrahnik]

@d4nkIot Summary: It still looks like the driver is just starting too early, nothing else. 2 reasons, the first is x11 because is a problem with connecting to the main display, does not exist yet, x11 init is not finished and then we are not able to check the status of the touchpad device because for checking is used xinput, the tool which is under x11 and x11 is not started yet. Not started x11 yet describe these rows in the error log:

Invalid MIT-MAGIC-COOKIE-1 key
Unable to connect to X server
INFO:asus-touchpad-numpad-driver:Getting Device Enabled via xinput failed

Some people may suggest graphical.target on the system bus, but the problem with this is you need to manually set the > $DISPLAY and $XAUTHORITY environment variables in your service, you need to set User= and it will try to start when
reaching the display manager login screen instead of when the desktop environment is started.
(https://unix.stackexchange.com/questions/666509/systemd-service-does-not-start-wantedby-multi-user-target)

I have no exp it could be a problem, I use x11 and graphical.target does not do the problem for me (Ubuntu20.04), x11 is initialized already but it might do a problem as is described in this comment in stackowerflow especially when you, for example, use more monitors and any tool/configurator package for them.

The second problem is when we try not to check the status! but when we are trying listening touchpad device it says does not exist:

unable to find device ASUE140D:00 04F3:31BC Touchpad

Traceback (most recent call last):
  File "/usr/share/asus_touchpad_numpad-driver/asus_touchpad.py", line 1300, in <module>
    listen_touchpad_events()
  File "/usr/share/asus_touchpad_numpad-driver/asus_touchpad.py", line 1055, in listen_touchpad_events
    for e in d_t.events():
  File "/usr/lib/python3.10/site-packages/libevdev/device.py", line 536, in events
    ev = self._libevdev.next_event(flags)
  File "/usr/lib/python3.10/site-packages/libevdev/_clib.py", line 893, in next_event
    raise OSError(-rc, os.strerror(-rc))
OSError: [Errno 19] No such device
unable to find device ASUE140D:00 04F3:31BC Touchpad

What we could test more? I would like to confirm or refute that the second problem is connected to X11. Could you again please change the row in install.sh[13]: wayland_or_x11="foobar" and do the same report as you did without postponing driver start?

[d4nkIot]

@ldrahnik firstly --> 2 cases with foobar.log

1. reinstall after editing install.sh line 13 to foobar, no sleep timer added, clear log, restart = not working
2. on line 203 restart service in same session = working

[d4nkIot]

@ldrahnik I appreciate the help trying to troubleshoot this!!
Obviously it works fine after starting manually the service in session.. so for me now is still suitable as I probably don't use it that much ultimately anyway, and when I need just open terminal quickly -- so can consider the not automatically loading on start a minor unfavorable UX element :)

Maybe there might be another way to make the driver load later, once X11 is running -- or automate the manual starting of service later at some point before SDDM loads session. I will dig around some internet..

[ldrahnik]

@d4nkIot Please, could you try again? Please pull master. What's bothering me is keyboard device is loaded, every time, and touchpad device is at the same moment not found, it can be because adding input device consumes more time, for example, I do not know. So I added printing entire list of devices at that moment /proc/bus/input/devices. I already have there a touchpad device added, it is weird: ERROR:asus-touchpad-numpad-driver:N: Name="ASUE140D:00 04F3:31B9 Touchpad". I would compare that list with list of all devices when is laptop started. Could you do that? What I am interested in is Q: Is touchpad only device what is all time missing? Or are missing more devices? Missing more devices could confirm driver is loading too early.

[d4nkIot]

@ldrahnik sure, here is after pulling master and reinstalling: error.log

[ldrahnik]

@d4nkIot Could you please try it now? I pushed to master change - I added a line to the service unit BindsTo=graphical.target. Git pull, reinstall, restart laptop, sudo systemctl status asus_touchpad_numpad.service, post driver log here /var/log/asus_touchpad_numpad-driver/error.log. Thank you for testing, I would like to solve this if possible.

[d4nkIot]

@ldrahnik sure thing!
restart-after-line-106.log

[ldrahnik]

@d4nkIot Could you please try branch 78-not-started-driver, reinstall, restart and attach the entire log again.

[d4nkIot]

@ldrahnik here it is
78-not-started-driver-branch.log

[ldrahnik]

@d4nkIot And this version of is_x11_started.sh:

#!/bin/bash

if ! xset q &>/dev/null; then
    echo "No X server at \$DISPLAY [$DISPLAY]" >&2
    exit 1
fi

I am only interested if is printed echo "No X server at \$DISPLAY [$DISPLAY]" >&2 or not. Thank you a lot.

[d4nkIot]

@ldrahnik

[ldrahnik]

@d4nkIot Badly described, of course, is necessary to edit file is_x11_started.sh and install driver again and check log when is NumberPad driver starting and line is printed or not at that moment but I do not need to attach the entire log, that was what I tried to say.

[d4nkIot]

ah gotcha..
give me a moment

[d4nkIot]

@ldrahnik

No X server at $DISPLAY [:0]

[ldrahnik]

@d4nkIot Please again git pull branch, reinstall, restart and this time again attach entire log, I added to service line: [Unit] After=graphical.target systemd-user-sessions.service, might be helpful.

[d4nkIot]

@ldrahnik I will try again.
I was searching few things, and came across this:
https://wiki.archlinux.org/title/SDDM#X_authority_(aka_MIT-MAGIC-COOKIE)_file
--> related issue discussion

Do you think this is related (I use KDE - SDDM) since the previous logs were also throwing the similar errors mentioned?

Invalid MIT-MAGIC-COOKIE-1 key
Unable to connect to X server
ERROR:asus-touchpad-numpad-driver:Getting Device Enabled via xinput failed

[ldrahnik]

@d4nkIot Did you test that service proposal from mentioned git issue? Important to test is I think adding to [Unit]:

Requires=display-manager.service
After=display-manager.service

[d4nkIot]

@ldrahnik Here are the only 5 lines in log, from the updated branch. Same failed status as above as well.

No X server at $DISPLAY [:0]
No X server at $DISPLAY [:0]
No X server at $DISPLAY [:0]
No X server at $DISPLAY [:0]
No X server at $DISPLAY [:0]

I have not tested out what was suggested on the git issue, I will have more time later tonight to try.

[ldrahnik]

@d4nkIot Please let me know about any progress.

[d4nkIot]

@ldrahnik Hi, sorry been quite busy last few days.
As mentioned above, the error message shows no X server with the previous pull from git branch you updated.
I tried 2 different edited variations on the service unit, suggested from that SDDM git issue, without success. I need to look in more detail, and try some other ones later today or tomorrow when I have time.

[d4nkIot]

@ldrahnik Hi. FYI, I just had some time to test things out today... actually I got the lasted updated master, reinstalled, and now it works as intended! Issues are gone :)