RS232 COM port mouse can't work

I design carrier board for Xavier NX, when use COM port mouse can’t work, but use cmdline to test TX/RX are normal. Hardware design is USB to UART → UART to COM, I need to set the COM port parameters under Ubuntu?
Kernel version: 4.9.201-tegra

hello Tang_Chen,

you may access Jetson Xavier NX Product Design Guide for product design,
please also check similar topic for reference, Topic 52926.

We have disconnected the USB signal of the USB to COM circuit and connected it to another x86 MB USB port, test COM port mouse can use under x86 windows & Ubuntu system, so we can be sure the USB to COM circuit is correct, but if use the NVIDIA Jetson SDK system test the COM port mouse cannot working.
We need to install the driver or execute commands?

Is USB for that port recognized during boot? It sounds like it is a dedicated circuit board trace, and not a removable USB plug which connects to the UART. During boot, logs should show the USB itself being set up…if not, then the UART cannot function. The USB might need device tree content changed if the USB fails to show up in boot logs (emphasis on the USB which supports that “port”, regardless of whether it has a removable USB plug or not). Once USB sees the UART it should be possible for UART drivers to load.

Hi, linuxdev
I’m co-worker of Tang,
We just connect pl2303 chip to USB2_D_P and USB2_D_N (pin 123 and 121)
The driver is installed and device can get ttyUSB0. We tested UART TX/RX loopback and worked fine.

But the COM port mouse doesn’t work when we use following command

sudo inputattach --intellimouse /dev/ttyUSB0
inputattach: can't set line discipline

We test the same command on x86 Ubuntu and work fine.
I also try to dump the device.

sudo inputattach --dump /dev/ttyUSB0

I can get some garbled message. I think that UART is worked.
But the mouse cursor is still not worked.
Should I install other drivers?

I suspect it is a device tree issue, but have no way to prove it. Background follows…

During boot some devices are “plug-n-play”, and thus they self report what they are and where to find them. Most other devices have no way to report on what or where they are. This is the realm of passing arguments to the driver at the time of load so that the driver can find the device. The method of providing that argument is the device tree. If your USB chip (the pl2303) is at any address other than the one the device tree names, or if the device tree node has incorrect information (such as naming the driver which works with the pl2303), then USB itself will fail. Without USB the device connected to USB cannot self-report.

Custom board which are anything except an exact match to the dev kit will need device tree customization. Did you adjust the device tree? Or is this chip and its wiring an exact match to the dev kit?

Incidentally, you can extract the device tree via this (if you don’t have dtc, then “sudo apt-get install device-tree-compiler”):
dtc -I fs -O dts -o extracted.dts /proc/device-tree

If you know the address where the pl2303 is, then there should be a node with that hexadecimal address in it somewhere (leave out the 0x and grep for the address).

Yes, the pl2303 is plug and play usb device. When I install pl2303.ko, the usb can get the device and add /dev/ttyUSB0 device.
I modify the gpios about the pl2303 chip, you can get them in the dmesg.
I can’t find the pl2303 address in device tree.
Here is the dts file and dmesg.log
dmesg.log (63.9 KB)
extracted.dts (256.9 KB)

Because “/dev/ttyUSB0” is created we know the UART is up and running. The driver needs no further work, and hardware detection is complete (no need to worry about the device tree…also, since I now know the pl2303 is USB, the device tree would not apply to it…the device tree would apply to the root HUB, but we know the root HUB works because it sees the pl2303).

Everything up to and including the pl2303 is 100% functional. If you have a mouse or other item on that port, then that item will work. However, items on a serial UART cannot self-detect. This would not be a device tree entry (most likely) since a device tree entry is for a driver wanting to access something directly via a bus address. Instead you will need to add configuration to point the user of the mouse to “/dev/ttyUSB0”.

The above configuration is probably done from the user of the mouse, and I don’t know what you want to use this mouse with. Assuming this is the X server, or something which looks for any mouse device, one method of doing this is with a udev configuration. That configuration could rename “/dev/ttyUSB0” to something like “/dev/input/mouse1” (basically it would automatically increment the number in “/dev/input/mouse#” for each device). Most of the X server input is determined by conventions which are paired with udev rules for the input devices of interest.

Incidentally, I suspect you could temporarily test this with a symbolic link from “/dev/input/mouse1” (assuming this is the second mouse, but would be mouse0 if the only mouse) to “/dev/ttyUSB0”. A serial mouse is itself just a serial UART stream where the consumer of the content knows to treat it as a mouse.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.