Re: Input and games.

[David Herrmann]

Hi Todd

On Tue, Apr 23, 2013 at 4:12 PM, Todd Showalter  wrote:
> On Tue, Apr 23, 2013 at 7:25 AM, Pekka Paalanen  wrote:
>
>> what you describe here is very much a keymap-like database for game
>> controllers: translating from button and axis indices to labels or
>> symbols. However, having a brief chat with Daniel Stone, it seems we
>> should not need these.
>>
>> Take a look at /usr/include/linux/input.h
>>
>> There you find definitions for BTN_A, BTN_X, BTN_START, ABS_X, ABS_Y,
>> ABS_RX, ABS_RY, ABS_HATnn, and many more. The kernel evdev interface
>> should alreay be giving out events with the correct label, so we would
>> not need any mapping.
>>
>> Are you saying that the kernel gives out the labels wrong? If so, this
>> should be fixed in the kernel drivers. One thing less to care about in
>> Wayland. We "just" need to write the protocol for these devices, the
>> labels should be already there.
>
> I'm not saying the labels are wrong; I assume they are correct.
> The problem is that the labels are hardware-specific, at least for the
> buttons.  That said, it looks like the axis values are being properly
> labelled, which means we're way closer to sane behaviour than we were
> last time I looked into this.
>
> I grabbed evtest and ran it with three devices; an xbox
> controller, an xbox 360 controller, and a ps3 controller.  The
> results:
>
> xbox:
> - button
>A B X Y START THUMBL THUMBR
>Z (white button)
>C (black button)
>SELECT (back button)
> - axis
>ABS_X ABS_Y ABS_Z
>ABS_RX ABS_RY ABS_RZ
>ABS_HAT0X ABS_HAT0Y (dpad)
>
> xbox 360:
> - button
>A B X Y START THUMBL THUMBR
>TL  TR
>MODE (home button)
>SELECT (back button)
> - axis
>ABS_X ABS_Y ABS_Z
>ABS_RX ABS_RY ABS_RZ
>ABS_HAT0X ABS_HAT0Y (dpad)
>
> ps3:
>   - button
> TRIGGER  THUMB  THUMB2
> TOP TOP2 PINKIE BASE  BASE2
> BASE3  BASE3  BASE4  BASE5
> BASE6  DEAD  TRIGGER_HAPPY17
> TRIGGER_HAPPY18  TRIGGER_HAPPY19
>   - axis
> ABS_X  ABS_Y  ABS_Z  ABS_RZ  ABS_MISC
>
> The xbox controller and the xbox 360 controller are more or less
> the same; the 360 controller has a couple of shoulder buttons instead
> of a the black and white buttons, and (somewhat oddly) the "back"
> buttons come in as "select", but that's workable.
>
> It all rather goes pear-shaped when we get beyond that, though.
> The PS3 controller, while physically quite similar to the other two,
> even down to the placement of controls and how the controls are
> clustered, comes in completely differently.  There is not a single
> button in common between the PS3 controller and the XBox controllers
> as reported by evdev, despite the PS3 controller having buttons
> physically labelled "start" and "select", plus direct equivalents to
> many of the XBox 360 controller's parts (ie: TL, TR, MODE, ABS_HAT0X,
> ABS_HAT0Y, ABS_RX, ABS_RY...).

That's a known problem that isn't easy to fix. Of course, we can
adjust the kernel driver, but this breaks applications that expect the
current behavior. The problem I see is that we never paid enough
attention how keys are mapped when adding kernel drivers and now we
have a mess of different mappings that cannot be fixed. You can try to
send patches to linux-in...@vger.kernel.org, but chances are low that
they will get merged.

Nevertheless, the problem is actually easy to fix in userspace. You
just need to create buttons mappings for the different devices. There
is no complex logic involved. It would be enough to have a bunch of
static tables indexed by input-device names which map the input
keycode to the correct/expected output keycode.

But I cannot see a reason why a compositor should do this, though.
This can be easily put into a library and every game that needs it
performs the mappings. Table-mappings add a single memory-read which
shouldn't affect performance and clients can share the library.
The compositor isn't interested in joystick/gamepad events so my first
approach would be to let clients handle them.

> The PS3 controller also has several "(?)" entries for buttons and
> axis values, and also appears to have (if I understand correctly) a
> bunch of codes for a multitouch panel?  I couldn't tell you what the
> right or left stick axis values are in the above, because though I did
> build my kernel with ps3 controller support, and evtest did see it and
> dump the supported event list, I get no events logged from... ah, ok,
> I have to hit the PS button to get it to actually work.  And now
> there's a torrent of what I assume is accelerometer data coming in on
> "(?)" events.
>
> It turns out the left stick is ABS_X and ABS_Y, and right stick is
> ABS_Z and ABS_RZ.  I suspect this is just broken somehow.  Maybe the
> ps3 gamepad kernel driver is still a work in progress?  But this is
> the kind of thing I was talking about; the data I get from a ps3
> gamepad is ma

Re: [PATCH 2/3] Add a 'serial' property on weston_output

[Richard Hughes]

On 23 April 2013 16:37, Rob Bradford  wrote:
> When I read the commit message I wondered "why does he need a serial"
> for the wl_output. I was of course thinking about the wayland use of
> "serial" as a sequence number.

Ooops, my bad.

> Are you intending to expose this through the wayland protocol? If so
> have you considered how this ambiguity might be avoided.

"serial_number"?

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

Re: [PATCH 3/3] Parse the EDID when outputs are added

[Richard Hughes]

On 23 Apr 2013 16:36, "Rob Bradford"  wrote:
> Please can you clarify what I think this statement implies. That is that
> you are certifying that you have the rights to license this code under
> the MIT license as carried by Weston.

Correct, i.e. I read the VESA EDID specification document. :)
Richard.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Pointer lock and warping

[Bill Spitzak]

On 04/23/2013 12:11 AM, Pekka Paalanen wrote:


Here's a lot simpler solution for non-jittery dragging of objects: just
hide the pointer cursor, when starting the move. If you still want the
pointer cursor visible, draw it yourself with the object you are
moving. That is already possible today, and sub-surfaces will make that
even simpler to implement in the future.


How do you make the cursor not blink when switching between the real and 
fake one?


And I don't see how this helps Todd's request for the "slow scrollbar". 
The pointer has to end up at the warped position, it cannot jump from 
where the user sees it to where it really is.




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

Re: [PATCH 2/3] Add a 'serial' property on weston_output

[Rob Bradford]

On Mon, Apr 22, 2013 at 12:57:03PM +0100, Richard Hughes wrote:
> ---
>  src/compositor-drm.c | 1 +
>  src/compositor.h | 2 +-
>  2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> index 61ef97e..a454676 100644
> --- a/src/compositor-drm.c
> +++ b/src/compositor-drm.c
> @@ -1522,6 +1522,7 @@ create_output_for_connector(struct drm_compositor *ec,
>   output->base.subpixel = drm_subpixel_to_wayland(connector->subpixel);
>   output->base.make = "unknown";
>   output->base.model = "unknown";
> + output->base.serial = "unknown";
>   wl_list_init(&output->base.mode_list);
>
>   if (connector->connector_type < ARRAY_LENGTH(connector_type_names))
> diff --git a/src/compositor.h b/src/compositor.h
> index 1e999a6..fa6162c 100644
> --- a/src/compositor.h
> +++ b/src/compositor.h
> @@ -178,7 +178,7 @@ struct weston_output {
>   uint32_t frame_time;
>   int disable_planes;
>
> - char *make, *model;
> + char *make, *model, *serial;
>   uint32_t subpixel;
>   uint32_t transform;

Hi Richard,

When I read the commit message I wondered "why does he need a serial"
for the wl_output. I was of course thinking about the wayland use of
"serial" as a sequence number.

Are you intending to expose this through the wayland protocol? If so
have you considered how this ambiguity might be avoided.

Cheers,

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

Re: [PATCH 3/3] Parse the EDID when outputs are added

[Rob Bradford]

On Mon, Apr 22, 2013 at 12:57:04PM +0100, Richard Hughes wrote:
> At the moment we're only extracting interesting strings. We have to be quite
> careful parsing the EDID data, as vendors like to do insane things.
> 
> The original EDID parsing code was written by me for gnome-color-manager.

Hi Richard, 

Please can you clarify what I think this statement implies. That is that
you are certifying that you have the rights to license this code under
the MIT license as carried by Weston.

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

Re: [PATCH weston 2/6] weston: Allow relative paths for modules

[John Kåre Alsaker]

You should drop the code changes since they already allow relative paths.
You just changed it to only allow base filenames.


On Tue, Apr 23, 2013 at 2:54 PM, Quentin Glidic <
sardemff7+wayl...@sardemff7.net> wrote:

> From: Quentin Glidic 
>
> Signed-off-by: Quentin Glidic 
> ---
>  man/weston.man   | 4 ++--
>  src/compositor.c | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/man/weston.man b/man/weston.man
> index a25e619..97db3c8 100644
> --- a/man/weston.man
> +++ b/man/weston.man
> @@ -102,7 +102,7 @@ Load
>  .I backend.so
>  instead of the default backend. The file is searched for in
>  .IR "__weston_modules_dir__" ,
> -or you can pass an absolute path. The default backend is
> +or you can pass a path. The default backend is
>  .I __weston_native_backend__
>  unless the environment suggests otherwise, see
>  .IR DISPLAY " and " WAYLAND_DISPLAY .
> @@ -131,7 +131,7 @@ instead of writing them to stderr.
>  Load the comma-separated list of modules. Only used by the test
>  suite. The file is searched for in
>  .IR "__weston_modules_dir__" ,
> -or you can pass an absolute path.
> +or you can pass a path.
>  .TP
>  \fB\-\^S\fR\fIname\fR, \fB\-\-socket\fR=\fIname\fR
>  Weston will listen in the Wayland socket called
> diff --git a/src/compositor.c b/src/compositor.c
> index 693df2c..fe51061 100644
> --- a/src/compositor.c
> +++ b/src/compositor.c
> @@ -3349,7 +3349,7 @@ load_module(const char *name, const char *entrypoint)
> char path[PATH_MAX];
> void *module, *init;
>
> -   if (name[0] != '/')
> +   if (!strchr(name, '/'))
> snprintf(path, sizeof path, "%s/%s", MODULEDIR, name);
> else
> snprintf(path, sizeof path, "%s", name);
> --
> 1.8.2.1
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 2/6] weston: Allow relative paths for modules

[Bill Spitzak]

On 04/23/2013 05:54 AM, Quentin Glidic wrote:

From: Quentin Glidic 



-   if (name[0] != '/')
+   if (!strchr(name, '/'))
snprintf(path, sizeof path, "%s/%s", MODULEDIR, name);
else
snprintf(path, sizeof path, "%s", name);


This disallows any subdirectories in MODULEDIR. Is this ok?

An alternative would be to use the name unchanged if it starts with 
either '/' or '.' so the user can type "./foo" to get a file in the 
current directory.


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

Re: [PATCH weston 1/6] shared/option-parser: Allow spaced options

[Bill Spitzak]

On 04/23/2013 05:54 AM, Quentin Glidic wrote:


+You can specify short options having an argument with a following space. Long
+options with argument can be specified either with or without an equal sign.



-static void
+static bool
  handle_option(const struct weston_option *option, char *value)
  {


This can be called with NULL from the code below (if the option is last 
on in argv with no argument after it).



@@ -62,14 +63,20 @@ parse_options(const struct weston_option *options,
if (options[k].name &&
argv[i][0] == '-' &&
argv[i][1] == '-' &&
-   strncmp(options[k].name, &argv[i][2], len) == 0 &&
-   (argv[i][len + 2] == '=' || argv[i][len + 2] == 
'\0')) {
-   handle_option(&options[k], &argv[i][len + 3]);
+   strncmp(options[k].name, &argv[i][2], len) == 0) {
+
+   if (argv[i][len + 2] == '=')
+   handle_option(&options[k], &argv[i][len 
+ 3]);


You need to check if argv[i][len + 2] == 0, if not then the option did 
not match.



+   else if (handle_option(&options[k], argv[i+1]))
+   ++i;
break;
} else if (options[k].short_name &&
   argv[i][0] == '-' &&
   options[k].short_name == argv[i][1]) {
-   handle_option(&options[k], &argv[i][2]);
+   if (argv[i][2] != '\0')
+   handle_option(&options[k], &argv[i][2]);


If this returns false then it should continue parsing the next letter as 
another single-letter option.



+   else if (handle_option(&options[k], argv[i+1]))


I think you should also make '=' work (ie "-x=12").

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

Re: Input and games.

[Todd Showalter]

On Tue, Apr 23, 2013 at 7:25 AM, Pekka Paalanen  wrote:

> what you describe here is very much a keymap-like database for game
> controllers: translating from button and axis indices to labels or
> symbols. However, having a brief chat with Daniel Stone, it seems we
> should not need these.
>
> Take a look at /usr/include/linux/input.h
>
> There you find definitions for BTN_A, BTN_X, BTN_START, ABS_X, ABS_Y,
> ABS_RX, ABS_RY, ABS_HATnn, and many more. The kernel evdev interface
> should alreay be giving out events with the correct label, so we would
> not need any mapping.
>
> Are you saying that the kernel gives out the labels wrong? If so, this
> should be fixed in the kernel drivers. One thing less to care about in
> Wayland. We "just" need to write the protocol for these devices, the
> labels should be already there.

I'm not saying the labels are wrong; I assume they are correct.
The problem is that the labels are hardware-specific, at least for the
buttons.  That said, it looks like the axis values are being properly
labelled, which means we're way closer to sane behaviour than we were
last time I looked into this.

I grabbed evtest and ran it with three devices; an xbox
controller, an xbox 360 controller, and a ps3 controller.  The
results:

xbox:
- button
   A B X Y START THUMBL THUMBR
   Z (white button)
   C (black button)
   SELECT (back button)
- axis
   ABS_X ABS_Y ABS_Z
   ABS_RX ABS_RY ABS_RZ
   ABS_HAT0X ABS_HAT0Y (dpad)

xbox 360:
- button
   A B X Y START THUMBL THUMBR
   TL  TR
   MODE (home button)
   SELECT (back button)
- axis
   ABS_X ABS_Y ABS_Z
   ABS_RX ABS_RY ABS_RZ
   ABS_HAT0X ABS_HAT0Y (dpad)

ps3:
  - button
TRIGGER  THUMB  THUMB2
TOP TOP2 PINKIE BASE  BASE2
BASE3  BASE3  BASE4  BASE5
BASE6  DEAD  TRIGGER_HAPPY17
TRIGGER_HAPPY18  TRIGGER_HAPPY19
  - axis
ABS_X  ABS_Y  ABS_Z  ABS_RZ  ABS_MISC

The xbox controller and the xbox 360 controller are more or less
the same; the 360 controller has a couple of shoulder buttons instead
of a the black and white buttons, and (somewhat oddly) the "back"
buttons come in as "select", but that's workable.

It all rather goes pear-shaped when we get beyond that, though.
The PS3 controller, while physically quite similar to the other two,
even down to the placement of controls and how the controls are
clustered, comes in completely differently.  There is not a single
button in common between the PS3 controller and the XBox controllers
as reported by evdev, despite the PS3 controller having buttons
physically labelled "start" and "select", plus direct equivalents to
many of the XBox 360 controller's parts (ie: TL, TR, MODE, ABS_HAT0X,
ABS_HAT0Y, ABS_RX, ABS_RY...).

The PS3 controller also has several "(?)" entries for buttons and
axis values, and also appears to have (if I understand correctly) a
bunch of codes for a multitouch panel?  I couldn't tell you what the
right or left stick axis values are in the above, because though I did
build my kernel with ps3 controller support, and evtest did see it and
dump the supported event list, I get no events logged from... ah, ok,
I have to hit the PS button to get it to actually work.  And now
there's a torrent of what I assume is accelerometer data coming in on
"(?)" events.

It turns out the left stick is ABS_X and ABS_Y, and right stick is
ABS_Z and ABS_RZ.  I suspect this is just broken somehow.  Maybe the
ps3 gamepad kernel driver is still a work in progress?  But this is
the kind of thing I was talking about; the data I get from a ps3
gamepad is mapped totally differently from the data I get from an xbox
gamepad, so from a game point of view, even if all I want is a
joystick, a jump button and a shoot button, I still have to care what
particular kind of gamepad the player has plugged in because I'm going
to get completely different button messages depending on what kind of
pad is plugged in.

> The current behaviour can be checked with evtest:
> http://cgit.freedesktop.org/evtest/
> Was that what you used to check the controller events?

   Previously, I'd been dumping data from the libjsw interface, and
then dumping data by going directly through evdev.  This time I used
evtest.

   Todd.

--
 Todd Showalter, President,
 Electron Jump Games, Inc.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] compositor: add a layer clipping mechanism

[Pekka Paalanen]

On Tue, 23 Apr 2013 15:01:18 +0200
Giulio Camuffo  wrote:

> 2013/4/23 Pekka Paalanen 
> 
> > On Mon,  8 Apr 2013 14:31:53 +0200
> > Giulio Camuffo  wrote:
> >
> > > this adds a mechanism to clip the surfaces belonging to a layer
> > > to an arbitrary rect
> >
> > Hi Giulio,
> >
> > I don't have anything against the idea of clipping layers, but the
> > implementation below is puzzling.
> >
> > > ---
> > >
> > > I'm using this functionality in my shell plugin
> > > (https://github.com/giucam/orbital/tree/workspaces) to implement
> > workspaces.
> > > See http://www.youtube.com/watch?v=_o-sKdyUPO8 for a screencast.
> > > As you see there i need to be able to show all the windows of all the
> > > workspaces, but clipped to their workspace, so they don't stick out over
> > > neighbour ones. So simply showing/hiding layers does not work.
> > >
> > >  src/compositor.c | 15 +++
> > >  src/compositor.h |  8 
> > >  2 files changed, 23 insertions(+)
> > >
> > > diff --git a/src/compositor.c b/src/compositor.c
> > > index 3645b04..a748894 100644
> > > --- a/src/compositor.c
> > > +++ b/src/compositor.c
> > > @@ -1159,6 +1159,7 @@ surface_accumulate_damage(struct weston_surface
> > *surface,
> > >   pixman_region32_union(&surface->plane->damage,
> > > &surface->plane->damage, &surface->damage);
> > >   empty_region(&surface->damage);
> > > + pixman_region32_subtract(opaque, &surface->transform.boundingbox,
> > &surface->layer->clip);
> >
> > So, you subtract layer.clip from the surface bounding box to produce
> > 'opaque'. Hmm... I don't really understand the set operations here. It
> > seems somehow inverted. What does layer.clip mean, is it the region
> > that is inside or outside of the paintable region?
> >
> > If layer.clip is the outside, i.e. the region to be clipped away, isn't
> > weston_layer_clip() then incapable of clipping from more than one side?
> >
> > Doesn't this subtracting into 'opaque' clobber the state that is being
> > accumulated into it over several calls to surface_accumulate_damage()?
> > 'opaque' is supposed to accumulate the opaque regions when walking the
> > surface stack from top to bottom, so we can skip painting surface
> > regions that are already hidden by opaque regions above. Simple
> > assignment to it is strange.
> >
> > Could you explain these operations, since to me they look just wrong?
> >
> 
> I don't fully understand how the repaint is done, and what e.g. the opaque
> region there is, so i may well have done some stupid mistake.
> layer->clip is a region outside of which any layer surface should be
> clipped, so it renders only what is inside that region. Maybe 'clip' isn't
> the right name, and e.g. 'visible' would be better.
> 

The name 'clip' is fine, I was just confused by the code there, where
it seemed to be used somehow inverted, but it was actually used doubly
inverted. No, wait... weston_surface::clip is the opposite, isn't it?
Ok, so the name needs to be changed, otherwise it's confusing. How about
'mask'?

The 'opaque' region in surface_accumulate_damage() is initialised
outside of the function to be initially empty. Then the function is
called for each surface in z-order, from top to bottom. First, the
previous 'opaque' is subtracted from the surface damage, so we do not
repaint it. Then, this surface's opaque region is added to 'opaque' for
the next call, so that what will be under the opaque regions of this
surface, will not be repainted of the below surfaces. I suspect you
broke this optimization. Maybe the repaint debug mode could visualize
it for you.

Btw. I guess you are relying on a grab to avoid picking surfaces from
their clipped areas? That is, you are not calling the pick functions
while layer clipping is in effect? Otherwise you need to fix the input
side, too.


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

Re: [PATCH weston] compositor: add a layer clipping mechanism

[Giulio Camuffo]

2013/4/23 Pekka Paalanen 

> On Mon,  8 Apr 2013 14:31:53 +0200
> Giulio Camuffo  wrote:
>
> > this adds a mechanism to clip the surfaces belonging to a layer
> > to an arbitrary rect
>
> Hi Giulio,
>
> I don't have anything against the idea of clipping layers, but the
> implementation below is puzzling.
>
> > ---
> >
> > I'm using this functionality in my shell plugin
> > (https://github.com/giucam/orbital/tree/workspaces) to implement
> workspaces.
> > See http://www.youtube.com/watch?v=_o-sKdyUPO8 for a screencast.
> > As you see there i need to be able to show all the windows of all the
> > workspaces, but clipped to their workspace, so they don't stick out over
> > neighbour ones. So simply showing/hiding layers does not work.
> >
> >  src/compositor.c | 15 +++
> >  src/compositor.h |  8 
> >  2 files changed, 23 insertions(+)
> >
> > diff --git a/src/compositor.c b/src/compositor.c
> > index 3645b04..a748894 100644
> > --- a/src/compositor.c
> > +++ b/src/compositor.c
> > @@ -1159,6 +1159,7 @@ surface_accumulate_damage(struct weston_surface
> *surface,
> >   pixman_region32_union(&surface->plane->damage,
> > &surface->plane->damage, &surface->damage);
> >   empty_region(&surface->damage);
> > + pixman_region32_subtract(opaque, &surface->transform.boundingbox,
> &surface->layer->clip);
>
> So, you subtract layer.clip from the surface bounding box to produce
> 'opaque'. Hmm... I don't really understand the set operations here. It
> seems somehow inverted. What does layer.clip mean, is it the region
> that is inside or outside of the paintable region?
>
> If layer.clip is the outside, i.e. the region to be clipped away, isn't
> weston_layer_clip() then incapable of clipping from more than one side?
>
> Doesn't this subtracting into 'opaque' clobber the state that is being
> accumulated into it over several calls to surface_accumulate_damage()?
> 'opaque' is supposed to accumulate the opaque regions when walking the
> surface stack from top to bottom, so we can skip painting surface
> regions that are already hidden by opaque regions above. Simple
> assignment to it is strange.
>
> Could you explain these operations, since to me they look just wrong?
>

I don't fully understand how the repaint is done, and what e.g. the opaque
region there is, so i may well have done some stupid mistake.
layer->clip is a region outside of which any layer surface should be
clipped, so it renders only what is inside that region. Maybe 'clip' isn't
the right name, and e.g. 'visible' would be better.


>
> >   pixman_region32_copy(&surface->clip, opaque);
> >   pixman_region32_union(opaque, opaque, &surface->transform.opaque);
> >  }
> > @@ -1223,6 +1224,7 @@ weston_output_repaint(struct weston_output
> *output, uint32_t msecs)
> >   wl_list_for_each(layer, &ec->layer_list, link) {
> >   wl_list_for_each(es, &layer->surface_list, layer_link) {
> >   weston_surface_update_transform(es);
> > + es->layer = layer;
> >   wl_list_insert(ec->surface_list.prev, &es->link);
> >   if (es->output == output) {
> >   wl_list_insert_list(&frame_callback_list,
> > @@ -1319,11 +1321,24 @@ WL_EXPORT void
> >  weston_layer_init(struct weston_layer *layer, struct wl_list *below)
> >  {
> >   wl_list_init(&layer->surface_list);
> > + region_init_infinite(&layer->clip);
> >   if (below != NULL)
> >   wl_list_insert(below, &layer->link);
> >  }
> >
> >  WL_EXPORT void
> > +weston_layer_clip(struct weston_layer *layer, int x, int y, int width,
> int height)
> > +{
> > + pixman_region32_init_rect(&layer->clip, x, y, width, height);
> > +}
> > +
> > +WL_EXPORT void
> > +weston_layer_clip_infinite(struct weston_layer *layer)
> > +{
> > +region_init_infinite(&layer->clip);
> > +}
> > +
> > +WL_EXPORT void
> >  weston_output_schedule_repaint(struct weston_output *output)
> >  {
> >   struct weston_compositor *compositor = output->compositor;
> > diff --git a/src/compositor.h b/src/compositor.h
> > index 1e999a6..b3038bd 100644
> > --- a/src/compositor.h
> > +++ b/src/compositor.h
> > @@ -271,6 +271,7 @@ enum {
> >  struct weston_layer {
> >   struct wl_list surface_list;
> >   struct wl_list link;
> > + pixman_region32_t clip;
> >  };
> >
> >  struct weston_plane {
> > @@ -413,6 +414,7 @@ struct weston_surface {
> >   struct wl_list layer_link;
> >   float alpha; /* part of geometry, see below */
> >   struct weston_plane *plane;
> > + struct weston_layer *layer;
>
> I think we should have some comment or grouping here to indicate, that
> 'layer' is only valid during repaint.
>

Right.


>
> >
> >   void *renderer_state;
> >
> > @@ -598,6 +600,12 @@ void
> >  weston_layer_init(struct weston_layer *layer, struct wl_list *below);
> >
> >  void
> > +weston_layer_clip(struct weston

[PATCH weston 6/6] headless-backend: Init fake pointer and keyboard

[Quentin Glidic]

From: "U. Artie Eoff" 

Signed-off-by: Quentin Glidic 
---
 src/compositor-headless.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/compositor-headless.c b/src/compositor-headless.c
index 4720329..507d4bf 100644
--- a/src/compositor-headless.c
+++ b/src/compositor-headless.c
@@ -173,6 +173,8 @@ headless_compositor_create(struct wl_display *display,
goto err_free;
 
weston_seat_init(&c->fake_seat, &c->base);
+   weston_seat_init_pointer(&c->fake_seat);
+   weston_seat_init_keyboard(&c->fake_seat, NULL);
 
c->base.destroy = headless_destroy;
c->base.restore = headless_restore;
-- 
1.8.2.1

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

[PATCH weston 5/6] tests: Drop weston-tests-env

[Quentin Glidic]

From: Quentin Glidic 

Signed-off-by: Quentin Glidic 
---
 tests/.gitignore   | 10 +++--
 tests/Makefile.am  | 56 --
 tests/weston-tests-env | 39 ---
 3 files changed, 44 insertions(+), 61 deletions(-)
 delete mode 100755 tests/weston-tests-env

diff --git a/tests/.gitignore b/tests/.gitignore
index 05bc024..fe61189 100644
--- a/tests/.gitignore
+++ b/tests/.gitignore
@@ -1,13 +1,9 @@
-logs
-matrix-test
+*.test
+*.log
+*.trs
 setbacklight
 test-client
 test-text-client
 wayland-test-client-protocol.h
 wayland-test-protocol.c
 wayland-test-server-protocol.h
-text-test
-keyboard-test
-event-test
-button-test
-xwayland-test
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 2729545..453c567 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -1,36 +1,62 @@
 TESTS = $(module_tests) $(weston_tests)
 
+# Keep them in sync
 module_tests = \
+   .libs/surface-test.so   \
+   .libs/surface-global-test.so
+
+module_tests_la = \
surface-test.la \
surface-global-test.la
 
 weston_tests = \
-   keyboard-test   \
-   event-test  \
-   button-test \
-   text-test   \
+   keyboard.test   \
+   event.test  \
+   button.test \
+   text.test   \
$(xwayland_test)
 
-AM_TESTS_ENVIRONMENT = \
-   abs_builddir='$(abs_builddir)'; export abs_builddir;
+TEST_WESTON  ?= $(top_builddir)/src/weston
 
-LOG_COMPILER = $(srcdir)/weston-tests-env
+ #ifneq ($(strip $(WAYLAND_DISPLAY)),)
+ ifdef WAYLAND_DISPLAY
+TEST_BACKEND ?= $(top_builddir)/src/.libs/wayland-backend.so
+ else ifneq ($(strip $(DISPLAY)),)
+TEST_BACKEND ?= $(top_builddir)/src/.libs/x11-backend.so
+ else
+TEST_BACKEND ?= $(top_builddir)/src/.libs/headless-backend.so
+ endif
 
-clean-local:
-   -rm -rf logs
+TEST_EXTENSIONS = .test .so
 
-# To remove when automake 1.11 support is dropped
-export abs_builddir
+LOG_COMPILER = $(TEST_WESTON)
+TEST_LOG_COMPILER = $(LOG_COMPILER)
+SO_LOG_COMPILER = $(LOG_COMPILER)
 
-noinst_LTLIBRARIES =   \
-   $(weston_test)
+AM_LOG_FLAGS = \
+   --modules xwayland.so \
+   --backend $(TEST_BACKEND) \
+   --socket test-socket-$(notdir $@)
+
+AM_TEST_LOG_FLAGS = \
+   $(AM_LOG_FLAGS) \
+   --modules .libs/weston-test.so
+
+# Keep --modules as the last arg, so it grabs the test module in
+AM_SO_LOG_FLAGS = \
+   $(AM_LOG_FLAGS) \
+   --modules
+
+clean-local:
+   -rm -rf logs
 
 noinst_PROGRAMS =  \
$(setbacklight) \
matrix-test
 
 check_LTLIBRARIES =\
-   $(module_tests)
+   $(module_tests_la)  \
+   $(weston_test)
 
 check_PROGRAMS =   \
$(weston_tests)
@@ -89,7 +115,7 @@ xwayland_test_SOURCES = xwayland-test.c  
$(weston_test_client_src)
 xwayland_test_LDADD = $(weston_test_client_libs) $(XWAYLAND_TEST_LIBS)
 
 if ENABLE_XWAYLAND_TEST
-xwayland_test = xwayland_test
+xwayland_test = xwayland.test
 endif
 
 matrix_test_SOURCES =  \
diff --git a/tests/weston-tests-env b/tests/weston-tests-env
deleted file mode 100755
index ed10d68..000
--- a/tests/weston-tests-env
+++ /dev/null
@@ -1,39 +0,0 @@
-#!/bin/bash
-
-WESTON=$abs_builddir/../src/weston
-LOGDIR=$abs_builddir/logs
-
-mkdir -p "$LOGDIR"
-
-SERVERLOG="$LOGDIR/$1-serverlog.txt"
-OUTLOG="$LOGDIR/$1-log.txt"
-
-rm -f "$SERVERLOG"
-
-if test x$WAYLAND_DISPLAY != x; then
-   BACKEND=$abs_builddir/../src/.libs/wayland-backend.so
-elif test x$DISPLAY != x; then
-   BACKEND=$abs_builddir/../src/.libs/x11-backend.so
-else
-   BACKEND=$abs_builddir/../src/.libs/wayland-backend.so
-fi
-
-case $1 in
-   *.la|*.so)
-   $WESTON --backend=$BACKEND \
-   --socket=test-$(basename $1) \
-   --modules=xwayland.so \
-   --modules=$abs_builddir/.libs/${1/.la/.so} \
-   --log="$SERVERLOG" \
-   &> "$OUTLOG"
-   ;;
-   *)
-   $WESTON \
-   --socket=test-$(basename $1) \
-   --backend=$BACKEND \
-   --log="$SERVERLOG" \
-   --modules=xwayland.so \
-   --modules=$abs_builddir/.libs/weston-test.so \
-   $abs_builddir/$1 \
-   &> "$OUTLOG"
-esac
-- 
1.8.2.1

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

[PATCH weston 4/6] shared/option-parser: Add string list options

[Quentin Glidic]

From: Quentin Glidic 

Signed-off-by: Quentin Glidic 
---
 man/weston.man |  6 +++---
 shared/config-parser.h |  1 +
 shared/option-parser.c | 13 +
 src/compositor.c   | 27 ---
 tests/weston-tests-env |  6 --
 5 files changed, 45 insertions(+), 8 deletions(-)

diff --git a/man/weston.man b/man/weston.man
index 97db3c8..1812be7 100644
--- a/man/weston.man
+++ b/man/weston.man
@@ -127,9 +127,9 @@ Append log messages to the file
 .I file.log
 instead of writing them to stderr.
 .TP
-\fB\-\-modules\fR=\fImodule1.so,module2.so\fR
-Load the comma-separated list of modules. Only used by the test
-suite. The file is searched for in
+\fB\-\-modules\fR=\fImodule.so\fR
+Load the modules (the option may be specified multiple times).
+Only used by the test suite. The file is searched for in
 .IR "__weston_modules_dir__" ,
 or you can pass a path.
 .TP
diff --git a/shared/config-parser.h b/shared/config-parser.h
index 1d0ee3f..37af064 100644
--- a/shared/config-parser.h
+++ b/shared/config-parser.h
@@ -59,6 +59,7 @@ enum weston_option_type {
WESTON_OPTION_INTEGER,
WESTON_OPTION_UNSIGNED_INTEGER,
WESTON_OPTION_STRING,
+   WESTON_OPTION_STRING_LIST,
WESTON_OPTION_BOOLEAN
 };
 
diff --git a/shared/option-parser.c b/shared/option-parser.c
index 023fe72..9e0a740 100644
--- a/shared/option-parser.c
+++ b/shared/option-parser.c
@@ -32,6 +32,8 @@
 static bool
 handle_option(const struct weston_option *option, char *value)
 {
+   char **string_list, **str;
+   int size = 0;
switch (option->type) {
case WESTON_OPTION_INTEGER:
* (int32_t *) option->data = strtol(value, NULL, 0);
@@ -42,6 +44,17 @@ handle_option(const struct weston_option *option, char 
*value)
case WESTON_OPTION_STRING:
* (char **) option->data = strdup(value);
return true;
+   case WESTON_OPTION_STRING_LIST:
+   string_list = * (char ***) option->data;
+   if (string_list != NULL) {
+   for (str = string_list; *str != NULL; ++str)
+   ++size;
+   }
+   string_list = realloc(string_list, (size+2) * sizeof(char *));
+   string_list[size] = strdup(value);
+   string_list[size+1] = NULL;
+   * (char ***) option->data = string_list;
+   return true;
case WESTON_OPTION_BOOLEAN:
* (int32_t *) option->data = 1;
return false;
diff --git a/src/compositor.c b/src/compositor.c
index fe51061..5296df2 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -3406,6 +3406,26 @@ load_modules(struct weston_compositor *ec, const char 
*modules,
return 0;
 }
 
+static int
+load_modules_strv(struct weston_compositor *ec, char **modules,
+ int *argc, char *argv[], const char *config_file)
+{
+   char **module;
+   int (*module_init)(struct weston_compositor *ec,
+  int *argc, char *argv[], const char *config_file);
+
+   if (modules == NULL)
+   return 0;
+
+   for (module = modules; *module != NULL; ++module) {
+   module_init = load_module(*module, "module_init");
+   if (module_init)
+   module_init(ec, argc, argv, config_file);
+   }
+
+   return 0;
+}
+
 static const char xdg_error_message[] =
"fatal: environment variable XDG_RUNTIME_DIR is not set.\n";
 
@@ -3525,7 +3545,8 @@ int main(int argc, char *argv[])
 int *argc, char *argv[], const char 
*config_file);
int i;
char *backend = NULL;
-   const char *modules = "desktop-shell.so", *option_modules = NULL;
+   const char *modules = "desktop-shell.so";
+   char **option_modules = NULL;
char *log = NULL;
int32_t idle_time = 300;
int32_t help = 0;
@@ -3546,7 +3567,7 @@ int main(int argc, char *argv[])
{ WESTON_OPTION_STRING, "backend", 'B', &backend },
{ WESTON_OPTION_STRING, "socket", 'S', &socket_name },
{ WESTON_OPTION_INTEGER, "idle-time", 'i', &idle_time },
-   { WESTON_OPTION_STRING, "modules", 0, &option_modules },
+   { WESTON_OPTION_STRING_LIST, "modules", 0, &option_modules },
{ WESTON_OPTION_STRING, "log", 0, &log },
{ WESTON_OPTION_BOOLEAN, "help", 'h', &help },
{ WESTON_OPTION_BOOLEAN, "version", 0, &version },
@@ -3619,7 +3640,7 @@ int main(int argc, char *argv[])
 
if (load_modules(ec, modules, &argc, argv, config_file) < 0)
goto out;
-   if (load_modules(ec, option_modules, &argc, argv, config_file) < 0)
+   if (load_modules_strv(ec, option_modules, &argc, argv, config_file) < 0)
goto out;
 
free(config_file);
diff --git a/tests/weston-tests-env b/tests/weston-tests-env
index 8

[PATCH weston 3/6] weston-test: Get the test client path from args

[Quentin Glidic]

From: Quentin Glidic 

Signed-off-by: Quentin Glidic 
---
 tests/weston-test.c| 18 --
 tests/weston-tests-env |  3 ++-
 2 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/tests/weston-test.c b/tests/weston-test.c
index 55c5da4..c19db3a 100644
--- a/tests/weston-test.c
+++ b/tests/weston-test.c
@@ -29,6 +29,7 @@
 #include "wayland-test-server-protocol.h"
 
 struct weston_test {
+   char *client;
struct weston_compositor *compositor;
struct weston_layer layer;
struct weston_process process;
@@ -202,19 +203,15 @@ idle_launch_client(void *data)
struct weston_test *test = data;
pid_t pid;
sigset_t allsigs;
-   char *path;
 
-   path = getenv("WESTON_TEST_CLIENT_PATH");
-   if (path == NULL)
-   exit(EXIT_FAILURE);
pid = fork();
if (pid == -1)
exit(EXIT_FAILURE);
if (pid == 0) {
sigfillset(&allsigs);
sigprocmask(SIG_UNBLOCK, &allsigs, NULL);
-   execl(path, path, NULL);
-   weston_log("compositor: executing '%s' failed: %m\n", path);
+   execl(test->client, test->client, NULL);
+   weston_log("compositor: executing '%s' failed: %m\n", 
test->client);
exit(EXIT_FAILURE);
}
 
@@ -229,6 +226,7 @@ module_init(struct weston_compositor *ec,
 {
struct weston_test *test;
struct wl_event_loop *loop;
+   int i;
 
test = malloc(sizeof *test);
if (test == NULL)
@@ -242,6 +240,14 @@ module_init(struct weston_compositor *ec,
  test, bind_test) == NULL)
return -1;
 
+   if (*argc < 2)
+   exit(EXIT_FAILURE);
+   test->client = strdup(argv[1]);
+   for (i = 1; i < *argc; ++i)
+   argv[i] = argv[i+1];
+   *argc = i-1;
+
+
loop = wl_display_get_event_loop(ec->wl_display);
wl_event_loop_add_idle(loop, idle_launch_client, test);
 
diff --git a/tests/weston-tests-env b/tests/weston-tests-env
index 2e5fa95..8ae0bcf 100755
--- a/tests/weston-tests-env
+++ b/tests/weston-tests-env
@@ -27,10 +27,11 @@ case $1 in
&> "$OUTLOG"
;;
*)
-   WESTON_TEST_CLIENT_PATH=$abs_builddir/$1 $WESTON \
+   $WESTON \
--socket=test-$(basename $1) \
--backend=$BACKEND \
--log="$SERVERLOG" \

--modules=$abs_builddir/.libs/weston-test.so,xwayland.so \
+   $abs_builddir/$1 \
&> "$OUTLOG"
 esac
-- 
1.8.2.1

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

[PATCH weston 1/6] shared/option-parser: Allow spaced options

[Quentin Glidic]

From: Quentin Glidic 

Signed-off-by: Quentin Glidic 
---
 man/weston.man |  3 +++
 shared/option-parser.c | 25 -
 2 files changed, 19 insertions(+), 9 deletions(-)

diff --git a/man/weston.man b/man/weston.man
index 39d854b..a25e619 100644
--- a/man/weston.man
+++ b/man/weston.man
@@ -92,6 +92,9 @@ and
 .\" ***
 .SH OPTIONS
 .
+You can specify short options having an argument with a following space. Long
+options with argument can be specified either with or without an equal sign.
+.
 .SS Weston core options:
 .TP
 \fB\-\^B\fR\fIbackend.so\fR, \fB\-\-backend\fR=\fIbackend.so\fR
diff --git a/shared/option-parser.c b/shared/option-parser.c
index a7e497f..023fe72 100644
--- a/shared/option-parser.c
+++ b/shared/option-parser.c
@@ -22,28 +22,29 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 
 #include "config-parser.h"
 
-static void
+static bool
 handle_option(const struct weston_option *option, char *value)
 {
switch (option->type) {
case WESTON_OPTION_INTEGER:
* (int32_t *) option->data = strtol(value, NULL, 0);
-   return;
+   return true;
case WESTON_OPTION_UNSIGNED_INTEGER:
* (uint32_t *) option->data = strtoul(value, NULL, 0);
-   return;
+   return true;
case WESTON_OPTION_STRING:
* (char **) option->data = strdup(value);
-   return;
+   return true;
case WESTON_OPTION_BOOLEAN:
* (int32_t *) option->data = 1;
-   return;
+   return false;
default:
assert(0);
}
@@ -62,14 +63,20 @@ parse_options(const struct weston_option *options,
if (options[k].name &&
argv[i][0] == '-' &&
argv[i][1] == '-' &&
-   strncmp(options[k].name, &argv[i][2], len) == 0 &&
-   (argv[i][len + 2] == '=' || argv[i][len + 2] == 
'\0')) {
-   handle_option(&options[k], &argv[i][len + 3]);
+   strncmp(options[k].name, &argv[i][2], len) == 0) {
+
+   if (argv[i][len + 2] == '=')
+   handle_option(&options[k], &argv[i][len 
+ 3]);
+   else if (handle_option(&options[k], argv[i+1]))
+   ++i;
break;
} else if (options[k].short_name &&
   argv[i][0] == '-' &&
   options[k].short_name == argv[i][1]) {
-   handle_option(&options[k], &argv[i][2]);
+   if (argv[i][2] != '\0')
+   handle_option(&options[k], &argv[i][2]);
+   else if (handle_option(&options[k], argv[i+1]))
+   ++i;
break;
}
}
-- 
1.8.2.1

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

[PATCH weston 2/6] weston: Allow relative paths for modules

[Quentin Glidic]

From: Quentin Glidic 

Signed-off-by: Quentin Glidic 
---
 man/weston.man   | 4 ++--
 src/compositor.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/man/weston.man b/man/weston.man
index a25e619..97db3c8 100644
--- a/man/weston.man
+++ b/man/weston.man
@@ -102,7 +102,7 @@ Load
 .I backend.so
 instead of the default backend. The file is searched for in
 .IR "__weston_modules_dir__" ,
-or you can pass an absolute path. The default backend is 
+or you can pass a path. The default backend is
 .I __weston_native_backend__
 unless the environment suggests otherwise, see
 .IR DISPLAY " and " WAYLAND_DISPLAY .
@@ -131,7 +131,7 @@ instead of writing them to stderr.
 Load the comma-separated list of modules. Only used by the test
 suite. The file is searched for in
 .IR "__weston_modules_dir__" ,
-or you can pass an absolute path.
+or you can pass a path.
 .TP
 \fB\-\^S\fR\fIname\fR, \fB\-\-socket\fR=\fIname\fR
 Weston will listen in the Wayland socket called
diff --git a/src/compositor.c b/src/compositor.c
index 693df2c..fe51061 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -3349,7 +3349,7 @@ load_module(const char *name, const char *entrypoint)
char path[PATH_MAX];
void *module, *init;
 
-   if (name[0] != '/')
+   if (!strchr(name, '/'))
snprintf(path, sizeof path, "%s/%s", MODULEDIR, name);
else
snprintf(path, sizeof path, "%s", name);
-- 
1.8.2.1

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

Re: [PATCH weston] compositor: add a layer clipping mechanism

[Pekka Paalanen]

On Mon,  8 Apr 2013 14:31:53 +0200
Giulio Camuffo  wrote:

> this adds a mechanism to clip the surfaces belonging to a layer
> to an arbitrary rect

Hi Giulio,

I don't have anything against the idea of clipping layers, but the
implementation below is puzzling.

> ---
> 
> I'm using this functionality in my shell plugin 
> (https://github.com/giucam/orbital/tree/workspaces) to implement workspaces.
> See http://www.youtube.com/watch?v=_o-sKdyUPO8 for a screencast.
> As you see there i need to be able to show all the windows of all the
> workspaces, but clipped to their workspace, so they don't stick out over
> neighbour ones. So simply showing/hiding layers does not work.
> 
>  src/compositor.c | 15 +++
>  src/compositor.h |  8 
>  2 files changed, 23 insertions(+)
> 
> diff --git a/src/compositor.c b/src/compositor.c
> index 3645b04..a748894 100644
> --- a/src/compositor.c
> +++ b/src/compositor.c
> @@ -1159,6 +1159,7 @@ surface_accumulate_damage(struct weston_surface 
> *surface,
>   pixman_region32_union(&surface->plane->damage,
> &surface->plane->damage, &surface->damage);
>   empty_region(&surface->damage);
> + pixman_region32_subtract(opaque, &surface->transform.boundingbox, 
> &surface->layer->clip);

So, you subtract layer.clip from the surface bounding box to produce
'opaque'. Hmm... I don't really understand the set operations here. It
seems somehow inverted. What does layer.clip mean, is it the region
that is inside or outside of the paintable region?

If layer.clip is the outside, i.e. the region to be clipped away, isn't
weston_layer_clip() then incapable of clipping from more than one side?

Doesn't this subtracting into 'opaque' clobber the state that is being
accumulated into it over several calls to surface_accumulate_damage()?
'opaque' is supposed to accumulate the opaque regions when walking the
surface stack from top to bottom, so we can skip painting surface
regions that are already hidden by opaque regions above. Simple
assignment to it is strange.

Could you explain these operations, since to me they look just wrong?

>   pixman_region32_copy(&surface->clip, opaque);
>   pixman_region32_union(opaque, opaque, &surface->transform.opaque);
>  }
> @@ -1223,6 +1224,7 @@ weston_output_repaint(struct weston_output *output, 
> uint32_t msecs)
>   wl_list_for_each(layer, &ec->layer_list, link) {
>   wl_list_for_each(es, &layer->surface_list, layer_link) {
>   weston_surface_update_transform(es);
> + es->layer = layer;
>   wl_list_insert(ec->surface_list.prev, &es->link);
>   if (es->output == output) {
>   wl_list_insert_list(&frame_callback_list,
> @@ -1319,11 +1321,24 @@ WL_EXPORT void
>  weston_layer_init(struct weston_layer *layer, struct wl_list *below)
>  {
>   wl_list_init(&layer->surface_list);
> + region_init_infinite(&layer->clip);
>   if (below != NULL)
>   wl_list_insert(below, &layer->link);
>  }
>  
>  WL_EXPORT void
> +weston_layer_clip(struct weston_layer *layer, int x, int y, int width, int 
> height)
> +{
> + pixman_region32_init_rect(&layer->clip, x, y, width, height);
> +}
> +
> +WL_EXPORT void
> +weston_layer_clip_infinite(struct weston_layer *layer)
> +{
> +region_init_infinite(&layer->clip);
> +}
> +
> +WL_EXPORT void
>  weston_output_schedule_repaint(struct weston_output *output)
>  {
>   struct weston_compositor *compositor = output->compositor;
> diff --git a/src/compositor.h b/src/compositor.h
> index 1e999a6..b3038bd 100644
> --- a/src/compositor.h
> +++ b/src/compositor.h
> @@ -271,6 +271,7 @@ enum {
>  struct weston_layer {
>   struct wl_list surface_list;
>   struct wl_list link;
> + pixman_region32_t clip;
>  };
>  
>  struct weston_plane {
> @@ -413,6 +414,7 @@ struct weston_surface {
>   struct wl_list layer_link;
>   float alpha; /* part of geometry, see below */
>   struct weston_plane *plane;
> + struct weston_layer *layer;

I think we should have some comment or grouping here to indicate, that
'layer' is only valid during repaint.

>  
>   void *renderer_state;
>  
> @@ -598,6 +600,12 @@ void
>  weston_layer_init(struct weston_layer *layer, struct wl_list *below);
>  
>  void
> +weston_layer_clip(struct weston_layer *layer, int x, int y, int width, int 
> height);
> +
> +void
> +weston_layer_clip_infinite(struct weston_layer *layer);
> +
> +void
>  weston_plane_init(struct weston_plane *plane, int32_t x, int32_t y);
>  void
>  weston_plane_release(struct weston_plane *plane);

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

Re: Input and games.

[Pekka Paalanen]

On Mon, 22 Apr 2013 15:32:50 -0400
Todd Showalter  wrote:

> On Mon, Apr 22, 2013 at 1:40 PM, Pekka Paalanen 
> wrote:
> 
> >> Gamepads, by contrast, are all mostly the same these days, much
> >> like mice.  You can find oddball ones like that PC gamepad that
> >> was up on Kickstarter recently which had a trackball in place of
> >> the right thumb stick, but the core gamepad is now every bit as
> >> standardized as the core mouse.
> >
> > Alright, do you really mean that the controls are as standard as
> > mouse buttons and wheels, and we would not need a per-device-model
> > database? If so, then sure, a mouse-like Wayland protocol would
> > indeed be possible.
> 
> What I mean is that in practice, the difference between game
> controllers is almost entirely two things; which particular bit in the
> button mask gets set/cleared by any particular button, and which axis
> maps to which control.  Right now (unless things have changed), for
> example, if you plug in an xbox 360 controller:
> 
> - left stick is axis (0, 1)
> - left trigger is axis 2
> - right stick is axis (3, 4)
> - right trigger is axis 5
> - dpad is axis (6, 7)
> 
> I had to determine that by logging values and playing with the
> controls to see what made what numbers move.  The xbox controller (ie:
> not 360) may be the same order, it may not be.  The Dual Shock
> controller may be the same order, it likely isn't.  So unless we're
> really lucky something has to convert the axis ordering to a canonical
> form.
> 
> Likewise, the buttons are just indexed, since as far as I can tell
> without cracking open the code, JSGetButtonState() is just:
> 
> return (buttons & (1 << index));
> 
> I'd vastly prefer keysyms here; I don't want to have to go look up
> which button is START on this controller, or have to figure out which
> index is the bottom right face button.
> 
> So, some layer needs to translate buttons to keysyms, and adjust
> the axis ordering (and possibly scaling) to fit the canonical
> controller model, which I would suggest essentially be two analog
> sticks, two analog triggers, plus keys (where the four dpad directions
> are keys).  The translation layer needn't be very complex; as long as
> there's some way to query evdev or the underlying system to find out
> exactly what kind of device this is, it's a simple matter of per-axis
> scale, offset and index translation (ie: scale this axis by -0.5f, add
> 1.0f, map to left trigger) and a list of bit to keysym lookups.
> 
> So, in terms of hardware capabilities, there is very much a
> standard.  In terms of how that hardware is presented to the system
> over USB, the same data is all there, but your guess is as good as
> mine with regards to ordering.  Which is the problem I'd really like
> to see solved.

Hi Todd,

what you describe here is very much a keymap-like database for game
controllers: translating from button and axis indices to labels or
symbols. However, having a brief chat with Daniel Stone, it seems we
should not need these.

Take a look at /usr/include/linux/input.h

There you find definitions for BTN_A, BTN_X, BTN_START, ABS_X, ABS_Y,
ABS_RX, ABS_RY, ABS_HATnn, and many more. The kernel evdev interface
should alreay be giving out events with the correct label, so we would
not need any mapping.

Are you saying that the kernel gives out the labels wrong? If so, this
should be fixed in the kernel drivers. One thing less to care about in
Wayland. We "just" need to write the protocol for these devices, the
labels should be already there.

The current behaviour can be checked with evtest:
http://cgit.freedesktop.org/evtest/
Was that what you used to check the controller events?

> >> >> If the events are just coming in as a pile in 60Hz ticks,
> >> >> it's all good and we can do everything we need to.  If they're
> >> >> coming in as a pile at 10Hz ticks, it's going to be difficult
> >> >> to make anything more active than Solitaire.
> >> >
> >> > Yes as far as I understand, currently input events are sent to
> >> > Wayland clients as a burst at every compositor repaint cycle,
> >> > which happens at the monitor refresh rate, so for a 60 Hz
> >> > monitor, you would be getting them in bursts at 60 Hz.
> >>
> >> That's as good as we get from consoles, and besides, there
> >> isn't much point in most games in running your simulator at a
> >> higher frequency than the refresh rate.
> >
> > What about these hardcore fps-gamers who want at least 200+ frames
> > per second, or they can't win? :-)
> 
> If you're sending me vsync at 200Hz, I'll gladly update my
> simulation at 200Hz and chew input at 200Hz.  :)
> 
> Most players are playing on 60Hz refresh monitors, and those LCD
> monitors have enough lag on them that it really doesn't matter if the
> simulation ticks are happening (and eating input) faster than that.
> Even if you react at the speed of light (literally), you're
> interacting with data where he simulation probably sta

Re: [DRM] Patch for Compositor Drm

[Ander Conselvan de Oliveira]

Hi,

Thanks for fixing this.

Just a small nitpick about the commit message. We keep the summary line 
below 76 characters because of git log, and we also prefix it with the 
component to which the change was made. In this particular case, I would 
go with something like


compositor-drm: Check return value of drmIoctl() in drm_fb_create_dumb()

Thanks,
Ander


On 04/22/2013 07:12 PM, Christopher Michael wrote:

 From acb79e4a5921525b35e07e48f7f903e42a08fb7c Mon Sep 17 00:00:00 2001
From: Chris Michael 
Date: Mon, 22 Apr 2013 15:22:48 +0100
Subject: [PATCH] Fix not checking return value of drmIoctl function call to
  map dumb buffer.

in drm_fb_create_dumb, the return value of the drmIoctl function call
to map the dumb buffer was never checked, thus the following "if
(ret)" check was invalid as it was checking the previous return value
from the above drmModeAddFB call.

Signed-off-by: Chris Michael 
---
  src/compositor-drm.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index da1ba79..13b9d79 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -255,7 +255,7 @@ drm_fb_create_dumb(struct drm_compositor *ec,
unsigned width, unsigned height)

  memset(&map_arg, 0, sizeof(map_arg));
  map_arg.handle = fb->handle;
-drmIoctl(fb->fd, DRM_IOCTL_MODE_MAP_DUMB, &map_arg);
+ret = drmIoctl(fb->fd, DRM_IOCTL_MODE_MAP_DUMB, &map_arg);

  if (ret)
  goto err_add_fb;


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

Re: [PATCH] Extract and parse the EDID when outputs are added

[Ander Conselvan de Oliveira]

Hi,


On 04/22/2013 02:57 PM, Richard Hughes wrote:

At the moment we're only extracting interesting strings. We have to be quite
careful parsing the EDID data, as vendors like to do insane things.


You should add some information of why this patch is necessary to the 
commit message. It seems you added that to the cover letter, but it 
should be in the commit message so we can find that later without going 
through the list archives.



The original EDID parsing code was written by me for gnome-color-manager.
---
  src/compositor-drm.c | 139 +++
  src/compositor.h |   2 +-
  2 files changed, 140 insertions(+), 1 deletion(-)

diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index da1ba79..1909712 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c


[...]


@@ -1499,7 +1603,10 @@ create_output_for_connector(struct drm_compositor *ec,
drmModeEncoder *encoder;
drmModeModeInfo crtc_mode;
drmModeCrtc *crtc;
+   drmModePropertyPtr property;
+   drmModePropertyBlobPtr edid_blob = NULL;
int i;
+   int rc;
char name[32];
const char *type_name;

@@ -1517,6 +1624,7 @@ create_output_for_connector(struct drm_compositor *ec,
output->base.subpixel = drm_subpixel_to_wayland(connector->subpixel);
output->base.make = "unknown";
output->base.model = "unknown";
+   output->base.serial = "unknown";
wl_list_init(&output->base.mode_list);

if (connector->connector_type < ARRAY_LENGTH(connector_type_names))
@@ -1642,6 +1750,37 @@ create_output_for_connector(struct drm_compositor *ec,

wl_list_insert(ec->base.output_list.prev, &output->base.link);

+   /* find and parse the EDID blob */
+   for (i = 0; i < connector->count_props && !edid_blob; i++) {
+   property = drmModeGetProperty(ec->drm.fd, connector->props[i]);
+   if (!property)
+   continue;
+   if ((property->flags & DRM_MODE_PROP_BLOB) &&
+   !strcmp(property->name, "EDID")) {
+   edid_blob = drmModeGetPropertyBlob(ec->drm.fd,
+  
connector->prop_values[i]);
+   }
+   drmModeFreeProperty(property);
+   }
+   if (edid_blob) {
+   rc = edid_parse(&output->edid,
+   edid_blob->data,
+   edid_blob->length);
+   if (!rc) {
+   weston_log("EDID data '%s', '%s', '%s'\n",
+  output->edid.pnp_id,
+  output->edid.monitor_name,
+  output->edid.serial_number);
+   if (output->edid.pnp_id[0] != '\0')
+   output->base.make = output->edid.pnp_id;
+   if (output->edid.monitor_name[0] != '\0')
+   output->base.model = output->edid.monitor_name;
+   if (output->edid.serial_number[0] != '\0')
+   output->base.serial = 
output->edid.serial_number;
+   }
+   drmModeFreePropertyBlob(edid_blob);
+   }
+


Could you split this whole hunk into a separate function, 
create_output_for_connector() is already awfully long.



output->base.origin = output->base.current;
output->base.start_repaint_loop = drm_output_start_repaint_loop;
output->base.repaint = drm_output_repaint;
diff --git a/src/compositor.h b/src/compositor.h
index 1e999a6..fa6162c 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -178,7 +178,7 @@ struct weston_output {
uint32_t frame_time;
int disable_planes;

-   char *make, *model;
+   char *make, *model, *serial;


I think it would be better to call this field 'serial_number'. We 
normally use 'serial' for numbers obtained from 
wl_display_next_serial(), and that may lead to unnecessary confusion.



Cheers,
Ander


uint32_t subpixel;
uint32_t transform;




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

Re: [PATCH 1/3] Extract the EDID blob when adding a DRM output

[Richard Hughes]

On 23 April 2013 08:32, Kai-Uwe Behrmann  wrote:
> Client side parsing is a different issue indeed. However the patch author
> mentioned in the initial post GNOME CMS alias colord as a plugin inside the
> Weston CMS. So other possible CMS plugins like Argyll and Oyranos have
> different requirements and want to access the standards EDID binary blob for
> their own feature set.

You mean things like the Yxy primaries and the MD5 ID? That's
perfectly in scope for my little parser here, I just didn't include it
yet as I wanted to get the core stuff implemented and reviewed.

> Btw. a library for parsing CMS related attributes from EDID exists:
> http://www.oyranos.org/libxcm/

Sure, but it's an additional dep, which also drags in quite a few
chunks of the weirder parts of X11. We don't need a deps list like
that just to parse a few fields in an EDID blob.

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

Re: [PATCH] evdev: Handle SYN_DROPPED, keep transaction buffer

[Pekka Paalanen]

On Sat, 6 Apr 2013 00:27:10 +0200
Martin Minarik  wrote:

> Each evdev device keeps a key press bitmap,
> the incoming events are filtered to the following constraints:
> 
> 1. only notify releases for previously pressed keys
> 2. only notify presses for previously released keys
> 3. on device destroy, notify a releases for all pressed keys
> 
> Notes:
> 
> 1. For example when switching VTs, we recieve only key releases
>Nothing special, the lost key presses were of course not
>recorded (happens outside weston). So key releases are simply
>dropped with warning (double release).
> 2. This is solved by injecting a fake key release notify, we
>assume evdev doesn't send double key press without key
>release in between.
> 3. Solved by broadcasting fake release events.

Hi,

how is this explanation related to SYN_DROPPED?

It looks like the title promises one thing, and then the explanation
discusses a completely different thing, and as far as I understood from
a quick glance, the patch attemps to do both.

I think this should be split into two patches, one handling
SYN_DROPPED, and the other the rest.

Also, I do not think you can fake key events, if that is what I think
it is. You can't get a real timestamp for them, and in general, I think
we just do not want to fake anything. If you need a "reset all state"
action, write one.

Was there some related irc discussion?


Thanks,
pq


> ---
>  src/evdev-touchpad.c |   57 +++-
>  src/evdev.c  |  240
> ++
> src/evdev.h  |   31 +++ 3 files changed, 289
> insertions(+), 39 deletions(-)
> 
> diff --git a/src/evdev-touchpad.c b/src/evdev-touchpad.c
> index c25a199..8f1e0c3 100644
> --- a/src/evdev-touchpad.c
> +++ b/src/evdev-touchpad.c
> @@ -523,6 +523,27 @@ on_release(struct touchpad_dispatch *touchpad)
>   push_fsm_event(touchpad, FSM_EVENT_RELEASE);
>  }
>  
> +struct evdev_dispatch_interface touchpad_interface;
> +struct evdev_dispatch_interface touchpad_syn_drop_interface;
> +
> +static inline void
> +process_syn(struct touchpad_dispatch *touchpad,
> +  struct evdev_device *device,
> +  struct input_event *e, uint32_t time)
> +{
> + switch (e->code) {
> + case SYN_DROPPED:
> + if (device->dispatch->interface ==
> &touchpad_interface)
> + device->dispatch->interface =
> &touchpad_syn_drop_interface;
> + weston_log("warning: evdev: Syn drop at %u on %s
> \n", time, device->devname);
> + break;
> + case SYN_REPORT:
> + default:
> + touchpad->event_mask |= TOUCHPAD_EVENT_REPORT;
> + break;
> + }
> +}
> +
>  static inline void
>  process_absolute(struct touchpad_dispatch *touchpad,
>struct evdev_device *device,
> @@ -578,7 +599,8 @@ process_key(struct touchpad_dispatch *touchpad,
>   case BTN_FORWARD:
>   case BTN_BACK:
>   case BTN_TASK:
> - notify_button(device->seat,
> + if (evdev_tx(device, e->code, e->value))
> + notify_button(device->seat,
> time, e->code,
> e->value ?
> WL_POINTER_BUTTON_STATE_PRESSED : WL_POINTER_BUTTON_STATE_RELEASED);
> @@ -624,8 +646,7 @@ touchpad_process(struct evdev_dispatch *dispatch,
>  
>   switch (e->type) {
>   case EV_SYN:
> - if (e->code == SYN_REPORT)
> - touchpad->event_mask |=
> TOUCHPAD_EVENT_REPORT;
> + process_syn(touchpad, device, e, time);
>   break;
>   case EV_ABS:
>   process_absolute(touchpad, device, e);
> @@ -654,6 +679,32 @@ struct evdev_dispatch_interface
> touchpad_interface = { touchpad_destroy
>  };
>  
> +static void
> +touchpad_syn_drop_process(struct evdev_dispatch *dispatch,
> +  struct evdev_device *device,
> +  struct input_event *event,
> +  uint32_t time)
> +{
> + if ((event->code != EV_SYN) || (event->code != SYN_REPORT))
> + return;
> +
> + if (device->dispatch->interface ==
> &touchpad_syn_drop_interface)
> + device->dispatch->interface = &touchpad_interface;
> +
> + evdev_tx_sync(device, time);
> +}
> +
> +static void
> +touchpad_syn_drop_destroy(struct evdev_dispatch *dispatch)
> +{
> + free(dispatch);
> +}
> +
> +struct evdev_dispatch_interface touchpad_syn_drop_interface = {
> + touchpad_syn_drop_process,
> + touchpad_syn_drop_destroy
> +};
> +
>  static int
>  touchpad_init(struct touchpad_dispatch *touchpad,
> struct evdev_device *device)
> diff --git a/src/evdev.c b/src/evdev.c
> index d2954b5..5417149 100644
> --- a/src/evdev.c
> +++ b/src/evdev.c
> @@ -60,6 +60,130 @@ evdev_led_update(struct evdev_device *device,
> enum weston_led leds) (void)i; /* no, we really don't care about the
> return value */ }
>  
> +struct evdev_dispatch_interface fallback_interface;
> +struct evdev

RE: [RFC] [tests] Running the wayland tests against compositor-headless

[Eoff, Ullysses A]

> -Original Message-
> From: Sam Spilsbury [mailto:smspil...@gmail.com]
>>
>> 
>>
> Ah interesting. I guess the point of the tests is to verify the
> backends themselves as opposed to testing the core compositor (well,
> it tests that as an incident, but I guess its not the point?). Does it
> make sense to have also acceptance tests which really only verify the
> core behavior of weston and not the backends themselves?
>

Well, not exactly.  The tests don't *explicitly* verify or depend on any 
particular
backend.  But, many of them (client<->server tests) depend on the availability
of input devices (i.e. pointer and keyboard).  As it stands, the backends
are the only parts that provide/initialize those input devices (except the
headless backend, of course).  And, as a side-effect, the backends are the
components that get incidental (i.e. implicit) verification--which is a good 
thing.

There is no reason why we couldn't create new client<->server and/or
server-only tests to verify other *non-input* related parts of core 
functionality.
Believe me, we need more of em :-).

> > ...but if it's a problem that the tests themselves can't run on the headless
> backend,
> > then changing those in a way to work on headless, too, might be useful.
> 
> So at the moment - they aren't - well, its possible to run the two
> library based ones. 3 of the client based ones are easy to enable, as
> for the other three, two of them protocol support from the backend,
> the other one (xwayland) doesn't really make sense on headless.
> 

Yes, it would be trivial to enable the input-based tests to run on the
headless backend... however, it's unclear to me whether the headless
backend should be the one responsible for initializing/tracking the
keyboard and pointer inputs.  That kinda feels counter intuitive to the
definition of "headless" (but perhaps not :-/).  Maybe we could have the
weston-test extension module initialize the inputs in an idle loop
callback, for example if the output->model == "headless", then
do:

weston_seat_init_pointer(seat);
weston_seat_init_keyboard(seat, NULL);

For the other two, which ones are they and what kind of protocol
support is lacking?  Perhaps there is another way we can get them
to work on "headless"?

> The broader reason I'm looking into this is because I want to see if
> we can eventually export the weston-test module as part of the
> installation as well as the headless and no-op backends so that
> applications can run integration tests against weston to verify that
> they handle input, shell surface changes etc correctly. I'm looking
> into doing some GSoC work on a project where I suspect that the
> wayland backend will not be run all the time, and it will be good to
> have integration tests in place to ensure that it doesn't break
> accidentally because developers may not be able to run it regularly.
> 

The headless backend module gets installed, already.  But if you're
also talking about exporting headless backend header(s), then I'm
willing to bet that won't happen.

As for the weston-test module being exported (module and headers),
that would have to be the maintainer's decision (Kristian; aka, krh)
and/or a consensus from other community contributors.

If nothing else, you can always write your own test extension, too, that
will enable you to do integration testing on your particular application
use-cases.

> So - shall I create and submit some patches to get the tests working
> on headless? I suppose this is a desirable thing right?
> 

I wouldn't be the one to make the ultimate decision on their
inclusions into upstream.  It'd be nice to hear what others think about
this topic, too.  Either way, it wouldn't hurt to send patches for review,
feedback, and discussion... even if they end up getting rejected for a
different solution ;).

> Best,
> 
> Sam
> 
> > 

Cheers,

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

Re: [PATCH 1/3] Extract the EDID blob when adding a DRM output

[Kai-Uwe Behrmann]

Am 23.04.2013 07:49, schrieb David Herrmann:

On Apr 23, 2013 6:38 AM, "Graeme Gill"  wrote:

David Herrmann wrote:



Patch 3/3 parses the blob and keeps the parsed values. Why
should we keep the binary blob, too? If we need more EDID values, we
simply extend the parser?


This would seem to imply that every time a client/application needs some
piece of information from the EDID that hasn't been allowed for,
an update to the display server is needed.


Please read the patch. This is a display server internal feature, clients
aren't involved. It's about the display server parsing the EDID blob for
its own use!

If you want clients to be involved, it's a separate feature and you can
keep the blob if you need it. But this doesn't belong in this patch.


Client side parsing is a different issue indeed. However the patch 
author mentioned in the initial post GNOME CMS alias colord as a plugin 
inside the Weston CMS. So other possible CMS plugins like Argyll and 
Oyranos have different requirements and want to access the standards 
EDID binary blob for their own feature set.


>> I think the idea would be to have both (a minimal set of parsed
>> information, + the blob), or relegate the parsing to a client
>> library would be another approach, although supplying that
>> client library by default would be a good thing, rather
>> than leaving everyone to re-invent EDID parsing badly.

Btw. a library for parsing CMS related attributes from EDID exists:
http://www.oyranos.org/libxcm/

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

Re: Pointer lock and warping

[Pekka Paalanen]

On Mon, 22 Apr 2013 19:48:14 -0700
Bill Spitzak  wrote:

> Thinking about Todd Showalter's requests for pointer warping, I think
> in fact a correctly-behaving Wayland app will always want pointer
> warping and incremental update when the mouse is held down. This
> would require a major change in the mouse api, though I think the
> differences in back-compatibility can be worked around in the client
> library. This has the side effect of also getting the "slow
> scrollbar" effect requested, and edge resistance, and an equivalent
> of the pointer-lock proposal into a single api.
> 
> The purpose is to produce non-jittery dragging of objects. If the
> user drags an object drawn in the window, if the pointer image and
> drawn image move out of sync they will jitter in respect to each
> other. The solution is to synchronize the pointer movement with the
> drawing using the commit mechanism.

Here's a lot simpler solution for non-jittery dragging of objects: just
hide the pointer cursor, when starting the move. If you still want the
pointer cursor visible, draw it yourself with the object you are
moving. That is already possible today, and sub-surfaces will make that
even simpler to implement in the future.


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