Help with libinput debug

[Peter Hutterer]

On Wed, Aug 16, 2017 at 11:36:02PM +0200, Corentin Marciau wrote:
> Hello,
> 
> I'm trying to build and test libinput but I can't figure out how.
> I followed the documentation :
> 
> 	meson --prefix=/usr builddir
> 	ninja -C builddir
> 	sudo ninja -C builddir install
> 	sudo udevadm hwdb --update
> 
> All went so well that I cried of joy. Then I tried to add something like a
> log message in evdev-mt-touchpad-tap.c @ tp_tap_touch_handle_event to see if
> my modifs where taken into account :
> 
> 	case TAP_EVENT_RELEASE:
> 		evdev_log_debug(tp->device,
> 		                "Isn't that a nice tap ?\n");
> 
> But nothing came out in ~/.local/share/xorg/Xorg.0.log, where I expected the
> logs would go. Even though I :
> - Restarted X
> - Checked the correct lib was linked to libinput.so
> - Recompiled with libinput->log_priority = LIBINPUT_LOG_PRIORITY_DEBUG;

the xf86-input-libinput handler overrides the log handlers and maps
libinput's log priority to X server ones. So unless you start the xserver
with a higher log verbosity (>= 10) you won't see the messages. Easiest way
around all this is to just add your debug messages as evdev_log_error(),
that way you're guaranteed to see them with default verbosity.

> - Checked with lsof that libinput was using
>   ~/.local/share/xorg/Xorg.0.log
> - Checked in the sources of libinput_drv.so that the log priority was
>   set to Debug
> 
> Does anyone has a clue about what I did wrong ? And generally speaking, how
> do you test your modifications to libinput ?

- step one is always libinput debug-events (can be run from builddir as
  libinput-debug-events)
- step two for anything that relates to 'feel' is libinput debug-gui (can be
  run from builddir as libinput-debug-gui)
- step three is a wayland/xorg session

Always do step 1 and/or 2 first, because it's a much faster turnaround time.
And unless you're working on things like pointer acceleration where the
motion of the pointer matters a lot, libinput debug-events is likely
sufficient.

Also, if you're testing for a specific bug, I recommend recording an input
sequence that triggers that bug with evemu-record first, then replaying this
sequence. That way you're guaranteed to always hit the same code paths while
debugging.

Cheers,
   Peter