Re: [PATCH wayland-protocols] xdg-shell: Introduce xdg_toplevel capabilities

[Jonas Ådahl]

On Wed, Jul 20, 2016 at 11:12:03AM +0200, Quentin Glidic wrote:
> On 15/07/2016 13:00, Jonas Ådahl wrote:
> > The xdg_toplevel capabilities are meant to let the compositor know what
> > configurations a client can be configured to. This is meant to make it
> > possible to disallow a compositor to maximize, fullscreen etc a
> > surface, which would otherwise mandate the client to configure the
> > surface according to dimension in the xdg_toplevel.configure event.
> > 
> > This makes it possible to create non-resizable surfaces as well as
> > surfaces with only a certain aspect ratio allowed, by making them
> > un-fullscreen:able and un-maximize:able.
> > 
> > Signed-off-by: Jonas Ådahl 
> > ---
> > 
> > This is an alternative solution to the s/must/should/ patch.
> > 
> > I made a separate enum, because certain state enum entries make no sense to
> > support or not, since they don't mandate anything (resize, activated so 
> > far).
> > 
> 
> I like this idea better than the s/must/should/ patch.
> 
> Since we do not reuse the existing enum, does that make sense to group
> similar features?
> The fullscreen/maximized/tiled states are about obeying an arbitrary size,
> you can still support even if you do nothing more. Sure, a fullscreen
> surface would look weird with a title bar, but it is usable, and will be on
> top of everything, just like intended.
> Thoughts?

Hmm. A 'can-be-force-resized' capability might be better indeed. It'd
mean that a unresizeable surface could still be tiled as long as both
the min and max size are set and set to the same thing. It wouldn't,
however, for aspect-ratio bound clients (neither would the capabilities
in this patch). We wouldn't be able to support that use case with this,
while the s/must/should/ would. Another alternative we could go with is
to add a 'can-be-force-resized' 'incapability' which would change the
requirements of the fullscreen/maximized/tiled_* states to
s/must/should/ only if that 'incapability' was set. We should probably
not call it 'incapability' or 'capability' if so though. Thoughts?

> 
> Nit: it should be  not . ;-)

Oops. I obviously haven't implemented it either, since I just threw it
together after our IRC discussion.


Jonas

> 
> Cheers,
> 
> > Jonas
> > 
> >  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 23 +++
> >  1 file changed, 23 insertions(+)
> > 
> > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> > b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > index 563e39b..73944a8 100644
> > --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > @@ -734,6 +734,29 @@
> >
> >  
> > 
> > +
> > +  
> > +   Certain xdg_toplevel states mandate certain client capabilities. For
> > +   example while a fullscreen:ed client is required to configure itself
> > +   according to the dimension in the configure event, some clients may not
> > +   have this ability due to various reasons.
> > +  
> > +   > +summary="the toplevel can be maximized"/>
> > +   > +summary="the toplevel can be fullscreened"/>
> > +
> > +
> > +
> > +  
> > +   Notify the compositor about what capabilities this xdg_toplevel
> > +   supports. This request can only be issued once and if so must be done
> > +   before the initial state is comitted. The default capabilities are no
> > +   capabilities.
> > +  
> > +  
> > +
> > +
> >  
> >
> > Set a maximum size for the window.
> > 
> 
> 
> -- 
> 
> Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols] Introduce xdg-foreign protocol

[Jonas Ådahl]

On Wed, Jul 20, 2016 at 12:04:04PM -0700, Yong Bakos wrote:
> Hi Jonas,
> 
> > On Jul 13, 2016, at 12:58 AM, Jonas Ådahl  wrote:
> > 
> > xdg-foreign is a protocol meant to enable setting up inter surface
> > relationships across clients. Potential use cases are out-of-process
> > dialogs, such as file dialogs, meant to be used by sandboxed processes
> > that may not have the access it needs to implement such dialogs.
> > 
> > It works by enabling a client to export a surface, creating a handle
> > for the exported surface. The handle, in form of a unique string, may
> > be shared in some way with other clients (for example the provider of
> > the file dialog) which can then import the exported surface.
> > 
> > Signed-off-by: Jonas Ådahl 
> 
> Interesting protocol. Just a wild thought: would surface-exporting be
> something useful in the core Wayland protocol? (Not now, but...)

We abondened that idea years ago. You can search the archives for
wl_foreign_surface. In short, we went with the nested compositing
solution.

> 
> I'll need to re-read and imagine the scenarios, but I feel like there
> is some inconsistency in either the descriptions or the protocol itself.
> Specifically, I thought that the exported surface from client A would
> be displayed by client B as an xdg_toplevel, but then I also see
> set_parent_of, meaning that client B can add subsurfaces to the
> imported surface?

That is not the idea. I'd appreciate some input on how to rephrase
things to make that clear. The idea is that one only affects the
relationship between two xdg surface's, and so far only stacking.

> 
> No need to explain that in length, I think I just need to re-read.
> 
> Some notes inline below.
> 
> 
> > ---
> > 
> > Hi,
> > 
> > This protocol is intended to be used by flatpak's xdg desktop portals, in 
> > order
> > to have a portal dialog (such as a file chooser) to be stacked above (and 
> > maybe
> > as a modal) a parent surface.
> > 
> > A compositor that want to be able to run sandboxed Wayland clients that 
> > need to
> > use portals would need to implement this protocol.
> > 
> > In short, a sandboxed client would "export" its surface and in the process
> > retrieve a server generated handle string, acting as a unique identifier for
> > the exported window. In the flatpak case the client will pass the identifier
> > string via D-Bus to a xdg desktop portal service provider, which will then
> > import it using xdg_importer and create a xdg_imported object that it can be
> > used to modify the stacking relationship.
> > 
> > So far the only supported operation is setting an imported window to be the
> > parent of some surface.
> > 
> > Note that the protocol documentation says "xdg_surface". In the future this
> > would be "xdg_toplevel".
> > 
> > 
> > Jonas
> > 
> > Makefile.am  |   1 +
> > unstable/xdg-foreign/README  |   4 +
> > unstable/xdg-foreign/xdg-foreign-unstable-v1.xml | 177 
> > +++
> > 3 files changed, 182 insertions(+)
> > create mode 100644 unstable/xdg-foreign/README
> > create mode 100644 unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> > 
> > diff --git a/Makefile.am b/Makefile.am
> > index 71d2632..06a1bb2 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -8,6 +8,7 @@ unstable_protocols =
> > \
> > unstable/relative-pointer/relative-pointer-unstable-v1.xml  
> > \
> > unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
> > \
> > unstable/tablet/tablet-unstable-v1.xml  
> > \
> > +   unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> > \
> > $(NULL)
> > 
> > stable_protocols =  
> > \
> > diff --git a/unstable/xdg-foreign/README b/unstable/xdg-foreign/README
> > new file mode 100644
> > index 000..f5bcb83
> > --- /dev/null
> > +++ b/unstable/xdg-foreign/README
> > @@ -0,0 +1,4 @@
> > +xdg foreign protocol
> > +
> > +Maintainers:
> > +Jonas Ådahl 
> > diff --git a/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml 
> > b/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> > new file mode 100644
> > index 000..d8a90c3
> > --- /dev/null
> > +++ b/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> > @@ -0,0 +1,177 @@
> > +
> > +
> > +
> > +  
> > +Copyright © 2015-2016 Red Hat Inc.
> > +
> > +Permission is hereby granted, free of charge, to any person obtaining a
> > +copy of this software and associated documentation files (the 
> > "Software"),
> > +to deal in the Software without restriction, including without 
> > limitation
> > +the rights to use, copy, modify, merge, publish, distribute, 
> > sublicense,
> > +and/or sell copies of the Software, and to permit persons to whom the
> > +Software is 

[PATCH libinput 11/14] evdev: switch three ints to booleans

[Peter Hutterer]

And a minor rename to make it more obvious

Signed-off-by: Peter Hutterer 
---
 src/evdev-mt-touchpad-buttons.c |  2 +-
 src/evdev-mt-touchpad.c |  6 +++---
 src/evdev.c | 17 +
 src/evdev.h |  6 +++---
 4 files changed, 16 insertions(+), 15 deletions(-)

diff --git a/src/evdev-mt-touchpad-buttons.c b/src/evdev-mt-touchpad-buttons.c
index 263bb80..ff8ce39 100644
--- a/src/evdev-mt-touchpad-buttons.c
+++ b/src/evdev-mt-touchpad-buttons.c
@@ -1057,7 +1057,7 @@ tp_notify_clickpadbutton(struct tp_dispatch *tp,
}
 
/* Ignore button events not for the trackpoint while suspended */
-   if (tp->device->suspended)
+   if (tp->device->is_suspended)
return 0;
 
/* A button click always terminates edge scrolling, even if we
diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index 777914e..fa398e2 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -1118,7 +1118,7 @@ tp_post_events(struct tp_dispatch *tp, uint64_t time)
int filter_motion = 0;
 
/* Only post (top) button events while suspended */
-   if (tp->device->suspended) {
+   if (tp->device->is_suspended) {
tp_post_button_events(tp, time);
return;
}
@@ -2114,7 +2114,7 @@ tp_init_default_resolution(struct tp_dispatch *tp,
  touchpad_height_mm = 50;
int xres, yres;
 
-   if (!device->abs.fake_resolution)
+   if (!device->abs.is_fake_resolution)
return;
 
/* we only get here if
@@ -2138,7 +2138,7 @@ tp_init_default_resolution(struct tp_dispatch *tp,
libevdev_set_abs_resolution(device->evdev, ABS_Y, yres);
libevdev_set_abs_resolution(device->evdev, ABS_MT_POSITION_X, xres);
libevdev_set_abs_resolution(device->evdev, ABS_MT_POSITION_Y, yres);
-   device->abs.fake_resolution = 0;
+   device->abs.is_fake_resolution = false;
 }
 
 static inline void
diff --git a/src/evdev.c b/src/evdev.c
index 39eef9e..44b0be5 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -2170,7 +2170,7 @@ evdev_extract_abs_axes(struct evdev_device *device)
 return;
 
if (evdev_fix_abs_resolution(device, ABS_X, ABS_Y))
-   device->abs.fake_resolution = 1;
+   device->abs.is_fake_resolution = true;
device->abs.absinfo_x = libevdev_get_abs_info(evdev, ABS_X);
device->abs.absinfo_y = libevdev_get_abs_info(evdev, ABS_Y);
device->abs.point.x = device->abs.absinfo_x->value;
@@ -2188,7 +2188,7 @@ evdev_extract_abs_axes(struct evdev_device *device)
if (evdev_fix_abs_resolution(device,
 ABS_MT_POSITION_X,
 ABS_MT_POSITION_Y))
-   device->abs.fake_resolution = 1;
+   device->abs.is_fake_resolution = true;
 
device->abs.absinfo_x = libevdev_get_abs_info(evdev, ABS_MT_POSITION_X);
device->abs.absinfo_y = libevdev_get_abs_info(evdev, ABS_MT_POSITION_Y);
@@ -2374,7 +2374,8 @@ evdev_notify_added_device(struct evdev_device *device)
device->dispatch->interface->device_added(device, d);
 
/* Notify new device device if existing device d is suspended */
-   if (d->suspended && 
device->dispatch->interface->device_suspended)
+   if (d->is_suspended &&
+   device->dispatch->interface->device_suspended)
device->dispatch->interface->device_suspended(device, 
d);
}
 
@@ -2722,7 +2723,7 @@ evdev_device_get_size(const struct evdev_device *device,
x = libevdev_get_abs_info(device->evdev, ABS_X);
y = libevdev_get_abs_info(device->evdev, ABS_Y);
 
-   if (!x || !y || device->abs.fake_resolution ||
+   if (!x || !y || device->abs.is_fake_resolution ||
!x->resolution || !y->resolution)
return -1;
 
@@ -2872,7 +2873,7 @@ evdev_notify_suspended_device(struct evdev_device *device)
 {
struct libinput_device *it;
 
-   if (device->suspended)
+   if (device->is_suspended)
return;
 
list_for_each(it, >base.seat->devices_list, link) {
@@ -2884,7 +2885,7 @@ evdev_notify_suspended_device(struct evdev_device *device)
d->dispatch->interface->device_suspended(d, device);
}
 
-   device->suspended = 1;
+   device->is_suspended = true;
 }
 
 void
@@ -2892,7 +2893,7 @@ evdev_notify_resumed_device(struct evdev_device *device)
 {
struct libinput_device *it;
 
-   if (!device->suspended)
+   if (!device->is_suspended)
return;
 
list_for_each(it, >base.seat->devices_list, link) {
@@ -2904,7 +2905,7 @@ evdev_notify_resumed_device(struct evdev_device *device)
d->dispatch->interface->device_resumed(d, device);
}
 
-   device->suspended = 0;

[PATCH libinput 06/14] evdev: move the relative deltas for normal devices to the fallback dispatch

[Peter Hutterer]

Signed-off-by: Peter Hutterer 
---
 src/evdev.c | 36 ++--
 src/evdev.h |  4 ++--
 2 files changed, 24 insertions(+), 16 deletions(-)

diff --git a/src/evdev.c b/src/evdev.c
index 140fa73..e68eab4 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -372,10 +372,10 @@ evdev_filter_defuzz_touch(struct evdev_device *device, 
struct mt_slot *slot)
 }
 
 static inline void
-evdev_rotate_relative(struct evdev_device *device)
+evdev_rotate_relative(struct evdev_dispatch *dispatch,
+ struct evdev_device *device)
 {
-   struct evdev_dispatch *dispatch = device->dispatch;
-   struct device_coords rel = device->rel;
+   struct device_coords rel = dispatch->rel;
 
if (!device->base.config.rotation)
return;
@@ -384,7 +384,7 @@ evdev_rotate_relative(struct evdev_device *device)
 * right now anyway */
matrix_mult_vec(>rotation.matrix, , );
 
-   device->rel = rel;
+   dispatch->rel = rel;
 }
 
 static void
@@ -412,13 +412,13 @@ evdev_flush_pending_event(struct evdev_device *device, 
uint64_t time)
if (!(device->seat_caps & EVDEV_DEVICE_POINTER))
break;
 
-   evdev_rotate_relative(device);
+   evdev_rotate_relative(dispatch, device);
 
-   normalize_delta(device, >rel, );
-   raw.x = device->rel.x;
-   raw.y = device->rel.y;
-   device->rel.x = 0;
-   device->rel.y = 0;
+   normalize_delta(device, >rel, );
+   raw.x = dispatch->rel.x;
+   raw.y = dispatch->rel.y;
+   dispatch->rel.x = 0;
+   dispatch->rel.y = 0;
 
/* Use unaccelerated deltas for pointing stick scroll */
if (evdev_post_trackpoint_scroll(device, unaccel, time))
@@ -774,6 +774,7 @@ static inline void
 evdev_process_relative(struct evdev_device *device,
   struct input_event *e, uint64_t time)
 {
+   struct evdev_dispatch *dispatch = device->dispatch;
struct normalized_coords wheel_degrees = { 0.0, 0.0 };
struct discrete_coords discrete = { 0.0, 0.0 };
 
@@ -784,13 +785,13 @@ evdev_process_relative(struct evdev_device *device,
case REL_X:
if (device->pending_event != EVDEV_RELATIVE_MOTION)
evdev_flush_pending_event(device, time);
-   device->rel.x += e->value;
+   dispatch->rel.x += e->value;
device->pending_event = EVDEV_RELATIVE_MOTION;
break;
case REL_Y:
if (device->pending_event != EVDEV_RELATIVE_MOTION)
evdev_flush_pending_event(device, time);
-   device->rel.y += e->value;
+   dispatch->rel.y += e->value;
device->pending_event = EVDEV_RELATIVE_MOTION;
break;
case REL_WHEEL:
@@ -1481,6 +1482,14 @@ fallback_dispatch_init_slots(struct evdev_dispatch 
*dispatch,
return 0;
 }
 
+static inline void
+fallback_dispatch_init_rel(struct evdev_dispatch *dispatch,
+  struct evdev_device *device)
+{
+   dispatch->rel.x = 0;
+   dispatch->rel.y = 0;
+}
+
 static struct evdev_dispatch *
 fallback_dispatch_create(struct libinput_device *device)
 {
@@ -1492,6 +1501,7 @@ fallback_dispatch_create(struct libinput_device *device)
 
dispatch->interface = _interface;
 
+   fallback_dispatch_init_rel(dispatch, evdev_device);
if (fallback_dispatch_init_slots(dispatch, evdev_device) == -1) {
free(dispatch);
return NULL;
@@ -2494,8 +2504,6 @@ evdev_device_create(struct libinput_seat *seat,
device->is_mt = 0;
device->mtdev = NULL;
device->udev_device = udev_device_ref(udev_device);
-   device->rel.x = 0;
-   device->rel.y = 0;
device->abs.seat_slot = -1;
device->dispatch = NULL;
device->fd = fd;
diff --git a/src/evdev.h b/src/evdev.h
index c2fad15..ff918b0 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -155,8 +155,6 @@ struct evdev_device {
 
struct mtdev *mtdev;
 
-   struct device_coords rel;
-
struct {
struct libinput_timer timer;
struct libinput_device_config_scroll_method config;
@@ -302,6 +300,8 @@ struct evdev_dispatch {
bool want_hysteresis;
struct device_coords hysteresis_margin;
} mt;
+
+   struct device_coords rel;
 };
 
 struct evdev_device *
-- 
2.7.4

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH libinput 03/14] evdev: split out slot init

[Peter Hutterer]

Signed-off-by: Peter Hutterer 
---
 src/evdev.c | 131 +---
 1 file changed, 73 insertions(+), 58 deletions(-)

diff --git a/src/evdev.c b/src/evdev.c
index b0f2870..0687de0 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -1392,6 +1392,77 @@ evdev_init_rotation(struct evdev_device *device,
device->base.config.rotation = >rotation.config;
 }
 
+static inline int
+evdev_need_mtdev(struct evdev_device *device)
+{
+   struct libevdev *evdev = device->evdev;
+
+   return (libevdev_has_event_code(evdev, EV_ABS, ABS_MT_POSITION_X) &&
+   libevdev_has_event_code(evdev, EV_ABS, ABS_MT_POSITION_Y) &&
+   !libevdev_has_event_code(evdev, EV_ABS, ABS_MT_SLOT));
+}
+
+static inline int
+fallback_dispatch_init_slots(struct evdev_dispatch *dispatch,
+struct evdev_device *device)
+{
+   struct libevdev *evdev = device->evdev;
+   struct mt_slot *slots;
+   int num_slots;
+   int active_slot;
+   int slot;
+
+   if (!libevdev_has_event_code(evdev, EV_ABS, ABS_MT_POSITION_X) ||
+   !libevdev_has_event_code(evdev, EV_ABS, ABS_MT_POSITION_Y))
+return 0;
+
+   /* We only handle the slotted Protocol B in libinput.
+  Devices with ABS_MT_POSITION_* but not ABS_MT_SLOT
+  require mtdev for conversion. */
+   if (evdev_need_mtdev(device)) {
+   device->mtdev = mtdev_new_open(device->fd);
+   if (!device->mtdev)
+   return -1;
+
+   /* pick 10 slots as default for type A
+  devices. */
+   num_slots = 10;
+   active_slot = device->mtdev->caps.slot.value;
+   } else {
+   num_slots = libevdev_get_num_slots(device->evdev);
+   active_slot = libevdev_get_current_slot(evdev);
+   }
+
+   slots = calloc(num_slots, sizeof(struct mt_slot));
+   if (!slots)
+   return -1;
+
+   for (slot = 0; slot < num_slots; ++slot) {
+   slots[slot].seat_slot = -1;
+
+   if (evdev_need_mtdev(device))
+   continue;
+
+   slots[slot].point.x = libevdev_get_slot_value(evdev,
+ slot,
+ 
ABS_MT_POSITION_X);
+   slots[slot].point.y = libevdev_get_slot_value(evdev,
+ slot,
+ 
ABS_MT_POSITION_Y);
+   }
+   device->mt.slots = slots;
+   device->mt.slots_len = num_slots;
+   device->mt.slot = active_slot;
+
+   if (device->abs.absinfo_x->fuzz || device->abs.absinfo_y->fuzz) {
+   device->mt.want_hysteresis = true;
+   device->mt.hysteresis_margin.x = device->abs.absinfo_x->fuzz/2;
+   device->mt.hysteresis_margin.y = device->abs.absinfo_y->fuzz/2;
+   }
+
+   return 0;
+}
+
 static struct evdev_dispatch *
 fallback_dispatch_create(struct libinput_device *device)
 {
@@ -1403,6 +1474,8 @@ fallback_dispatch_create(struct libinput_device *device)
 
dispatch->interface = _interface;
 
+   fallback_dispatch_init_slots(dispatch, evdev_device);
+
if (evdev_device->left_handed.want_enabled)
evdev_init_left_handed(evdev_device,
   evdev_change_to_left_handed);
@@ -1671,16 +1744,6 @@ evdev_device_init_pointer_acceleration(struct 
evdev_device *device,
}
 }
 
-static inline bool
-evdev_need_mtdev(struct evdev_device *device)
-{
-   struct libevdev *evdev = device->evdev;
-
-   return (libevdev_has_event_code(evdev, EV_ABS, ABS_MT_POSITION_X) &&
-   libevdev_has_event_code(evdev, EV_ABS, ABS_MT_POSITION_Y) &&
-   !libevdev_has_event_code(evdev, EV_ABS, ABS_MT_SLOT));
-}
-
 static inline int
 evdev_read_wheel_click_prop(struct evdev_device *device)
 {
@@ -2057,10 +2120,6 @@ static bool
 evdev_configure_mt_device(struct evdev_device *device)
 {
struct libevdev *evdev = device->evdev;
-   struct mt_slot *slots;
-   int num_slots;
-   int active_slot;
-   int slot;
 
if (!libevdev_has_event_code(evdev, EV_ABS, ABS_MT_POSITION_X) ||
!libevdev_has_event_code(evdev, EV_ABS, ABS_MT_POSITION_Y))
@@ -2079,50 +2138,6 @@ evdev_configure_mt_device(struct evdev_device *device)
   device->abs.absinfo_y->minimum);
device->is_mt = 1;
 
-   /* We only handle the slotted Protocol B in libinput.
-  Devices with ABS_MT_POSITION_* but not ABS_MT_SLOT
-  require mtdev for conversion. */
-   if (evdev_need_mtdev(device)) {
-   device->mtdev = mtdev_new_open(device->fd);
-   if (!device->mtdev)
-   return 

[PATCH libinput 09/14] evdev: split evdev_dispatch and fallback_dispatch into separate entities

[Peter Hutterer]

Signed-off-by: Peter Hutterer 
---
 src/evdev-tablet.c |  2 +-
 src/evdev-tablet.h |  2 ++
 src/evdev.c| 81 +-
 src/evdev.h| 17 
 4 files changed, 58 insertions(+), 44 deletions(-)

diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
index f1dce27..8f24555 100644
--- a/src/evdev-tablet.c
+++ b/src/evdev-tablet.c
@@ -1535,7 +1535,7 @@ tablet_init_calibration(struct tablet_dispatch *tablet,
struct evdev_device *device)
 {
if (libevdev_has_property(device->evdev, INPUT_PROP_DIRECT))
-   evdev_init_calibration(device, >base);
+   evdev_init_calibration(device, >calibration);
 }
 
 static void
diff --git a/src/evdev-tablet.h b/src/evdev-tablet.h
index 57d627c..f66de5d 100644
--- a/src/evdev-tablet.h
+++ b/src/evdev-tablet.h
@@ -69,6 +69,8 @@ struct tablet_dispatch {
uint32_t current_tool_serial;
 
uint32_t cursor_proximity_threshold;
+
+   struct libinput_device_config_calibration calibration;
 };
 
 static inline enum libinput_tablet_tool_axis
diff --git a/src/evdev.c b/src/evdev.c
index 5d6b2a9..39eef9e 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -92,13 +92,13 @@ static const struct evdev_udev_tag_match 
evdev_udev_tag_matches[] = {
 };
 
 static void
-hw_set_key_down(struct evdev_dispatch *dispatch, int code, int pressed)
+hw_set_key_down(struct fallback_dispatch *dispatch, int code, int pressed)
 {
long_set_bit_state(dispatch->hw_key_mask, code, pressed);
 }
 
 static bool
-hw_is_key_down(struct evdev_dispatch *dispatch, int code)
+hw_is_key_down(struct fallback_dispatch *dispatch, int code)
 {
return long_bit_is_set(dispatch->hw_key_mask, code);
 }
@@ -132,7 +132,7 @@ update_key_down_count(struct evdev_device *device, int 
code, int pressed)
 }
 
 static void
-evdev_keyboard_notify_key(struct evdev_dispatch *dispatch,
+evdev_keyboard_notify_key(struct fallback_dispatch *dispatch,
  struct evdev_device *device,
  uint64_t time,
  int key,
@@ -350,7 +350,7 @@ evdev_post_trackpoint_scroll(struct evdev_device *device,
 static inline bool
 evdev_filter_defuzz_touch(struct evdev_device *device, struct mt_slot *slot)
 {
-   struct evdev_dispatch *dispatch = device->dispatch;
+   struct fallback_dispatch *dispatch = (struct 
fallback_dispatch*)device->dispatch;
struct device_coords point;
 
if (!dispatch->mt.want_hysteresis)
@@ -373,7 +373,7 @@ evdev_filter_defuzz_touch(struct evdev_device *device, 
struct mt_slot *slot)
 }
 
 static inline void
-evdev_rotate_relative(struct evdev_dispatch *dispatch,
+evdev_rotate_relative(struct fallback_dispatch *dispatch,
  struct evdev_device *device)
 {
struct device_coords rel = dispatch->rel;
@@ -391,7 +391,7 @@ evdev_rotate_relative(struct evdev_dispatch *dispatch,
 static void
 evdev_flush_pending_event(struct evdev_device *device, uint64_t time)
 {
-   struct evdev_dispatch *dispatch = device->dispatch;
+   struct fallback_dispatch *dispatch = (struct 
fallback_dispatch*)device->dispatch;
struct libinput *libinput = evdev_libinput_context(device);
int slot_idx;
int seat_slot;
@@ -602,7 +602,7 @@ static void
 evdev_process_touch_button(struct evdev_device *device,
   uint64_t time, int value)
 {
-   struct evdev_dispatch *dispatch = device->dispatch;
+   struct fallback_dispatch *dispatch = (struct 
fallback_dispatch*)device->dispatch;
 
if (dispatch->pending_event != EVDEV_NONE &&
dispatch->pending_event != EVDEV_ABSOLUTE_MOTION)
@@ -614,7 +614,7 @@ evdev_process_touch_button(struct evdev_device *device,
 }
 
 static inline void
-evdev_process_key(struct evdev_dispatch *dispatch,
+evdev_process_key(struct fallback_dispatch *dispatch,
  struct evdev_device *device,
  struct input_event *e, uint64_t time)
 {
@@ -677,7 +677,7 @@ evdev_process_touch(struct evdev_device *device,
struct input_event *e,
uint64_t time)
 {
-   struct evdev_dispatch *dispatch = device->dispatch;
+   struct fallback_dispatch *dispatch = (struct 
fallback_dispatch*)device->dispatch;
 
switch (e->code) {
case ABS_MT_SLOT:
@@ -718,7 +718,7 @@ static inline void
 evdev_process_absolute_motion(struct evdev_device *device,
  struct input_event *e)
 {
-   struct evdev_dispatch *dispatch = device->dispatch;
+   struct fallback_dispatch *dispatch = (struct 
fallback_dispatch*)device->dispatch;
 
switch (e->code) {
case ABS_X:
@@ -781,7 +781,7 @@ static inline void
 evdev_process_relative(struct evdev_device *device,
   struct input_event *e, uint64_t time)
 {
-   struct evdev_dispatch *dispatch = device->dispatch;
+   struct 

[PATCH libinput 08/14] evdev: move the keyboard mask into the fallback dispatch

[Peter Hutterer]

Signed-off-by: Peter Hutterer 
---
 src/evdev.c | 45 +++--
 src/evdev.h | 13 -
 2 files changed, 31 insertions(+), 27 deletions(-)

diff --git a/src/evdev.c b/src/evdev.c
index 620c6b7..5d6b2a9 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -92,15 +92,15 @@ static const struct evdev_udev_tag_match 
evdev_udev_tag_matches[] = {
 };
 
 static void
-hw_set_key_down(struct evdev_device *device, int code, int pressed)
+hw_set_key_down(struct evdev_dispatch *dispatch, int code, int pressed)
 {
-   long_set_bit_state(device->hw_key_mask, code, pressed);
+   long_set_bit_state(dispatch->hw_key_mask, code, pressed);
 }
 
 static bool
-hw_is_key_down(struct evdev_device *device, int code)
+hw_is_key_down(struct evdev_dispatch *dispatch, int code)
 {
-   return long_bit_is_set(device->hw_key_mask, code);
+   return long_bit_is_set(dispatch->hw_key_mask, code);
 }
 
 static int
@@ -131,8 +131,9 @@ update_key_down_count(struct evdev_device *device, int 
code, int pressed)
return key_count;
 }
 
-void
-evdev_keyboard_notify_key(struct evdev_device *device,
+static void
+evdev_keyboard_notify_key(struct evdev_dispatch *dispatch,
+ struct evdev_device *device,
  uint64_t time,
  int key,
  enum libinput_key_state state)
@@ -613,7 +614,8 @@ evdev_process_touch_button(struct evdev_device *device,
 }
 
 static inline void
-evdev_process_key(struct evdev_device *device,
+evdev_process_key(struct evdev_dispatch *dispatch,
+ struct evdev_device *device,
  struct input_event *e, uint64_t time)
 {
enum evdev_key_type type;
@@ -640,18 +642,19 @@ evdev_process_key(struct evdev_device *device,
break;
case EVDEV_KEY_TYPE_KEY:
case EVDEV_KEY_TYPE_BUTTON:
-   if (!hw_is_key_down(device, e->code))
+   if (!hw_is_key_down(dispatch, e->code))
return;
}
}
 
-   hw_set_key_down(device, e->code, e->value);
+   hw_set_key_down(dispatch, e->code, e->value);
 
switch (type) {
case EVDEV_KEY_TYPE_NONE:
break;
case EVDEV_KEY_TYPE_KEY:
evdev_keyboard_notify_key(
+   dispatch,
device,
time,
e->code,
@@ -839,13 +842,14 @@ evdev_process_absolute(struct evdev_device *device,
 }
 
 static inline bool
-evdev_any_button_down(struct evdev_device *device)
+evdev_any_button_down(struct evdev_dispatch *dispatch,
+ struct evdev_device *device)
 {
unsigned int button;
 
for (button = BTN_LEFT; button < BTN_JOYSTICK; button++) {
if (libevdev_has_event_code(device->evdev, EV_KEY, button) &&
-   hw_is_key_down(device, button))
+   hw_is_key_down(dispatch, button))
return true;
}
return false;
@@ -932,7 +936,7 @@ fallback_process(struct evdev_dispatch *dispatch,
evdev_process_absolute(device, event, time);
break;
case EV_KEY:
-   evdev_process_key(device, event, time);
+   evdev_process_key(dispatch, device, event, time);
break;
case EV_SYN:
need_frame = evdev_need_touch_frame(device);
@@ -944,7 +948,8 @@ fallback_process(struct evdev_dispatch *dispatch,
 }
 
 static void
-release_pressed_keys(struct evdev_device *device)
+release_pressed_keys(struct evdev_dispatch *dispatch,
+struct evdev_device *device)
 {
struct libinput *libinput = evdev_libinput_context(device);
uint64_t time;
@@ -971,6 +976,7 @@ release_pressed_keys(struct evdev_device *device)
break;
case EVDEV_KEY_TYPE_KEY:
evdev_keyboard_notify_key(
+   dispatch,
device,
time,
code,
@@ -999,7 +1005,8 @@ static void
 fallback_suspend(struct evdev_dispatch *dispatch,
 struct evdev_device *device)
 {
-   release_pressed_keys(device);
+   release_pressed_keys(dispatch, device);
+   memset(dispatch->hw_key_mask, 0, sizeof(dispatch->hw_key_mask));
 }
 
 static void
@@ -1120,10 +1127,12 @@ evdev_left_handed_has(struct libinput_device *device)
 static void
 evdev_change_to_left_handed(struct evdev_device *device)
 {
+   struct evdev_dispatch *dispatch = device->dispatch;
+
if (device->left_handed.want_enabled == device->left_handed.enabled)
return;
 
-   if (evdev_any_button_down(device))
+   if (evdev_any_button_down(dispatch, device))
return;
 

[PATCH libinput 13/14] evdev: pass the dispatch interface around

[Peter Hutterer]

The only places we should typecast from device->dispatch is where we have
external entry points. Everywhere else keep the pointer to the dispatch
interface we already have anyway.

This way we avoid papering over a potential re-use of a function from
non-evdev code, passing in the wrong dispatch.

Signed-off-by: Peter Hutterer 
---
 src/evdev.c | 74 +++--
 1 file changed, 38 insertions(+), 36 deletions(-)

diff --git a/src/evdev.c b/src/evdev.c
index 74693f1..6dc8302 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -348,9 +348,10 @@ evdev_post_trackpoint_scroll(struct evdev_device *device,
 }
 
 static inline bool
-evdev_filter_defuzz_touch(struct evdev_device *device, struct mt_slot *slot)
+evdev_filter_defuzz_touch(struct fallback_dispatch *dispatch,
+ struct evdev_device *device,
+ struct mt_slot *slot)
 {
-   struct fallback_dispatch *dispatch = (struct 
fallback_dispatch*)device->dispatch;
struct device_coords point;
 
if (!dispatch->mt.want_hysteresis)
@@ -389,9 +390,10 @@ evdev_rotate_relative(struct fallback_dispatch *dispatch,
 }
 
 static void
-evdev_flush_pending_event(struct evdev_device *device, uint64_t time)
+evdev_flush_pending_event(struct fallback_dispatch *dispatch,
+ struct evdev_device *device,
+ uint64_t time)
 {
-   struct fallback_dispatch *dispatch = (struct 
fallback_dispatch*)device->dispatch;
struct libinput *libinput = evdev_libinput_context(device);
int slot_idx;
int seat_slot;
@@ -479,7 +481,7 @@ evdev_flush_pending_event(struct evdev_device *device, 
uint64_t time)
if (seat_slot == -1)
break;
 
-   if (evdev_filter_defuzz_touch(device, slot))
+   if (evdev_filter_defuzz_touch(dispatch, device, slot))
break;
 
evdev_transform_absolute(device, );
@@ -599,14 +601,13 @@ get_key_type(uint16_t code)
 }
 
 static void
-evdev_process_touch_button(struct evdev_device *device,
+evdev_process_touch_button(struct fallback_dispatch *dispatch,
+  struct evdev_device *device,
   uint64_t time, int value)
 {
-   struct fallback_dispatch *dispatch = (struct 
fallback_dispatch*)device->dispatch;
-
if (dispatch->pending_event != EVDEV_NONE &&
dispatch->pending_event != EVDEV_ABSOLUTE_MOTION)
-   evdev_flush_pending_event(device, time);
+   evdev_flush_pending_event(dispatch, device, time);
 
dispatch->pending_event = (value ?
 EVDEV_ABSOLUTE_TOUCH_DOWN :
@@ -626,11 +627,14 @@ evdev_process_key(struct fallback_dispatch *dispatch,
 
if (e->code == BTN_TOUCH) {
if (!device->is_mt)
-   evdev_process_touch_button(device, time, e->value);
+   evdev_process_touch_button(dispatch,
+  device,
+  time,
+  e->value);
return;
}
 
-   evdev_flush_pending_event(device, time);
+   evdev_flush_pending_event(dispatch, device, time);
 
type = get_key_type(e->code);
 
@@ -673,12 +677,11 @@ evdev_process_key(struct fallback_dispatch *dispatch,
 }
 
 static void
-evdev_process_touch(struct evdev_device *device,
+evdev_process_touch(struct fallback_dispatch *dispatch,
+   struct evdev_device *device,
struct input_event *e,
uint64_t time)
 {
-   struct fallback_dispatch *dispatch = (struct 
fallback_dispatch*)device->dispatch;
-
switch (e->code) {
case ABS_MT_SLOT:
if ((size_t)e->value >= dispatch->mt.slots_len) {
@@ -689,13 +692,13 @@ evdev_process_touch(struct evdev_device *device,
 dispatch->mt.slots_len);
e->value = dispatch->mt.slots_len - 1;
}
-   evdev_flush_pending_event(device, time);
+   evdev_flush_pending_event(dispatch, device, time);
dispatch->mt.slot = e->value;
break;
case ABS_MT_TRACKING_ID:
if (dispatch->pending_event != EVDEV_NONE &&
dispatch->pending_event != EVDEV_ABSOLUTE_MT_MOTION)
-   evdev_flush_pending_event(device, time);
+   evdev_flush_pending_event(dispatch, device, time);
if (e->value >= 0)
dispatch->pending_event = EVDEV_ABSOLUTE_MT_DOWN;
else
@@ -713,13 +716,11 @@ evdev_process_touch(struct evdev_device *device,
break;
}
 }
-
 static inline void
-evdev_process_absolute_motion(struct evdev_device 

[PATCH libinput 10/14] evdev: reshuffle the evdev_device struct fields

[Peter Hutterer]

Have the ungrouped items at the top of the struct for better visibility.

Signed-off-by: Peter Hutterer 
---
 src/evdev.h | 24 ++--
 1 file changed, 10 insertions(+), 14 deletions(-)

diff --git a/src/evdev.h b/src/evdev.h
index f592032..7bc09d2 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -138,6 +138,16 @@ struct evdev_device {
const char *devname;
bool was_removed;
int fd;
+   enum evdev_device_seat_capability seat_caps;
+   enum evdev_device_tags tags;
+   int is_mt;
+   int suspended;
+   int dpi; /* HW resolution */
+   struct ratelimit syn_drop_limit; /* ratelimit for SYN_DROPPED logging */
+   struct ratelimit nonpointer_rel_limit; /* ratelimit for REL_* events 
from non-pointer devices */
+   uint32_t model_flags;
+   struct mtdev *mtdev;
+
struct {
const struct input_absinfo *absinfo_x, *absinfo_y;
int fake_resolution;
@@ -153,8 +163,6 @@ struct evdev_device {
struct device_coords dimensions;
} abs;
 
-   struct mtdev *mtdev;
-
struct {
struct libinput_timer timer;
struct libinput_device_config_scroll_method config;
@@ -185,12 +193,6 @@ struct evdev_device {
int wheel_click_angle;
} scroll;
 
-   enum evdev_device_seat_capability seat_caps;
-   enum evdev_device_tags tags;
-
-   int is_mt;
-   int suspended;
-
struct {
struct libinput_device_config_accel config;
struct motion_filter *filter;
@@ -222,12 +224,6 @@ struct evdev_device {
uint32_t button_mask;
uint64_t first_event_time;
} middlebutton;
-
-   int dpi; /* HW resolution */
-   struct ratelimit syn_drop_limit; /* ratelimit for SYN_DROPPED logging */
-   struct ratelimit nonpointer_rel_limit; /* ratelimit for REL_* events 
from non-pointer devices */
-
-   uint32_t model_flags;
 };
 
 #define EVDEV_UNHANDLED_DEVICE ((struct evdev_device *) 1)
-- 
2.7.4

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH libinput 14/14] evdev: rename all fallback-specific functions to a fallback_ prefix

[Peter Hutterer]

Signed-off-by: Peter Hutterer 
---
 src/evdev.c | 132 ++--
 1 file changed, 66 insertions(+), 66 deletions(-)

diff --git a/src/evdev.c b/src/evdev.c
index 6dc8302..a4dd74c 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -132,11 +132,11 @@ update_key_down_count(struct evdev_device *device, int 
code, int pressed)
 }
 
 static void
-evdev_keyboard_notify_key(struct fallback_dispatch *dispatch,
- struct evdev_device *device,
- uint64_t time,
- int key,
- enum libinput_key_state state)
+fallback_keyboard_notify_key(struct fallback_dispatch *dispatch,
+struct evdev_device *device,
+uint64_t time,
+int key,
+enum libinput_key_state state)
 {
int down_count;
 
@@ -348,9 +348,9 @@ evdev_post_trackpoint_scroll(struct evdev_device *device,
 }
 
 static inline bool
-evdev_filter_defuzz_touch(struct fallback_dispatch *dispatch,
- struct evdev_device *device,
- struct mt_slot *slot)
+fallback_filter_defuzz_touch(struct fallback_dispatch *dispatch,
+struct evdev_device *device,
+struct mt_slot *slot)
 {
struct device_coords point;
 
@@ -374,8 +374,8 @@ evdev_filter_defuzz_touch(struct fallback_dispatch 
*dispatch,
 }
 
 static inline void
-evdev_rotate_relative(struct fallback_dispatch *dispatch,
- struct evdev_device *device)
+fallback_rotate_relative(struct fallback_dispatch *dispatch,
+struct evdev_device *device)
 {
struct device_coords rel = dispatch->rel;
 
@@ -390,9 +390,9 @@ evdev_rotate_relative(struct fallback_dispatch *dispatch,
 }
 
 static void
-evdev_flush_pending_event(struct fallback_dispatch *dispatch,
- struct evdev_device *device,
- uint64_t time)
+fallback_flush_pending_event(struct fallback_dispatch *dispatch,
+struct evdev_device *device,
+uint64_t time)
 {
struct libinput *libinput = evdev_libinput_context(device);
int slot_idx;
@@ -415,7 +415,7 @@ evdev_flush_pending_event(struct fallback_dispatch 
*dispatch,
if (!(device->seat_caps & EVDEV_DEVICE_POINTER))
break;
 
-   evdev_rotate_relative(dispatch, device);
+   fallback_rotate_relative(dispatch, device);
 
normalize_delta(device, >rel, );
raw.x = dispatch->rel.x;
@@ -481,7 +481,7 @@ evdev_flush_pending_event(struct fallback_dispatch 
*dispatch,
if (seat_slot == -1)
break;
 
-   if (evdev_filter_defuzz_touch(dispatch, device, slot))
+   if (fallback_filter_defuzz_touch(dispatch, device, slot))
break;
 
evdev_transform_absolute(device, );
@@ -601,13 +601,13 @@ get_key_type(uint16_t code)
 }
 
 static void
-evdev_process_touch_button(struct fallback_dispatch *dispatch,
-  struct evdev_device *device,
-  uint64_t time, int value)
+fallback_process_touch_button(struct fallback_dispatch *dispatch,
+ struct evdev_device *device,
+ uint64_t time, int value)
 {
if (dispatch->pending_event != EVDEV_NONE &&
dispatch->pending_event != EVDEV_ABSOLUTE_MOTION)
-   evdev_flush_pending_event(dispatch, device, time);
+   fallback_flush_pending_event(dispatch, device, time);
 
dispatch->pending_event = (value ?
 EVDEV_ABSOLUTE_TOUCH_DOWN :
@@ -615,9 +615,9 @@ evdev_process_touch_button(struct fallback_dispatch 
*dispatch,
 }
 
 static inline void
-evdev_process_key(struct fallback_dispatch *dispatch,
- struct evdev_device *device,
- struct input_event *e, uint64_t time)
+fallback_process_key(struct fallback_dispatch *dispatch,
+struct evdev_device *device,
+struct input_event *e, uint64_t time)
 {
enum evdev_key_type type;
 
@@ -627,14 +627,14 @@ evdev_process_key(struct fallback_dispatch *dispatch,
 
if (e->code == BTN_TOUCH) {
if (!device->is_mt)
-   evdev_process_touch_button(dispatch,
-  device,
-  time,
-  e->value);
+   fallback_process_touch_button(dispatch,
+ device,
+ time,
+

[PATCH libinput 12/14] evdev: move the abs point into the fallback dispatch

[Peter Hutterer]

Signed-off-by: Peter Hutterer 
---
 src/evdev.c | 34 ++
 src/evdev.h |  8 +---
 2 files changed, 27 insertions(+), 15 deletions(-)

diff --git a/src/evdev.c b/src/evdev.c
index 44b0be5..74693f1 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -504,7 +504,7 @@ evdev_flush_pending_event(struct evdev_device *device, 
uint64_t time)
if (!(device->seat_caps & EVDEV_DEVICE_TOUCH))
break;
 
-   if (device->abs.seat_slot != -1) {
+   if (dispatch->abs.seat_slot != -1) {
log_bug_kernel(libinput,
   "%s: Driver sent multiple touch down for 
the "
   "same slot",
@@ -513,24 +513,24 @@ evdev_flush_pending_event(struct evdev_device *device, 
uint64_t time)
}
 
seat_slot = ffs(~seat->slot_map) - 1;
-   device->abs.seat_slot = seat_slot;
+   dispatch->abs.seat_slot = seat_slot;
 
if (seat_slot == -1)
break;
 
seat->slot_map |= 1 << seat_slot;
 
-   point = device->abs.point;
+   point = dispatch->abs.point;
evdev_transform_absolute(device, );
 
touch_notify_touch_down(base, time, -1, seat_slot, );
break;
case EVDEV_ABSOLUTE_MOTION:
-   point = device->abs.point;
+   point = dispatch->abs.point;
evdev_transform_absolute(device, );
 
if (device->seat_caps & EVDEV_DEVICE_TOUCH) {
-   seat_slot = device->abs.seat_slot;
+   seat_slot = dispatch->abs.seat_slot;
 
if (seat_slot == -1)
break;
@@ -545,8 +545,8 @@ evdev_flush_pending_event(struct evdev_device *device, 
uint64_t time)
if (!(device->seat_caps & EVDEV_DEVICE_TOUCH))
break;
 
-   seat_slot = device->abs.seat_slot;
-   device->abs.seat_slot = -1;
+   seat_slot = dispatch->abs.seat_slot;
+   dispatch->abs.seat_slot = -1;
 
if (seat_slot == -1)
break;
@@ -722,12 +722,12 @@ evdev_process_absolute_motion(struct evdev_device *device,
 
switch (e->code) {
case ABS_X:
-   device->abs.point.x = e->value;
+   dispatch->abs.point.x = e->value;
if (dispatch->pending_event == EVDEV_NONE)
dispatch->pending_event = EVDEV_ABSOLUTE_MOTION;
break;
case ABS_Y:
-   device->abs.point.y = e->value;
+   dispatch->abs.point.y = e->value;
if (dispatch->pending_event == EVDEV_NONE)
dispatch->pending_event = EVDEV_ABSOLUTE_MOTION;
break;
@@ -1514,6 +1514,18 @@ fallback_dispatch_init_rel(struct fallback_dispatch 
*dispatch,
dispatch->rel.y = 0;
 }
 
+static inline void
+fallback_dispatch_init_abs(struct fallback_dispatch *dispatch,
+  struct evdev_device *device)
+{
+   if (!libevdev_has_event_code(device->evdev, EV_ABS, ABS_X))
+   return;
+
+   dispatch->abs.point.x = device->abs.absinfo_x->value;
+   dispatch->abs.point.y = device->abs.absinfo_y->value;
+   dispatch->abs.seat_slot = -1;
+}
+
 static struct evdev_dispatch *
 fallback_dispatch_create(struct libinput_device *device)
 {
@@ -1527,6 +1539,7 @@ fallback_dispatch_create(struct libinput_device *device)
dispatch->pending_event = EVDEV_NONE;
 
fallback_dispatch_init_rel(dispatch, evdev_device);
+   fallback_dispatch_init_abs(dispatch, evdev_device);
if (fallback_dispatch_init_slots(dispatch, evdev_device) == -1) {
free(dispatch);
return NULL;
@@ -2173,8 +2186,6 @@ evdev_extract_abs_axes(struct evdev_device *device)
device->abs.is_fake_resolution = true;
device->abs.absinfo_x = libevdev_get_abs_info(evdev, ABS_X);
device->abs.absinfo_y = libevdev_get_abs_info(evdev, ABS_Y);
-   device->abs.point.x = device->abs.absinfo_x->value;
-   device->abs.point.y = device->abs.absinfo_y->value;
device->abs.dimensions.x = abs(device->abs.absinfo_x->maximum -
   device->abs.absinfo_x->minimum);
device->abs.dimensions.y = abs(device->abs.absinfo_y->maximum -
@@ -2530,7 +2541,6 @@ evdev_device_create(struct libinput_seat *seat,
device->is_mt = 0;
device->mtdev = NULL;
device->udev_device = udev_device_ref(udev_device);
-   device->abs.seat_slot = -1;
device->dispatch = NULL;
device->fd = fd;
device->devname = libevdev_get_name(device->evdev);
diff --git a/src/evdev.h b/src/evdev.h
index c56c76f..8279286 100644
--- a/src/evdev.h
+++ 

[PATCH libinput 07/14] evdev: move pending_event to the evdev_dispatch struct

[Peter Hutterer]

Signed-off-by: Peter Hutterer 
---
 src/evdev.c | 52 +---
 src/evdev.h |  3 ++-
 2 files changed, 31 insertions(+), 24 deletions(-)

diff --git a/src/evdev.c b/src/evdev.c
index e68eab4..620c6b7 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -405,7 +405,7 @@ evdev_flush_pending_event(struct evdev_device *device, 
uint64_t time)
if (dispatch->mt.slots)
slot = >mt.slots[slot_idx];
 
-   switch (device->pending_event) {
+   switch (dispatch->pending_event) {
case EVDEV_NONE:
return;
case EVDEV_RELATIVE_MOTION:
@@ -559,7 +559,7 @@ evdev_flush_pending_event(struct evdev_device *device, 
uint64_t time)
break;
}
 
-   device->pending_event = EVDEV_NONE;
+   dispatch->pending_event = EVDEV_NONE;
 }
 
 static enum evdev_key_type
@@ -601,11 +601,13 @@ static void
 evdev_process_touch_button(struct evdev_device *device,
   uint64_t time, int value)
 {
-   if (device->pending_event != EVDEV_NONE &&
-   device->pending_event != EVDEV_ABSOLUTE_MOTION)
+   struct evdev_dispatch *dispatch = device->dispatch;
+
+   if (dispatch->pending_event != EVDEV_NONE &&
+   dispatch->pending_event != EVDEV_ABSOLUTE_MOTION)
evdev_flush_pending_event(device, time);
 
-   device->pending_event = (value ?
+   dispatch->pending_event = (value ?
 EVDEV_ABSOLUTE_TOUCH_DOWN :
 EVDEV_ABSOLUTE_TOUCH_UP);
 }
@@ -688,23 +690,23 @@ evdev_process_touch(struct evdev_device *device,
dispatch->mt.slot = e->value;
break;
case ABS_MT_TRACKING_ID:
-   if (device->pending_event != EVDEV_NONE &&
-   device->pending_event != EVDEV_ABSOLUTE_MT_MOTION)
+   if (dispatch->pending_event != EVDEV_NONE &&
+   dispatch->pending_event != EVDEV_ABSOLUTE_MT_MOTION)
evdev_flush_pending_event(device, time);
if (e->value >= 0)
-   device->pending_event = EVDEV_ABSOLUTE_MT_DOWN;
+   dispatch->pending_event = EVDEV_ABSOLUTE_MT_DOWN;
else
-   device->pending_event = EVDEV_ABSOLUTE_MT_UP;
+   dispatch->pending_event = EVDEV_ABSOLUTE_MT_UP;
break;
case ABS_MT_POSITION_X:
dispatch->mt.slots[dispatch->mt.slot].point.x = e->value;
-   if (device->pending_event == EVDEV_NONE)
-   device->pending_event = EVDEV_ABSOLUTE_MT_MOTION;
+   if (dispatch->pending_event == EVDEV_NONE)
+   dispatch->pending_event = EVDEV_ABSOLUTE_MT_MOTION;
break;
case ABS_MT_POSITION_Y:
dispatch->mt.slots[dispatch->mt.slot].point.y = e->value;
-   if (device->pending_event == EVDEV_NONE)
-   device->pending_event = EVDEV_ABSOLUTE_MT_MOTION;
+   if (dispatch->pending_event == EVDEV_NONE)
+   dispatch->pending_event = EVDEV_ABSOLUTE_MT_MOTION;
break;
}
 }
@@ -713,16 +715,18 @@ static inline void
 evdev_process_absolute_motion(struct evdev_device *device,
  struct input_event *e)
 {
+   struct evdev_dispatch *dispatch = device->dispatch;
+
switch (e->code) {
case ABS_X:
device->abs.point.x = e->value;
-   if (device->pending_event == EVDEV_NONE)
-   device->pending_event = EVDEV_ABSOLUTE_MOTION;
+   if (dispatch->pending_event == EVDEV_NONE)
+   dispatch->pending_event = EVDEV_ABSOLUTE_MOTION;
break;
case ABS_Y:
device->abs.point.y = e->value;
-   if (device->pending_event == EVDEV_NONE)
-   device->pending_event = EVDEV_ABSOLUTE_MOTION;
+   if (dispatch->pending_event == EVDEV_NONE)
+   dispatch->pending_event = EVDEV_ABSOLUTE_MOTION;
break;
}
 }
@@ -783,16 +787,16 @@ evdev_process_relative(struct evdev_device *device,
 
switch (e->code) {
case REL_X:
-   if (device->pending_event != EVDEV_RELATIVE_MOTION)
+   if (dispatch->pending_event != EVDEV_RELATIVE_MOTION)
evdev_flush_pending_event(device, time);
dispatch->rel.x += e->value;
-   device->pending_event = EVDEV_RELATIVE_MOTION;
+   dispatch->pending_event = EVDEV_RELATIVE_MOTION;
break;
case REL_Y:
-   if (device->pending_event != EVDEV_RELATIVE_MOTION)
+   if (dispatch->pending_event != EVDEV_RELATIVE_MOTION)
evdev_flush_pending_event(device, time);

[PATCH libinput 04/14] evdev: move axis dimension handling into a single helper function

[Peter Hutterer]

Signed-off-by: Peter Hutterer 
---
 src/evdev.c | 42 ++
 1 file changed, 22 insertions(+), 20 deletions(-)

diff --git a/src/evdev.c b/src/evdev.c
index 0687de0..a7b77c8 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -2116,14 +2116,30 @@ evdev_reject_device(struct evdev_device *device)
return false;
 }
 
-static bool
-evdev_configure_mt_device(struct evdev_device *device)
+static void
+evdev_extract_abs_axes(struct evdev_device *device)
 {
struct libevdev *evdev = device->evdev;
 
-   if (!libevdev_has_event_code(evdev, EV_ABS, ABS_MT_POSITION_X) ||
+   if (!libevdev_has_event_code(evdev, EV_ABS, ABS_X) ||
+   !libevdev_has_event_code(evdev, EV_ABS, ABS_Y))
+return;
+
+   if (evdev_fix_abs_resolution(device, ABS_X, ABS_Y))
+   device->abs.fake_resolution = 1;
+   device->abs.absinfo_x = libevdev_get_abs_info(evdev, ABS_X);
+   device->abs.absinfo_y = libevdev_get_abs_info(evdev, ABS_Y);
+   device->abs.point.x = device->abs.absinfo_x->value;
+   device->abs.point.y = device->abs.absinfo_y->value;
+   device->abs.dimensions.x = abs(device->abs.absinfo_x->maximum -
+  device->abs.absinfo_x->minimum);
+   device->abs.dimensions.y = abs(device->abs.absinfo_y->maximum -
+  device->abs.absinfo_y->minimum);
+
+   if (evdev_is_fake_mt_device(device) ||
+   !libevdev_has_event_code(evdev, EV_ABS, ABS_MT_POSITION_X) ||
!libevdev_has_event_code(evdev, EV_ABS, ABS_MT_POSITION_Y))
-return true;
+return;
 
if (evdev_fix_abs_resolution(device,
 ABS_MT_POSITION_X,
@@ -2137,8 +2153,6 @@ evdev_configure_mt_device(struct evdev_device *device)
device->abs.dimensions.y = abs(device->abs.absinfo_y->maximum -
   device->abs.absinfo_y->minimum);
device->is_mt = 1;
-
-   return true;
 }
 
 static struct evdev_dispatch *
@@ -2201,22 +2215,10 @@ evdev_configure_device(struct evdev_device *device)
evdev_fix_android_mt(device);
 
if (libevdev_has_event_code(evdev, EV_ABS, ABS_X)) {
-   if (evdev_fix_abs_resolution(device, ABS_X, ABS_Y))
-   device->abs.fake_resolution = 1;
-   device->abs.absinfo_x = libevdev_get_abs_info(evdev, ABS_X);
-   device->abs.absinfo_y = libevdev_get_abs_info(evdev, ABS_Y);
-   device->abs.point.x = device->abs.absinfo_x->value;
-   device->abs.point.y = device->abs.absinfo_y->value;
-   device->abs.dimensions.x = abs(device->abs.absinfo_x->maximum -
-  device->abs.absinfo_x->minimum);
-   device->abs.dimensions.y = abs(device->abs.absinfo_y->maximum -
-  device->abs.absinfo_y->minimum);
+   evdev_extract_abs_axes(device);
 
-   if (evdev_is_fake_mt_device(device)) {
+   if (evdev_is_fake_mt_device(device))
udev_tags &= ~EVDEV_UDEV_TAG_TOUCHSCREEN;
-   } else if (!evdev_configure_mt_device(device)) {
-   return NULL;
-   }
}
 
/* libwacom assigns touchpad (or touchscreen) _and_ tablet to the
-- 
2.7.4

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH libinput 02/14] evdev: return the dispatch method from evdev_configure_device

[Peter Hutterer]

Rather than setting a magic device field and returning true/false just return
the dispatch method.

Signed-off-by: Peter Hutterer 
---
 src/evdev.c | 43 +++
 1 file changed, 19 insertions(+), 24 deletions(-)

diff --git a/src/evdev.c b/src/evdev.c
index 1f77bc0..b0f2870 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -2126,7 +2126,7 @@ evdev_configure_mt_device(struct evdev_device *device)
return true;
 }
 
-static bool
+static struct evdev_dispatch *
 evdev_configure_device(struct evdev_device *device)
 {
struct libinput *libinput = evdev_libinput_context(device);
@@ -2134,6 +2134,7 @@ evdev_configure_device(struct evdev_device *device)
const char *devnode = udev_device_get_devnode(device->udev_device);
enum evdev_device_udev_tags udev_tags;
unsigned int tablet_tags;
+   struct evdev_dispatch *dispatch;
 
udev_tags = evdev_device_get_udev_tags(device, device->udev_device);
 
@@ -2142,7 +2143,7 @@ evdev_configure_device(struct evdev_device *device)
log_info(libinput,
 "input device '%s', %s not tagged as input device\n",
 device->devname, devnode);
-   return false;
+   return NULL;
}
 
log_info(libinput,
@@ -2162,7 +2163,7 @@ evdev_configure_device(struct evdev_device *device)
log_info(libinput,
 "input device '%s', %s is an accelerometer, 
ignoring\n",
 device->devname, devnode);
-   return false;
+   return NULL;
}
 
/* libwacom *adds* TABLET, TOUCHPAD but leaves JOYSTICK in place, so
@@ -2171,14 +2172,14 @@ evdev_configure_device(struct evdev_device *device)
log_info(libinput,
 "input device '%s', %s is a joystick, ignoring\n",
 device->devname, devnode);
-   return false;
+   return NULL;
}
 
if (evdev_reject_device(device)) {
log_info(libinput,
 "input device '%s', %s was rejected.\n",
 device->devname, devnode);
-   return false;
+   return NULL;
}
 
if (!evdev_is_fake_mt_device(device))
@@ -2199,7 +2200,7 @@ evdev_configure_device(struct evdev_device *device)
if (evdev_is_fake_mt_device(device)) {
udev_tags &= ~EVDEV_UDEV_TAG_TOUCHSCREEN;
} else if (!evdev_configure_mt_device(device)) {
-   return false;
+   return NULL;
}
}
 
@@ -2212,29 +2213,29 @@ evdev_configure_device(struct evdev_device *device)
 
/* libwacom assigns tablet _and_ tablet_pad to the pad devices */
if (udev_tags & EVDEV_UDEV_TAG_TABLET_PAD) {
-   device->dispatch = evdev_tablet_pad_create(device);
+   dispatch = evdev_tablet_pad_create(device);
device->seat_caps |= EVDEV_DEVICE_TABLET_PAD;
log_info(libinput,
 "input device '%s', %s is a tablet pad\n",
 device->devname, devnode);
-   return device->dispatch != NULL;
+   return dispatch;
 
} else if ((udev_tags & tablet_tags) == EVDEV_UDEV_TAG_TABLET) {
-   device->dispatch = evdev_tablet_create(device);
+   dispatch = evdev_tablet_create(device);
device->seat_caps |= EVDEV_DEVICE_TABLET;
log_info(libinput,
 "input device '%s', %s is a tablet\n",
 device->devname, devnode);
-   return device->dispatch != NULL;
+   return dispatch;
}
 
if (udev_tags & EVDEV_UDEV_TAG_TOUCHPAD) {
-   device->dispatch = evdev_mt_touchpad_create(device);
+   dispatch = evdev_mt_touchpad_create(device);
log_info(libinput,
 "input device '%s', %s is a touchpad\n",
 device->devname, devnode);
 
-   return device->dispatch != NULL;
+   return dispatch;
}
 
if (udev_tags & EVDEV_UDEV_TAG_MOUSE ||
@@ -2287,12 +2288,10 @@ evdev_configure_device(struct evdev_device *device)
log_error(libinput,
  "failed to initialize pointer acceleration for %s\n",
  device->devname);
-   return false;
+   return NULL;
}
 
-   device->dispatch = fallback_dispatch_create(>base);
-
-   return true;
+   return fallback_dispatch_create(>base);
 }
 
 static void
@@ -2495,17 +2494,13 @@ evdev_device_create(struct libinput_seat *seat,
 
evdev_pre_configure_model_quirks(device);
 
-   if (!evdev_configure_device(device))
-   goto err;
-
-   if 

[PATCH libinput 05/14] evdev: move the mt struct into the evdev dispatch struct

[Peter Hutterer]

This is only used by the fallback dispatch method, not by any of the others.
Anything dispatch-specific should go into that struct.

Signed-off-by: Peter Hutterer 
---
 src/evdev.c | 74 ++---
 src/evdev.h | 15 +++--
 2 files changed, 49 insertions(+), 40 deletions(-)

diff --git a/src/evdev.c b/src/evdev.c
index a7b77c8..140fa73 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -349,17 +349,18 @@ evdev_post_trackpoint_scroll(struct evdev_device *device,
 static inline bool
 evdev_filter_defuzz_touch(struct evdev_device *device, struct mt_slot *slot)
 {
+   struct evdev_dispatch *dispatch = device->dispatch;
struct device_coords point;
 
-   if (!device->mt.want_hysteresis)
+   if (!dispatch->mt.want_hysteresis)
return false;
 
point.x = evdev_hysteresis(slot->point.x,
   slot->hysteresis_center.x,
-  device->mt.hysteresis_margin.x);
+  dispatch->mt.hysteresis_margin.x);
point.y = evdev_hysteresis(slot->point.y,
   slot->hysteresis_center.y,
-  device->mt.hysteresis_margin.y);
+  dispatch->mt.hysteresis_margin.y);
 
slot->hysteresis_center = slot->point;
if (point.x == slot->point.x && point.y == slot->point.y)
@@ -389,6 +390,7 @@ evdev_rotate_relative(struct evdev_device *device)
 static void
 evdev_flush_pending_event(struct evdev_device *device, uint64_t time)
 {
+   struct evdev_dispatch *dispatch = device->dispatch;
struct libinput *libinput = evdev_libinput_context(device);
int slot_idx;
int seat_slot;
@@ -399,9 +401,9 @@ evdev_flush_pending_event(struct evdev_device *device, 
uint64_t time)
struct device_float_coords raw;
struct mt_slot *slot = NULL;
 
-   slot_idx = device->mt.slot;
-   if (device->mt.slots)
-   slot = >mt.slots[slot_idx];
+   slot_idx = dispatch->mt.slot;
+   if (dispatch->mt.slots)
+   slot = >mt.slots[slot_idx];
 
switch (device->pending_event) {
case EVDEV_NONE:
@@ -670,18 +672,20 @@ evdev_process_touch(struct evdev_device *device,
struct input_event *e,
uint64_t time)
 {
+   struct evdev_dispatch *dispatch = device->dispatch;
+
switch (e->code) {
case ABS_MT_SLOT:
-   if ((size_t)e->value >= device->mt.slots_len) {
+   if ((size_t)e->value >= dispatch->mt.slots_len) {
log_bug_libinput(evdev_libinput_context(device),
 "%s exceeds slots (%d of %zd)\n",
 device->devname,
 e->value,
-device->mt.slots_len);
-   e->value = device->mt.slots_len - 1;
+dispatch->mt.slots_len);
+   e->value = dispatch->mt.slots_len - 1;
}
evdev_flush_pending_event(device, time);
-   device->mt.slot = e->value;
+   dispatch->mt.slot = e->value;
break;
case ABS_MT_TRACKING_ID:
if (device->pending_event != EVDEV_NONE &&
@@ -693,12 +697,12 @@ evdev_process_touch(struct evdev_device *device,
device->pending_event = EVDEV_ABSOLUTE_MT_UP;
break;
case ABS_MT_POSITION_X:
-   device->mt.slots[device->mt.slot].point.x = e->value;
+   dispatch->mt.slots[dispatch->mt.slot].point.x = e->value;
if (device->pending_event == EVDEV_NONE)
device->pending_event = EVDEV_ABSOLUTE_MT_MOTION;
break;
case ABS_MT_POSITION_Y:
-   device->mt.slots[device->mt.slot].point.y = e->value;
+   dispatch->mt.slots[dispatch->mt.slot].point.y = e->value;
if (device->pending_event == EVDEV_NONE)
device->pending_event = EVDEV_ABSOLUTE_MT_MOTION;
break;
@@ -994,6 +998,7 @@ fallback_suspend(struct evdev_dispatch *dispatch,
 static void
 fallback_destroy(struct evdev_dispatch *dispatch)
 {
+   free(dispatch->mt.slots);
free(dispatch);
 }
 
@@ -1402,6 +1407,18 @@ evdev_need_mtdev(struct evdev_device *device)
!libevdev_has_event_code(evdev, EV_ABS, ABS_MT_SLOT));
 }
 
+/* Fake MT devices have the ABS_MT_SLOT bit set because of
+   the limited ABS_* range - they aren't MT devices, they
+   just have too many ABS_ axes */
+static inline bool
+evdev_is_fake_mt_device(struct evdev_device *device)
+{
+   struct libevdev *evdev = device->evdev;
+
+   return libevdev_has_event_code(evdev, EV_ABS, ABS_MT_SLOT) &&
+   

[PATCH libinput 00/14] evdev dispatch cleanup

[Peter Hutterer]

This patchset cleans up the split between the device-specific dispatch and
the generic evdev_device struct. Before anything that would go into the
fallback dispatch (mouse, keyboards, ...) was stored in the evdev_device.
This led to some duplication, e.g. the 'mt' struct wasn't used for touchpads
who keep track for MT information in other ways.

This patchset cleans up that mix, moving everything that's fallback-dispatch
specific into a new struct, leaving the device with the truly generic info.

No functionality added or changed, this is internal reshuffling only.

Cheers,
  Peter
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH libinput 01/14] evdev: move the fallback dispatch creation to evdev_configure_device

[Peter Hutterer]

All the other devices are created in there too, unify that approach.

Signed-off-by: Peter Hutterer 
---
 src/evdev.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/src/evdev.c b/src/evdev.c
index aeb21eb..1f77bc0 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -2290,6 +2290,8 @@ evdev_configure_device(struct evdev_device *device)
return false;
}
 
+   device->dispatch = fallback_dispatch_create(>base);
+
return true;
 }
 
@@ -2501,9 +2503,6 @@ evdev_device_create(struct libinput_seat *seat,
goto err;
}
 
-   /* If the dispatch was not set up use the fallback. */
-   if (device->dispatch == NULL)
-   device->dispatch = fallback_dispatch_create(>base);
if (device->dispatch == NULL)
goto err;
 
-- 
2.7.4

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH v2 libinput] udev: check wacom devices for a paired product id

[Peter Hutterer]

The newer Wacom Cintiqs have touch devices with a different PID than the pen
device. Use the new libwacom_get_paired_device call where available to pair
the two devices and give them the same device group.

This isn't that important just yet, so no need to force users to update to a
new libwacom version.

Signed-off-by: Peter Hutterer 
Tested-by: Benjamin Tissoires 
---
Changes to v1:
- use AC_LINK_IFELSE instead of AC_CHECK_LIB
- re-instate the libinput-util include that got lost during a rebase (needed
  for the VENDOR_ID_WACOM define)

 configure.ac | 19 +
 udev/Makefile.am |  9 ++-
 udev/libinput-device-group.c | 64 ++--
 3 files changed, 89 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index 9e238b4..b6f7555 100644
--- a/configure.ac
+++ b/configure.ac
@@ -208,7 +208,26 @@ AC_ARG_ENABLE(libwacom,
 if test "x$use_libwacom" = "xyes"; then
PKG_CHECK_MODULES(LIBWACOM, [libwacom >= 0.12], [HAVE_LIBWACOM="yes"])
AC_DEFINE(HAVE_LIBWACOM, 1, [Build with libwacom])
+
+   OLD_LIBS=$LIBS
+   OLD_CFLAGS=$CFLAGS
+   LIBS="$LIBS $LIBWACOM_LIBS"
+   CFLAGS="$CFLAGS $LIBWACOM_CFLAGS"
+   AC_MSG_CHECKING([if libwacom_get_paired_device is available])
+   AC_LINK_IFELSE(
+  [AC_LANG_PROGRAM([[#include ]],
+   [[libwacom_get_paired_device(NULL)]])],
+  [AC_MSG_RESULT([yes])
+   AC_DEFINE(HAVE_LIBWACOM_GET_PAIRED_DEVICE, [1],
+ [libwacom_get_paired_device() is available])
+   [libwacom_have_get_paired_device=yes]],
+  [AC_MSG_RESULT([no])
+   [libwacom_have_get_paired_device=no]])
+   LIBS=$OLD_LIBS
+   CFLAGS=$OLD_CFLAGS
 fi
+AM_CONDITIONAL(HAVE_LIBWACOM_GET_PAIRED_DEVICE,
+  [test "x$libwacom_have_get_paired_device" == "xyes"])
 
 AM_CONDITIONAL(HAVE_VALGRIND, [test "x$VALGRIND" != "x"])
 AM_CONDITIONAL(BUILD_TESTS, [test "x$build_tests" = "xyes"])
diff --git a/udev/Makefile.am b/udev/Makefile.am
index cfb854e..f06dc56 100644
--- a/udev/Makefile.am
+++ b/udev/Makefile.am
@@ -7,9 +7,16 @@ litest_rules = 80-libinput-device-groups-litest.rules \
 noinst_SCRIPTS = $(litest_rules)
 
 libinput_device_group_SOURCES = libinput-device-group.c
-libinput_device_group_CFLAGS = $(LIBUDEV_CFLAGS) $(GCC_CFLAGS)
+libinput_device_group_CFLAGS = -I$(top_srcdir)/src \
+  $(LIBUDEV_CFLAGS) \
+  $(GCC_CFLAGS)
 libinput_device_group_LDADD = $(LIBUDEV_LIBS)
 
+if HAVE_LIBWACOM_GET_PAIRED_DEVICE
+libinput_device_group_CFLAGS += $(LIBWACOM_CFLAGS)
+libinput_device_group_LDADD += $(LIBWACOM_LIBS)
+endif
+
 libinput_model_quirks_SOURCES = libinput-model-quirks.c
 libinput_model_quirks_CFLAGS = \
   -I$(top_srcdir)/src \
diff --git a/udev/libinput-device-group.c b/udev/libinput-device-group.c
index ab9409b..fa70e11 100644
--- a/udev/libinput-device-group.c
+++ b/udev/libinput-device-group.c
@@ -21,11 +21,49 @@
  * DEALINGS IN THE SOFTWARE.
  */
 
+#include "config.h"
+
 #include 
 #include 
 #include 
 #include 
 
+#include "libinput-util.h"
+
+#if HAVE_LIBWACOM_GET_PAIRED_DEVICE
+#include 
+
+static void
+wacom_handle_paired(struct udev_device *device,
+   int *vendor_id,
+   int *product_id)
+{
+   WacomDeviceDatabase *db = NULL;
+   WacomDevice *tablet = NULL;
+   const WacomMatch *paired;
+
+   db = libwacom_database_new();
+   if (!db)
+   goto out;
+
+   tablet = libwacom_new_from_usbid(db, *vendor_id, *product_id, NULL);
+   if (!tablet)
+   goto out;
+   paired = libwacom_get_paired_device(tablet);
+   if (!paired)
+   goto out;
+
+   *vendor_id = libwacom_match_get_vendor_id(paired);
+   *product_id = libwacom_match_get_product_id(paired);
+
+out:
+   if (tablet)
+   libwacom_destroy(tablet);
+   if (db)
+   libwacom_database_destroy(db);
+}
+#endif
+
 int main(int argc, char **argv)
 {
int rc = 1;
@@ -34,6 +72,7 @@ int main(int argc, char **argv)
const char *syspath,
   *phys = NULL;
const char *product;
+   int bustype, vendor_id, product_id, version;
char group[1024];
char *str;
 
@@ -73,8 +112,29 @@ int main(int argc, char **argv)
   on that*/
product = udev_device_get_property_value(device, "PRODUCT");
if (!product)
-   product = "";
-   snprintf(group, sizeof(group), "%s:%s", product, phys);
+   product = "00/00/00/00";
+
+   if (sscanf(product,
+  "%x/%x/%x/%x",
+  ,
+  _id,
+  _id,
+  ) != 4) {
+ 

Re: Weston on framebuffer?

[The Rasterman]

On Wed, 20 Jul 2016 21:49:57 +0200 Christer Weinigel 
said:

> Hi,
> 
> On 07/20/2016 01:04 AM, Carsten Haitzler (The Rasterman) wrote:
> >> With this I managed to get a desktop and was unable to start
> >> wayland-terminal.  Redrawing of the graphics felt fairly snappy, but the
> >> lag from pressing a key on the keyboard until a character showed up in
> >> the terminal was slow, probably between a quarter to half a second.
> >>
> >> So my question is if this is the performance I should expect with weston
> >> on a 400MHz ARM9 and a dumb framebuffer?  Have I done something stupid
> >> and there are easy ways to speed it up?
> 
> > when you say redraw is snappy... that implies that output is fast. so time
> > from deciding to render and update and it appearing is very short. but you
> > seem to have serious input lag which implies to me that it has nothing to
> > do with your cpu speed and is something else deeper and more involved. time
> > to trace things and see how they go.
> 
> I put up a short video here:
> 
> http://zoo.weinigel.se/misc/2016-07-20-213549.webm

that's not snappy. :) startup takes quite a while. but after that moving the
terminal window around is maybe getting you 6-7fps or so.

> On the framebuffer I don't perceive any lag at all between a keypress 
> and the character appearing on the screen.
> 
> With weston-terminal running I can drag the window around and even 
> though it's not very fast and there's a bit of tearing it isn't too bad. 
> The response when dragging feels ok.  Keypresses feel laggy even though 
> mouse motion doesn't, but I'm not sure if that's because I don't notice 
> the lag when moving the mouse or if it is a real difference.

well they are done by different things. the move will be done directly by
weston itself. it will be asked to begin a window move by the client and then
just do it itself. render the changes. key events have a different path. they
go to client, client handles it, draws new frame, then weston has to update
screen with that new frame.

it seems to be either weston-terminal is just slow at drawing there and thus is
ending up taking a while to draw, add another 200ms or so for weston itself and
thats probably what's going on.

weston reads input, sends 1 or more key events to client.
client gets input now does some updates/rendering (let's say takes 200ms
assuming weston terminal is slow-ish at rendering). let's now say client sends
update buffer to weston. weston now gets it, spends 200ms rendering, then reads
buffered input, sends backto client (it may have sent it before), but weston
will be either rendering a frame (takes 200ms or a bit less) or sending events.
not both. that means at least some events could take 600ms to come back to the
screen (almost half a second) because weston got blocks then client renders,
then come back to screen. so maybe 500ms on average. half a second.

i think rendering is slow and due to the above it just adds latency to the
point where you see it easily. you only have a single cpu. any cpu time used up
one place cannot be used elsewhere. no multilpe cores. :)

that's my guess. weston is either reading input + sending, or drawing, and the
big blobs of time spent drawing mean it's not reading and sending. so that adds
UP to ~200ms THEN client gets these. client may be still drawing a previous
frame, so doesn't respond for a little bit. let's say 100ms. then client draws.
let's say 100ms, then client sends new frame over to compositor. compositor
gets frame, begins draw. now 200ms more. NOW you see what you just typed. 600ms
later. more or less. which is about what it looks like. when moving a window,
weston gets mouse events, weston redraws, repeat. so 200ms lag. speed up the
drawing or allow drawing to happen in parallel and you're good.

remember weston is the SAMPLE compositor. it will not have been tuned to run
ultra-fast on your setup. you likely have a 16bpp display but what's actually
going on is clients are rendering in 32bpp so taking longer to render that they
would natively (like the text console), and then weston is likely rendering in
32bpp too... THEN it's down-converting to 16bpp for display. none of that is
free. :) you will likely not find much support these days that doesn't involve
down-conversion as everyone is handling alpha and thus 32bpp (yes you can do
16bpp+alpha mask for example, or pack argb  into 16bpp and other
imaginative ways of getting it). dropping the whole pipeline down to something
like 16bpp+masks and a very carefully tuned pipeline would help.

(the reason i say 16bpp + masks is you can do a memcpy for the 16bpp data
direct to memory and since this doesn't convert it likely will be 2-3 times
faster - on the compositor fb side. on the client side the mask can be
pre-computed once for the window then just render 16bpp content, and with
opaque regions - since all the drawing happens inside those, the compositor can
skip blending entirely for regions 

Re: Weston on framebuffer?

[Christer Weinigel]

Hi,

On 07/20/2016 01:04 AM, Carsten Haitzler (The Rasterman) wrote:

With this I managed to get a desktop and was unable to start
wayland-terminal.  Redrawing of the graphics felt fairly snappy, but the
lag from pressing a key on the keyboard until a character showed up in
the terminal was slow, probably between a quarter to half a second.

So my question is if this is the performance I should expect with weston
on a 400MHz ARM9 and a dumb framebuffer?  Have I done something stupid
and there are easy ways to speed it up?



when you say redraw is snappy... that implies that output is fast. so time from
deciding to render and update and it appearing is very short. but you seem to
have serious input lag which implies to me that it has nothing to do with your
cpu speed and is something else deeper and more involved. time to trace things
and see how they go.


I put up a short video here:

http://zoo.weinigel.se/misc/2016-07-20-213549.webm

On the framebuffer I don't perceive any lag at all between a keypress 
and the character appearing on the screen.


With weston-terminal running I can drag the window around and even 
though it's not very fast and there's a bit of tearing it isn't too bad. 
The response when dragging feels ok.  Keypresses feel laggy even though 
mouse motion doesn't, but I'm not sure if that's because I don't notice 
the lag when moving the mouse or if it is a real difference.


I tried to do a strace of weston-terminal, but it was a bit painful, it 
reads every file it can find in /usr/share/icons/default/cursors/ when 
it starts so strace took forever before the terminal would even show up.


And for trying to do more advanced tracing, I don't quite know where to 
start.  Are there any knobs in the source to do things such as dump 
timestamps for messages between the server and client?


 /Christer
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols] Introduce xdg-foreign protocol

[Yong Bakos]

Hi Jonas,

> On Jul 13, 2016, at 12:58 AM, Jonas Ådahl  wrote:
> 
> xdg-foreign is a protocol meant to enable setting up inter surface
> relationships across clients. Potential use cases are out-of-process
> dialogs, such as file dialogs, meant to be used by sandboxed processes
> that may not have the access it needs to implement such dialogs.
> 
> It works by enabling a client to export a surface, creating a handle
> for the exported surface. The handle, in form of a unique string, may
> be shared in some way with other clients (for example the provider of
> the file dialog) which can then import the exported surface.
> 
> Signed-off-by: Jonas Ådahl 

Interesting protocol. Just a wild thought: would surface-exporting be
something useful in the core Wayland protocol? (Not now, but...)

I'll need to re-read and imagine the scenarios, but I feel like there
is some inconsistency in either the descriptions or the protocol itself.
Specifically, I thought that the exported surface from client A would
be displayed by client B as an xdg_toplevel, but then I also see
set_parent_of, meaning that client B can add subsurfaces to the
imported surface?

No need to explain that in length, I think I just need to re-read.

Some notes inline below.


> ---
> 
> Hi,
> 
> This protocol is intended to be used by flatpak's xdg desktop portals, in 
> order
> to have a portal dialog (such as a file chooser) to be stacked above (and 
> maybe
> as a modal) a parent surface.
> 
> A compositor that want to be able to run sandboxed Wayland clients that need 
> to
> use portals would need to implement this protocol.
> 
> In short, a sandboxed client would "export" its surface and in the process
> retrieve a server generated handle string, acting as a unique identifier for
> the exported window. In the flatpak case the client will pass the identifier
> string via D-Bus to a xdg desktop portal service provider, which will then
> import it using xdg_importer and create a xdg_imported object that it can be
> used to modify the stacking relationship.
> 
> So far the only supported operation is setting an imported window to be the
> parent of some surface.
> 
> Note that the protocol documentation says "xdg_surface". In the future this
> would be "xdg_toplevel".
> 
> 
> Jonas
> 
> Makefile.am  |   1 +
> unstable/xdg-foreign/README  |   4 +
> unstable/xdg-foreign/xdg-foreign-unstable-v1.xml | 177 +++
> 3 files changed, 182 insertions(+)
> create mode 100644 unstable/xdg-foreign/README
> create mode 100644 unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> 
> diff --git a/Makefile.am b/Makefile.am
> index 71d2632..06a1bb2 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -8,6 +8,7 @@ unstable_protocols =  
> \
>   unstable/relative-pointer/relative-pointer-unstable-v1.xml  
> \
>   unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
> \
>   unstable/tablet/tablet-unstable-v1.xml  
> \
> + unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> \
>   $(NULL)
> 
> stable_protocols =
> \
> diff --git a/unstable/xdg-foreign/README b/unstable/xdg-foreign/README
> new file mode 100644
> index 000..f5bcb83
> --- /dev/null
> +++ b/unstable/xdg-foreign/README
> @@ -0,0 +1,4 @@
> +xdg foreign protocol
> +
> +Maintainers:
> +Jonas Ådahl 
> diff --git a/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml 
> b/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> new file mode 100644
> index 000..d8a90c3
> --- /dev/null
> +++ b/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> @@ -0,0 +1,177 @@
> +
> +
> +
> +  
> +Copyright © 2015-2016 Red Hat Inc.
> +
> +Permission is hereby granted, free of charge, to any person obtaining a
> +copy of this software and associated documentation files (the 
> "Software"),
> +to deal in the Software without restriction, including without limitation
> +the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +and/or sell copies of the Software, and to permit persons to whom the
> +Software is furnished to do so, subject to the following conditions:
> +
> +The above copyright notice and this permission notice (including the next
> +paragraph) shall be included in all copies or substantial portions of the
> +Software.
> +
> +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
> OR
> +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> OTHER
> +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, 

Re: [PATCH wayland-protocols 2/3] xdg-shell: Clarify focus semantics for popup grabs

[Yong Bakos]

Hi Jonas,

> On Jul 15, 2016, at 2:37 AM, Jonas Ådahl  wrote:
> 
> Make it clearer what the focus semantics are during a popup grab. In
> short, when a grabbing popup is mapped, the top most popup will always
> have keyboard focus, while pointer and touch focus works just as normal
> except that only surfaces from the grabbing client will receive pointer
> and touch focus.
> 
> This patch doesn't really change any semantics but rather clarifies
> what was ambiguous before.
> 
> Signed-off-by: Jonas Ådahl 
> ---
> unstable/xdg-shell/xdg-shell-unstable-v6.xml | 8 
> 1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> index 862e664..644dbc2 100644
> --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> @@ -1002,10 +1002,10 @@
>   popup will be immediately dismissed. If the parent is a popup that did
>   not take an explicit grab, an error will be raised.
> 
> - Clients will receive events for all their surfaces during this grab
> - (which is an "owner-events" grab in X11 parlance). This is done so that
> - users can navigate through submenus and other "nested" popup windows
> - without having to dismiss the topmost popup.
> + During an popup grab, the client owning the grab will receive pointer
> + and touch events for all their surfaces as normal (similar to an
> + "owner-events" grab in X11 parlance), while the top most grabbing popup
> + will always have keyboard focus.

The sentence is definitely more succinct and clear, but I also feel that the
example (navigating through submenus) helps illustrate the purpose and usage.

yong


>   
> 
>-- 
> 2.7.4
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols v4 7/7] xdg-shell: Introduce xdg_positioner

[Yong Bakos]

Jonas,
My R'b for 1-6 of v4 stand.

I think I finally grok xdg_positioner, and this seems straightforward.
I would like to understand Bill's 'list of rectangles' approach,
mentioned off-list, but from what I can tell it doesn't jive with
current best practices. I mention this because I'm always open to
'better' ways of handling positioning, if there's an opportunity to do
something better.

I /think/ this can be landed as-is, especially since we've got a branch
for this, but I have some comments inline below before I R'b.


> On Jun 23, 2016, at 11:47 PM, Jonas Ådahl  wrote:
> 
> xdg_positioner is a method for declarative positioning of child surfaces
> (currently only xdg_popup surfaces). A client creates a description of a
> positioning logic using the xdg_positioner interface. The xdg_positioner
> object is then used when creating a xdg_popup for describing how the
> child surface should be positioned in relation to the parent surface.
> 
> Signed-off-by: Jonas Ådahl 
> Signed-off-by: Mike Blumenkrantz 
> Acked-by: Yong Bakos 
> ---
> 
> Changes since v3:
> 
> - Allow combining slide_x/y and flip_x/y enums, while explaining the order of
>   adjustments.
> - Reworded the non-immediate effect of the configure event (the same as
>   xdg-surface generic split update)
> 
> 
> unstable/xdg-shell/xdg-shell-unstable-v6.xml | 266 ++-
> 1 file changed, 263 insertions(+), 3 deletions(-)
> 
> diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> index 4c5dab4..7fab656 100644
> --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> @@ -45,6 +45,8 @@
>summary="the client specified an invalid popup parent surface"/>
>   summary="the client provided an invalid surface state"/>
> +   +  summary="the client provided an invalid positioner"/>
> 
> 
> 
> @@ -57,6 +59,15 @@
>   
> 
> 
> +
> +  
> + Create a positioner object. A positioner object is used to position
> + surfaces relative to some parent surface. See the interface description
> + and xdg_surface.get_popup for details.
> +  
> +  
> +
> +
> 
>   
>   This creates an xdg_surface for the given surface. While xdg_surface
> @@ -101,6 +112,240 @@
> 
>   
> 
> +  
> +
> +  The xdg_positioner provides an interface for constructing positioning
> +  rules used for positioning a child surface relative to a parent surface
> +  in a certain way. It allows methods for defining a rule that will make
> +  the child surface stay within the border of the visible area of the
> +  screen, with different ways in which the child surface should change
> +  its position, including sliding along an axis, or flipping around a
> +  rectangle.
> +
> +  See the various requests for details about possible rules.
> +
> +  Semantically, an xdg_positioner is a collection of positioning rules. 
> When
> +  used for positioning a surface, for example when passed as an argument 
> to
> +  xdg_surface.get_popup, the compositor copies the rules that were set 
> up at
> +  the time of the request. Making any changes or destroying the object 
> after
> +  it was used has no effect on previous usages.
> +
> +  For an xdg_positioner object to be considered complete, it must have a
> +  non-zero size set by set_size, and a non-zero anchor rectangle set by
> +  set_anchor_rect. Passing an incomplete xdg_positioner object when
> +  positioning a surface raises an error.
> +
> +
> +
> +  
> +
> +
> +
> +  
> + Notify the compositor that the xdg_positioner will no longer be used.
> +  
> +
> +
> +
> +  
> + Set the size of the surface that is to be positioned with the positioner
> + object. The size is in surface-local coordinates and corresponds to the
> + window geometry. See xdg_surface.set_window_geometry.
> +
> + If a zero or negative size is set the invalid_input error is raised.
> +  
> +  
> +  
> +
> +
> +
> +  
> + Specify the anchor rectangle within the parent surface that the child
> + surface will be placed relative to. The rectangle is relative to the
> + window geometry as defined by xdg_surface.set_window_geometry of the
> + parent surface. The rectangle must be at least 1x1 large.
> +
> + When the xdg_positioner object is used to position a child surface, the
> + anchor rectangle may not extend outside the window geometry of the
> + positioned child's parent surface.
> +
> + If a zero or negative size is set the invalid_input error is raised.
> +  
> +  
> +  
> +  
> +  
> +
> +
> +
> +   +  summary="the center of the anchor rectangle"/>
> +   +   

Re: [Question] About muti-thread with wayland/weston

[Daniel Stone]

Hi Lingyun,

On 8 July 2016 at 06:52, Zhu, Lingyun  wrote:
> I’m trying to develop an application under Yocto, which may have multiple
> (maybe 16) threads contained in one process.
>
> Each thread wants to have an individual connection with Weston and render
> its own picture independently at the same time.
>
> But I’m not sure whether it’s feasible with Weston.
>
> So, my question is whether Weston support thread-level connection? Or in
> another word, does Weston treat thread the same way as process?

Weston supports any kind of connection from clients.

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[Question] About muti-thread with wayland/weston

[Zhu, Lingyun]

Hi, guys

I'm trying to develop an application under Yocto, which may have multiple 
(maybe 16) threads contained in one process.
Each thread wants to have an individual connection with Weston and render its 
own picture independently at the same time.
But I'm not sure whether it's feasible with Weston.

So, my question is whether Weston support thread-level connection? Or in 
another word, does Weston treat thread the same way as process?


Thanks,
Lingyun
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Create cross wayland-scanner for toolchain or cross-development environment

[Andrew Kosteltsev]

Hi Quentin.

I see. My suggestion related to simplify the build process on developer
machines which doesn't have pre-installed native Wayland package. And also
I think it would be good if wailand-scanner output will be generated by
scanner which has the same version as target machine scanner.

Currently developers must have installed wayland package and it is not
convenient if developer builds several targets for different CPU (and may
be different versions of some SW packages) at the same time using cross
environment.

(for example, GNU file also requires native file utility on developer
machine, moreover it must have same version). I think not all needed tools
can be implemented into toolchain like cross-compiler. Some of them can be
built and added into DevEnv later on build time.

Any way It is up to you. I just suggest.

Best Regards,
Andrey K.


On Fri, Jul 8, 2016 at 11:17 AM, Quentin Glidic <
sardemff7+wayl...@sardemff7.net> wrote:

> On 18/05/2016 14:55, Andrew Kosteltsev wrote:
>
>> Hi guys,
>>
>> Currently during cross compilation of the wayland library the
>> wayland-scanner utility is built by cross-gcc and then used on the
>> developer machine which lead build error.
>>
>> I suggest to build development version, for example,
>> $(top_builddir)/build-wayland-scanner and to use this utility during
>> cross-buildin the wayland package.
>>
>> When build is done the user can copy this release of scanner utility
>> into his toolchain or into his SDK for example wit $(host-triplet) preffix
>>
>> cp $(top_builddir)/build-wayland-scanner
>> SDK/bin/$(host_triplet)-wayland-scanner
>>
>> Then the user can make use this cross-wayland-scanner in his SDK, for
>> example, like follow:
>>
>> $ ../MesaLib-10.3.4/configure
>> WAILAND_SCANNER=$(SDK_DIR)/bin/$(target)-wayland-scanner
>>
>> I have attached the patch for you. Please look at this patch and please
>> make decision related to cross building the wayland.
>>
>> Of course after applying attached patch we have to reconfigure src
>> package;
>>
>> $ autoreconf -i
>>
>
> NAK from me on this patch.
>
> wayland-scanner does not output host-specific code, so you should simply
> use the one in the PATH of your build machine, via --with-host-scanner.
>
> Cheers,
>
> --
>
> Quentin “Sardem FF7” Glidic
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Create cross wayland-scanner for toolchain or cross-development environment

[Andrew Kosteltsev]

Of course, not an old lib with a never scanner! only the same.

On Fri, Jul 8, 2016 at 12:24 PM, Quentin Glidic <
sardemff7+wayl...@sardemff7.net> wrote:

> On 08/07/2016 10:46, Andrew Kosteltsev wrote:
>
>> Hi Quentin.
>>
>> I see. My suggestion related to simplify the build process on developer
>> machines which doesn't have pre-installed native Wayland package. And
>> also I think it would be good if wailand-scanner output will be
>> generated by scanner which has the same version as target machine scanner.
>>
> >
>
>> Currently developers must have installed wayland package and it is not
>> convenient if developer builds several targets for different CPU (and
>> may be different versions of some SW packages) at the same time using
>> cross environment.
>>
>> (for example, GNU file also requires native file utility on developer
>> machine, moreover it must have same version). I think not all needed
>> tools can be implemented into toolchain like cross-compiler. Some of
>> them can be built and added into DevEnv later on build time.
>>
>> Any way It is up to you. I just suggest.
>>
>
>
> I see your concern, and you should worry about only one thing: that your
> native libwayland package (so your wayland-scanner) is newer than the one
> you build.
> libwayland, and thus the scanner, will remain backward-compatible, so
> there is no harm in generating an old libwayland with a newer scanner.
> At least until wayland 2.0. :-)
>
>
> Cheers,
>
> --
>
> Quentin “Sardem FF7” Glidic
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Create cross wayland-scanner for toolchain or cross-development environment

[Andrew Kosteltsev]

Hi Emil,

Unfortunattely Mesa-11.2.2 still requires wayland-scanner. But I will check
it again.

Best Regards,
Andrey K.
8 июля 2016 г. 13:29 пользователь "Emil Velikov" 
написал:

Hi all,

Jumping the gun a bit, hope you'll forgive me :-)

On 8 July 2016 at 09:17, Quentin Glidic 
wrote:
> On 18/05/2016 14:55, Andrew Kosteltsev wrote:

>> Then the user can make use this cross-wayland-scanner in his SDK, for
>> example, like follow:
>>
>> $ ../MesaLib-10.3.4/configure
>> WAILAND_SCANNER=$(SDK_DIR)/bin/$(target)-wayland-scanner
>>
Afaict newer mesa releases should include the generated files. Thus
one shouldn't need to use the tool, let alone have it.

If anything I'd suggest pinging the respective projects to provide
complete/comprehensive release tarballs.

-Emil
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: When to use libweston plugin registry

[Armin Krezović]

On 20.07.2016 09:45, Pekka Paalanen wrote:
> Hi Armin,
> 
> I didn't manage to catch you online, so here is re:
> https://paste.debian.net/hidden/ac601ed5/
> 

Hi Pekka,

Sorry for not being available in the past few days. I will be
once again available full time starting tomorrow afternoon.

> Yes, that's the mechanics of using the plugin registry, but I
> didn't think of using it for those particular entries.
> 
> For libweston-core <-> backend APIs using the plugin registry seems
> like an unnecessary detour. I don't see it benefiting anything.
> Libweston-core loads the backend directly and communicates with it
> directly. We also wouldn't want to expose interfaces meant only for
> the use of libweston-core. libweston-core is non-optional, so the
> flexibility is not useful.
> 
> Originally plugin registry was written for plugins to interface
> with other plugins, so that we don't need to keep adding new
> plugin-specific APIs or relays to (lib)weston-core or the
> compositor.
> 
> Another use case in my mind is offering optional interfaces from
> libweston and anything below it to the compositor. It might be seen
> as a layering violation since we skip over libweston-core rather
> than plumbing things through it, but in this case I think it's for
> the better.
> 
> E.g. DRM-backend specific APIs might want to use libdrm, libudev or
> libinput types. If these were exposed from libweston proper, we
> would have libweston depend on all of them, regardless whether the
> compositor actually wanted the DRM-backend. It would be even more
> glaring if x11-backend had some API using XCB or X11 types,
> causing libweston to depend on libxcb. When we use the plugin
> registry for these, we don't need the extra dependencies on the
> libweston-core. The extra dependencies can be pulled in by the
> backends and the interface headers used with the plugin registry as
> needed instead of always.
> 
> In summary, I'd like to see the plugin registry used for optional
> interfaces that might also come with a cost (e.g. extra
> dependencies) if offered straight from libweston proper.
> 
> I still consider it optional even if it is mandatory for using a
> specific backend or feature, because compositors are free to choose
> the backend(s) and features they use.
> 

When we discussed API for configuring outputs, you mentioned that
I should consider using plugin-registry to call backend specific
functions to configure an output.

We already have API's calling into backend specific code via
function pointers (mode switching comes to mind), so I think
it's safe to use same approach for output configuration (backend
specific parts only).

So, to be sure, I don't need plugin-registry for such features?

> 
> Thanks,
> pq
> 

Cheers.



signature.asc
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput] udev: check wacom devices for a paired product id

[Quentin Glidic]

On 20/07/2016 12:02, Peter Hutterer wrote:

The newer Wacom Cintiqs have touch devices with a different PID than the pen
device. Use the new libwacom_get_paired_device call where available to pair
the two devices and give them the same device group.

This isn't that important just yet, so no need to force users to update to a
new libwacom version.

Signed-off-by: Peter Hutterer 
Tested-by: Benjamin Tissoires 
---
 configure.ac |  9 +++
 udev/Makefile.am |  5 
 udev/libinput-device-group.c | 62 ++--
 3 files changed, 74 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 9e238b4..1bf912e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -208,7 +208,16 @@ AC_ARG_ENABLE(libwacom,
 if test "x$use_libwacom" = "xyes"; then
PKG_CHECK_MODULES(LIBWACOM, [libwacom >= 0.12], [HAVE_LIBWACOM="yes"])
AC_DEFINE(HAVE_LIBWACOM, 1, [Build with libwacom])
+   AC_CHECK_LIB([wacom],
+[libwacom_get_paired_device],
+[libwacom_have_get_paired_device=yes,
+ AC_DEFINE(HAVE_LIBWACOM_GET_PAIRED_DEVICE, [1],
+   [libwacom_get_paired_device() is available])],
+[libwacom_have_get_paired_device=no],
+[$LIBWACOM_LIBS])


I may be nitpicking here, but this check sounds wrong. Say you are 
cross-compiling, will AC_CHECK_LIB find the right one? Making it search 
for -lwacom *and* passing $LIBWACOM_LIBS sounds wrong too.

I would use AC_LINK_IFELSE[1] directly.

Cheers,


[1] 




 fi
+AM_CONDITIONAL(HAVE_LIBWACOM_GET_PAIRED_DEVICE,
+  [test "x$libwacom_get_paired_device" == "xyes"])

>

 AM_CONDITIONAL(HAVE_VALGRIND, [test "x$VALGRIND" != "x"])
 AM_CONDITIONAL(BUILD_TESTS, [test "x$build_tests" = "xyes"])
diff --git a/udev/Makefile.am b/udev/Makefile.am
index cfb854e..78e3791 100644
--- a/udev/Makefile.am
+++ b/udev/Makefile.am
@@ -10,6 +10,11 @@ libinput_device_group_SOURCES = libinput-device-group.c
 libinput_device_group_CFLAGS = $(LIBUDEV_CFLAGS) $(GCC_CFLAGS)
 libinput_device_group_LDADD = $(LIBUDEV_LIBS)

+if HAVE_LIBWACOM_GET_PAIRED_DEVICE
+libinput_device_group_CFLAGS += $(LIBWACOM_CFLAGS)
+libinput_device_group_LDADD += $(LIBWACOM_LIBS)
+endif
+
 libinput_model_quirks_SOURCES = libinput-model-quirks.c
 libinput_model_quirks_CFLAGS = \
   -I$(top_srcdir)/src \
diff --git a/udev/libinput-device-group.c b/udev/libinput-device-group.c
index ab9409b..217ed44 100644
--- a/udev/libinput-device-group.c
+++ b/udev/libinput-device-group.c
@@ -21,11 +21,47 @@
  * DEALINGS IN THE SOFTWARE.
  */

+#include "config.h"
+
 #include 
 #include 
 #include 
 #include 

+#if HAVE_LIBWACOM_GET_PAIRED_DEVICE
+#include 
+
+static void
+wacom_handle_paired(struct udev_device *device,
+   int *vendor_id,
+   int *product_id)
+{
+   WacomDeviceDatabase *db = NULL;
+   WacomDevice *tablet = NULL;
+   const WacomMatch *paired;
+
+   db = libwacom_database_new();
+   if (!db)
+   goto out;
+
+   tablet = libwacom_new_from_usbid(db, *vendor_id, *product_id, NULL);
+   if (!tablet)
+   goto out;
+   paired = libwacom_get_paired_device(tablet);
+   if (!paired)
+   goto out;
+
+   *vendor_id = libwacom_match_get_vendor_id(paired);
+   *product_id = libwacom_match_get_product_id(paired);
+
+out:
+   if (tablet)
+   libwacom_destroy(tablet);
+   if (db)
+   libwacom_database_destroy(db);
+}
+#endif
+
 int main(int argc, char **argv)
 {
int rc = 1;
@@ -34,6 +70,7 @@ int main(int argc, char **argv)
const char *syspath,
   *phys = NULL;
const char *product;
+   int bustype, vendor_id, product_id, version;
char group[1024];
char *str;

@@ -73,8 +110,29 @@ int main(int argc, char **argv)
   on that*/
product = udev_device_get_property_value(device, "PRODUCT");
if (!product)
-   product = "";
-   snprintf(group, sizeof(group), "%s:%s", product, phys);
+   product = "00/00/00/00";
+
+   if (sscanf(product,
+  "%x/%x/%x/%x",
+  ,
+  _id,
+  _id,
+  ) != 4) {
+   snprintf(group, sizeof(group), "%s:%s", product, phys);
+   } else {
+#if HAVE_LIBWACOM_GET_PAIRED_DEVICE
+   if (vendor_id == VENDOR_ID_WACOM)
+   wacom_handle_paired(device, _id, _id);
+#endif
+   snprintf(group,
+sizeof(group),
+"%x/%x/%x/%x:%s",
+bustype,
+vendor_id,
+product_id,
+

[PATCH libinput] udev: check wacom devices for a paired product id

[Peter Hutterer]

The newer Wacom Cintiqs have touch devices with a different PID than the pen
device. Use the new libwacom_get_paired_device call where available to pair
the two devices and give them the same device group.

This isn't that important just yet, so no need to force users to update to a
new libwacom version.

Signed-off-by: Peter Hutterer 
Tested-by: Benjamin Tissoires 
---
 configure.ac |  9 +++
 udev/Makefile.am |  5 
 udev/libinput-device-group.c | 62 ++--
 3 files changed, 74 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 9e238b4..1bf912e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -208,7 +208,16 @@ AC_ARG_ENABLE(libwacom,
 if test "x$use_libwacom" = "xyes"; then
PKG_CHECK_MODULES(LIBWACOM, [libwacom >= 0.12], [HAVE_LIBWACOM="yes"])
AC_DEFINE(HAVE_LIBWACOM, 1, [Build with libwacom])
+   AC_CHECK_LIB([wacom],
+[libwacom_get_paired_device],
+[libwacom_have_get_paired_device=yes,
+ AC_DEFINE(HAVE_LIBWACOM_GET_PAIRED_DEVICE, [1],
+   [libwacom_get_paired_device() is available])],
+[libwacom_have_get_paired_device=no],
+[$LIBWACOM_LIBS])
 fi
+AM_CONDITIONAL(HAVE_LIBWACOM_GET_PAIRED_DEVICE,
+  [test "x$libwacom_get_paired_device" == "xyes"])
 
 AM_CONDITIONAL(HAVE_VALGRIND, [test "x$VALGRIND" != "x"])
 AM_CONDITIONAL(BUILD_TESTS, [test "x$build_tests" = "xyes"])
diff --git a/udev/Makefile.am b/udev/Makefile.am
index cfb854e..78e3791 100644
--- a/udev/Makefile.am
+++ b/udev/Makefile.am
@@ -10,6 +10,11 @@ libinput_device_group_SOURCES = libinput-device-group.c
 libinput_device_group_CFLAGS = $(LIBUDEV_CFLAGS) $(GCC_CFLAGS)
 libinput_device_group_LDADD = $(LIBUDEV_LIBS)
 
+if HAVE_LIBWACOM_GET_PAIRED_DEVICE
+libinput_device_group_CFLAGS += $(LIBWACOM_CFLAGS)
+libinput_device_group_LDADD += $(LIBWACOM_LIBS)
+endif
+
 libinput_model_quirks_SOURCES = libinput-model-quirks.c
 libinput_model_quirks_CFLAGS = \
   -I$(top_srcdir)/src \
diff --git a/udev/libinput-device-group.c b/udev/libinput-device-group.c
index ab9409b..217ed44 100644
--- a/udev/libinput-device-group.c
+++ b/udev/libinput-device-group.c
@@ -21,11 +21,47 @@
  * DEALINGS IN THE SOFTWARE.
  */
 
+#include "config.h"
+
 #include 
 #include 
 #include 
 #include 
 
+#if HAVE_LIBWACOM_GET_PAIRED_DEVICE
+#include 
+
+static void
+wacom_handle_paired(struct udev_device *device,
+   int *vendor_id,
+   int *product_id)
+{
+   WacomDeviceDatabase *db = NULL;
+   WacomDevice *tablet = NULL;
+   const WacomMatch *paired;
+
+   db = libwacom_database_new();
+   if (!db)
+   goto out;
+
+   tablet = libwacom_new_from_usbid(db, *vendor_id, *product_id, NULL);
+   if (!tablet)
+   goto out;
+   paired = libwacom_get_paired_device(tablet);
+   if (!paired)
+   goto out;
+
+   *vendor_id = libwacom_match_get_vendor_id(paired);
+   *product_id = libwacom_match_get_product_id(paired);
+
+out:
+   if (tablet)
+   libwacom_destroy(tablet);
+   if (db)
+   libwacom_database_destroy(db);
+}
+#endif
+
 int main(int argc, char **argv)
 {
int rc = 1;
@@ -34,6 +70,7 @@ int main(int argc, char **argv)
const char *syspath,
   *phys = NULL;
const char *product;
+   int bustype, vendor_id, product_id, version;
char group[1024];
char *str;
 
@@ -73,8 +110,29 @@ int main(int argc, char **argv)
   on that*/
product = udev_device_get_property_value(device, "PRODUCT");
if (!product)
-   product = "";
-   snprintf(group, sizeof(group), "%s:%s", product, phys);
+   product = "00/00/00/00";
+
+   if (sscanf(product,
+  "%x/%x/%x/%x",
+  ,
+  _id,
+  _id,
+  ) != 4) {
+   snprintf(group, sizeof(group), "%s:%s", product, phys);
+   } else {
+#if HAVE_LIBWACOM_GET_PAIRED_DEVICE
+   if (vendor_id == VENDOR_ID_WACOM)
+   wacom_handle_paired(device, _id, _id);
+#endif
+   snprintf(group,
+sizeof(group),
+"%x/%x/%x/%x:%s",
+bustype,
+vendor_id,
+product_id,
+version,
+phys);
+   }
 
str = strstr(group, "/input");
if (str)
-- 
2.7.4

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH libinput] udev: don't overwrite a previously set device group

[Peter Hutterer]

In some cases a device may need a device group assigned by a custom udev rule
or hwdb entry. Don't overwrite that with our generated one.

Signed-off-by: Peter Hutterer 
---
 udev/80-libinput-device-groups.rules.in | 1 +
 1 file changed, 1 insertion(+)

diff --git a/udev/80-libinput-device-groups.rules.in 
b/udev/80-libinput-device-groups.rules.in
index c2af0ce..1a26f78 100644
--- a/udev/80-libinput-device-groups.rules.in
+++ b/udev/80-libinput-device-groups.rules.in
@@ -2,6 +2,7 @@ ACTION!="add|change", GOTO="libinput_device_group_end"
 KERNEL!="event[0-9]*", GOTO="libinput_device_group_end"
 
 ATTRS{phys}=="?*", \
+   ENV{LIBINPUT_DEVICE_GROUP}=="", \
PROGRAM="@UDEV_TEST_PATH@libinput-device-group %S%p", \
ENV{LIBINPUT_DEVICE_GROUP}="%c"
 
-- 
2.7.4

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols] xdg-shell: Introduce xdg_toplevel capabilities

[Quentin Glidic]

On 15/07/2016 13:00, Jonas Ådahl wrote:

The xdg_toplevel capabilities are meant to let the compositor know what
configurations a client can be configured to. This is meant to make it
possible to disallow a compositor to maximize, fullscreen etc a
surface, which would otherwise mandate the client to configure the
surface according to dimension in the xdg_toplevel.configure event.

This makes it possible to create non-resizable surfaces as well as
surfaces with only a certain aspect ratio allowed, by making them
un-fullscreen:able and un-maximize:able.

Signed-off-by: Jonas Ådahl 
---

This is an alternative solution to the s/must/should/ patch.

I made a separate enum, because certain state enum entries make no sense to
support or not, since they don't mandate anything (resize, activated so far).



I like this idea better than the s/must/should/ patch.

Since we do not reuse the existing enum, does that make sense to group 
similar features?
The fullscreen/maximized/tiled states are about obeying an arbitrary 
size, you can still support even if you do nothing more. Sure, a 
fullscreen surface would look weird with a title bar, but it is usable, 
and will be on top of everything, just like intended.

Thoughts?

Nit: it should be  not . ;-)

Cheers,


Jonas

 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
index 563e39b..73944a8 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -734,6 +734,29 @@
   
 

+
+  
+   Certain xdg_toplevel states mandate certain client capabilities. For
+   example while a fullscreen:ed client is required to configure itself
+   according to the dimension in the configure event, some clients may not
+   have this ability due to various reasons.
+  
+  
+  
+
+
+
+  
+   Notify the compositor about what capabilities this xdg_toplevel
+   supports. This request can only be issued once and if so must be done
+   before the initial state is comitted. The default capabilities are no
+   capabilities.
+  
+  
+
+
 
   
Set a maximum size for the window.




--

Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols 3/3] xdg-shell: Add resize_x/y constrain adjustment to positioner

[Quentin Glidic]

On 15/07/2016 11:37, Jonas Ådahl wrote:

In order to get feedback of available space where a client can create
its popup, let it create requset that its popup rectangle being resized
would it not fit the within the work area. This adds two new constrain
adjustment values to the adjustment enum, and dimension parameters to
the xdg_popup.configure event.

The existing constrain adjustment actions take precedence, and resizing
will only be triggered if all other adjustments requested didn't manage
to make the popup rectangle fully visible.

Signed-off-by: Jonas Ådahl 
---


Sounds good:
Acked-by: Quentin Glidic 

Cheers,



 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 40 +---
 1 file changed, 30 insertions(+), 10 deletions(-)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
index 644dbc2..563e39b 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -239,6 +239,19 @@
 

 
+  
+   The constrain adjustment value define ways the compositor will adjust
+   the position of the surface, if the unadjusted position would result
+   in the surface being partly constrained.
+
+   What a constrained surface means is compositor specific, but it could
+   for example be partly outside of the work area of a monitor.
+
+   Multiple constrain adjustment values can be combined, in which case
+   they have a defined precedence. The order of adjustments is: flip,
+   slide then resize.
+  
+
   

  Don't alter the surface position even if it is constrained on some
@@ -258,8 +271,6 @@
  x axis until either the edge in the direction of the gravity is
  unconstrained or the edge in the opposite direction of the gravity is
  constrained.
-
- If 'slide_x' is combined with 'flip_x', 'flip_x' takes precedence.

   
   
@@ -275,8 +286,6 @@
  y axis until either the edge in the direction of the gravity is
  unconstrained or the edge in the opposite direction of the gravity is
  constrained.
-
- If 'slide_y' is combined with 'flip_y', 'flip_y' takes precedence.

   
   
@@ -287,9 +296,8 @@
  'left', change the gravity to 'right' and the anchor to 'right'.

  If the adjusted position also ends up being constrained, the resulting
- position will be the one before the adjustment. If the resulting
- position is still constrained, and 'flip_x' is combined with
- 'slide_x', the position is adjusted according to 'slide_x'.
+ position of the flip_x adjustment will be the one before the
+ adjustment.

   
   
@@ -300,9 +308,19 @@
  'bottom', change the gravity to 'top' and the anchor to 'top'.

  If the adjusted position also ends up being constrained, the resulting
- position will be the one before the adjustment. If the resulting
- position is still constrained, and 'flip_y' is combined with
- 'slide_y', the position is adjusted according to 'slide_y'.
+ position of the flip_y adjustment will be the one before the
+ adjustment.
+   
+  
+  
+   
+ Resize the surface horizontally so that it is completely
+ unconstrained.
+   
+  
+  
+   
+ Resize the surface vertically so that it is completely unconstrained.

   
 
@@ -1027,6 +1045,8 @@
   summary="x position relative to parent surface window geometry"/>
   
+  
+  
 

 




--

Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols 1/3] xdg-shell: Don't require the client to obay configure sizes

[Quentin Glidic]

On 15/07/2016 11:37, Jonas Ådahl wrote:

Some clients cannot obay arbitrary dimensions configured via
xdg_toplevel.configure. For example, a client surface could require to
have a certain aspect ratio, or not even be able to resize at all.

Prior to this patch, such clients could not be implemented correctly, as
the compositor is allowed to ignore the max/min size limits set by the
client, resulting in the client either having to abort itself or being
disconnected by the compositor when it disobayed the mandated
configuration.

With this change, compositors can up front make the decision to either
disconnect a client that will not be able to resize to a certain size,
or deal with it in some way, such as adding padding or scaling.

Signed-off-by: Jonas Ådahl 
---


As commented on IRC, NAK from me here.
I see the xdg_toplevel capabilities as a nicer answer to the issue.

My rationale:
The "fullscreen" and "maximized" state should be complete features, not 
something the client can half-implement. If a client claims to support 
them, it must obey the compositor as no other component will know better 
which size will fit, but only the client knows how to fill the space 
(e.g. padding with the background colour for a terminal, instead of dumb 
black, which would looks weird if the terminal uses white as background).


Cheers,



 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
index 8da9c57..862e664 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -690,13 +690,13 @@
   

  The surface is maximized. The window geometry specified in the 
configure
- event must be obeyed by the client.
+ event should be obeyed by the client.

   
   

  The surface is fullscreen. The window geometry specified in the 
configure
- event must be obeyed by the client.
+ event should be obeyed by the client.

   
   




--

Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols v4 7/7] xdg-shell: Introduce xdg_positioner

[Quentin Glidic]

On 24/06/2016 08:47, Jonas Ådahl wrote:

xdg_positioner is a method for declarative positioning of child surfaces
(currently only xdg_popup surfaces). A client creates a description of a
positioning logic using the xdg_positioner interface. The xdg_positioner
object is then used when creating a xdg_popup for describing how the
child surface should be positioned in relation to the parent surface.

Signed-off-by: Jonas Ådahl 
Signed-off-by: Mike Blumenkrantz 
Acked-by: Yong Bakos 
---


I like the idea. I would love to test it for real, but Weston will be 
hard to port to v6. ;-)


Acked-by: Quentin Glidic 

Cheers,




Changes since v3:

 - Allow combining slide_x/y and flip_x/y enums, while explaining the order of
   adjustments.
 - Reworded the non-immediate effect of the configure event (the same as
   xdg-surface generic split update)


 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 266 ++-
 1 file changed, 263 insertions(+), 3 deletions(-)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
index 4c5dab4..7fab656 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -45,6 +45,8 @@
 summary="the client specified an invalid popup parent surface"/>
   
+  
 

 
@@ -57,6 +59,15 @@
   
 

+
+  
+   Create a positioner object. A positioner object is used to position
+   surfaces relative to some parent surface. See the interface description
+   and xdg_surface.get_popup for details.
+  
+  
+
+
 
   
This creates an xdg_surface for the given surface. While xdg_surface
@@ -101,6 +112,240 @@
 
   

+  
+
+  The xdg_positioner provides an interface for constructing positioning
+  rules used for positioning a child surface relative to a parent surface
+  in a certain way. It allows methods for defining a rule that will make
+  the child surface stay within the border of the visible area of the
+  screen, with different ways in which the child surface should change
+  its position, including sliding along an axis, or flipping around a
+  rectangle.
+
+  See the various requests for details about possible rules.
+
+  Semantically, an xdg_positioner is a collection of positioning rules. 
When
+  used for positioning a surface, for example when passed as an argument to
+  xdg_surface.get_popup, the compositor copies the rules that were set up 
at
+  the time of the request. Making any changes or destroying the object 
after
+  it was used has no effect on previous usages.
+
+  For an xdg_positioner object to be considered complete, it must have a
+  non-zero size set by set_size, and a non-zero anchor rectangle set by
+  set_anchor_rect. Passing an incomplete xdg_positioner object when
+  positioning a surface raises an error.
+
+
+
+  
+
+
+
+  
+   Notify the compositor that the xdg_positioner will no longer be used.
+  
+
+
+
+  
+   Set the size of the surface that is to be positioned with the positioner
+   object. The size is in surface-local coordinates and corresponds to the
+   window geometry. See xdg_surface.set_window_geometry.
+
+   If a zero or negative size is set the invalid_input error is raised.
+  
+  
+  
+
+
+
+  
+   Specify the anchor rectangle within the parent surface that the child
+   surface will be placed relative to. The rectangle is relative to the
+   window geometry as defined by xdg_surface.set_window_geometry of the
+   parent surface. The rectangle must be at least 1x1 large.
+
+   When the xdg_positioner object is used to position a child surface, the
+   anchor rectangle may not extend outside the window geometry of the
+   positioned child's parent surface.
+
+   If a zero or negative size is set the invalid_input error is raised.
+  
+  
+  
+  
+  
+
+
+
+  
+  
+  
+  
+  
+
+
+
+  
+   Set the anchor edges of the anchor rectangle. The anchor edges define
+   where on the anchor rectangle the child surface should be positioned
+   relative to. An anchor is a bit mask of up to two values of the anchor
+   enum.
+
+   If two values on the same axis (for example left and right) are set the
+   invalid_input error is raised.
+
+   If no anchor is set on any axis, the anchor position will be positioned
+   at the center of the anchor rectangle on the unset axis. The default
+   value is "none".
+  
+  
+
+
+
+  
+  
+  
+  
+  
+
+
+
+  
+   The gravity defines in what direction a surface would be positioned,
+   relative to the 

Re: [PATCH wayland-protocols v4 5/7] xdg-shell: Make get_popup take a xdg_surface instead of wl_surface

[Quentin Glidic]

On 24/06/2016 08:47, Jonas Ådahl wrote:

The reason for using wl_surface before was that xdg_popup and
xdg_surface (now xdg_toplevel) had no common interface other than
wl_surface, but since xdg_surface is now the base interface, lets use
that.

Signed-off-by: Jonas Ådahl 
Reviewed-by: Mike Blumenkrantz 
Reviewed-by: Yong Bakos 
Reviewed-by: Benoit Gschwind 
---


Really neat, avoids a few checks:
Reviewed-by: Quentin Glidic 

Cheers,




No changes since v3.

 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
index fc41485..e4d552c 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -171,7 +171,7 @@
xdg_popup is and how it is used.
   
   
-  
+  
   
   
   




--

Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols v4 4/7] xdg-shell: Improve error enum formatting some

[Quentin Glidic]

On 24/06/2016 08:47, Jonas Ådahl wrote:

The long lines stood out, break them by putting the summary on its own
line.

Signed-off-by: Jonas Ådahl 
Reviewed-by: Yong Bakos 
Reviewed-by: Mike Blumenkrantz 
Reviewed-by: Benoit Gschwind 
---


Trivial enough:
Reviewed-by: Quentin Glidic 

Cheers,




No changes since v3.

 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
index 858c13e..fc41485 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -37,10 +37,14 @@

 
   
-  
-  
-  
-  
+  
+  
+  
+  
 

 




--

Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols v4 3/7] xdg-shell: Add error codes for invalid surface state

[Quentin Glidic]

On 24/06/2016 08:47, Jonas Ådahl wrote:

Signed-off-by: Jonas Ådahl 
Reviewed-by: Mike Blumenkrantz 
Reviewed-by: Yong Bakos 
---


Sounds good:
Acked-by: Quentin Glidic 

Cheers,




No changes since v3.

 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
index a7294dc..858c13e 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -40,6 +40,7 @@
   
   
   
+  
 

 
@@ -133,6 +134,7 @@
 
   
   
+  
 

 




--

Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols v4 2/7] xdg-shell: Put xdg_shell events after requests

[Quentin Glidic]

On 24/06/2016 08:47, Jonas Ådahl wrote:

It makes the structure consistent with most other protocols and
provides a clear separation between what is done by the server and what
is done by the client.

Signed-off-by: Jonas Ådahl 
Reviewed-by: Yong Bakos 
Reviewed-by: Mike Blumenkrantz 
---


Just moving stuff around so:
Reviewed-by: Quentin Glidic 

Cheers,




Changes since v3:

 - Added 'See xdg_shell.ping/pong' to xdg_shell.pong/ping.

 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 74 ++--
 1 file changed, 37 insertions(+), 37 deletions(-)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
index 3268077..a7294dc 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -70,11 +70,19 @@
   
 

+
+  
+   A client must respond to a ping event with a pong request or
+   the client may be deemed unresponsive. See xdg_shell.ping.
+  
+  
+
+
 
   
The ping event asks the client if it's still alive. Pass the
serial specified in the event back to the compositor by sending
-   a "pong" request back with the specified serial.
+   a "pong" request back with the specified serial. See xdg_shell.ping.

Compositors can use this to determine if the client is still
alive. It's unspecified what will happen if the client doesn't
@@ -86,14 +94,6 @@
   
   
 
-
-
-  
-   A client must respond to a ping event with a pong request or
-   the client may be deemed unresponsive.
-  
-  
-
   

   
@@ -471,34 +471,6 @@
   
 

-
-  
-   This configure event asks the client to resize its toplevel surface or
-   to change its state. The configured state should not be applied
-   immediately. See xdg_surface.configure for details.
-
-   The width and height arguments specify a hint to the window
-   about how its surface should be resized in window geometry
-   coordinates. See set_window_geometry.
-
-   If the width or height arguments are zero, it means the client
-   should decide its own window dimension. This may happen when the
-   compositor need to configure the state of the surface but doesn't
-   have any information about any previous or expected dimension.
-
-   The states listed in the event specify how the width/height
-   arguments should be interpreted, and possibly how it should be
-   drawn.
-
-   Clients must send an ack_configure in response to this event. See
-   xdg_surface.configure and xdg_surface.ack_configure for details.
-  
-
-  
-  
-  
-
-
 
   
Set a maximum size for the window.
@@ -653,6 +625,34 @@
   
 

+
+  
+   This configure event asks the client to resize its toplevel surface or
+   to change its state. The configured state should not be applied
+   immediately. See xdg_surface.configure for details.
+
+   The width and height arguments specify a hint to the window
+   about how its surface should be resized in window geometry
+   coordinates. See set_window_geometry.
+
+   If the width or height arguments are zero, it means the client
+   should decide its own window dimension. This may happen when the
+   compositor need to configure the state of the surface but doesn't
+   have any information about any previous or expected dimension.
+
+   The states listed in the event specify how the width/height
+   arguments should be interpreted, and possibly how it should be
+   drawn.
+
+   Clients must send an ack_configure in response to this event. See
+   xdg_surface.configure and xdg_surface.ack_configure for details.
+  
+
+  
+  
+  
+
+
 
   
The close event is sent by the compositor when the user




--

Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols v4 1/7] xdg-shell: Turn xdg_surface into a generic base interface

[Quentin Glidic]

On 24/06/2016 08:47, Jonas Ådahl wrote:

Split out toplevel window like requests and events into a new interface
called xdg_toplevel, and turn xdg_surface into a generic base interface
which others extends.

xdg_popup is changed to extend the xdg_surface.

The configure event in xdg_surface was split up making
xdg_surface.configure an event only carrying the serial number, while a
new xdg_toplevel.configure event carries the other data previously sent
via xdg_surface.configure. xdg_toplevel.configure is made to extend,
via the latch-state mechanism, xdg_surface.configure and depends on
that event to synchronize state.

Other future xdg_surface based extensions are meant to also extend
xdg_surface.configure for relevant window type dependend state
synchronization.

Signed-off-by: Jonas Ådahl 
Signed-off-by: Mike Blumenkrantz 
Reviewed-by: Yong Bakos 
---


Sounds good:
Acked-by: Quentin Glidic 

Cheers,




Changes since v3:

 - Clarify the requirements for a xdg_surface based surface to be mapped
 - Reword the non-immediate effect of xdg_surface.configure
 - Reword the explanation of a configure sequence
 - Clarify that xdg_surface forms a basis for xdg_surface based surface roles

 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 280 ---
 1 file changed, 170 insertions(+), 110 deletions(-)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
index ce57153..3268077 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -54,11 +54,14 @@

 
   
-   This creates an xdg_surface for the given surface and gives it the
-   xdg_surface role. A wl_surface can only be given an xdg_surface role
-   once. If get_xdg_surface is called with a wl_surface that already has
-   an active xdg_surface associated with it, or if it had any other role,
-   an error is raised.
+   This creates an xdg_surface for the given surface. While xdg_surface
+   itself is not a role, the corresponding surface may only be assigned
+   a role extending xdg_surface, such as xdg_toplevel or xdg_popup.
+
+   This creates an xdg_surface for the given surface. An xdg_surface is
+   used as basis to define a role to a given surface, such as xdg_toplevel
+   or xdg_popup. It also manages functionality shared between xdg_surface
+   based surface roles.

See the documentation of xdg_surface for more details about what an
xdg_surface is and how it is used.
@@ -67,29 +70,6 @@
   
 

-
-  
-   This creates an xdg_popup for the given surface and gives it the
-   xdg_popup role. A wl_surface can only be given an xdg_popup role
-   once. If get_xdg_popup is called with a wl_surface that already has
-   an active xdg_popup associated with it, or if it had any other role,
-   an error is raised.
-
-   This request must be used in response to some sort of user action
-   like a button press, key press, or touch down event.
-
-   See the documentation of xdg_popup for more details about what an
-   xdg_popup is and how it is used.
-  
-  
-  
-  
-  
-  
-  
-  
-
-
 
   
The ping event asks the client if it's still alive. Pass the
@@ -117,13 +97,23 @@
   

   
-
+
   An interface that may be implemented by a wl_surface, for
   implementations that provide a desktop-style user interface.

-  It provides requests to treat surfaces like windows, allowing to set
-  properties like maximized, fullscreen, minimized, and to move and resize
-  them, and associate metadata like title and app id.
+  It provides a base set of functionality required to construct user
+  interface elements requiring management by the compositor, such as
+  toplevel windows, menus, etc. The types of functionality are split into
+  xdg_surface roles.
+
+  Creating an xdg_surface does not set the role for a wl_surface. In order
+  to map an xdg_surface, the client must create a role-specific object
+  using, e.g., get_toplevel, get_popup. The wl_surface for any given
+  xdg_surface can have at most one role, and may not be assigned any role
+  not based on xdg_surface.
+
+  A role must be assigned before any other requests are made to the
+  xdg_surface object.

   The client must call wl_surface.commit on the corresponding wl_surface
   for the xdg_surface state to take effect.
@@ -133,12 +123,147 @@
   manipulate a buffer prior to the first xdg_surface.configure call must
   also be treated as errors.

-  For a surface to be mapped by the compositor the client must have
-  committed both an xdg_surface state and a buffer.
+  For a surface to be mapped by the compositor, the following conditions

When to use libweston plugin registry

[Pekka Paalanen]

Hi Armin,

I didn't manage to catch you online, so here is re:
https://paste.debian.net/hidden/ac601ed5/

Yes, that's the mechanics of using the plugin registry, but I
didn't think of using it for those particular entries.

For libweston-core <-> backend APIs using the plugin registry seems
like an unnecessary detour. I don't see it benefiting anything.
Libweston-core loads the backend directly and communicates with it
directly. We also wouldn't want to expose interfaces meant only for
the use of libweston-core. libweston-core is non-optional, so the
flexibility is not useful.

Originally plugin registry was written for plugins to interface
with other plugins, so that we don't need to keep adding new
plugin-specific APIs or relays to (lib)weston-core or the
compositor.

Another use case in my mind is offering optional interfaces from
libweston and anything below it to the compositor. It might be seen
as a layering violation since we skip over libweston-core rather
than plumbing things through it, but in this case I think it's for
the better.

E.g. DRM-backend specific APIs might want to use libdrm, libudev or
libinput types. If these were exposed from libweston proper, we
would have libweston depend on all of them, regardless whether the
compositor actually wanted the DRM-backend. It would be even more
glaring if x11-backend had some API using XCB or X11 types,
causing libweston to depend on libxcb. When we use the plugin
registry for these, we don't need the extra dependencies on the
libweston-core. The extra dependencies can be pulled in by the
backends and the interface headers used with the plugin registry as
needed instead of always.

In summary, I'd like to see the plugin registry used for optional
interfaces that might also come with a cost (e.g. extra
dependencies) if offered straight from libweston proper.

I still consider it optional even if it is mandatory for using a
specific backend or feature, because compositors are free to choose
the backend(s) and features they use.


Thanks,
pq


pgpqxbSfVoWhS.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols v5 1/4] tablet: add v2 of the tablet protocol

[Jonas Ådahl]

All 4 patches merged, with the typo mentioned by Peter and wording
change suggested by Jason, as well as with Bryce and my RBs:

   2009a70..24eb670  master -> master

Will let it brew over the night a and make release hopefully tomorrow.


Jonas

On Mon, Jul 11, 2016 at 05:13:33PM +0200, Carlos Garnacho wrote:
> From: Peter Hutterer 
> 
> This is a straightforward copy/paste with a _v1 -> _v2 rename. No functional
> changes otherwise.
> 
> Signed-off-by: Peter Hutterer 
> Reviewed-by: Jason Gerecke 
> Reviewed-by: Carlos Garnacho 
> ---
>  Makefile.am|   1 +
>  unstable/tablet/tablet-unstable-v2.xml | 641 
> +
>  2 files changed, 642 insertions(+)
>  create mode 100644 unstable/tablet/tablet-unstable-v2.xml
> 
> diff --git a/Makefile.am b/Makefile.am
> index 71d2632..9e2a029 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -8,6 +8,7 @@ unstable_protocols =  
> \
>   unstable/relative-pointer/relative-pointer-unstable-v1.xml  
> \
>   unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
> \
>   unstable/tablet/tablet-unstable-v1.xml  
> \
> + unstable/tablet/tablet-unstable-v2.xml  
> \
>   $(NULL)
>  
>  stable_protocols =   
> \
> diff --git a/unstable/tablet/tablet-unstable-v2.xml 
> b/unstable/tablet/tablet-unstable-v2.xml
> new file mode 100644
> index 000..81e9835
> --- /dev/null
> +++ b/unstable/tablet/tablet-unstable-v2.xml
> @@ -0,0 +1,641 @@
> +
> +
> +
> +  
> +Copyright 2014 © Stephen "Lyude" Chandler Paul
> +Copyright 2015-2016 © Red Hat, Inc.
> +
> +Permission is hereby granted, free of charge, to any person
> +obtaining a copy of this software and associated documentation files
> +(the "Software"), to deal in the Software without restriction,
> +including without limitation the rights to use, copy, modify, merge,
> +publish, distribute, sublicense, and/or sell copies of the Software,
> +and to permit persons to whom the Software is furnished to do so,
> +subject to the following conditions:
> +
> +The above copyright notice and this permission notice (including the
> +next paragraph) shall be included in all copies or substantial
> +portions of the Software.
> +
> +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> +EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> +MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> +NONINFRINGEMENT.  IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
> +BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
> +ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
> +CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
> +SOFTWARE.
> +  
> +
> +  
> +This description provides a high-level overview of the interplay between
> +the interfaces defined this protocol. For details, see the protocol
> +specification.
> +
> +More than one tablet may exist, and device-specifics matter. Tablets are
> +not represented by a single virtual device like wl_pointer. A client
> +binds to the tablet manager object which is just a proxy object. From
> +that, the client requests wp_tablet_manager.get_tablet_seat(wl_seat)
> +and that returns the actual interface that has all the tablets. With
> +this indirection, we can avoid merging wp_tablet into the actual Wayland
> +protocol, a long-term benefit.
> +
> +The wp_tablet_seat sends a "tablet added" event for each tablet
> +connected. That event is followed by descriptive events about the
> +hardware; currently that includes events for name, vid/pid and
> +a wp_tablet.path event that describes a local path. This path can be
> +used to uniquely identify a tablet or get more information through
> +libwacom. Emulated or nested tablets can skip any of those, e.g. a
> +virtual tablet may not have a vid/pid. The sequence of descriptive
> +events is terminated by a wp_tablet.done event to signal that a client
> +may now finalize any initialization for that tablet.
> +
> +Events from tablets require a tool in proximity. Tools are also managed
> +by the tablet seat; a "tool added" event is sent whenever a tool is new
> +to the compositor. That event is followed by a number of descriptive
> +events about the hardware; currently that includes capabilities,
> +hardware id and serial number, and tool type. Similar to the tablet
> +interface, a wp_tablet_tool.done event is sent to terminate that initial
> +sequence.
> +
> +Any event from a tool happens on the wp_tablet_tool interface. When the
> +

Re: [RFC PATCH wayland] wayland-server: Add API to control globals visibility

[Jonas Ådahl]

On Wed, Jul 06, 2016 at 03:45:00PM +0200, Olivier Fourdan wrote:
> Add a new API to let compositor decide whether or not a wl_global
> should be advertised to the clients via wl_registry_bind() or
> display_get_registry()
> 
> By using its own filter, the compositor can decide which wl_global would
> be listed to clients.
> 
> Compositors can use this mechanism to hide their own private interfaces
> that regular clients should not use.

FWIW, I think this is a reasonable idea, especially when compositors use
private shell protocols that shouldn't be used by random clients, 
thus there is no reason to expose them. Right now we simply rely on
disconnecting any client that tries to bind a private protocol. Some
comments on the patch itself follow.

> 
> Signed-off-by: Olivier Fourdan 
> ---
>  src/wayland-server-core.h |  8 +++
>  src/wayland-server.c  | 38 ++-
>  tests/display-test.c  | 57 
> +++
>  3 files changed, 97 insertions(+), 6 deletions(-)
> 
> diff --git a/src/wayland-server-core.h b/src/wayland-server-core.h
> index ad1292f..b02ebcd 100644
> --- a/src/wayland-server-core.h
> +++ b/src/wayland-server-core.h
> @@ -28,6 +28,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include "wayland-util.h"
>  #include "wayland-version.h"
>  
> @@ -141,6 +142,9 @@ struct wl_client;
>  typedef void (*wl_global_bind_func_t)(struct wl_client *client, void *data,
> uint32_t version, uint32_t id);
>  
> +typedef bool (*wl_display_filter_global_func_t)(const struct wl_client 
> *client,
> + const struct wl_interface 
> *interface);

Probably want a void *user_data here. I also wonder whether we should
just pass the wl_global instead of the interface, and maybe add a
wl_global_get_interface if we need to. If we just always pass just a
client and an interface, but for some reason want to add more details
about what global, we'll be in a difficult situation.

> +
>  uint32_t
>  wl_display_get_serial(struct wl_display *display);
>  
> @@ -155,6 +159,10 @@ struct wl_listener *
>  wl_display_get_destroy_listener(struct wl_display *display,
>   wl_notify_func_t notify);
>  
> +void
> +wl_display_set_filter_global(struct wl_display *display,
> +  wl_display_filter_global_func_t filter);
> +
>  struct wl_global *
>  wl_global_create(struct wl_display *display,
>const struct wl_interface *interface,
> diff --git a/src/wayland-server.c b/src/wayland-server.c
> index 19aa2e8..55e532e 100644
> --- a/src/wayland-server.c
> +++ b/src/wayland-server.c
> @@ -98,6 +98,7 @@ struct wl_display {
>   struct wl_signal destroy_signal;
>  
>   struct wl_array additional_shm_formats;
> + wl_display_filter_global_func_t wl_display_global_filter;
>  };
>  
>  struct wl_global {
> @@ -740,7 +741,8 @@ registry_bind(struct wl_client *client,
>  WL_DISPLAY_ERROR_INVALID_OBJECT,
>  "invalid version for global %s (%d): 
> have %d, wanted %d",
>  interface, name, global->version, 
> version);
> - else
> + else if (display->wl_display_global_filter == NULL ||
> +  display->wl_display_global_filter (client, global->interface))

Could probably put these two lines in a filter_global (client, global)
helper, which can be reused in display_get_registry().

Also, in the case that a client tries to bind a filtered global, we
should probably just disconnect it.


Jonas

>   global->bind(client, global->data, version, id);
>  }
>  
> @@ -795,11 +797,13 @@ display_get_registry(struct wl_client *client,
>  _resource->link);
>  
>   wl_list_for_each(global, >global_list, link)
> - wl_resource_post_event(registry_resource,
> -WL_REGISTRY_GLOBAL,
> -global->name,
> -global->interface->name,
> -global->version);
> + if (display->wl_display_global_filter == NULL ||
> + display->wl_display_global_filter (client, 
> global->interface))
> + wl_resource_post_event(registry_resource,
> +WL_REGISTRY_GLOBAL,
> +global->name,
> +global->interface->name,
> +global->version);
>  }
>  
>  static const struct wl_display_interface display_interface = {
> @@ -867,6 +871,7 @@ wl_display_create(void)
>  
>   display->id = 1;
>   display->serial = 0;
> + display->wl_display_global_filter = NULL;
>  
>   wl_array_init(>additional_shm_formats);
>  
> @@ -940,6 +945,27 @@