-
Bug
-
Resolution: Fixed
-
P3
-
8
We have an option -Dlog.lens=finest that gives us all the raw events that we receive from input devices. This option is very useful for us but not useful for anyone who doesn't know the code in udevInput.c.
We frequently ask people to run getevent.c and send us the output. We already have the same functionality inside udevInput.c. We should have a command-line option "lens.input.trace" to provide just this output, in the format:
<timestamp seconds>.<timestamp ms> <event type> <event code> <event value>
For example,
180534723.456 EV_SYN EV_MT_REPORT 0
In addition, this option should show raw data we read concerning devices. It should not show our reasoning about devices, just raw data and final conclusions ("Skipping device", "Attaching as pointer device".
We should include udev monitor events.
The goal is that when someone has problems with an input device and we don't have the hardware in Oracle to reproduce the problem, we ask for a log with this option. The result should be understandable to people who are not familiar with JavaFX internals but do understand the Linux input event system.
We frequently ask people to run getevent.c and send us the output. We already have the same functionality inside udevInput.c. We should have a command-line option "lens.input.trace" to provide just this output, in the format:
<timestamp seconds>.<timestamp ms> <event type> <event code> <event value>
For example,
180534723.456 EV_SYN EV_MT_REPORT 0
In addition, this option should show raw data we read concerning devices. It should not show our reasoning about devices, just raw data and final conclusions ("Skipping device", "Attaching as pointer device".
We should include udev monitor events.
The goal is that when someone has problems with an input device and we don't have the hardware in Oracle to reproduce the problem, we ask for a log with this option. The result should be understandable to people who are not familiar with JavaFX internals but do understand the Linux input event system.