Re: [PATCH libinput 3/3] Change the logging system to be per-context
On Wed, Jun 18, 2014 at 08:39:01AM +1000, Peter Hutterer wrote: On Tue, Jun 17, 2014 at 11:20:00PM +0200, Jonas Ådahl wrote: On Fri, Jun 13, 2014 at 12:48:33PM +1000, Peter Hutterer wrote: Rather than a single global logging function, make the logging dependent on the individual context. This way we won't stomp on each other's feet in the (admittedly unusual) case of having multiple libinput contexts. The log handler and the log priority is now a part of the libinput interface. We can drop the various setters and getters, the caller owns the struct anyway so we don't need functions to give it those values. The userdata argument to the log handler was dropped. The caller has a ref to the libinput context now, any userdata can be attached to that context instead. There is no need for a default log function anymore. Any serious caller should hook into it anyway, those that don't care can just use NULL. There is no default log priority anymore, a caller must set the desired priority in the interface. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- There's a side-effect to this that I'm not sure is intended. We don't copy the interface into libinput, we merely keep a reference. The caller is already able to change open_restricted/close_restricted at runtime, though we can't do this ourselves (it's const). Given that, I figured we can leave the log handler and priority up to the caller as well then, switching at runtime. That's the main reason for dropping the set/get priority calls. If that side effect wasn't intended, then we'll have rework a few things. Jonas? Not sure I like this change. The interface (function pointer struct) is intended to really be an constant interface where the caller never changes the function used. Of course it would be possible, given how its implemnted, but it was not intended. so should we copy the struct then? or trust callers to not do anything untoward? The purpose of the struct was to provide an interface with the functionality that libinput would require to have to function without having to be root, and it doesn't feel logging function fits this purpose. It was already a set/get, wouldn't it fit better to just make them per context, while keeping the interface struct minimal? yeah, fair enough. I arrived at this solution at a bit of a roundabout way since I wanted to make the current udev_create work without changes and then failed anyway. with the create_context function it's possible now to do the following: li = libinput_udev_create_context(); libinput_set_log_handler(li, ...); libinput_set_log_priority(li, ...); libinput_udev_set_set(li, seat); That's what you're proposing, right? Yes, something like that. We could also possibly do what I think we discussed a while ago and default to suspended, i.e. _create_for_seat(), _set_(), _enable(), but either way really. The problem with _set_seat() though I guess is that it makes it look like we can actually switch seat of a context, which I don't know if we should support. Jonas Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 3/3] Change the logging system to be per-context
On Wed, Jun 18, 2014 at 09:24:03AM +0200, Jonas Ådahl wrote: The purpose of the struct was to provide an interface with the functionality that libinput would require to have to function without having to be root, and it doesn't feel logging function fits this purpose. It was already a set/get, wouldn't it fit better to just make them per context, while keeping the interface struct minimal? yeah, fair enough. I arrived at this solution at a bit of a roundabout way since I wanted to make the current udev_create work without changes and then failed anyway. with the create_context function it's possible now to do the following: li = libinput_udev_create_context(); libinput_set_log_handler(li, ...); libinput_set_log_priority(li, ...); libinput_udev_set_set(li, seat); That's what you're proposing, right? Yes, something like that. We could also possibly do what I think we discussed a while ago and default to suspended, i.e. _create_for_seat(), _set_(), _enable(), but either way really. The problem with _set_seat() though I guess is that it makes it look like we can actually switch seat of a context, which I don't know if we should support. well, we could do it as add/remove like in the path backend, I just don't know if there's a use-case for that? for the current code I'll just add a check, right now it just overwrites it which is a bug. other name suggestions: assign_seat() or bind_seat() Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 2/2] evdev-mt-touchpad: tp_current_touch: Fix off by one error
Signed-off-by: Hans de Goede hdego...@redhat.com
---
src/evdev-mt-touchpad.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index 0294eb2..92e0651 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -139,7 +139,7 @@ tp_motion_history_reset(struct tp_touch *t)
static inline struct tp_touch *
tp_current_touch(struct tp_dispatch *tp)
{
- return tp-touches[min(tp-slot, tp-ntouches)];
+ return tp-touches[min(tp-slot, tp-ntouches - 1)];
}
static inline struct tp_touch *
--
2.0.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston] desktop-shell: Don't assume there is a pointer when resizing
From: Emilio Pozuelo Monfort emilio.pozu...@collabora.co.uk Fixes a crash on touch devices without a pointer, when touching the window frame of a client. Signed-off-by: Emilio Pozuelo Monfort emilio.pozu...@collabora.co.uk --- desktop-shell/shell.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c index 84f5c83..d965618 100644 --- a/desktop-shell/shell.c +++ b/desktop-shell/shell.c @@ -1784,7 +1784,8 @@ common_surface_resize(struct wl_resource *resource, struct shell_surface *shsurf = wl_resource_get_user_data(resource); struct weston_surface *surface; - if (seat-pointer-button_count == 0 || + if (seat-pointer == NULL || + seat-pointer-button_count == 0 || seat-pointer-grab_serial != serial || seat-pointer-focus == NULL) return; -- 2.0.0 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: browser status on pure wayland
It's not about Wayland per se that made VDA on Linux possible... in short, Chromium devs couldn't afford maintenance of different decoding libraries on Linux for different hw vendors so they preferred to only maintain whatever comes on ChromeOS and its devices: https://code.google.com/p/chromium/issues/detail?id=137247 maybe I should blog about that and explain in more details. Tiago On 06/18/2014 03:12 PM, Yomi Ogunwumi wrote: What made adding video decoding acceleration in Chromium on Wayland possible? Would I be correct in guessing that Chromium on X11 doesn't have this functionality? Yomi On Jun 17, 2014 9:36 AM, Tiago Vignatti tiago.vigna...@linux.intel.com mailto:tiago.vigna...@linux.intel.com wrote: yup, Ozone-Wayland enables a bunch of Chromium based targets including the Chromium Browser. I have it daily running on my testing machines and the state is quite good, with most of expected functionalities in place. In fact yesterday I've added video decoding acceleration support (through libva) to it, so on this aspect Chromium on Linux is more advanced on Wayland than on X11 :) You're welcome to join #ozone-wayland at freenode to chat with developers and other users. Tiago On 06/17/2014 05:23 AM, Caner Altinbasak wrote: You can check ozone-wayland(wayland port of chromium): https://github.com/01org/__ozone-wayland https://github.com/01org/ozone-wayland On 17 June 2014 01:34, Andrea Giammarchi andrea.giammar...@gmail.com mailto:andrea.giammar...@gmail.com mailto:andrea.giammarchi@__gmail.com mailto:andrea.giammar...@gmail.com wrote: Hello There! Apologies if this has been discussed for years now but I've managed to build weston on wayland without any X11 dependency and miserably failed to build a WebKitGTK even forcing GTK3 which does build without problems on X-less systems. in WebKit2 --gtk=3.0 GTK2 is still required for some reason behind the scene but GTK2 won't build without xorg libraries which is kinda a fail since I had to bring in X related stuff that messed up with all other autogen.sh builds ^_^ Qt would probably be my best bet but AFAIK they are moving from QtWebkit to QtWebEngine and I'm not sure what's the status there (is this still the case?) Long story short: I'd like to have a pure wayland browser but I've no idea how to build one without bringing X libraries in. Can anyone please point me to a previous discussion or give me hints for a possible solution/repo/build instructions? Thanks a lot and most of all, thanks for Wayland, it's amazing so far! _ wayland-devel mailing list wayland-devel@lists.__freedesktop.org mailto:wayland-devel@lists.freedesktop.org mailto:wayland-devel@lists.__freedesktop.org mailto:wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/__mailman/listinfo/wayland-devel http://lists.freedesktop.org/mailman/listinfo/wayland-devel _ wayland-devel mailing list wayland-devel@lists.__freedesktop.org mailto:wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/__mailman/listinfo/wayland-devel http://lists.freedesktop.org/mailman/listinfo/wayland-devel _ wayland-devel mailing list wayland-devel@lists.__freedesktop.org mailto:wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/__mailman/listinfo/wayland-devel 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 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: browser status on pure wayland
I popped it yesterday in freenode but everyone was probably busy :-) Meanwhile, I've discovered that depot_tools to build chrome and chrome on ozone including GYP and not sure about ninja requires GTK2 for some reason so I am again back to the same problem: I really would like to build in the machine itself without polluting the env with anything X11 related ... how come this is such strong dependency even to GYP ? I wonder if anyone managed to manually build ozone/chromium without using Chrome tools ... like some manual kilometric instruction on the how to and what's really needed would be awesome, thanks! On Wed, Jun 18, 2014 at 11:24 AM, Tiago Vignatti tiago.vigna...@linux.intel.com wrote: It's not about Wayland per se that made VDA on Linux possible... in short, Chromium devs couldn't afford maintenance of different decoding libraries on Linux for different hw vendors so they preferred to only maintain whatever comes on ChromeOS and its devices: https://code.google.com/p/chromium/issues/detail?id=137247 maybe I should blog about that and explain in more details. Tiago On 06/18/2014 03:12 PM, Yomi Ogunwumi wrote: What made adding video decoding acceleration in Chromium on Wayland possible? Would I be correct in guessing that Chromium on X11 doesn't have this functionality? Yomi On Jun 17, 2014 9:36 AM, Tiago Vignatti tiago.vigna...@linux.intel.com mailto:tiago.vigna...@linux.intel.com wrote: yup, Ozone-Wayland enables a bunch of Chromium based targets including the Chromium Browser. I have it daily running on my testing machines and the state is quite good, with most of expected functionalities in place. In fact yesterday I've added video decoding acceleration support (through libva) to it, so on this aspect Chromium on Linux is more advanced on Wayland than on X11 :) You're welcome to join #ozone-wayland at freenode to chat with developers and other users. Tiago On 06/17/2014 05:23 AM, Caner Altinbasak wrote: You can check ozone-wayland(wayland port of chromium): https://github.com/01org/__ozone-wayland https://github.com/01org/ozone-wayland On 17 June 2014 01:34, Andrea Giammarchi andrea.giammar...@gmail.com mailto:andrea.giammar...@gmail.com mailto:andrea.giammarchi@__gmail.com mailto:andrea.giammar...@gmail.com wrote: Hello There! Apologies if this has been discussed for years now but I've managed to build weston on wayland without any X11 dependency and miserably failed to build a WebKitGTK even forcing GTK3 which does build without problems on X-less systems. in WebKit2 --gtk=3.0 GTK2 is still required for some reason behind the scene but GTK2 won't build without xorg libraries which is kinda a fail since I had to bring in X related stuff that messed up with all other autogen.sh builds ^_^ Qt would probably be my best bet but AFAIK they are moving from QtWebkit to QtWebEngine and I'm not sure what's the status there (is this still the case?) Long story short: I'd like to have a pure wayland browser but I've no idea how to build one without bringing X libraries in. Can anyone please point me to a previous discussion or give me hints for a possible solution/repo/build instructions? Thanks a lot and most of all, thanks for Wayland, it's amazing so far! _ wayland-devel mailing list wayland-devel@lists.__freedesktop.org mailto:wayland-devel@lists.freedesktop.org mailto:wayland-devel@lists.__freedesktop.org mailto:wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/__mailman/listinfo/wayland-devel http://lists.freedesktop.org/mailman/listinfo/wayland-devel _ wayland-devel mailing list wayland-devel@lists.__freedesktop.org mailto:wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/__mailman/listinfo/wayland-devel http://lists.freedesktop.org/mailman/listinfo/wayland-devel _ wayland-devel mailing list wayland-devel@lists.__freedesktop.org mailto:wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/__mailman/listinfo/wayland-devel 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: browser status on pure wayland
Brazil was playing in the World Cup yesterday, so yeah I was busy :) But I've seen your messages in the chat log. I think all you need is to set -Duse_x11=0 probably. I fixed that in Chromium once and it worked like a charm (in fact Tizen has been building Wayland-only images in awhile with this option). Tiago On 06/18/2014 03:46 PM, Andrea Giammarchi wrote: I popped it yesterday in freenode but everyone was probably busy :-) Meanwhile, I've discovered that depot_tools to build chrome and chrome on ozone including GYP and not sure about ninja requires GTK2 for some reason so I am again back to the same problem: I really would like to build in the machine itself without polluting the env with anything X11 related ... how come this is such strong dependency even to GYP ? I wonder if anyone managed to manually build ozone/chromium without using Chrome tools ... like some manual kilometric instruction on the how to and what's really needed would be awesome, thanks! On Wed, Jun 18, 2014 at 11:24 AM, Tiago Vignatti tiago.vigna...@linux.intel.com mailto:tiago.vigna...@linux.intel.com wrote: It's not about Wayland per se that made VDA on Linux possible... in short, Chromium devs couldn't afford maintenance of different decoding libraries on Linux for different hw vendors so they preferred to only maintain whatever comes on ChromeOS and its devices: https://code.google.com/p/__chromium/issues/detail?id=__137247 https://code.google.com/p/chromium/issues/detail?id=137247 maybe I should blog about that and explain in more details. Tiago On 06/18/2014 03:12 PM, Yomi Ogunwumi wrote: What made adding video decoding acceleration in Chromium on Wayland possible? Would I be correct in guessing that Chromium on X11 doesn't have this functionality? Yomi On Jun 17, 2014 9:36 AM, Tiago Vignatti tiago.vignatti@linux.intel.__com mailto:tiago.vigna...@linux.intel.com mailto:tiago.vignatti@linux.__intel.com mailto:tiago.vigna...@linux.intel.com wrote: yup, Ozone-Wayland enables a bunch of Chromium based targets including the Chromium Browser. I have it daily running on my testing machines and the state is quite good, with most of expected functionalities in place. In fact yesterday I've added video decoding acceleration support (through libva) to it, so on this aspect Chromium on Linux is more advanced on Wayland than on X11 :) You're welcome to join #ozone-wayland at freenode to chat with developers and other users. Tiago On 06/17/2014 05:23 AM, Caner Altinbasak wrote: You can check ozone-wayland(wayland port of chromium): https://github.com/01org/ozone-wayland https://github.com/01org/__ozone-wayland https://github.com/01org/__ozone-wayland https://github.com/01org/ozone-wayland On 17 June 2014 01:34, Andrea Giammarchi andrea.giammar...@gmail.com mailto:andrea.giammar...@gmail.com mailto:andrea.giammarchi@__gmail.com mailto:andrea.giammar...@gmail.com mailto:andrea.giammarchi@ mailto:andrea.giammarchi@__gm__ail.com http://gmail.com mailto:andrea.giammarchi@__gmail.com mailto:andrea.giammar...@gmail.com wrote: Hello There! Apologies if this has been discussed for years now but I've managed to build weston on wayland without any X11 dependency and miserably failed to build a WebKitGTK even forcing GTK3 which does build without problems on X-less systems. in WebKit2 --gtk=3.0 GTK2 is still required for some reason behind the scene but GTK2 won't build without xorg libraries which is kinda a fail since I had to bring in X related stuff that messed up with all other autogen.sh builds ^_^ Qt would probably be my best bet but AFAIK they are moving from QtWebkit to QtWebEngine and I'm not sure what's the status there (is this still the case?) Long story short: I'd like to have a pure wayland browser but I've no idea how to build one without bringing X libraries in. Can anyone please point me to a previous discussion or give me hints for a possible solution/repo/build
Re: [PATCH] compositor: update the surface size when there is a size change without a buffer attach
On Fri, Jun 13, 2014 at 9:14 AM, George Kiagiadakis
george.kiagiada...@collabora.com wrote:
This fixes at least the case where you want to do
wl_viewport.set_destination
to resize the surface but without attaching new content in it.
---
src/compositor.c | 60
+++-
src/compositor.h | 2 ++
2 files changed, 48 insertions(+), 14 deletions(-)
diff --git a/src/compositor.c b/src/compositor.c
index 2fbfdbf..973c7e4 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -404,6 +404,7 @@ weston_surface_create(struct weston_compositor
*compositor)
surface-buffer_viewport.buffer.scale = 1;
surface-buffer_viewport.buffer.src_width = wl_fixed_from_int(-1);
surface-buffer_viewport.surface.width = -1;
+ surface-pending.buffer_viewport.changed = 0;
surface-pending.buffer_viewport = surface-buffer_viewport;
surface-output = NULL;
surface-pending.newly_attached = 0;
@@ -1211,13 +1212,12 @@ fixed_round_up_to_int(wl_fixed_t f)
}
static void
-weston_surface_set_size_from_buffer(struct weston_surface *surface)
+weston_surface_calculate_size_from_buffer(struct weston_surface *surface)
{
struct weston_buffer_viewport *vp = surface-buffer_viewport;
int32_t width, height;
if (!surface-buffer_ref.buffer) {
- surface_set_size(surface, 0, 0);
surface-width_from_buffer = 0;
surface-height_from_buffer = 0;
return;
@@ -1239,14 +1239,24 @@ weston_surface_set_size_from_buffer(struct
weston_surface *surface)
surface-width_from_buffer = width;
surface-height_from_buffer = height;
+}
+
+static void
+weston_surface_update_size(struct weston_surface *surface)
+{
+ struct weston_buffer_viewport *vp = surface-buffer_viewport;
+ int32_t width, height;
+
+ width = surface-width_from_buffer;
+ height = surface-height_from_buffer;
- if (vp-surface.width != -1) {
+ if (width != 0 vp-surface.width != -1) {
surface_set_size(surface,
vp-surface.width, vp-surface.height);
return;
}
- if (vp-buffer.src_width != wl_fixed_from_int(-1)) {
+ if (width != 0 vp-buffer.src_width != wl_fixed_from_int(-1)) {
int32_t w = fixed_round_up_to_int(vp-buffer.src_width);
int32_t h = fixed_round_up_to_int(vp-buffer.src_height);
@@ -1351,6 +1361,7 @@ weston_surface_reset_pending_buffer(struct
weston_surface *surface)
surface-pending.sx = 0;
surface-pending.sy = 0;
surface-pending.newly_attached = 0;
+ surface-pending.buffer_viewport.changed = 0;
}
struct weston_frame_callback {
@@ -1520,7 +1531,7 @@ weston_surface_attach(struct weston_surface *surface,
surface-compositor-renderer-attach(surface, buffer);
- weston_surface_set_size_from_buffer(surface);
+ weston_surface_calculate_size_from_buffer(surface);
}
I think we have an issue here. If a client attaches a new buffer but does
not commit for a while, the width/height_from_buffer and width/height will
be out of sync. That said, I think having surface_set_size_from_buffer
here was wrong in the first place. The new surface size should only take
over after the commit. Other than that, the patch looks fine to me.
--Jason Ekstrand
WL_EXPORT void
@@ -2049,8 +2060,6 @@ weston_surface_commit(struct weston_surface *surface)
struct weston_view *view;
pixman_region32_t opaque;
- /* XXX: wl_viewport.set without an attach should call configure */
-
/* wl_surface.set_buffer_transform */
/* wl_surface.set_buffer_scale */
/* wl_viewport.set */
@@ -2060,9 +2069,13 @@ weston_surface_commit(struct weston_surface
*surface)
if (surface-pending.newly_attached)
weston_surface_attach(surface, surface-pending.buffer);
- if (surface-configure surface-pending.newly_attached)
- surface-configure(surface,
- surface-pending.sx, surface-
pending.sy);
+ if (surface-pending.newly_attached ||
+ surface-pending.buffer_viewport.changed) {
+ weston_surface_update_size(surface);
+ if (surface-configure)
+ surface-configure(surface, surface-pending.sx,
+ surface-pending.sy);
+ }
weston_surface_reset_pending_buffer(surface);
@@ -2151,6 +2164,7 @@ surface_set_buffer_transform(struct wl_client
*client,
}
surface-pending.buffer_viewport.buffer.transform = transform;
+ surface-pending.buffer_viewport.changed = 1;
}
static void
@@ -2169,6 +2183,7 @@ surface_set_buffer_scale(struct wl_client *client,
}
Re: browser status on pure wayland
I'll try that, and I've been at Tizen conf and know about Xwalk but building Wayland images only from a X based system is like cheating :-) I'd like to build Wayland only ozone/chromium from a Wayland only system and I'll try that flag ASAP, thanks! On Wed, Jun 18, 2014 at 11:59 AM, Tiago Vignatti tiago.vigna...@linux.intel.com wrote: Brazil was playing in the World Cup yesterday, so yeah I was busy :) But I've seen your messages in the chat log. I think all you need is to set -Duse_x11=0 probably. I fixed that in Chromium once and it worked like a charm (in fact Tizen has been building Wayland-only images in awhile with this option). Tiago On 06/18/2014 03:46 PM, Andrea Giammarchi wrote: I popped it yesterday in freenode but everyone was probably busy :-) Meanwhile, I've discovered that depot_tools to build chrome and chrome on ozone including GYP and not sure about ninja requires GTK2 for some reason so I am again back to the same problem: I really would like to build in the machine itself without polluting the env with anything X11 related ... how come this is such strong dependency even to GYP ? I wonder if anyone managed to manually build ozone/chromium without using Chrome tools ... like some manual kilometric instruction on the how to and what's really needed would be awesome, thanks! On Wed, Jun 18, 2014 at 11:24 AM, Tiago Vignatti tiago.vigna...@linux.intel.com mailto:tiago.vigna...@linux.intel.com wrote: It's not about Wayland per se that made VDA on Linux possible... in short, Chromium devs couldn't afford maintenance of different decoding libraries on Linux for different hw vendors so they preferred to only maintain whatever comes on ChromeOS and its devices: https://code.google.com/p/__chromium/issues/detail?id=__137247 https://code.google.com/p/chromium/issues/detail?id=137247 maybe I should blog about that and explain in more details. Tiago On 06/18/2014 03:12 PM, Yomi Ogunwumi wrote: What made adding video decoding acceleration in Chromium on Wayland possible? Would I be correct in guessing that Chromium on X11 doesn't have this functionality? Yomi On Jun 17, 2014 9:36 AM, Tiago Vignatti tiago.vignatti@linux.intel.__com mailto:tiago.vigna...@linux.intel.com mailto:tiago.vignatti@linux.__intel.com mailto:tiago.vigna...@linux.intel.com wrote: yup, Ozone-Wayland enables a bunch of Chromium based targets including the Chromium Browser. I have it daily running on my testing machines and the state is quite good, with most of expected functionalities in place. In fact yesterday I've added video decoding acceleration support (through libva) to it, so on this aspect Chromium on Linux is more advanced on Wayland than on X11 :) You're welcome to join #ozone-wayland at freenode to chat with developers and other users. Tiago On 06/17/2014 05:23 AM, Caner Altinbasak wrote: You can check ozone-wayland(wayland port of chromium): https://github.com/01org/ozone-wayland https://github.com/01org/__ozone-wayland https://github.com/01org/__ozone-wayland https://github.com/01org/ozone-wayland On 17 June 2014 01:34, Andrea Giammarchi andrea.giammar...@gmail.com mailto:andrea.giammar...@gmail.com mailto:andrea.giammarchi@__gmail.com mailto:andrea.giammar...@gmail.com mailto:andrea.giammarchi@ mailto:andrea.giammarchi@__gm__ail.com http://gmail.com mailto:andrea.giammarchi@__gmail.com mailto:andrea.giammar...@gmail.com wrote: Hello There! Apologies if this has been discussed for years now but I've managed to build weston on wayland without any X11 dependency and miserably failed to build a WebKitGTK even forcing GTK3 which does build without problems on X-less systems. in WebKit2 --gtk=3.0 GTK2 is still required for some reason behind the scene but GTK2 won't build without xorg libraries which is kinda a fail since I had to bring in X related stuff that messed up with all other autogen.sh builds ^_^ Qt would probably be my best bet but AFAIK they are moving from QtWebkit to QtWebEngine and I'm not sure what's the status
Re: [PATCH weston] Apply output transform to the cursor while copying into a plane
On Wed, May 21, 2014 at 07:36:21PM +0100, Neil Roberts wrote:
Previously if the output had a transform then the cursor plane would
be disabled. However as we have to copy the cursor image into a buffer
with the CPU anyway it probably won't cost much extra to also apply
the transform in the process and then we can avoid disabling the
plane.
If the transform is either normal or flipped-180 then a slightly
faster path is used that still copies the lines one at a time with
memcpy. Otherwise there is a slower path which copies one pixel at a
time.
Previously the check for whether to disable the plane was only looking
at whether the output has a transform. However it should probably have
also been disabled if the surface has a transform. This patch changes
it to just look at the surface transform instead. It could be possible
to work out a relative transform and apply that so that any
combinations of transforms will work, but this patch doesn't attempt
that.
Could we just use pixman here? We could also scale up the cursor image
when possible with that.
Kristian
---
src/compositor-drm.c | 120
---
1 file changed, 113 insertions(+), 7 deletions(-)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 7d514e4..553454d 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -958,7 +958,7 @@ drm_output_prepare_cursor_view(struct weston_output
*output_base,
if (c-gbm == NULL)
return NULL;
- if (output-base.transform != WL_OUTPUT_TRANSFORM_NORMAL)
+ if (viewport-buffer.transform != WL_OUTPUT_TRANSFORM_NORMAL)
return NULL;
if (viewport-buffer.scale != output_base-current_scale)
return NULL;
@@ -979,6 +979,102 @@ drm_output_prepare_cursor_view(struct weston_output
*output_base,
}
static void
+transform_cursor_buffer_slow(enum wl_output_transform transform,
+ uint32_t *buf,
+ unsigned char *s,
+ int32_t width,
+ int32_t height,
+ int stride)
+{
+ int angle = transform 3;
+ int swap_xy = transform 1;
+ int flip_x, flip_y;
+ int buf_x_increment, buf_y_increment;
+ int s_y_increment;
+ int sx, sy;
+
+ /* Flip here means we flip the direction of the destination
+ * iterators */
+ flip_x = (angle 1) ^ (angle 1);
+ flip_y = (angle 1);
+
+ if (swap_xy) {
+ if (transform 4)
+ flip_y = !flip_y;
+
+ if (flip_y) {
+ buf += (width - 1) * 64;
+ buf_x_increment = -64;
+ } else {
+ buf_x_increment = 64;
+ }
+
+ if (flip_x) {
+ buf += height - 1;
+ buf_y_increment = -1 - buf_x_increment * width;
+ } else {
+ buf_y_increment = 1 - buf_x_increment * width;
+ }
+ } else {
+ if (transform 4)
+ flip_x = !flip_x;
+
+ if (flip_x) {
+ buf += width - 1;
+ buf_x_increment = -1;
+ } else {
+ buf_x_increment = 1;
+ }
+
+ if (flip_y) {
+ buf += (height - 1) * 64;
+ buf_y_increment = -64 - buf_x_increment * width;
+ } else {
+ buf_y_increment = 64 - buf_x_increment * width;
+ }
+ }
+
+ s_y_increment = stride - width * 4;
+
+ for (sy = 0; sy height; sy++) {
+ for (sx = 0; sx width; sx++) {
+ memcpy(buf, s, 4);
+ s += 4;
+ buf += buf_x_increment;
+ }
+ s += s_y_increment;
+ buf += buf_y_increment;
+ }
+}
+
+static void
+transform_cursor_buffer(enum wl_output_transform transform,
+ uint32_t *buf,
+ unsigned char *s,
+ int32_t width,
+ int32_t height,
+ int stride)
+{
+ int y;
+
+ switch (transform) {
+ case WL_OUTPUT_TRANSFORM_NORMAL:
+ for (y = 0; y height; y++)
+ memcpy(buf + y * 64, s + y * stride, width * 4);
+ break;
+ case WL_OUTPUT_TRANSFORM_FLIPPED_180:
+ for (y = 0; y height; y++)
+ memcpy(buf + y * 64, s + (height - 1 - y) * stride,
+width * 4);
+ break;
+ default:
+ transform_cursor_buffer_slow(transform,
+ buf, s, width, height, stride);
+ break;
+ }
+}
+
+static void
drm_output_set_cursor(struct drm_output *output)
{
Re: [PATCH] protocol: remove redundant 'the' in description
On Fri, May 23, 2014 at 07:26:56AM +0200, Silvan Jegen wrote: Signed-off-by: Silvan Jegen s.je...@gmail.com Thanks, applied. Kristian --- protocol/wayland.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 22eb6e7..113c7b7 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -550,8 +550,8 @@ The current and pending input regions of the icon wl_surface are cleared, and wl_surface.set_input_region is ignored until the wl_surface is no longer used as the icon surface. When the use - as an icon ends, the the current and pending input regions - become undefined, and the wl_surface is unmapped. + as an icon ends, the current and pending input regions become + undefined, and the wl_surface is unmapped. /description arg name=source type=object interface=wl_data_source allow-null=true/ arg name=origin type=object interface=wl_surface/ -- 1.9.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 weston] exposay: fix crash when navigating with the keyboard
On Sat, May 24, 2014 at 02:43:04AM +0200, Emilio Pozuelo Monfort wrote:
From: Emilio Pozuelo Monfort emilio.pozu...@collabora.co.uk
Commit a7592019 introduced an optimization that caused some
exposay struct members to not be properly initialized, particularly
cur_output, leading to crashes in some circumstances (e.g. pressing
the down arrow key after going to exposay).
Signed-off-by: Emilio Pozuelo Monfort emilio.pozu...@collabora.co.uk
Thanks, I see the problem, and this fixes it. Committed.
Kristian
---
desktop-shell/exposay.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/desktop-shell/exposay.c b/desktop-shell/exposay.c
index 1d8b40e..104b9d9 100644
--- a/desktop-shell/exposay.c
+++ b/desktop-shell/exposay.c
@@ -323,8 +323,10 @@ exposay_layout(struct desktop_shell *shell, struct
shell_output *shell_output)
i++;
}
- if (highlight)
+ if (highlight) {
+ shell-exposay.focus_current = NULL;
exposay_highlight_surface(shell, highlight);
+ }
weston_compositor_schedule_repaint(shell-compositor);
--
2.0.0.rc2
___
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 weston 1/5] animation: fix move scale animation
On Thu, May 22, 2014 at 10:41:30PM +0200, Jonny Lamb wrote: Both weston_move_scale_run() and weston_slide_run() were broken in commit 3a869019. Commit a4a6f161 fixed and explained the problem for weston_slide_run() but weston_move_scale_run() remained broken. To fix weston_move_scale_run(), weston_view_animation_run() is also required. It was removed when _run() was split into two functions _create() and _run() in commit f5cc2b56, but _run() was not added in this commit. Thanks, that fixes exposay, applied. Kristian --- src/animation.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/animation.c b/src/animation.c index a29b34a..392e32d 100644 --- a/src/animation.c +++ b/src/animation.c @@ -458,8 +458,10 @@ weston_move_scale_run(struct weston_view *view, int dx, int dy, if (animation == NULL) return NULL; - weston_spring_init(animation-spring, 400.0, start, end); + weston_spring_init(animation-spring, 400.0, 0.0, 1.0); animation-spring.friction = 1150; + weston_view_animation_run(animation); + return animation; } -- 2.0.0.rc2 ___ 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 weston 3/5] desktop-shell: use panel location to calculate correct sizes and ranges
On Thu, May 22, 2014 at 10:41:32PM +0200, Jonny Lamb wrote:
Now the client can let us know where the panel is using
desktop_shell.set_panel_position, we can correctly calculate where to
put new views and how big maximized views should be.
---
desktop-shell/shell.c | 229
++
1 file changed, 173 insertions(+), 56 deletions(-)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index e586922..51683ee 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -251,9 +251,10 @@ shell_fade_startup(struct desktop_shell *shell);
static struct shell_seat *
get_shell_seat(struct weston_seat *seat);
-static int
-get_output_panel_height(struct desktop_shell *shell,
- struct weston_output *output);
+static void
+get_output_panel_size(struct desktop_shell *shell,
+ struct weston_output *output,
+ int *width, int *height);
static void
shell_surface_update_child_surface_layers(struct shell_surface *shsurf);
@@ -351,24 +352,54 @@ shell_grab_start(struct shell_grab *grab,
}
}
-static int
-get_output_panel_height(struct desktop_shell *shell,
- struct weston_output *output)
+static void
+get_output_panel_size(struct desktop_shell *shell,
+ struct weston_output *output,
+ int *width,
+ int *height)
{
struct weston_view *view;
- int panel_height = 0;
- if (!output)
- return 0;
+ if (output) {
+ wl_list_for_each(view, shell-panel_layer.view_list,
layer_link) {
+ if (view-surface-output == output) {
+ float x, y;
Can we do
if (view-surface-output != output)
continue;
instead to avoid the 4 level indent here?
- wl_list_for_each(view, shell-panel_layer.view_list, layer_link) {
- if (view-surface-output == output) {
- panel_height = view-surface-height;
- break;
+ if (shell-panel_position ==
+ DESKTOP_SHELL_PANEL_POSITION_TOP ||
+ shell-panel_position ==
+ DESKTOP_SHELL_PANEL_POSITION_BOTTOM) {
+
+ weston_view_to_global_float(view,
+
view-surface-width, 0,
+ x, y);
+
+ *width = (int) x;
+ *height = view-surface-height + (int)
y;
+
+ return;
+
+ } else if (shell-panel_position ==
+DESKTOP_SHELL_PANEL_POSITION_LEFT ||
+shell-panel_position ==
+DESKTOP_SHELL_PANEL_POSITION_RIGHT) {
+
+ weston_view_to_global_float(view,
+ 0,
view-surface-height,
+ x, y);
+
+ *width = view-surface-width + (int) x;
+ *height = (int) y;
+
+ return;
It'll be cleaner and easier to read if we do this as a case statement:
switch (shell-panel_position) {
case DESKTOP_SHELL_PANEL_POSITION_TOP:
case DESKTOP_SHELL_PANEL_POSITION_BOTTOM:
..
}
+ }
+ }
}
}
- return panel_height;
+ /* output is NULL or the correct view wasn't found */
+ *width = 0;
+ *height = 0;
}
static void
@@ -389,13 +420,20 @@ send_configure_for_surface(struct shell_surface *shsurf)
height = shsurf-output-height;
} else if (state-maximized) {
struct desktop_shell *shell;
- uint32_t panel_height = 0;
+ int32_t panel_width = 0, panel_height = 0;
shell = shell_surface_get_shell(shsurf);
- panel_height = get_output_panel_height(shell, shsurf-output);
+ get_output_panel_size(shell, shsurf-output,
+ panel_width, panel_height);
width = shsurf-output-width;
height = shsurf-output-height - panel_height;
+
+ if (shell-panel_position == DESKTOP_SHELL_PANEL_POSITION_LEFT
||
+ shell-panel_position ==
DESKTOP_SHELL_PANEL_POSITION_RIGHT) {
+ width = shsurf-output-width - panel_width;
+ height = shsurf-output-height;
+ }
} else {
width = 0;
Re: [PATCH weston 4/5] animation: ensure repaints are always scheduled during animations
On Thu, May 22, 2014 at 10:41:33PM +0200, Jonny Lamb wrote:
Animations are run off the repaint cycle so if there's nothing to
repaint, an animation will stop running. This is usually not a problem
as each frame function of an animation causes something to change and
therefore a repaint to happen. This patch helps detect when the
animation isn't in said case and triggers a repaint to keep the
animation running.
This problem was found by using weston_move_scale_run() to move a view
onscreen from completely off. The very first time the animation frame
function was called the progress wasn't enough to move it into
view. The compositor saw there was nothing to repaint and stopped
doing anything else. When something else (like a pointer move) forced
a redraw, the view's position was very much onscreen and jumped into
view in an ugly way.
Yup, this should work.
Kristian
---
src/animation.c | 11 +++
src/spring-tool.c | 5 +
2 files changed, 16 insertions(+)
diff --git a/src/animation.c b/src/animation.c
index 392e32d..5ded3ad 100644
--- a/src/animation.c
+++ b/src/animation.c
@@ -161,6 +161,8 @@ weston_view_animation_frame(struct weston_animation *base,
struct weston_view_animation *animation =
container_of(base,
struct weston_view_animation, animation);
+ struct weston_compositor *compositor =
+ animation-view-surface-compositor;
if (base-frame_counter = 1)
animation-spring.timestamp = msecs;
@@ -178,6 +180,15 @@ weston_view_animation_frame(struct weston_animation
*base,
weston_view_geometry_dirty(animation-view);
weston_view_schedule_repaint(animation-view);
+
+ /* The view's output_mask will be zero if its position is
+ * offscreen. Animations should always run but as they are also
+ * run off the repaint cycle, if there's nothing to repaint
+ * the animation stops running. Therefore if we catch this situation
+ * and schedule a repaint on all outputs it will be avoided.
+ */
+ if (animation-view-output_mask == 0)
+ weston_compositor_schedule_repaint(compositor);
}
static struct weston_view_animation *
diff --git a/src/spring-tool.c b/src/spring-tool.c
index 41cc52c..685bfd9 100644
--- a/src/spring-tool.c
+++ b/src/spring-tool.c
@@ -40,6 +40,11 @@ weston_view_schedule_repaint(struct weston_view *view)
{
}
+WL_EXPORT void
+weston_compositor_schedule_repaint(struct weston_compositor *compositor)
+{
+}
+
int
main(int argc, char *argv[])
{
--
2.0.0.rc2
___
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 weston 5/5] desktop-shell: make background applications less dark
On Thu, May 22, 2014 at 10:41:34PM +0200, Jonny Lamb wrote:
Patch applied.
Kristian
---
desktop-shell/shell.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 51683ee..a5886d7 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -911,21 +911,21 @@ animate_focus_change(struct desktop_shell *shell,
struct workspace *ws,
if (focus_surface_created) {
ws-focus_animation = weston_fade_run(
ws-fsurf_front-view,
- ws-fsurf_front-view-alpha, 0.6, 300,
+ ws-fsurf_front-view-alpha, 0.4, 300,
focus_animation_done, ws);
} else if (from) {
wl_list_insert(from-layer_link,
ws-fsurf_back-view-layer_link);
ws-focus_animation = weston_stable_fade_run(
ws-fsurf_front-view, 0.0,
- ws-fsurf_back-view, 0.6,
+ ws-fsurf_back-view, 0.4,
focus_animation_done, ws);
} else if (to) {
wl_list_insert(ws-layer.view_list,
ws-fsurf_back-view-layer_link);
ws-focus_animation = weston_stable_fade_run(
ws-fsurf_front-view, 0.0,
- ws-fsurf_back-view, 0.6,
+ ws-fsurf_back-view, 0.4,
focus_animation_done, ws);
}
}
--
2.0.0.rc2
___
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] compositor-wayland: Fix compiler warning
On Tue, May 27, 2014 at 09:08:29AM +0200, Thierry Reding wrote:
From: Thierry Reding tred...@nvidia.com
sizeof returns size_t, for which the correct printf specifier is %zu.
Fixes the following warning when building for ARMv7.
src/compositor-wayland.c: In function 'wayland_output_get_shm_buffer':
src/compositor-wayland.c:260:3: warning: format '%ld' expects argument
of type 'long int', but argument 2 has type 'unsigned int' [-Wformat=]
weston_log(could not zalloc %ld memory for sb: %m\n, sizeof *sb);
^
Signed-off-by: Thierry Reding tred...@nvidia.com
Thanks, patch applied.
Kristian
---
src/compositor-wayland.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
index 76e5396f4215..a4dcec272233 100644
--- a/src/compositor-wayland.c
+++ b/src/compositor-wayland.c
@@ -257,7 +257,7 @@ wayland_output_get_shm_buffer(struct wayland_output
*output)
sb = zalloc(sizeof *sb);
if (sb == NULL) {
- weston_log(could not zalloc %ld memory for sb: %m\n, sizeof
*sb);
+ weston_log(could not zalloc %zu memory for sb: %m\n, sizeof
*sb);
close(fd);
free(data);
return NULL;
--
1.9.2
___
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] weston: Fix memleak issue in compositor.c
On Tue, May 27, 2014 at 02:30:59PM +0530, Srivardhan Hebbar wrote:
This fix is upon Hardening rdp.eff...@gmail.com patch. [PATCH 2/2] Handle
OOM with signal events.
Thanks, applied. I edited the commit message to wrap at 72 columns.
Kristian
Signed-off-by: Srivardhan Hebbar sri.heb...@samsung.com
---
src/compositor.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/src/compositor.c b/src/compositor.c
index 574db2d..f233101 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -4207,6 +4207,11 @@ int main(int argc, char *argv[])
signals[3] = wl_event_loop_add_signal(loop, SIGCHLD, sigchld_handler,
NULL);
+ if (!signals[0] || !signals[1] || !signals[2] || !signals[3]) {
+ ret = EXIT_FAILURE;
+ goto out_signals;
+ }
+
if (noconfig == 0)
config = weston_config_parse(weston.ini);
if (config != NULL) {
@@ -4234,13 +4239,16 @@ int main(int argc, char *argv[])
backend_init = weston_load_module(backend, backend_init);
free(backend);
- if (!backend_init)
- exit(EXIT_FAILURE);
+ if (!backend_init) {
+ ret = EXIT_FAILURE;
+ goto out_signals;
+ }
ec = backend_init(display, argc, argv, config);
if (ec == NULL) {
weston_log(fatal: failed to create compositor\n);
- exit(EXIT_FAILURE);
+ ret = EXIT_FAILURE;
+ goto out_signals;
}
catch_signals();
@@ -4321,12 +4329,15 @@ int main(int argc, char *argv[])
wl_signal_emit(ec-destroy_signal, ec);
- for (i = ARRAY_LENGTH(signals); i;)
- wl_event_source_remove(signals[--i]);
-
weston_compositor_xkb_destroy(ec);
ec-destroy(ec);
+
+out_signals:
+ for (i = ARRAY_LENGTH(signals) - 1; i = 0; i--)
+ if (signals[i])
+ wl_event_source_remove(signals[i]);
+
wl_display_destroy(display);
weston_log_file_close();
--
1.7.9.5
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 2/2] evdev-mt-touchpad: tp_current_touch: Fix off by one error
On Wed, Jun 18, 2014 at 02:22:24PM +0200, Hans de Goede wrote:
Signed-off-by: Hans de Goede hdego...@redhat.com
---
src/evdev-mt-touchpad.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index 0294eb2..92e0651 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -139,7 +139,7 @@ tp_motion_history_reset(struct tp_touch *t)
static inline struct tp_touch *
tp_current_touch(struct tp_dispatch *tp)
{
- return tp-touches[min(tp-slot, tp-ntouches)];
+ return tp-touches[min(tp-slot, tp-ntouches - 1)];
}
static inline struct tp_touch *
--
2.0.0
merged, thanks. one minor comment: we dropped the old touchpad driver now,
so a prefix of touchpad: is enough. I've changed that before pushing.
Cheers,
Peter
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston client window] Fixed the input region of the popup menu
On Mon, Jun 02, 2014 at 01:53:38PM +0200, Tomek Obrebski wrote:
Changed the input region of the menu popup window to exclude the shadow and
border regions and set to frame's internal region only.
This is a good patch but there are a few stylistic issues. First, the
commit message is usually written in present tense, ie what the patch
*does* not what you did. Also the body should be wrapped at around 72
columns.
Regards,
blsd
---
clients/window.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/clients/window.c b/clients/window.c
index b82a93e..9a6e8be 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -4615,7 +4615,8 @@ window_show_menu(struct display *display,
{
struct menu *menu;
struct window *window;
- int32_t ix, iy;
+struct wl_region *input_region;
+int32_t ix, iy, ih, iw;
We use 8-space tabs for indent, as you can see right here in the patch, the
indention of the lines you added don't match the indention of the lines
already there.
Other than the stylistic issues, the patch is good and fixes the problem.
Kristian
menu = create_menu(display, input, time, func, entries, count, parent);
@@ -4630,7 +4631,11 @@ window_show_menu(struct display *display,
window-x = x;
window-y = y;
- frame_interior(menu-frame, ix, iy, NULL, NULL);
+frame_interior(menu-frame, ix, iy, iw, ih);
+input_region = wl_compositor_create_region(display-compositor);
+wl_region_add(input_region, ix, iy, iw, ih);
+wl_surface_set_input_region(window-main_surface-surface, input_region);
+wl_region_destroy(input_region);
window-xdg_popup = xdg_shell_get_xdg_popup(display-xdg_shell,
window-main_surface-surface,
--
1.9.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] connection: remove unreached code
On Wed, Jun 04, 2014 at 11:39:08AM +0800, Boyan Ding wrote: Heh, oops, that was silly. Patch committed, thanks. Kristian --- src/connection.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/connection.c b/src/connection.c index 47ee556..f292853 100644 --- a/src/connection.c +++ b/src/connection.c @@ -379,8 +379,6 @@ wl_connection_queue(struct wl_connection *connection, } return wl_buffer_put(connection-out, data, count); - - return 0; } static int -- 1.9.3 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 1/2] evdev: Safe x and y resolution for later use
On Wed, Jun 18, 2014 at 02:22:23PM +0200, Hans de Goede wrote:
Signed-off-by: Hans de Goede hdego...@redhat.com
---
src/evdev.c | 2 ++
src/evdev.h | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/evdev.c b/src/evdev.c
index 51ad5e3..b72e5e1 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -608,11 +608,13 @@ evdev_configure_device(struct evdev_device *device)
if ((absinfo = libevdev_get_abs_info(evdev, ABS_X))) {
device-abs.min_x = absinfo-minimum;
device-abs.max_x = absinfo-maximum;
+ device-abs.res_x = absinfo-resolution;
has_abs = 1;
}
if ((absinfo = libevdev_get_abs_info(evdev, ABS_Y))) {
device-abs.min_y = absinfo-minimum;
device-abs.max_y = absinfo-maximum;
+ device-abs.res_y = absinfo-resolution;
This came up in the tablet branch when testing: the resolution of a device
_may_ be 0. I don't know how many devices with ABS_X/Y still have zero, but
especially when testing with uinput devices it always is. uinput currently
doesn't let you set the resolution, the kernel patch to fix this stalled a
while ago and needs someone motivated to pick it up again :)
so I think it'd be safer to force the resolution to 1, prevents a couple of
mathematical surprises lateron.
Cheers,
Peter
PS: save, not safe in the commit msg, except for when saving 1 is
safe :)
has_abs = 1;
}
/* We only handle the slotted Protocol B in weston.
diff --git a/src/evdev.h b/src/evdev.h
index d057010..2db990f 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -66,7 +66,7 @@ struct evdev_device {
const char *devname;
int fd;
struct {
- int min_x, max_x, min_y, max_y;
+ int min_x, max_x, min_y, max_y, res_x, res_y;
int32_t x, y;
int32_t seat_slot;
--
2.0.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] client: extend error handling
On Mon, May 26, 2014 at 04:57:23PM +0200, Marek Chalupa wrote:
When an error occurs, wl_display_get_error() does not
provide any way of getting know if it was a local error or if it was
an error event, respectively what object caused the error and what
the error was.
This patch introduces a new function wl_display_get_protocol_error()
which will return error code, interface and id of the object that
generated the error.
wl_display_get_error() will work the same way as before.
wl_display_get_protocol_error() DOES NOT indicate that a non-protocol
error happened. It returns valid information only in that case that
(protocol) error occurred, so it should be used after calling
wl_display_get_error() with positive result.
Thanks to Pekka Paalanen ppaala...@gmail.com for pointing out
issues in the first versions of this patch.
Reviewed-by: Pekka Paalanen ppaala...@gmail.com
Some copyedits below. Otherwise LGTM.
Reviewed-by: Bryce Harrington b.harring...@samsung.com
---
src/wayland-client.c | 138
---
src/wayland-client.h | 3 ++
2 files changed, 123 insertions(+), 18 deletions(-)
diff --git a/src/wayland-client.c b/src/wayland-client.c
index e8aab7e..ee2215d 100644
--- a/src/wayland-client.c
+++ b/src/wayland-client.c
@@ -78,7 +78,24 @@ struct wl_event_queue {
struct wl_display {
struct wl_proxy proxy;
struct wl_connection *connection;
+
+ /* errno of the last wl_display error */
int last_error;
+
+ /* When display gets an error event from some object, it stores
+ * information about it here, so that client can get this
+ * information afterwards */
+ struct {
+ /* Code of the error. It can be compared to
+ * the interface's errors enumeration. */
+ uint32_t code;
+ /* interface (protocol) in which the error occurred */
+ const struct wl_interface *interface;
+ /* id of the proxy that caused the error. There's no warranty
+ * that the proxy is still valid. It's up to client how it will
+ * use it */
+ uint32_t id;
+ } protocol_error;
int fd;
pthread_t display_thread;
struct wl_map objects;
@@ -96,6 +113,14 @@ struct wl_display {
static int debug_client = 0;
+/**
+ * This function is called for local errors (no memory, server hung up)
+ *
+ * \param display
+ * \param errorerror value (EINVAL, EFAULT, ...)
+ *
+ * \note this function is called with display mutex locked
+ */
static void
display_fatal_error(struct wl_display *display, int error)
{
@@ -105,7 +130,7 @@ display_fatal_error(struct wl_display *display, int error)
return;
if (!error)
- error = 1;
+ error = EFAULT;
display-last_error = error;
@@ -113,11 +138,56 @@ display_fatal_error(struct wl_display *display, int
error)
pthread_cond_broadcast(iter-cond);
}
+/**
+ * This function is called for error events
+ * and idicates that in some object occured an error.
indicates
in some object an error occurred might be grammatically better.
+ * Difference between this function and display_fatal_error()
+ * is that this one handles errors that will come in wire, whereas
come by wire or come in by wire might be clearer
+ * display_fatal_error() is called for local errors.
+ *
+ * \param display
+ * \param codeerror code
+ * \param id id of the object that generated the error
+ * \param intfprotocol interface
+ */
static void
-wl_display_fatal_error(struct wl_display *display, int error)
+display_protocol_error(struct wl_display *display, uint32_t code,
+uint32_t id, const struct wl_interface *intf)
{
+ struct wl_event_queue *iter;
+ int err;
+
+ if (display-last_error)
+ return;
+
+ /* set correct errno */
+ if (wl_interface_equal(intf, wl_display_interface)) {
+ switch (code) {
+ case WL_DISPLAY_ERROR_INVALID_OBJECT:
+ case WL_DISPLAY_ERROR_INVALID_METHOD:
+ err = EINVAL;
+ break;
+ case WL_DISPLAY_ERROR_NO_MEMORY:
+ err = ENOMEM;
+ break;
+ default:
+ err = EFAULT;
+ }
+ } else {
+ err = EPROTO;
+ }
+
pthread_mutex_lock(display-mutex);
- display_fatal_error(display, error);
+
+ display-last_error = err;
+
+ display-protocol_error.code = code;
+ display-protocol_error.id = id;
+ display-protocol_error.interface = intf;
+
+ wl_list_for_each(iter, display-event_queue_list, link)
+ pthread_cond_broadcast(iter-cond);
+
pthread_mutex_unlock(display-mutex);
}
@@ -579,25 +649,12 @@ display_handle_error(void
Re: [PATCH 1/3] tests: add expect_protocol_error function
On Mon, May 26, 2014 at 04:58:05PM +0200, Marek Chalupa wrote:
This function checks if a particular protocol error came in wire.
It's usefull in the cases where we hitherto used FAIL_TEST.
The problem with FAIL_TEST is that *any* assert will pass the test,
but we want only some asserts to pass the test (i. e. we don't
want the test to pass when it, for example, can't connect to display).
FAIL_TESTs are good only for sanity testing.
The expect_protocol_error allows us to turn all FAIL_TESTs to TESTs
as will be introduced in following patches.
---
tests/weston-test-client-helper.c | 49
+++
tests/weston-test-client-helper.h | 4
2 files changed, 53 insertions(+)
diff --git a/tests/weston-test-client-helper.c
b/tests/weston-test-client-helper.c
index 186b395..fb2e477 100644
--- a/tests/weston-test-client-helper.c
+++ b/tests/weston-test-client-helper.c
@@ -26,6 +26,7 @@
#include stdio.h
#include string.h
#include unistd.h
+#include errno.h
#include sys/mman.h
#include ../shared/os-compatibility.h
@@ -512,6 +513,54 @@ skip(const char *fmt, ...)
exit(77);
}
+void
+expect_protocol_error(struct client *client,
+ const struct wl_interface *intf,
+ uint32_t code)
+{
+ int err;
+ uint32_t errcode, failed = 0;
+ const struct wl_interface *interface;
+ unsigned int id;
+
+ /* if the error has not came yet, make it happen */
has not come yet
+ wl_display_roundtrip(client-wl_display);
+
+ err = wl_display_get_error(client-wl_display);
+
+ assert(err Expected protocol error but nothing came);
+ assert(err == EPROTO Expected protocol error but got local error);
+
+
+ errcode = wl_display_get_protocol_error(client-wl_display,
+ interface, id);
+
+ /* check error */
+ if (errcode != code) {
+ fprintf(stderr, Should get error code %d but got %d\n,
+ code, errcode);
+ failed = 1;
+ }
+
+ /* this should be definitely set */
+ assert(interface);
+
+ if (strcmp(intf-name, interface-name) != 0) {
+ fprintf(stderr, Should get interface '%s' but got '%s'\n,
+ intf-name, interface-name);
+ failed = 1;
+ }
+
+ if (failed) {
+ fprintf(stderr, Expected other protocol error\n);
+ abort();
+ }
+
+ /* all OK */
+ fprintf(stderr, Got expected protocol error on '%s' (object id: %d)
+ with code %d\n, interface-name, id, errcode);
+}
+
I think if you move the assert higher, you can condense the logic a
bit. Maybe it's clearer:
/* this should be definitely set */
assert(interface);
if (errcode != code) {
fprintf(stderr, Should get error code %d but got %d\n,
code, errcode);
} else if (strcmp(intf-name, interface-name) != 0) {
fprintf(stderr, Should get interface '%s' but got '%s'\n,
intf-name, interface-name);
} else {
fprintf(stderr, Got expected protocol error on '%s' (object
id: %d)
with code %d\n, interface-name, id, errcode);
return;
}
fprintf(stderr, Expected a different protocol error\n);
abort();
}
I wonder if the final error message is a bit redundant.
static void
log_handler(const char *fmt, va_list args)
{
diff --git a/tests/weston-test-client-helper.h
b/tests/weston-test-client-helper.h
index 4bfc3fa..f154661 100644
--- a/tests/weston-test-client-helper.h
+++ b/tests/weston-test-client-helper.h
@@ -129,4 +129,8 @@ get_n_egl_buffers(struct client *client);
void
skip(const char *fmt, ...);
+void
+expect_protocol_error(struct client *client,
+ const struct wl_interface *intf, uint32_t code);
+
#endif
Reviewed-by: Bryce Harrington b.harring...@samsung.com
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 4/4] Add a function to get the size of a device
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
src/evdev.c | 19 +++
src/evdev.h | 5 +
src/libinput.c | 10 ++
src/libinput.h | 19 +++
tools/event-debug.c | 8 +++-
5 files changed, 60 insertions(+), 1 deletion(-)
diff --git a/src/evdev.c b/src/evdev.c
index 2b2725c..70c232c 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -871,6 +871,25 @@ evdev_device_has_capability(struct evdev_device *device,
}
}
+int
+evdev_device_get_size(struct evdev_device *device,
+ double *width,
+ double *height)
+{
+ const struct input_absinfo *x, *y;
+
+ x = libevdev_get_abs_info(device-evdev, ABS_X);
+ y = libevdev_get_abs_info(device-evdev, ABS_Y);
+
+ if (!x || !y || !x-resolution || !y-resolution)
+ return -1;
+
+ *width = evdev_convert_to_mm(x, x-maximum);
+ *height = evdev_convert_to_mm(y, y-maximum);
+
+ return 0;
+}
+
void
evdev_device_remove(struct evdev_device *device)
{
diff --git a/src/evdev.h b/src/evdev.h
index eebfab1..4a83a78 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -148,6 +148,11 @@ int
evdev_device_has_capability(struct evdev_device *device,
enum libinput_device_capability capability);
+int
+evdev_device_get_size(struct evdev_device *device,
+ double *w,
+ double *h);
+
double
evdev_device_transform_x(struct evdev_device *device,
double x,
diff --git a/src/libinput.c b/src/libinput.c
index f384f43..c4f7fe1 100644
--- a/src/libinput.c
+++ b/src/libinput.c
@@ -1185,6 +1185,16 @@ libinput_device_has_capability(struct libinput_device
*device,
capability);
}
+LIBINPUT_EXPORT int
+libinput_device_get_size(struct libinput_device *device,
+double *width,
+double *height)
+{
+ return evdev_device_get_size((struct evdev_device *)device,
+width,
+height);
+}
+
LIBINPUT_EXPORT struct libinput_event *
libinput_event_device_notify_get_base_event(struct
libinput_event_device_notify *event)
{
diff --git a/src/libinput.h b/src/libinput.h
index c19460b..fe75f87 100644
--- a/src/libinput.h
+++ b/src/libinput.h
@@ -1303,6 +1303,25 @@ int
libinput_device_has_capability(struct libinput_device *device,
enum libinput_device_capability capability);
+/**
+ * @ingroup device
+ *
+ * Get the physical size of a device in mm, where meaningful. This function
+ * only succeeds on devices with the required data, i.e. tablets, touchpads
+ * and touchscreens.
+ *
+ * If this function returns nonzero, width and height are unmodified.
+ *
+ * @param device The device
+ * @param width Set to the width of the device
+ * @param height Set to the height of the device
+ * @return 0 on success, or nonzero otherwise
+ */
+int
+libinput_device_get_size(struct libinput_device *device,
+double *width,
+double *height);
+
#ifdef __cplusplus
}
#endif
diff --git a/tools/event-debug.c b/tools/event-debug.c
index ffb4524..0f0d033 100644
--- a/tools/event-debug.c
+++ b/tools/event-debug.c
@@ -231,10 +231,16 @@ print_device_notify(struct libinput_event *ev)
{
struct libinput_device *dev = libinput_event_get_device(ev);
struct libinput_seat *seat = libinput_device_get_seat(dev);
+ double w, h;
- printf(%s %s\n,
+ printf(%s %s,
libinput_seat_get_physical_name(seat),
libinput_seat_get_logical_name(seat));
+
+ if (libinput_device_get_size(dev, w, h) == 0)
+ printf(\tsize %.2f/%.2fmm, w, h);
+
+ printf(\n);
}
static void
--
1.9.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH libinput 1/4] evdev: keep the absinfo struct around instead of min/max
We'll need that later for conversion to mm.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
src/evdev-mt-touchpad-buttons.c | 20 +---
src/evdev-mt-touchpad.c | 6 --
src/evdev.c | 25 +
src/evdev.h | 2 +-
4 files changed, 31 insertions(+), 22 deletions(-)
diff --git a/src/evdev-mt-touchpad-buttons.c b/src/evdev-mt-touchpad-buttons.c
index ce48ed0..45d5d70 100644
--- a/src/evdev-mt-touchpad-buttons.c
+++ b/src/evdev-mt-touchpad-buttons.c
@@ -565,6 +565,7 @@ tp_init_buttons(struct tp_dispatch *tp,
struct tp_touch *t;
int width, height;
double diagonal;
+ const struct input_absinfo *absinfo_x, *absinfo_y;
tp-buttons.is_clickpad = libevdev_has_property(device-evdev,
INPUT_PROP_BUTTONPAD);
@@ -580,8 +581,11 @@ tp_init_buttons(struct tp_dispatch *tp,
log_bug_kernel(non clickpad without right button?\n);
}
- width = abs(device-abs.max_x - device-abs.min_x);
- height = abs(device-abs.max_y - device-abs.min_y);
+ absinfo_x = device-abs.absinfo_x;
+ absinfo_y = device-abs.absinfo_y;
+
+ width = abs(absinfo_x-maximum - absinfo_x-minimum);
+ height = abs(absinfo_y-maximum - absinfo_y-minimum);
diagonal = sqrt(width*width + height*height);
tp-buttons.motion_dist = diagonal * DEFAULT_BUTTON_MOTION_THRESHOLD;
@@ -590,13 +594,15 @@ tp_init_buttons(struct tp_dispatch *tp,
tp-buttons.use_clickfinger = true;
if (tp-buttons.is_clickpad !tp-buttons.use_clickfinger) {
- tp-buttons.bottom_area.top_edge = height * .8 +
device-abs.min_y;
- tp-buttons.bottom_area.rightbutton_left_edge = width/2 +
device-abs.min_x;
+ int xoffset = absinfo_x-minimum,
+ yoffset = absinfo_y-minimum;
+ tp-buttons.bottom_area.top_edge = height * .8 + yoffset;
+ tp-buttons.bottom_area.rightbutton_left_edge = width/2 +
xoffset;
if (tp-buttons.has_topbuttons) {
- tp-buttons.top_area.bottom_edge = height * .08 +
device-abs.min_y;
- tp-buttons.top_area.rightbutton_left_edge = width *
.58 + device-abs.min_x;
- tp-buttons.top_area.leftbutton_right_edge = width *
.42 + device-abs.min_x;
+ tp-buttons.top_area.bottom_edge = height * .08 +
yoffset;
+ tp-buttons.top_area.rightbutton_left_edge = width *
.58 + xoffset;
+ tp-buttons.top_area.leftbutton_right_edge = width *
.42 + xoffset;
} else {
tp-buttons.top_area.bottom_edge = INT_MIN;
}
diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index 92e0651..787afa4 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -750,8 +750,10 @@ tp_init(struct tp_dispatch *tp,
if (tp_init_slots(tp, device) != 0)
return -1;
- width = abs(device-abs.max_x - device-abs.min_x);
- height = abs(device-abs.max_y - device-abs.min_y);
+ width = abs(device-abs.absinfo_x-maximum -
+ device-abs.absinfo_x-minimum);
+ height = abs(device-abs.absinfo_y-maximum -
+device-abs.absinfo_y-minimum);
diagonal = sqrt(width*width + height*height);
tp-hysteresis.margin_x =
diff --git a/src/evdev.c b/src/evdev.c
index 51ad5e3..907d18e 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -89,13 +89,19 @@ transform_absolute(struct evdev_device *device, int32_t *x,
int32_t *y)
}
}
+static inline double
+scale_axis(const struct input_absinfo *absinfo, double val, double to_range)
+{
+ return (val - absinfo-minimum) * to_range /
+ (absinfo-maximum - absinfo-minimum + 1);
+}
+
double
evdev_device_transform_x(struct evdev_device *device,
double x,
uint32_t width)
{
- return (x - device-abs.min_x) * width /
- (device-abs.max_x - device-abs.min_x + 1);
+ return scale_axis(device-abs.absinfo_x, x, width);
}
double
@@ -103,8 +109,7 @@ evdev_device_transform_y(struct evdev_device *device,
double y,
uint32_t height)
{
- return (y - device-abs.min_y) * height /
- (device-abs.max_y - device-abs.min_y + 1);
+ return scale_axis(device-abs.absinfo_y, y, height);
}
static void
@@ -606,13 +611,11 @@ evdev_configure_device(struct evdev_device *device)
if (libevdev_has_event_type(evdev, EV_ABS)) {
if ((absinfo = libevdev_get_abs_info(evdev, ABS_X))) {
- device-abs.min_x = absinfo-minimum;
- device-abs.max_x = absinfo-maximum;
+ device-abs.absinfo_x =
[PATCH libinput v2 3/3] Change the logging system to be per-context
Rather than a single global logging function, make the logging dependent on
the individual context. This way we won't stomp on each other's feet in the
(admittedly unusual) case of having multiple libinput contexts.
The userdata argument to the log handler was dropped. The caller has a ref to
the libinput context now, any userdata can be attached to that context
instead.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
src/evdev-mt-touchpad-buttons.c | 15 +--
src/evdev-mt-touchpad-tap.c | 13 --
src/evdev.c | 23 +++
src/libinput-private.h | 23 +++
src/libinput.c | 48 ++
src/libinput.h | 19 +
src/path.c | 20 +++---
src/timer.c | 4 +-
src/udev-seat.c | 17
test/litest.c | 13 --
test/log.c | 88 +++--
tools/event-debug.c | 33 +---
12 files changed, 161 insertions(+), 155 deletions(-)
diff --git a/src/evdev-mt-touchpad-buttons.c b/src/evdev-mt-touchpad-buttons.c
index ce48ed0..b86f344 100644
--- a/src/evdev-mt-touchpad-buttons.c
+++ b/src/evdev-mt-touchpad-buttons.c
@@ -452,6 +452,7 @@ tp_button_handle_event(struct tp_dispatch *tp,
enum button_event event,
uint64_t time)
{
+ struct libinput *libinput = tp-device-base.seat-libinput;
enum button_state current = t-button.state;
switch(t-button.state) {
@@ -485,7 +486,8 @@ tp_button_handle_event(struct tp_dispatch *tp,
}
if (current != t-button.state)
- log_debug(button state: from %s, event %s to %s\n,
+ log_debug(libinput,
+ button state: from %s, event %s to %s\n,
button_state_to_str(current),
button_event_to_str(event),
button_state_to_str(t-button.state));
@@ -538,11 +540,13 @@ tp_process_button(struct tp_dispatch *tp,
const struct input_event *e,
uint64_t time)
{
+ struct libinput *libinput = tp-device-base.seat-libinput;
uint32_t mask = 1 (e-code - BTN_LEFT);
/* Ignore other buttons on clickpads */
if (tp-buttons.is_clickpad e-code != BTN_LEFT) {
- log_bug_kernel(received %s button event on a clickpad\n,
+ log_bug_kernel(libinput,
+ received %s button event on a clickpad\n,
libevdev_event_code_get_name(EV_KEY, e-code));
return 0;
}
@@ -562,6 +566,7 @@ int
tp_init_buttons(struct tp_dispatch *tp,
struct evdev_device *device)
{
+ struct libinput *libinput = tp-device-base.seat-libinput;
struct tp_touch *t;
int width, height;
double diagonal;
@@ -574,10 +579,12 @@ tp_init_buttons(struct tp_dispatch *tp,
if (libevdev_has_event_code(device-evdev, EV_KEY, BTN_MIDDLE) ||
libevdev_has_event_code(device-evdev, EV_KEY, BTN_RIGHT)) {
if (tp-buttons.is_clickpad)
- log_bug_kernel(clickpad advertising right button\n);
+ log_bug_kernel(libinput,
+ clickpad advertising right button\n);
} else {
if (!tp-buttons.is_clickpad)
- log_bug_kernel(non clickpad without right button?\n);
+ log_bug_kernel(libinput,
+ non clickpad without right button?\n);
}
width = abs(device-abs.max_x - device-abs.min_x);
diff --git a/src/evdev-mt-touchpad-tap.c b/src/evdev-mt-touchpad-tap.c
index 34bb0d0..2541218 100644
--- a/src/evdev-mt-touchpad-tap.c
+++ b/src/evdev-mt-touchpad-tap.c
@@ -130,6 +130,7 @@ tp_tap_clear_timer(struct tp_dispatch *tp)
static void
tp_tap_idle_handle_event(struct tp_dispatch *tp, enum tap_event event,
uint64_t time)
{
+ struct libinput *libinput = tp-device-base.seat-libinput;
switch (event) {
case TAP_EVENT_TOUCH:
@@ -138,7 +139,8 @@ tp_tap_idle_handle_event(struct tp_dispatch *tp, enum
tap_event event, uint64_t
break;
case TAP_EVENT_RELEASE:
case TAP_EVENT_MOTION:
- log_bug_libinput(invalid event, no fingers are down\n);
+ log_bug_libinput(libinput,
+invalid event, no fingers are down\n);
break;
case TAP_EVENT_TIMEOUT:
break;
@@ -197,11 +199,13 @@ tp_tap_hold_handle_event(struct tp_dispatch *tp, enum
tap_event event, uint64_t
static void
tp_tap_tapped_handle_event(struct tp_dispatch *tp, enum tap_event event,
uint64_t time)
{
+ struct libinput *libinput = tp-device-base.seat-libinput;
switch (event) {
[PATCH libinput 1/4] evdev: Continue updating axes internally when tool leaves proximity
Axis changes are now still processed by libinput regardless of whether or not
the tool is in proximity, however we refrain from reporting them unless the tool
is in proximity. This stops bad distance events from being reported without
needing a huge mess of conditional statements in sanitize_axes(). The tool is
now counted as back in proximity when a tool update is received instead of when
an axis update is received.
Signed-off-by: Stephen Chandler Paul thatsly...@gmail.com
---
src/evdev-tablet.c | 67 +++---
src/evdev-tablet.h | 9
2 files changed, 33 insertions(+), 43 deletions(-)
diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
index bde3b47..760b954 100644
--- a/src/evdev-tablet.c
+++ b/src/evdev-tablet.c
@@ -50,9 +50,6 @@ tablet_process_absolute(struct tablet_dispatch *tablet,
case ABS_PRESSURE:
case ABS_TILT_X:
case ABS_TILT_Y:
- tablet_unset_status(tablet, TABLET_TOOL_OUT_OF_PROXIMITY);
-
- /* Fall through */
case ABS_DISTANCE:
axis = evcode_to_axis(e-code);
if (axis == LIBINPUT_TABLET_AXIS_NONE) {
@@ -77,12 +74,15 @@ tablet_update_tool(struct tablet_dispatch *tablet,
{
assert(tool != LIBINPUT_TOOL_NONE);
- if (enabled tool != tablet-current_tool_type) {
- tablet-current_tool_type = tool;
- tablet_set_status(tablet, TABLET_TOOL_UPDATED);
+ if (enabled) {
+ if (tool != tablet-current_tool_type) {
+ tablet-current_tool_type = tool;
+ tablet_set_status(tablet, TABLET_TOOL_UPDATED);
+ }
+ tablet_unset_status(tablet, TABLET_TOOL_OUT_OF_PROXIMITY);
}
- else if (!enabled)
- tablet_set_status(tablet, TABLET_TOOL_LEAVING_PROXIMITY);
+ else
+ tablet_set_status(tablet, TABLET_TOOL_OUT_OF_PROXIMITY);
}
static inline double
@@ -141,10 +141,14 @@ tablet_check_notify_axes(struct tablet_dispatch *tablet,
axis_update_needed = true;
}
- if (axis_update_needed) {
- tablet_notify_axis(base, time, tablet-changed_axes,
tablet-axes);
- memset(tablet-changed_axes, 0, sizeof(tablet-changed_axes));
- }
+ if (axis_update_needed
+ !tablet_has_status(tablet, TABLET_TOOL_OUT_OF_PROXIMITY))
+ tablet_notify_axis(base,
+ time,
+ tablet-changed_axes,
+ tablet-axes);
+
+ memset(tablet-changed_axes, 0, sizeof(tablet-changed_axes));
}
static void
@@ -223,6 +227,8 @@ tablet_process_misc(struct tablet_dispatch *tablet,
e-value != -1) {
tablet-current_tool_serial = e-value;
tablet_set_status(tablet, TABLET_TOOL_UPDATED);
+ tablet_unset_status(tablet,
+ TABLET_TOOL_OUT_OF_PROXIMITY);
}
break;
default:
@@ -334,11 +340,8 @@ sanitize_tablet_axes(struct tablet_dispatch *tablet)
* properly
*/
if (bit_is_set(tablet-changed_axes, LIBINPUT_TABLET_AXIS_DISTANCE)
- ((distance-value distance-minimum
- pressure-value pressure-minimum) ||
-(tablet_has_status(tablet, TABLET_TOOL_OUT_OF_PROXIMITY)
- (distance-value = distance-minimum ||
- distance-value = distance-maximum {
+ distance-value distance-minimum
+ pressure-value pressure-minimum) {
clear_bit(tablet-changed_axes, LIBINPUT_TABLET_AXIS_DISTANCE);
tablet-axes[LIBINPUT_TABLET_AXIS_DISTANCE] = 0;
} else if (bit_is_set(tablet-changed_axes,
LIBINPUT_TABLET_AXIS_PRESSURE)
@@ -357,28 +360,19 @@ tablet_flush(struct tablet_dispatch *tablet,
struct evdev_device *device,
uint32_t time)
{
- if (tablet_has_status(tablet, TABLET_TOOL_LEAVING_PROXIMITY)) {
+ if (tablet_has_status(tablet, TABLET_TOOL_OUT_OF_PROXIMITY)) {
/* Release all stylus buttons */
tablet-button_state.stylus_buttons = 0;
tablet_set_status(tablet, TABLET_BUTTONS_RELEASED);
+ } else if (tablet_has_status(tablet, TABLET_TOOL_UPDATED)) {
+ tablet_notify_tool(tablet, device, time);
+ tablet_unset_status(tablet, TABLET_TOOL_UPDATED);
+ }
- /* FIXME: This behavior is not ideal and this memset should be
-* removed */
- memset(tablet-changed_axes, 0, sizeof(tablet-changed_axes));
- memset(tablet-axes, 0, sizeof(tablet-axes));
-
+ if (tablet_has_status(tablet, TABLET_AXES_UPDATED)) {
+ sanitize_tablet_axes(tablet);
+ tablet_check_notify_axes(tablet, device, time);
[PATCH libinput 4/4] test: Add tests for serial numbers on tools
These tests make sure that any tablets with the capability to report a tool's
serial number do so properly, that the tool changes when another tool of the
same type with a different serial number is used, and that libinput doesn't
change the current tool when -1 is reported as the serial number (-1 is used for
special purposes by the linuxwacom driver).
Signed-off-by: Stephen Chandler Paul thatsly...@gmail.com
---
test/litest-wacom-cintiq-tablet.c | 2 +-
test/litest-wacom-intuos-tablet.c | 2 +-
test/litest.h | 1 +
test/tablet.c | 113 ++
4 files changed, 116 insertions(+), 2 deletions(-)
diff --git a/test/litest-wacom-cintiq-tablet.c
b/test/litest-wacom-cintiq-tablet.c
index 93cd2a8..0217f56 100644
--- a/test/litest-wacom-cintiq-tablet.c
+++ b/test/litest-wacom-cintiq-tablet.c
@@ -125,7 +125,7 @@ static int events[] = {
struct litest_test_device litest_wacom_cintiq_tablet_device = {
.type = LITEST_WACOM_CINTIQ,
- .features = LITEST_TABLET | LITEST_DISTANCE,
+ .features = LITEST_TABLET | LITEST_DISTANCE | LITEST_TOOL_SERIAL,
.shortname = wacom-cintiq-tablet,
.setup = litest_wacom_cintiq_tablet_setup,
.interface = interface,
diff --git a/test/litest-wacom-intuos-tablet.c
b/test/litest-wacom-intuos-tablet.c
index 0cbb632..e30d606 100644
--- a/test/litest-wacom-intuos-tablet.c
+++ b/test/litest-wacom-intuos-tablet.c
@@ -123,7 +123,7 @@ static int events[] = {
struct litest_test_device litest_wacom_intuos_tablet_device = {
.type = LITEST_WACOM_INTUOS,
- .features = LITEST_TABLET | LITEST_DISTANCE,
+ .features = LITEST_TABLET | LITEST_DISTANCE | LITEST_TOOL_SERIAL,
.shortname = wacom-intuos-tablet,
.setup = litest_wacom_intuos_tablet_setup,
.interface = interface,
diff --git a/test/litest.h b/test/litest.h
index 5904805..9e159a3 100644
--- a/test/litest.h
+++ b/test/litest.h
@@ -64,6 +64,7 @@ enum litest_device_feature {
LITEST_TOPBUTTONPAD = 1 9,
LITEST_TABLET = 1 10,
LITEST_DISTANCE = 1 11,
+ LITEST_TOOL_SERIAL = 1 12,
};
struct litest_device {
diff --git a/test/tablet.c b/test/tablet.c
index 1121914..3bfbb6a 100644
--- a/test/tablet.c
+++ b/test/tablet.c
@@ -427,9 +427,122 @@ START_TEST(normalization)
}
END_TEST
+START_TEST(tool_serial)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput *li = dev-libinput;
+ struct libinput_event_tablet *tablet_event;
+ struct libinput_event *event;
+ struct libinput_tool *tool;
+
+ litest_drain_events(li);
+
+ litest_event(dev, EV_KEY, BTN_TOOL_PEN, 1);
+ litest_event(dev, EV_MSC, MSC_SERIAL, 1000);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+
+ libinput_dispatch(li);
+ while ((event = libinput_get_event(li))) {
+ if (libinput_event_get_type(event) ==
+ LIBINPUT_EVENT_TABLET_TOOL_UPDATE) {
+ tablet_event = libinput_event_get_tablet_event(event);
+ tool = libinput_event_tablet_get_tool(tablet_event);
+
+ ck_assert_uint_eq(libinput_tool_get_serial(tool), 1000);
+ }
+
+ libinput_event_destroy(event);
+ }
+}
+END_TEST
+
+START_TEST(serial_changes_tool)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput *li = dev-libinput;
+ struct libinput_event_tablet *tablet_event;
+ struct libinput_event *event;
+ struct libinput_tool *tool;
+ bool tool_updated = false;
+
+ litest_drain_events(li);
+
+ litest_event(dev, EV_KEY, BTN_TOOL_PEN, 1);
+ litest_event(dev, EV_MSC, MSC_SERIAL, 1000);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+
+ litest_drain_events(li);
+
+ litest_event(dev, EV_MSC, MSC_SERIAL, 2000);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+
+ libinput_dispatch(li);
+ while ((event = libinput_get_event(li))) {
+ if (libinput_event_get_type(event) ==
+ LIBINPUT_EVENT_TABLET_TOOL_UPDATE) {
+ tablet_event = libinput_event_get_tablet_event(event);
+ tool = libinput_event_tablet_get_tool(tablet_event);
+
+ ck_assert_uint_eq(libinput_tool_get_serial(tool), 2000);
+ tool_updated = true;
+ }
+
+ libinput_event_destroy(event);
+ }
+ ck_assert(tool_updated);
+}
+END_TEST
+
+START_TEST(invalid_serials)
+{
+ struct litest_device *dev = litest_current_device();
+ struct libinput *li = dev-libinput;
+ struct libinput_event *event;
+ bool tool_updated = false;
+
+ litest_drain_events(li);
+
+ litest_event(dev, EV_KEY, BTN_TOOL_PEN, 1);
+ litest_event(dev, EV_MSC, MSC_SERIAL, 1000);
+ litest_event(dev, EV_SYN, SYN_REPORT, 0);
+
[PATCH libinput 2/4] evdev: Add tablet_mark_all_axes_changed()
Occasionally all the axes that are valid for a device need to be marked as
updated for the caller's sake.
Signed-off-by: Stephen Chandler Paul thatsly...@gmail.com
---
src/evdev-tablet.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
index 760b954..52499fd 100644
--- a/src/evdev-tablet.c
+++ b/src/evdev-tablet.c
@@ -68,6 +68,22 @@ tablet_process_absolute(struct tablet_dispatch *tablet,
}
static void
+tablet_mark_all_axes_changed(struct tablet_dispatch *tablet,
+struct evdev_device *device)
+{
+ enum libinput_tablet_axis a;
+
+ for (a = 0; a LIBINPUT_TABLET_AXIS_CNT; a++) {
+ if (libevdev_has_event_code(device-evdev,
+ EV_ABS,
+ axis_to_evcode(a)))
+ set_bit(tablet-changed_axes, a);
+ }
+
+ tablet_set_status(tablet, TABLET_AXES_UPDATED);
+}
+
+static void
tablet_update_tool(struct tablet_dispatch *tablet,
enum libinput_tool_type tool,
bool enabled)
@@ -444,20 +460,12 @@ static int
tablet_init(struct tablet_dispatch *tablet,
struct evdev_device *device)
{
- enum libinput_tablet_axis a;
-
tablet-base.interface = tablet_interface;
tablet-device = device;
tablet-status = TABLET_NONE;
tablet-current_tool_type = LIBINPUT_TOOL_NONE;
- /* Mark any axes the tablet has as changed */
- for (a = 0; a LIBINPUT_TABLET_AXIS_CNT; a++) {
- if (libevdev_has_event_code(device-evdev,
- EV_ABS,
- axis_to_evcode(a)))
- set_bit(tablet-changed_axes, a);
- }
+ tablet_mark_all_axes_changed(tablet, device);
return 0;
}
--
1.8.5.5
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
