Trying to capture raw USB touchscreen data

Some years ago, I made a shell script + C program that filters data from a USB-touchscreen. It used the /usr/sbin/usbdump tool but with time delay value commented out to get real-time data. This had to be converted from hex byte pairs to decimal screen coordinates and passed to a POS-system program.
Now I have upgraded to FreeBSD 14 but the usbdump program has changed and I can't seem to get the delay out of it, so no real-time touchscreen operation. The old version is segfaulting, probably due to kernel differences, so that's no option.

Also, I can't seem to dump only 1 particular USB device, which should be possible according to usbdump -?, but usbdump -v -d ugen#.# to a touchscreen doesn't output anything at all.

Anybody knows how to capture raw traffic data from a USB-device, real-time, using FreeBSD 14?
 
Still not figured this out. Now translating uhid data to screen coordinates, but it doesn't allow distinguishing of screen touch and release actions. (Or I missed something)
I believe the official usbdump tool doesn't comply with the current USB stack anymore. I can't get anything out of it from this touchscreen, while the uhid device is reactive, so there must be USB-data. It sees data from the mouse and keyboard, though, even when they are on the same root hub as the touchscreen...

Using usbdump of FreeBSD 14.0, how do I scan and show -all- the data coming from ugen1.6 as shown by usbconfig?
 
It seems to be a deeper problem. The only way to get any data from the device is by reading the corresponding uhid device. This gives very limited information: only touch x and y values. No release-signal or multi-touch.
Anything else I tried (dd, cat, cp) results in I/O error.. The permisions on /dev/ugen*.* are set to a+rwx, so that's not the cause. Different ports and different cables don't change anything...

The touch device model is ILITEK Multi-Touch-V5700 placed in a Liyama t1732MSC monitor.
Is it possible that they intentionally screwed this up to prevent people from writing non-Windows drivers that utilize all capabilities?
 
Back
Top