Re: [PATCH libinput 2/2] Rename functions for left handed device configurations
On Mon, Jan 05, 2015 at 05:44:38PM -0500, Stephen Chandler Paul wrote:
Some devices require more then just flipping around the buttons, such as
tablets.
typo: then - than
and pls sign off your patches. pls also add a sentence to explain what is
necessary, in this particular case we need to turn the tablet x/y upside
down for left-handed mode. and reorder the buttons but we don't support them
yet anyway
this is mostly a rename so I just comment here instead of inline:
if we make this a separate group from buttons, this should be named
libinput_device_config_left_handed_foo (make sure libinput.sym is
alphabetically sorted then).
all that also bumps the soname, so I'll try to combine it with the scrolling
API changes so we only need to bump it once.
Cheers,
Peter
---
src/evdev-mt-touchpad.c | 4 ++--
src/evdev.c | 34 +++---
src/evdev.h | 12 +--
src/libinput.c | 14 ++---
src/libinput.h | 55
-
src/libinput.sym| 8 +++
test/pointer.c | 12 +--
test/touch.c| 8 +++
test/touchpad.c | 18
tools/event-debug.c | 2 +-
tools/shared.c | 2 +-
11 files changed, 84 insertions(+), 85 deletions(-)
diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index 7e8306d..34b107e 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -1310,7 +1310,7 @@ tp_change_to_left_handed(struct evdev_device *device)
{
struct tp_dispatch *tp = (struct tp_dispatch *)device-dispatch;
- if (device-buttons.want_left_handed == device-buttons.left_handed)
+ if (device-left_handed.want_enabled == device-left_handed.enabled)
return;
if (tp-buttons.state 0x3) /* BTN_LEFT|BTN_RIGHT */
@@ -1319,7 +1319,7 @@ tp_change_to_left_handed(struct evdev_device *device)
/* tapping and clickfinger aren't affected by left-handed config,
* so checking physical buttons is enough */
- device-buttons.left_handed = device-buttons.want_left_handed;
+ device-left_handed.enabled = device-left_handed.want_enabled;
}
struct model_lookup_t {
diff --git a/src/evdev.c b/src/evdev.c
index 1718491..1fc1d6b 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -119,8 +119,8 @@ evdev_pointer_notify_button(struct evdev_device *device,
pointer_notify_button(device-base, time, button, state);
if (state == LIBINPUT_BUTTON_STATE_RELEASED
- device-buttons.change_to_left_handed)
- device-buttons.change_to_left_handed(device);
+ device-left_handed.change_to_enabled)
+ device-left_handed.change_to_enabled(device);
if (state == LIBINPUT_BUTTON_STATE_RELEASED
device-scroll.change_scroll_method)
@@ -810,13 +810,13 @@ evdev_left_handed_has(struct libinput_device *device)
static void
evdev_change_to_left_handed(struct evdev_device *device)
{
- if (device-buttons.want_left_handed == device-buttons.left_handed)
+ if (device-left_handed.want_enabled == device-left_handed.enabled)
return;
if (evdev_any_button_down(device))
return;
- device-buttons.left_handed = device-buttons.want_left_handed;
+ device-left_handed.enabled = device-left_handed.want_enabled;
}
static enum libinput_config_status
@@ -824,9 +824,9 @@ evdev_left_handed_set(struct libinput_device *device, int
left_handed)
{
struct evdev_device *evdev_device = (struct evdev_device *)device;
- evdev_device-buttons.want_left_handed = left_handed ? true : false;
+ evdev_device-left_handed.want_enabled = left_handed ? true : false;
- evdev_device-buttons.change_to_left_handed(evdev_device);
+ evdev_device-left_handed.change_to_enabled(evdev_device);
return LIBINPUT_CONFIG_STATUS_SUCCESS;
}
@@ -838,7 +838,7 @@ evdev_left_handed_get(struct libinput_device *device)
/* return the wanted configuration, even if it hasn't taken
* effect yet! */
- return evdev_device-buttons.want_left_handed;
+ return evdev_device-left_handed.want_enabled;
}
static int
@@ -851,14 +851,14 @@ int
evdev_init_left_handed(struct evdev_device *device,
void (*change_to_left_handed)(struct evdev_device *))
{
- device-buttons.config_left_handed.has = evdev_left_handed_has;
- device-buttons.config_left_handed.set = evdev_left_handed_set;
- device-buttons.config_left_handed.get = evdev_left_handed_get;
- device-buttons.config_left_handed.get_default =
evdev_left_handed_get_default;
- device-base.config.left_handed = device-buttons.config_left_handed;
- device-buttons.left_handed = false;
- device-buttons.want_left_handed = false;
-
Re: [PATCH libinput 1/6] touchpad: factor out fake finger handling
Hi,
On 16-12-14 04:14, Peter Hutterer wrote:
We need this for determining hovering touches on some semi-mt touchpads.
This makes the fake_touches mask use bit 1 for BTN_TOUCH,
I believe you mean bit 0 here (per the usual bit numbering conventions).
Other then that this looks good and is:
Reviewed-by: Hans de Goede hdego...@redhat.com
Regards,
Hans
and the other bits
for BTN_TOOL_FINGER, BTN_TOOL_DOUBLETAP, etc. BTN_TOUCH is independent of the
rest, the others are mutually exclusive in the kernel.
Since the mask isn't a straightforward bitmask anymore, abstract it all
through helper functions.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
src/evdev-mt-touchpad.c | 72 -
1 file changed, 53 insertions(+), 19 deletions(-)
diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index 32d6eac..42c163b 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -135,6 +135,57 @@ tp_get_touch(struct tp_dispatch *tp, unsigned int slot)
return tp-touches[slot];
}
+static inline int
+tp_fake_finger_count(struct tp_dispatch *tp)
+{
+ unsigned int fake_touches, nfake_touches;
+
+ /* don't count BTN_TOUCH */
+ fake_touches = tp-fake_touches 1;
+ nfake_touches = 0;
+ while (fake_touches) {
+ nfake_touches++;
+ fake_touches = 1;
+ }
+
+ return nfake_touches;
+}
+
+static inline bool
+tp_fake_finger_is_touching(struct tp_dispatch *tp)
+{
+ return tp-fake_touches 0x1;
+}
+
+static inline void
+tp_fake_finger_set(struct tp_dispatch *tp,
+ unsigned int code,
+ bool is_press)
+{
+ unsigned int shift;
+
+ switch (code) {
+ case BTN_TOUCH:
+ shift = 0;
+ break;
+ case BTN_TOOL_FINGER:
+ shift = 1;
+ break;
+ case BTN_TOOL_DOUBLETAP:
+ case BTN_TOOL_TRIPLETAP:
+ case BTN_TOOL_QUADTAP:
+ shift = code - BTN_TOOL_DOUBLETAP + 2;
+ break;
+ default:
+ return;
+ }
+
+ if (is_press)
+ tp-fake_touches |= 1 shift;
+ else
+ tp-fake_touches = ~(0x1 shift);
+}
+
static inline void
tp_begin_touch(struct tp_dispatch *tp, struct tp_touch *t, uint64_t time)
{
@@ -253,30 +304,13 @@ tp_process_fake_touch(struct tp_dispatch *tp,
uint64_t time)
{
struct tp_touch *t;
- unsigned int fake_touches;
unsigned int nfake_touches;
unsigned int i, start;
- unsigned int shift;
- if (e-code != BTN_TOUCH
- (e-code BTN_TOOL_DOUBLETAP || e-code BTN_TOOL_QUADTAP))
- return;
+ tp_fake_finger_set(tp, e-code, e-value != 0);
- shift = e-code == BTN_TOUCH ? 0 : (e-code - BTN_TOOL_DOUBLETAP + 1);
+ nfake_touches = tp_fake_finger_count(tp);
- if (e-value)
- tp-fake_touches |= 1 shift;
- else
- tp-fake_touches = ~(0x1 shift);
-
- fake_touches = tp-fake_touches;
- nfake_touches = 0;
- while (fake_touches) {
- nfake_touches++;
- fake_touches = 1;
- }
-
- /* For single touch tps we use BTN_TOUCH for begin / end of touch 0 */
start = tp-has_mt ? tp-real_touches : 0;
for (i = start; i tp-ntouches; i++) {
t = tp_get_touch(tp, i);
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 3/6] touchpad: add a TOUCH_HOVERING state
Hi,
On 16-12-14 04:14, Peter Hutterer wrote:
Some touchpads provide touch information while the finger hovers over the
touchpad, i.e. before BTN_TOUCH. Add a touch state for those touchpads so we
can ignore the touches until they actually start.
The approach is now: instead of BEGIN we mark a new touch as HOVERING.
Use the BTN_TOOL_FINGER, BTN_TOOL_DOUBLETAP information during
tp_process_state() to mark any touches that are hovering as down or ended.
i.e. provided BTN_TOUCH is down: if BTN_TOOL_FINGER is down, one hovering
touch gets marked as down, if DOUBLETAP is down, two touches are marked as
down, etc.
When ending touches, switch them back into HOVERING if the BTN_TOOL_FINGER
is still set, otherwise end them properly.
https://bugs.freedesktop.org/show_bug.cgi?id=87197
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
src/evdev-mt-touchpad-edge-scroll.c | 1 +
src/evdev-mt-touchpad.c | 81 -
src/evdev-mt-touchpad.h | 8 +++-
3 files changed, 78 insertions(+), 12 deletions(-)
diff --git a/src/evdev-mt-touchpad-edge-scroll.c
b/src/evdev-mt-touchpad-edge-scroll.c
index 616080f..55720f8 100644
--- a/src/evdev-mt-touchpad-edge-scroll.c
+++ b/src/evdev-mt-touchpad-edge-scroll.c
@@ -294,6 +294,7 @@ tp_edge_scroll_handle_state(struct tp_dispatch *tp,
uint64_t time)
switch (t-state) {
case TOUCH_NONE:
+ case TOUCH_HOVERING:
break;
case TOUCH_BEGIN:
tp_edge_scroll_handle_event(tp, t, SCROLL_EVENT_TOUCH);
diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index c80d314..4898950 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -180,24 +180,36 @@ tp_fake_finger_set(struct tp_dispatch *tp,
static inline void
tp_begin_touch(struct tp_dispatch *tp, struct tp_touch *t, uint64_t time)
{
- if (t-state == TOUCH_BEGIN || t-state == TOUCH_UPDATE)
+ if (t-state == TOUCH_BEGIN ||
+ t-state == TOUCH_UPDATE ||
+ t-state == TOUCH_HOVERING)
return;
+ /* we begin the touch as hovering because until BTN_TOUCH happens we
+* don't know if it's a touch down or not. And BTN_TOUCH may happen
+* after ABS_MT_TRACKING_ID */
tp_motion_history_reset(t);
t-dirty = true;
- t-state = TOUCH_BEGIN;
+ t-state = TOUCH_HOVERING;
t-pinned.is_pinned = false;
t-millis = time;
- tp-nfingers_down++;
- assert(tp-nfingers_down = 1);
tp-queued |= TOUCHPAD_EVENT_MOTION;
}
static inline void
tp_end_touch(struct tp_dispatch *tp, struct tp_touch *t, uint64_t time)
{
- if (t-state == TOUCH_END || t-state == TOUCH_NONE)
+ switch (t-state) {
+ case TOUCH_HOVERING:
+ t-state = TOUCH_NONE;
+ case TOUCH_NONE:
+ case TOUCH_END:
return;
+ case TOUCH_BEGIN:
+ case TOUCH_UPDATE:
+ break;
+
+ }
t-dirty = true;
t-is_pointer = false;
@@ -310,9 +322,6 @@ tp_process_fake_touch(struct tp_dispatch *tp,
else
tp_end_touch(tp, t, time);
}
-
- /* On mt the actual touch info may arrive after BTN_TOOL_FOO */
- assert(tp-has_mt || tp-nfingers_down == nfake_touches);
}
static void
@@ -327,6 +336,7 @@ tp_process_key(struct tp_dispatch *tp,
tp_process_button(tp, e, time);
break;
case BTN_TOUCH:
+ case BTN_TOOL_FINGER:
case BTN_TOOL_DOUBLETAP:
case BTN_TOOL_TRIPLETAP:
case BTN_TOOL_QUADTAP:
@@ -543,12 +553,56 @@ tp_remove_scroll(struct tp_dispatch *tp)
}
static void
+tp_unhover_touches(struct tp_dispatch *tp, uint64_t time)
+{
+ struct tp_touch *t;
+ unsigned int nfake_touches;
+ unsigned int i;
+
+ if (!tp-fake_touches !tp-nfingers_down)
+ return;
+
+ nfake_touches = tp_fake_finger_count(tp);
+ if (tp-nfingers_down == nfake_touches
+ ((tp-nfingers_down == 0 !tp_fake_finger_is_touching(tp)) ||
+(tp-nfingers_down 0 tp_fake_finger_is_touching(tp
+ return;
+
+ for (i = 0; i tp-ntouches; i++) {
+ t = tp_get_touch(tp, i);
+
+ /* if BTN_TOUCH is set, switch each hovering touch to BEGIN
+* until nfingers_down matches nfake_touches (or end touches
+* until that happens).
+* if BTN_TOUCH is unset, end all touches, we're hovering
+* all fingers now
+*/
+ if (t-state == TOUCH_HOVERING) {
+ if (tp_fake_finger_is_touching(tp)) {
+ t-state = TOUCH_BEGIN;
+ tp-nfingers_down++;
+
[weston-ivi-shell]Qestion about caller of [bind_shell] and [shell_get_shell_surface ]
Hi everyone I am testing QT/EFL application launch time from ICO-HomeScreen at tizenIVI platform,but the launch time is about 4 seconds. I analyze the NG log,and find result as below: (a) When QT application is laundch by AUL module,until the function [bind_shell] of weston-ivi-shell module is called,consumption time is 1 second.(Below step:2--3) (b) Until the function [shell_get_shell_surface ] of weston-ivi-shell module is called,consumption time is 1.5 second.(Below step:3--4) So i think the point is to find the caller of function [bind_shell] and [shell_get_shell_surface ]. I have two question for help,any answer is appreciate. Qeustion1:Are 「bind_shell」 and 「shell_get_shell_surface」 called by ＱＴ−Ｗａｙｌａｎｄ? （I search source of ＱＴ−Ｗａｙｌａｎｄ,but i did not find the right one） Qestion2:Do contents/screen rendering sequence as below?? Ａ） ＱＴ−Ｗａｙｌａｎｄ module create ＷＬ−Ｓｕｒｆａｃｅ. Ｂ） ＱＴ−Ｗａｙｌａｎｄ create contents on ＷＬ−Ｓｕｒｆａｃｅ. Ｃ） ＱＴ−Ｗａｙｌａｎｄ send request to ＩＶＩ−Ｓｈｅｌｌ for creating ＩＶＩ−Ｓｕｒｆａｃｅ（At this timing,i think that bind_shell and shell_get_shell_surface is called??） Ｄ） ＩＶＩ−Ｓｈｅｌｌ／ＩＶＩ−Ｃｏｎｔｒｏｌｌｅｒ create ＩＶＩ−Ｓｕｒｆａｃｅ,and send request toＩＣＯ−Ｈｏｍｅ for creaing Windows. Ｅ） ＩＣＯ−Ｈｏｍｅ useＩＶＩ−Ｃｏｎｔｒｏｌｌｅｒ to request sreen composition. Could anyone give me some advice? Software version tizen-3.0.m14.3-ivi_20141028.3 Referecen Log (1)23:05:56.731[PRF]@461 TOUCH_EVENT Menu Up (238,315)-(238,315) app=tizen.qt.media (TouchUpMenu,CicoHSMenuTouch.cpp:207) (2)23:05:56.862[DBG]@461 execute app tizen.qt.media (ExecuteApp_i,CicoHomeScreen.cpp:601) (3)23:05:57.742[DBG]@405 bind_shell start (bind_shell,ivi-shell/ivi-shell-ext.c:644) (4)23:05:59.209[DBG]@405 shell_get_shell_surface start (shell_get_shell_surface,ivi-shell/ivi-shell-ext.c:601) Best regards, Andy. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 1/7] protocol: add linux_dmabuf extension RFCv1
On Thu, Dec 18, 2014 at 01:45:22PM +0200, Pekka Paalanen wrote: On Thu, 18 Dec 2014 10:25:09 +0100 Daniel Vetter dan...@ffwll.ch wrote: On Fri, Dec 12, 2014 at 04:51:02PM -0500, Louis-Francis Ratté-Boulianne wrote: From: Pekka Paalanen pekka.paala...@collabora.co.uk An experimental (hence the 'z' prefix) linux_dmabuf Wayland protocol extension for creating dmabuf-based wl_buffers in a generic manner. This does not include proper dmabuf metadata negotiation because there is no way to communicate all dmabuf constraints from the compositor to a client before-hand. The client has to create a wl_buffer wrapping one or more dmabuf buffers and then listen at the feedback object returned to know if the operation was successful. Signed-off-by: Pekka Paalanen pekka.paala...@collabora.co.uk Signed-off-by: Louis-Francis Ratté-Boulianne l...@collabora.com So I have no idea about how wayland protos work, so please take that into account ;-) Hi Daniel, very much appreciated anyway! Generally I think we should try to follow what the drm addfb2 ioctl does in drm, since in the end we need to be able to handle pretty much all the same issues. Well wayland needs to solve a few more since it also must cope with buffer layouts which can only be used for rendering but not scanned out. Yes. The current proposal was written based on https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt which has some differences compared to addfb2, like having only 3 planes instead of 4. Wrt tiling layouts and compressed buffers and similar vendor specific things: The current proposal is to add a new uint64_t layout qualifier to addfb with opaque #defines (probably a new header), with an 8:56 bit split between vendor identifier and opaque vendor specified content. It will also be per-buffer (like pitches/offsets). The abi isn't locked down yet, but definitely something to keep in mind. Yup, I've seen it. It will definitely complicate the protocol though since the specific layout modifiers which are acceptable change dynamically at runtime: Some scanout formats become invalid when we run out of fifo space, some can only be used on specific planes and ofc this all depends upon whether gl compositing or hw planes are used to pick the right one. From the Wayland compositor point of view, things would get awfully hard if an existing wl_buffer (handle to a dmabuf object) could suddenly become completely unusable. That is why we try to make sure during the wl_buffer creation phase (when a client initially shares the dmabuf with the compositor) that the buffer is always usable for at least compositing (i.e. as a GL texture). If the buffer is also usable for direct scanout, that's a nice bonus. It's no problem to fall back to compositing if a buffer suddenly or temporarily turns out to be not scanout-able. We just need to guarantee that the compositing path always works. I don't think we can say to a client oops, go make a different kind of buffer, this no longer works. Do you think these expectations are realistic? Yeah gl should always work. The complications really are just about trying to get the optimum out of the plane hardware and the limited resources it has (fifo space, limits for rotation, compressed formats and whatever else). I expect that long-term wayland compositors need some form of hw abstraction (like hwc from android) to really get the most out of the hw - occasionally the limits are really crazy. That component would need to be able to pass hints to clients a la please use this hw specific layout for the next frame. But that's mostly about picking the right tiling layout or compressed format. So maybe something for a further revision (once we have the addfb2 extension merged into the kernel). Some more random comments below. Cheers, Daniel --- Makefile.am | 7 +- protocol/linux-dmabuf.xml | 224 ++ 2 files changed, 229 insertions(+), 2 deletions(-) create mode 100644 protocol/linux-dmabuf.xml diff --git a/Makefile.am b/Makefile.am index 494266d..0462fdd 100644 --- a/Makefile.am +++ b/Makefile.am @@ -91,7 +91,9 @@ nodist_weston_SOURCES = \ protocol/presentation_timing-protocol.c \ protocol/presentation_timing-server-protocol.h\ protocol/scaler-protocol.c\ - protocol/scaler-server-protocol.h + protocol/scaler-server-protocol.h \ + protocol/linux-dmabuf-protocol.c\ + protocol/linux-dmabuf-server-protocol.h BUILT_SOURCES += $(nodist_weston_SOURCES) @@ -1101,7 +1103,8 @@ EXTRA_DIST +=\ protocol/presentation_timing.xml \ protocol/scaler.xml \
RE: [weston1.5]Question about HardKey input monitor with wayland/weston
Hi Pekka Thank you very much for your reply. If you're interested in that, you can dig the wayland-devel mailing list archives, or if you can't find it, someone else probably can. This discussion was about any normal app that just wants to register for a global hotkey. I have searched for the related topic,but i did not find it. In all cases, the main idea is to prevent random clients from eavesdropping input, while still letting the right client(s) get them. This is always some new protocol extension that is unrelated to wl_keyboard, wl_pointer, etc.Right now,my solution is to extend wl_keyboard protocol,because the work volume is little. Software architecture is HMI--QT/EFL(wayland/client)--westion(wl_keyboard/extention key)--evdev. But i have another question. In my uses case,i will composite QT-applicaiton and EFL-applicaion into one image,both of them want to get hardkey input event but only one application can get the input event who get the foucs. When QT /EFL application want to get hardkey input event,it have to get the windows focus. How do i switch the focus/active for specific QT or EFL application by software design? Could you give some advice? Best regards, Andy Date: Fri, 2 Jan 2015 14:13:58 +0200 From: ppaala...@gmail.com To: williamyan...@hotmail.com CC: wayland-devel@lists.freedesktop.org Subject: Re: [weston1.5]Question about HardKey input monitor with wayland/weston On Wed, 24 Dec 2014 09:32:42 + Yang Andy williamyan...@hotmail.com wrote: Hi everyone I have a question about HardKey input monitor with wayland/weston. HardKey input monitor does not seem to be a program or a piece of hardware that Google knows about. Any pointers to what it is? [Use Case] When user press specific HardKey on panel,IVI system launch referred application. Ok. So application have to monitor HardKey press. [Question] Draft software archiecture design as below: Application(client)--Weston(v1.5)--Kernel Input Subsystem--HardKey Question1:Is Draft software archiecture right? Yes, at least if HardKey is hardware. Either Weston (the compositor) itself handles the input event, or you need protocol to relay it to a client if you want a client to handle it and launch your new app. Question2:Is is necessary to modify weston in order to monitor HardKey press? Yes, or you can write a Weston plugin to do that. Question3:How to design application(protocol) to communicate with weston(input)? That's the hard question. We have had some discussions how a desktop global hotkey protocol should look like to both work nicely and be secure (prevent spying input). If you're interested in that, you can dig the wayland-devel mailing list archives, or if you can't find it, someone else probably can. This discussion was about any normal app that just wants to register for a global hotkey. If you don't need this capability for normal apps, but it would be enough for your shell helper program to handle it, you can simply invent whatever protocol you need - just make sure no normal client can bind the interface. An example in Weston for desktop is the protocol/desktop-shell.xml extension, which is implemented in desktop-shell/shell.c and used from clients/desktop-shell.c. If your goal with the input event is to launch a new app, this is probably the best option. However, your context is IVI which is totally not a desktop. I suppose the controller could define specific ivi-ids somehow with which a client could bind to the extension interface. This would be similar to the shell helper program design, except the mechanism to authorize a client is different. In all cases, the main idea is to prevent random clients from eavesdropping input, while still letting the right client(s) get them. This is always some new protocol extension that is unrelated to wl_keyboard, wl_pointer, etc. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 6/6] test: add touchpad hover finger test
Hi,
On 16-12-14 04:14, Peter Hutterer wrote:
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
Looks good:
Reviewed-by: Hans de Goede hdego...@redhat.com
Regards,
Hans
---
test/touchpad.c | 322 +++-
1 file changed, 321 insertions(+), 1 deletion(-)
diff --git a/test/touchpad.c b/test/touchpad.c
index 934674c..9890566 100644
--- a/test/touchpad.c
+++ b/test/touchpad.c
@@ -2060,9 +2060,321 @@ START_TEST(touchpad_left_handed_clickpad_delayed)
}
END_TEST
+static void
+hover_continue(struct litest_device *dev, unsigned int slot,
+ int x, int y)
+{
+ litest_event(dev, EV_ABS, ABS_MT_SLOT, slot);
+ litest_event(dev, EV_ABS, ABS_MT_POSITION_X, x);
+ litest_event(dev, EV_ABS, ABS_MT_POSITION_Y, y);
+ litest_event(dev, EV_ABS, ABS_X, x);
+ litest_event(dev, EV_ABS, ABS_Y, y);
+ litest_event(dev, EV_ABS, ABS_PRESSURE, 10);
+ litest_event(dev, EV_ABS, ABS_TOOL_WIDTH, 6);
+ /* WARNING: no SYN_REPORT! */
+}
+
+static void
+hover_start(struct litest_device *dev, unsigned int slot,
+ int x, int y)
+{
+ static unsigned int tracking_id;
+
+ litest_event(dev, EV_ABS, ABS_MT_SLOT, slot);
+ litest_event(dev, EV_ABS, ABS_MT_TRACKING_ID, ++tracking_id);
+ hover_continue(dev, slot, x, y);
+ /* WARNING: no SYN_REPORT! */
+}
+
+START_TEST(touchpad_hover_noevent)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput *li = dev-libinput;
+ int i;
+ int x = 2400,
+ y = 2400;
+
+ litest_drain_events(li);
+
+ hover_start(dev, 0, x, y);
+ litest_event(dev, EV_KEY, BTN_TOOL_FINGER, 1);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+
+ for (i = 0; i 10; i++) {
+ x += 200;
+ y -= 200;
+ litest_event(dev, EV_ABS, ABS_MT_POSITION_X, x);
+ litest_event(dev, EV_ABS, ABS_MT_POSITION_Y, y);
+ litest_event(dev, EV_ABS, ABS_X, x);
+ litest_event(dev, EV_ABS, ABS_Y, y);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+ }
+
+ litest_event(dev, EV_KEY, BTN_TOOL_FINGER, 0);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+
+ litest_assert_empty_queue(li);
+}
+END_TEST
+
+START_TEST(touchpad_hover_down)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput *li = dev-libinput;
+ struct libinput_event *event;
+ int i;
+ int x = 2400,
+ y = 2400;
+
+ litest_drain_events(li);
+
+ hover_start(dev, 0, x, y);
+ litest_event(dev, EV_KEY, BTN_TOOL_FINGER, 1);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+
+ for (i = 0; i 10; i++) {
+ x += 200;
+ y -= 200;
+ litest_event(dev, EV_ABS, ABS_MT_POSITION_X, x);
+ litest_event(dev, EV_ABS, ABS_MT_POSITION_Y, y);
+ litest_event(dev, EV_ABS, ABS_X, x);
+ litest_event(dev, EV_ABS, ABS_Y, y);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+ }
+
+ litest_assert_empty_queue(li);
+
+ litest_event(dev, EV_ABS, ABS_X, x + 100);
+ litest_event(dev, EV_ABS, ABS_Y, y + 100);
+ litest_event(dev, EV_KEY, BTN_TOUCH, 1);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+ libinput_dispatch(li);
+ for (i = 0; i 10; i++) {
+ x -= 200;
+ y += 200;
+ litest_event(dev, EV_ABS, ABS_MT_POSITION_X, x);
+ litest_event(dev, EV_ABS, ABS_MT_POSITION_Y, y);
+ litest_event(dev, EV_ABS, ABS_X, x);
+ litest_event(dev, EV_ABS, ABS_Y, y);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+ }
+
+ libinput_dispatch(li);
+
+ ck_assert_int_ne(libinput_next_event_type(li),
+LIBINPUT_EVENT_NONE);
+ while ((event = libinput_get_event(li)) != NULL) {
+ ck_assert_int_eq(libinput_event_get_type(event),
+LIBINPUT_EVENT_POINTER_MOTION);
+ libinput_event_destroy(event);
+ libinput_dispatch(li);
+ }
+
+ /* go back to hover */
+ hover_continue(dev, 0, x, y);
+ litest_event(dev, EV_KEY, BTN_TOUCH, 0);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+
+ for (i = 0; i 10; i++) {
+ x += 200;
+ y -= 200;
+ litest_event(dev, EV_ABS, ABS_MT_POSITION_X, x);
+ litest_event(dev, EV_ABS, ABS_MT_POSITION_Y, y);
+ litest_event(dev, EV_ABS, ABS_X, x);
+ litest_event(dev, EV_ABS, ABS_Y, y);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+ }
+
+ litest_event(dev, EV_KEY, BTN_TOOL_FINGER, 0);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+
+ litest_assert_empty_queue(li);
+}
+END_TEST
+
+START_TEST(touchpad_hover_down_hover_down)
Re: [PATCH libinput 4/6] test: move semi-mt special tracking into the shared litest.c
Hi,
On 16-12-14 04:14, Peter Hutterer wrote:
An upcoming synaptics semi-mt device needs the same code.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
Looks good:
Reviewed-by: Hans de Goede hdego...@redhat.com
Regards,
Hans
---
test/litest-alps-semi-mt.c | 146 +++--
test/litest.c | 141 +++
test/litest.h | 27 +
3 files changed, 177 insertions(+), 137 deletions(-)
diff --git a/test/litest-alps-semi-mt.c b/test/litest-alps-semi-mt.c
index 12b93b8..4d95ac9 100644
--- a/test/litest-alps-semi-mt.c
+++ b/test/litest-alps-semi-mt.c
@@ -31,21 +31,6 @@
#include litest.h
#include litest-int.h
-static int tracking_id;
-
-/* this is a semi-mt device, so we keep track of the touches that the tests
- * send and modify them so that the first touch is always slot 0 and sends
- * the top-left of the bounding box, the second is always slot 1 and sends
- * the bottom-right of the bounding box.
- * Lifting any of two fingers terminates slot 1
- */
-struct alps {
- /* The actual touches requested by the test for the two slots
-* in the 0..100 range used by litest */
- struct {
- double x, y;
- } touches[2];
-};
static void alps_create(struct litest_device *d);
@@ -57,140 +42,27 @@ litest_alps_setup(void)
}
static void
-send_abs_xy(struct litest_device *d, double x, double y)
-{
- struct input_event e;
- int val;
-
- e.type = EV_ABS;
- e.code = ABS_X;
- e.value = LITEST_AUTO_ASSIGN;
- val = litest_auto_assign_value(d, e, 0, x, y);
- litest_event(d, EV_ABS, ABS_X, val);
-
- e.code = ABS_Y;
- val = litest_auto_assign_value(d, e, 0, x, y);
- litest_event(d, EV_ABS, ABS_Y, val);
-}
-
-static void
-send_abs_mt_xy(struct litest_device *d, double x, double y)
-{
- struct input_event e;
- int val;
-
- e.type = EV_ABS;
- e.code = ABS_MT_POSITION_X;
- e.value = LITEST_AUTO_ASSIGN;
- val = litest_auto_assign_value(d, e, 0, x, y);
- litest_event(d, EV_ABS, ABS_MT_POSITION_X, val);
-
- e.code = ABS_MT_POSITION_Y;
- e.value = LITEST_AUTO_ASSIGN;
- val = litest_auto_assign_value(d, e, 0, x, y);
- litest_event(d, EV_ABS, ABS_MT_POSITION_Y, val);
-}
-
-static void
alps_touch_down(struct litest_device *d, unsigned int slot, double x, double
y)
{
- struct alps *alps = d-private;
- double t, l, r = 0, b = 0; /* top, left, right, bottom */
+ struct litest_semi_mt *semi_mt = d-private;
- if (d-ntouches_down 2 || slot 1)
- return;
-
- if (d-ntouches_down == 1) {
- l = x;
- t = y;
- } else {
- int other = (slot + 1) % 2;
- l = min(x, alps-touches[other].x);
- t = min(y, alps-touches[other].y);
- r = max(x, alps-touches[other].x);
- b = max(y, alps-touches[other].y);
- }
-
- send_abs_xy(d, l, t);
-
- litest_event(d, EV_ABS, ABS_MT_SLOT, 0);
-
- if (d-ntouches_down == 1)
- litest_event(d, EV_ABS, ABS_MT_TRACKING_ID, ++tracking_id);
-
- send_abs_mt_xy(d, l, t);
-
- if (d-ntouches_down == 2) {
- litest_event(d, EV_ABS, ABS_MT_SLOT, 1);
- litest_event(d, EV_ABS, ABS_MT_TRACKING_ID, ++tracking_id);
-
- send_abs_mt_xy(d, r, b);
- }
-
- litest_event(d, EV_SYN, SYN_REPORT, 0);
-
- alps-touches[slot].x = x;
- alps-touches[slot].y = y;
+ litest_semi_mt_touch_down(d, semi_mt, slot, x, y);
}
static void
alps_touch_move(struct litest_device *d, unsigned int slot, double x, double
y)
{
- struct alps *alps = d-private;
- double t, l, r = 0, b = 0; /* top, left, right, bottom */
+ struct litest_semi_mt *semi_mt = d-private;
- if (d-ntouches_down 2 || slot 1)
- return;
-
- if (d-ntouches_down == 1) {
- l = x;
- t = y;
- } else {
- int other = (slot + 1) % 2;
- l = min(x, alps-touches[other].x);
- t = min(y, alps-touches[other].y);
- r = max(x, alps-touches[other].x);
- b = max(y, alps-touches[other].y);
- }
-
- send_abs_xy(d, l, t);
-
- litest_event(d, EV_ABS, ABS_MT_SLOT, 0);
- send_abs_mt_xy(d, l, t);
-
- if (d-ntouches_down == 2) {
- litest_event(d, EV_ABS, ABS_MT_SLOT, 1);
- send_abs_mt_xy(d, r, b);
- }
-
- litest_event(d, EV_SYN, SYN_REPORT, 0);
-
- alps-touches[slot].x = x;
- alps-touches[slot].y = y;
+ litest_semi_mt_touch_move(d, semi_mt, slot, x, y);
}
static void
alps_touch_up(struct litest_device *d, unsigned int slot)
{
- struct alps *alps = d-private;
+ struct litest_semi_mt *semi_mt = d-private;
-
Re: [PATCH libinput 5/6] test: add a semi-mt + hover synaptics touchpad
Hi,
On 16-12-14 04:14, Peter Hutterer wrote:
This device sends touch information before BTN_TOUCH
https://bugs.freedesktop.org/show_bug.cgi?id=87197
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
Looks good:
Reviewed-by: Hans de Goede hdego...@redhat.com
Regards,
Hans
---
test/Makefile.am | 1 +
test/litest-synaptics-hover.c | 132 ++
test/litest.c | 2 +
test/litest.h | 1 +
4 files changed, 136 insertions(+)
create mode 100644 test/litest-synaptics-hover.c
diff --git a/test/Makefile.am b/test/Makefile.am
index 2c36e3f..1b7ba87 100644
--- a/test/Makefile.am
+++ b/test/Makefile.am
@@ -21,6 +21,7 @@ liblitest_la_SOURCES = \
litest-ms-surface-cover.c \
litest-qemu-usb-tablet.c \
litest-synaptics.c \
+ litest-synaptics-hover.c \
litest-synaptics-st.c \
litest-synaptics-t440.c \
litest-trackpoint.c \
diff --git a/test/litest-synaptics-hover.c b/test/litest-synaptics-hover.c
new file mode 100644
index 000..7ba56bc
--- /dev/null
+++ b/test/litest-synaptics-hover.c
@@ -0,0 +1,132 @@
+/*
+ * Copyright © 2014 Red Hat, Inc.
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission. The copyright holders make no representations
+ * about the suitability of this software for any purpose. It is provided as
+ * is without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
+ * OF THIS SOFTWARE.
+ */
+
+#if HAVE_CONFIG_H
+#include config.h
+#endif
+
+#include assert.h
+
+#include libinput-util.h
+
+#include litest.h
+#include litest-int.h
+
+static void
+synaptics_hover_create(struct litest_device *d);
+
+static void
+litest_synaptics_hover_setup(void)
+{
+ struct litest_device *d =
litest_create_device(LITEST_SYNAPTICS_HOVER_SEMI_MT);
+ litest_set_current_device(d);
+}
+
+static void
+synaptics_hover_touch_down(struct litest_device *d, unsigned int slot, double
x, double y)
+{
+ struct litest_semi_mt *semi_mt = d-private;
+
+ litest_semi_mt_touch_down(d, semi_mt, slot, x, y);
+}
+
+static void
+synaptics_hover_touch_move(struct litest_device *d, unsigned int slot, double
x, double y)
+{
+ struct litest_semi_mt *semi_mt = d-private;
+
+ litest_semi_mt_touch_move(d, semi_mt, slot, x, y);
+}
+
+static void
+synaptics_hover_touch_up(struct litest_device *d, unsigned int slot)
+{
+ struct litest_semi_mt *semi_mt = d-private;
+
+ litest_semi_mt_touch_up(d, semi_mt, slot);
+}
+
+static struct litest_device_interface interface = {
+ .touch_down = synaptics_hover_touch_down,
+ .touch_move = synaptics_hover_touch_move,
+ .touch_up = synaptics_hover_touch_up,
+};
+
+static struct input_id input_id = {
+ .bustype = 0x11,
+ .vendor = 0x2,
+ .product = 0x7,
+};
+
+static int events[] = {
+ EV_KEY, BTN_LEFT,
+ EV_KEY, BTN_RIGHT,
+ EV_KEY, BTN_TOOL_FINGER,
+ EV_KEY, BTN_TOUCH,
+ EV_KEY, BTN_TOOL_DOUBLETAP,
+ EV_KEY, BTN_TOOL_TRIPLETAP,
+ INPUT_PROP_MAX, INPUT_PROP_POINTER,
+ INPUT_PROP_MAX, INPUT_PROP_SEMI_MT,
+ -1, -1,
+};
+
+static struct input_absinfo absinfo[] = {
+ { ABS_X, 1472, 5472, 0, 0, 60 },
+ { ABS_Y, 1408, 4498, 0, 0, 85 },
+ { ABS_PRESSURE, 0, 255, 0, 0, 0 },
+ { ABS_TOOL_WIDTH, 0, 15, 0, 0, 0 },
+ { ABS_MT_SLOT, 0, 1, 0, 0, 0 },
+ { ABS_MT_POSITION_X, 1472, 5472, 0, 0, 60 },
+ { ABS_MT_POSITION_Y, 1408, 4498, 0, 0, 85 },
+ { ABS_MT_TRACKING_ID, 0, 65535, 0, 0, 0 },
+ { .value = -1 }
+};
+
+struct litest_test_device litest_synaptics_hover_device = {
+ .type = LITEST_SYNAPTICS_HOVER_SEMI_MT,
+ .features = LITEST_TOUCHPAD | LITEST_SEMI_MT | LITEST_BUTTON,
+ .shortname = synaptics hover,
+ .setup = litest_synaptics_hover_setup,
+ .interface = interface,
+ .create = synaptics_hover_create,
+
+ .name = SynPS/2 Synaptics TouchPad,
+ .id = input_id,
+ .events = events,
+ .absinfo = absinfo,
+};
+
+static void
Re: [PATCH libinput 2/2] Add libinput_event_pointer_has_axis to scroll events
Hi,
On 05-01-15 06:20, Peter Hutterer wrote:
Right now we only have two (scroll) axes and we could easily just check both
for non-zero values. If we want to allow further axes in the future, we need
a check whether an axis is set in an event.
We also need the mask to notify of a scroll stop event, which could otherwise
be confused as a vertical-only or horizontal-only event.
Note: intentionally done as a separate patch to the previous one to aid review
and debugging.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
Hmm, I see this negates a lot of my review on patch 1/2. This means that the
direction / axis variables can stay in evdev-mt-touchpad-edge-scroll.c, but the
not used axis should still be cleared and libinput_event_pointer_get_axis_value
should check event-axes, calling log_bug_client if an unset axis is requested.
Also see comments inline.
---
src/evdev-mt-touchpad-edge-scroll.c | 3 +++
src/evdev.c | 17 +++--
src/libinput-private.h | 1 +
src/libinput-util.h | 1 +
src/libinput.c | 16
src/libinput.h | 17 +
6 files changed, 53 insertions(+), 2 deletions(-)
diff --git a/src/evdev-mt-touchpad-edge-scroll.c
b/src/evdev-mt-touchpad-edge-scroll.c
index b82c966..8dfa97e 100644
--- a/src/evdev-mt-touchpad-edge-scroll.c
+++ b/src/evdev-mt-touchpad-edge-scroll.c
@@ -325,6 +325,7 @@ tp_edge_scroll_post_events(struct tp_dispatch *tp, uint64_t
time)
if (t-scroll.direction != -1) {
/* Send stop scroll event */
pointer_notify_axis(device, time,
+ t-scroll.direction,
t-scroll.direction contains the previous axis variable, so this should use
AS_MASK.
LIBINPUT_POINTER_AXIS_SOURCE_FINGER,
0.0, 0.0);
t-scroll.direction = -1;
@@ -352,6 +353,7 @@ tp_edge_scroll_post_events(struct tp_dispatch *tp, uint64_t
time)
continue;
pointer_notify_axis(device, time,
+ AS_MASK(axis),
LIBINPUT_POINTER_AXIS_SOURCE_FINGER,
dx, dy);
t-scroll.direction = axis;
@@ -371,6 +373,7 @@ tp_edge_scroll_stop_events(struct tp_dispatch *tp, uint64_t
time)
tp_for_each_touch(tp, t) {
if (t-scroll.direction != -1) {
pointer_notify_axis(device, time,
+ t-scroll.direction,
LIBINPUT_POINTER_AXIS_SOURCE_FINGER,
0.0, 0.0);
t-scroll.direction = -1;
idem.
Regards,
Hans
diff --git a/src/evdev.c b/src/evdev.c
index 5d22af2..7597afc 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -539,6 +539,7 @@ evdev_process_absolute_motion(struct evdev_device *device,
static void
evdev_notify_axis(struct evdev_device *device,
uint64_t time,
+ uint32_t axes,
enum libinput_pointer_axis_source source,
double x, double y)
{
@@ -549,6 +550,7 @@ evdev_notify_axis(struct evdev_device *device,
pointer_notify_axis(device-base,
time,
+ axes,
source,
x, y);
}
@@ -575,6 +577,7 @@ evdev_process_relative(struct evdev_device *device,
evdev_notify_axis(
device,
time,
+ AS_MASK(LIBINPUT_POINTER_AXIS_SCROLL_VERTICAL),
LIBINPUT_POINTER_AXIS_SOURCE_WHEEL,
0,
-1 * e-value * DEFAULT_AXIS_STEP_DISTANCE);
@@ -584,6 +587,7 @@ evdev_process_relative(struct evdev_device *device,
evdev_notify_axis(
device,
time,
+ AS_MASK(LIBINPUT_POINTER_AXIS_SCROLL_HORIZONTAL),
LIBINPUT_POINTER_AXIS_SOURCE_WHEEL,
e-value * DEFAULT_AXIS_STEP_DISTANCE,
0);
@@ -1792,6 +1796,7 @@ evdev_post_scroll(struct evdev_device *device,
double dy)
{
double trigger_horiz, trigger_vert;
+ uint32_t axes;
if (!evdev_is_scrolling(device,
LIBINPUT_POINTER_AXIS_SCROLL_VERTICAL))
@@ -1829,19 +1834,26 @@ evdev_post_scroll(struct evdev_device *device,
LIBINPUT_POINTER_AXIS_SCROLL_HORIZONTAL);
}
+ axes = device-scroll.direction;
+
/* We use the trigger to enable, but the
[PATCH libinput 2/2] Rename functions for left handed device configurations
Some devices require more then just flipping around the buttons, such as
tablets.
---
src/evdev-mt-touchpad.c | 4 ++--
src/evdev.c | 34 +++---
src/evdev.h | 12 +--
src/libinput.c | 14 ++---
src/libinput.h | 55 -
src/libinput.sym| 8 +++
test/pointer.c | 12 +--
test/touch.c| 8 +++
test/touchpad.c | 18
tools/event-debug.c | 2 +-
tools/shared.c | 2 +-
11 files changed, 84 insertions(+), 85 deletions(-)
diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index 7e8306d..34b107e 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -1310,7 +1310,7 @@ tp_change_to_left_handed(struct evdev_device *device)
{
struct tp_dispatch *tp = (struct tp_dispatch *)device-dispatch;
- if (device-buttons.want_left_handed == device-buttons.left_handed)
+ if (device-left_handed.want_enabled == device-left_handed.enabled)
return;
if (tp-buttons.state 0x3) /* BTN_LEFT|BTN_RIGHT */
@@ -1319,7 +1319,7 @@ tp_change_to_left_handed(struct evdev_device *device)
/* tapping and clickfinger aren't affected by left-handed config,
* so checking physical buttons is enough */
- device-buttons.left_handed = device-buttons.want_left_handed;
+ device-left_handed.enabled = device-left_handed.want_enabled;
}
struct model_lookup_t {
diff --git a/src/evdev.c b/src/evdev.c
index 1718491..1fc1d6b 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -119,8 +119,8 @@ evdev_pointer_notify_button(struct evdev_device *device,
pointer_notify_button(device-base, time, button, state);
if (state == LIBINPUT_BUTTON_STATE_RELEASED
- device-buttons.change_to_left_handed)
- device-buttons.change_to_left_handed(device);
+ device-left_handed.change_to_enabled)
+ device-left_handed.change_to_enabled(device);
if (state == LIBINPUT_BUTTON_STATE_RELEASED
device-scroll.change_scroll_method)
@@ -810,13 +810,13 @@ evdev_left_handed_has(struct libinput_device *device)
static void
evdev_change_to_left_handed(struct evdev_device *device)
{
- if (device-buttons.want_left_handed == device-buttons.left_handed)
+ if (device-left_handed.want_enabled == device-left_handed.enabled)
return;
if (evdev_any_button_down(device))
return;
- device-buttons.left_handed = device-buttons.want_left_handed;
+ device-left_handed.enabled = device-left_handed.want_enabled;
}
static enum libinput_config_status
@@ -824,9 +824,9 @@ evdev_left_handed_set(struct libinput_device *device, int
left_handed)
{
struct evdev_device *evdev_device = (struct evdev_device *)device;
- evdev_device-buttons.want_left_handed = left_handed ? true : false;
+ evdev_device-left_handed.want_enabled = left_handed ? true : false;
- evdev_device-buttons.change_to_left_handed(evdev_device);
+ evdev_device-left_handed.change_to_enabled(evdev_device);
return LIBINPUT_CONFIG_STATUS_SUCCESS;
}
@@ -838,7 +838,7 @@ evdev_left_handed_get(struct libinput_device *device)
/* return the wanted configuration, even if it hasn't taken
* effect yet! */
- return evdev_device-buttons.want_left_handed;
+ return evdev_device-left_handed.want_enabled;
}
static int
@@ -851,14 +851,14 @@ int
evdev_init_left_handed(struct evdev_device *device,
void (*change_to_left_handed)(struct evdev_device *))
{
- device-buttons.config_left_handed.has = evdev_left_handed_has;
- device-buttons.config_left_handed.set = evdev_left_handed_set;
- device-buttons.config_left_handed.get = evdev_left_handed_get;
- device-buttons.config_left_handed.get_default =
evdev_left_handed_get_default;
- device-base.config.left_handed = device-buttons.config_left_handed;
- device-buttons.left_handed = false;
- device-buttons.want_left_handed = false;
- device-buttons.change_to_left_handed = change_to_left_handed;
+ device-left_handed.config.has = evdev_left_handed_has;
+ device-left_handed.config.set = evdev_left_handed_set;
+ device-left_handed.config.get = evdev_left_handed_get;
+ device-left_handed.config.get_default = evdev_left_handed_get_default;
+ device-base.config.left_handed = device-left_handed.config;
+ device-left_handed.enabled = false;
+ device-left_handed.want_enabled = false;
+ device-left_handed.change_to_enabled = change_to_left_handed;
return 0;
}
@@ -1052,7 +1052,7 @@ fallback_dispatch_create(struct libinput_device *device)
dispatch-interface = fallback_interface;
- if
[PATCH libinput 1/2] libinput.h: Fix some line wrapping in documentation
--- src/libinput.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/libinput.h b/src/libinput.h index 56b77c2..7719b8c 100644 --- a/src/libinput.h +++ b/src/libinput.h @@ -2141,8 +2141,8 @@ libinput_device_config_buttons_get_left_handed(struct libinput_device *device); * Get the default left-handed configuration of the device. * * @param device The device to configure - * @return Zero if the device is in right-handed mode by default, or non-zero if the - * device is in left-handed mode by default + * @return Zero if the device is in right-handed mode by default, or non-zero + * if the device is in left-handed mode by default * * @see libinput_device_config_buttons_has_left_handed * @see libinput_device_config_buttons_set_left_handed -- 2.0.5 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 0/2] Patches to prepare for left-handed tablet mode
Hi! It's nice to finally have some patches back on this mailing list. Anyway, the first patch is just a fix for some incorrect line-wrapping I noticed, the second patch is to prepare for adding a left-handed mode for tablets. Since left-handed mode on tablets involves reversing the coordinates as opposed to reversing the buttons, I've renamed all of the left handed device configuration functions in libinput more appropriately. After these two patches, me and/or Peter should be bringing the tablet-support branch up to date with master, and I'll send off the patch to add a lefty mode for tablets. Cheers, Stephen Chandler Paul Stephen Chandler Paul (2): libinput.h: Fix some line wrapping in documentation Rename functions for left handed device configurations src/evdev-mt-touchpad.c | 4 ++-- src/evdev.c | 34 ++-- src/evdev.h | 12 +- src/libinput.c | 14 ++-- src/libinput.h | 59 - src/libinput.sym| 8 +++ test/pointer.c | 12 +- test/touch.c| 8 +++ test/touchpad.c | 18 +++ tools/event-debug.c | 2 +- tools/shared.c | 2 +- 11 files changed, 86 insertions(+), 87 deletions(-) -- 2.0.5 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 2/6] touchpad: use __builtin_ffs instead of a manual count
On Mon, Jan 05, 2015 at 04:29:48PM -0800, Thiago Macieira wrote: On Monday 05 January 2015 12:00:24 Hans de Goede wrote: + return __builtin_ffs(tp-fake_touches 1); Why the builtin instead of ffs from strings.h? simple answer: was the first one that google came up with. does it matter much though? it's supported by gcc and clang. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 2/6] touchpad: use __builtin_ffs instead of a manual count
On Tue, Jan 06, 2015 at 01:00:08PM +1000, Peter Hutterer wrote: On Mon, Jan 05, 2015 at 04:29:48PM -0800, Thiago Macieira wrote: On Monday 05 January 2015 12:00:24 Hans de Goede wrote: + return __builtin_ffs(tp-fake_touches 1); Why the builtin instead of ffs from strings.h? simple answer: was the first one that google came up with. does it matter much though? it's supported by gcc and clang. Consistency and I suppose aesthetics. We already use ffs elsewhere in libinput. Jonas Cheers, Peter ___ 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 libinput 2/6] touchpad: use __builtin_ffs instead of a manual count
On Tue, Jan 06, 2015 at 01:39:24PM +0800, Jonas Ådahl wrote: On Tue, Jan 06, 2015 at 01:00:08PM +1000, Peter Hutterer wrote: On Mon, Jan 05, 2015 at 04:29:48PM -0800, Thiago Macieira wrote: On Monday 05 January 2015 12:00:24 Hans de Goede wrote: + return __builtin_ffs(tp-fake_touches 1); Why the builtin instead of ffs from strings.h? simple answer: was the first one that google came up with. does it matter much though? it's supported by gcc and clang. Consistency and I suppose aesthetics. We already use ffs elsewhere in libinput. fair enough, fixed locally. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: Where should project Weston go?
-Original Message- From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On Behalf Of Pekka Paalanen Sent: Wednesday, December 10, 2014 8:32 AM To: wayland-devel@lists.freedesktop.org Cc: Samuele Disegna; Bryce Harrington; Jason Ekstrand Subject: Re: Where should project Weston go? The other option is to get weston's head and heart aligned, and strengthen our focus on being just a test bed for improving the Wayland protocol. Give our community's primary attention not to Weston's users but Wayland's users - Enlightenment, GNOME, KDE, and other DEs. Survey and study their requirements and look for things they need across the board. And make it easier for them to bring us their problems/ideas/needs. Make it convenient for people to do prototyping and experimentation in Weston first, and then port to production compositors, rather than vice versa. Instead of unit testing weston, improve the validation testing of wayland, such that the same testsuite would run against the weston compositor, enlightenment compositor, et al to verify that the DEs have properly implemented the protocol requirements. Instead of delivering a monolithic Weston package, turn the best bits of it into specialized libraries that DEs can use too (if they wish). Define a clear process for 3rd parties to contribute extensions, libraries, and driver support changes. Finally, work to change public perception to stop the expectations on producing Weston-the-desktop, by vocally championing DEs that are already giving solid Wayland-based desktops. Yes. I'm guilty of pretty much ignoring Wayland-fits. Maybe we should look in that direction for testing? Yep, Wayland-fits was designed with the intention of testing multiple Wayland compositor implementations. It currently only supports the Weston compositor atm. In addition, there are several generic (or core, if you will) protocol tests and quite a few EFL/Elementary-based tests. Adding support for additional Wayland compositors should be relatively easy, though. I have not had any time lately to maintain or expand the testsuite, nor will I have much time with it in the near future. So any help would be GREATLY appreciated! Regards, U. Artie Eoff Intel Open Source Technology Center Thanks, pq ___ 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
