| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
This was a bad idea. No-one seems to use this and it gives us little benefits.
To even get this feature a number of other features need to be turned off
(like two-finger scrolling and tapping). Many of these are enabled by default,
if they are disabled a client stack with full touchpad gesture support could
in theory support true touchpad gestures. This has never happened.
Drop the touch events from the synaptics driver. This allows us to switch the
touchpad fully over to look like a relative device, thus also removing the
bug that changes the touchpad speed whenever a monitor is added/removed in.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
Usually doesn't happen, but the evtest output in
https://bugs.freedesktop.org/show_bug.cgi?id=90392
actually has repeat events for the button. Ignore them if they happen.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
An MT device without X/Y is not a touchpad. And neither are fake MT devices.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
This came up as a kernel bug, but it's valid to create uinput devices with a
min == max range for x/y. Technically valid, but effectively useless, so catch
it, complain and hobble on along.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
This reverts commit 064445364b4775b25ba49c2250b22b169f291147.
The Lenovo *50 series, including the X1 Carbon 3rd always require multiple
kernel patches to enable the touchpad buttons. This patch in synaptics only
addresses the re-routing of the top buttons.
The final iteration of the kernel patches also route the trackpoint buttons
through the trackpoint device, rendering this patch unnecessary. These patches
are queued for 4.0.
See kernel patch series up to commit cdd9dc195916ef5644cfac079094c3c1d1616e4c
Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date: Sun Mar 8 22:35:41 2015 -0700
Input: synaptics - re-route tracksticks buttons on the Lenovo 2015 series
Currently in Dmitry's for-linus branch.
Distributions running older kernels or the kernel stable series which has
partial backports of the above patch series are encouraged to leave the
0644453 commit in and undo this revert.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
Some applications ignore the second tap of double taps because of the
lack of a delay between the button down and button up events.
Prevent this by replacing the transition from TS_2B to TS_START with a
transition from TS_2B to TS_SINGLETAP that emits only a button down
event. The button up event will be emitted when transitioning from
TS_SINGLETAP to TS_START.
In addition, decrease the default value of MaxDoubleTapTime from 180 ms
to 100 ms in order to make double taps faster.
Signed-off-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
This device has the trackpoint buttons wired up to the touchpad to send BTN_0,
BTN_1 and BTN_2 for left, right, middle. This conflicts with previous
touchpads that used those event codes for dedicated scroll buttons.
Add an option HasTrackpointButtons that can be set via a xorg.conf.d
snippets. This option is not intended as a user-set option, rather
we expect distributions to ship some conglomerate of udev/hal rules with
xorg.conf snippets that take effect.
If the option is set, we look at the three affected buttons at the beginning
of HandleState and send button events immediately for them. The HW state is
reset to neutral and other processing continues. This saves us from having to
synchronize these buttons with software buttons (also present on this device),
tapping, etc.
Since the buttons are physically different and (mentally) associated with the
trackpoint device we also don't need to worry about having finger motion event
correctly synced up with the button presses - it's acceptable to send the
presses before the motion events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
|
|
The palm detection relies on both the width and the pressure.
a897147be04 ("Use ABS_MT events for the palm detection when supported")
assumed that all the touch devices can report both ABS_MT_TOUCH_MAJOR
and ABS_MT_PRESSURE, but this is not necessarily true. This assumption
could hence break the palm detection when at least one of the mentioned
events is not declared but both ABS_TOOL_WIDTH and ABS_PRESSURE are
reported.
Signed-off-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Use ABS_MT_TOUCH_MAJOR and ABS_MT_PRESSURE instead of ABS_TOOL_WIDTH
and ABS_PRESSURE when supported so that the pressure and the width of
all the fingers is taken into account for the palm detection.
This also fixes the palm detection for those touchpads for which the
kernel only sends ABS_MT_TOUCH_MAJOR and not ABS_TOOL_WIDTH.
Signed-off-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Touchpads are limited by a fixed sampling rate (usually 80Hz). Some finger
changes may happen too fast for this sampling rate, resulting in two distinct
event sequences:
* finger 1 up and finger 2 down in the same EV_SYN frame. Synaptics sees one
finger down before and after and the changed coordinates
* finger 1 up and finger 2 down _between_ two EV_SYN frames. Synaptics sees one
touchpoint move from f1 position to f2 position.
That move causes a large cursor jump. The former could be solved (with
difficulty) by adding fake EV_SYN handling after releasing touchpoints but
that won't fix the latter case.
So as a solution for now limit the finger movement to 20mm per event.
Tests on a T440 and an x220 showed that this is just above what a reasonable
finger movement would trigger. If a movement is greater than that limit, reset
it to 0/0.
On devices without resolution, use 0.25 of the touchpad's diagonal instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
Default resolution is 1, don't allow setting 0 to avoid divisions by 0 or
just general weirdness.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
open_slots holds the slot index, resetting it to 0 is a bad idea. And make
sure that we do reset after DEVICE_INIT. We already do so on DEVICE_CLOSE, but
after the first DEVICE_ON the data could still be random.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
|
|
And warn when we run out of labels.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
|
|
xf86-input-synaptics-1.8.0/src/synaptics.c:498: var_compare_op: Comparing
"end_str" to null implies that "end_str" might be null.
end_str can't be null, so no need for this check and no need to get Coverity
all confused.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
|
|
Just to make it explicit
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
|
|
Signed-off-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Default on evdev devices is CLOCK_REALTIME. If that clock falls behind the
server's CLOCK_MONOTONIC, motion after a clickpad click may be delayed by the
difference in the clocks.
In detail:
When the timer func is triggered, GetTimeInMillis() which is CLOCK_MONOTONIC,
is stored as hwState->millis. The eventcomm backend uses struct
input_event time (CLOCK_REALTIME).
When we read events from the device, if the evdev time is less than the server
time, the fix for (#48777) sets the current event time to hwState->millis.
Until the evdev time overtakes that stored time, all events have the
hwState->millis time.
If during that time a clickpad triggers a physical click,
clickpad_click_millis is set to hwState->millis + the ignore-motion timeout.
Thus, all motion is ignored until the event time overtakes that stored
time.
The whole issue is further enhanced by us unconditionally setting the timer
func if we get any events, which is a separate issue anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
In file included from /usr/include/string.h:634:0,
from /usr/include/xorg/os.h:53,
from /usr/include/xorg/misc.h:115,
from /usr/include/xorg/xf86str.h:37,
from /usr/include/xorg/xf86Xinput.h:54,
from synproto.h:36,
from synproto.c:24:
/usr/include/xorg/os.h:579:1: error: expected identifier or '(' before '__extension__'
strndup(const char *str, size_t n);
See http://lists.freedesktop.org/archives/xorg-devel/2014-July/043070.html
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Potentially uninitialized, false positive in both cases.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
When two fingers are used, the coordinates of only one of them is taken into
account. This can lead to sudden variations of the absolute coordinates when
two-fingers taps are performed if the finger considered changes.
Take into account coordinates variations to prevent unwanted taps only if
the number of fingers doesn't change.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Per-device logging functions don't interfere with other drivers if they also
use libevdev, so use those instead the global log handler if available. If not
available, drop libevdev logging, I don't want to maintain the ifdef mess and
the logging doesn't give us _that_ much benefit.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
When we required a grab on the device, this was a shortcut so we didn't have
to query the device only to realise we can't read events off it anyway. Now
that we don't actually grab the device by default, this is unnecessary.
Something else may have a temporary grab on the device during init, in which
case we just continue as usual and read events if and when they become
available.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
Some Macbooks are being tagged as MODEL_UNIBODY_MACBOOKs when they should not
be. This causes the default sensitivity to be very low for them, making the
touchpad almost unusable. This change puts those devices into the correct
bucket again.
Signed-off-by: Clinton Sprain <clintonsprain@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Add a HasSecondaryButtons boolean config option which defaults to true for
devices with the INPUT_PROP_TOPBUTTONPAD and false for all other devices.
Only parse the SecondarySoftButtonAreas when this option is true, effectively
disabling the top buttons when it is false. Likewise, only initialize the
SecondarySoftButtonAreas property if we enable support for it.
This means that it is now safe to always set a SecondarySoftButtonAreas
default in 50-synaptics.conf, and that he section which was intended for
use with future pnp-id matching can be dropped, as that is now all handled
in the kernel.
While at also remove the comment about disabling the bottom edge area, as that
is now done automatically.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
When trying to do a 3 fingerclick on a touchpad which only tracks 2 touches,
this may register as a 3 or 2 fingerclick depending on the order in which
the touchpad detects the fingers. If the 2 outer fingers of the 3 get seen
first, then the 2 touches will be too far apart for the heuristic to see
them as being close together, and the click gets counted as a 2 finger click.
A user will likely never do a 2 finger click with a 3th finger resting
somewhere else on the pad, where-as the above misdetection of the clicks is
a real issue, so simply always count a click with trippletap set as a
3 finger click on pads which track less then 3 touches.
https://bugzilla.redhat.com/show_bug.cgi?id=1086218
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Everytime I look at this I get confused about OPEN_EMPTY vs EMPTY. Let's fix
that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
This is a bit problematic: libevdev only has one global log handler.
So if we have another driver use libevdev, we'll either overwrite that handler
or get overwritten, whichever comes first. So we need to re-set the handler
every time we get an event to make sure we log through our handler.
Likewise, if we ever drop the device, we need to unset the log handler back to
NULL because we may unload the module and our handler may disappear.
Use the lowest logging priority, let the server filter based on the verbosity
level instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
Once the sync finishes, we get -EAGAIN. This only indicates the sync is done,
but some events may still be waiting in the pipe for us to read. We must read
those now, otherwise select may not trigger on further data.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
last_mt_vals_slot is only used in one location and there we can just use
cur_slot
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
This was required when we started supporting hotplugging to avoid duplicate
events. These days the drawback of not being able to record events in the case
of a bug is significant.
Check the configuration source on init. If the device was hotplugged through a
a server config backend, disable the grab. If the device was statically
configured through an xorg.conf then leave the default grab enabled to avoid
a duplicate device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
Enabling clicks in off mode also allows for the new Lenovo *40 series to use
the top software buttons while the touchpad is disabled. This benefits those
that usually disable touchpads altogether but still need the buttons for the
trackstick.
This changes existing behaviour, but TouchpadOff was always intended to stop
erroneous events while typing. Physical button presses are hard to trigger
accidentally. On the touchpads that TouchpadOff concept was originally
designed for the buttons are nowhere near the keyboard and are physically
separated from the touchpad anyway. On Clickpads, triggering a physical
click requires more force than accidentally touching the surface.
https://bugs.freedesktop.org/show_bug.cgi?id=76156
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
clicks"
This third state is not needed, the behaviour of the touchpad driver is now
good enough to not need an external syndaemon instance to toggle this third
state.
This reverts commit eea73358760c7ff9c9dac061f265753637c6f25c.
Conflicts:
man/synaptics.man
src/synaptics.c
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Clicking in the top soft button area causes the trackpad to begin
registering motion, even if the finger never leaves the top soft button
area. We don't want this kind of behavior for the top soft button area,
since it makes clicking and dragging items much more difficult when
using a pointing stick.
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
All kernel touchpad devices now support slots, there isn't really a need to
support protocol A devices in synaptics. If such devices exist, we just treat
them as non-multitouch devices.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
|
|
When checking the device don't open a new mtdev instance, use the existing
libevdev struct.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
|
|
The kernel guarantees slots start at 0
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
|
|
This was supposed to emulate a SYN_REPORT event so that the upper layers
process what's in the queue.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
|
|
This was originally intended as a fixed xorg.conf option only (and still
largely is seen as such). Secondary software button are required only on a specific series
of touchpads and should be pre-configured by the system and/or the
distribution. As such, the property will not be initialized if it is not set
in the xorg.conf and will thus not respond to runtime changes.
Exposing the property in this way gives clients a chance of detecting if a top
software button area is present and thus adjust their behaviour accordingly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
It is possible for a click to get reported before any related touch events
get reported, here is the relevant part of an evemu-record session on a T440s:
E: 3.985585 0000 0000 0000 # ------------ SYN_REPORT (0) ----------
E: 3.997419 0003 0039 -001 # EV_ABS / ABS_MT_TRACKING_ID -1
E: 3.997419 0001 014a 0000 # EV_KEY / BTN_TOUCH 0
E: 3.997419 0003 0018 0000 # EV_ABS / ABS_PRESSURE 0
E: 3.997419 0001 0145 0000 # EV_KEY / BTN_TOOL_FINGER 0
E: 3.997419 0000 0000 0000 # ------------ SYN_REPORT (0) ----------
E: 5.117881 0001 0110 0001 # EV_KEY / BTN_LEFT 1
E: 5.117881 0000 0000 0000 # ------------ SYN_REPORT (0) ----------
E: 5.133422 0003 0039 0187 # EV_ABS / ABS_MT_TRACKING_ID 187
E: 5.133422 0003 0035 3098 # EV_ABS / ABS_MT_POSITION_X 3098
E: 5.133422 0003 0036 3282 # EV_ABS / ABS_MT_POSITION_Y 3282
E: 5.133422 0003 003a 0046 # EV_ABS / ABS_MT_PRESSURE 46
E: 5.133422 0001 014a 0001 # EV_KEY / BTN_TOUCH 1
E: 5.133422 0003 0000 3102 # EV_ABS / ABS_X 3102
E: 5.133422 0003 0001 3282 # EV_ABS / ABS_Y 3282
E: 5.133422 0003 0018 0046 # EV_ABS / ABS_PRESSURE 46
E: 5.133422 0001 0145 0001 # EV_KEY / BTN_TOOL_FINGER 1
E: 5.133422 0000 0000 0000 # ------------ SYN_REPORT (0) ----------
Notice the BTN_LEFT event all by itself!
If this happens, it may lead to the following problem scenario:
-touch the touchpad in its right click area
-let go of the touchpad
-rapidly click in the middle area, so that BTN_LEFT gets reported before the
new coordinates (such as seen in the trace above, this may require some
practicing with evemu-record to reproduce)
-the driver registers the click as a right click because it uses the
old coordinates from the cumulative coordinates to determine the
click location
This commit fixes this by:
1) Resetting the cumulative coordinates not only when no button is pressed,
but also when there is no finger touching the touchpad, so that when
we do get a touch the cumulative coordinates start at the right place
2) Delaying processing the BTN_LEFT down transition if there is no finger
touching the touchpad
This approach has one downside, if we wrongly identify a touchpad as
a clickpad, then the left button won't work unless the user touches the
touchpad while clicking the left button.
If we want we can fix this by doing something like this:
1) Making update_hw_button_state return a delay; and
2) Tracking that we've delayed BTN_LEFT down transition processing; and
3) When we've delayed BTN_LEFT down transition return a small delay value; and
4) If when we're called again we still don't have a finger down, just
treat the click as a BTN_LEFT
But this is not worth the trouble IMHO, the proper thing to do in this
scenario is to fix the mis-identification of the touchpad as a clickpad.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
When a button click and new coordinates get reported in one go we sync the
cumulative coordinates to the old x and y, rather then the newly reported ones.
This keeping of the old coordinates causes the following issue:
-touch the touchpad in its right click area
-let go of the touchpad
-rapidly click in the left click area (or middle area), so that the
new location and the click get reported in one syn (may require some
practicing with evemu-record to reproduce)
-the driver registers the click as a right click because it uses the
old coordinates from the cumulative coordinates to determine the
click location
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
This fixes my #1 anoyance with clickpads, where 2 out of 3 clicks turn into
a click + drag unless I hold my finger really really still.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Replaced property with a hardcoded 100ms. This is not something that we should
expose as property, we should find a delay that works best and live with it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Unless the motion has started outside the soft-button area.
Note that we must start reporting motions regardless of whether we think we're
in the button area or not as soon as we've switched to using cumulative
coordinates, since then the coordinates are no longer absolute.
This fixes the reporting of unintended motion just before a click in a soft
button area which sometimes causes mis-clicks.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
We only use it to store button state which we already have in
priv->lastButtons.
While at it also properly indent the code block checking the various
soft button areas.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
While at it also move the enum for the soft button edges out of
is_inside_button_area() so that it can be used elsewhere too.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
On a new set of laptops like the Lenovo T440 the trackstick does not have
physical buttons. Instead, the touchpad's top edge is supposed to acts
software button area. To avoid spurious cursor jumps when the trackstick is in
use and the finger is resting on the touchpad, add another mode that disables
motion events.
Enabled by syndaemon with -t click-only, the default stays unchanged. No
specific integration with the traditional disable-while-typing is needed. On
such touchpads, disabling motion events is sufficient to avoid spurious
events and we don't want to stop HW buttons to send events.
Note that this only adds the new state to the driver and to syndaemon, there
is nothing hooked up otherwise to actually monitor the trackstick.
Special note for syndaemon: optional arguments are a GNU extension, so work
around it by messing with an optstring starting with ":" which allows us to
manually parse the options.
Original version of this patch by John Pham <jhnphm@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
If we try to grab the evdev device before we've set the new file
descriptor, libevdev_grab returns -EFAULT, which causes DeviceOn to
fail.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
