In theory, the device could change between stat() call and open(), resulting
in us opening the new device. Change to open() first, then fstat() on the fd.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
tools/libevdev-tweak-device.c:390: uninit_use_in_call: Using uninitialized
value "changes" when calling "parse_options_abs".
tools/libevdev-tweak-device.c:376: warning: 'led' may be used uninitialized in
this function
tools/libevdev-tweak-device.c:375: warning: 'axis' may be used uninitialized
in this function
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is the caller's responsibility, for two reasons:
* we don't know if O_NONBLOCK is set, so draining the fd isn't a simple matter
of read() until EAGAIN. A select() + read() could work around this of
course.
* for stateless information, keys and relative data, it is not a problem when
there are events waiting on the fd already, they are processed correctly,
albeit with a delay.
So punt this decision to the caller, they openend the fd, they know if they
care about delayed events, they can drain the fd before handing it to us.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Acked-by: David Herrmann <dh.herrmann@gmail.com>
This change will only affect certain touch screens, for which the driver
integration code does not provide meaningful values for the allowed range
of ABS_MT_TRACKING_IDs. The reported range [0, 0] will be overwritten with
[-1, 0xFFFF]
Signed-off-by: Andreas Pokorny <andreas.pokorny@canonical.com>
[Changed from INT_MAX to 0xFFFF to match the kernel, add device name to log
message]
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We're starting to collect overrides for custom devices, making this easier for
users and saves us time. Once we measured everything, print out a
guesstimated udev rule and instructions on how to calculate the resolution.
Extra output now is:
Touchpad size as listed by the kernel: 132x111mm
Calculate resolution as:
x axis: 6076/<width in mm>
y axis: 5021/<height in mm>
Suggested udev rule:
# <Laptop model description goes here>
evdev:input:b0005v05ACp030E*
EVDEV_ABS_01=-2694:2862:<x resolution>
EVDEV_ABS_02=-20:121:<y resolution>
EVDEV_ABS_35=-2694:2862:<x resolution>
EVDEV_ABS_36=-20:121:<y resolution>
The ABS_MT_ axes are only printed if the device have them, if the device isn't
bluetooth/usb we print the dmi modalias instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
So far, 100% of the usages for tweak-tool was to set the x/y resolution of a
device. Make --resolution a shortcut for this.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Make the code base a bit more modular so it's easier to add new commands.
Main change here is: options are parsed twice now, first time for the mode
(abs/led) and the device path, then again for the mode-specific options.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The returned errno from libevdev_input_create_from_device was returned
incorrectly because libevdev_uinput_destroy() would try to close the
unset value of ->fd, overwriting errno.
That was fixed in debe9b030c, this patch avoids
the ioctl/close calls if the fd isn't set.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some devices scale the frequency based on the input and will provide
recordings with different frequencies each time. Recommend to measure multiple
times since we can only know what the highest frequency is.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
clang looks at GCC pragmas, but doesn't understand -Woverride-init. Instead,
it uses -Winitializer-overrides.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Relative devices don't provide a physical resolution to the host. For things
like pointer acceleration, the physical amount of movement is better as
baseline than the movement in device units.
Alas, many devices don't come with any information at all, so the users have
to guess. Help that guesswork by providing a tool that does the calculations
for them.
This tool measures the device units covered, then prints the frequency and an
lookup table for various resolutions (in dpi) to match to the physical
movement of the device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
These were removed in (7da329b) because for some reason they got copied into
the output. That was either a buggy doxygen or just some other problem. Add
them again, makes it much easier to read the header file.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
