Hi there,
I wanted to connect my Xavier to a touchscreen I found online and everything works great, but after around 2 min the touchscreen stops working and but the screen is still working.
Does anyone have a clue what the reason for this could be?
The Touchscreen is this:
Or does anyone know a touchscreen that is reliable working with the xavier?
Thanks
I wonder if perhaps the USB is thinking there is no activity and timing out, then going to low power/suspend mode. If you run “dmesg --follow” from some other connection (e.g., ssh or serial console), and note the touch component failure, is there new log in the “dmesg --follow” mentioning a USB low power or suspend?
If you add “usbcore.autosuspend=-1” to the “/boot/extlinux/extlinux.conf” file’s “APPEND” key/value pair (with your content being separated from other content by a space character), then boot and verify “cat /proc/cmdline” contains “usbcore.autosuspend=-1”, does the issue go away?
Hi,
Thanks for your tip.
Unfortunately this wasn’t the solution.
Running dmesg --follow didn’t show any change when the problem occured. I tested the usbcore.autosuspend change nonetheless, but didn’t improve the situation.
Any other idea what it might be?
Since there are no messages, and since removing usbcore.usbautosuspend (via =-1) did not help, perhaps looking at a different log would help. If you are in the GUI of your touchscreen, and run command “echo $DISPLAY”, then it will probably show as either “:0” or “:1”. The log files “/var/log/Xorg.#.log” will be used based on the “0” or “1” (if “:0”, then “/var/log/Xorg.0.log” is your log). Prior to the failure occurring, run this (preferably from serial console, possibly from ssh, but definitely not from the GUI):
sudo tail -f /var/log/Xorg.0.log
The log should remain silent until the failure occurs. If there is still no output, then the problem is quite different than one where Xorg realizes the touch input device is missing or disabled. What shows up in Xorg logs as the problem hits?
So I run the command from serial and got this as a output:
sudo tail -f /var/log/Xorg.0.log
[ 37.955] (II) event5 - gpio-keys: device removed
[ 37.955] () Option “fd” “41”
[ 37.956] (II) event4 - tegra-snd-t19x-mobile-rt565x Headset Jack: dev
ice removed
[ 37.956] () Option “fd” “35”
[ 37.956] (II) event8 - Logitech K400 Plus: device removed
[ 38.052] (II) systemd-logind: got pause for 13:70
[ 38.052] (II) systemd-logind: got pause for 13:72
[ 38.052] (II) systemd-logind: got pause for 13:68
[ 38.052] (II) systemd-logind: got pause for 13:71
[ 38.052] (II) systemd-logind: got pause for 13:69
[ 106.438] (II) config/udev: removing device 深圳市全动电子技术有限公司
ByQDtech 触控USB鼠标
[ 106.439] (II) UnloadModule: “libinput”
[ 106.439] (II) systemd-logind: releasing fd for 13:70
when the log at 106.438 occured the touchscreen stopped working.
Not really sure how to fix this.
Thanks for your great support!
If dmesg does not show, maybe you could check syslog (/var/log/syslog). Logs from ubuntu OS would be there.
Your xorg.log points out “udev:” here. Probably there is some specific udev rule remove the usb touch.
FYI, X has a modular plugin system. Graphics is from an NVDIA plugin, but in this case the USB mouse disconnected (XInput). Following disconnect, the libinput was unloaded (there was no longer a device, so this is expected). Note that (as mentioned by @WayneWWW) libinput goes by udev events to determine what is present or missing, but it is out of the control of the X server to know this information (X is just doing what it was told to do by a udev event, and udev was probably just going by what it saw happen in USB). Now your real task is to figure out why udev dropped the mouse…if you can answer this, then you will know what is happening to the touch screen.
If there is a USB error, then probably at the same moment there would be a log note in “dmesg” (e.g., if you “tail -f” Xorg logs and “dmesg --follow”, then both should print a message at the same moment).
There are a lot of reasons why a USB device might disconnect. One is from incorrect handling of a low power suspend mode, another is marginal signal quality (and dmesg might distinguish among them). For signal quality there could be some intermittent noise source in the environment, or the traces could be poorly designed.
Hi, I’ve exactly the same problem with my Jetson nano JetPack 4.4.
¿Any advance with this issue?
HI
I just ended up using a different screen. couldn’t solve the problem with this one.
could you please share which touchscreen you’ve ended up using? I’ve also got one on QDtech MPI5001 controller and it has exactly the same problem :/
We used this one :)
Hi!
Could you please describe how exactly you have solved the issue with touchscreen?
I am using Jetson Nano and 7 inch capacitive touchscreen. The touchscreen only works for the first 2 minutes after the start, then no reaction from it.
Please help!)
They described the solution. The solution was to use another screen.