[xkbcommon] Use an integer type for modifiers bit mask.

2013-10-03 Thread Wander Lairson Costa 
If we combine two enum values, the result is not a valid enum value
anymore, so it cannot be attributed to an enum variable.

C++ compilers will complain if such an assigment is done.

Signed-off-by: Wander Lairson Costa 
---
 src/state.c   | 10 +-
 xkbcommon/xkbcommon.h |  8 
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/src/state.c b/src/state.c
index e13d1fd..aaae5c7 100644
--- a/src/state.c
+++ b/src/state.c
@@ -678,7 +678,7 @@ xkb_state_update_derived(struct xkb_state *state)
 xkb_state_led_update_all(state);
 }
 
-static enum xkb_state_component
+static xkb_mod_mask_t
 get_state_component_changes(const struct state_components *a,
 const struct state_components *b)
 {
@@ -710,7 +710,7 @@ get_state_component_changes(const struct state_components 
*a,
  * Given a particular key event, updates the state structure to reflect the
  * new modifiers.
  */
-XKB_EXPORT enum xkb_state_component
+XKB_EXPORT xkb_mod_mask_t
 xkb_state_update_key(struct xkb_state *state, xkb_keycode_t kc,
  enum xkb_key_direction direction)
 {
@@ -760,7 +760,7 @@ xkb_state_update_key(struct xkb_state *state, xkb_keycode_t 
kc,
  * lossy, and should only be used to update a slave state mirroring the
  * master, e.g. in a client/server window system.
  */
-XKB_EXPORT enum xkb_state_component
+XKB_EXPORT xkb_mod_mask_t
 xkb_state_update_mask(struct xkb_state *state,
   xkb_mod_mask_t base_mods,
   xkb_mod_mask_t latched_mods,
@@ -861,7 +861,7 @@ xkb_state_key_get_one_sym(struct xkb_state *state, 
xkb_keycode_t kc)
  */
 XKB_EXPORT xkb_mod_mask_t
 xkb_state_serialize_mods(struct xkb_state *state,
- enum xkb_state_component type)
+ xkb_mod_mask_t type)
 {
 xkb_mod_mask_t ret = 0;
 
@@ -884,7 +884,7 @@ xkb_state_serialize_mods(struct xkb_state *state,
  */
 XKB_EXPORT xkb_layout_index_t
 xkb_state_serialize_layout(struct xkb_state *state,
-   enum xkb_state_component type)
+   xkb_mod_mask_t type)
 {
 xkb_layout_index_t ret = 0;
 
diff --git a/xkbcommon/xkbcommon.h b/xkbcommon/xkbcommon.h
index cc9262f..b9d1dd0 100644
--- a/xkbcommon/xkbcommon.h
+++ b/xkbcommon/xkbcommon.h
@@ -1166,7 +1166,7 @@ enum xkb_state_component {
  *
  * @sa xkb_state_update_mask()
  */
-enum xkb_state_component
+xkb_mod_mask_t
 xkb_state_update_key(struct xkb_state *state, xkb_keycode_t key,
  enum xkb_key_direction direction);
 
@@ -1197,7 +1197,7 @@ xkb_state_update_key(struct xkb_state *state, 
xkb_keycode_t key,
  * @sa xkb_state_component
  * @sa xkb_state_update_key
  */
-enum xkb_state_component
+xkb_mod_mask_t
 xkb_state_update_mask(struct xkb_state *state,
   xkb_mod_mask_t depressed_mods,
   xkb_mod_mask_t latched_mods,
@@ -1331,7 +1331,7 @@ enum xkb_state_match {
  */
 xkb_mod_mask_t
 xkb_state_serialize_mods(struct xkb_state *state,
- enum xkb_state_component components);
+ xkb_mod_mask_t components);
 
 /**
  * The counterpart to xkb_state_update_mask for layouts, to be used on
@@ -1353,7 +1353,7 @@ xkb_state_serialize_mods(struct xkb_state *state,
  */
 xkb_layout_index_t
 xkb_state_serialize_layout(struct xkb_state *state,
-   enum xkb_state_component components);
+   xkb_mod_mask_t components);
 
 /**
  * Test whether a modifier is active in a given keyboard state by name.
-- 
1.8.1.2

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

Re: [PATCH v2] Post buffer release events instead of queue when no frame callback

2013-10-03 Thread Jason Ekstrand 
Neil,
After further consideration, I think your approach is exactly what we need.
Not only are there more possible (backend-dependant) release algorithms
than the two I listed but determining whether to queue or post may be more
complicated. For instance, if a frame is offscreen it may have frame
callbacks pending that will not get sent. Should we make sure the regular
gets sent anyway?

I don't think this last issue is a showstopper as the patch is no worse
than the current implementation. I'd say we apply this now and get the pi
backend working. We can fix release of offscreen surfaces later.

-- Jason Ekstrand
On Oct 2, 2013 2:20 PM, "Jason Ekstrand"  wrote:

>
> On Oct 2, 2013 10:06 AM, "Neil Roberts"  wrote:
> >
> > I don't think this function would help in cases where the buffer is
> > released after the frame is drawn but the compositor is not drawing
> > anything else. Ie, if the events were like this:
> >
> > 1 - client attaches a buffer and waits for the next release
> > 2 - compositor redraws a frame
> > 3 - the redraw completes so the compositor flushes all event queues
> > 4 - the swap completes and the compositor queues a release event
> >
> > If nothing else causes the compositor to queue a redraw the release
> > event will just sit in the event queue forever and the client will still
> > be blocked waiting for it.
>
> If the backend is going to send the release from the swap, shouldn't it
> just post instead of queue anyway?  The reason for queueing in the first
> place is to simply delay the event until the render.  Perhaps I am
> misunderstanding what you mean.
>
> Also, I can really only envision two cases for buffer releasing:
>
> 1. Where the compositor can release the buffer as soon as it is on the
> card (the current case with shm and the go renderer). In this case we can
> send the release during the render or earlier.
>
> 2. Where the compositor cannot release the buffer until it is done with
> the render (go client in a DRM plane).  In this case you can't release
> until the client commits another buffer (causing a repaint) because you
> might need it for a second render.  In order to handle handle this case, we
> may have to post instead of queue in the case where the client is off
> screen.
>
> Am I missing any cases?  If I am then the current system is probably
> fundamentally broken anyway.  In that case, what you have is probably the
> best solution.
>
> > I think this doesn't actually happen at the moment because as far as I
> > can tell the gl-renderer immediately queues the buffer release when you
> > attach a new one rather than waiting for the swap to actually complete.
> > I think that would mean you could cause tearing if you are using
> > eglSwapInterval(0) because you could write into the released buffer
> > while the GPU is actually still rendering the previous frame using the
> > buffer in a texture.
>
> I recall there being a good reason why this isn't a problem.  Something
> about the way the drivers are implemented but I don't remember the details.
>
> > I will try an experiment to check this. If that's right then we should
> > probably add an extra buffer reference in the gl-renderer whenever it
> > uses a texture to draw and then only release it when the frame is
> > complete.
> >
> > Regards,
> > - Neil
> >
> > Jason Ekstrand  writes:
> >
> > > All,
> > > Perhaps a simpler approach would be better.  We could add a function to
> > > wayland-server called wl_client_post_event_queue which would simply
> set the
> > > wants_flush flag on the client connection. This function would be fast
> > > ,require no I/O, and safe to call multiple times so Weston could simply
> > > call it on all clients with surfaces visible on the output in question
> at
> > > the time when it would call frame events.  Then, when the event loop
> > > flushes the clients, the release events will get sent out.
> > > --Jason Ekstrand
> > -
> > Intel Corporation (UK) Limited
> > Registered No. 1134945 (England)
> > Registered Office: Pipers Way, Swindon SN3 1RJ
> > VAT No: 860 2173 47
> >
> > This e-mail and any attachments may contain confidential material for
> > the sole use of the intended recipient(s). Any review or distribution
> > by others is strictly prohibited. If you are not the intended
> > recipient, please contact the sender and delete all copies.
> >
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston 3/4] Only update the touch grab position for the first finger

2013-10-03 Thread Neil Roberts 
Previously if you add a second finger while moving a window with a
touch grab then the position will keep jumping between the position of
each finger as you move them around. This patch changes it so that it
keeps track of the first touch id that starts the grab and only
updates the grab position when that finger moves.
---
 src/compositor.h | 1 +
 src/input.c  | 7 +--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/compositor.h b/src/compositor.h
index ad5a786..ffa5124 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -343,6 +343,7 @@ struct weston_touch {
 
struct weston_touch_grab *grab;
struct weston_touch_grab default_grab;
+   int grab_touch_id;
wl_fixed_t grab_x, grab_y;
uint32_t grab_serial;
uint32_t grab_time;
diff --git a/src/input.c b/src/input.c
index 3e4f4b1..4e6818c 100644
--- a/src/input.c
+++ b/src/input.c
@@ -1093,8 +1093,10 @@ notify_touch(struct weston_seat *seat, uint32_t time, 
int touch_id,
wl_fixed_t sx, sy;
 
/* Update grab's global coordinates. */
-   touch->grab_x = x;
-   touch->grab_y = y;
+   if (touch_id == touch->grab_touch_id && touch_type != WL_TOUCH_UP) {
+   touch->grab_x = x;
+   touch->grab_y = y;
+   }
 
switch (touch_type) {
case WL_TOUCH_DOWN:
@@ -1124,6 +1126,7 @@ notify_touch(struct weston_seat *seat, uint32_t time, int 
touch_id,
if (seat->num_tp == 1) {
touch->grab_serial =
wl_display_get_serial(ec->wl_display);
+   touch->grab_touch_id = touch_id;
touch->grab_time = time;
touch->grab_x = x;
touch->grab_y = y;
-- 
1.8.3.1

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

[PATCH weston 4/4] Don't remove the touch grab until the last touch point is removed

2013-10-03 Thread Neil Roberts 
Previously if you move a window around and temporarily add a second
finger then it will cancel the grab even though the original finger is
still held on the screen. It seems more robust to avoid cancelling the
grab until all fingers have been removed.
---
 src/shell.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/shell.c b/src/shell.c
index 2822a2b..45bbed3 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -1085,7 +1085,9 @@ touch_move_grab_up(struct weston_touch_grab *grab, 
uint32_t time, int touch_id)
struct shell_touch_grab *shell_grab = container_of(grab, 
   struct 
shell_touch_grab,
   grab);
-   shell_touch_grab_end(shell_grab);
+
+   if (grab->touch->seat->num_tp == 0)
+   shell_touch_grab_end(shell_grab);
 }
 
 static void
-- 
1.8.3.1

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

[PATCH weston 2/4] Add a touch move binding

2013-10-03 Thread Neil Roberts 
When holding the compositor super key the touch events can now be used
to move a window.
---
 src/shell.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/src/shell.c b/src/shell.c
index 4a0c122..2822a2b 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -2774,6 +2774,26 @@ move_binding(struct weston_seat *seat, uint32_t time, 
uint32_t button, void *dat
 }
 
 static void
+touch_move_binding(struct weston_seat *seat, uint32_t time, void *data)
+{
+   struct weston_surface *focus =
+   (struct weston_surface *) seat->touch->focus;
+   struct weston_surface *surface;
+   struct shell_surface *shsurf;
+
+   surface = weston_surface_get_main_surface(focus);
+   if (surface == NULL)
+   return;
+
+   shsurf = get_shell_surface(surface);
+   if (shsurf == NULL || shsurf->type == SHELL_SURFACE_FULLSCREEN ||
+   shsurf->type == SHELL_SURFACE_MAXIMIZED)
+   return;
+
+   surface_touch_move(shsurf, (struct weston_seat *) seat);
+}
+
+static void
 resize_binding(struct weston_seat *seat, uint32_t time, uint32_t button, void 
*data)
 {
struct weston_surface *focus =
@@ -4531,6 +4551,7 @@ shell_add_bindings(struct weston_compositor *ec, struct 
desktop_shell *shell)
  zoom_key_binding, NULL);
weston_compositor_add_button_binding(ec, BTN_LEFT, mod, move_binding,
 shell);
+   weston_compositor_add_touch_binding(ec, mod, touch_move_binding, shell);
weston_compositor_add_button_binding(ec, BTN_MIDDLE, mod,
 resize_binding, shell);
 
-- 
1.8.3.1

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

[PATCH weston 1/4] Add a touch binding to activate a surface

2013-10-03 Thread Neil Roberts 
Adds a new binding type for touch events via the new function
weston_compositor_add_touch_binding. The binding can only be added for
a touch down with the first finger. The shell now uses this to install
a binding to activate the current surface.
---
 src/bindings.c   | 36 
 src/compositor.c |  2 ++
 src/compositor.h | 14 ++
 src/input.c  |  2 ++
 src/shell.c  | 36 
 5 files changed, 82 insertions(+), 8 deletions(-)

diff --git a/src/bindings.c b/src/bindings.c
index f6ec9ea..03c9238 100644
--- a/src/bindings.c
+++ b/src/bindings.c
@@ -94,6 +94,24 @@ weston_compositor_add_button_binding(struct 
weston_compositor *compositor,
 }
 
 WL_EXPORT struct weston_binding *
+weston_compositor_add_touch_binding(struct weston_compositor *compositor,
+   uint32_t modifier,
+   weston_touch_binding_handler_t handler,
+   void *data)
+{
+   struct weston_binding *binding;
+
+   binding = weston_compositor_add_binding(compositor, 0, 0, 0,
+   modifier, handler, data);
+   if (binding == NULL)
+   return NULL;
+
+   wl_list_insert(compositor->touch_binding_list.prev, &binding->link);
+
+   return binding;
+}
+
+WL_EXPORT struct weston_binding *
 weston_compositor_add_axis_binding(struct weston_compositor *compositor,
   uint32_t axis, uint32_t modifier,
   weston_axis_binding_handler_t handler,
@@ -253,6 +271,24 @@ weston_compositor_run_button_binding(struct 
weston_compositor *compositor,
}
 }
 
+WL_EXPORT void
+weston_compositor_run_touch_binding(struct weston_compositor *compositor,
+   struct weston_seat *seat, uint32_t time,
+   int touch_type)
+{
+   struct weston_binding *b;
+
+   if (seat->num_tp != 1 || touch_type != WL_TOUCH_DOWN)
+   return;
+
+   wl_list_for_each(b, &compositor->touch_binding_list, link) {
+   if (b->modifier == seat->modifier_state) {
+   weston_touch_binding_handler_t handler = b->handler;
+   handler(seat, time, b->data);
+   }
+   }
+}
+
 WL_EXPORT int
 weston_compositor_run_axis_binding(struct weston_compositor *compositor,
   struct weston_seat *seat,
diff --git a/src/compositor.c b/src/compositor.c
index b8e442a..935015a 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -3112,6 +3112,7 @@ weston_compositor_init(struct weston_compositor *ec,
wl_list_init(&ec->output_list);
wl_list_init(&ec->key_binding_list);
wl_list_init(&ec->button_binding_list);
+   wl_list_init(&ec->touch_binding_list);
wl_list_init(&ec->axis_binding_list);
wl_list_init(&ec->debug_binding_list);
 
@@ -3172,6 +3173,7 @@ weston_compositor_shutdown(struct weston_compositor *ec)
 
weston_binding_list_destroy_all(&ec->key_binding_list);
weston_binding_list_destroy_all(&ec->button_binding_list);
+   weston_binding_list_destroy_all(&ec->touch_binding_list);
weston_binding_list_destroy_all(&ec->axis_binding_list);
weston_binding_list_destroy_all(&ec->debug_binding_list);
 
diff --git a/src/compositor.h b/src/compositor.h
index 9b48287..ad5a786 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -575,6 +575,7 @@ struct weston_compositor {
struct wl_list plane_list;
struct wl_list key_binding_list;
struct wl_list button_binding_list;
+   struct wl_list touch_binding_list;
struct wl_list axis_binding_list;
struct wl_list debug_binding_list;
 
@@ -984,6 +985,15 @@ weston_compositor_add_button_binding(struct 
weston_compositor *compositor,
 weston_button_binding_handler_t binding,
 void *data);
 
+typedef void (*weston_touch_binding_handler_t)(struct weston_seat *seat,
+  uint32_t time,
+  void *data);
+struct weston_binding *
+weston_compositor_add_touch_binding(struct weston_compositor *compositor,
+   enum weston_keyboard_modifier modifier,
+   weston_touch_binding_handler_t binding,
+   void *data);
+
 typedef void (*weston_axis_binding_handler_t)(struct weston_seat *seat,
  uint32_t time, uint32_t axis,
  wl_fixed_t value, void *data);
@@ -1014,6 +1024,10 @@ weston_compositor_run_button_binding(struct 
weston_compositor *compositor,
 struct weston_seat *seat, uint32_t time,

Re: [RFC DRAFT] graphics tablet protocol extension

2013-10-03 Thread David Herrmann 
Hi Peter

On Wed, Oct 2, 2013 at 11:13 PM, Peter Hutterer
 wrote:
> On Wed, Oct 02, 2013 at 05:44:29PM +0200, David Herrmann wrote:
>> Hi Peter
>>
>> On Fri, Sep 20, 2013 at 12:35 PM, Peter Hutterer
>> > diff --git a/protocol/wayland.xml b/protocol/wayland.xml
>> > index aeb0412..8d10746 100644
>> > --- a/protocol/wayland.xml
>> > +++ b/protocol/wayland.xml
>> > @@ -1235,7 +1235,7 @@
>> >  
>> > 
>> >
>> > -  
>> > +  
>> >  
>> >A seat is a group of keyboards, pointer and touch devices. This
>> >object is published as a global during start up, or when such a
>> > @@ -1251,6 +1251,7 @@
>> >
>> >
>> >
>> > +  
>>
>> What's actually the reason to allow multiple graphics-tablets per
>> seat? I thought wl_seat objects respresent a single user interacting
>> with your desktop. So if you have two tablets, why not force them to
>> be in two different wl_seat objects? Is there ever a reason to have
>> multiple tablets in a single seat? What would the use-case be?
>
> my laptop has a built-in wacom tablet (lenovo x220t), but I also have an
> Intuos4 plugged in. depending on the use-case I use either, but they should
> be in the same seat. two wl_seat objects means two different keyboard foci
> (only one of which actually works if you have only one keyboard), etc.
> I also know of professional setups that require two tablets or more.
>
> ideally there'd be just one generic wl_tablet per seat, same as wl_pointer
> but the tablets differ too much to make that useable. Hence the multiple
> wl_tablet objects.

Yepp, merging them might be not as easy as with keyboards/mice. Point taken.

>> We could even go further and put tablets into their own seats. Always.
>> A pointer and keyboard may be used by a single user at the same time.
>> But for a graphics-tablet that doesn't sound like a legitimate
>> use-case, does it? But maybe I just have a different view of wl_seat..
>> don't know. I somehow have the feeling we never really agreed on how
>> to define wl_seat objects. Currently they are just user-defined groups
>> of devices with some specific policies ("only one keyboard-object per
>> seat").
>
> my understanding of wl_seat is "one group of input devices". that would
> usually map to one user. it's already not ideal for the bimanual input but
> then again that's even more of a corner case than multiple seats.
>
> once you start moving devices out into other seats, you're in trouble. a
> seat defines keyboard events, so anything that has an interaction with the
> keyboard can't easily be unpaired. a tablet is a fancy pointer device,
> users expect to click somewhere and have it work as a mouse, i.e.
> to move the keyboard focus to wherever you just clicked.
> moving it into a different seat means you'd have to switch to a mouse to
> change the keyboard focus. or, if you have two wl_seats you now need to pair
> them somehow to have the right focus behaviour. and that is going to be
> horrible.

Ok, so wl_seat is just about input focus. I had a much stricter view
of it but obviously it makes it hard to control focus of seats without
mice/keyboards. So yeah, agreed.

>> >  
>> >
>> >  
>> > @@ -1306,6 +1307,19 @@
>> >
>> >  
>> >
>> > +
>> > +
>> > +  
>> > +The ID provided will be initialized to the wl_tablet_manager
>> > +interface for this seat. This can then be used to retrieve the
>> > +objects representing the actual tablet devices.
>> > +
>> > +This request only takes effect if the seat has the tablets
>> > +capability.
>> > +  
>> > +  
>> > +
>> > +
>> >
>> >
>> >
>> > @@ -1617,6 +1631,223 @@
>> >  
>> >
>> >
>> > +  
>> > +
>> > +  A tablet manager object provides requests to access the graphics
>> > +  tablets available on this system.
>> > +
>> > +
>> > +
>> > +  
>> > +Describes the type of tablet.
>> > +  
>> > +  
>> > +  
>> > +  
>> > +
>> > +
>> > +
>> > +  
>> > +  
>> > +  
>> > +  
>> > +  
>> > +  
>>
>> So tablets are server-side created objects? I think we tried to avoid
>> that. Only wl_display uses this now, afaik. Even for globals we added
>> the wl_registry interface which just announces unique names which the
>> client then binds to via wl_registry.bind. So why not turn
>> wl_tablet_manager into wl_tablet_registry and provide the same
>> functions as the global registry?
>
> two things:
> having thought about this (and talked to krh and daniels at XDC) the tablet
> manager shouldn't be necessary anymore. It used to have the device_removed
> event, but now it's just an intermediate layer that can be removed by moving
> the device_added event up into the seat and sending it conditional on either
> get_tablets or on binding to the seat with the correct version.

That sounds much better. I like the approach with advertising tablets
on the seat via "tabled_added" even