Re: [PATCH] wl_resource: Add version field and getter/setter

2013-05-24 Thread Alexander Larsson 
On tor, 2013-05-23 at 15:54 -0500, Jason Ekstrand wrote:
> 
> 
> wl_signal_get might be better here.  It's more robust in (somewhat
> odd) case the user code decides to manually put a listener at the
> beginning.  It's also more readable and almost just as fast (different
> by an if).

Yeah, sure, thats probably better.

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

Re: [PATCH] wayland-server: Version check requests

2013-05-24 Thread Alexander Larsson 
On tor, 2013-05-23 at 15:58 -0500, Jason Ekstrand wrote:
> 
> On Thu, May 23, 2013 at 3:20 PM,  wrote:
> From: Alexander Larsson 
> 
> If an interface has any messages and its version is larger
> than 1
> then we emit a method counts array which lists the number of
> methods
> for each version of the interface. This can be used in
> addition
> to the normal method_count to reject requests that the
> server doesn't support. This allows the wayland server library
> to be upgraded and still safely run oler compositors that
> don't
> implement the new requests.
> 
> Since there is no other space in the wm_interface we add the
> method count array at the end of the events array. We then
> add some warnings to the event sending code so that we never
> accidentally trigger these events.
> 
> 
> Would it possibly be better to use the upper bits of method_count (or
> method_count < 0) to signal that a method_counts array is appended to
> methods?  This keeps methods with methods and also allows us to
> optionally do the same thing with events client-side to protect
> clients from broken newer-version compositors.

It depends on what kind of guarantees we want to make. My hack is 100%
backwards compatible in that a library that generates protocol
descriptions using the scanner will still work with an older
libwayland-server. If the scanner starts producing method_counts with
the high bit set then old versions of libwayland-server will handle
these as if there was a lot of methods and break the check for invalid
requests.

Of course, for the case of the core wayland protocol this is not a
problem as they are in the same library as the dispatcher. However, one
could imagine e.g. weston or libEGL being built with a newer version of
scanner and then deployed on an older libwayland-server. Or we could
just ignore this case...


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

[PATCH 0/2] resource versioning V3

2013-05-24 Thread alexl 
From: Alexander Larsson 

New in this version:
* We look up the private with wl_signal_get
* Fixed off-by-one error in method_counts array lookup
  (version 1 is at offset 0)

Alexander Larsson (2):
  wl_resource: Add version field and getter/setter
  wayland-server: Version check requests

 src/scanner.c|  54 
 src/wayland-server.c | 100 +--
 src/wayland-server.h |   6 
 3 files changed, 151 insertions(+), 9 deletions(-)

-- 
1.8.1.4

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

[PATCH 1/2] wl_resource: Add version field and getter/setter

2013-05-24 Thread alexl 
From: Alexander Larsson 

We create a private structure for extra data and store it in
a destroy notifier. In this way we can store the version
in a backwards compatible way.

This lets us track the actual version of a resource which
is generally the min of what the client requested and what
the server supports. This will let us avoid sending messages
the client doesn't support and to not handle requests the
server doesn't support.
---
 src/wayland-server.c | 66 +++-
 src/wayland-server.h |  6 +
 2 files changed, 71 insertions(+), 1 deletion(-)

diff --git a/src/wayland-server.c b/src/wayland-server.c
index a3d3887..4604008 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -102,6 +102,11 @@ struct wl_global {
struct wl_list link;
 };
 
+struct wl_resource_private {
+   struct wl_listener listener;
+   uint32_t version;
+};
+
 static int wl_debug = 0;
 
 static void
@@ -373,10 +378,28 @@ wl_client_get_credentials(struct wl_client *client,
*gid = client->ucred.gid;
 }
 
+static void
+resource_private_notify(struct wl_listener *listener, void *data)
+{
+   struct wl_resource *resource = data;
+   struct wl_resource_private *priv = (struct wl_resource_private 
*)listener;
+
+   if (priv != (struct wl_resource_private *)(resource + 1))
+   free (priv);
+}
+
 WL_EXPORT uint32_t
 wl_client_add_resource(struct wl_client *client,
   struct wl_resource *resource)
 {
+   struct wl_resource_private *priv;
+
+   priv = calloc(1, sizeof(struct wl_resource_private));
+   if (!priv) {
+   wl_resource_post_no_memory(resource);
+   return 0;
+   }
+
if (resource->object.id == 0) {
resource->object.id =
wl_map_insert_new(&client->objects,
@@ -387,12 +410,18 @@ wl_client_add_resource(struct wl_client *client,
   WL_DISPLAY_ERROR_INVALID_OBJECT,
   "invalid new id %d",
   resource->object.id);
+   free(priv);
return 0;
}
 
resource->client = client;
wl_signal_init(&resource->destroy_signal);
 
+   priv->listener.notify = resource_private_notify;
+   wl_signal_add(&resource->destroy_signal, &priv->listener);
+
+   priv->version = 1;
+
return resource->object.id;
 }
 
@@ -895,6 +924,33 @@ wl_display_get_destroy_listener(struct wl_display *display,
return wl_signal_get(&display->destroy_signal, notify);
 }
 
+static struct wl_resource_private *
+wl_resource_get_priv (struct wl_resource *resource)
+{
+   return (struct wl_resource_private *)
+   wl_signal_get(&resource->destroy_signal, 
resource_private_notify);
+}
+
+WL_EXPORT void
+wl_resource_set_version(struct wl_resource *resource,
+   uint32_t version)
+{
+   struct wl_resource_private *priv = wl_resource_get_priv (resource);
+
+   /* We don't want anything to set this to 0, as that will cause us
+  to look before the start of the method_counts array */
+   if (version >= 1)
+   priv->version = version;
+}
+
+WL_EXPORT uint32_t
+wl_resource_get_version(struct wl_resource *resource)
+{
+   struct wl_resource_private *priv = wl_resource_get_priv (resource);
+
+   return priv->version;
+}
+
 WL_EXPORT struct wl_resource *
 wl_client_add_object(struct wl_client *client,
 const struct wl_interface *interface,
@@ -902,8 +958,9 @@ wl_client_add_object(struct wl_client *client,
 uint32_t id, void *data)
 {
struct wl_resource *resource;
+   struct wl_resource_private *priv;
 
-   resource = malloc(sizeof *resource);
+   resource = malloc(sizeof *resource + sizeof (struct 
wl_resource_private));
if (resource == NULL) {
wl_resource_post_no_memory(client->display_resource);
return NULL;
@@ -913,6 +970,13 @@ wl_client_add_object(struct wl_client *client,
resource->client = client;
resource->destroy = (void *) free;
 
+   priv = (struct wl_resource_private *)(resource + 1);
+
+   priv->listener.notify = resource_private_notify;
+   wl_signal_add(&resource->destroy_signal, &priv->listener);
+
+   priv->version = 1;
+
if (wl_map_insert_at(&client->objects, resource->object.id, resource) < 
0) {
wl_resource_post_error(client->display_resource,
   WL_DISPLAY_ERROR_INVALID_OBJECT,
diff --git a/src/wayland-server.h b/src/wayland-server.h
index a9cf544..6beb0dd 100644
--- a/src/wayland-server.h
+++ b/src/wayland-server.h
@@ -135,6 +135,12 @@ wl_client_new_object(struct wl_client *client,
 struct wl_resource *
 wl_client_get_object(struct wl_client *client, uint32_t id);
 
+void
+wl_resource_set_version(struct wl_resource *

[PATCH 2/2] wayland-server: Version check requests

2013-05-24 Thread alexl 
From: Alexander Larsson 

If an interface has any messages and its version is larger than 1
then we emit a method counts array which lists the number of methods
for each version of the interface. This can be used in addition
to the normal method_count to reject requests that the
server doesn't support. This allows the wayland server library
to be upgraded and still safely run oler compositors that don't
implement the new requests.

Since there is no other space in the wm_interface we add the
method count array at the end of the events array. We then
add some warnings to the event sending code so that we never
accidentally trigger these events.

Then we add code in the server to reject messages that are not
supported by the server version of the object they are sent to.
---
 src/scanner.c| 54 ++--
 src/wayland-server.c | 34 +++--
 2 files changed, 80 insertions(+), 8 deletions(-)

diff --git a/src/scanner.c b/src/scanner.c
index 9c14ad3..38e7909 100644
--- a/src/scanner.c
+++ b/src/scanner.c
@@ -1019,12 +1019,13 @@ emit_types(struct protocol *protocol, struct wl_list 
*message_list)
 
 static void
 emit_messages(struct wl_list *message_list,
- struct interface *interface, const char *suffix)
+ struct interface *interface, const char *suffix,
+ int emit_method_counts)
 {
struct message *m;
struct arg *a;
 
-   if (wl_list_empty(message_list))
+   if (wl_list_empty(message_list) && !emit_method_counts)
return;
 
printf("static const struct wl_message "
@@ -1070,13 +1071,52 @@ emit_messages(struct wl_list *message_list,
printf("\", types + %d },\n", m->type_index);
}
 
+   if (emit_method_counts) {
+   printf("\t{ NULL, \"\", (void *)%s_method_counts },\n", 
interface->name);
+   }
+
+   printf("};\n\n");
+}
+
+static int
+emit_method_counts(struct wl_list *message_list,
+  struct interface *interface)
+{
+   struct message *m;
+   int version = 1;
+   int count;
+
+   if (wl_list_empty(message_list) || interface->version == 1)
+   return 0;
+
+   printf("static const uint32_t "
+  "%s_method_counts[] = { ",
+  interface->name);
+
+   count = 0;
+   wl_list_for_each(m, message_list, link) {
+   while (m->since != version) {
+   printf("%d,", count);
+   version++;
+   }
+   count++;
+   }
+
+   while (version <= interface->version) {
+   printf("%d, ", count);
+   version++;
+   }
+
printf("};\n\n");
+
+   return 1;
 }
 
 static void
 emit_code(struct protocol *protocol)
 {
struct interface *i;
+   int has_method_counts;
 
if (protocol->copyright)
format_copyright(protocol->copyright);
@@ -1101,8 +1141,10 @@ emit_code(struct protocol *protocol)
 
wl_list_for_each(i, &protocol->interface_list, link) {
 
-   emit_messages(&i->request_list, i, "requests");
-   emit_messages(&i->event_list, i, "events");
+
+   emit_messages(&i->request_list, i, "requests", 0);
+   has_method_counts = emit_method_counts(&i->request_list, i);
+   emit_messages(&i->event_list, i, "events", has_method_counts);
 
printf("WL_EXPORT const struct wl_interface "
   "%s_interface = {\n"
@@ -1115,9 +1157,9 @@ emit_code(struct protocol *protocol)
else
printf("\t0, NULL,\n");
 
-   if (!wl_list_empty(&i->event_list))
+   if (!wl_list_empty(&i->event_list) || has_method_counts)
printf("\t%d, %s_events,\n",
-  wl_list_length(&i->event_list), i->name);
+  wl_list_length(&i->event_list) + 
has_method_counts, i->name);
else
printf("\t0, NULL,\n");
 
diff --git a/src/wayland-server.c b/src/wayland-server.c
index 4604008..a82707a 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -124,6 +124,12 @@ wl_resource_post_event(struct wl_resource *resource, 
uint32_t opcode, ...)
struct wl_object *object = &resource->object;
va_list ap;
 
+   if (opcode >= (uint32_t)object->interface->event_count ||
+   object->interface->events[opcode].name == NULL) {
+   wl_log ("Trying to post unsupported event\n");
+   return;
+   }
+
va_start(ap, opcode);
closure = wl_closure_vmarshal(object, opcode, ap,
  &object->interface->events[opcode]);
@@ -150,6 +156,12 @@ wl_resource_queue_event(struct wl_resource *resource, 
uint32_t opcode, ...)
struct wl_object *object = &resource->object;
va_list ap;
 
+

[PATCH] window: Bind to version 3 of compositor

2013-05-24 Thread alexl 
From: Alexander Larsson 

We need version 3 of the compositor to get version 3 of wl_surface
which has set_buffer_transform and set_buffer_scale.
---
 clients/window.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/clients/window.c b/clients/window.c
index b2e1af7..8e49f22 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -4749,7 +4749,7 @@ registry_handle_global(void *data, struct wl_registry 
*registry, uint32_t id,
 
if (strcmp(interface, "wl_compositor") == 0) {
d->compositor = wl_registry_bind(registry, id,
-&wl_compositor_interface, 1);
+&wl_compositor_interface, 3);
} else if (strcmp(interface, "wl_output") == 0) {
display_add_output(d, id);
} else if (strcmp(interface, "wl_seat") == 0) {
-- 
1.8.1.4

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

Re: [PATCH 2/2] protocol: Support scaled outputs and surfaces

2013-05-24 Thread Pekka Paalanen 
On Thu, 23 May 2013 14:51:16 -0400 (EDT)
Alexander Larsson  wrote:

> > What if a client sets scale=0?
> 
> I guess we should forbid that, as it risks things dividing by zero.
> 
> > Maybe the scale should also be signed here? I think all sizes are
> > signed, too, even though a negative size does not make sense. We seem
> > to have a convention, that numbers you compute with are signed, and
> > enums and flags and bitfields and handles and such are unsigned. And
> > timestamps, since there we need the overflow behaviour. I
> > believe it's due to the C promotion or implicit cast rules more than
> > anything else.
> 
> Yeah, we should change it to signed.
> 
> > > @@ -1548,6 +1596,8 @@
> > >summary="indicates this is the current mode"/>
> > > > >summary="indicates this is the preferred mode"/>
> > > +   > > +  summary="indicates that this is a scaled mode"/>
> > 
> > What do we need the "scaled" flag for? And what does this flag mean?
> > How is it used? I mean, can we get duplicate native modes that differ
> > only by the scaled flag?
> > 
> > Unfortunately I didn't get to answer that thread before, but I had some
> > disagreement or not understanding there.
> 
> Yeah, this is the area of the scaling stuff that is least baked. 
> 
> Right now what happens is that the modes get listed at the scaled resolution
> (i.e. divided by to two, etc), and such scaled mode gets reported with a bit
> set so client can tell they are not native size. However, this doesn't seem
> quite right for a few reasons:
> 
> * We don't report rotated/flipped modes, nor do we swap the width/height for
>   these so this is inconsistent
> * The clients can tell what the scale is anyway, so what use is it?
> 
> However, listing the unscaled resolution for the modes is also somewhat
> problematic. For instance, if we listed the raw modes and an app wanted
> to go fullscreen in a mode it would need to create a surface of the scaled
> width/heigh (with the right scale), as otherwise the buffer size would not
> match the scanout size. 
> 
> For instance, if the output scale is 2 and there is a 800x600 native mode
> then the app should use a 400x300 surface with a 800x600 buffer and a 
> buffer_scale of 2.
> 
> Hmmm, I guess if the app used a 800x600 surface with buffer scale 1 we could 
> still
> scan out from it. Although we'd have to be very careful about how we treat
> input and pointer position then, as its not quite the same.
> 
> I'll have a look at changing this.

I agree with all that. There are some more considerations. One is
the wl_shell_surface.geometry event. If you look at the specification
of wl_shell_surface.set_fullscreen, it requires the compositor to reply
with a geometry event with the dimensions to make the surface
fullscreen in the current native video mode. Since that is in pels
like John pointed out, it would carry 400x300 for a 800x600 mode, if
output_scale=2. I haven't read enough of the patches to see how you
handled that.

An old application not knowing about buffer_scale would simply use
400x300, and get scaled up. All good. Might even be scanned out
directly, if an overlay allows hardware scaling.

An old application looking at the mode list could pick the 800x600
mode, and use that with the implicit scale 1. Because fullscreen state
specifies, that the compositor makes the surface fullscreen, and allows
e.g. scaling, we can as well just simply scan it out.

The difference between these two cases is the surface size in pels,
400x300 in the former, and 800x600 in the latter. No problem for the
client. In the server we indeed need to make sure the input coordinates
are right.

An issue I see here is that the 800x600 buffer_scale=1 fullscreen setup
will have the very problem the whole output scale is trying to solve:
the application will draw its GUI in single-density, and it ends up 1:1
on a double-density screen, unreadable. However, if the application is
using the mode list to begin with, it probably has a way for the user
to pick a mode. So with a magnifying glass, the user can fix the
situation in the application settings. Cue in Weston desktop zoom...

Now, should we require, that applications that have a video mode menu,
will also have an entry called "default" or "native", which will come
from the geometry event?

If not, do we need to make sure there are output modes listed that match
exactly mode*output_scale == default native mode, and fake a new mode as
needed? Do we need that for all native modes, in case the default mode
changes?

Or maybe we don't need any of that, if we assume the user can configure
the application to use an arbitrary "mode"?

I'm thinking about an application (game), that renders in pixel units,
and only offers the user a choice between the server reported output
video modes. Is that an important use case?

If the application is output_scale/buffer_scale aware, it knows how to
do the right thing, even if it chooses a mode from the output mode
list

Re: [PATCH] Avoid unnecessarily re-allocating texture buffer when the size hasn't changed.

2013-05-24 Thread Pekka Paalanen 
On Thu, 23 May 2013 13:18:29 -0700
Sinclair Yeh  wrote:

> v2:
> Fixed the wrong comparison
> 
> v1:
> Depending on specific DRI driver implementation, glTexImage2D() with data
> set to NULL may or may not re-allocate the texture buffer each time it is
> called.  Unintended consequences happen if later glTexSubImage2D() is called
> to only update a sub-region of the texture buffer.
> 
> I've explored moving glTexImage2D() from gl_renderer_attach() and simply
> mark the texture dirty, but the current implemention seems cleaner because
> I won't have to worry about calling ensure_textures() and re-assigning
> gs->shader unnecessarily.
> ---
>  src/gl-renderer.c |   32 
>  1 files changed, 20 insertions(+), 12 deletions(-)
> 
> diff --git a/src/gl-renderer.c b/src/gl-renderer.c
> index be74eba..c508825 100644
> --- a/src/gl-renderer.c
> +++ b/src/gl-renderer.c
> @@ -68,6 +68,7 @@ struct gl_surface_state {
>  
>   struct weston_buffer_reference buffer_ref;
>   int pitch; /* in pixels */
> + int height;
>  };
>  
>  struct gl_renderer {
> @@ -1213,18 +1214,24 @@ gl_renderer_attach(struct weston_surface *es, struct 
> wl_buffer *buffer)
>   }
>  
>   if (wl_buffer_is_shm(buffer)) {
> - gs->pitch = wl_shm_buffer_get_stride(buffer) / 4;
> - gs->target = GL_TEXTURE_2D;
> -
> - ensure_textures(gs, 1);
> - glBindTexture(GL_TEXTURE_2D, gs->textures[0]);
> - glTexImage2D(GL_TEXTURE_2D, 0, GL_BGRA_EXT,
> -  gs->pitch, buffer->height, 0,
> -  GL_BGRA_EXT, GL_UNSIGNED_BYTE, NULL);
> - if (wl_shm_buffer_get_format(buffer) == WL_SHM_FORMAT_XRGB)
> - gs->shader = &gr->texture_shader_rgbx;
> - else
> - gs->shader = &gr->texture_shader_rgba;
> + /* Only allocate a texture if it doesn't match existing one */
> + if (((wl_shm_buffer_get_stride(buffer) / 4) != gs->pitch) ||
> + (buffer->height != gs->height)) {
> + gs->pitch = wl_shm_buffer_get_stride(buffer) / 4;
> + gs->height = buffer->height;
> + gs->target = GL_TEXTURE_2D;
> +
> + ensure_textures(gs, 1);
> + glBindTexture(GL_TEXTURE_2D, gs->textures[0]);
> + glTexImage2D(GL_TEXTURE_2D, 0, GL_BGRA_EXT,
> +  gs->pitch, buffer->height, 0,
> +  GL_BGRA_EXT, GL_UNSIGNED_BYTE, NULL);
> + if (wl_shm_buffer_get_format(buffer) ==
> + WL_SHM_FORMAT_XRGB)
> + gs->shader = &gr->texture_shader_rgbx;
> + else
> + gs->shader = &gr->texture_shader_rgba;
> + }
>   } else if (gr->query_buffer(gr->egl_display, buffer,
>   EGL_TEXTURE_FORMAT, &format)) {
>   for (i = 0; i < gs->num_images; i++)
> @@ -1279,6 +1286,7 @@ gl_renderer_attach(struct weston_surface *es, struct 
> wl_buffer *buffer)
>   }
>  
>   gs->pitch = buffer->width;
> + gs->height = buffer->height;
>   } else {
>   weston_log("unhandled buffer type!\n");
>   weston_buffer_reference(&gs->buffer_ref, NULL);

Seems fine to me.


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

[PATCH] protocol: Use signed int for scale values

2013-05-24 Thread alexl 
From: Alexander Larsson 

We usually use signed ints for things like this, to avoid
issues C sign coersion.
---
 protocol/wayland.xml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index acfb140..0c7c053 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -1155,7 +1155,7 @@
a buffer that is larger (by a factor of scale in each dimension)
than the desired surface size.
   
-  
+  
 

 
@@ -1652,7 +1652,7 @@
avoid scaling the surface, and the client can supply
a higher detail image.
   
-  
+  
 
   
 
-- 
1.8.1.4

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

[PATCH] Convert all scales to int32_t

2013-05-24 Thread alexl 
From: Alexander Larsson 

The type changed in the protocol, so update weston for this.
---
 clients/desktop-shell.c |  2 +-
 clients/window.c| 24 
 clients/window.h|  2 +-
 src/compositor-x11.c|  4 ++--
 src/compositor.c| 12 ++--
 src/compositor.h| 14 +++---
 6 files changed, 29 insertions(+), 29 deletions(-)

diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c
index 40dd1dd..51ce3ec 100644
--- a/clients/desktop-shell.c
+++ b/clients/desktop-shell.c
@@ -1115,7 +1115,7 @@ output_handle_done(void *data,
 static void
 output_handle_scale(void *data,
 struct wl_output *wl_output,
-uint32_t scale)
+int32_t scale)
 {
struct output *output = data;
 
diff --git a/clients/window.c b/clients/window.c
index b2e1af7..3870898 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -159,7 +159,7 @@ struct toysurface {
 */
cairo_surface_t *(*prepare)(struct toysurface *base, int dx, int dy,
int32_t width, int32_t height, uint32_t 
flags,
-   enum wl_output_transform buffer_transform, 
uint32_t buffer_scale);
+   enum wl_output_transform buffer_transform, 
int32_t buffer_scale);
 
/*
 * Post the surface to the server, returning the server allocation
@@ -167,7 +167,7 @@ struct toysurface {
 * after calling this.
 */
void (*swap)(struct toysurface *base,
-enum wl_output_transform buffer_transform, uint32_t 
buffer_scale,
+enum wl_output_transform buffer_transform, int32_t 
buffer_scale,
 struct rectangle *server_allocation);
 
/*
@@ -210,7 +210,7 @@ struct surface {
 
enum window_buffer_type buffer_type;
enum wl_output_transform buffer_transform;
-   uint32_t buffer_scale;
+   int32_t buffer_scale;
 
cairo_surface_t *cairo_surface;
 
@@ -468,7 +468,7 @@ debug_print(void *proxy, int line, const char *func, const 
char *fmt, ...)
 #endif
 
 static void
-surface_to_buffer_size (enum wl_output_transform buffer_transform, uint32_t 
buffer_scale, int32_t *width, int32_t *height)
+surface_to_buffer_size (enum wl_output_transform buffer_transform, int32_t 
buffer_scale, int32_t *width, int32_t *height)
 {
int32_t tmp;
 
@@ -490,7 +490,7 @@ surface_to_buffer_size (enum wl_output_transform 
buffer_transform, uint32_t buff
 }
 
 static void
-buffer_to_surface_size (enum wl_output_transform buffer_transform, uint32_t 
buffer_scale, int32_t *width, int32_t *height)
+buffer_to_surface_size (enum wl_output_transform buffer_transform, int32_t 
buffer_scale, int32_t *width, int32_t *height)
 {
int32_t tmp;
 
@@ -531,7 +531,7 @@ to_egl_window_surface(struct toysurface *base)
 static cairo_surface_t *
 egl_window_surface_prepare(struct toysurface *base, int dx, int dy,
   int32_t width, int32_t height, uint32_t flags,
-  enum wl_output_transform buffer_transform, uint32_t 
buffer_scale)
+  enum wl_output_transform buffer_transform, int32_t 
buffer_scale)
 {
struct egl_window_surface *surface = to_egl_window_surface(base);
 
@@ -545,7 +545,7 @@ egl_window_surface_prepare(struct toysurface *base, int dx, 
int dy,
 
 static void
 egl_window_surface_swap(struct toysurface *base,
-   enum wl_output_transform buffer_transform, uint32_t 
buffer_scale,
+   enum wl_output_transform buffer_transform, int32_t 
buffer_scale,
struct rectangle *server_allocation)
 {
struct egl_window_surface *surface = to_egl_window_surface(base);
@@ -1017,7 +1017,7 @@ static const struct wl_buffer_listener 
shm_surface_buffer_listener = {
 static cairo_surface_t *
 shm_surface_prepare(struct toysurface *base, int dx, int dy,
int32_t width, int32_t height, uint32_t flags,
-   enum wl_output_transform buffer_transform, uint32_t 
buffer_scale)
+   enum wl_output_transform buffer_transform, int32_t 
buffer_scale)
 {
int resize_hint = !!(flags & SURFACE_HINT_RESIZE);
struct shm_surface *surface = to_shm_surface(base);
@@ -1095,7 +1095,7 @@ out:
 
 static void
 shm_surface_swap(struct toysurface *base,
-enum wl_output_transform buffer_transform, uint32_t 
buffer_scale,
+enum wl_output_transform buffer_transform, int32_t 
buffer_scale,
 struct rectangle *server_allocation)
 {
struct shm_surface *surface = to_shm_surface(base);
@@ -1457,7 +1457,7 @@ window_set_buffer_transform(struct window *window,
 
 void
 window_set_buffer_scale(struct window *window,
-   uint32_t scale)
+   int32_t scale)
 {
window->main_surface->buffer_scale = scale;

Re: [RFC] libinputmapper: Input device configuration for graphic-servers

2013-05-24 Thread David Herrmann 
Hi

On Thu, May 23, 2013 at 7:32 AM, Peter Hutterer
 wrote:
> On Tue, May 21, 2013 at 04:30:03PM +0200, David Herrmann wrote:
>> Hi Peter
>>
>> On Tue, May 21, 2013 at 6:37 AM, Peter Hutterer
>>  wrote:
>> > On Thu, May 16, 2013 at 03:16:11PM +0200, David Herrmann wrote:
>> >> Hi Peter
>> >>
>> >> On Thu, May 16, 2013 at 7:37 AM, Peter Hutterer
>> >>  wrote:
>> >> > On Sun, May 12, 2013 at 04:20:59PM +0200, David Herrmann wrote:
>> >> [..]
>> >> >> So what is the proposed solution?
>> >> >> My recommendation is, that compositors still search for devices via
>> >> >> udev and use device drivers like libxkbcommon. So linux evdev handling
>> >> >> is still controlled by the compositor. However, I'd like to see
>> >> >> something like my libinputmapper proposal being used for device
>> >> >> detection and classification.
>> >> >>
>> >> >> libinputmapper provides an "inmap_evdev" object which reads device
>> >> >> information from an evdev-fd or sysfs /sys/class/input/input
>> >> >> path, performs some heuristics to classify it and searches it's global
>> >> >> database for known fixups for broken devices.
>> >> >> It then provides "capabilities" to the caller, which allow them to see
>> >> >> what drivers to load on the device. And it provides a very simple
>> >> >> mapping table that allows to apply fixup mappings for broken devices.
>> >> >> These mappings are simple 1-to-1 mappings that are supposed to be
>> >> >> applied before drivers handle the input. This is to avoid
>> >> >> device-specific fixup in the drivers and move all this to the
>> >> >> inputmapper. An example would be a remapping for gamepads that report
>> >> >> BTN_A instead of BTN_NORTH, but we cannot fix them in the kernel for
>> >> >> backwards-compatibility reasons. The gamepad-driver can then assume
>> >> >> that if it receives BTN_NORTH, it is guaranteed to be BTN_NORTH and
>> >> >> doesn't need to special case xbox360/etc. controllers, because they're
>> >> >> broken.
>> >> >
>> >> > I think evdev is exactly that interface and apparently it doesn't work.
>> >> >
>> >> > if you want a mapping table, you need a per-client table because sooner 
>> >> > or
>> >> > later you have a client that needs BTN_FOO when the kernel gives you 
>> >> > BTN_BAR
>> >> > and you can't change the client to fix it.
>> >> >
>> >> > i.e. the same issue evdev has now, having a global remapping table just
>> >> > moves the problem down by 2 years.
>> >> >
>> >> > a mapping table is good, but you probably want two stages of mapping: 
>> >> > one
>> >> > that's used in the compositor for truly broken devices that for some 
>> >> > reason
>> >> > can't be fixed in the kernel, and one that's used on a per-client 
>> >> > basis. and
>> >> > you'll likely want to be able to overide the client-specific from 
>> >> > outside
>> >> > the client too.
>> >>
>> >> IMHO, the problem with evdev is, that it doesn't provide device
>> >> classes. The only class we have is "this is an input device". All
>> >> other event-flags can be combined in whatever way we want.
>> >>
>> >> So like 10 years ago when the first gamepad driver was introduced, we
>> >> added some mapping that was unique to this device (the device was
>> >> probably unique, too). Some time later, we added some other
>> >> gamepad-like driver with a different mapping (as it was probably a
>> >> very different device-type, back then, and we didn't see it coming
>> >> that this will become a wide-spread device-type).
>> >> However, today we notice that a "GamePad" is an established type of
>> >> device (like a touchpad), but we have tons of different mappings in
>> >> the kernel for backwards-compatibility reasons. I can see that this
>> >> kind of development can happen again (and very likely it _will_ happen
>> >> again) and it will happen for all kinds of devices.
>> >>
>> >> But that's why I designed the proposal from a compositor's view
>> >> instead of from a kernel's view.
>> >>
>> >> A touchpad driver of the compositor needs to know exactly what kind of
>> >> events it gets from the kernel. If it gets wrong events, it will
>> >> misbehave. As we cannot guarantee that all kernel drivers behave the
>> >> same way, the compositor's touchpad driver needs to work around all
>> >> these little details on a per-device basis.
>> >> To avoid this, I tried to abstract the touchpad-protocol and moved
>> >> per-device handling into a separate library. It detects all devices
>> >> that can serve as a touchpad and fixes trivial (1-to-1 mapping)
>> >> incompatibilities. This removes all per-device handling from the
>> >> touchpad driver and it can expect all input it gets to be conform with
>> >> a "touchpad" protocol.
>> >> And in fact, it removes this from all the compositor's input drivers.
>> >> So I think of it more like a "lib-detect-and-make-compat".
>> >>
>> >> All devices that do not fall into one of the categories (I called it
>> >> capability), will be handled as custom devices. So if we want an input
>> >> d

[PATCH] config-parser-test: fix compile error

2013-05-24 Thread Mun, Gwan-gyeong 
This patch fixes compile error on config-parser-test.

config-parser-test uses wayland-util.h header file.
But , config-parser-test's Makefile does not include COMPOSITOR_CFLAGS.

This patch fixes it.

---
>From 993ddf5481242b74db2174eb2c7d05abe0be126c Mon Sep 17 00:00:00 2001
From: Mun Gwan-gyeong 
Date: Sat, 25 May 2013 01:13:09 +0900
Subject: [PATCH] config-parser-test: fix compile error

Add COMPOSITOR_CFLAGS to Makefile.am
---
shared/Makefile.am | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/shared/Makefile.am b/shared/Makefile.am
index cf08ec5..323f838 100644
--- a/shared/Makefile.am
+++ b/shared/Makefile.am
@@ -1,6 +1,6 @@
noinst_LTLIBRARIES = libshared.la libshared-cairo.la

-libshared_la_CFLAGS = $(GCC_CFLAGS)
+libshared_la_CFLAGS = $(GCC_CFLAGS) $(COMPOSITOR_CFLAGS)

libshared_la_SOURCES = \
config-parser.c \
-- 
1.7.9.5

>From 993ddf5481242b74db2174eb2c7d05abe0be126c Mon Sep 17 00:00:00 2001
From: Mun Gwan-gyeong 
Date: Sat, 25 May 2013 01:13:09 +0900
Subject: [PATCH] config-parser-test: fix compile error

Add COMPOSITOR_CFLAGS to Makefile.am
---
 shared/Makefile.am |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/shared/Makefile.am b/shared/Makefile.am
index cf08ec5..323f838 100644
--- a/shared/Makefile.am
+++ b/shared/Makefile.am
@@ -1,6 +1,6 @@
 noinst_LTLIBRARIES = libshared.la libshared-cairo.la
 
-libshared_la_CFLAGS = $(GCC_CFLAGS)
+libshared_la_CFLAGS = $(GCC_CFLAGS) $(COMPOSITOR_CFLAGS)
 
 libshared_la_SOURCES =\
 	config-parser.c\
-- 
1.7.9.5

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

[PATCH] config-parser: Avoid null dereference when handling config-parser

2013-05-24 Thread Mun, Gwan-gyeong 
This patch fixes segmentation fault when weston starts without config file.

---
>From bb953ce110dd27d1b6504c2b9aab28e771c4410b Mon Sep 17 00:00:00 2001
From: Mun Gwan-gyeong 
Date: Sat, 25 May 2013 02:09:13 +0900
Subject: [PATCH] config-parser: Avoid null dereference when handling
config-parser

backtrace:
(gdb) bt
#0 weston_config_get_section (config=0x0, section=0x8062f31 "keyboard",
key=0x0, value=0x0)
at config-parser.c:265
#1 0x080535a1 in weston_compositor_init (ec=0x905b690,
display=0x9056490, argc=0xbf8bd2f0,
argv=0xbf8bd384, config_fd=-1) at compositor.c:2819
#2 0xb75d72bb in x11_compositor_create (config_fd=-1, argv=0xbf8bd384,
argc=,
use_pixman=0, no_input=0, fullscreen=0, display=0x9056490) at
compositor-x11.c:1527
#3 backend_init (display=0x9056490, argc=0xbf8bd2f0, argv=0xbf8bd384,
config_fd=-1)
at compositor-x11.c:1746
---
shared/config-parser.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/shared/config-parser.c b/shared/config-parser.c
index 5ef6f03..9772c12 100644
--- a/shared/config-parser.c
+++ b/shared/config-parser.c
@@ -262,6 +262,8 @@ weston_config_get_section(struct weston_config
*config, const char *section,
struct weston_config_section *s;
struct weston_config_entry *e;

+ if (config == NULL)
+ return NULL;
wl_list_for_each(s, &config->section_list, link) {
if (strcmp(s->name, section) != 0)
continue;
-- 
1.7.9.5

>From bb953ce110dd27d1b6504c2b9aab28e771c4410b Mon Sep 17 00:00:00 2001
From: Mun Gwan-gyeong 
Date: Sat, 25 May 2013 02:09:13 +0900
Subject: [PATCH] config-parser: Avoid null dereference when handling
 config-parser

backtrace:
 (gdb) bt
 #0  weston_config_get_section (config=0x0, section=0x8062f31 "keyboard", key=0x0, value=0x0)
 at config-parser.c:265
 #1  0x080535a1 in weston_compositor_init (ec=0x905b690, display=0x9056490, argc=0xbf8bd2f0,
 argv=0xbf8bd384, config_fd=-1) at compositor.c:2819
 #2  0xb75d72bb in x11_compositor_create (config_fd=-1, argv=0xbf8bd384, argc=,
 use_pixman=0, no_input=0, fullscreen=0, display=0x9056490) at compositor-x11.c:1527
 #3  backend_init (display=0x9056490, argc=0xbf8bd2f0, argv=0xbf8bd384, config_fd=-1)
 at compositor-x11.c:1746
---
 shared/config-parser.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/shared/config-parser.c b/shared/config-parser.c
index 5ef6f03..9772c12 100644
--- a/shared/config-parser.c
+++ b/shared/config-parser.c
@@ -262,6 +262,8 @@ weston_config_get_section(struct weston_config *config, const char *section,
 	struct weston_config_section *s;
 	struct weston_config_entry *e;
 
+	if (config == NULL)
+		return NULL;
 	wl_list_for_each(s, &config->section_list, link) {
 		if (strcmp(s->name, section) != 0)
 			continue;
-- 
1.7.9.5

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

ANNOUNCE: Wayland Live CD that starts directly to Wayland

2013-05-24 Thread nerdopolis 
New Wayland Live CD / First true Wayland Live CD.

Hi. Today I pushed out a new ISO of my Wayland Live CD project, which is named 
for my favorite celebrity.

For this new Wayland CD, I wrote a new login manager with Bash and Zenity and 
Expect (and Script) that fully runs on a Wayland server (weston). 

Now X is no longer involved in the boot process, and X does not start, (unless 
you use an X application with xwayland), because I replaced LightDM with the 
new loginmanager

***As far as security goes, it does store the password in the environment, but 
the users would have to be either root or daemon in order to be able to read 
the /proc//environ, depending on the process. It also has a FIFO that has 
777 access, but login info is never passed across it, just commands that tell 
it to switch user ttys, show a login prompt, show a shutdown menu, and tell the 
script who's weston owns a TTY. So if you decide to install it, and depend on 
security, be warned.***

And just a note for people that switch ttys. The script tries to find the first 
available TTY automatically that isn't open, and it seems to favor TTY8, and 
then start using the next ones for the session. (Unlike what we are used to in 
X, where it defaults to TTY7)

I got it to a point where it supports automatic login, picking a user from a 
list to login, and switching user sessions.
It also supports specifying the desktop environment you want to use, similar to 
the X display managers, only for desktop environments that run as plugins under 
Weston. Right now, all I have is Weston's desktop-shell.so, but in the next 
ISO, I can add Weston's tablet-shell.so, as well as Hawaii's Weston plugin.

It even works in virtualbox if there is a framebuffer, as if there is no kms, 
it falls back to using a framebuffer. (and if there is no framebuffer, it falls 
back to a text dialog).
Under virtualbox, you might have to select a different boot option to force 
create a framebuffer.

there's also a command line wizard
rbos-add-framebuffer 
It's basically an easy to use frontline for adding vga= argument to 
/etc/default/grub if you install the system. It does have ubiquity, it has the 
shortcut in the Desktop folder. (or the command).


You can download the new ISO here: (sorry, 32 bit only, as I need to work my 32 
bit dpkg to install a 64 bit kernel again)
http://sourceforge.net/projects/rebeccablackos/files/May%2024th%202013/RebeccaBlackLinux_i386.iso/download
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: ANNOUNCE: Wayland Live CD that starts directly to Wayland

2013-05-24 Thread Ilyes Gouta 
Hi,

Would it be possible to place that ISO image on a usb key and to boot from
it?

Ilyes
On May 24, 2013 11:01 PM, "nerdopolis" 
wrote:

> **
>
> New Wayland Live CD / First true Wayland Live CD.
>
>
>
> Hi. Today I pushed out a new ISO of my Wayland Live CD project, which is
> named for my favorite celebrity.
>
>
>
> For this new Wayland CD, I wrote a new login manager with Bash and Zenity
> and Expect (and Script) that fully runs on a Wayland server (weston).
>
>
>
> Now X is no longer involved in the boot process, and X does not start,
> (unless you use an X application with xwayland), because I replaced LightDM
> with the new loginmanager
>
>
>
> ***As far as security goes, it does store the password in the environment,
> but the users would have to be either root or daemon in order to be able to
> read the /proc//environ, depending on the process. It also has a FIFO
> that has 777 access, but login info is never passed across it, just
> commands that tell it to switch user ttys, show a login prompt, show a
> shutdown menu, and tell the script who's weston owns a TTY. So if you
> decide to install it, and depend on security, be warned.***
>
>
>
> And just a note for people that switch ttys. The script tries to find the
> first available TTY automatically that isn't open, and it seems to favor
> TTY8, and then start using the next ones for the session. (Unlike what we
> are used to in X, where it defaults to TTY7)
>
>
>
> I got it to a point where it supports automatic login, picking a user from
> a list to login, and switching user sessions.
>
> It also supports specifying the desktop environment you want to use,
> similar to the X display managers, only for desktop environments that run
> as plugins under Weston. Right now, all I have is Weston's
> desktop-shell.so, but in the next ISO, I can add Weston's tablet-shell.so,
> as well as Hawaii's Weston plugin.
>
>
>
> It even works in virtualbox if there is a framebuffer, as if there is no
> kms, it falls back to using a framebuffer. (and if there is no framebuffer,
> it falls back to a text dialog).
>
> Under virtualbox, you might have to select a different boot option to
> force create a framebuffer.
>
>
>
> there's also a command line wizard
>
> rbos-add-framebuffer
>
> It's basically an easy to use frontline for adding vga= argument to
> /etc/default/grub if you install the system. It does have ubiquity, it has
> the shortcut in the Desktop folder. (or the command).
>
>
>
>
>
> You can download the new ISO here: (sorry, 32 bit only, as I need to work
> my 32 bit dpkg to install a 64 bit kernel again)
>
>
> http://sourceforge.net/projects/rebeccablackos/files/May%2024th%202013/RebeccaBlackLinux_i386.iso/download
>
> ___
> 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