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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
