Re: [PATCH libinput 1/2] Change the scroll step distance to 15 and document it as degrees
On Mon, Jan 12, 2015 at 09:37:05AM +0800, Jonas Ådahl wrote:
> On Mon, Jan 12, 2015 at 09:12:35AM +1000, Peter Hutterer wrote:
> > Similar to the mouse resolution, let's make the scroll distance a sensible
> > predictable value. Most mice use a 15 degree angle per scroll click, so
> > let's
> > change to that. This will alter behaviour in clients that expect 10 but it
> > shouldn't be too bad. We return doubles anyway for the axis value, so that
> > leaves the option of really fine-grained step sizes.
>
> This is not entirely true, as a few clients use the '10' value to
> convert to steps. In other words this change may cause them to
> potentially emit double scroll events. We need to make weston (and other
> users) not break compatibility with Wayland clients by, as discussed, for
> now ignoring the degrees and continue sending the distance based value
> for wheel events.
>
> Other than this, one nit below, and with that fixed,
>
> Reviewed-by: Jonas Ådahl
>
>
> Jonas
>
> >
> > We currently assume all mice have 15 degree angles. Like the DPI settings,
> > it
> > will require a udev property to be set. Patch for that to follow.
> >
> > Signed-off-by: Peter Hutterer
> > ---
> > src/evdev.c| 2 +-
> > src/libinput.h | 8
> > test/pointer.c | 4 ++--
> > 3 files changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/src/evdev.c b/src/evdev.c
> > index 1718491..4fb37d6 100644
> > --- a/src/evdev.c
> > +++ b/src/evdev.c
> > @@ -40,7 +40,7 @@
> > #include "filter.h"
> > #include "libinput-private.h"
> >
> > -#define DEFAULT_AXIS_STEP_DISTANCE 10
> > +#define DEFAULT_AXIS_STEP_DISTANCE 15
>
> This is no longer a distance, as the value is changed from distance to
> angle.
renamed to DEFAULT_WHEEL_CLICK_ANGLE and a slight edit to the commit
message, thanks.
Cheers,
Peter
>
> > #define DEFAULT_MIDDLE_BUTTON_SCROLL_TIMEOUT 200
> >
> > enum evdev_key_type {
> > diff --git a/src/libinput.h b/src/libinput.h
> > index 27c5868..95a5c1d 100644
> > --- a/src/libinput.h
> > +++ b/src/libinput.h
> > @@ -704,10 +704,10 @@ libinput_event_pointer_get_axis_value(struct
> > libinput_event_pointer *event);
> > *
> > * If the source is @ref LIBINPUT_POINTER_AXIS_SOURCE_WHEEL, no terminating
> > * event is guaranteed (though it may happen).
> > - * Scrolling is in discrete steps, a value of 10 representing one click
> > - * of a typical mouse wheel. Some mice may have differently grained wheels,
> > - * libinput will adjust the value accordingly. It is up to the caller how
> > to
> > - * interpret such different step sizes.
> > + * Scrolling is in discrete steps, the value is the angle the wheel moved
> > + * in degrees. The default is 15 degrees per wheel click, but some mice may
> > + * have differently grained wheels. It is up to the caller how to interpret
> > + * such different step sizes.
> > *
> > * If the source is @ref LIBINPUT_POINTER_AXIS_SOURCE_CONTINUOUS, no
> > * terminating event is guaranteed (though it may happen).
> > diff --git a/test/pointer.c b/test/pointer.c
> > index b9bd3cc..d12c9f6 100644
> > --- a/test/pointer.c
> > +++ b/test/pointer.c
> > @@ -350,8 +350,8 @@ test_wheel_event(struct litest_device *dev, int which,
> > int amount)
> > struct libinput_event_pointer *ptrev;
> >
> > /* the current evdev implementation scales the scroll wheel events
> > - up by a factor 10 */
>
>
>
> > - const int scroll_step = 10;
> > + up by a factor 15 */
> > + const int scroll_step = 15;
> > int expected = amount * scroll_step;
> >
> > if
> > (libinput_device_config_scroll_get_natural_scroll_enabled(dev->libinput_device))
> > --
> > 2.1.0
> >
> > ___
> > 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 v2 libinput] Change axis events to carry all directions
On Fri, Jan 09, 2015 at 01:05:53PM +0100, Hans de Goede wrote:
> Hi,
>
> On 07-01-15 02:33, Peter Hutterer wrote:
> >Sending separate axis events instead of one unified events is limiting,
> >especially when simultaneously scrolling in both directions and the caller
> >tries to implement kinetic scrolling.
> >
> >Take a page from the tablet-support branch and instead implement the axis
> >event as a generic event that can contain multiple axes simultaneously.
> >
> >Right now we only have two (scroll) axes and we could easily just check both
> >for non-zero values. If we want to allow further axes in the future, we need
> >a check whether an axis is set in an event, that's what
> >libinput_event_pointer_has_axis to scroll events() is for.
> >
> >We also need the mask to notify of a scroll stop event, which could otherwise
> >be confused as a vertical-only or horizontal-only event.
> >
> >This is an API and ABI break.
> >
> >Signed-off-by: Peter Hutterer
> >---
> >I think I addressed the comments but I'm not 100% sure. Squashed both patches
> >now together to make it easier this time.
> >
> >Changes to v1:
> >- use AS_MASK in edge scrolling
> >- libinput_event_pointer_get_axis_value() checks for the bit being set and
> > logs a client bug
> >- added early bail out if edge scrolling deltas for the direction we want
> >are 0
> >- use !!(axes & mask) as return value for libinput_event_pointer_has_axis()
> > to avoid leaking mask values
>
> See (minor) comments inline.
[...]
all fixed as requested, thanks. And I added the libinput.sym bits for
has_axis as well.
Cheers,
Peter
>
> >
> > src/evdev-mt-touchpad-edge-scroll.c | 27 ++--
> > src/evdev.c | 62
> > ++---
> > src/libinput-private.h | 4 +--
> > src/libinput-util.h | 1 +
> > src/libinput.c | 47 +---
> > src/libinput.h | 22 +++--
> > test/litest.c | 19 ++--
> > test/pointer.c | 11 ---
> > test/touchpad.c | 16 +-
> > tools/event-debug.c | 22 -
> > tools/event-gui.c | 18 +--
> > 11 files changed, 141 insertions(+), 108 deletions(-)
> >
> >diff --git a/src/evdev-mt-touchpad-edge-scroll.c
> >b/src/evdev-mt-touchpad-edge-scroll.c
> >index a4dc093..093cd5d 100644
> >--- a/src/evdev-mt-touchpad-edge-scroll.c
> >+++ b/src/evdev-mt-touchpad-edge-scroll.c
> >@@ -314,7 +314,7 @@ tp_edge_scroll_post_events(struct tp_dispatch *tp,
> >uint64_t time)
> > struct libinput_device *device = &tp->device->base;
> > struct tp_touch *t;
> > enum libinput_pointer_axis axis;
> >-double dx, dy, *delta;
> >+double dx, dy;
> >
> > tp_for_each_touch(tp, t) {
> > if (!t->dirty)
> >@@ -325,19 +325,17 @@ tp_edge_scroll_post_events(struct tp_dispatch *tp,
> >uint64_t time)
> > if (t->scroll.direction != -1) {
> > /* Send stop scroll event */
> > pointer_notify_axis(device, time,
> >-t->scroll.direction,
> >+AS_MASK(t->scroll.direction),
> >
> > LIBINPUT_POINTER_AXIS_SOURCE_FINGER,
> >-0.0);
> >+0.0, 0.0);
> > t->scroll.direction = -1;
> > }
> > continue;
> > case EDGE_RIGHT:
> > axis = LIBINPUT_POINTER_AXIS_SCROLL_VERTICAL;
> >-delta = &dy;
> > break;
> > case EDGE_BOTTOM:
> > axis = LIBINPUT_POINTER_AXIS_SCROLL_HORIZONTAL;
> >-delta = &dx;
> > break;
> > default: /* EDGE_RIGHT | EDGE_BOTTOM */
> > continue; /* Don't know direction yet, skip */
> >@@ -346,12 +344,21 @@ tp_edge_scroll_post_events(struct tp_dispatch *tp,
> >uint64_t time)
> > tp_get_delta(t, &dx, &dy);
> > tp_filter_motion(tp, &dx, &dy, NULL, NULL, time);
> >
> >-if (fabs(*delta) < t->scroll.threshold)
> >+if (fabs(dx) < t->scroll.threshold)
> >+dx = 0.0;
> >+if (fabs(dy) < t->scroll.threshold)
> >+dy = 0.0;
> >+
> >+if ((dx == 0.0 &&
> >+ axis == LIBINPUT_POINTER_AXIS_SCROLL_HORIZONTAL) ||
> >+(dy == 0.0 &&
> >+ axis == LIBINPUT_POINTER_AXIS_SCROLL_VERTICAL))
> > continue;
> >
>
> Why not simply keep the delta pointer and
Re: [PATCH libinput 2/2] Parse the MOUSE_WHEEL_CLICK_ANGLE udev property if present
On Mon, Jan 12, 2015 at 09:12:36AM +1000, Peter Hutterer wrote:
> Signed-off-by: Peter Hutterer
Reviewed-by: Jonas Ådahl
> ---
> doc/device-configuration-via-udev.dox | 4
> src/evdev.c | 29 +++--
> src/evdev.h | 3 +++
> src/libinput-util.c | 30 ++
> src/libinput-util.h | 1 +
> test/misc.c | 34 --
> 6 files changed, 97 insertions(+), 4 deletions(-)
>
> diff --git a/doc/device-configuration-via-udev.dox
> b/doc/device-configuration-via-udev.dox
> index b854035..bee3659 100644
> --- a/doc/device-configuration-via-udev.dox
> +++ b/doc/device-configuration-via-udev.dox
> @@ -23,6 +23,10 @@ context. Defaults to "default".
> HW resolution and sampling frequency of a relative pointer device.
> See @ref motion_normalization for details.
>
> +MOUSE_WHEEL_CLICK_ANGLE
> +The angle in degrees for each click on a mouse wheel. See
> +libinput_pointer_get_axis_source() for details.
> +
>
>
> Below is an example udev rule to assign "seat1" to a device from vendor
> diff --git a/src/evdev.c b/src/evdev.c
> index 4fb37d6..f35ee34 100644
> --- a/src/evdev.c
> +++ b/src/evdev.c
> @@ -577,7 +577,7 @@ evdev_process_relative(struct evdev_device *device,
> time,
> LIBINPUT_POINTER_AXIS_SCROLL_VERTICAL,
> LIBINPUT_POINTER_AXIS_SOURCE_WHEEL,
> - -1 * e->value * DEFAULT_AXIS_STEP_DISTANCE);
> + -1 * e->value * device->scroll.wheel_click_angle);
> break;
> case REL_HWHEEL:
> evdev_flush_pending_event(device, time);
> @@ -586,7 +586,7 @@ evdev_process_relative(struct evdev_device *device,
> time,
> LIBINPUT_POINTER_AXIS_SCROLL_HORIZONTAL,
> LIBINPUT_POINTER_AXIS_SOURCE_WHEEL,
> - e->value * DEFAULT_AXIS_STEP_DISTANCE);
> + e->value * device->scroll.wheel_click_angle);
> break;
> }
> }
> @@ -1240,6 +1240,29 @@ evdev_tag_device(struct evdev_device *device)
> }
>
> static inline int
> +evdev_read_wheel_click_prop(struct evdev_device *device)
> +{
> + struct libinput *libinput = device->base.seat->libinput;
> + const char *prop;
> + int angle = DEFAULT_AXIS_STEP_DISTANCE;
> +
> + prop = udev_device_get_property_value(device->udev_device,
> + "MOUSE_WHEEL_CLICK_ANGLE");
> + if (prop) {
> + angle = parse_mouse_wheel_click_angle_property(prop);
> + if (!angle) {
> + log_error(libinput,
> + "Mouse wheel click angle '%s' is present but
> invalid,"
> + "using %d degrees instead\n",
> + device->devname,
> + DEFAULT_AXIS_STEP_DISTANCE);
> + angle = DEFAULT_AXIS_STEP_DISTANCE;
> + }
> + }
> +
> + return angle;
> +}
> +static inline int
> evdev_read_dpi_prop(struct evdev_device *device)
> {
> struct libinput *libinput = device->base.seat->libinput;
> @@ -1568,6 +1591,8 @@ evdev_device_create(struct libinput_seat *seat,
> device->devname = libevdev_get_name(device->evdev);
> device->scroll.threshold = 5.0; /* Default may be overridden */
> device->scroll.direction = 0;
> + device->scroll.wheel_click_angle =
> + evdev_read_wheel_click_prop(device);
> device->dpi = evdev_read_dpi_prop(device);
> /* at most 5 SYN_DROPPED log-messages per 30s */
> ratelimit_init(&device->syn_drop_limit, 30ULL * 1000, 5);
> diff --git a/src/evdev.h b/src/evdev.h
> index a75dd13..2171c5a 100644
> --- a/src/evdev.h
> +++ b/src/evdev.h
> @@ -119,6 +119,9 @@ struct evdev_device {
> /* set during device init if we want natural scrolling,
>* used at runtime to enable/disable the feature */
> bool natural_scrolling_enabled;
> +
> + /* angle per REL_WHEEL click in degrees */
> + int wheel_click_angle;
> } scroll;
>
> enum evdev_event_type pending_event;
> diff --git a/src/libinput-util.c b/src/libinput-util.c
> index c16de1b..49e297a 100644
> --- a/src/libinput-util.c
> +++ b/src/libinput-util.c
> @@ -171,3 +171,33 @@ parse_mouse_dpi_property(const char *prop)
> }
> return dpi;
> }
> +
> +/**
> + * Helper function to parse the MOUSE_WHEEL_CLICK_ANGLE property from udev.
> + * Property is of the form:
> + * MOUSE_WHEEL_CLICK_ANGLE=
> + * Where the number indicates the degrees travelled for each click.
> + *
> + * We skip preceding whitespaces and parse the first number seen. If
> + * multiple numbers are specified, we ignore those.
> + *
> + * @param prop The value of the udev
Re: [PATCH libinput 1/2] Change the scroll step distance to 15 and document it as degrees
On Mon, Jan 12, 2015 at 09:12:35AM +1000, Peter Hutterer wrote:
> Similar to the mouse resolution, let's make the scroll distance a sensible
> predictable value. Most mice use a 15 degree angle per scroll click, so let's
> change to that. This will alter behaviour in clients that expect 10 but it
> shouldn't be too bad. We return doubles anyway for the axis value, so that
> leaves the option of really fine-grained step sizes.
This is not entirely true, as a few clients use the '10' value to
convert to steps. In other words this change may cause them to
potentially emit double scroll events. We need to make weston (and other
users) not break compatibility with Wayland clients by, as discussed, for
now ignoring the degrees and continue sending the distance based value
for wheel events.
Other than this, one nit below, and with that fixed,
Reviewed-by: Jonas Ådahl
Jonas
>
> We currently assume all mice have 15 degree angles. Like the DPI settings, it
> will require a udev property to be set. Patch for that to follow.
>
> Signed-off-by: Peter Hutterer
> ---
> src/evdev.c| 2 +-
> src/libinput.h | 8
> test/pointer.c | 4 ++--
> 3 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/src/evdev.c b/src/evdev.c
> index 1718491..4fb37d6 100644
> --- a/src/evdev.c
> +++ b/src/evdev.c
> @@ -40,7 +40,7 @@
> #include "filter.h"
> #include "libinput-private.h"
>
> -#define DEFAULT_AXIS_STEP_DISTANCE 10
> +#define DEFAULT_AXIS_STEP_DISTANCE 15
This is no longer a distance, as the value is changed from distance to
angle.
> #define DEFAULT_MIDDLE_BUTTON_SCROLL_TIMEOUT 200
>
> enum evdev_key_type {
> diff --git a/src/libinput.h b/src/libinput.h
> index 27c5868..95a5c1d 100644
> --- a/src/libinput.h
> +++ b/src/libinput.h
> @@ -704,10 +704,10 @@ libinput_event_pointer_get_axis_value(struct
> libinput_event_pointer *event);
> *
> * If the source is @ref LIBINPUT_POINTER_AXIS_SOURCE_WHEEL, no terminating
> * event is guaranteed (though it may happen).
> - * Scrolling is in discrete steps, a value of 10 representing one click
> - * of a typical mouse wheel. Some mice may have differently grained wheels,
> - * libinput will adjust the value accordingly. It is up to the caller how to
> - * interpret such different step sizes.
> + * Scrolling is in discrete steps, the value is the angle the wheel moved
> + * in degrees. The default is 15 degrees per wheel click, but some mice may
> + * have differently grained wheels. It is up to the caller how to interpret
> + * such different step sizes.
> *
> * If the source is @ref LIBINPUT_POINTER_AXIS_SOURCE_CONTINUOUS, no
> * terminating event is guaranteed (though it may happen).
> diff --git a/test/pointer.c b/test/pointer.c
> index b9bd3cc..d12c9f6 100644
> --- a/test/pointer.c
> +++ b/test/pointer.c
> @@ -350,8 +350,8 @@ test_wheel_event(struct litest_device *dev, int which,
> int amount)
> struct libinput_event_pointer *ptrev;
>
> /* the current evdev implementation scales the scroll wheel events
> -up by a factor 10 */
> - const int scroll_step = 10;
> +up by a factor 15 */
> + const int scroll_step = 15;
> int expected = amount * scroll_step;
>
> if
> (libinput_device_config_scroll_get_natural_scroll_enabled(dev->libinput_device))
> --
> 2.1.0
>
> ___
> 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 "Back", "Forward", and other special mouse buttons in the X11 compositor.
Looks like this patch got discarded (according to patchwork)?
This one is different from http://patchwork.freedesktop.org/patch/39499/.
That one fixed the Wayland->X11 key code translation; this one fixes
X11->Wayland.
On Dec 22, 2014 11:51 AM, "Dima Ryazanov" wrote:
> They're off by 4 because of the scroll buttons.
>
> (However, if you test them in XWayland, they'll appear to work because
> XWayland has the same bug; see
> http://lists.x.org/archives/xorg-devel/2014-December/044987.html)
>
> Signed-off-by: Dima Ryazanov
> ---
> src/compositor-x11.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/src/compositor-x11.c b/src/compositor-x11.c
> index 29f2119..af9de6f 100644
> --- a/src/compositor-x11.c
> +++ b/src/compositor-x11.c
> @@ -1015,7 +1015,10 @@ x11_compositor_deliver_button_event(struct
> x11_compositor *c,
>
> switch (button_event->detail) {
> default:
> - button = button_event->detail + BTN_LEFT - 1;
> + button = button_event->detail + BTN_SIDE - 8;
> + break;
> + case 1:
> + button = BTN_LEFT;
> break;
> case 2:
> button = BTN_MIDDLE;
> --
> 2.1.0
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v1] Added touch support to wayland backend
On Wed, Dec 17, 2014 at 04:11:56PM +0200, Imran Zaman wrote:
> Nested westons (with wayland backend as child weston) is one possible
> use case for the needed touch support.
>
> Signed-off-by: Imran Zaman
Have a look at these patches:
http://lists.freedesktop.org/archives/wayland-devel/2014-May/014648.html
they seem to address the same thing but do a bit more, and Jason had a few
comments on them. I suspect the same comments still apply.
(bug ref is https://bugs.freedesktop.org/show_bug.cgi?id=77769)
Cheers,
Peter
> ---
> src/compositor-wayland.c | 59
>
> 1 file changed, 59 insertions(+)
>
> diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
> index 65bce39..f125210 100644
> --- a/src/compositor-wayland.c
> +++ b/src/compositor-wayland.c
> @@ -1581,6 +1581,53 @@ static const struct wl_keyboard_listener
> keyboard_listener = {
> };
>
> static void
> +input_handle_touch_down(void *data, struct wl_touch *wl_touch,
> + uint32_t serial, uint32_t time,
> + struct wl_surface *surface, int32_t id, wl_fixed_t x_w,
> + wl_fixed_t y_w)
> +{
> + struct wayland_input *input = data;
> + notify_touch(&input->base, time, id, x_w, y_w, WL_TOUCH_DOWN);
> +}
> +
> +static void
> +input_handle_touch_up(void *data, struct wl_touch *wl_touch,
> + uint32_t serial, uint32_t time, int32_t id)
> +{
> + struct wayland_input *input = data;
> + notify_touch(&input->base, time, id, 0, 0, WL_TOUCH_UP);
> +}
> +
> +static void
> +input_handle_touch_motion(void *data, struct wl_touch *wl_touch,
> + uint32_t time, int32_t id, wl_fixed_t x_w,
> + wl_fixed_t y_w)
> +{
> + struct wayland_input *input = data;
> + notify_touch(&input->base, time, id, x_w, y_w, WL_TOUCH_MOTION);
> +}
> +
> +static void
> +input_handle_touch_frame(void *data, struct wl_touch *wl_touch)
> +{
> + struct wayland_input *input = data;
> + notify_touch_frame(&input->base);
> +}
> +
> +static void
> +input_handle_touch_cancel(void *data, struct wl_touch *wl_touch)
> +{
> +}
> +
> +static const struct wl_touch_listener touch_listener = {
> + input_handle_touch_down,
> + input_handle_touch_up,
> + input_handle_touch_motion,
> + input_handle_touch_frame,
> + input_handle_touch_cancel,
> +};
> +
> +static void
> input_handle_capabilities(void *data, struct wl_seat *seat,
> enum wl_seat_capability caps)
> {
> @@ -1606,6 +1653,18 @@ input_handle_capabilities(void *data, struct wl_seat
> *seat,
> wl_keyboard_destroy(input->parent.keyboard);
> input->parent.keyboard = NULL;
> }
> +
> + if ((caps & WL_SEAT_CAPABILITY_TOUCH) && !input->parent.touch) {
> + input->parent.touch = wl_seat_get_touch(seat);
> + weston_seat_init_touch (&input->base);
> + wl_touch_set_user_data(input->parent.touch, input);
> + wl_touch_add_listener(input->parent.touch,
> + &touch_listener, input);
> + } else if (!(caps & WL_SEAT_CAPABILITY_TOUCH) && input->parent.touch) {
> + weston_seat_release_touch (&input->base);
> + wl_touch_destroy(input->parent.touch);
> + input->parent.touch = NULL;
> + }
> }
>
> static void
> --
> 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
[PATCH libinput 2/2] Parse the MOUSE_WHEEL_CLICK_ANGLE udev property if present
Signed-off-by: Peter Hutterer
---
doc/device-configuration-via-udev.dox | 4
src/evdev.c | 29 +++--
src/evdev.h | 3 +++
src/libinput-util.c | 30 ++
src/libinput-util.h | 1 +
test/misc.c | 34 --
6 files changed, 97 insertions(+), 4 deletions(-)
diff --git a/doc/device-configuration-via-udev.dox
b/doc/device-configuration-via-udev.dox
index b854035..bee3659 100644
--- a/doc/device-configuration-via-udev.dox
+++ b/doc/device-configuration-via-udev.dox
@@ -23,6 +23,10 @@ context. Defaults to "default".
HW resolution and sampling frequency of a relative pointer device.
See @ref motion_normalization for details.
+MOUSE_WHEEL_CLICK_ANGLE
+The angle in degrees for each click on a mouse wheel. See
+libinput_pointer_get_axis_source() for details.
+
Below is an example udev rule to assign "seat1" to a device from vendor
diff --git a/src/evdev.c b/src/evdev.c
index 4fb37d6..f35ee34 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -577,7 +577,7 @@ evdev_process_relative(struct evdev_device *device,
time,
LIBINPUT_POINTER_AXIS_SCROLL_VERTICAL,
LIBINPUT_POINTER_AXIS_SOURCE_WHEEL,
- -1 * e->value * DEFAULT_AXIS_STEP_DISTANCE);
+ -1 * e->value * device->scroll.wheel_click_angle);
break;
case REL_HWHEEL:
evdev_flush_pending_event(device, time);
@@ -586,7 +586,7 @@ evdev_process_relative(struct evdev_device *device,
time,
LIBINPUT_POINTER_AXIS_SCROLL_HORIZONTAL,
LIBINPUT_POINTER_AXIS_SOURCE_WHEEL,
- e->value * DEFAULT_AXIS_STEP_DISTANCE);
+ e->value * device->scroll.wheel_click_angle);
break;
}
}
@@ -1240,6 +1240,29 @@ evdev_tag_device(struct evdev_device *device)
}
static inline int
+evdev_read_wheel_click_prop(struct evdev_device *device)
+{
+ struct libinput *libinput = device->base.seat->libinput;
+ const char *prop;
+ int angle = DEFAULT_AXIS_STEP_DISTANCE;
+
+ prop = udev_device_get_property_value(device->udev_device,
+ "MOUSE_WHEEL_CLICK_ANGLE");
+ if (prop) {
+ angle = parse_mouse_wheel_click_angle_property(prop);
+ if (!angle) {
+ log_error(libinput,
+ "Mouse wheel click angle '%s' is present but
invalid,"
+ "using %d degrees instead\n",
+ device->devname,
+ DEFAULT_AXIS_STEP_DISTANCE);
+ angle = DEFAULT_AXIS_STEP_DISTANCE;
+ }
+ }
+
+ return angle;
+}
+static inline int
evdev_read_dpi_prop(struct evdev_device *device)
{
struct libinput *libinput = device->base.seat->libinput;
@@ -1568,6 +1591,8 @@ evdev_device_create(struct libinput_seat *seat,
device->devname = libevdev_get_name(device->evdev);
device->scroll.threshold = 5.0; /* Default may be overridden */
device->scroll.direction = 0;
+ device->scroll.wheel_click_angle =
+ evdev_read_wheel_click_prop(device);
device->dpi = evdev_read_dpi_prop(device);
/* at most 5 SYN_DROPPED log-messages per 30s */
ratelimit_init(&device->syn_drop_limit, 30ULL * 1000, 5);
diff --git a/src/evdev.h b/src/evdev.h
index a75dd13..2171c5a 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -119,6 +119,9 @@ struct evdev_device {
/* set during device init if we want natural scrolling,
* used at runtime to enable/disable the feature */
bool natural_scrolling_enabled;
+
+ /* angle per REL_WHEEL click in degrees */
+ int wheel_click_angle;
} scroll;
enum evdev_event_type pending_event;
diff --git a/src/libinput-util.c b/src/libinput-util.c
index c16de1b..49e297a 100644
--- a/src/libinput-util.c
+++ b/src/libinput-util.c
@@ -171,3 +171,33 @@ parse_mouse_dpi_property(const char *prop)
}
return dpi;
}
+
+/**
+ * Helper function to parse the MOUSE_WHEEL_CLICK_ANGLE property from udev.
+ * Property is of the form:
+ * MOUSE_WHEEL_CLICK_ANGLE=
+ * Where the number indicates the degrees travelled for each click.
+ *
+ * We skip preceding whitespaces and parse the first number seen. If
+ * multiple numbers are specified, we ignore those.
+ *
+ * @param prop The value of the udev property (without the
MOUSE_WHEEL_CLICK_ANGLE=)
+ * @return The angle of the wheel (may be negative) or 0 on error.
+ */
+int
+parse_mouse_wheel_click_angle_property(const char *prop)
+{
+ int angle = 0,
+ nread = 0;
[PATCH libinput 1/2] Change the scroll step distance to 15 and document it as degrees
Similar to the mouse resolution, let's make the scroll distance a sensible
predictable value. Most mice use a 15 degree angle per scroll click, so let's
change to that. This will alter behaviour in clients that expect 10 but it
shouldn't be too bad. We return doubles anyway for the axis value, so that
leaves the option of really fine-grained step sizes.
We currently assume all mice have 15 degree angles. Like the DPI settings, it
will require a udev property to be set. Patch for that to follow.
Signed-off-by: Peter Hutterer
---
src/evdev.c| 2 +-
src/libinput.h | 8
test/pointer.c | 4 ++--
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/src/evdev.c b/src/evdev.c
index 1718491..4fb37d6 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -40,7 +40,7 @@
#include "filter.h"
#include "libinput-private.h"
-#define DEFAULT_AXIS_STEP_DISTANCE 10
+#define DEFAULT_AXIS_STEP_DISTANCE 15
#define DEFAULT_MIDDLE_BUTTON_SCROLL_TIMEOUT 200
enum evdev_key_type {
diff --git a/src/libinput.h b/src/libinput.h
index 27c5868..95a5c1d 100644
--- a/src/libinput.h
+++ b/src/libinput.h
@@ -704,10 +704,10 @@ libinput_event_pointer_get_axis_value(struct
libinput_event_pointer *event);
*
* If the source is @ref LIBINPUT_POINTER_AXIS_SOURCE_WHEEL, no terminating
* event is guaranteed (though it may happen).
- * Scrolling is in discrete steps, a value of 10 representing one click
- * of a typical mouse wheel. Some mice may have differently grained wheels,
- * libinput will adjust the value accordingly. It is up to the caller how to
- * interpret such different step sizes.
+ * Scrolling is in discrete steps, the value is the angle the wheel moved
+ * in degrees. The default is 15 degrees per wheel click, but some mice may
+ * have differently grained wheels. It is up to the caller how to interpret
+ * such different step sizes.
*
* If the source is @ref LIBINPUT_POINTER_AXIS_SOURCE_CONTINUOUS, no
* terminating event is guaranteed (though it may happen).
diff --git a/test/pointer.c b/test/pointer.c
index b9bd3cc..d12c9f6 100644
--- a/test/pointer.c
+++ b/test/pointer.c
@@ -350,8 +350,8 @@ test_wheel_event(struct litest_device *dev, int which, int
amount)
struct libinput_event_pointer *ptrev;
/* the current evdev implementation scales the scroll wheel events
- up by a factor 10 */
- const int scroll_step = 10;
+ up by a factor 15 */
+ const int scroll_step = 15;
int expected = amount * scroll_step;
if
(libinput_device_config_scroll_get_natural_scroll_enabled(dev->libinput_device))
--
2.1.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
wl_test / accessibility
Hi, I was curious whether wl_test (from weston) is intended to eventually be moved into wayland. I'm asking because it contains functionality (such as being able to track and move the mouse pointer) that the Orca screen reader relies on[1], so I'm trying to decide whether it makes sense to use wl_test for this, or if we should do something else. [1] Some previous discussion at http://lists.freedesktop.org/archives/wayland-devel/2013-October/011487.html Thanks, -Mike ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] build-pedantic: use main(void)
On Fri, Jan 09, 2015 at 10:34:46AM +0100, Marek Chalupa wrote:
> Main has unused parameters argc and argv. Since they are unused and
> C 99 allows to prototype main as 'int main(void)',
> remove them and replace by void. It fixes build when unused parameters
> are treated as errors.
>
> Signed-off-by: Marek Chalupa
merged and pushed, thanks.
Cheers,
Peter
> ---
> test/build-pedantic.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/test/build-pedantic.c b/test/build-pedantic.c
> index 1dfb67d..920fc4a 100644
> --- a/test/build-pedantic.c
> +++ b/test/build-pedantic.c
> @@ -3,6 +3,6 @@
> /* This is a build-test only */
>
> int
> -main(int argc, char **argv) {
> +main(void) {
> return 0;
> }
> --
> 2.2.0
>
> ___
> 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 v2 2/2] releasing: Add example commands to release directions
On Fri, Jan 09, 2015 at 06:09:21PM -0800, Bryce Harrington wrote: > Note that for weston, configure.ac needs version numbers updated in > several places. `make distcheck` for weston no longer triggers the test > suite to run, so update the directions to run a `make check` > pre-release. Switch to using the X.org release.sh script in place of > some of the manual steps. > > Signed-off-by: Bryce Harrington Reviewed-by: Peter Hutterer for both Cheers, Peter > --- > releasing.txt | 46 +++--- > 1 file changed, 31 insertions(+), 15 deletions(-) > > diff --git a/releasing.txt b/releasing.txt > index 2debcd0..def6614 100644 > --- a/releasing.txt > +++ b/releasing.txt > @@ -1,29 +1,42 @@ > -To make a release follow these steps. > +To make a release of Weston and/or Wayland, follow these steps. > > - 1. Update configure.ac to intended version, commit. > + 0. Update the first three lines of configure.ac to the intended > + version, commit. Also note that Weston includes versioned > + dependencies on 'wayland-server' and 'wayland-client' in > + configure.ac which typically need updated as well. > > - 2. make distcheck (for weston I do make distcheck TESTS= to avoid > - running the tests... most of the tests pass, but the xwayland one > - is flaky) > + 1. Verify the test suites and codebase checks pass. (All of the > + tests pass should pass except for xwayland, which can be flaky.) > > - 3. git tag -am 1.5.0 1.5.0 > + $ make check > > - 4. scp tarballs to /srv/wayland.freedesktop.org/www/releases on > - annarchy.freedesktop.org > + 2. Run the release.sh script to generate the tarballs, sign and > + upload them, and generate a release announcement template. > + This script can be obtained from X.org's modular package: > > - 5. Put SHA1 for tarballs and tagged commits in release announcement > +http://cgit.freedesktop.org/xorg/util/modular/tree/release.sh > > - 6. Push configure.ac commits and tags. > + The script supports a --dry-run option to test it without actually > + doing a release. If the script fails on the distcheck step due to > + a testsuite error that can't be fixed for some reason, you can > + skip testsuite by specifying the --dist argument. Pass --help to > + see other supported options. > > - 7. Send out release announcement. > + 3. Compose a release announcement. The script will generate a > + weston.x.y.0.announce file with a list of changes and tags. > + Prepend this with a human-readable listing of the most notable > + changes. For x.y.0 releases, indicate the schedule for the > + x.y+1.0 release. > > - 8. Get the release email URL from > + 4. Send the release announcement to wayland-devel@lists.freedesktop.org > + > + 5. Get your freshly posted release email URL from >http://lists.freedesktop.org/archives/wayland-devel/ > > - 9. Update releases.html in wayland-web with links to tarballs and > - release email. > + 6. Update releases.html in wayland-web with links to tarballs and > + the release email URL > > - 10. Update topic in #wayland to point to release announcement > + 7. Update topic in #wayland to point to the release announcement URL > > For x.y.0 releases, also create the x.y branch. The x.y branch is for > bug fixes and conservative changes to the x.y.0 release, and is where > @@ -34,6 +47,9 @@ fixing for the x.y.1 release for a little longer) or before > the x.y.0 > release (like we did with the 1.5.0 release, to unblock master > development early). > > +$ git branch x.y > +$ git push origin x.y > + > The master branch configure.ac version should always be (at least) > x.y.90, with x.y being the most recent stable branch. Stable branch > configure version is just whatever was most recently released from > -- > 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 v2] xwm: tell the shell the pid of the X clients
2015-01-11 12:26 GMT+02:00 Giulio Camuffo :
> 2015-01-11 10:33 GMT+02:00 Jasper St. Pierre :
>> In the case of X clients, using XKillClient instead of killing the PID would
>> be much nicer.
>>
>> On Sat, Jan 10, 2015 at 3:27 AM, Giulio Camuffo
>> wrote:
>>>
>>> All the surfaces from all the X clients share the same wl_client so
>>> wl_client_get_credentials can't be used to get the pid of the X
>>> clients.
>>> The shell may need to know the pid to be able to associate a surface
>>> with e.g. a DBus service.
>>> ---
>>> src/compositor.h | 1 +
>>> xwayland/window-manager.c | 21 +
>>> 2 files changed, 14 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/src/compositor.h b/src/compositor.h
>>> index 900d2a5..3b1e490 100644
>>> --- a/src/compositor.h
>>> +++ b/src/compositor.h
>>> @@ -121,6 +121,7 @@ struct weston_shell_interface {
>>> void (*set_window_geometry)(struct shell_surface *shsurf,
>>> int32_t x, int32_t y,
>>> int32_t width, int32_t height);
>>> + void (*set_pid)(struct shell_surface *shsurf, pid_t pid);
>>
>>
>> I don't see anywhere you fill this in?
>
> You're right, i forgor the shell part.
>
>>
>>>
>>> };
>>>
>>> struct weston_animation {
>>> diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
>>> index f362eac..b819b04 100644
>>> --- a/xwayland/window-manager.c
>>> +++ b/xwayland/window-manager.c
>>> @@ -401,6 +401,7 @@ weston_wm_window_read_properties(struct
>>> weston_wm_window *window)
>>> uint32_t *xid;
>>> xcb_atom_t *atom;
>>> uint32_t i;
>>> + char name[1024];
>>>
>>> if (!window->properties_dirty)
>>> return;
>>> @@ -487,10 +488,19 @@ weston_wm_window_read_properties(struct
>>> weston_wm_window *window)
>>> free(reply);
>>> }
>>>
>>> + gethostname(name, 1024);
>>> + /* this is only one heuristic to guess the PID of a client is
>>> valid,
>>> +* assuming it's compliant with icccm and ewmh. Non-compliants and
>>> +* remote applications of course fail. */
>>> + if (strcmp(window->machine, name))
>>> + window->pid = 0;
>>> +
>>> if (window->shsurf && window->name)
>>> shell_interface->set_title(window->shsurf, window->name);
>>> if (window->frame && window->name)
>>> frame_set_title(window->frame, window->name);
>>> + if (window->shsurf && window->pid > 0)
>>> + shell_interface->set_pid(window->shsurf, window->pid);
>>> }
>>>
>>> static void
>>> @@ -651,17 +661,10 @@ weston_wm_kill_client(struct wl_listener *listener,
>>> void *data)
>>> {
>>> struct weston_surface *surface = data;
>>> struct weston_wm_window *window = get_wm_window(surface);
>>> - char name[1024];
>>> -
>>> if (!window)
>>> return;
>>>
>>> - gethostname(name, 1024);
>>> -
>>> - /* this is only one heuristic to guess the PID of a client is
>>> valid,
>>> -* assuming it's compliant with icccm and ewmh. Non-compliants and
>>> -* remote applications of course fail. */
>>> - if (!strcmp(window->machine, name) && window->pid != 0)
>>> + if (!window->pid > 0)
>>
>>
>> This looks very wrong.
>
> Why? if the hostname check fails the pid is set to 0 so the if here will fail.
Oh, you meant the !. It was a mistake, i didn't notice it.
>
>>
>>>
>>> kill(window->pid, SIGKILL);
>>> }
>>>
>>> @@ -2350,6 +2353,8 @@ xserver_map_shell_surface(struct weston_wm_window
>>> *window,
>>>
>>> if (window->name)
>>> shell_interface->set_title(window->shsurf, window->name);
>>> + if (window->pid > 0)
>>> + shell_interface->set_pid(window->shsurf, window->pid);
>>>
>>> if (window->fullscreen) {
>>> window->saved_width = window->width;
>>> --
>>> 2.2.1
>>>
>>> ___
>>> wayland-devel mailing list
>>> wayland-devel@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>
>>
>>
>>
>> --
>> Jasper
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH v3] xwm: tell the shell the pid of the X clients
All the surfaces from all the X clients share the same wl_client so
wl_client_get_credentials can't be used to get the pid of the X
clients.
The shell may need to know the pid to be able to associate a surface
with e.g. a DBus service.
---
v3: added the implementation in shell.c
desktop-shell/shell.c | 7 +++
src/compositor.h | 1 +
xwayland/window-manager.c | 21 +
3 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index c9c61b1..1925cd5 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -2248,6 +2248,12 @@ set_title(struct shell_surface *shsurf, const char
*title)
}
static void
+set_pid(struct shell_surface *shsurf, pid_t pid)
+{
+ /* We have no use for it */
+}
+
+static void
set_type(struct shell_surface *shsurf, enum shell_surface_type t)
{
shsurf->type = t;
@@ -6626,6 +6632,7 @@ module_init(struct weston_compositor *ec,
ec->shell_interface.resize = surface_resize;
ec->shell_interface.set_title = set_title;
ec->shell_interface.set_window_geometry = set_window_geometry;
+ ec->shell_interface.set_pid = set_pid;
weston_layer_init(&shell->fullscreen_layer, &ec->cursor_layer.link);
weston_layer_init(&shell->panel_layer, &shell->fullscreen_layer.link);
diff --git a/src/compositor.h b/src/compositor.h
index 900d2a5..3b1e490 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -121,6 +121,7 @@ struct weston_shell_interface {
void (*set_window_geometry)(struct shell_surface *shsurf,
int32_t x, int32_t y,
int32_t width, int32_t height);
+ void (*set_pid)(struct shell_surface *shsurf, pid_t pid);
};
struct weston_animation {
diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index f362eac..b819b04 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -401,6 +401,7 @@ weston_wm_window_read_properties(struct weston_wm_window
*window)
uint32_t *xid;
xcb_atom_t *atom;
uint32_t i;
+ char name[1024];
if (!window->properties_dirty)
return;
@@ -487,10 +488,19 @@ weston_wm_window_read_properties(struct weston_wm_window
*window)
free(reply);
}
+ gethostname(name, 1024);
+ /* this is only one heuristic to guess the PID of a client is valid,
+* assuming it's compliant with icccm and ewmh. Non-compliants and
+* remote applications of course fail. */
+ if (strcmp(window->machine, name))
+ window->pid = 0;
+
if (window->shsurf && window->name)
shell_interface->set_title(window->shsurf, window->name);
if (window->frame && window->name)
frame_set_title(window->frame, window->name);
+ if (window->shsurf && window->pid > 0)
+ shell_interface->set_pid(window->shsurf, window->pid);
}
static void
@@ -651,17 +661,10 @@ weston_wm_kill_client(struct wl_listener *listener, void
*data)
{
struct weston_surface *surface = data;
struct weston_wm_window *window = get_wm_window(surface);
- char name[1024];
-
if (!window)
return;
- gethostname(name, 1024);
-
- /* this is only one heuristic to guess the PID of a client is valid,
-* assuming it's compliant with icccm and ewmh. Non-compliants and
-* remote applications of course fail. */
- if (!strcmp(window->machine, name) && window->pid != 0)
+ if (!window->pid > 0)
kill(window->pid, SIGKILL);
}
@@ -2350,6 +2353,8 @@ xserver_map_shell_surface(struct weston_wm_window *window,
if (window->name)
shell_interface->set_title(window->shsurf, window->name);
+ if (window->pid > 0)
+ shell_interface->set_pid(window->shsurf, window->pid);
if (window->fullscreen) {
window->saved_width = window->width;
--
2.2.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [weston1.5]Question about HardKey input monitor with wayland/weston
On Mon, 5 Jan 2015 11:48:00 + Yang Andy wrote: > Hi Pekka > > Thank you very much for your reply. > > > If you're interested in that, you can > >dig the wayland-devel mailing list archives, or if you can't find it, > >someone else probably can. This discussion was about any normal app > >that just wants to register for a global hotkey. > I have searched for the related topic,but i did not find it. Here are some pointers: http://lists.freedesktop.org/archives/wayland-devel/2014-July/015869.html which is a part of a thread starting at http://lists.freedesktop.org/archives/wayland-devel/2014-July/015856.html containing some discussion. There's some hand-waving and a youtube link in http://lists.freedesktop.org/archives/wayland-devel/2012-September/005603.html Some good ideas are in http://lists.freedesktop.org/archives/wayland-devel/2013-December/012659.html I didn't find what I would think as the latest comprehensive proposal, though. > >In all cases, the main idea is to prevent random clients from > >eavesdropping input, while still letting the right client(s) get them. > >This is always some new protocol extension that is unrelated to > >wl_keyboard, wl_pointer, etc. > Right now,my solution is to extend wl_keyboard protocol,because the > work volume is little. So you are faking temporary keyboard focus changes in the compositor to send keyboard events? I believe that will be hard to make it work right and follow the guarantees we require from wl_keyboard events, if not impossible. > Software architecture is > HMI-->QT/EFL(wayland/client)-->westion(wl_keyboard/extention key)--evdev. > > But i have another question. > > In my uses case,i will composite QT-applicaiton and EFL-applicaion into one > image,both of them want to get hardkey input event but only one application > can get the input event who get the foucs. > > When QT /EFL application want to get hardkey input event,it have to get the > windows focus. > > How do i switch the focus/active for specific QT or EFL application by > software design? > > Could you give some advice? I think you have a fundamental problem here: global hotkeys cannot be in any way associated with keyboard focus. That is their whole point: they must work without any focus. So a design that relies on focus or focus switching is broken from the start. This is one of the reasons why we cannot use wl_keyboard for this. We need a whole new protocol extension. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v2] xwm: tell the shell the pid of the X clients
2015-01-11 10:33 GMT+02:00 Jasper St. Pierre :
> In the case of X clients, using XKillClient instead of killing the PID would
> be much nicer.
>
> On Sat, Jan 10, 2015 at 3:27 AM, Giulio Camuffo
> wrote:
>>
>> All the surfaces from all the X clients share the same wl_client so
>> wl_client_get_credentials can't be used to get the pid of the X
>> clients.
>> The shell may need to know the pid to be able to associate a surface
>> with e.g. a DBus service.
>> ---
>> src/compositor.h | 1 +
>> xwayland/window-manager.c | 21 +
>> 2 files changed, 14 insertions(+), 8 deletions(-)
>>
>> diff --git a/src/compositor.h b/src/compositor.h
>> index 900d2a5..3b1e490 100644
>> --- a/src/compositor.h
>> +++ b/src/compositor.h
>> @@ -121,6 +121,7 @@ struct weston_shell_interface {
>> void (*set_window_geometry)(struct shell_surface *shsurf,
>> int32_t x, int32_t y,
>> int32_t width, int32_t height);
>> + void (*set_pid)(struct shell_surface *shsurf, pid_t pid);
>
>
> I don't see anywhere you fill this in?
You're right, i forgor the shell part.
>
>>
>> };
>>
>> struct weston_animation {
>> diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
>> index f362eac..b819b04 100644
>> --- a/xwayland/window-manager.c
>> +++ b/xwayland/window-manager.c
>> @@ -401,6 +401,7 @@ weston_wm_window_read_properties(struct
>> weston_wm_window *window)
>> uint32_t *xid;
>> xcb_atom_t *atom;
>> uint32_t i;
>> + char name[1024];
>>
>> if (!window->properties_dirty)
>> return;
>> @@ -487,10 +488,19 @@ weston_wm_window_read_properties(struct
>> weston_wm_window *window)
>> free(reply);
>> }
>>
>> + gethostname(name, 1024);
>> + /* this is only one heuristic to guess the PID of a client is
>> valid,
>> +* assuming it's compliant with icccm and ewmh. Non-compliants and
>> +* remote applications of course fail. */
>> + if (strcmp(window->machine, name))
>> + window->pid = 0;
>> +
>> if (window->shsurf && window->name)
>> shell_interface->set_title(window->shsurf, window->name);
>> if (window->frame && window->name)
>> frame_set_title(window->frame, window->name);
>> + if (window->shsurf && window->pid > 0)
>> + shell_interface->set_pid(window->shsurf, window->pid);
>> }
>>
>> static void
>> @@ -651,17 +661,10 @@ weston_wm_kill_client(struct wl_listener *listener,
>> void *data)
>> {
>> struct weston_surface *surface = data;
>> struct weston_wm_window *window = get_wm_window(surface);
>> - char name[1024];
>> -
>> if (!window)
>> return;
>>
>> - gethostname(name, 1024);
>> -
>> - /* this is only one heuristic to guess the PID of a client is
>> valid,
>> -* assuming it's compliant with icccm and ewmh. Non-compliants and
>> -* remote applications of course fail. */
>> - if (!strcmp(window->machine, name) && window->pid != 0)
>> + if (!window->pid > 0)
>
>
> This looks very wrong.
Why? if the hostname check fails the pid is set to 0 so the if here will fail.
>
>>
>> kill(window->pid, SIGKILL);
>> }
>>
>> @@ -2350,6 +2353,8 @@ xserver_map_shell_surface(struct weston_wm_window
>> *window,
>>
>> if (window->name)
>> shell_interface->set_title(window->shsurf, window->name);
>> + if (window->pid > 0)
>> + shell_interface->set_pid(window->shsurf, window->pid);
>>
>> if (window->fullscreen) {
>> window->saved_width = window->width;
>> --
>> 2.2.1
>>
>> ___
>> wayland-devel mailing list
>> wayland-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>
>
>
> --
> Jasper
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v2] xwm: tell the shell the pid of the X clients
In the case of X clients, using XKillClient instead of killing the PID
would be much nicer.
On Sat, Jan 10, 2015 at 3:27 AM, Giulio Camuffo
wrote:
> All the surfaces from all the X clients share the same wl_client so
> wl_client_get_credentials can't be used to get the pid of the X
> clients.
> The shell may need to know the pid to be able to associate a surface
> with e.g. a DBus service.
> ---
> src/compositor.h | 1 +
> xwayland/window-manager.c | 21 +
> 2 files changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/src/compositor.h b/src/compositor.h
> index 900d2a5..3b1e490 100644
> --- a/src/compositor.h
> +++ b/src/compositor.h
> @@ -121,6 +121,7 @@ struct weston_shell_interface {
> void (*set_window_geometry)(struct shell_surface *shsurf,
> int32_t x, int32_t y,
> int32_t width, int32_t height);
> + void (*set_pid)(struct shell_surface *shsurf, pid_t pid);
>
I don't see anywhere you fill this in?
> };
>
> struct weston_animation {
> diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
> index f362eac..b819b04 100644
> --- a/xwayland/window-manager.c
> +++ b/xwayland/window-manager.c
> @@ -401,6 +401,7 @@ weston_wm_window_read_properties(struct
> weston_wm_window *window)
> uint32_t *xid;
> xcb_atom_t *atom;
> uint32_t i;
> + char name[1024];
>
> if (!window->properties_dirty)
> return;
> @@ -487,10 +488,19 @@ weston_wm_window_read_properties(struct
> weston_wm_window *window)
> free(reply);
> }
>
> + gethostname(name, 1024);
> + /* this is only one heuristic to guess the PID of a client is
> valid,
> +* assuming it's compliant with icccm and ewmh. Non-compliants and
> +* remote applications of course fail. */
> + if (strcmp(window->machine, name))
> + window->pid = 0;
> +
> if (window->shsurf && window->name)
> shell_interface->set_title(window->shsurf, window->name);
> if (window->frame && window->name)
> frame_set_title(window->frame, window->name);
> + if (window->shsurf && window->pid > 0)
> + shell_interface->set_pid(window->shsurf, window->pid);
> }
>
> static void
> @@ -651,17 +661,10 @@ weston_wm_kill_client(struct wl_listener *listener,
> void *data)
> {
> struct weston_surface *surface = data;
> struct weston_wm_window *window = get_wm_window(surface);
> - char name[1024];
> -
> if (!window)
> return;
>
> - gethostname(name, 1024);
> -
> - /* this is only one heuristic to guess the PID of a client is
> valid,
> -* assuming it's compliant with icccm and ewmh. Non-compliants and
> -* remote applications of course fail. */
> - if (!strcmp(window->machine, name) && window->pid != 0)
> + if (!window->pid > 0)
>
This looks very wrong.
> kill(window->pid, SIGKILL);
> }
>
> @@ -2350,6 +2353,8 @@ xserver_map_shell_surface(struct weston_wm_window
> *window,
>
> if (window->name)
> shell_interface->set_title(window->shsurf, window->name);
> + if (window->pid > 0)
> + shell_interface->set_pid(window->shsurf, window->pid);
>
> if (window->fullscreen) {
> window->saved_width = window->width;
> --
> 2.2.1
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
--
Jasper
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland color depth 256 / 16 / 24 /32
On Wed, 7 Jan 2015 16:53:43 +0100 Damian Ivanov wrote: > Hi, > > What color depth works on wayland? Wayland does not really care. The actual compositors and clients would be the key here, and also the graphics driver implementations (EGL, GL, etc.) where acceleration is desired. If you need more buffer color formats added to the protocol for wl_shm based buffers, we can do that quite easily, especially if those formats have a widely accepted fourcc code. However, adding paletted formats would be quite more work: define a protocol extension, and implement support for it in compositors and clients. I'm not sure that would be worth it: the client can convert to a non-paletted format, and if that is too slow, then a composited window system is perhaps too slow also. > I haven't seen any configuration hint on this one, > it would be nice to have 256 possible too, if it's not a total hack or > brings an enormous amount of code. > > Usecase would be, as soon as wine works native on wayland to run > legacy 256 only apps. (There are a few of them) I seem to recall that there are some other harder problems that are much more blockers for porting Wine to Wayland than just color depth. Color depth or pixel format issues are easily circumvented by adding an intermediate buffer with some copying/converting, but the other problems are more fundamental. Perhaps a faster way to let Wine work on Wayland-based desktop systems would be to improve Xwayland instead of Wine. Do you know of anyone actually looking into the Wine on Wayland matter? Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
