Re: Compiling weston now needs colord

[Michael Hasselmann]

On Tue, 2013-05-28 at 22:16 -0700, Bill Spitzak wrote:
> Running autogen.sh in weston with --disable-colord works to avoid this, 
> I suspect nothing I care about is lost this way.

I ran into the very same problems. I would have preferred if such new
dependencies were optional or if someone would explain what we will miss
if we disable them. For colord, trying to build the latest required
version from git just pulls in more dependencies that you also have to
build from git (as Bill mentioned).

It's kind of frustrating, even if weston is meant to be a playground and
thus new dependencies have to be expected.

http://wayland.freedesktop.org/building.html should be updated I guess?

ciao Michael


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

[PATCH wayland] Clean up the internals of wl_map

[Jason Ekstrand]

This commit cleans up the internals of wl_map by splitting it into two
wl_simple_maps.  This both makes the internals cleaner and also fixes potential
issues with having a single free_list for both sides of the map.

Signed-off-by: Jason Ekstrand 
---

Ignore the previous patch as it contained an error.  This one is the correct 
one.

 src/wayland-private.h |  10 ++-
 src/wayland-util.c| 177 +++---
 2 files changed, 102 insertions(+), 85 deletions(-)

diff --git a/src/wayland-private.h b/src/wayland-private.h
index c4ce6b0..a733a96 100644
--- a/src/wayland-private.h
+++ b/src/wayland-private.h
@@ -41,12 +41,16 @@
 #define WL_SERVER_ID_START 0xff00
 #define WL_CLOSURE_MAX_ARGS 20
 
-struct wl_map {
-   struct wl_array client_entries;
-   struct wl_array server_entries;
+struct wl_simple_map {
+   struct wl_array entries;
uint32_t free_list;
 };
 
+struct wl_map {
+   struct wl_simple_map client_map;
+   struct wl_simple_map server_map;
+};
+
 typedef void (*wl_iterator_func_t)(void *element, void *data);
 
 void wl_map_init(struct wl_map *map);
diff --git a/src/wayland-util.c b/src/wayland-util.c
index 598ab42..10607d8 100644
--- a/src/wayland-util.c
+++ b/src/wayland-util.c
@@ -151,102 +151,64 @@ union map_entry {
void *data;
 };
 
-WL_EXPORT void
-wl_map_init(struct wl_map *map)
-{
-   memset(map, 0, sizeof *map);
-}
-
-WL_EXPORT void
-wl_map_release(struct wl_map *map)
-{
-   wl_array_release(&map->client_entries);
-   wl_array_release(&map->server_entries);
-}
-
-WL_EXPORT uint32_t
-wl_map_insert_new(struct wl_map *map, uint32_t side, void *data)
+static uint32_t
+wl_simple_map_insert_new(struct wl_simple_map *map, void *data)
 {
union map_entry *start, *entry;
-   struct wl_array *entries;
-   uint32_t base;
-
-   if (side == WL_MAP_CLIENT_SIDE) {
-   entries = &map->client_entries;
-   base = 0;
-   } else {
-   entries = &map->server_entries;
-   base = WL_SERVER_ID_START;
-   }
-
if (map->free_list) {
-   start = entries->data;
+   start = map->entries.data;
entry = &start[map->free_list >> 1];
map->free_list = entry->next;
} else {
-   entry = wl_array_add(entries, sizeof *entry);
+   entry = wl_array_add(&map->entries, sizeof *entry);
if (!entry)
return 0;
-   start = entries->data;
+   start = map->entries.data;
}
 
entry->data = data;
 
-   return (entry - start) + base;
+   return (entry - start);
 }
 
-WL_EXPORT int
-wl_map_insert_at(struct wl_map *map, uint32_t i, void *data)
+static int
+wl_simple_map_insert_at(struct wl_simple_map *map, uint32_t i, void *data)
 {
union map_entry *start;
uint32_t count;
-   struct wl_array *entries;
-
-   if (i < WL_SERVER_ID_START) {
-   entries = &map->client_entries;
-   } else {
-   entries = &map->server_entries;
-   i -= WL_SERVER_ID_START;
-   }
 
-   count = entries->size / sizeof *start;
+   count = map->entries.size / sizeof *start;
if (count < i)
return -1;
 
if (count == i)
-   wl_array_add(entries, sizeof *start);
+   if (!wl_array_add(&map->entries, sizeof *start))
+   return -1;
 
-   start = entries->data;
+   start = map->entries.data;
start[i].data = data;
 
return 0;
 }
 
-WL_EXPORT int
-wl_map_reserve_new(struct wl_map *map, uint32_t i)
+static int
+wl_simple_map_reserve_new(struct wl_simple_map *map, uint32_t i)
 {
union map_entry *start;
uint32_t count;
-   struct wl_array *entries;
 
-   if (i < WL_SERVER_ID_START) {
-   entries = &map->client_entries;
-   } else {
-   entries = &map->server_entries;
-   i -= WL_SERVER_ID_START;
-   }
-
-   count = entries->size / sizeof *start;
+   count = map->entries.size / sizeof *start;
 
if (count < i)
return -1;
 
if (count == i) {
-   wl_array_add(entries, sizeof *start);
-   start = entries->data;
+   if (!wl_array_add(&map->entries, sizeof *start))
+   return -1;
+   start = map->entries.data;
start[i].data = NULL;
} else {
-   start = entries->data;
+   start = map->entries.data;
if (start[i].data != NULL) {
return -1;
}
@@ -255,40 +217,24 @@ wl_map_reserve_new(struct wl_map *map, uint32_t i)
return 0;
 }
 
-WL_EXPORT void
-wl_map_remove(struct wl_map *map, uint32_t i)
+static void
+wl_simple_map_remove(struct wl_simple_map *map, uint32_t i)
 {
union map_entry *start;
-  

[PATCH wayland] Clean up the internals of wl_map

[Jason Ekstrand]

This commit cleans up the internals of wl_map by splitting it into two
wl_simple_maps.  This both makes the internals cleaner and also fixes potential
issues with having a single free_list for both sides of the map.

Signed-off-by: Jason Ekstrand 
---
 src/wayland-private.h |  10 ++-
 src/wayland-util.c| 172 ++
 2 files changed, 97 insertions(+), 85 deletions(-)

diff --git a/src/wayland-private.h b/src/wayland-private.h
index c4ce6b0..a733a96 100644
--- a/src/wayland-private.h
+++ b/src/wayland-private.h
@@ -41,12 +41,16 @@
 #define WL_SERVER_ID_START 0xff00
 #define WL_CLOSURE_MAX_ARGS 20
 
-struct wl_map {
-   struct wl_array client_entries;
-   struct wl_array server_entries;
+struct wl_simple_map {
+   struct wl_array entries;
uint32_t free_list;
 };
 
+struct wl_map {
+   struct wl_simple_map client_map;
+   struct wl_simple_map server_map;
+};
+
 typedef void (*wl_iterator_func_t)(void *element, void *data);
 
 void wl_map_init(struct wl_map *map);
diff --git a/src/wayland-util.c b/src/wayland-util.c
index 598ab42..b8831b8 100644
--- a/src/wayland-util.c
+++ b/src/wayland-util.c
@@ -151,102 +151,64 @@ union map_entry {
void *data;
 };
 
-WL_EXPORT void
-wl_map_init(struct wl_map *map)
-{
-   memset(map, 0, sizeof *map);
-}
-
-WL_EXPORT void
-wl_map_release(struct wl_map *map)
-{
-   wl_array_release(&map->client_entries);
-   wl_array_release(&map->server_entries);
-}
-
-WL_EXPORT uint32_t
-wl_map_insert_new(struct wl_map *map, uint32_t side, void *data)
+static uint32_t
+wl_simple_map_insert_new(struct wl_simple_map *map, void *data)
 {
union map_entry *start, *entry;
-   struct wl_array *entries;
-   uint32_t base;
-
-   if (side == WL_MAP_CLIENT_SIDE) {
-   entries = &map->client_entries;
-   base = 0;
-   } else {
-   entries = &map->server_entries;
-   base = WL_SERVER_ID_START;
-   }
-
if (map->free_list) {
-   start = entries->data;
+   start = map->entries.data;
entry = &start[map->free_list >> 1];
map->free_list = entry->next;
} else {
-   entry = wl_array_add(entries, sizeof *entry);
+   entry = wl_array_add(&map->entries, sizeof *entry);
if (!entry)
return 0;
-   start = entries->data;
+   start = map->entries.data;
}
 
entry->data = data;
 
-   return (entry - start) + base;
+   return (entry - start);
 }
 
-WL_EXPORT int
-wl_map_insert_at(struct wl_map *map, uint32_t i, void *data)
+static int
+wl_simple_map_insert_at(struct wl_simple_map *map, uint32_t i, void *data)
 {
union map_entry *start;
uint32_t count;
-   struct wl_array *entries;
-
-   if (i < WL_SERVER_ID_START) {
-   entries = &map->client_entries;
-   } else {
-   entries = &map->server_entries;
-   i -= WL_SERVER_ID_START;
-   }
 
-   count = entries->size / sizeof *start;
+   count = map->entries.size / sizeof *start;
if (count < i)
return -1;
 
if (count == i)
-   wl_array_add(entries, sizeof *start);
+   if (!wl_array_add(&map->entries, sizeof *start))
+   return -1;
 
-   start = entries->data;
+   start = map->entries.data;
start[i].data = data;
 
return 0;
 }
 
-WL_EXPORT int
-wl_map_reserve_new(struct wl_map *map, uint32_t i)
+static int
+wl_simple_map_reserve_new(struct wl_simple_map *map, uint32_t i)
 {
union map_entry *start;
uint32_t count;
-   struct wl_array *entries;
 
-   if (i < WL_SERVER_ID_START) {
-   entries = &map->client_entries;
-   } else {
-   entries = &map->server_entries;
-   i -= WL_SERVER_ID_START;
-   }
-
-   count = entries->size / sizeof *start;
+   count = map->entries.size / sizeof *start;
 
if (count < i)
return -1;
 
if (count == i) {
-   wl_array_add(entries, sizeof *start);
-   start = entries->data;
+   if (!wl_array_add(&map->entries, sizeof *start))
+   return -1;
+   start = map->entries.data;
start[i].data = NULL;
} else {
-   start = entries->data;
+   start = map->entries.data;
if (start[i].data != NULL) {
return -1;
}
@@ -255,40 +217,24 @@ wl_map_reserve_new(struct wl_map *map, uint32_t i)
return 0;
 }
 
-WL_EXPORT void
-wl_map_remove(struct wl_map *map, uint32_t i)
+static void
+wl_simple_map_remove(struct wl_simple_map *map, uint32_t i)
 {
union map_entry *start;
-   struct wl_array *entries;
 
-   if (i < WL_SERVER_ID_START) {
-   ent

Re: Licence for RPi .pc files ?

[Tom Gundersen]

On Tue, May 28, 2013 at 11:27 AM, Pekka Paalanen  wrote:
> On Mon, 6 May 2013 23:29:24 +0200
> Tom Gundersen  wrote:
>
>> On Mon, May 6, 2013 at 8:12 AM, Pekka Paalanen  wrote:
>> > On Sun, 5 May 2013 22:06:49 +0200
>> > Tom Gundersen  wrote:
>> >
>> >> Hi Pekka,
>> >>
>> >> I'm trying to make Weston work nicely on Raspberry Pi under ArchLinux
>> >> ARM, and was pointed to Collabora's pkg-config files [0] from the
>> >> Wayland wiki [1]. I couldn't find any licencing information, so I
>> >> thought I'd ask you as you are the author of most of the commits:
>> >>
>> >> What is the licence of the files, and would you be ok with them being
>> >> included upstream (I suppose [2]), or is there a reason they are kept
>> >> separate? I'd be happy to submit them if the licence allows it.
>> >>
>> >> Cheers,
>> >>
>> >> Tom
>> >>
>> >> [0]: 
>> >> 
>> >> [1]: 
>> >> [2]: 
>> >
>> > Hi Tom,
>> >
>> > we have intended to submit those files upstream for quite some time,
>> > but somehow there has always been something better to do. Therefore I
>> > would be very glad to see them submitted upstream!
>> >
>> > As for the licence, I never included one, since I didn't think they
>> > would count as copyrightable work, being so tiny and obvious. The
>> > information there has been gathered from public resources, mainly the
>> > rpi firmware.git examples.
>> >
>> > Please, consider the three files in [0] (the raspberrypi branch) as
>> > public domain. I'm also ok, if you or upstream wants to put them under
>> > a BSD-like licence.
>> >
>> > However, you should check, that the files are correct, especially all
>> > the flags. You probably want to change the description strings (since in
>> > upstream they are not fake anymore), and probably the version numbers.
>> > Maybe ask the upstream, what version numbers they want to use.
>> >
>> > I chose the version numbers simply to fill the requirements in Weston's
>> > configure, which assumes Mesa version numbers. That will probably
>> > become a problem, since rpi upstream is not Mesa, but still provides
>> > e.g. egl.pc, and Weston should accept both with provider specific
>> > version checks. I do not know how to solve that nicely.
>> >
>> > Maybe this issue should be raised with Mesa. I don't know if anyone
>> > else provides an egl.pc, but to me it seems that everyone should
>> > provide an egl.pc with the *EGL* version number, and then provide an
>> > additional .pc file for the implementor's version, say, mesa.pc.
>> >
>> > And now that there is the new Linux OpenGL ABI proposal in the works,
>> > that might be a good place to see it defined.
>> > http://lists.freedesktop.org/archives/mesa-dev/2013-April/038440.html
>> >
>> > Therefore, I assume you will be changing the files enough, that they
>> > become your work, if anyone's. :-)
>>
>> Thanks for the pointers Pekka, I'll look into this to get it upstream asap.
>
> Hi Tom,
>
> is there somewhere I could follow the progress on this?

Hi Pekka,

Sorry to say I didn't yet manage to find time for this. I expect to
have some more time next week, and will cc this list once I post
something (unless someone else beat me to it ;-) ).

Cheers,

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

Re: [PATCH 00/15] weston scaling support

[Bill Spitzak]

On 05/29/2013 12:31 AM, Alexander Larsson wrote:


I don't think you can avoid non-integer scaling. What happens if a
client says it's scale is 3 and the output has a scale of 2? This is not
just hypothetical, it will certainly happen if there is both a scale 3
and scale 2 output on the device.


Yes, the actual scaling that the compositor has to apply from the buffer
to a given output may be fractional. However, the scaling factor between
the buffer and the surface (i.e. in pels or in global compositor
relative sizes) is an integer. This means that any integer position in
surface space corresponds to an integer in buffer space, so for instance
a pixman region (in ints) damage or clip region in surface space
corresponds to an exact pixman region in buffer coordinates. And, this
is the transformation that the compositor really cares about internally
(e.g. for input scaling, clipping, dirty tracking, etc) rather than the
final drawing translation.


The compositor will produce regions that are not integers in surface 
space. For instance the damage from an overlapping window atop a surface 
who's scale is not an integer will produce a region that is fractional 
in that lower surface's space.


I agree that the compositor will then immediately expand these to 
integer buffer coordinates, but I don't think limiting the scales to 
integers is buying you anything.


The client should send regions to the compositor in buffer pixels. It 
has to use these coordinates to draw and things like "opaque region" are 
much more related to drawing than anything else.


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

Re: Compiling weston now needs colord

[Bill Spitzak]

On 05/28/2013 11:33 PM, Armin K. wrote:


http://packages.ubuntu.com/search?keywords=libcolord-dev

Debian and derivatives ship development files in corresponding
lib-dev packages.


Thanks. Apparently the "Ubuntu Software Center" does not show that when 
you do a search for "colord" but it shows up if you search for 
"libcolord"... Strange that this worked for finding development files at 
other times.



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

Re: [PATCH 0/3] Fix screenshooter/recorder for scale

[Kristian Høgsberg]

On Wed, May 29, 2013 at 12:01:31PM +0200, al...@redhat.com wrote:
> From: Alexander Larsson 
> 
> The actual fix for output scale is trivial, but I needed
> two fixes to get screenshooting to work with the pixman
> renderer.

Thanks, all applied.

Kristian

> Alexander Larsson (3):
>   screenshoter: Make recorder handle PIXMAN_x8r8g8b8
>   pixman-renderer: Fix read_pixels for screen recorder
>   screenshooter: Scale damage by output scale in screen recorder
> 
>  src/pixman-renderer.c | 33 -
>  src/screenshooter.c   |  6 ++
>  2 files changed, 26 insertions(+), 13 deletions(-)
> 
> -- 
> 1.8.1.4
> 
> ___
> 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 2/9] input: Fix possible crash in clip_pointer_motion

[Kristian Høgsberg]

On Wed, May 29, 2013 at 09:25:33AM +0200, Alexander Larsson wrote:
> On tis, 2013-05-28 at 17:25 -0400, Kristian Høgsberg wrote:
> > On Tue, May 28, 2013 at 04:23:33PM +0200, al...@redhat.com wrote:
> > > From: Alexander Larsson 
> > > 
> > > It was erronously using output->current->height in one
> > > place where it should use output->height. This may cause
> > > it to create an invalid clipped coordinate in case of output
> > > scaling or transform, because the next round "prev" would
> > > end up NULL.
> > 
> > This an remaining patches look good.  The policy change in case of
> > switching away from a DRIVER fullscreen buffer, is fine, it was always
> > a bit rough the way it worked before.
> 
> You applied the weston side, but not the corresponding protocol side:
> 
> http://lists.freedesktop.org/archives/wayland-devel/2013-May/009498.html

I forgot to push wayland, done now.

Kristian

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

Re: [PATCH 1/9] shell: Position DRIVER fullscreen surfaces at origin

[Kristian Høgsberg]

On Wed, May 29, 2013 at 09:20:25AM +0200, Alexander Larsson wrote:
> On tis, 2013-05-28 at 16:10 -0400, Kristian Høgsberg wrote:
> > On Tue, May 28, 2013 at 04:23:32PM +0200, al...@redhat.com wrote:
> > > From: Alexander Larsson 
> > > 
> > > When a window is fullscreened with DRIVER method and we succeeded
> > > in changing mode we need to actually move the surface to the
> > > origin of the output, or it won't be used for scanout.
> > > ---
> > >  src/shell.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > > 
> > > diff --git a/src/shell.c b/src/shell.c
> > > index 1443328..07be564 100644
> > > --- a/src/shell.c
> > > +++ b/src/shell.c
> > > @@ -1802,6 +1802,9 @@ shell_configure_fullscreen(struct shell_surface 
> > > *shsurf)
> > >   shsurf->fullscreen.framerate};
> > >  
> > >   if (weston_output_switch_mode(output, &mode) == 0) {
> > > + weston_surface_set_position(surface,
> > > + output->x - 
> > > surf_x,
> > > + output->y - 
> > > surf_y);
> > >   
> > > weston_surface_configure(shsurf->fullscreen.black_surface,
> > >output->x - surf_x,
> > >output->y - surf_y,
> > 
> > Is that not done by this weston_surface_configure() call?
> 
> No, they apply to different surfaces, one the client surface, the other
> the black surface.

Right, thanks, I knew I was missing something.  Committed.

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

[PATCH 3/3] screenshooter: Scale damage by output scale in screen recorder

[alexl]

From: Alexander Larsson 

The damage region is in compositor coords, we need to scale it by
the output scale when using the damage to read output buffer data.
---
 src/screenshooter.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/screenshooter.c b/src/screenshooter.c
index d088cf7..83ad192 100644
--- a/src/screenshooter.c
+++ b/src/screenshooter.c
@@ -330,6 +330,11 @@ transform_rect(struct weston_output *output, 
pixman_box32_t *r)
 default:
 break;
 }
+
+   r->x1 *= output->scale;
+   r->y1 *= output->scale;
+   r->x2 *= output->scale;
+   r->y2 *= output->scale;
 }
 
 static void
-- 
1.8.1.4

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

[PATCH 2/3] pixman-renderer: Fix read_pixels for screen recorder

[alexl]

From: Alexander Larsson 

The old code had an off-by-one error on the y coordinate
where it says height - (cur_y - y). And it does the vflipping of
the *destination* buffer, whereas what is really needed is to
vflip the whole source buffer. This only affects when you read
out part of the image, such as when using the screen recoder.

Also, instead of doing the flipping manually we just let pixman
handle it.
---
 src/pixman-renderer.c | 33 -
 1 file changed, 20 insertions(+), 13 deletions(-)

diff --git a/src/pixman-renderer.c b/src/pixman-renderer.c
index ba7cb43..2c42390 100644
--- a/src/pixman-renderer.c
+++ b/src/pixman-renderer.c
@@ -72,8 +72,8 @@ pixman_renderer_read_pixels(struct weston_output *output,
   uint32_t width, uint32_t height)
 {
struct pixman_output_state *po = get_output_state(output);
+   pixman_transform_t transform;
pixman_image_t *out_buf;
-   uint32_t cur_y;
 
if (!po->hw_buffer) {
errno = ENODEV;
@@ -86,18 +86,25 @@ pixman_renderer_read_pixels(struct weston_output *output,
pixels,
(PIXMAN_FORMAT_BPP(format) / 8) * width);
 
-   /* Caller expects vflipped image */
-   for (cur_y = y; cur_y < y + height; cur_y++) {
-   pixman_image_composite32(PIXMAN_OP_SRC,
-   po->hw_buffer, /* src */
-   NULL /* mask */,
-   out_buf, /* dest */
-   x, cur_y, /* src_x, src_y */
-   0, 0, /* mask_x, mask_y */
-   0, height - (cur_y - y), /* dest_x, dest_y */
-   width, /* width */
-   1 /* height */);
-   }
+   /* Caller expects vflipped source image */
+   pixman_transform_init_translate(&transform,
+   pixman_int_to_fixed (x),
+   pixman_int_to_fixed (y - 
pixman_image_get_height (po->hw_buffer)));
+   pixman_transform_scale(&transform, NULL,
+  pixman_fixed_1,
+  pixman_fixed_minus_1);
+   pixman_image_set_transform(po->hw_buffer, &transform);
+
+   pixman_image_composite32(PIXMAN_OP_SRC,
+po->hw_buffer, /* src */
+NULL /* mask */,
+out_buf, /* dest */
+0, 0, /* src_x, src_y */
+0, 0, /* mask_x, mask_y */
+0, 0, /* dest_x, dest_y */
+pixman_image_get_width (po->hw_buffer), /* 
width */
+pixman_image_get_height (po->hw_buffer) /* 
height */);
+   pixman_image_set_transform(po->hw_buffer, NULL);
 
pixman_image_unref(out_buf);
 
-- 
1.8.1.4

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

[PATCH 1/3] screenshoter: Make recorder handle PIXMAN_x8r8g8b8

[alexl]

From: Alexander Larsson 

This is what the pixman renderer reports for the read format.
---
 src/screenshooter.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/screenshooter.c b/src/screenshooter.c
index dde052f..d088cf7 100644
--- a/src/screenshooter.c
+++ b/src/screenshooter.c
@@ -465,6 +465,7 @@ weston_recorder_create(struct weston_output *output, const 
char *filename)
header.magic = WCAP_HEADER_MAGIC;
 
switch (compositor->read_format) {
+   case PIXMAN_x8r8g8b8:
case PIXMAN_a8r8g8b8:
header.format = WCAP_FORMAT_XRGB;
break;
-- 
1.8.1.4

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

[PATCH 0/3] Fix screenshooter/recorder for scale

[alexl]

From: Alexander Larsson 

The actual fix for output scale is trivial, but I needed
two fixes to get screenshooting to work with the pixman
renderer.

Alexander Larsson (3):
  screenshoter: Make recorder handle PIXMAN_x8r8g8b8
  pixman-renderer: Fix read_pixels for screen recorder
  screenshooter: Scale damage by output scale in screen recorder

 src/pixman-renderer.c | 33 -
 src/screenshooter.c   |  6 ++
 2 files changed, 26 insertions(+), 13 deletions(-)

-- 
1.8.1.4

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

Re: [PATCH 00/15] weston scaling support

[Alexander Larsson]

On tis, 2013-05-28 at 18:33 -0700, Bill Spitzak wrote:
> On 05/28/2013 06:40 AM, Pekka Paalanen wrote:
> 
> > If you really need an output scaling factor like 1.5, then you report it
> > as either 1 or 2, and do a compensating scaling in the compositor to
> > achieve 1.5. That is the best compromize I can imagine, since to be
> > honest, 1.5 does not work for the protocol nor the clients' rendering.
> 
> Then it is impossible for the client to render 1:1 with this output's 
> pixels. All it can do is set the scale to 1 and have it scaled up by 1.5 
> to get the output pixels, or set the scale to 2 and have it scaled down 
> to .75 to get the pixels.
> 
> I don't think you can avoid non-integer scaling. What happens if a 
> client says it's scale is 3 and the output has a scale of 2? This is not 
> just hypothetical, it will certainly happen if there is both a scale 3 
> and scale 2 output on the device.

Yes, the actual scaling that the compositor has to apply from the buffer
to a given output may be fractional. However, the scaling factor between
the buffer and the surface (i.e. in pels or in global compositor
relative sizes) is an integer. This means that any integer position in
surface space corresponds to an integer in buffer space, so for instance
a pixman region (in ints) damage or clip region in surface space
corresponds to an exact pixman region in buffer coordinates. And, this
is the transformation that the compositor really cares about internally
(e.g. for input scaling, clipping, dirty tracking, etc) rather than the
final drawing translation.


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

Re: [PATCH 2/9] input: Fix possible crash in clip_pointer_motion

[Alexander Larsson]

On tis, 2013-05-28 at 17:25 -0400, Kristian Høgsberg wrote:
> On Tue, May 28, 2013 at 04:23:33PM +0200, al...@redhat.com wrote:
> > From: Alexander Larsson 
> > 
> > It was erronously using output->current->height in one
> > place where it should use output->height. This may cause
> > it to create an invalid clipped coordinate in case of output
> > scaling or transform, because the next round "prev" would
> > end up NULL.
> 
> This an remaining patches look good.  The policy change in case of
> switching away from a DRIVER fullscreen buffer, is fine, it was always
> a bit rough the way it worked before.

You applied the weston side, but not the corresponding protocol side:

http://lists.freedesktop.org/archives/wayland-devel/2013-May/009498.html

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

Re: [PATCH 1/9] shell: Position DRIVER fullscreen surfaces at origin

[Alexander Larsson]

On tis, 2013-05-28 at 16:10 -0400, Kristian Høgsberg wrote:
> On Tue, May 28, 2013 at 04:23:32PM +0200, al...@redhat.com wrote:
> > From: Alexander Larsson 
> > 
> > When a window is fullscreened with DRIVER method and we succeeded
> > in changing mode we need to actually move the surface to the
> > origin of the output, or it won't be used for scanout.
> > ---
> >  src/shell.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/src/shell.c b/src/shell.c
> > index 1443328..07be564 100644
> > --- a/src/shell.c
> > +++ b/src/shell.c
> > @@ -1802,6 +1802,9 @@ shell_configure_fullscreen(struct shell_surface 
> > *shsurf)
> >   shsurf->fullscreen.framerate};
> >  
> >   if (weston_output_switch_mode(output, &mode) == 0) {
> > + weston_surface_set_position(surface,
> > + output->x - 
> > surf_x,
> > + output->y - 
> > surf_y);
> >   
> > weston_surface_configure(shsurf->fullscreen.black_surface,
> >output->x - surf_x,
> >output->y - surf_y,
> 
> Is that not done by this weston_surface_configure() call?

No, they apply to different surfaces, one the client surface, the other
the black surface.



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