Re: [PATCH v3 0/4] Fix Lenovo X230 series touchpad
Hi Benjamin, On Thu, Apr 16, 2015 at 9:41 PM, Benjamin Tissoires wrote: > So here is a v2 (well v3 to keep things incrementing) of the x230 touchpad > series. > > The touchpad seems almost as fast as any other by multiplying again the > incline parameter by TP_MAGIC_LOW_RES_FACTOR. I am sure there is an > explanation > here, but I won't give it. New settings are unusable on my x230. Difference between slow and fast movement is too high, it's hard to position cursor on some small button, etc. > I also did not felt now that the scroll was too laggy. If you scroll slow, > then > yes you have a 2 lines scroll for the whole height of the touchpad. But at > normal speed, I found it OK. Scroll _IS_ laggy. Just compare it with normal touchpad. Moving finger through half of touchpad height to scroll for a single line is not OK, and I can't get it scrolling for exactly one line with faster movement. > Again, like in v1, I am not sure we should take the 4/4. A fix should go in > hwdb more likely and there is not so much difference with or without it. > Maybe other users would be more picky and prefer to have it. > > Cheers, > Benjamin Regards, Vasily ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v3 3/4] udev: add a custom udev rule for X230 touchpads
On Thu, Apr 16, 2015 at 02:41:35PM -0400, Benjamin Tissoires wrote:
> X230 touchpads should be tagged as LIBINPUT_MODEL_LENOVO_X230 by udev to
> apply a different acceleration profile.
>
> Signed-off-by: Benjamin Tissoires
one minor change: rename it to 90-... so that local overrides are easier
Reviewed-by: Peter Hutterer
Cheers,
Peter
> ---
> Changes to v1:
> - more generic rule (in the file name and the way it is handled)
>
> No changes to v2.
>
> udev/99-libinput-model-quirks.rules | 14 ++
> udev/Makefile.am|4 +++-
> 2 files changed, 17 insertions(+), 1 deletions(-)
> create mode 100644 udev/99-libinput-model-quirks.rules
>
> diff --git a/udev/99-libinput-model-quirks.rules
> b/udev/99-libinput-model-quirks.rules
> new file mode 100644
> index 000..1ff4a05
> --- /dev/null
> +++ b/udev/99-libinput-model-quirks.rules
> @@ -0,0 +1,14 @@
> +ACTION!="add|change", GOTO="libinput_model_quirks_end"
> +KERNEL!="event*", GOTO="libinput_model_quirks_end"
> +
> +# model specific quirks
> +
> +# Lenovo X230 have a special touchpad with a low resolution
> +
> +ATTR{[dmi/id]product_version}=="ThinkPad X230*", \
> + ENV{ID_INPUT_TOUCHPAD}!="", \
> + ENV{ID_PATH}=="platform-i8042-serio-*", \
> + ENV{LIBINPUT_MODEL_LENOVO_X230}="1", \
> + GOTO="libinput_model_quirks_end"
> +
> +LABEL="libinput_model_quirks_end"
> diff --git a/udev/Makefile.am b/udev/Makefile.am
> index 3691172..24abdea 100644
> --- a/udev/Makefile.am
> +++ b/udev/Makefile.am
> @@ -6,4 +6,6 @@ libinput_device_group_CFLAGS = $(LIBUDEV_CFLAGS) $(GCC_CFLAGS)
> libinput_device_group_LDADD = $(LIBUDEV_LIBS)
>
> udev_rulesdir=$(UDEV_DIR)/rules.d
> -dist_udev_rules_DATA = 80-libinput-device-groups.rules
> +dist_udev_rules_DATA = \
> + 80-libinput-device-groups.rules \
> + 99-libinput-model-quirks.rules
> --
> 1.7.1
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v3 1/4] filter: break out accel_profile_linear from pointer_accel_profile_linear
On Thu, Apr 16, 2015 at 02:41:33PM -0400, Benjamin Tissoires wrote:
> No functional code. Allows to reuse the linear filtering in other
> acceleration profiles.
>
> Signed-off-by: Benjamin Tissoires
> ---
> no changes since v1
>
> src/filter.c | 20 +++-
> 1 files changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/src/filter.c b/src/filter.c
> index 962d74d..f7ff426 100644
> --- a/src/filter.c
> +++ b/src/filter.c
> @@ -305,6 +305,20 @@ create_pointer_accelerator_filter(accel_profile_func_t
> profile)
> return &filter->base;
> }
>
> +static double
> +accel_profile_linear(double speed_in,
> + const double max_accel,
> + const double threshold,
> + const double incline)
> +{
> + double s1, s2;
> +
> + s1 = min(1, speed_in * 5);
> + s2 = 1 + (speed_in - threshold) * incline;
> +
> + return min(max_accel, s2 > 1 ? s2 : s1);
> +}
> +
thinking about this again, I'm not sure we should do this. for the
archives, we had a couple of meetings where we agreed on that if we need
model specific pointer acceleration we will write it once, get it to work
and then leave it untouched for eternity. while we may tweak pointer
acceleration over time, model-specific ones will stay static to avoid an
explosion of the test matrix or accidentally breaking a device that we don't
have access to (anymore).
With that in mind, I think we should just drop this patch and copy the code
for the x230 acceleration method.
Cheers,
Peter
> double
> pointer_accel_profile_linear(struct motion_filter *filter,
>void *data,
> @@ -314,15 +328,11 @@ pointer_accel_profile_linear(struct motion_filter
> *filter,
> struct pointer_accelerator *accel_filter =
> (struct pointer_accelerator *)filter;
>
> - double s1, s2;
> const double max_accel = accel_filter->accel; /* unitless factor */
> const double threshold = accel_filter->threshold; /* units/ms */
> const double incline = accel_filter->incline;
>
> - s1 = min(1, speed_in * 5);
> - s2 = 1 + (speed_in - threshold) * incline;
> -
> - return min(max_accel, s2 > 1 ? s2 : s1);
> + return accel_profile_linear(speed_in, max_accel, threshold, incline);
> }
>
> double
> --
> 1.7.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v3 4/4] evdev: Fix reported resolution of Lenovo X230 touchpads
On Thu, Apr 16, 2015 at 02:41:36PM -0400, Benjamin Tissoires wrote:
> The Lenovo X230 advertise a vertical resolution of 136, which gives a size
> of 31 mm. The actual size of the touchpad is 40mm, so override the
> resolution to 100.
>
> /!\ This is a temporary fix. The proper fix should go in hwdb. /!\
>
> Signed-off-by: Benjamin Tissoires
> ---
> changes to v1:
> - updated with previous series :)
fwiw, the udev fixes went into upstream, so the hwdb patch would be
something like:
evdev:name:TPPS/2 IBM TrackPoint:dmi:*ThinkpadX230*:
EVDEV_ABS_01=::100
EVDEV_ABS_36=::100
Happy to merge any tested patches from you :)
Cheers,
Peter
> src/evdev.c | 13 +
> 1 files changed, 13 insertions(+), 0 deletions(-)
>
> diff --git a/src/evdev.c b/src/evdev.c
> index 0b705e4..8cd12cb 100644
> --- a/src/evdev.c
> +++ b/src/evdev.c
> @@ -1491,6 +1491,17 @@ evdev_fix_android_mt(struct evdev_device *device)
> libevdev_get_abs_info(evdev, ABS_MT_POSITION_Y));
> }
>
> +static inline void
> +evdev_fix_x230_res(struct evdev_device *device)
> +{
> + struct libevdev *evdev = device->evdev;
> +
> + /* ugly hack while EV_ABS_OVERRIDE is merged in udev */
> +
> + if (device->model == EVDEV_MODEL_LENOVO_X230)
> + libevdev_set_abs_resolution(evdev, ABS_Y, 100);
> +}
> +
> static inline int
> evdev_check_min_max(struct evdev_device *device, unsigned int code)
> {
> @@ -1681,6 +1692,8 @@ evdev_configure_device(struct evdev_device *device)
> evdev_fix_android_mt(device);
>
> if (libevdev_has_event_code(evdev, EV_ABS, ABS_X)) {
> + evdev_fix_x230_res(device);
> +
> if (evdev_fix_abs_resolution(device,
>ABS_X,
>ABS_Y,
> --
> 1.7.1
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Relative Pointer API Progress
If you add in something like get a wl_input from a wl_seat which can be used as a generic interface to access the libinput directly in a safe way but still controlled the compositor if the window loses focus or there needs to be some translation done. This would be much more generic than my wl_jostick or wl_6dof proposal. On Fri, Apr 17, 2015 at 1:48 PM, x414e54 wrote: > Actually sorry I was wrong. UE4 uses HID raw input but there are some > older game engines that used to use directinput. > > On Fri, Apr 17, 2015 at 1:43 PM, x414e54 wrote: >> Thank you for the comments. >> I do have a few counterpoints but I will leave after that. >> >>> >>> Not sure an IR/laser/wii mote pointer should even be considered a >>> "relative" pointer since they operate in absolute coordinates. Given >>> this, there is no "set position" hint to consider. Transmitting >>> acceleramoter data via a "relative pointer" doesn't sound reasonable. >>> >> >> I think this is the issue right here. Pointers are not relative, mice >> are not pointers. >> >> I think this is perfectly fine to how it would work in practice >> because when you button down on a GUI widget and ask for a "relative" >> pointer the compositor just hides the pointer switches to the wii mote >> accelerometer and transforms the motion into a 2d projection. If it >> does not have an accelerometer then the relative motion finishes at >> the edge of the input area. >> >>> Sliders etc will be possible with the pointer lock and relative pointer >>> protocols. Confinement has other use cases. >> >> Yes but this protocol should be revised to take an implicit grab >> serial and freeze the pointer and be separate to the >> explicit/long-term grab required for the game api. >> >> It needs to be separate to prevent GUI applications receiving a >> generic explicit grab on the pointer when they do not need it. >> >>> Well, they do. Sure, consoles don't tend to use a mouse for input, but >>> on PC, a very large amount of games do. And a large amount of those tend >>> to use it in "relative mode" i.e. not to show a cursor (Quake, >>> Neverball, ...). >> >> I am not sure if you have made a game but I have shipped a few and I >> am currently sitting in front of the source for a major game engine >> and the "relative pointer" is really just a 2 axis joystick delta. It >> is labeled separately from the gamepad thumb axis but it still reaches >> exactly the same api call at the end which is then using the 2 axis >> deltas to rotate or transform a 3d view. Even with absolute mouse >> positions it is still transformed into an axis delta. >> >> People seem to think because mouse input is superior look aim in FPS >> to a thumb-stick or because one is mapped to a ursor that they are >> somehow completely different programatically... they are not. >> >>> >>> Joysticks, gamepads, 6DOF are orthagonal to pointer locking and relative >>> pointers. Currently games usually rely on opening the evdev device >>> themself, and so far it doesn't seem reasonable to abstract such devices >>> in the compositor. What may make more sense is to rely on the compositor >>> to handle focus, passing fds around, continuing to make the client >>> responsible for translating input events to character movements or >>> whatever. >> >> On windows you would use direct input to open the mouse for "relative" >> motion events, this is exactly the same API as used for joysticks. In >> direct input a "mouse" is just a 2 axis direct input device with the >> mouse label. >> From the point of games they really are not orthogonal. UE4 on window >> uses direct input (joystick api) for it's "high resolution" mouse >> mode. >> >> There are various reasons why you should also need to abstract the >> joystick API and that could be multiple games running at the same time >> trying to access the joystick. You need to give the focus window >> access for example. Also in 3D a VR compositor you would need to >> translate plenty of matrices from the HMD tracking and the 6DOF input >> devices to get the correct view of a 3D window. It would not be >> reasonable to allow an application to access these devices directly. >> >>> It doesn't make any sense to compositor driven hot-swap what input device >>> type a game should use. Many games probably wouldn't even support >>> changing from a mouse+keyboard to a gamepad simply because the gameplay >>> would be different. A game needs to decide itself what input device type >> i> t should use. >> >> As above it games just check the axis label against a list of mappings >> to work out if it is a rotate or translate, etc. You could perfectly >> have a gamepad thumb-stick as movement and a mouse as look and have >> the compositor swap the two inputs without the game caring. Internally >> the game would still think "this is the mouse axis" it is irrelevant >> if it is coming from a different device than the wl_pointer, it just >> needs to be from the same wl_seat. >> >>> Emulating pointer devices from
Re: Wayland Relative Pointer API Progress
Actually sorry I was wrong. UE4 uses HID raw input but there are some older game engines that used to use directinput. On Fri, Apr 17, 2015 at 1:43 PM, x414e54 wrote: > Thank you for the comments. > I do have a few counterpoints but I will leave after that. > >> >> Not sure an IR/laser/wii mote pointer should even be considered a >> "relative" pointer since they operate in absolute coordinates. Given >> this, there is no "set position" hint to consider. Transmitting >> acceleramoter data via a "relative pointer" doesn't sound reasonable. >> > > I think this is the issue right here. Pointers are not relative, mice > are not pointers. > > I think this is perfectly fine to how it would work in practice > because when you button down on a GUI widget and ask for a "relative" > pointer the compositor just hides the pointer switches to the wii mote > accelerometer and transforms the motion into a 2d projection. If it > does not have an accelerometer then the relative motion finishes at > the edge of the input area. > >> Sliders etc will be possible with the pointer lock and relative pointer >> protocols. Confinement has other use cases. > > Yes but this protocol should be revised to take an implicit grab > serial and freeze the pointer and be separate to the > explicit/long-term grab required for the game api. > > It needs to be separate to prevent GUI applications receiving a > generic explicit grab on the pointer when they do not need it. > >> Well, they do. Sure, consoles don't tend to use a mouse for input, but >> on PC, a very large amount of games do. And a large amount of those tend >> to use it in "relative mode" i.e. not to show a cursor (Quake, >> Neverball, ...). > > I am not sure if you have made a game but I have shipped a few and I > am currently sitting in front of the source for a major game engine > and the "relative pointer" is really just a 2 axis joystick delta. It > is labeled separately from the gamepad thumb axis but it still reaches > exactly the same api call at the end which is then using the 2 axis > deltas to rotate or transform a 3d view. Even with absolute mouse > positions it is still transformed into an axis delta. > > People seem to think because mouse input is superior look aim in FPS > to a thumb-stick or because one is mapped to a ursor that they are > somehow completely different programatically... they are not. > >> >> Joysticks, gamepads, 6DOF are orthagonal to pointer locking and relative >> pointers. Currently games usually rely on opening the evdev device >> themself, and so far it doesn't seem reasonable to abstract such devices >> in the compositor. What may make more sense is to rely on the compositor >> to handle focus, passing fds around, continuing to make the client >> responsible for translating input events to character movements or >> whatever. > > On windows you would use direct input to open the mouse for "relative" > motion events, this is exactly the same API as used for joysticks. In > direct input a "mouse" is just a 2 axis direct input device with the > mouse label. > From the point of games they really are not orthogonal. UE4 on window > uses direct input (joystick api) for it's "high resolution" mouse > mode. > > There are various reasons why you should also need to abstract the > joystick API and that could be multiple games running at the same time > trying to access the joystick. You need to give the focus window > access for example. Also in 3D a VR compositor you would need to > translate plenty of matrices from the HMD tracking and the 6DOF input > devices to get the correct view of a 3D window. It would not be > reasonable to allow an application to access these devices directly. > >> It doesn't make any sense to compositor driven hot-swap what input device >> type a game should use. Many games probably wouldn't even support >> changing from a mouse+keyboard to a gamepad simply because the gameplay >> would be different. A game needs to decide itself what input device type > i> t should use. > > As above it games just check the axis label against a list of mappings > to work out if it is a rotate or translate, etc. You could perfectly > have a gamepad thumb-stick as movement and a mouse as look and have > the compositor swap the two inputs without the game caring. Internally > the game would still think "this is the mouse axis" it is irrelevant > if it is coming from a different device than the wl_pointer, it just > needs to be from the same wl_seat. > >> Emulating pointer devices from controller input I think is completely >> out of scope for any protocol. It can be done by something server side >> if needed. > > This is exactly what the compositor is currently doing with mouse input. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Relative Pointer API Progress
Thank you for the comments. I do have a few counterpoints but I will leave after that. > > Not sure an IR/laser/wii mote pointer should even be considered a > "relative" pointer since they operate in absolute coordinates. Given > this, there is no "set position" hint to consider. Transmitting > acceleramoter data via a "relative pointer" doesn't sound reasonable. > I think this is the issue right here. Pointers are not relative, mice are not pointers. I think this is perfectly fine to how it would work in practice because when you button down on a GUI widget and ask for a "relative" pointer the compositor just hides the pointer switches to the wii mote accelerometer and transforms the motion into a 2d projection. If it does not have an accelerometer then the relative motion finishes at the edge of the input area. > Sliders etc will be possible with the pointer lock and relative pointer > protocols. Confinement has other use cases. Yes but this protocol should be revised to take an implicit grab serial and freeze the pointer and be separate to the explicit/long-term grab required for the game api. It needs to be separate to prevent GUI applications receiving a generic explicit grab on the pointer when they do not need it. > Well, they do. Sure, consoles don't tend to use a mouse for input, but > on PC, a very large amount of games do. And a large amount of those tend > to use it in "relative mode" i.e. not to show a cursor (Quake, > Neverball, ...). I am not sure if you have made a game but I have shipped a few and I am currently sitting in front of the source for a major game engine and the "relative pointer" is really just a 2 axis joystick delta. It is labeled separately from the gamepad thumb axis but it still reaches exactly the same api call at the end which is then using the 2 axis deltas to rotate or transform a 3d view. Even with absolute mouse positions it is still transformed into an axis delta. People seem to think because mouse input is superior look aim in FPS to a thumb-stick or because one is mapped to a ursor that they are somehow completely different programatically... they are not. > > Joysticks, gamepads, 6DOF are orthagonal to pointer locking and relative > pointers. Currently games usually rely on opening the evdev device > themself, and so far it doesn't seem reasonable to abstract such devices > in the compositor. What may make more sense is to rely on the compositor > to handle focus, passing fds around, continuing to make the client > responsible for translating input events to character movements or > whatever. On windows you would use direct input to open the mouse for "relative" motion events, this is exactly the same API as used for joysticks. In direct input a "mouse" is just a 2 axis direct input device with the mouse label. From the point of games they really are not orthogonal. UE4 on window uses direct input (joystick api) for it's "high resolution" mouse mode. There are various reasons why you should also need to abstract the joystick API and that could be multiple games running at the same time trying to access the joystick. You need to give the focus window access for example. Also in 3D a VR compositor you would need to translate plenty of matrices from the HMD tracking and the 6DOF input devices to get the correct view of a 3D window. It would not be reasonable to allow an application to access these devices directly. > It doesn't make any sense to compositor driven hot-swap what input device > type a game should use. Many games probably wouldn't even support > changing from a mouse+keyboard to a gamepad simply because the gameplay > would be different. A game needs to decide itself what input device type i> t should use. As above it games just check the axis label against a list of mappings to work out if it is a rotate or translate, etc. You could perfectly have a gamepad thumb-stick as movement and a mouse as look and have the compositor swap the two inputs without the game caring. Internally the game would still think "this is the mouse axis" it is irrelevant if it is coming from a different device than the wl_pointer, it just needs to be from the same wl_seat. > Emulating pointer devices from controller input I think is completely > out of scope for any protocol. It can be done by something server side > if needed. This is exactly what the compositor is currently doing with mouse input. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Relative Pointer API Progress
On Fri, Apr 17, 2015 at 11:51:41AM +0900, x414e54 wrote: > Hi, > > I am wondering if there has been any recent progress on the stability of > the Wayland relative pointer API? AFAIK it is being / to be reviewed a bit more. I have some kind of plan to submit a version with the previous issues addressed, but haven't gotten to it yet. > > I had a few ideas on the original December implementation: > > Whilst we definitely need the relative event support, I feel that the > client should never be allowed to warp or confine the global pointer even > if it is just a hint. There may be cases such as IR or laser pointer > devices (e.g. wii mote) which can never guarantee a warp or pointer > confinement but can still transmit accelerometer data as relative pointer > motion. Looking at most toolkits and applications they cannot be trusted > even with "hints". Not sure an IR/laser/wii mote pointer should even be considered a "relative" pointer since they operate in absolute coordinates. Given this, there is no "set position" hint to consider. Transmitting acceleramoter data via a "relative pointer" doesn't sound reasonable. > > I think the API needs to be split into two use cases: > > 1. GUI sliders etc. - They should be allowed to freeze the pointer and > receive relative events based on an implicit button down grab similar to > the drag and drop protocol. They should not be allowed to warp or confine > and upon button up the grab is lost. Gnome already looks like it uses > heuristics todo this if the cursor is hidden on button down. Sliders etc will be possible with the pointer lock and relative pointer protocols. Confinement has other use cases. > > 1. Games - They do not really need relative "pointer" events they just want > the current seat mapped to a 6DOF or joystick style input. They should be > allowed to request some kind of wl_joystick or wl_6dof interface. Then the > compositor can decide what it actually presents to the application for > using that input. Maybe a user has a joystick they always select to use > instead of their mouse or they have an accelerometer device etc. It is then > up to the compositor what it does with the actual on screen cursor if it > confines it or hides it etc, there could be a notification of entering > "game mode" etc. If the compositor is not using the same input device for > wl_pointer and a wl_joystick or wl_6dof then it does nothing. This would > also allow a user to hot-swap the device between mouse and keyboard and a > gamepad just by using the WM settings. It could also allow for using 6DOF > or 3D mice in an application which is also mapped as the default x, y > pointer. > > The application will then still receive absolute pointer events which it > can use for in game GUI clicks. > Well, they do. Sure, consoles don't tend to use a mouse for input, but on PC, a very large amount of games do. And a large amount of those tend to use it in "relative mode" i.e. not to show a cursor (Quake, Neverball, ...). Joysticks, gamepads, 6DOF are orthagonal to pointer locking and relative pointers. Currently games usually rely on opening the evdev device themself, and so far it doesn't seem reasonable to abstract such devices in the compositor. What may make more sense is to rely on the compositor to handle focus, passing fds around, continuing to make the client responsible for translating input events to character movements or whatever. It doesn't make any sense to compositor driven hot-swap what input device type a game should use. Many games probably wouldn't even support changing from a mouse+keyboard to a gamepad simply because the gameplay would be different. A game needs to decide itself what input device type it should use. Emulating pointer devices from controller input I think is completely out of scope for any protocol. It can be done by something server side if needed. Jonas > Any opinions on this would be appreciated. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 2/2] touchpad: introduce MULTITAP for multi-tap-and-drag
On Thu, Apr 16, 2015 at 10:00:45AM +0200, Hans de Goede wrote: > Hi, > > On 16-04-15 07:04, Peter Hutterer wrote: > >Once we have a doubletap, enter a loop in the state machine where we can tap > >multiple times and either get a multi-click or a multi-click drag-and-drop. > > > >The sequence down/up down/up down/up produces a triple-click. The sequence > >down/up down/up down/up down produces a triple-click with a button down for > > I think you've one down/up to many here. heh, no, should be correct. three full taps plus finger down is tripleclick-drag > Otherwise looks good: > > Reviewed-by: Hans de Goede thanks, much appreciated. Cheers, Peter > Regards, > > Hans > > >dragging. Yes, that glorious octuple-tap-and-drag, it is now possible. World > >domination has been achieved, thank you for playing. > > > >We don't know when we finish tapping now, so add a timeout to send the last > >click event once the finger has been released for the last time. This > >guarantees that the timestamp of the last button down is later than the > >last release. This avoids the bug fixed in synaptics commit > >xf86-input-synaptics-1.8.0-21-g37d34f0 (some application don't handle > >doubletap correctly without the timestamps). > > > >This works for double-tap immediately, for multi-tap we need to remember the > >timestamp of the first press event and use it for the release event so that > >there's a forced gap between the release and the second press. > > > >https://bugs.freedesktop.org/show_bug.cgi?id=89511 > > > >Signed-off-by: Peter Hutterer > >--- > > doc/touchpad-tap-state-machine.svg | 1593 > > ++-- > > src/evdev-mt-touchpad-tap.c| 88 +- > > src/evdev-mt-touchpad.h|3 + > > test/touchpad.c| 394 + > > 4 files changed, 1447 insertions(+), 631 deletions(-) ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Wayland Relative Pointer API Progress
Hi, I am wondering if there has been any recent progress on the stability of the Wayland relative pointer API? I had a few ideas on the original December implementation: Whilst we definitely need the relative event support, I feel that the client should never be allowed to warp or confine the global pointer even if it is just a hint. There may be cases such as IR or laser pointer devices (e.g. wii mote) which can never guarantee a warp or pointer confinement but can still transmit accelerometer data as relative pointer motion. Looking at most toolkits and applications they cannot be trusted even with "hints". I think the API needs to be split into two use cases: 1. GUI sliders etc. - They should be allowed to freeze the pointer and receive relative events based on an implicit button down grab similar to the drag and drop protocol. They should not be allowed to warp or confine and upon button up the grab is lost. Gnome already looks like it uses heuristics todo this if the cursor is hidden on button down. 1. Games - They do not really need relative "pointer" events they just want the current seat mapped to a 6DOF or joystick style input. They should be allowed to request some kind of wl_joystick or wl_6dof interface. Then the compositor can decide what it actually presents to the application for using that input. Maybe a user has a joystick they always select to use instead of their mouse or they have an accelerometer device etc. It is then up to the compositor what it does with the actual on screen cursor if it confines it or hides it etc, there could be a notification of entering "game mode" etc. If the compositor is not using the same input device for wl_pointer and a wl_joystick or wl_6dof then it does nothing. This would also allow a user to hot-swap the device between mouse and keyboard and a gamepad just by using the WM settings. It could also allow for using 6DOF or 3D mice in an application which is also mapped as the default x, y pointer. The application will then still receive absolute pointer events which it can use for in game GUI clicks. Any opinions on this would be appreciated. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: EFL/Wayland and xdg-shell
On Thu, 16 Apr 2015 15:32:31 +0100 Daniel Stone said:
> Hi,
>
> On 15 April 2015 at 23:51, Carsten Haitzler wrote:
> > On Wed, 15 Apr 2015 20:29:32 +0100 Daniel Stone said:
> >> On 15 April 2015 at 02:39, Carsten Haitzler wrote:
> >> > not esoteric - an actual request from people making products.
> >>
> >> The reason I took that as 'esoteric' was that I assumed it was about
> >> free window rotation inside Weston: a feature which is absolutely
> >> pointless but as a proof-of-concept for a hidden global co-ordinate
> >> space. Makes a lot more sense for whole-display rotation. More below.
> >
> > not just whole display - but now imagine a table with a screen and touch
> > and 4 people around it one along each side and multiple windows floating
> > about like scraps of paper... just an illustration where you'd want
> > window-by-window rotation done by compositor as well.
>
> Sure, but that's complex enough - and difficult enough to reason even
> about the desired UI semantics - that it really wants a prototype
> first, or even a mockup. How do you define orientation in a table
> scenario? If you're doing gesture-based/constant rotation (rather than
> quantised to 90°), how do you animate that, and where does the
> threshold for relayout lie? Without knowing what to design for, it's
> hard to come up with a protocol which makes sense.
sure - let's leave this until later.
> Luckily, writing extensions is infinitely less difficult than under
> X11, so the general approach has been to farm these out to separate
> extensions and then bring them in later if they turn out to make sense
> in a global context. The most relevant counter-example (and
> anti-pattern) I can think of is XI2 multitouch, where changing things
> was so difficult that we had to design from the moon from the get-go.
> The result, well, was XI2 multitouch. Not my finest moment, but
> luckily I stepped out before it was merged so can just blame Peter.
well on 2 levels. extensions were basically almost a no-go area. but with x
client message events, properties you could "extend" x (well wm/comp/clients <->
clients) fairly trivially. :) at this stage wayland is missing such a "trivial"
ad-hoc extending api. i actually might add one just for the purposes of
prototyping ideas - like just shovel some strings/ints etc. with some string
message name/id. anyway...
> >> > actually the other way around... clients know where the vkbd region(s)
> >> > are so client can shuffle content to be visible. :)
> >>
> >> In a VKB (rather than overlay-helper, as used for complex composition)
> >> scenario, I would expect xdg-shell to send a configure event to resize
> >> the window and allow for the VKB. If this isn't sufficient - I
> >> honestly don't know what the behaviour is under X11 - then a potential
> >> version bump of wl_text could provide for this.
> >
> > no - resizing is a poorer solution. tried that in x11. first obvious port of
> > call. imagine vkbd is partly translucent... you want it to still be over
> > window content. imagine a kbd split onto left and right halves, one in the
> > middle of the left and right edges of the screen (because screen is
> > bigger). :)
>
> Yeah, gotcha; it does fall apart after more than about a minute's
> thought. Seems like this has been picked up though, so happy days.
>
> >> > (pretend a phone with 4 external monitors attached).
> >>
> >> Hell of a phone. More seriously, yes, a display-management API could
> >> expose this, however if the aim is for clients to communicate intent
> >> ('this is a presentation') rather than for compositors to communicate
> >> situation ('this is one of the external monitors'), then we probably
> >> don't need this. wl_output already provides the relative geometry, so
> >> all that is required for this is a way to communicate output type.
> >
> > i was thinking a simplified geometry. then again client toolkits can figure
> > that out and present a simplified enum or what not to the app too. but yes -
> > some enumerated "type" attached to the output would be very nice. smarter
> > clients can decide their intent based on what is listed as available -
> > adapt to the situation. dumber ones will just ask for a fixed type and
> > "deal with it" if they don't get it.
>
> I think exposing an output type would be relatively uncontroversial.
> The fullscreen request already takes a target output; would that cover
> your uses, or do you really need to request initial presentation of
> non-fullscreen windows on particular outputs? (Actually, I can see
> that: you'd want your PDF viewer's primary view to tack to your
> internal output, and its presentation view aimed at the external
> output. Jasper/Manuel - any thoughts?)
yes - any surface, anywhere, any time. :)
> >> > surfaces should be
> >> > able to hint at usage - eg "i want to be on the biggest tv". "i want to
> >> > be wherever you have a small mobile touch screen" etc. compositor deals
> >> > with deciding where they
[PATCH weston] input: add a weston_pointer_clear_focus() helper function
This adds a function to clear pointer focus and also set the sx,sy
co-ordinates to an arbitrary value we shouldn't compute with.
Assertions are added to make sure any time pointer focus is set to NULL
these values are used.
weston_compositor_pick_view() now returns these values too.
Signed-off-by: Derek Foreman
---
Ok, so I didn't do quite what I set out to, but I think this is better :)
Pekka, does this roughly cover what we talked about? Now everyone sets sx,
sx "properly".
Not sure how I feel about the previous patch. I think it's superfluous now,
as the pointer co-ordinates test should fail and stop the focus signal from
firing.
desktop-shell/exposay.c | 3 +--
desktop-shell/shell.c | 4 +---
src/compositor.c| 7 +++
src/compositor.h| 2 ++
src/data-device.c | 3 +--
src/input.c | 34 +-
6 files changed, 37 insertions(+), 16 deletions(-)
diff --git a/desktop-shell/exposay.c b/desktop-shell/exposay.c
index 4b65cbd..5d77893 100644
--- a/desktop-shell/exposay.c
+++ b/desktop-shell/exposay.c
@@ -572,8 +572,7 @@ exposay_transition_active(struct desktop_shell *shell)
shell->exposay.grab_ptr.interface = &exposay_ptr_grab;
weston_pointer_start_grab(seat->pointer,
&shell->exposay.grab_ptr);
- weston_pointer_set_focus(seat->pointer, NULL,
-seat->pointer->x, seat->pointer->y);
+ weston_pointer_clear_focus(seat->pointer);
wl_list_for_each(shell_output, &shell->output_list, link) {
enum exposay_layout_state state;
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index f7c928e..4e9f9c2 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -3160,9 +3160,7 @@ popup_grab_focus(struct weston_pointer_grab *grab)
wl_resource_get_client(view->surface->resource) == client) {
weston_pointer_set_focus(pointer, view, sx, sy);
} else {
- weston_pointer_set_focus(pointer, NULL,
-wl_fixed_from_int(0),
-wl_fixed_from_int(0));
+ weston_pointer_clear_focus(pointer);
}
}
diff --git a/src/compositor.c b/src/compositor.c
index e6a60bd..8bd11ce 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -1770,6 +1770,8 @@ weston_compositor_pick_view(struct weston_compositor
*compositor,
return view;
}
+ *vx = wl_fixed_from_int(-100);
+ *vy = wl_fixed_from_int(-100);
return NULL;
}
@@ -1809,10 +1811,7 @@ weston_view_unmap(struct weston_view *view)
if (seat->keyboard && seat->keyboard->focus == view->surface)
weston_keyboard_set_focus(seat->keyboard, NULL);
if (seat->pointer && seat->pointer->focus == view)
- weston_pointer_set_focus(seat->pointer,
-NULL,
-wl_fixed_from_int(0),
-wl_fixed_from_int(0));
+ weston_pointer_clear_focus(seat->pointer);
if (seat->touch && seat->touch->focus == view)
weston_touch_set_focus(seat, NULL);
}
diff --git a/src/compositor.h b/src/compositor.h
index 5f49237..8b694aa 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -379,6 +379,8 @@ weston_pointer_set_focus(struct weston_pointer *pointer,
struct weston_view *view,
wl_fixed_t sx, wl_fixed_t sy);
void
+weston_pointer_clear_focus(struct weston_pointer *pointer);
+void
weston_pointer_start_grab(struct weston_pointer *pointer,
struct weston_pointer_grab *grab);
void
diff --git a/src/data-device.c b/src/data-device.c
index a0913a2..f879daa 100644
--- a/src/data-device.c
+++ b/src/data-device.c
@@ -587,8 +587,7 @@ weston_pointer_start_drag(struct weston_pointer *pointer,
&drag->base.data_source_listener);
}
- weston_pointer_set_focus(pointer, NULL,
-wl_fixed_from_int(0), wl_fixed_from_int(0));
+ weston_pointer_clear_focus(pointer);
weston_pointer_start_grab(pointer, &drag->grab);
return 0;
diff --git a/src/input.c b/src/input.c
index 18d1262..97a0284 100644
--- a/src/input.c
+++ b/src/input.c
@@ -78,7 +78,7 @@ pointer_focus_view_destroyed(struct wl_listener *listener,
void *data)
container_of(listener, struct weston_pointer,
focus_view_listener);
- weston_pointer_set_focus(pointer, NULL, 0, 0);
+ weston_pointer_clear_focus(pointer);
}
static void
@@ -88,7 +88,7 @@ pointer_focus_resource_destroyed(struct wl_listener
*listener, void *data)
container_of(listener, struct weston_pointer,
Re: [PATCH weston] input: Don't use uninitialized variables in default_grab_pointer_focus()
Hi, On 16 April 2015 at 21:02, Derek Foreman wrote: > exposay is the only caller that tries to use non 0 with a NULL view, and > I haven't been able to figure out a reason why that's useful - we've > just declared that case to be invalid. I'm planning to just make that 0 > too. From taking a look at the code, this can indeed just be removed and changed to (0, 0). Not only is this not helpful, but it's doubly invalid: weston_pointer_set_focus() takes sx and sy, not global x/y. So, I can't see how that could ever have done anything useful. Ack to anything which changes it to what it should be. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] protocol: Add DnD actions
On 04/16/2015 03:55 AM, Carlos Garnacho wrote: In gtk+/gnome we currently have the following keybindings active during DnD: - Cursor keys move the drag point, modifiers affect speed - Esc key cancels drag - Modifiers alone pick an action from the offered list The user has to hold the mouse button down during these? That does not sound very useful. Or is it possible to start DnD with a keystroke? What happens then if the user moves the mouse or pushes the mouse button? I really need a clearer explanation of these keystrokes. I suspect some requirements of implementing things on X are leaking into your description, and you are talking about a global handicapped-assistance api (which I agree would be done by the compositor, but applies everywhere, not just DnD). So ok, the latter is dubious to punt to compositors, but there's basically no other choice with the 2 first ones. It can be handled by either the source or dest getting a grab and responding to the key events with some new api that manually moves the drop target. In fact there is a lot of proposed things for the grab to be able to completely control the cursor position, this would be another one. I do agree that making Esc cause the compositor to cancel a grab unconditionally is an acceptable idea. If you don't have to hold down the mouse to do DnD, or if there is no position on the screen that you can drop without anything happening, then this is necessary. It does seem like the source getting the keyboard drag is consistent, and match how dragging any other part of the source's ui works. However I think it will work better for the destination to get the grab. This is because the destination has a more complex job, including actions that the source does not need to distinguish (insert vs replace, link vs copy), and if there is a popup menu to let the user choose the action they will think it is part of the destination and it would look far better if it was drawn with the destination's style, and user preferences for it are set on the destination. So during a DnD the keyboard focus should be (in effect) point-to-type. I don't think it should get mouse enter/exit/move events, instead the drag enter/exit/move would replace them. There will unfortunately have to be a keyboard focus-in event as that is the only way to communicate the current keymap to the client (it may be useful to add an event for that as there already is the problem where the compositor eats keystrokes, but can't tell the client about the new keymap without a fake exit/enter). I think both the source and destination should be able to modify the cursor. If the destination says it will accept the drop then it is it's job to update the cursor, as it may modify it to show clearly what will happen (for instance it may update it's own display to show the result of the drop, and change the cursor to just the pointer). If it says it won't, then the source sets the cursor to it's default version. Race conditions with this idea need to be solved... ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] input: Don't use uninitialized variables in default_grab_pointer_focus()
On 13/04/15 01:51 AM, Pekka Paalanen wrote: > On Fri, 10 Apr 2015 11:13:22 -0500 > Derek Foreman wrote: > >> On 10/04/15 09:41 AM, Derek Foreman wrote: >>> On 10/04/15 02:16 AM, Pekka Paalanen wrote: On Wed, 8 Apr 2015 15:18:41 -0500 Derek Foreman wrote: > If we have no pointer focus and weston_compositor_pick_view() returns NULL > default_grab_pointer_focus() will test the unset sx, sy output parameters > from weston_compositor_pick_view(). > > Instead, assume that since both pointers are NULL focus hasn't changed and > we don't need to update pointer focus. > > Signed-off-by: Derek Foreman > --- > > This fixes an error reported by valgrind. I think the patch is correct > but > it does stop pointer->focus_signal from being emitted when focus switches > from NULL to NULL. I think that shouldn't have happened anyway? If focus switches from NULL to NULL, weston_pointer_set_focus() would never be called because of the pointer->focus != view check, right? So the case you saw in Valgrind must be a case of !NULL -> NULL switch, which has to be processed but does not have valid sx, sy by definition. Therefore... > Initializing sx, sy to wl_fixed_from_int(0) would silence the warning too, > but I think this way is more correct... ...isn't initializing the sx, sy the right thing to do, and this patch actually fixes nothing? Did I miss something? >>> >>> As did I. >>> >>> As discussed on irc, the null to null case doesn't short circuit the || >>> so the patch does "something"... > > Ahaha, yeah, silly me, can't read logic operators right... sorry. > >>> However, we probably shouldn't be getting here for a null to null switch >>> anyway, so I need to investigate why that's happened in the first place. >>> >>> Initializing sx and sy would really have the same result, so I'm going >>> to avoid that for now as well. >> >> On further investigation this happens in two places: >> From udev_input_init() which is called very early, so device_added() >> gets called before the view list contains anything at all. This could >> be hidden by setting input->suspended for the duration of >> udev_input_init(). However, if the user is moving the mouse around >> during startup, it'll still happen. > > Sounds like that special-casing is not worth it, then. > >> During the first repaint when only the shell's fade surface exists. >> This can be hidden by giving the shell's fade surface an input region, I >> guess. This'll also hide the mouse cursor during fade in, which is a >> little weird/wrong. > > Yeah, not good. > >> I think we need to deal with this case with either what I've done, or >> initializing sx, sy. exposay appears to set a NULL focus with non-zero >> co-ordinates, so there may actually be a functional difference between >> these, though I'm having a hard time figuring out what it is, and if >> it's even intentional. > > Right... > > Let's take a step back. If weston_compositor_pick_view() returns NULL, > then there is no surface having input at that point. As there is no > surface, no value for sx,sy makes sense, because you don't even have a > coordinate system to begin with (a surface would define the coordinate > system). Therefore, sx,sy should not be used at all, they are invalid > in any case. > > Comparing invalid sx,sy to previous sx,sy makes no sense either. It > just should not be done. Comparing previous sx,sy to new sx,sy only > makes sense if the coordinate systems are the same, that means, the > previous and current picked surface are the same and not NULL. > > This brings us to what default_grab_pointer_focus() should do. Sx,sy > should be compared only if the previous and current surface are the > same non-NULL. In all other cases, the comparison is illegal. > > If the picked surface is different than the previous one, then we > obviously need to call weston_pointer_set_focus(). If previous and > current are NULL, then it should just do nothing, because there are no > sx,sy and going from no-target to no-target is not a change. Ok, that's all I've handled in the previous patch. > This leaves the problem when previous surface was non-NULL, but the new > pick is NULL, because weston_pointer_set_focus() needs some sx,sy > arguments. In this case, I'd suggest we pick some arbitrary sx,sy that > is not easily confused with proper coordinates. Maybe something like > wl_fixed_from_int(-100). Ah, yes. I don't know if that ever happens right now, but we should prevent it. I'd like to be a little more aggressive in stamping this out - how about if view is NULL we expect 0s to be passed along with it to weston_pointer_set_focus() (and assert otherwise). Then internally in weston_pointer_set_focus() we set sx, sy to wl_fixed_from_int(-100). Can it be a normal integer 0 instead of a wl_fixed_from_int(0) since it's being ignored anyway? ;)
Re: [PATCH v3 2/4] evdev: use a different filter for low resolution touchpad on the Lenovo X230
On Thu, Apr 16, 2015 at 9:41 PM, Benjamin Tissoires
wrote:
> Those touchpads presents an actual lower resolution that what is
> advertised.
>
> We see some jumps from the cursor due to the big steps in X and Y
> when we are receiving data.
>
> For instance, we receive:
>
> E: 13.471932 0003 16366# EV_ABS / ABS_X16366
> E: 13.471932 0003 0001 9591 # EV_ABS / ABS_Y9591
> E: 13.471932 # SYN_REPORT (0) --
> E: 13.479924 0003 16316# EV_ABS / ABS_X16316
> E: 13.479924 0003 0001 9491 # EV_ABS / ABS_Y9491
> E: 13.479924 # SYN_REPORT (0) --
> E: 13.487939 0003 16271# EV_ABS / ABS_X16271
> E: 13.487939 0003 0001 9403 # EV_ABS / ABS_Y9403
> E: 13.487939 # SYN_REPORT (0) --
>
> -> jumps of ~50 in X in each report, and ~100 for Y.
>
> Apply a factor to minimize those jumps at low speed and try keeping
> the same feeling as regular touchpads at high speed. It still feels
> slower but it is usable at least
>
> Signed-off-by: Benjamin Tissoires
> Signed-off-by: Peter Hutterer
> ---
> Changes to v1:
> - a bit more generic than the original, makes adding new models more
> straightforward.
>
> Changes to v2:
> - changed the incline parameter to have a touchpad which feels like the other.
> Not sure these are the final parameters but they make the touchpad much
> better.
>
> doc/device-configuration-via-udev.dox |9
> src/evdev-mt-touchpad.c | 14 ++--
> src/evdev.c | 23 ++
> src/evdev.h |7 ++
> src/filter.c | 34
> +
> src/filter.h |5
> 6 files changed, 89 insertions(+), 3 deletions(-)
>
> diff --git a/doc/device-configuration-via-udev.dox
> b/doc/device-configuration-via-udev.dox
> index fc1c0af..c570913 100644
> --- a/doc/device-configuration-via-udev.dox
> +++ b/doc/device-configuration-via-udev.dox
> @@ -57,6 +57,15 @@ See @ref motion_normalization for details.
> The angle in degrees for each click on a mouse wheel. See
> libinput_pointer_get_axis_source() for details.
>
> +LIBINPUT_MODEL_LENOVO_X230
> +Do not use for anything except a Lenovo X230 series (you have been
> +warned).
> +This flag allows libinput to apply a different acceleration profile for the
> +touchpads of this series of laptops to counter a hardware deficiency. It may
> +also be use to tune other parts of the inputs of these laptops, so the
> effects
> +of this property may change anytime and will be only tested against the
> +mentioned laptop series.
> +
>
>
> Below is an example udev rule to assign "seat1" to a device from vendor
> diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
> index 4e5a558..f88e906 100644
> --- a/src/evdev-mt-touchpad.c
> +++ b/src/evdev-mt-touchpad.c
> @@ -998,6 +998,7 @@ static int
> tp_init_accel(struct tp_dispatch *tp, double diagonal)
> {
> int res_x, res_y;
> + accel_profile_func_t profile;
>
> res_x = tp->device->abs.absinfo_x->resolution;
> res_y = tp->device->abs.absinfo_y->resolution;
> @@ -1021,9 +1022,16 @@ tp_init_accel(struct tp_dispatch *tp, double diagonal)
> tp->accel.y_scale_coeff = DEFAULT_ACCEL_NUMERATOR / diagonal;
> }
>
> - if (evdev_device_init_pointer_acceleration(
> - tp->device,
> - touchpad_accel_profile_linear) == -1)
> + switch (tp->device->model) {
> + case EVDEV_MODEL_LENOVO_X230:
> + profile = touchpad_lenovo_x230_accel_profile;
> + break;
> + default:
> + profile = touchpad_accel_profile_linear;
> + break;
> + }
> +
> + if (evdev_device_init_pointer_acceleration(tp->device, profile) == -1)
> return -1;
>
> return 0;
> diff --git a/src/evdev.c b/src/evdev.c
> index 5b4b2b6..0b705e4 100644
> --- a/src/evdev.c
> +++ b/src/evdev.c
> @@ -1356,6 +1356,28 @@ evdev_read_dpi_prop(struct evdev_device *device)
> return dpi;
> }
>
> +static inline enum evdev_device_model
> +evdev_read_model(struct evdev_device *device)
> +{
> + const struct model_map {
> + const char *property;
> + enum evdev_device_model model;
> + } model_map[] = {
> + { "LIBINPUT_MODEL_LENOVO_X230", EVDEV_MODEL_LENOVO_X230 },
> + { NULL, EVDEV_MODEL_DEFAULT },
> + };
> + const struct model_map *m = model_map;
> +
> + while (m->property) {
> + if (!!udev_device_get_property_value(device->udev_device,
> +m->property))
> + br
[PATCH v3 3/4] udev: add a custom udev rule for X230 touchpads
X230 touchpads should be tagged as LIBINPUT_MODEL_LENOVO_X230 by udev to
apply a different acceleration profile.
Signed-off-by: Benjamin Tissoires
---
Changes to v1:
- more generic rule (in the file name and the way it is handled)
No changes to v2.
udev/99-libinput-model-quirks.rules | 14 ++
udev/Makefile.am|4 +++-
2 files changed, 17 insertions(+), 1 deletions(-)
create mode 100644 udev/99-libinput-model-quirks.rules
diff --git a/udev/99-libinput-model-quirks.rules
b/udev/99-libinput-model-quirks.rules
new file mode 100644
index 000..1ff4a05
--- /dev/null
+++ b/udev/99-libinput-model-quirks.rules
@@ -0,0 +1,14 @@
+ACTION!="add|change", GOTO="libinput_model_quirks_end"
+KERNEL!="event*", GOTO="libinput_model_quirks_end"
+
+# model specific quirks
+
+# Lenovo X230 have a special touchpad with a low resolution
+
+ATTR{[dmi/id]product_version}=="ThinkPad X230*", \
+ ENV{ID_INPUT_TOUCHPAD}!="", \
+ ENV{ID_PATH}=="platform-i8042-serio-*", \
+ ENV{LIBINPUT_MODEL_LENOVO_X230}="1", \
+ GOTO="libinput_model_quirks_end"
+
+LABEL="libinput_model_quirks_end"
diff --git a/udev/Makefile.am b/udev/Makefile.am
index 3691172..24abdea 100644
--- a/udev/Makefile.am
+++ b/udev/Makefile.am
@@ -6,4 +6,6 @@ libinput_device_group_CFLAGS = $(LIBUDEV_CFLAGS) $(GCC_CFLAGS)
libinput_device_group_LDADD = $(LIBUDEV_LIBS)
udev_rulesdir=$(UDEV_DIR)/rules.d
-dist_udev_rules_DATA = 80-libinput-device-groups.rules
+dist_udev_rules_DATA = \
+ 80-libinput-device-groups.rules \
+ 99-libinput-model-quirks.rules
--
1.7.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v3 0/4] Fix Lenovo X230 series touchpad
Grmbl... this series is for libinput, sorry for the missing subject prefix Benjamin On Thu, Apr 16, 2015 at 2:41 PM, Benjamin Tissoires wrote: > So here is a v2 (well v3 to keep things incrementing) of the x230 touchpad > series. > > The touchpad seems almost as fast as any other by multiplying again the > incline parameter by TP_MAGIC_LOW_RES_FACTOR. I am sure there is an > explanation > here, but I won't give it. > > I also did not felt now that the scroll was too laggy. If you scroll slow, > then > yes you have a 2 lines scroll for the whole height of the touchpad. But at > normal speed, I found it OK. > > Again, like in v1, I am not sure we should take the 4/4. A fix should go in > hwdb more likely and there is not so much difference with or without it. > Maybe other users would be more picky and prefer to have it. > > Cheers, > Benjamin > > Benjamin Tissoires (4): > filter: break out accel_profile_linear from > pointer_accel_profile_linear > evdev: use a different filter for low resolution touchpad on the > Lenovo X230 > udev: add a custom udev rule for X230 touchpads > evdev: Fix reported resolution of Lenovo X230 touchpads > > doc/device-configuration-via-udev.dox |9 + > src/evdev-mt-touchpad.c | 14 +++-- > src/evdev.c | 36 ++ > src/evdev.h |7 > src/filter.c | 54 +--- > src/filter.h |5 +++ > udev/99-libinput-model-quirks.rules | 14 > udev/Makefile.am |4 ++- > 8 files changed, 134 insertions(+), 9 deletions(-) > create mode 100644 udev/99-libinput-model-quirks.rules > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH v3 0/4] Fix Lenovo X230 series touchpad
So here is a v2 (well v3 to keep things incrementing) of the x230 touchpad series. The touchpad seems almost as fast as any other by multiplying again the incline parameter by TP_MAGIC_LOW_RES_FACTOR. I am sure there is an explanation here, but I won't give it. I also did not felt now that the scroll was too laggy. If you scroll slow, then yes you have a 2 lines scroll for the whole height of the touchpad. But at normal speed, I found it OK. Again, like in v1, I am not sure we should take the 4/4. A fix should go in hwdb more likely and there is not so much difference with or without it. Maybe other users would be more picky and prefer to have it. Cheers, Benjamin Benjamin Tissoires (4): filter: break out accel_profile_linear from pointer_accel_profile_linear evdev: use a different filter for low resolution touchpad on the Lenovo X230 udev: add a custom udev rule for X230 touchpads evdev: Fix reported resolution of Lenovo X230 touchpads doc/device-configuration-via-udev.dox |9 + src/evdev-mt-touchpad.c | 14 +++-- src/evdev.c | 36 ++ src/evdev.h |7 src/filter.c | 54 +--- src/filter.h |5 +++ udev/99-libinput-model-quirks.rules | 14 udev/Makefile.am |4 ++- 8 files changed, 134 insertions(+), 9 deletions(-) create mode 100644 udev/99-libinput-model-quirks.rules ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH v3 2/4] evdev: use a different filter for low resolution touchpad on the Lenovo X230
Those touchpads presents an actual lower resolution that what is
advertised.
We see some jumps from the cursor due to the big steps in X and Y
when we are receiving data.
For instance, we receive:
E: 13.471932 0003 16366# EV_ABS / ABS_X16366
E: 13.471932 0003 0001 9591 # EV_ABS / ABS_Y9591
E: 13.471932 # SYN_REPORT (0) --
E: 13.479924 0003 16316# EV_ABS / ABS_X16316
E: 13.479924 0003 0001 9491 # EV_ABS / ABS_Y9491
E: 13.479924 # SYN_REPORT (0) --
E: 13.487939 0003 16271# EV_ABS / ABS_X16271
E: 13.487939 0003 0001 9403 # EV_ABS / ABS_Y9403
E: 13.487939 # SYN_REPORT (0) --
-> jumps of ~50 in X in each report, and ~100 for Y.
Apply a factor to minimize those jumps at low speed and try keeping
the same feeling as regular touchpads at high speed. It still feels
slower but it is usable at least
Signed-off-by: Benjamin Tissoires
Signed-off-by: Peter Hutterer
---
Changes to v1:
- a bit more generic than the original, makes adding new models more
straightforward.
Changes to v2:
- changed the incline parameter to have a touchpad which feels like the other.
Not sure these are the final parameters but they make the touchpad much
better.
doc/device-configuration-via-udev.dox |9
src/evdev-mt-touchpad.c | 14 ++--
src/evdev.c | 23 ++
src/evdev.h |7 ++
src/filter.c | 34 +
src/filter.h |5
6 files changed, 89 insertions(+), 3 deletions(-)
diff --git a/doc/device-configuration-via-udev.dox
b/doc/device-configuration-via-udev.dox
index fc1c0af..c570913 100644
--- a/doc/device-configuration-via-udev.dox
+++ b/doc/device-configuration-via-udev.dox
@@ -57,6 +57,15 @@ See @ref motion_normalization for details.
The angle in degrees for each click on a mouse wheel. See
libinput_pointer_get_axis_source() for details.
+LIBINPUT_MODEL_LENOVO_X230
+Do not use for anything except a Lenovo X230 series (you have been
+warned).
+This flag allows libinput to apply a different acceleration profile for the
+touchpads of this series of laptops to counter a hardware deficiency. It may
+also be use to tune other parts of the inputs of these laptops, so the effects
+of this property may change anytime and will be only tested against the
+mentioned laptop series.
+
Below is an example udev rule to assign "seat1" to a device from vendor
diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index 4e5a558..f88e906 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -998,6 +998,7 @@ static int
tp_init_accel(struct tp_dispatch *tp, double diagonal)
{
int res_x, res_y;
+ accel_profile_func_t profile;
res_x = tp->device->abs.absinfo_x->resolution;
res_y = tp->device->abs.absinfo_y->resolution;
@@ -1021,9 +1022,16 @@ tp_init_accel(struct tp_dispatch *tp, double diagonal)
tp->accel.y_scale_coeff = DEFAULT_ACCEL_NUMERATOR / diagonal;
}
- if (evdev_device_init_pointer_acceleration(
- tp->device,
- touchpad_accel_profile_linear) == -1)
+ switch (tp->device->model) {
+ case EVDEV_MODEL_LENOVO_X230:
+ profile = touchpad_lenovo_x230_accel_profile;
+ break;
+ default:
+ profile = touchpad_accel_profile_linear;
+ break;
+ }
+
+ if (evdev_device_init_pointer_acceleration(tp->device, profile) == -1)
return -1;
return 0;
diff --git a/src/evdev.c b/src/evdev.c
index 5b4b2b6..0b705e4 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -1356,6 +1356,28 @@ evdev_read_dpi_prop(struct evdev_device *device)
return dpi;
}
+static inline enum evdev_device_model
+evdev_read_model(struct evdev_device *device)
+{
+ const struct model_map {
+ const char *property;
+ enum evdev_device_model model;
+ } model_map[] = {
+ { "LIBINPUT_MODEL_LENOVO_X230", EVDEV_MODEL_LENOVO_X230 },
+ { NULL, EVDEV_MODEL_DEFAULT },
+ };
+ const struct model_map *m = model_map;
+
+ while (m->property) {
+ if (!!udev_device_get_property_value(device->udev_device,
+m->property))
+ break;
+ m++;
+ }
+
+ return m->model;
+}
+
/* Return 1 if the given resolutions have been set, or 0 otherwise */
inline int
evdev_fix_abs_resolution(struct evdev_device *device,
@@ -1868,6 +1890,7 @@ evdev_device_create(struct libinput_seat *seat,
devic
[PATCH v3 1/4] filter: break out accel_profile_linear from pointer_accel_profile_linear
No functional code. Allows to reuse the linear filtering in other
acceleration profiles.
Signed-off-by: Benjamin Tissoires
---
no changes since v1
src/filter.c | 20 +++-
1 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/src/filter.c b/src/filter.c
index 962d74d..f7ff426 100644
--- a/src/filter.c
+++ b/src/filter.c
@@ -305,6 +305,20 @@ create_pointer_accelerator_filter(accel_profile_func_t
profile)
return &filter->base;
}
+static double
+accel_profile_linear(double speed_in,
+const double max_accel,
+const double threshold,
+const double incline)
+{
+ double s1, s2;
+
+ s1 = min(1, speed_in * 5);
+ s2 = 1 + (speed_in - threshold) * incline;
+
+ return min(max_accel, s2 > 1 ? s2 : s1);
+}
+
double
pointer_accel_profile_linear(struct motion_filter *filter,
void *data,
@@ -314,15 +328,11 @@ pointer_accel_profile_linear(struct motion_filter *filter,
struct pointer_accelerator *accel_filter =
(struct pointer_accelerator *)filter;
- double s1, s2;
const double max_accel = accel_filter->accel; /* unitless factor */
const double threshold = accel_filter->threshold; /* units/ms */
const double incline = accel_filter->incline;
- s1 = min(1, speed_in * 5);
- s2 = 1 + (speed_in - threshold) * incline;
-
- return min(max_accel, s2 > 1 ? s2 : s1);
+ return accel_profile_linear(speed_in, max_accel, threshold, incline);
}
double
--
1.7.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH v3 4/4] evdev: Fix reported resolution of Lenovo X230 touchpads
The Lenovo X230 advertise a vertical resolution of 136, which gives a size
of 31 mm. The actual size of the touchpad is 40mm, so override the
resolution to 100.
/!\ This is a temporary fix. The proper fix should go in hwdb. /!\
Signed-off-by: Benjamin Tissoires
---
changes to v1:
- updated with previous series :)
src/evdev.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/src/evdev.c b/src/evdev.c
index 0b705e4..8cd12cb 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -1491,6 +1491,17 @@ evdev_fix_android_mt(struct evdev_device *device)
libevdev_get_abs_info(evdev, ABS_MT_POSITION_Y));
}
+static inline void
+evdev_fix_x230_res(struct evdev_device *device)
+{
+ struct libevdev *evdev = device->evdev;
+
+ /* ugly hack while EV_ABS_OVERRIDE is merged in udev */
+
+ if (device->model == EVDEV_MODEL_LENOVO_X230)
+ libevdev_set_abs_resolution(evdev, ABS_Y, 100);
+}
+
static inline int
evdev_check_min_max(struct evdev_device *device, unsigned int code)
{
@@ -1681,6 +1692,8 @@ evdev_configure_device(struct evdev_device *device)
evdev_fix_android_mt(device);
if (libevdev_has_event_code(evdev, EV_ABS, ABS_X)) {
+ evdev_fix_x230_res(device);
+
if (evdev_fix_abs_resolution(device,
ABS_X,
ABS_Y,
--
1.7.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 5/6] compositor-drm: Fix refresh rate selection in drm_output_switch_mode
On 02/04/15 12:10 AM, Mario Kleiner wrote:
> The matching logic in choose_mode() compared refresh rate
> of a drm_mode candidate mode expressed in Hz against the
> requested refresh rate of the target weston_mode expressed
> in milliHz, so the match always failed and the logic always
> ended up the mode with the highest refresh rate for a given
> resolution, instead of the one matching the requested rate.
>
> Match proper fields to fix this.
>
> Signed-off-by: Mario Kleiner
> ---
> src/compositor-drm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> index 9ddb6d6..396938f 100644
> --- a/src/compositor-drm.c
> +++ b/src/compositor-drm.c
> @@ -1270,7 +1270,7 @@ choose_mode (struct drm_output *output, struct
> weston_mode *target_mode)
> wl_list_for_each(mode, &output->base.mode_list, base.link) {
> if (mode->mode_info.hdisplay == target_mode->width &&
> mode->mode_info.vdisplay == target_mode->height) {
> - if (mode->mode_info.vrefresh == target_mode->refresh ||
> + if (mode->base.refresh == target_mode->refresh ||
Definitely wrong in the current form, but I'm mildly concerned that the
math used to calculate mode->base.refresh is not just 1000 *
mode_info.vdisplay.
For my monitor, 1280x1024 with vrefresh = 60 has a refresh = 60020
1440x900@60 -> 59901
Should we be trying to do a nearest match instead of an exact match?
> target_mode->refresh == 0) {
> return mode;
> } else if (!tmp_mode)
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 3/6] desktop-shell: Allow multiple active fullscreen windows on multi-display setup.
On 02/04/15 12:10 AM, Mario Kleiner wrote:
> Desktop shell demoted all fullscreen shell surfaces on all active
> outputs of a multi-display setup whenever any shell surface was
> activated anywhere. This made it impossible to have multiple
> fullscreen windows on separate outputs active at the same
> time, as creating or activating any shell surface would disable
> fullscreen status for all existing fullscreen surfaces.
>
> Make lower_fullscreen_layer() more selective, so on request it
> only demotes fullscreen surfaces on a specified weston_output.
>
> The activate() method for a specific surface will now only request
> demotion of fullscreen surfaces on the target output of the activated
> surface, but leave fullscreen surfaces on unrelated outputs alone.
>
> Desktop wide acting functions like the window switcher or exposay
> will still demote all fullscreen surfaces on all outputs to
> implement their effect as before.
>
> Signed-off-by: Mario Kleiner
> ---
Looks sensible to me
Reviewed-By: Derek Foreman
> desktop-shell/exposay.c | 2 +-
> desktop-shell/shell.c | 47 +++
> desktop-shell/shell.h | 3 ++-
> 3 files changed, 38 insertions(+), 14 deletions(-)
>
> diff --git a/desktop-shell/exposay.c b/desktop-shell/exposay.c
> index 4b65cbd..a15fc7a 100644
> --- a/desktop-shell/exposay.c
> +++ b/desktop-shell/exposay.c
> @@ -563,7 +563,7 @@ exposay_transition_active(struct desktop_shell *shell)
> shell->exposay.clicked = NULL;
> wl_list_init(&shell->exposay.surface_list);
>
> - lower_fullscreen_layer(shell);
> + lower_fullscreen_layer(shell, NULL);
> shell->exposay.grab_kbd.interface = &exposay_kbd_grab;
> weston_keyboard_start_grab(seat->keyboard,
> &shell->exposay.grab_kbd);
> diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
> index f7c928e..7d0e403 100644
> --- a/desktop-shell/shell.c
> +++ b/desktop-shell/shell.c
> @@ -303,17 +303,29 @@ static bool
> shell_surface_is_top_fullscreen(struct shell_surface *shsurf)
> {
> struct desktop_shell *shell;
> - struct weston_view *top_fs_ev;
> + struct weston_view *view;
> + struct shell_surface *top_fs_shsurf = NULL;
>
> shell = shell_surface_get_shell(shsurf);
>
> if (wl_list_empty(&shell->fullscreen_layer.view_list.link))
> return false;
>
> - top_fs_ev = container_of(shell->fullscreen_layer.view_list.link.next,
> - struct weston_view,
> - layer_link.link);
> - return (shsurf == get_shell_surface(top_fs_ev->surface));
> + /* Find topmost shsurf on the same fullscreen output on which shsurf
> + * is displaying. We don't care about other outputs.
> + */
> + wl_list_for_each(view, &shell->fullscreen_layer.view_list.link,
> + layer_link.link) {
> + struct shell_surface *cand_shsurf =
> get_shell_surface(view->surface);
> +
> + if (cand_shsurf &&
> + (cand_shsurf->fullscreen_output ==
> shsurf->fullscreen_output)) {
> + top_fs_shsurf = cand_shsurf;
> + break;
> + }
> + }
> +
> + return (shsurf == top_fs_shsurf);
> }
>
> static void
> @@ -5000,10 +5012,14 @@ rotate_binding(struct weston_seat *seat, uint32_t
> time, uint32_t button,
> * and this is reversed when such a surface is re-configured, see
> * shell_configure_fullscreen() and shell_ensure_fullscreen_black_view().
> *
> + * lowering_output = NULL - Lower on all outputs, else only lower on the
> + * specified output.
> + *
> * This should be used when implementing shell-wide overlays, such as
> * the alt-tab switcher, which need to de-promote fullscreen layers. */
> void
> -lower_fullscreen_layer(struct desktop_shell *shell)
> +lower_fullscreen_layer(struct desktop_shell *shell,
> +struct weston_output
> *lowering_output)
> {
> struct workspace *ws;
> struct weston_view *view, *prev;
> @@ -5017,6 +5033,12 @@ lower_fullscreen_layer(struct desktop_shell *shell)
> if (!shsurf)
> continue;
>
> + /* Only lower surfaces which have lowering_output as their
> fullscreen
> + * output, unless a NULL output asks for lowering on all
> outputs.
> + */
> + if (lowering_output && (shsurf->fullscreen_output !=
> lowering_output))
> + continue;
> +
> /* We can have a non-fullscreen popup for a fullscreen surface
>* in the fullscreen layer. */
> if (shsurf->state.fullscreen) {
> @@ -5047,9 +5069,13 @@ activate(struct desktop_shell *shell, struct
> weston_surface *es,
> struct weston_surface *old_es;
> struct shell_surface *shsurf;
>
> - lower_fullscreen_layer(shel
Re: [PATCH 4/6] compositor-drm/shell: Allow restore_output_mode() to work properly.
On 02/04/15 12:10 AM, Mario Kleiner wrote:
> Initialize output->native_mode with the initially chosen
> mode for an output, so restore_output_mode() has something
> to work with and can switch back from temporary selected modes
> to the outputs native mode. Before, this was a no-op.
>
> This allows an output to switch back to its default mode if
> a former toplevel fullscreen shell surface created via method
> WL_SHELL_SURFACE_FULLSCREEN_METHOD_DRIVER gets destroyed, or
> demoted to non-fullscreen, or if modesetting on the output
> failed.
>
> Also fix desktop-shell's activate method to only restore
> output mode on the output on which a shell surface gets
> activated. This way fullscreen windows can mode switch their
> output, but window switching and exposay still works in the
> expected way.
>
> Signed-off-by: Mario Kleiner
> ---
> desktop-shell/shell.c | 3 ++-
> src/compositor-drm.c | 4
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
> index 7d0e403..68846ed 100644
> --- a/desktop-shell/shell.c
> +++ b/desktop-shell/shell.c
> @@ -2962,6 +2962,7 @@ shell_configure_fullscreen(struct shell_surface *shsurf)
>output->y - surf_y);
> break;
> } else {
> + weston_log("shell: Can't switch to temporary
> mode.\n");
> restore_output_mode(output);
> center_on_output(shsurf->view, output);
> }
> @@ -5089,7 +5090,7 @@ activate(struct desktop_shell *shell, struct
> weston_surface *es,
> if (shsurf->state.fullscreen && configure)
> shell_configure_fullscreen(shsurf);
> else
> - restore_all_output_modes(shell->compositor);
> + restore_output_mode(shsurf->output);
>
> /* Update the surface’s layer. This brings it to the top of the stacking
>* order as appropriate. */
I think above and below this point should be two separate patches.
> diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> index 4a7baa1..9ddb6d6 100644
> --- a/src/compositor-drm.c
> +++ b/src/compositor-drm.c
> @@ -2209,6 +2209,10 @@ create_output_for_connector(struct drm_compositor *ec,
> connector->count_modes == 0 ?
> ", built-in" : "");
>
> + /* Initialize output->native_mode field, so restore_output_mode()
> works. */
> + weston_output_mode_set_native(&output->base, output->base.current_mode,
> +
> output->base.current_scale);
> +
> return 0;
>
> err_output:
>
I'm not sure this is right - I think just setting
output->base.native_mode = output->base.current_mode would have the same
end result without triggering all the mode switch related machinery?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: EFL/Wayland and xdg-shell
Hi,
On 15 April 2015 at 23:51, Carsten Haitzler wrote:
> On Wed, 15 Apr 2015 20:29:32 +0100 Daniel Stone said:
>> On 15 April 2015 at 02:39, Carsten Haitzler wrote:
>> > not esoteric - an actual request from people making products.
>>
>> The reason I took that as 'esoteric' was that I assumed it was about
>> free window rotation inside Weston: a feature which is absolutely
>> pointless but as a proof-of-concept for a hidden global co-ordinate
>> space. Makes a lot more sense for whole-display rotation. More below.
>
> not just whole display - but now imagine a table with a screen and touch and 4
> people around it one along each side and multiple windows floating about like
> scraps of paper... just an illustration where you'd want window-by-window
> rotation done by compositor as well.
Sure, but that's complex enough - and difficult enough to reason even
about the desired UI semantics - that it really wants a prototype
first, or even a mockup. How do you define orientation in a table
scenario? If you're doing gesture-based/constant rotation (rather than
quantised to 90°), how do you animate that, and where does the
threshold for relayout lie? Without knowing what to design for, it's
hard to come up with a protocol which makes sense.
Luckily, writing extensions is infinitely less difficult than under
X11, so the general approach has been to farm these out to separate
extensions and then bring them in later if they turn out to make sense
in a global context. The most relevant counter-example (and
anti-pattern) I can think of is XI2 multitouch, where changing things
was so difficult that we had to design from the moon from the get-go.
The result, well, was XI2 multitouch. Not my finest moment, but
luckily I stepped out before it was merged so can just blame Peter.
>> > actually the other way around... clients know where the vkbd region(s) are
>> > so client can shuffle content to be visible. :)
>>
>> In a VKB (rather than overlay-helper, as used for complex composition)
>> scenario, I would expect xdg-shell to send a configure event to resize
>> the window and allow for the VKB. If this isn't sufficient - I
>> honestly don't know what the behaviour is under X11 - then a potential
>> version bump of wl_text could provide for this.
>
> no - resizing is a poorer solution. tried that in x11. first obvious port of
> call. imagine vkbd is partly translucent... you want it to still be over
> window
> content. imagine a kbd split onto left and right halves, one in the middle of
> the left and right edges of the screen (because screen is bigger). :)
Yeah, gotcha; it does fall apart after more than about a minute's
thought. Seems like this has been picked up though, so happy days.
>> > (pretend a phone with 4 external monitors attached).
>>
>> Hell of a phone. More seriously, yes, a display-management API could
>> expose this, however if the aim is for clients to communicate intent
>> ('this is a presentation') rather than for compositors to communicate
>> situation ('this is one of the external monitors'), then we probably
>> don't need this. wl_output already provides the relative geometry, so
>> all that is required for this is a way to communicate output type.
>
> i was thinking a simplified geometry. then again client toolkits can figure
> that out and present a simplified enum or what not to the app too. but yes -
> some enumerated "type" attached to the output would be very nice. smarter
> clients can decide their intent based on what is listed as available - adapt
> to
> the situation. dumber ones will just ask for a fixed type and "deal with it"
> if they don't get it.
I think exposing an output type would be relatively uncontroversial.
The fullscreen request already takes a target output; would that cover
your uses, or do you really need to request initial presentation of
non-fullscreen windows on particular outputs? (Actually, I can see
that: you'd want your PDF viewer's primary view to tack to your
internal output, and its presentation view aimed at the external
output. Jasper/Manuel - any thoughts?)
>> > surfaces should be
>> > able to hint at usage - eg "i want to be on the biggest tv". "i want to be
>> > wherever you have a small mobile touch screen" etc. compositor deals with
>> > deciding where they would go based on the current state of the world
>> > screen-wise and app hints.
>>
>> Right. So if we do have this client-intent-led interface (which would
>> definitely be the most Wayland-y approach), then we don't need to
>> advertise output types and wl_output already deals with the rest, so
>> no change required here?
>
> well the problem here is the client is not aware of the current situation. is
> that output on the right a tv on the other side of the room, ore a projector,
> or
> perhaps an internal lcd panel? is it far from the user or touchable (touch
> surface). if it's touchable the app may alter ui (make buttons bigger - remove
> scrollbars to go into a touch ui mode as oppose
Re: [PATCH libinput v2 4/4] touchpad: Implement pinch gesture support
Hi,
On 09-04-15 07:25, Peter Hutterer wrote:
On Thu, Mar 26, 2015 at 10:04:40AM +0100, Hans de Goede wrote:
Implement touchpad pinch (and rotate) gesture support.
Note that two two-finger scrolling tests are slightly tweaked to assure that
there is enough touch movement to allow the scroll-or-pinch detect code to do
its works.
Signed-off-by: Hans de Goede
---
src/evdev-mt-touchpad-gestures.c | 268 ++-
src/evdev-mt-touchpad.h | 17 +++
src/libinput-private.h | 33 +
test/touchpad.c | 4 +-
4 files changed, 315 insertions(+), 7 deletions(-)
diff --git a/src/evdev-mt-touchpad-gestures.c b/src/evdev-mt-touchpad-gestures.c
index 017354c..3d3dcaf 100644
--- a/src/evdev-mt-touchpad-gestures.c
+++ b/src/evdev-mt-touchpad-gestures.c
@@ -22,7 +22,6 @@
#include "config.h"
-#include
#include
#include
#include
@@ -30,6 +29,7 @@
#include "evdev-mt-touchpad.h"
#define DEFAULT_GESTURE_SWITCH_TIMEOUT 100 /* ms */
+#define DEFAULT_GESTURE_2FG_SCROLL_TIMEOUT 1000 /* ms */
static struct normalized_coords
tp_get_touches_delta(struct tp_dispatch *tp, bool average)
@@ -75,6 +75,7 @@ tp_get_average_touches_delta(struct tp_dispatch *tp)
static void
tp_gesture_start(struct tp_dispatch *tp, uint64_t time)
{
+ struct libinput *libinput = tp->device->base.seat->libinput;
const struct normalized_coords zero = { 0.0, 0.0 };
if (tp->gesture.started)
@@ -82,7 +83,21 @@ tp_gesture_start(struct tp_dispatch *tp, uint64_t time)
switch (tp->gesture.finger_count) {
case 2:
- /* NOP */
+ switch (tp->gesture.twofinger_state) {
+ case GESTURE_2FG_STATE_NONE:
+ case GESTURE_2FG_STATE_UNKNOWN:
+ log_bug_libinput(libinput,
+"%s in unknown gesture mode\n", __func__);
nitpick: for multi-line calls please line up the arguments with the opening
parenthesis where possible and use one arg per line. So this would become:
log_bug_libinput(libinput,
"%s in unknown gesture mode\n",
__func__);
Thanks for the review.
Fixed in the gestures branch of my personal repo.
+ break;
+ case GESTURE_2FG_STATE_SCROLL:
+ /* NOP */
+ break;
+ case GESTURE_2FG_STATE_PINCH:
+ gesture_notify_pinch(&tp->device->base, time,
+ LIBINPUT_EVENT_GESTURE_PINCH_START,
+ &zero, &zero, 0.0, 0.0);
+ break;
+ }
break;
case 3:
case 4:
@@ -114,8 +129,172 @@ tp_gesture_post_pointer_motion(struct tp_dispatch *tp,
uint64_t time)
}
}
+static unsigned int
+tp_gesture_get_active_touches(struct tp_dispatch *tp,
+ struct tp_touch **touches,
+ unsigned int count)
+{
+ unsigned int i, n = 0;
+ struct tp_touch *t;
+
+ memset(touches, 0, count * sizeof(struct tp_touch *));
+
+ for (i = 0; i < tp->real_touches; i++) {
+ t = &tp->touches[i];
+ if (tp_touch_active(tp, t)) {
+ touches[n++] = t;
+ if (n == count)
+ return count;
+ }
+ }
+
+ /*
+* This can happen when the user does .e.g:
+* 1) Put down 1st finger in center (so active)
+* 2) Put down 2nd finger in a button area (so inactive)
+* 3) Put down 3th finger somewhere, gets reported as a fake finger,
+*so gets same coordinates as 1st -> active
+*
+* We could avoid this by looking at all touches, be we really only
+* want to look at real touches.
+*/
+ return n;
+}
+
+static int
+tp_gesture_get_direction(struct tp_dispatch *tp, int touch)
+{
+ struct normalized_coords normalized;
+ double move_threshold;
+
+ /*
+* Semi-mt touchpads have somewhat inaccurate coordinates when
+* 2 fingers are down, so use a slightly larger threshold.
+*/
+ if (tp->semi_mt)
+ move_threshold = TP_MM_TO_DPI_NORMALIZED(4);
+ else
+ move_threshold = TP_MM_TO_DPI_NORMALIZED(3);
+
+ normalized = tp_normalize_delta(tp,
+ device_delta(tp->gesture.touches[touch]->point,
+ tp->gesture.touches[touch]->gesture.initial));
temp. variable please, with the indentation it's not immediately obvious
what calls what, so this would be better as:
struct tp_touch *t = &tp->gesture.touches[touch];
struct device_float_coords delta;
delta = device_delta(t->point, t->gesture.initial);
normalized
Re: EFL/Wayland and xdg-shell
Hi, On 16.04.2015 00:51, Carsten Haitzler (The Rasterman) wrote: actually the other way around... clients know where the vkbd region(s) are so client can shuffle content to be visible. :) In a VKB (rather than overlay-helper, as used for complex composition) scenario, I would expect xdg-shell to send a configure event to resize the window and allow for the VKB. If this isn't sufficient - I honestly don't know what the behaviour is under X11 - then a potential version bump of wl_text could provide for this. no - resizing is a poorer solution. tried that in x11. first obvious port of call. imagine vkbd is partly translucent... you want it to still be over window content. imagine a kbd split onto left and right halves, one in the middle of the left and right edges of the screen (because screen is bigger). :) Yes on the Nokia N9 we also solved the problem with widget relocation instead of resizing (see http://www.jonnor.com/files/maliit/maliit-lmt-technical-overview-widget-reloc.pdf) I will add an event to the text protocol to support that. Regards Jan Arne -- Jan Arne Petersen | jan.peter...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] protocol: Add DnD actions
Hey Jonas,
On Thu, Apr 16, 2015 at 10:15 AM, Jonas Ådahl wrote:
>
> I'd have to agree on that it doesn't seem like the best thing to let the
> compositor choose the preferred action. Having it apply compositor
> specific policy given what the keyboard state or similar will probably
> never work out very well, given that for example what modifier state
> means what type of action is very application dependent.
>
> On the other hand, I'm not sure we can currently rely on either side
> having keyboard focus during the drag. In weston the source will have the
> focus because starting the drag was done with a click which gave the
> surface keyboard focus implicitly, but what'd happen if the compositor
> has keyboard-focus-follows-mouse? We could probably say that drag implies
> an implicit grab on another device on the same seat to enforce no
> changing of keyboard focus, but not sure that is better.
In gtk+/gnome we currently have the following keybindings active during DnD:
- Cursor keys move the drag point, modifiers affect speed
- Esc key cancels drag
- Modifiers alone pick an action from the offered list
So ok, the latter is dubious to punt to compositors, but there's
basically no other choice with the 2 first ones.
More generally, I have the opinion that compositors grabs should
behave all consistently, as in:
- Ensuring clients reset all input state (we eg. don't cancel ongoing
touches when xdg_popup/dnd/... grabs kick in)
- Ensuring the grab affects the routing of all devices/events, and
that no client gets partial streams
For the touch case, depending on how the grab is implemented, with the
current guidelines the only 2 choices are "leave the client in
inconsistent state" or "make the client still receives ongoing touches
despite the pointer grab" (same applies if the grab is touch
triggered, only with the other touches that didn't trigger the grab).
More on topic, keyboards are also funky if we keep focus on clients,
you can conceivably Esc/Ctrl-Q/... to close the app you're dragging
from. IMO the way forward is precisely this, the compositor becomes in
control of the keyboard, and we offer the missing semantics to cover
for this.
>
> I also don't see the variable state to be a good thing considering we'd
> have three independent states, meaning it'd get a very racy and
> non-deterministic protocol.
Ideally all of this would have been right from the start as parameters
to wl_data_device.start_drag, wl_data_device.enter and
wl_data_offer.accept. Despite the extra combinations in data flow, I
fail to see how this gets racy or non-deterministic, you surely will
get a supported action and mimetype on the drag dest, or the drag will
be cancelled. If it is more conforting, we can make it more explicit
that wl_data_offer.notify_actions is the central point where DnD
success/action is decided, and that wl_data_offer.accept/receive are a
second step after it.
>
> If we'd want to have the destination choose the action, the source
> should advertise its possible actions, forwarded by the compositor to
> the destination ("atomically", without intermediate committed state).
wl_data_offer.source_actions?
>
> If we want to enable one of the clients to rely on keyboard modifier
> state, I think this should be communicated to the deciding end point;
Which used to be the drag source in XDND, as the holder of
pointer/keyboard grabs. It would update the "preferred action" that
was communicated then to the drag dest. If we do this 1:1 we probably
don't get rid of any of the "racyness" you see, and I suspect punting
it to the drag dest will involve a few changes in toolkits, plus
separate event handling paths from X11's.
> which I suspect is what Bill is talking about regarding the 'state'
> that is sent from the compositor.
>
>> >
>> > I am VERY much in favor of moving as much logic as possible from the
>> > compositor to the clients. And f(A,B,state) is a very complicated
>> > function. B may not be a list, it could be, in effect, infinite in
>> > size
>>
>> Are you maybe folding mimetypes and actions as A/B/C above? The only
>> thing that can grow "unbounded" is the mimetype list, the possible
>> actions are always a fixed set, and resolved after the mimetype is
>> negotiated. AFAICS "B" corresponds to the dest side, which confuses
>> me, because both the picked mimetype and action will always be a
>> subset of A's.
>>
>> > (a client conceivably could ask the user to type a filename that the
>> > drop should go to), can vary quickly (as the user moves across
>> > widget
>> > boundaries), and can contain items the compositor has no business
>> > knowing about (a paint program may ask how to tile a dropped
>> > pattern).
>>
>> Ah, I see, perhaps it's rather "varying over time" than "infinite"?
>> TBH I don't see how this is different to how mimetypes are dealt with,
>> you definitely don't have to calculate all possible states at once,
>> just for the position you're in.
>
> For clarification: I think
Re: [RFC PATCH v2 wayland] protocol: add wl_pointer.axis_source, axis_stop and axis_discrete events
On Tue, Apr 07, 2015 at 01:19:24PM +1000, Peter Hutterer wrote: > On Fri, Mar 27, 2015 at 10:23:43AM +0800, Jonas Ådahl wrote: > > > > Follow up questions: > > > > Do we expect to get axis_stop on both the horizontal and vertical axes, > > and is the client supposed to trigger its kinetic scrolling when both > > axises has stopped or just the first one? How would one interpret only > > one axis receiving the stop event but not the other? > > I'm not sure here tbh. I think it'd be good enough to say that this affects > all scroll directions currently active, but that's based on a couple of > conditions: > * the case of kinetic scrolling on two devices independently is a niche case > we don't care about. that's easy Yea that sounds a bit unusual. One touchpad for each hand, one for horizontal and one for vertical movements? :P > * we only have scroll axes so far, if we add unrelated axes to the > wl_pointer.axes set this gets a bit hairy. e.g. does a kinetic scrolling > stop affect a future rotation axis? > the solution here could be to add flags to the stop event to specify the > axes that stopped scrolling. Given what you said above (axis_stop affecting all scroll directions), it'd mean it'd have to be an array, since we otherwise would need two axis_stop events to get an atomic end event. Or say "any axis_stop on a "scroll" axis stops the other one as well. > > > Will we ever send axis_stop when the source is 'continuous' (or any > > other possibe source), and how to determine what source had its movement > > stopped in that case? With the current version, "axis_stop" is rather > > hard coded to "axis_finger_lifted" behind a generic name (which maybe is > > not that bad anyway though). > > I'll have to double check the code but iirc we send axis stop events in > libinput for some continuous scrolling. e.g. trackstick middle button > scrolling - releasing the middle button sends the scroll termination event. > we don't have a pre-notification in libinput though, so you won't know until > you get that stop event that you will get one. That's fixable but whether > it's needed is another matter: if you get it you'll get it fast enough to > trigger kinetics, otherwise you time out (and the stop event may come in > after the timeout). True, I suppose there is no usefulness with a warning. > > the axis_source is still prefixed to the axis_stop event, but that doesn't > scale if you have to independent scroll devices that use the same type. > Again, a question of whether that's required, if so we could assign some > sort of tracking ID to the scroll sequence like the touch sequences > have. Sounds a bit complex. If it ever turns out it is needed, that could be made into a separate extension IMHO. > > > > > > > + > > > > > + > > > > > + > > > > > + > > > > > +Scroll and other axis discrete step information. > > > > > + > > > > > +This event does not occur on its own. It is sent before a > > > > > +wl_pointer.axis event and carries the axis value of the > > > > > +wl_pointer.axis event in discrete steps (e.g. mouse wheel > > > > > clicks). > > > > > + > > > > > +This event is optional, continuous scrolling devices > > > > > +like two-finger scrolling on touchpads do not have discrete > > > > > +steps. > > > > > > > > Hmm. This means we wouldn't be able to convert the touch based scroll > > > > motions into the old scroll step clicks, since we wouldn't (reliably) > > > > know when a device would emit their own, since it doesn't specify > > > > exactly when to expect and not to expect. The client won't know whether > > > > there are "continuous scrolling devices" or not. > > > > > > > > Wouldn't it be easier to just provide XI2 style smooth scroll vectors, > > > > i.e. steps in "discrete scale", where a mouse scroll click is -1.0 or > > > > 1.0 and continuous scrolling is a fraction of such. Clients implementing > > > > version 5 can simply use the accumulation method for emitting scroll > > > > clicks without having to rely on the old "divide by 10" hack. > > > > > > > > This event is actually more like what I described in my previous mail > > > > that were more or less concluded to be not worth it, isn't it? > > > > > > the wl_pointer.axis documentation defines the axis events to be in the > > > same > > > coordinate space as motion data, there is nothing accommodating for mouse > > > wheel clicks. it's just magic knowledge with the value 10. > > > Adding this event set removes that magic knowledge, if you get an > > > axis_discrete event you can safely ignore the axis value and just scroll > > > by > > > the discrete value. > > > > > > I don't think the two should be merged into the same coordinate space. > > > It'd > > > be easier but also more error-prone. For example, on a touchpad you > > > probably > > > want scrolling to move at the same speed as the cursor would otherwise so > > > the content follow
Re: [PATCH] protocol: Add DnD actions
Hi,
Disclaimer: I don't know much how XDND works, but have some comments
anyway. See below:
On Sat, Apr 11, 2015 at 12:59:48PM +0200, Carlos Garnacho wrote:
> On vie, 2015-04-10 at 12:44 -0700, Bill Spitzak wrote:
> > On 04/10/2015 02:29 AM, Carlos Garnacho wrote:
> >
> > > > However the
> > > > compositor could send state along with A to the dest.
> > >
> > > This could also work,
> >
> > Thanks I think I finally made it clear what I am asking for.
>
> In fairness, your proposal started as something quite different, we
> happened to find the middle ground.
>
> >
> > So "intersection" is now f(A,B,state), and what I propose is:
> >
> > source sends A to compositor
> > compositor sends A to dest
> > compositor sends state to dest
> > dest does C = f(A,B,state)
> > dest sends C to compositor
> > compositor sends C to source
> >
> > "compositor sends state to dest" could very well mean that the dest
> > gets
> > events for the seat, as though it was temporarily focused. This
> > would
> > also allow the dest to make a popup menu to let the user choose an
> > action.
> >
> > > I however think it makes sense to abstract this a
> > > bit wrt the devices involved. Generally, wl_data_device nicely
> > > abstracts from the pointer/touch/device being used throughout the
> > > operation. It makes sense to me to do the same here, if what we are
> > > pursuing is a DnD action. Also, this IMO gives some degree of
> > > liberty
> > > wrt form factors, testing...
> >
> > Any such concerns like this apply to *all* events, there is nothing
> > special about the events during a DnD, and the clients must already
> > have
> > code to "abstract wrt the devices involved". The DnD should indicate
> > which "seat" is doing the drag however.
>
> DnD can be driven by mouse, touch, and stili when wl_tablet arrives.
> There's however no exposure of this on the events sent by data_device,
> everything happens in its own semantics rather than wl_pointer's or
> wl_touch's. I'm not sure why the actions derived from keyboards
> deserve a different treatment.
>
> >
> > > It's true that the modifier mapping becomes compositor-dependent
> > > (It's
> > > been traditionally on toolkit domain), but then so is every
> > > keycombo
> > > the compositor wants to implement.
> >
> > That seems completely different, as compositor bindings do actions
> > without communicating with any client (ie a key that launches a
> > particular client will work when there are no clients).
> >
> > > But I won't be as hard positioned on this one, if the consensus is
> > > that we better send pressed buttons/modifiers to the dest, it can
> > > be
> > > made to work.
> >
> > Anybody else want to say anything?
I'd have to agree on that it doesn't seem like the best thing to let the
compositor choose the preferred action. Having it apply compositor
specific policy given what the keyboard state or similar will probably
never work out very well, given that for example what modifier state
means what type of action is very application dependent.
On the other hand, I'm not sure we can currently rely on either side
having keyboard focus during the drag. In weston the source will have the
focus because starting the drag was done with a click which gave the
surface keyboard focus implicitly, but what'd happen if the compositor
has keyboard-focus-follows-mouse? We could probably say that drag implies
an implicit grab on another device on the same seat to enforce no
changing of keyboard focus, but not sure that is better.
I also don't see the variable state to be a good thing considering we'd
have three independent states, meaning it'd get a very racy and
non-deterministic protocol.
If we'd want to have the destination choose the action, the source
should advertise its possible actions, forwarded by the compositor to
the destination ("atomically", without intermediate committed state).
If we want to enable one of the clients to rely on keyboard modifier
state, I think this should be communicated to the deciding end point;
which I suspect is what Bill is talking about regarding the 'state'
that is sent from the compositor.
> >
> > I am VERY much in favor of moving as much logic as possible from the
> > compositor to the clients. And f(A,B,state) is a very complicated
> > function. B may not be a list, it could be, in effect, infinite in
> > size
>
> Are you maybe folding mimetypes and actions as A/B/C above? The only
> thing that can grow "unbounded" is the mimetype list, the possible
> actions are always a fixed set, and resolved after the mimetype is
> negotiated. AFAICS "B" corresponds to the dest side, which confuses
> me, because both the picked mimetype and action will always be a
> subset of A's.
>
> > (a client conceivably could ask the user to type a filename that the
> > drop should go to), can vary quickly (as the user moves across
> > widget
> > boundaries), and can contain items
Re: [PATCH libinput 1/1] touchpad: reduce palm detection threshold to 70mm
Hi, On 16-04-15 08:18, Peter Hutterer wrote: https://bugzilla.redhat.com/show_bug.cgi?id=1209753 lists a touchpad 76mm wide that suffers from palm touches Signed-off-by: Peter Hutterer Looks good: Reviewed-by: Hans de Goede Regards, Hans --- src/evdev-mt-touchpad.c | 2 +- test/touchpad.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c index 4e5a558..452cb85 100644 --- a/src/evdev-mt-touchpad.c +++ b/src/evdev-mt-touchpad.c @@ -1135,7 +1135,7 @@ tp_init_palmdetect(struct tp_dispatch *tp, /* Enable palm detection on touchpads >= 80 mm. Anything smaller probably won't need it, until we find out it does */ - if (width/device->abs.absinfo_x->resolution < 80) + if (width/device->abs.absinfo_x->resolution < 70) return 0; } diff --git a/test/touchpad.c b/test/touchpad.c index cd86f04..4e425f5 100644 --- a/test/touchpad.c +++ b/test/touchpad.c @@ -2469,7 +2469,7 @@ touchpad_has_palm_detect_size(struct litest_device *dev) rc = libinput_device_get_size(dev->libinput_device, &width, &height); - return rc == 0 && width >= 80; + return rc == 0 && width >= 70; } START_TEST(touchpad_palm_detect_at_edge) ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v2 libinput 4/6] evdev: enable middle button configuration on some devices
Hi,
On 16-04-15 07:39, Peter Hutterer wrote:
Devices that have left and right buttons but no middle button get middle
button emulation (without config). Devices that have a middle button too get
a config option but default to off. Most mice have LMR set as buttons,
regardless whether they have a middle button.
Signed-off-by: Peter Hutterer
Reviewed-by: Hans de Goede
---
Changes to v1:
- use extra variables to make the code clearer, no functional changes
otherwise
Looks good:
Reviewed-by: Hans de Goede
Regards,
Hans
src/evdev.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/src/evdev.c b/src/evdev.c
index 6ca874a..da33eae 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -1143,6 +1143,24 @@ fallback_dispatch_create(struct libinput_device *device)
evdev_init_calibration(evdev_device, dispatch);
evdev_init_sendevents(evdev_device, dispatch);
+ /* BTN_MIDDLE is set on mice even when it's not present. So
+* we can only use the absense of BTN_MIDDLE to mean something, i.e.
+* we enable it by default on anything that only has L&R.
+* If we have L&R and no middle, we don't expose it as config
+* option */
+ if (libevdev_has_event_code(evdev_device->evdev, EV_KEY, BTN_LEFT) &&
+ libevdev_has_event_code(evdev_device->evdev, EV_KEY, BTN_RIGHT)) {
+ bool has_middle = libevdev_has_event_code(evdev_device->evdev,
+ EV_KEY,
+ BTN_MIDDLE);
+ bool want_config = has_middle;
+ bool enable_by_default = !has_middle;
+
+ evdev_init_middlebutton(evdev_device,
+ enable_by_default,
+ want_config);
+ }
+
return dispatch;
}
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 1/2] test: add litest_is_button_event
Hi,
On 16-04-15 07:04, Peter Hutterer wrote:
Makes it easier from a caller to check for common things without all the other
boilerplate code.
Signed-off-by: Peter Hutterer
Looks good:
Reviewed-by: Hans de Goede
Regards,
Hans
---
test/litest.c | 26 +++---
test/litest.h | 4
2 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/test/litest.c b/test/litest.c
index 5c4f84d..5600b8e 100644
--- a/test/litest.c
+++ b/test/litest.c
@@ -1321,16 +1321,13 @@ litest_create_uinput_device(const char *name, struct
input_id *id, ...)
return uinput;
}
-void
-litest_assert_button_event(struct libinput *li, unsigned int button,
- enum libinput_button_state state)
+struct libinput_event_pointer*
+litest_is_button_event(struct libinput_event *event,
+ int button,
+ enum libinput_button_state state)
{
- struct libinput_event *event;
struct libinput_event_pointer *ptrev;
- litest_wait_for_event(li);
- event = libinput_get_event(li);
-
ck_assert(event != NULL);
ck_assert_int_eq(libinput_event_get_type(event),
LIBINPUT_EVENT_POINTER_BUTTON);
@@ -1339,6 +1336,21 @@ litest_assert_button_event(struct libinput *li, unsigned
int button,
button);
ck_assert_int_eq(libinput_event_pointer_get_button_state(ptrev),
state);
+
+ return ptrev;
+}
+
+void
+litest_assert_button_event(struct libinput *li, unsigned int button,
+ enum libinput_button_state state)
+{
+ struct libinput_event *event;
+
+ litest_wait_for_event(li);
+ event = libinput_get_event(li);
+
+ litest_is_button_event(event, button, state);
+
libinput_event_destroy(event);
}
diff --git a/test/litest.h b/test/litest.h
index 84567be..64db8c3 100644
--- a/test/litest.h
+++ b/test/litest.h
@@ -172,6 +172,10 @@ void litest_wait_for_event(struct libinput *li);
void litest_wait_for_event_of_type(struct libinput *li, ...);
void litest_drain_events(struct libinput *li);
void litest_assert_empty_queue(struct libinput *li);
+struct libinput_event_pointer * litest_is_button_event(
+ struct libinput_event *event,
+ int button,
+ enum libinput_button_state state);
void litest_assert_button_event(struct libinput *li,
unsigned int button,
enum libinput_button_state state);
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
