[PATCH libinput 1/1] touchpad: reduce palm detection threshold to 70mm
https://bugzilla.redhat.com/show_bug.cgi?id=1209753 lists a touchpad 76mm wide that suffers from palm touches Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- 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) -- 2.3.4 ___ 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 peter.hutte...@who-t.net
Reviewed-by: Hans de Goede hdego...@redhat.com
---
Changes to v1:
- use extra variables to make the code clearer, no functional changes
otherwise
Looks good:
Reviewed-by: Hans de Goede hdego...@redhat.com
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 LR.
+* If we have LR 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/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 peter.hutte...@who-t.net Looks good: Reviewed-by: Hans de Goede hdego...@redhat.com 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: [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: snip 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. +/event + +event name=axis_discrete since=5 + description summary=axis click event +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 follows the finger (this is a lot more obvious when natural scrolling is enabled). But a click is a click and maps to say 3 lines, or a page, or whatever in the
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 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
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 peter.hutte...@who-t.net
Looks good:
Reviewed-by: Hans de Goede hdego...@redhat.com
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
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) GmbHCo 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 jad...@gmail.com wrote: snip 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 that mime types should be considered a non-varying static set. They are advertised
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 mario.kleiner...@gmail.com
---
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: [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 mario.kleiner...@gmail.com
---
Looks sensible to me
Reviewed-By: Derek Foreman der...@osg.samsung.com
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(shell);
-
main_surface = weston_surface_get_main_surface(es);
+ shsurf =
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 mario.kleiner...@gmail.com
---
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: EFL/Wayland and xdg-shell
Hi,
On 15 April 2015 at 23:51, Carsten Haitzler ras...@rasterman.com wrote:
On Wed, 15 Apr 2015 20:29:32 +0100 Daniel Stone dan...@fooishbar.org said:
On 15 April 2015 at 02:39, Carsten Haitzler ras...@rasterman.com 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 opposed ro mouse driven...). maybe
app
is written
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 der...@osg.samsung.com 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 der...@osg.samsung.com 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 der...@osg.samsung.com --- 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? ;) 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
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
benjamin.tissoi...@gmail.com 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 benjamin.tissoi...@gmail.com
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
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.
ddThe angle in degrees for each click on a mouse wheel. See
libinput_pointer_get_axis_source() for details.
/dd
+dtLIBINPUT_MODEL_LENOVO_X230/dt
+ddbDo not use for anything except a Lenovo X230 series/b (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.
+/dd
/dl
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++;
+ }
+
Re: [PATCH weston] input: Don't use uninitialized variables in default_grab_pointer_focus()
Hi, On 16 April 2015 at 21:02, Derek Foreman der...@osg.samsung.com 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
[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 der...@osg.samsung.com
---
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: 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 x414...@linux.com 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 x414...@linux.com 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
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 benjamin.tissoi...@gmail.com
---
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: [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 benjamin.tissoi...@gmail.com
---
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 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 benjamin.tissoi...@gmail.com
one minor change: rename it to 90-... so that local overrides are easier
Reviewed-by: Peter Hutterer peter.hutte...@who-t.net
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: 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 x414...@linux.com 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: [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 hdego...@redhat.com 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 peter.hutte...@who-t.net --- 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
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: EFL/Wayland and xdg-shell
On Thu, 16 Apr 2015 15:32:31 +0100 Daniel Stone dan...@fooishbar.org said:
Hi,
On 15 April 2015 at 23:51, Carsten Haitzler ras...@rasterman.com wrote:
On Wed, 15 Apr 2015 20:29:32 +0100 Daniel Stone dan...@fooishbar.org said:
On 15 April 2015 at 02:39, Carsten Haitzler ras...@rasterman.com 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 would go based on the current state of the world
screen-wise and app hints.
Right.
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
[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 benjamin.tissoi...@gmail.com
---
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
[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 benjamin.tissoi...@gmail.com
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
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.
ddThe angle in degrees for each click on a mouse wheel. See
libinput_pointer_get_axis_source() for details.
/dd
+dtLIBINPUT_MODEL_LENOVO_X230/dt
+ddbDo not use for anything except a Lenovo X230 series/b (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.
+/dd
/dl
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 @@
[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 benjamin.tissoi...@gmail.com
---
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 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
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 benjamin.tissoi...@gmail.com 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 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 benjamin.tissoi...@gmail.com
---
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
