This patch adds 3 new options to weston.ini to allow
the user to change default constant_accel_factor,
min_accel_factor and max_accel_factor. If no options
are set, it falls back using defaults as it did before.
v2: create weston_config_section_get_double and use it
instead of manualy converting string to double.
v3: add default values in weston_config_get_double
instead of using conditionals.
v4: don't pass diagonal as pointer.
Other clients of an evdev device need to have the events they receive
be separated, in moment in time, from other events by an EV_SYN/
SYN_REPORT. This is the responsibility of the client who writes events
into the stream.
device->mt.slot is uninitialized when we're not receiving the
evdev slot events. Always use ID 0 as we do when we generate the
touch down and motion events.
For touchpads, device->dispatch is set up when exiting
evdev_handle_device() and a potential source for a memleak.
This can't actually happen at the moment, as evdev_handle_device() won't
fail for touchpads after setting up the dispatch but prevent this from
happening in the future.
If touches are already present on the device, absinfo has the currently
active touch slot. There's a race condition where the slot may change before
we enable the fd and we thus miss out on the ABS_MT_SLOT event. It's still
slightly more correct than assuming whatever comes next is slot 0.
For Protocol B devices, mtdev merely routes the events and is not needed.
For Protocol A devices, mtdev is needed, so fail for those devices now if we
mtdev fails.
mtdev as currently used in weston is a noop. mtdev's purpose is to convert
Protocol A devices (without ABS_MT_SLOT) to Protocol B devices (slots).
For Protocol B devices mtdev merely routes the events, so checking for
slots and then using mtdev based on that adds no functionality.
Check for ABS_MT_POSITION_X/Y instead and use that to categorise a device
as MT device. mtdev will provide us with a slotted protocol for all devices.
https://bugs.freedesktop.org/show_bug.cgi?id=54428
AC_USE_SYSTEM_EXTENSIONS enables _XOPEN_SOURCE, _GNU_SOURCE and similar
macros to expose the largest extent of functionality supported by the
underlying system. This is required since these macros are often
limiting rather than merely additive, e.g. _XOPEN_SOURCE will actually
on some systems hide declarations which are not part of the X/Open spec.
Since this goes into config.h rather than the command line, ensure all
source is consistently including config.h before anything else,
including system libraries. This doesn't need to be guarded by a
HAVE_CONFIG_H ifdef, which was only ever a hangover from the X.Org
modular transition.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
[pq: rebased and converted more files]
The issue was that touch::down event from the compositor to client apps
would send the previous motion events coordinates and this obviously made
the client do the wrong thing. This happened because we were not waiting
for a SYN event to come from evdev before sending down, motion or up events.
https://bugs.freedesktop.org/show_bug.cgi?id=51909
The original code would overrun since the calculation of the range did not
take into consideration the size of the entries in the table.
Cc:Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Rob Bradford <rob@linux.intel.com>
e->code is in the same range for ABS_ and for REL_. As the code currently
stands and for the current values in Linux's input.h there is no risk of a
problem. However just in case it would be wise to break after evaluating the
relative events.
Signed-off-by: Rob Bradford <rob@linux.intel.com>
The original code always set the finger_state to the appropriate bitmask
irrespective of whether the event was a press or a release. It would also blat
all members of the bitmask rather than ORing in the new bit for the event.
Cc:Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Rob Bradford <rob@linux.intel.com>
As said by krh: "Maybe we should also just call it an evdev_device
instead, shorter [and] not really ambiguous."
[krh: if my typo filled irc is going in a commit message, I'm at least going
to insert the missing words.]
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
evdev_led_update() does not really need the whole list of device at
once, it can be called one device at a time.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
evdev.c: In function 'evdev_led_update':
evdev.c:57:9: warning: ignoring return value of 'write', declared with
attribute warn_unused_result
Useless in this case.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Weston's notify_keyboard_focus_*() assume that a keyboard is present, if
they are called. With evdev, there might not always be a keyboard.
Also clean up the variable definition in evdev_notify_keyborad_focus().
I read that function through many times and finally had to grep where
does 'all_keys' come from.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Move all udev-related and now drm backend specific code into
compositor-drm.c.
This makes evdev.c free of udev and launcher-util, and allows it to be
used on Android.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
This makes the generic evdev code (i.e. the functions not relying on
udev) independent of launcher-util too. The aim is to allow re-using the
generic evdev code in the Android backend, where neither udev nor
launcher-util are available.
evdev_input_device_create() signature is changed:
- add the opened device file descriptor
- remove wl_display as unused
Also add a bit of failure logging.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
evdev_input_device_destroy() will completement the API of
evdev_input_device_create(), both being independent from udev.
Since the udev-specific device_removed() would only call
evdev_input_device_destroy() and do nothing else, device_remove() calls
are simply replaced with evdev_input_device_destroy().
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
