I’m not sure what the differences would be between an android driver and an L4T driver, but it is interesting to think about. Understand that mostly the latency issue would be about hardware IRQ work load and how hardware IRQs sort/prioritize/schedule for calling. From what I’ve found out in the past, pretty much all SoC (including all ARM multi-core SoC at this time) which would work in a tablet or smart phone service the hardware IRQ on only a single CPU core, whereas desktop multicore will slow down less under heavy IRQ with the ability to service hardware IRQ on any core. Important because IRQ driven hardware latency beyond any given driver inefficiency mostly depends on that one core being available (all IRQ triggered hardware handling competes for this specific core).
If you have latency issues profiling with kernel drivers can be quite difficult (it isn’t necessarily always easy in user space, and components for the driver run in both user and kernel spaces at the same time). The thing to keep in mind on any system where only a single CPU core can handle an interrupt is that everything else with a hardware IRQ is competing. The latency might be a result of another driver which locks the first core for a long time, and ends up causing other hardware IRQ service to wait rather than being serviced immediately.
The HID driver isn’t something GPU acceleration can help with, I/O from an HID device like a mouse or stylus is very low/trivial bandwidth and the data too simple to care. Rendering of what was tracked can cause latency, for which something like hardware accel OpenGL ES helps in visualizing…in which case two hardware IRQs are involved…one to service the sylus, another to service graphics display of the stylus data. Graphics is already GPU accelerated, the HID stylus is so simple it doesn’t need GPU.
It is conceivable that graphics could cause a 100 ms latency, but the frame rate on Jetson under OpenGL ES is normally so much faster than this that it seems unlikely. So long as the I/O (such as from USB) hasn’t gone to sleep or set to a low power mode (adding wake up time), the HID layer (regardless of being USB or SPI) is just too simple to cause a significant workload.
I don’t know how to do it, but the smoking gun on the latency issue is more a question of which other hardware IRQ/hardware device is on average either holding on to the first core for the longest time, or causing the stylus to wait longer for IRQ handling. If you could disable non-critical hardware IRQ servicing (e.g., build support as a module and remove the module), then you might see a reduction in latency as an IRQ hog is removed. Maybe it is even simpler, perhaps some of the hardware can be disabled via sysctl.conf.
One thing you’d want to do under any circumstance is to make sure your testing is with Jetson in high performance mode, with no battery saving or sleep getting in the way. See this:
If you have a user space process running, you might also test latency with and without renicing the priority of that process.