Re: [PATCH 7/7] compositor: implement a state machine for display control
On 02/24/2012 08:02 PM, Bill Spitzak wrote: > Tiago Vignatti wrote: >> DISPLAY_ON → DISPLAY_DIM → DISPLAY_SCREENSAVER → DISPLAY_OFF > > Won't there be some interest in making the backlight dim *after* the > screensaver starts? I can imagine the control ui being a bunch of > timing sliders, which the user can move anywhere. Thus the screen > saver can start before it dims. The only real rule is that if the > user moves display off to the left, it does not bother doing the > dimming or screensaver. > I concur. My screen never dims before the screensaver kicks in. Quite a lot of companies have a 1-minute rule for engaging screensavers and password-protecting their unlocking. Screen dimming usually doesn't happen until the computer's been idle for at least 10 minutes though, and it definitely doesn't make sense to dim the screen any faster than 1 minute. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[fullscreen v8] add fullscreen implementation and a test client
From: Alex Wu V7: Fullscreen surface will be atop panels and with a black surface underlying it. Only the WL_SHELL_SURFACE_FULLSCREEN_METHOD_SCALE method implemented in this version. We will implement other methods in another patch. V8: Move all the fullscreen things to map() or configure(). For the simple-rect, it will send a sync request after set_fullsceen and attach the next buffer in the callback. Thanks for Kristian and Pekka's comments. --- weston: The following changes since commit c6d7f60b19c07130f25a7b50e9578fe058c328df: Restructure output zoom key handling. available in the git repository at: git://gitorious.org/wayland-for-krh/weston.git fullscreen-v8 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[fullscreen-v8 PATCH 1/3] compositor: Export functions and add weston_suface::force_configure for fullscreen
From: Alex Wu
This will facilitate the implementation of fullscreen.
Signed-off-by: Alex Wu
---
src/compositor.c | 16 ++--
src/compositor.h |9 +
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/src/compositor.c b/src/compositor.c
index b12c583..022c7a1 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -212,6 +212,7 @@ weston_surface_create(struct weston_compositor *compositor)
surface->buffer = NULL;
surface->output = NULL;
+ surface->force_configure = 0;
pixman_region32_init(&surface->damage);
pixman_region32_init(&surface->opaque);
@@ -231,7 +232,7 @@ weston_surface_create(struct weston_compositor *compositor)
return surface;
}
-static void
+WL_EXPORT void
weston_surface_set_color(struct weston_surface *surface,
GLfloat red, GLfloat green, GLfloat blue, GLfloat alpha)
{
@@ -639,6 +640,16 @@ destroy_surface(struct wl_resource *resource)
free(surface);
}
+WL_EXPORT void
+weston_surface_destroy(struct weston_surface *surface)
+{
+ /*not trying to destroy a client surface this way*/
+ if (surface->surface.resource.client != NULL)
+ return;
+
+ destroy_surface(&surface->surface.resource);
+}
+
static void
weston_buffer_attach(struct wl_buffer *buffer, struct wl_surface *surface)
{
@@ -1132,7 +1143,7 @@ surface_attach(struct wl_client *client,
if (es->output == NULL) {
shell->map(shell, es, buffer->width, buffer->height, sx, sy);
- } else if (sx != 0 || sy != 0 ||
+ } else if (es->force_configure || sx != 0 || sy != 0 ||
es->geometry.width != buffer->width ||
es->geometry.height != buffer->height) {
GLfloat from_x, from_y;
@@ -1144,6 +1155,7 @@ surface_attach(struct wl_client *client,
es->geometry.x + to_x - from_x,
es->geometry.y + to_y - from_y,
buffer->width, buffer->height);
+ es->force_configure = 0;
}
weston_buffer_attach(buffer, &es->surface);
diff --git a/src/compositor.h b/src/compositor.h
index 881f53c..dd9cb20 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -301,6 +301,8 @@ struct weston_surface {
struct wl_buffer *buffer;
struct wl_listener buffer_destroy_listener;
+
+ int force_configure;
};
void
@@ -507,4 +509,11 @@ struct weston_zoom *
weston_zoom_run(struct weston_surface *surface, GLfloat start, GLfloat stop,
weston_zoom_done_func_t done, void *data);
+void
+weston_surface_set_color(struct weston_surface *surface,
+GLfloat red, GLfloat green, GLfloat blue, GLfloat
alpha);
+
+void
+weston_surface_destroy(struct weston_surface *surface);
+
#endif
--
1.7.5.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[fullscreen-v8 PATCH 2/3] shell: Add implementation of fullscreen.
From: Alex Wu
All the fullscreen things (black surface, raise atop panels, transform,
positioning)
are handled in map() or configure().
Signed-off-by: Alex Wu
Signed-off-by: Juan Zhao
---
src/shell.c | 231 ++-
1 files changed, 214 insertions(+), 17 deletions(-)
diff --git a/src/shell.c b/src/shell.c
index d949d0c..add9547 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -38,6 +38,8 @@
struct shell_surface;
+#define INVALID_X (-1)
+#define INVALID_Y (-1)
struct wl_shell {
struct weston_compositor *compositor;
struct weston_shell shell;
@@ -108,6 +110,13 @@ struct shell_surface {
int32_t initial_up;
} popup;
+ struct {
+ enum wl_shell_surface_fullscreen_method type;
+ struct weston_transform transform; /* matrix from x, y */
+ uint32_t framerate;
+ struct weston_surface *black_surface;
+ } fullscreen;
+
struct weston_output *fullscreen_output;
struct weston_output *output;
struct wl_list link;
@@ -134,6 +143,14 @@ struct rotate_grab {
};
static void
+activate(struct weston_shell *base, struct weston_surface *es,
+struct weston_input_device *device, uint32_t time);
+
+static void
+center_on_output(struct weston_surface *surface,
+struct weston_output *output);
+
+static void
shell_configuration(struct wl_shell *shell)
{
char *config_file;
@@ -303,7 +320,8 @@ weston_surface_resize(struct shell_surface *shsurf,
{
struct weston_resize_grab *resize;
- /* FIXME: Reject if fullscreen */
+ if (shsurf->type == SHELL_SURFACE_FULLSCREEN)
+ return 0;
if (edges == 0 || edges > 15 ||
(edges & 3) == 3 || (edges & 12) == 12)
@@ -334,7 +352,8 @@ shell_surface_resize(struct wl_client *client, struct
wl_resource *resource,
struct weston_input_device *wd = input_resource->data;
struct shell_surface *shsurf = resource->data;
- /* FIXME: Reject if fullscreen */
+ if (shsurf->type == SHELL_SURFACE_FULLSCREEN)
+ return;
if (wd->input_device.button_count == 0 ||
wd->input_device.grab_time != time ||
@@ -352,15 +371,22 @@ get_default_output(struct weston_compositor *compositor)
struct weston_output, link);
}
+static void
+shell_unset_fullscreen(struct shell_surface *shsurf)
+{
+ shsurf->fullscreen_output = NULL;
+ shsurf->fullscreen.type = WL_SHELL_SURFACE_FULLSCREEN_METHOD_DEFAULT;
+ shsurf->surface->force_configure = 1;
+ wl_list_remove(&shsurf->fullscreen.transform.link);
+ wl_list_init(&shsurf->fullscreen.transform.link);
+}
+
static int
reset_shell_surface_type(struct shell_surface *surface)
{
switch (surface->type) {
case SHELL_SURFACE_FULLSCREEN:
- weston_surface_set_position(surface->surface,
- surface->saved_x,
- surface->saved_y);
- surface->fullscreen_output = NULL;
+ shell_unset_fullscreen(surface);
break;
case SHELL_SURFACE_MAXIMIZED:
surface->output =
get_default_output(surface->surface->compositor);
@@ -487,6 +513,109 @@ shell_surface_set_maximized(struct wl_client *client,
shsurf->type = SHELL_SURFACE_MAXIMIZED;
}
+static struct weston_surface *
+create_black_surface(struct weston_compositor *ec)
+{
+ struct weston_surface *surface = NULL;
+
+ surface = weston_surface_create(ec);
+ if (surface == NULL) {
+ fprintf(stderr, "no memory\n");
+ return NULL;
+ }
+
+ weston_surface_configure(surface, 0, 0, 8192, 8192);
+ weston_surface_set_color(surface, 0.0, 0.0, 0.0, 1);
+ return surface;
+}
+
+/*
+ * Handle size dismatch and positioning according to the method.
+ */
+static void
+shell_configure_fullscreen(struct shell_surface *shsurf)
+{
+ struct weston_output *output = shsurf->fullscreen_output;
+ struct weston_surface *surface = shsurf->surface;
+ struct weston_matrix *matrix;
+ float scale;
+
+ center_on_output(surface, output);
+
+ switch (shsurf->fullscreen.type) {
+ case WL_SHELL_SURFACE_FULLSCREEN_METHOD_DEFAULT:
+ break;
+ case WL_SHELL_SURFACE_FULLSCREEN_METHOD_SCALE:
+ matrix = &shsurf->fullscreen.transform.matrix;
+ weston_matrix_init(matrix);
+ scale =
(float)output->current->width/(float)surface->geometry.width;
+ weston_matrix_scale(matrix, scale, scale, 1);
+ wl_list_remove(&shsurf->fullscreen.transform.link);
+ wl_list_insert(surface->geometry.transformation_list.prev,
+ &shsurf->fullscreen.transform.link);
+ weston_surface_set_position(
[RFC] compositor: add dpms and backlight support
- hotplug doesn't work; it's easy fix though.
- DPMS off only kicks in when wscreensaver is launched, cause then the
compositor will trigger the second call to lock(), inside shell. It works
anyway with the current wscreensaver broken.
- for backlight, we're using the changes I've done here:
http://cgit.freedesktop.org/~vignatti/libbacklight/commit/
There's a couple of things to evaluate now, but one is the API we're using now
for libbacklight. You will see that the application is encharged of setting
the connector udev handler and passing also the connector_type, which will be
used internally as heuristic to find the device. This is very simple API and
accommodates pretty well with Weston. It's leaving the burden of discovering
and probing the device for the application itself, which in case of Weston is
great because it was already done for other reasons.
Signed-off-by: Tiago Vignatti
---
configure.ac |2 +-
src/compositor-drm.c | 98 +
src/compositor-openwfd.c |2 +
src/compositor-wayland.c |2 +
src/compositor-x11.c |2 +
src/compositor.c | 14 +++
src/compositor.h |2 +
src/shell.c | 36 -
8 files changed, 146 insertions(+), 12 deletions(-)
diff --git a/configure.ac b/configure.ac
index ba42a04..6b54bb3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -73,7 +73,7 @@ AC_ARG_ENABLE(drm-compositor, [ --enable-drm-compositor],,
AM_CONDITIONAL(ENABLE_DRM_COMPOSITOR, test x$enable_drm_compositor = xyes)
if test x$enable_drm_compositor = xyes; then
AC_DEFINE([BUILD_DRM_COMPOSITOR], [1], [Build the DRM compositor])
- PKG_CHECK_MODULES(DRM_COMPOSITOR, [libudev >= 136 libdrm >= 2.4.30 gbm])
+ PKG_CHECK_MODULES(DRM_COMPOSITOR, [libbacklight libudev >= 136 libdrm >=
2.4.30 gbm])
fi
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 38ff02b..1d5d013 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -35,6 +35,7 @@
#include
#include
+#include
#include "compositor.h"
#include "evdev.h"
@@ -86,6 +87,7 @@ struct drm_output {
struct wl_listener scanout_buffer_destroy_listener;
struct wl_buffer *pending_scanout_buffer;
struct wl_listener pending_scanout_buffer_destroy_listener;
+ struct backlight *backlight;
};
/*
@@ -697,6 +699,9 @@ drm_output_destroy(struct weston_output *output_base)
drmModeCrtcPtr origcrtc = output->original_crtc;
int i;
+ if (output->backlight)
+ backlight_destroy(output->backlight);
+
/* Turn off hardware cursor */
drm_output_set_cursor(&output->base, NULL);
@@ -907,11 +912,76 @@ sprite_handle_pending_buffer_destroy(struct wl_listener
*listener,
sprite->pending_surface = NULL;
}
+static void
+drm_set_backlight(struct weston_output *output_base, uint32_t up_down)
+{
+ struct drm_output *output = (struct drm_output *) output_base;
+ long brightness;
+
+ if (!output->backlight)
+ return;
+
+ /* I know, very very rudimentary logic for turning brighter/darker.
+* Maybe we should normalize brightness value to have a scale say from
+* 1 to 10 or something. */
+ brightness = backlight_get_brightness(output->backlight);
+ if (up_down == 1)
+ brightness++;
+ else if (up_down == -1)
+ brightness--;
+ else
+ return;
+
+ if (brightness > backlight_get_max_brightness(output->backlight) ||
+ brightness < 0)
+ return;
+
+ backlight_set_brightness(output->backlight, brightness);
+ fprintf(stderr, "setting brightness to: %ld\n", brightness);
+}
+
+static void
+drm_set_dpms(struct weston_output *output_base, uint32_t state)
+{
+ struct drm_output *output = (struct drm_output *) output_base;
+ struct weston_compositor *ec = output_base->compositor;
+ struct drm_compositor *c = (struct drm_compositor *) ec;
+ drmModeConnectorPtr connector;
+ int i;
+
+ connector = drmModeGetConnector(c->drm.fd, output->connector_id);
+ if (!connector)
+ return;
+
+ if (connector->connection == DRM_MODE_DISCONNECTED)
+ return;
+
+ for (i = 0; i < connector->count_props; i++) {
+ drmModePropertyPtr props;
+ props = drmModeGetProperty(c->drm.fd, connector->props[i]);
+ if (!props)
+ continue;
+
+ if (!strcmp(props->name, "DPMS")) {
+ drmModeConnectorSetProperty(c->drm.fd,
+ connector->connector_id,
+ props->prop_id,
+ state);
+ fprintf(stderr, "setting dpms state to: %d\n", state);
+ drmModeFreeProperty(props);
+ drmModeF
Re: [fullscreen-v8 PATCH 1/3] compositor: Export functions and add weston_suface::force_configure for fullscreen
On Tue, Feb 28, 2012 at 06:07:54PM +0800, zhiwen...@linux.intel.com wrote:
> From: Alex Wu
Thanks, applied with a little edit to make the check in
weston_surface_destroy an assert instead. If we end up in that case,
it's an internal error and we need to catch it, not silently ignore
it.
Also, please format comments like other comments in the code (space
between /* and the comment text and */.
Kristian
> This will facilitate the implementation of fullscreen.
>
> Signed-off-by: Alex Wu
> ---
> src/compositor.c | 16 ++--
> src/compositor.h |9 +
> 2 files changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/src/compositor.c b/src/compositor.c
> index b12c583..022c7a1 100644
> --- a/src/compositor.c
> +++ b/src/compositor.c
> @@ -212,6 +212,7 @@ weston_surface_create(struct weston_compositor
> *compositor)
>
> surface->buffer = NULL;
> surface->output = NULL;
> + surface->force_configure = 0;
>
> pixman_region32_init(&surface->damage);
> pixman_region32_init(&surface->opaque);
> @@ -231,7 +232,7 @@ weston_surface_create(struct weston_compositor
> *compositor)
> return surface;
> }
>
> -static void
> +WL_EXPORT void
> weston_surface_set_color(struct weston_surface *surface,
>GLfloat red, GLfloat green, GLfloat blue, GLfloat alpha)
> {
> @@ -639,6 +640,16 @@ destroy_surface(struct wl_resource *resource)
> free(surface);
> }
>
> +WL_EXPORT void
> +weston_surface_destroy(struct weston_surface *surface)
> +{
> + /*not trying to destroy a client surface this way*/
> + if (surface->surface.resource.client != NULL)
> + return;
> +
> + destroy_surface(&surface->surface.resource);
> +}
> +
> static void
> weston_buffer_attach(struct wl_buffer *buffer, struct wl_surface *surface)
> {
> @@ -1132,7 +1143,7 @@ surface_attach(struct wl_client *client,
>
> if (es->output == NULL) {
> shell->map(shell, es, buffer->width, buffer->height, sx, sy);
> - } else if (sx != 0 || sy != 0 ||
> + } else if (es->force_configure || sx != 0 || sy != 0 ||
> es->geometry.width != buffer->width ||
> es->geometry.height != buffer->height) {
> GLfloat from_x, from_y;
> @@ -1144,6 +1155,7 @@ surface_attach(struct wl_client *client,
>es->geometry.x + to_x - from_x,
>es->geometry.y + to_y - from_y,
>buffer->width, buffer->height);
> + es->force_configure = 0;
> }
>
> weston_buffer_attach(buffer, &es->surface);
> diff --git a/src/compositor.h b/src/compositor.h
> index 881f53c..dd9cb20 100644
> --- a/src/compositor.h
> +++ b/src/compositor.h
> @@ -301,6 +301,8 @@ struct weston_surface {
>
> struct wl_buffer *buffer;
> struct wl_listener buffer_destroy_listener;
> +
> + int force_configure;
> };
>
> void
> @@ -507,4 +509,11 @@ struct weston_zoom *
> weston_zoom_run(struct weston_surface *surface, GLfloat start, GLfloat stop,
> weston_zoom_done_func_t done, void *data);
>
> +void
> +weston_surface_set_color(struct weston_surface *surface,
> + GLfloat red, GLfloat green, GLfloat blue, GLfloat
> alpha);
> +
> +void
> +weston_surface_destroy(struct weston_surface *surface);
> +
> #endif
> --
> 1.7.5.4
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH RFC] protocol: add xslt stylesheet to prettify the protocol
2012/2/25 Peter Hutterer :
> On 25/02/12 01:04 , Kristian Høgsberg wrote:
>>
>> On Fri, Feb 24, 2012 at 2:42 AM, Peter Hutterer
>> wrote:
>>>
>>> On Thu, Feb 23, 2012 at 04:26:23PM -0500, Kristian Hoegsberg wrote:
On Thu, Feb 23, 2012 at 03:58:37PM +1000, Peter Hutterer wrote:
>
> Includes rudimentary styling only.
>
> Signed-off-by: Peter Hutterer
> ---
> A few things to note:
> - I'm not a designer
> - Having a html version of the protocol makes it a lot easier to read,
> and
> it certainly reveals missing bits of documentation in the protocol
> - the .css file is the one from wayland.freedesktop.org, someone could
> easily fix it to prettify the result a bit.
That is very nice. As part of 1.0, we need to figure out a way to
combine the protocol and the spec document into something like docbook
and make pdf and html versions. I don't think we want to stick with
latex.
>>>
>>>
>>> I've played around a bit today and the result is this:
>>> http://people.freedesktop.org/~whot/Wayland/tmp/en-US/html/
>>>
>>> I've copied over the Wayland Architecture page from the current website
>>> just
>>> to have a proper chapter in there, the protocol documentation generated
>>> from
>>> a modification of the xsl.
>>>
>>> The whole lot is generated with publican, I've been assured that publican
>>> can also produce pdf, epub, etc. And the source was relatively trivial,
>>> even
>>> for someone with little docbook experience.
>>>
>>> With a bit of targeted styling, I think this could become quite useful
>>> but
>>> before I invest any more time in this I'd like to hear a yay/nay.
>>
>>
>> That is really cool, that's pretty much exactly what I had in mind. I
>> found a pdf generated by publican, it looks like this:
>>
>>
>> http://jfearn.fedorapeople.org/en-US/Publican/2.6/pdf/Users_Guide/Publican-2.6-Users_Guide-en-US.pdf
>>
>> which is pretty cool. There are various other themes (brand packages)
>> available so we could probably create our own eventually. And in any
>> case, how we go from docbook to pdf/html/etc is something we could
>> change later, but I don't see a problem with publican (*suppressing
>> comment about source code in svn*).
>
>
> I should probably also note that jfearn (who's document you linked to) sits
> about 3m away from me in the office. so if need be, there is publican
> insider knowledge available.
>
> I didn't point this out before but the source for the above link is in a
> higher-level directory http://people.freedesktop.org/~whot/Wayland/en-US/,
> the build was a simple call to "publican build".
>
> http://people.freedesktop.org/~whot/Wayland/en-US/Architecture.xml is the
> source for the architecture chapter,
> http://people.freedesktop.org/~whot/Wayland/en-US/Protocol.xml
> is autogenerated from protocol/wayland.xml.
Are the scripts you used to convert the protocol to docbook and merge
it all into one document in a state that you can share them? I'd like
to get this into git and automated so we can start building this
regularly.
thanks,
Kristian
>
> Cheers,
> Peter
>
>
>
>>
>> Thanks,
>> Kristian
>>
>>> Cheers,
>>> Peter
>>>
Anyway, for now, this is great and definitely highlights the missing
documentation. Committed, and I'll try to setup a push hook to put
the html on the web site.
thanks,
Kristian
> Makefile.am | 2 +-
> configure.ac | 6 +-
> protocol/Makefile.am | 7 ++
> protocol/protocol.xsl | 204
> +
> protocol/wayland.css | 41 ++
> 5 files changed, 258 insertions(+), 2 deletions(-)
> create mode 100644 protocol/Makefile.am
> create mode 100644 protocol/protocol.xsl
> create mode 100644 protocol/wayland.css
>
> diff --git a/Makefile.am b/Makefile.am
> index 4461e48..016bb76 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -1,4 +1,4 @@
> -SUBDIRS = src
> +SUBDIRS = src protocol
>
> ACLOCAL_AMFLAGS = -I m4 ${ACLOCAL_FLAGS}
>
> diff --git a/configure.ac b/configure.ac
> index a1c9d2a..fc623e8 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -48,9 +48,13 @@ if test "x$enable_scanner" = "xyes"; then
> AC_SUBST(EXPAT_LIBS)
> fi
>
> +AC_PATH_PROG(XSLTPROC, xsltproc)
> +AM_CONDITIONAL([HAVE_XSLTPROC], [test $XSLTPROC != ""])
> +
> AC_CONFIG_FILES([Makefile
> wayland-scanner.m4
> src/Makefile
> src/wayland-server.pc
> - src/wayland-client.pc])
> + src/wayland-client.pc
> + protocol/Makefile])
> AC_OUTPUT
> diff --git a/protocol/Makefile.am b/protocol/Makefile.am
> new file mode 100644
> index 000..9b57441
> --- /dev/null
> +++ b/protocol/Makefile.am
> @@ -0,0 +1,7 @@
> +if HAVE_XSLTPR
one drag-n-drop corner case
Hi. I stumbled upon problems (including crashes) with drag-n-drop in X11 in case when a window disappears while dragging is being done (for example a program exits). https://bugs.kde.org/show_bug.cgi?id=192270 So I thought it would be useful for you to have such corner case in mind when you implement drag-n-drop in Wayland... ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] compositor: make the input region of drag surfaces empty
With the input region changes, drag surfaces were being picked and
receiving events which led to problems on the client side.
---
src/compositor.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/src/compositor.c b/src/compositor.c
index b12c583..eabb34f 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -190,6 +190,15 @@ region_is_undefined(pixman_region32_t *region)
return region->data == &undef_region_data;
}
+static void
+empty_region(pixman_region32_t *region)
+{
+ if (!region_is_undefined(region))
+ pixman_region32_fini(region);
+
+ pixman_region32_init_rect(region, 0, 0, 0, 0);
+}
+
WL_EXPORT struct weston_surface *
weston_surface_create(struct weston_compositor *compositor)
{
@@ -1895,6 +1904,7 @@ weston_input_update_drag_surface(struct wl_input_device
*input_device,
surface_changed = 1;
if (!input_device->drag_surface || surface_changed) {
+ undef_region(&device->drag_surface->input);
device->drag_surface = NULL;
if (!surface_changed)
return;
@@ -1913,8 +1923,14 @@ weston_input_update_drag_surface(struct wl_input_device
*input_device,
wl_list_insert(weston_compositor_top(device->compositor),
&device->drag_surface->link);
weston_surface_assign_output(device->drag_surface);
+ empty_region(&device->drag_surface->input);
}
+ /* the client may have attached a buffer with a different size to
+* the drag surface, causing the input region to be reset */
+ if (region_is_undefined(&device->drag_surface->input))
+ empty_region(&device->drag_surface->input);
+
if (!dx && !dy)
return;
--
1.7.4.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
cairo/weston-terminal fonts bug bisected
In case anyone's curious, I've bisected the font corruption in weston-terminal with current cairo. Cairo commit 8c3b86787acf525df24a3b147da73398b7d1571c "gl: Fix gl-source-surface test" is the first to show the problem, but crashes weston-terminal instead of giving corruption. Cairo commit 7c34997a3ba89f2e957953aeb4bffa910dbf375b "gl: Just flush the context upon operand destroy" fixes the crash, and gives the corruption seen currently. --Andrew (dolphinling) ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] protocol: Clarify the documentation for the fullscreen protocol
From: Rob Bradford --- protocol/wayland.xml | 53 - 1 files changed, 34 insertions(+), 19 deletions(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 5cc13a8..3631289 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -431,12 +431,22 @@ - Map the surface as a fullscreen surface. On the output the - surface is assigned to. The client can use different fulllscreen - method to fix the size mismatch issue: default, scale, driver - and fill. And the framerate parameter is used for "driver" method, - to indicate the preferred framerate. framerate=0 means that the - app does not care about framerate +Map the surface as a fullscreen surface. If an output parameter is +given then the surface will be made fullscreen on that output. If the +client does not specify the output then the compositor will apply its +policy - usually choosing the output on which the surface has the +biggest surface area. + +The client may specify a method to resolve a size conflict between the +output size and the surface size - this is provided through the +fullscreen_method parameter. + +The framerate parameter is used only when the fullscreen_method is set +to "driver", to indicate the preferred framerate. framerate=0 indicates +that the app does not care about framerate. + +The compositor must reply to this request with a configure event with +the dimensions for the output on which the surface will be made fullscreen. @@ -445,19 +455,24 @@ - Hints to indicate compositor how to deal with this fullscreen surface. - "default" means the client has no preference on fullscreen - behavior, policies are determined by compositor. - "scale" means the client prefers scaling by the compositor. - Scaling would always preserve surface's aspect ratio. - And the surface is centered. - "driver" means the client wants to switch video mode to the - smallest mode that can fit the client buffer. If the - sizes do not match, black borders are added. - "fill"means the client wants to add blackborders to the - surface. This would be preferring 1:1 pixel mapping - in the monitor native video mode. The surface is - centered. +Hints to indicate compositor how to deal with a conflict between the +dimensions for the surface and the dimensions of the output. As a hint +the compositor is free to ignore this parameter. + +"default" The client has no preference on fullscreen behavior, +policies are determined by compositor. + +"scale" The client prefers scaling by the compositor. Scaling would +always preserve surface's aspect ratio with surface centered on the +output + +"driver" The client wants to switch video mode to the smallest mode +that can fit the client buffer. If the sizes do not match the +compositor must add black borders. + +"fill" The surface is centered on the output on the screen with no +scaling. If the surface is of insufficient size the compositor must +add black borders. -- 1.7.7.6 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] protocol: Clarify the documentation for the fullscreen protocol
Juan, Does this align with what you intended in this request? I think it is a bit clearer now and resolves some of the items we discussed at the last hackfest and also on IRC. Cheers, Rob On 28 February 2012 16:48, Rob Bradford wrote: > From: Rob Bradford > > --- > protocol/wayland.xml | 53 - > 1 files changed, 34 insertions(+), 19 deletions(-) > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > index 5cc13a8..3631289 100644 > --- a/protocol/wayland.xml > +++ b/protocol/wayland.xml > @@ -431,12 +431,22 @@ > > > > - Map the surface as a fullscreen surface. On the output the > - surface is assigned to. The client can use different fulllscreen > - method to fix the size mismatch issue: default, scale, driver > - and fill. And the framerate parameter is used for "driver" method, > - to indicate the preferred framerate. framerate=0 means that the > - app does not care about framerate > + Map the surface as a fullscreen surface. If an output parameter is > + given then the surface will be made fullscreen on that output. If the > + client does not specify the output then the compositor will apply its > + policy - usually choosing the output on which the surface has the > + biggest surface area. > + > + The client may specify a method to resolve a size conflict between > the > + output size and the surface size - this is provided through the > + fullscreen_method parameter. > + > + The framerate parameter is used only when the fullscreen_method is > set > + to "driver", to indicate the preferred framerate. framerate=0 > indicates > + that the app does not care about framerate. > + > + The compositor must reply to this request with a configure event with > + the dimensions for the output on which the surface will be made > fullscreen. > > > > @@ -445,19 +455,24 @@ > > > > - Hints to indicate compositor how to deal with this fullscreen surface. > - "default" means the client has no preference on fullscreen > - behavior, policies are determined by compositor. > - "scale" means the client prefers scaling by the compositor. > - Scaling would always preserve surface's aspect ratio. > - And the surface is centered. > - "driver" means the client wants to switch video mode to the > - smallest mode that can fit the client buffer. If the > - sizes do not match, black borders are added. > - "fill" means the client wants to add blackborders to the > - surface. This would be preferring 1:1 pixel mapping > - in the monitor native video mode. The surface is > - centered. > + Hints to indicate compositor how to deal with a conflict between the > + dimensions for the surface and the dimensions of the output. As a > hint > + the compositor is free to ignore this parameter. > + > + "default" The client has no preference on fullscreen behavior, > + policies are determined by compositor. > + > + "scale" The client prefers scaling by the compositor. Scaling would > + always preserve surface's aspect ratio with surface centered on the > + output > + > + "driver" The client wants to switch video mode to the smallest mode > + that can fit the client buffer. If the sizes do not match the > + compositor must add black borders. > + > + "fill" The surface is centered on the output on the screen with no > + scaling. If the surface is of insufficient size the compositor must > + add black borders. > > > > -- > 1.7.7.6 > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] compositor: add dpms and backlight support
On Tue, 28 Feb 2012 13:52:21 +0200
Tiago Vignatti wrote:
> @@ -907,11 +912,76 @@ sprite_handle_pending_buffer_destroy(struct wl_listener
> *listener,
> sprite->pending_surface = NULL;
> }
>
> +static void
> +drm_set_backlight(struct weston_output *output_base, uint32_t up_down)
> +{
> + struct drm_output *output = (struct drm_output *) output_base;
> + long brightness;
> +
> + if (!output->backlight)
> + return;
> +
> + /* I know, very very rudimentary logic for turning brighter/darker.
> + * Maybe we should normalize brightness value to have a scale say from
> + * 1 to 10 or something. */
So if it's just up & down, why not make an enum to make the code
clearer? Then you don't need the last else clause too.
> + brightness = backlight_get_brightness(output->backlight);
> + if (up_down == 1)
> + brightness++;
> + else if (up_down == -1)
> + brightness--;
> + else
> + return;
> +
> + if (brightness > backlight_get_max_brightness(output->backlight) ||
> + brightness < 0)
> + return;
> +
> + backlight_set_brightness(output->backlight, brightness);
> + fprintf(stderr, "setting brightness to: %ld\n", brightness);
Debug output, can be dropped.
> +}
> +
> +static void
> +drm_set_dpms(struct weston_output *output_base, uint32_t state)
> +{
> + struct drm_output *output = (struct drm_output *) output_base;
> + struct weston_compositor *ec = output_base->compositor;
> + struct drm_compositor *c = (struct drm_compositor *) ec;
> + drmModeConnectorPtr connector;
> + int i;
> +
> + connector = drmModeGetConnector(c->drm.fd, output->connector_id);
> + if (!connector)
> + return;
> +
> + if (connector->connection == DRM_MODE_DISCONNECTED)
> + return;
Will this ever be the case? Or will we have torn down the output
already?
> +
> + for (i = 0; i < connector->count_props; i++) {
> + drmModePropertyPtr props;
> + props = drmModeGetProperty(c->drm.fd, connector->props[i]);
> + if (!props)
> + continue;
> +
> + if (!strcmp(props->name, "DPMS")) {
> + drmModeConnectorSetProperty(c->drm.fd,
> + connector->connector_id,
> + props->prop_id,
> + state);
> + fprintf(stderr, "setting dpms state to: %d\n", state);
> + drmModeFreeProperty(props);
> + drmModeFreeConnector(connector);
> + return;
> + }
> + drmModeFreeProperty(props);
> + }
Not sure if we modify properties elsewhere, but it might be good to
separate this out into a helper that finds a specific property and
returns it.
> + output->backlight = backlight_init(drm_device,
> +connector->connector_type);
> + if (!output->backlight) {
> + fprintf(stderr, "failed to initiate backlight control\n");
> + }
> +
This will be a normal case for desktop configs, so it shouldn't be
treated like an error.
> +static void
> +weston_compositor_dpms_on(struct weston_compositor *compositor)
> +{
> +struct weston_output *output;
> +
> + /* TODO: we'd need a state machine to test whether dpms is on/off
> + * before just going and setting it */
> +wl_list_for_each(output, &compositor->output_list, link)
> + if (output->set_dpms)
> + output->set_dpms(output, 0);
> +}
> +
> WL_EXPORT void
> weston_compositor_activity(struct weston_compositor *compositor)
> {
> if (compositor->state == WESTON_COMPOSITOR_ACTIVE) {
> weston_compositor_wake(compositor);
> } else {
> + weston_compositor_dpms_on(compositor);
> compositor->shell->unlock(compositor->shell);
> }
> }
> @@ -2482,6 +2495,7 @@ int main(int argc, char *argv[])
> exit(EXIT_FAILURE);
> }
>
> + weston_compositor_dpms_on(ec);
Yeah just some simple timer arm & reset calls here would do the trick I
think.
> weston_compositor_wake(ec);
> if (setjmp(segv_jmp_buf) == 0)
> wl_display_run(display);
> diff --git a/src/compositor.h b/src/compositor.h
> index 881f53c..bb45bd1 100644
> --- a/src/compositor.h
> +++ b/src/compositor.h
> @@ -86,6 +86,8 @@ struct weston_output {
> void (*repaint)(struct weston_output *output);
> void (*destroy)(struct weston_output *output);
> void (*assign_planes)(struct weston_output *output);
> + void (*set_backlight)(struct weston_output *output, uint32_t up_down);
> + void (*set_dpms)(struct weston_output *output, uint32_t state);
> };
>
> struct weston_input_device {
> diff --git a/src/shell.c b/src/shell.c
> index d949d0c..1510035 100644
> --- a/src/shell.c
> ++
Re: [RFC] compositor: add dpms and backlight support
On Tue, Feb 28, 2012 at 1:19 PM, Jesse Barnes wrote:
> On Tue, 28 Feb 2012 13:52:21 +0200
> Tiago Vignatti wrote:
>> @@ -907,11 +912,76 @@ sprite_handle_pending_buffer_destroy(struct
>> wl_listener *listener,
>> sprite->pending_surface = NULL;
>> }
>>
>> +static void
>> +drm_set_backlight(struct weston_output *output_base, uint32_t up_down)
>> +{
>> + struct drm_output *output = (struct drm_output *) output_base;
>> + long brightness;
>> +
>> + if (!output->backlight)
>> + return;
>> +
>> + /* I know, very very rudimentary logic for turning brighter/darker.
>> + * Maybe we should normalize brightness value to have a scale say from
>> + * 1 to 10 or something. */
>
> So if it's just up & down, why not make an enum to make the code
> clearer? Then you don't need the last else clause too.
I was thinking that instead of up_down, we could just have an
well-defined range or a float 0-1 and have theweston_output
set_backlight interface take an absolute value in that range. That
was we can actually make shell.c dim the backlight on idle and restore
it to what it was on activity.
Kristian
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] compositor: make the input region of drag surfaces empty
On Tue, Feb 28, 2012 at 05:59:33PM +0200, Ander Conselvan de Oliveira wrote:
> With the input region changes, drag surfaces were being picked and
> receiving events which led to problems on the client side.
> ---
> src/compositor.c | 16
> 1 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/src/compositor.c b/src/compositor.c
> index b12c583..eabb34f 100644
> --- a/src/compositor.c
> +++ b/src/compositor.c
> @@ -190,6 +190,15 @@ region_is_undefined(pixman_region32_t *region)
> return region->data == &undef_region_data;
> }
>
> +static void
> +empty_region(pixman_region32_t *region)
> +{
> + if (!region_is_undefined(region))
> + pixman_region32_fini(region);
> +
> + pixman_region32_init_rect(region, 0, 0, 0, 0);
Thanks, committed. I changed the pixman_region32_init_rect above to
just pixman_region32_init, which initializes to the empty region.
Kristian
> +}
> +
> WL_EXPORT struct weston_surface *
> weston_surface_create(struct weston_compositor *compositor)
> {
> @@ -1895,6 +1904,7 @@ weston_input_update_drag_surface(struct wl_input_device
> *input_device,
> surface_changed = 1;
>
> if (!input_device->drag_surface || surface_changed) {
> + undef_region(&device->drag_surface->input);
> device->drag_surface = NULL;
> if (!surface_changed)
> return;
> @@ -1913,8 +1923,14 @@ weston_input_update_drag_surface(struct
> wl_input_device *input_device,
> wl_list_insert(weston_compositor_top(device->compositor),
> &device->drag_surface->link);
> weston_surface_assign_output(device->drag_surface);
> + empty_region(&device->drag_surface->input);
> }
>
> + /* the client may have attached a buffer with a different size to
> + * the drag surface, causing the input region to be reset */
> + if (region_is_undefined(&device->drag_surface->input))
> + empty_region(&device->drag_surface->input);
> +
> if (!dx && !dy)
> return;
>
> --
> 1.7.4.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: [fullscreen-v8 PATCH 2/3] shell: Add implementation of fullscreen.
On Tue, Feb 28, 2012 at 06:08:38PM +0800, zhiwen...@linux.intel.com wrote:
> From: Alex Wu
>
> All the fullscreen things (black surface, raise atop panels, transform,
> positioning)
> are handled in map() or configure().
Ok, looking good, we're almost there now :) A few comments below (and
please try to keep the commit message less than 78 chars wide).
thanks,
Kristian
> Signed-off-by: Alex Wu
> Signed-off-by: Juan Zhao
> ---
> src/shell.c | 231
> ++-
> 1 files changed, 214 insertions(+), 17 deletions(-)
>
> diff --git a/src/shell.c b/src/shell.c
> index d949d0c..add9547 100644
> --- a/src/shell.c
> +++ b/src/shell.c
> @@ -38,6 +38,8 @@
>
> struct shell_surface;
>
> +#define INVALID_X (-1)
> +#define INVALID_Y (-1)
> struct wl_shell {
> struct weston_compositor *compositor;
> struct weston_shell shell;
> @@ -108,6 +110,13 @@ struct shell_surface {
> int32_t initial_up;
> } popup;
>
> + struct {
> + enum wl_shell_surface_fullscreen_method type;
> + struct weston_transform transform; /* matrix from x, y */
> + uint32_t framerate;
> + struct weston_surface *black_surface;
> + } fullscreen;
> +
> struct weston_output *fullscreen_output;
> struct weston_output *output;
> struct wl_list link;
> @@ -134,6 +143,14 @@ struct rotate_grab {
> };
>
> static void
> +activate(struct weston_shell *base, struct weston_surface *es,
> + struct weston_input_device *device, uint32_t time);
> +
> +static void
> +center_on_output(struct weston_surface *surface,
> + struct weston_output *output);
> +
> +static void
> shell_configuration(struct wl_shell *shell)
> {
> char *config_file;
> @@ -303,7 +320,8 @@ weston_surface_resize(struct shell_surface *shsurf,
> {
> struct weston_resize_grab *resize;
>
> - /* FIXME: Reject if fullscreen */
> + if (shsurf->type == SHELL_SURFACE_FULLSCREEN)
> + return 0;
>
> if (edges == 0 || edges > 15 ||
> (edges & 3) == 3 || (edges & 12) == 12)
> @@ -334,7 +352,8 @@ shell_surface_resize(struct wl_client *client, struct
> wl_resource *resource,
> struct weston_input_device *wd = input_resource->data;
> struct shell_surface *shsurf = resource->data;
>
> - /* FIXME: Reject if fullscreen */
> + if (shsurf->type == SHELL_SURFACE_FULLSCREEN)
> + return;
>
> if (wd->input_device.button_count == 0 ||
> wd->input_device.grab_time != time ||
> @@ -352,15 +371,22 @@ get_default_output(struct weston_compositor *compositor)
> struct weston_output, link);
> }
>
> +static void
> +shell_unset_fullscreen(struct shell_surface *shsurf)
> +{
> + shsurf->fullscreen_output = NULL;
> + shsurf->fullscreen.type = WL_SHELL_SURFACE_FULLSCREEN_METHOD_DEFAULT;
> + shsurf->surface->force_configure = 1;
> + wl_list_remove(&shsurf->fullscreen.transform.link);
> + wl_list_init(&shsurf->fullscreen.transform.link);
> +}
> +
> static int
> reset_shell_surface_type(struct shell_surface *surface)
> {
> switch (surface->type) {
> case SHELL_SURFACE_FULLSCREEN:
> - weston_surface_set_position(surface->surface,
> - surface->saved_x,
> - surface->saved_y);
> - surface->fullscreen_output = NULL;
> + shell_unset_fullscreen(surface);
> break;
> case SHELL_SURFACE_MAXIMIZED:
> surface->output =
> get_default_output(surface->surface->compositor);
> @@ -487,6 +513,109 @@ shell_surface_set_maximized(struct wl_client *client,
> shsurf->type = SHELL_SURFACE_MAXIMIZED;
> }
>
> +static struct weston_surface *
> +create_black_surface(struct weston_compositor *ec)
> +{
> + struct weston_surface *surface = NULL;
> +
> + surface = weston_surface_create(ec);
> + if (surface == NULL) {
> + fprintf(stderr, "no memory\n");
> + return NULL;
> + }
> +
> + weston_surface_configure(surface, 0, 0, 8192, 8192);
> + weston_surface_set_color(surface, 0.0, 0.0, 0.0, 1);
This surface (8192x8192 at 0,0) will cover all outputs. We need to
make a surface for a specific output such that the size and position
matches the output.
> + return surface;
> +}
> +
> +/*
> + * Handle size dismatch and positioning according to the method.
> + */
> +static void
> +shell_configure_fullscreen(struct shell_surface *shsurf)
> +{
> + struct weston_output *output = shsurf->fullscreen_output;
> + struct weston_surface *surface = shsurf->surface;
> + struct weston_matrix *matrix;
> + float scale;
> +
> + center_on_output(surface, output);
> +
> + switch (shsurf->fullscreen.type) {
> + case WL_SHELL_SURFACE_FULLSCREEN_METHOD_DEFAULT:
> + break;
> + case WL_SHELL_SURF
Re: [RFC] [PATCH] Renamed client side wl_display_destroy() to wl_display_disconnect()
On Mon, Feb 27, 2012 at 05:10:03PM +0100, Samuel Rødal wrote:
> The only problem I see with this is that the "disconnect" naming can
> be confusing as the wl_display handle is actually freed as well.
I like it, it pairs better with wl_display_connect. I don't think
it's a problem that the name is less clear about destruction, we just
need to document it.
Kristian
> From 78588a8c322b9304aea658ea96673cac9cc52a68 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Samuel=20R=C3=B8dal?=
> Date: Mon, 27 Feb 2012 17:03:42 +0100
> Subject: [PATCH] Renamed client side wl_display_destroy() to
> wl_display_disconnect()
>
> This avoids the clash with the wayland-server version with the same
> name, and allows linking against both wayland-client and wayland-server
> at the same time, which can be useful for unit testing purposes as
> well as for nested compositing.
>
> Without this there will be crashes as the wrong wl_display_destroy()
> is called.
> ---
> src/wayland-client.c |2 +-
> src/wayland-client.h |2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/wayland-client.c b/src/wayland-client.c
> index bbfc035..6712c32 100644
> --- a/src/wayland-client.c
> +++ b/src/wayland-client.c
> @@ -397,7 +397,7 @@ wl_display_connect(const char *name)
> }
>
> WL_EXPORT void
> -wl_display_destroy(struct wl_display *display)
> +wl_display_disconnect(struct wl_display *display)
> {
> struct wl_global *global, *gnext;
> struct wl_global_listener *listener, *lnext;
> diff --git a/src/wayland-client.h b/src/wayland-client.h
> index efeee4a..b04a7ef 100644
> --- a/src/wayland-client.h
> +++ b/src/wayland-client.h
> @@ -71,7 +71,7 @@ typedef int (*wl_display_update_func_t)(uint32_t mask, void
> *data);
> typedef void (*wl_callback_func_t)(void *data, uint32_t time);
>
> struct wl_display *wl_display_connect(const char *name);
> -void wl_display_destroy(struct wl_display *display);
> +void wl_display_disconnect(struct wl_display *display);
> int wl_display_get_fd(struct wl_display *display,
> wl_display_update_func_t update, void *data);
> void wl_display_iterate(struct wl_display *display, uint32_t mask);
> --
> 1.7.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] Allow update function to not be set in wl_display_get_fd
On Mon, Feb 27, 2012 at 04:57:42PM +0100, Samuel Rødal wrote: > Ignore previous patch, here's the correct version. > From 4e1bedaaf05b576f5191f8fe3a34904ab9707414 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Samuel=20R=C3=B8dal?= > Date: Mon, 27 Feb 2012 15:17:20 +0100 > Subject: [PATCH] Allow update function to not be set in wl_display_get_fd > > The same check is done in connection_update, and now with > wl_display_flush() there's less need for the client to need to know the > connection mask. Yeah, ok, looks good. If you're paranoid about blocking on write, you need to poll for write of course, but for non-broken apps/compositors the write should never block. Kristian > --- > src/wayland-client.c |4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) > > diff --git a/src/wayland-client.c b/src/wayland-client.c > index 7814379..02b0592 100644 > --- a/src/wayland-client.c > +++ b/src/wayland-client.c > @@ -422,7 +422,9 @@ wl_display_get_fd(struct wl_display *display, > display->update = update; > display->update_data = data; > > - display->update(display->mask, display->update_data); > + if (display->update) > + display->update(display->mask, > + display->update_data); > > return display->fd; > } > -- > 1.7.0.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
[PATCH] protocol: fix make distcheck
Distribute all source files that we need for buildling. Plus, remove the html file on make clean. Signed-off-by: Peter Hutterer --- protocol/Makefile.am |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/protocol/Makefile.am b/protocol/Makefile.am index 9c6cc49..4939557 100644 --- a/protocol/Makefile.am +++ b/protocol/Makefile.am @@ -1,7 +1,8 @@ if HAVE_XSLTPROC -doc_DATA = wayland.html wayland-protocol.css +dist_doc_DATA = wayland.html wayland-protocol.css wayland.xml -wayland.html: wayland.xml protocol.xsl - $(AM_V_GEN)$(XSLTPROC) protocol.xsl wayland.xml > $@ +wayland.html: $(srcdir)/wayland.xml $(srcdir)/protocol.xsl + $(AM_V_GEN)$(XSLTPROC) $(srcdir)/protocol.xsl $(srcdir)/wayland.xml > $@ +CLEANFILES = wayland.html endif -- 1.7.7.6 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH RFC] protocol: add xslt stylesheet to prettify the protocol
On Tue, Feb 28, 2012 at 09:14:18AM -0500, Kristian Høgsberg wrote: > 2012/2/25 Peter Hutterer : > > On 25/02/12 01:04 , Kristian Høgsberg wrote: > >> > >> On Fri, Feb 24, 2012 at 2:42 AM, Peter Hutterer > >> wrote: > >>> > >>> On Thu, Feb 23, 2012 at 04:26:23PM -0500, Kristian Hoegsberg wrote: > > On Thu, Feb 23, 2012 at 03:58:37PM +1000, Peter Hutterer wrote: > > > > Includes rudimentary styling only. > > > > Signed-off-by: Peter Hutterer > > --- > > A few things to note: > > - I'm not a designer > > - Having a html version of the protocol makes it a lot easier to read, > > and > > it certainly reveals missing bits of documentation in the protocol > > - the .css file is the one from wayland.freedesktop.org, someone could > > easily fix it to prettify the result a bit. > > > That is very nice. As part of 1.0, we need to figure out a way to > combine the protocol and the spec document into something like docbook > and make pdf and html versions. I don't think we want to stick with > latex. > >>> > >>> > >>> I've played around a bit today and the result is this: > >>> http://people.freedesktop.org/~whot/Wayland/tmp/en-US/html/ > >>> > >>> I've copied over the Wayland Architecture page from the current website > >>> just > >>> to have a proper chapter in there, the protocol documentation generated > >>> from > >>> a modification of the xsl. > >>> > >>> The whole lot is generated with publican, I've been assured that publican > >>> can also produce pdf, epub, etc. And the source was relatively trivial, > >>> even > >>> for someone with little docbook experience. > >>> > >>> With a bit of targeted styling, I think this could become quite useful > >>> but > >>> before I invest any more time in this I'd like to hear a yay/nay. > >> > >> > >> That is really cool, that's pretty much exactly what I had in mind. I > >> found a pdf generated by publican, it looks like this: > >> > >> > >> http://jfearn.fedorapeople.org/en-US/Publican/2.6/pdf/Users_Guide/Publican-2.6-Users_Guide-en-US.pdf > >> > >> which is pretty cool. There are various other themes (brand packages) > >> available so we could probably create our own eventually. And in any > >> case, how we go from docbook to pdf/html/etc is something we could > >> change later, but I don't see a problem with publican (*suppressing > >> comment about source code in svn*). > > > > > > I should probably also note that jfearn (who's document you linked to) sits > > about 3m away from me in the office. so if need be, there is publican > > insider knowledge available. > > > > I didn't point this out before but the source for the above link is in a > > higher-level directory http://people.freedesktop.org/~whot/Wayland/en-US/, > > the build was a simple call to "publican build". > > > > http://people.freedesktop.org/~whot/Wayland/en-US/Architecture.xml is the > > source for the architecture chapter, > > http://people.freedesktop.org/~whot/Wayland/en-US/Protocol.xml > > is autogenerated from protocol/wayland.xml. > > Are the scripts you used to convert the protocol to docbook and merge > it all into one document in a state that you can share them? I'd like > to get this into git and automated so we can start building this > regularly. yes, I've fixed a few things up now, patches will come in a second Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 0/6] Publican documentation integration
Branch available from git://people.freedesktop.org/~whot/wayland.git :publican This adds a docbook tree hooked up to build with publican. Default make will build both html and pdf. The make distchecks hooks aren't pretty at all and for some reason it tries to build the documentation every time, even if nothing changed. So it's not perfect yet but that should be fixable. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 1/6] doc: Fix up title page with logo and author information
Abstract taken from http://wayland.freedesktop.org
Signed-off-by: Peter Hutterer
---
doc/Wayland/en-US/Author_Group.xml | 10 +-
doc/Wayland/en-US/Book_Info.xml | 13 ++---
doc/Wayland/en-US/Wayland.ent|2 +-
doc/Wayland/en-US/images/wayland.png | Bin 0 -> 5649 bytes
4 files changed, 16 insertions(+), 9 deletions(-)
create mode 100644 doc/Wayland/en-US/images/wayland.png
diff --git a/doc/Wayland/en-US/Author_Group.xml
b/doc/Wayland/en-US/Author_Group.xml
index b664025..7a70760 100644
--- a/doc/Wayland/en-US/Author_Group.xml
+++ b/doc/Wayland/en-US/Author_Group.xml
@@ -5,12 +5,12 @@
]>
- Dude
- McPants
+ Kristian
+ Høgsberg
- Somewhere
- Someone
+ Intel Corporation
- dude.mcpa...@example.com
+ k...@bitplanet.net
+
diff --git a/doc/Wayland/en-US/Book_Info.xml b/doc/Wayland/en-US/Book_Info.xml
index 4a6d694..4b134eb 100644
--- a/doc/Wayland/en-US/Book_Info.xml
+++ b/doc/Wayland/en-US/Book_Info.xml
@@ -5,20 +5,27 @@
]>
Wayland
- short description
+ The Wayland display server
Documentation
0.1
0
0
- A short overview and summary of the book's subject and
purpose, traditionally no more than one paragraph long. Note: the abstract will
appear in the front matter of your book and will also be placed in the
description field of the book's RPM spec file.
+ Wayland is a protocol for a compositor to talk to
+ its clients as well as a C library implementation of
+ that protocol. The compositor can be a standalone
+ display server running on Linux kernel modesetting
+ and evdev input devices, an X application, or a
+ wayland client itself. The clients can be
+ traditional applications, X servers (rootless or
+ fullscreen) or other display servers.
-
+
diff --git a/doc/Wayland/en-US/Wayland.ent b/doc/Wayland/en-US/Wayland.ent
index c6b36c2..da18a95 100644
--- a/doc/Wayland/en-US/Wayland.ent
+++ b/doc/Wayland/en-US/Wayland.ent
@@ -1,4 +1,4 @@
-
+
diff --git a/doc/Wayland/en-US/images/wayland.png
b/doc/Wayland/en-US/images/wayland.png
new file mode 100644
index
..c9937928ce9584a660ee10f7092eed2033f6eab8
GIT binary patch
literal 5649
zcmbVQWl$6jum_G3j_#I21j(bNB@QGcJmOG5QsQVhQo0W007a!+=|3QNgw#nRNJt&s
za5U1*<9&S}-_GprY|Zb>Z)ayV&OlF-f{c|64-bz*>$&>Ndylx+FQmlxc5$pH`Q8zF
zt7;jM-pe~uJLG-*z~i}@Hy$4GtN&GetAJm&_emBX2+RlS{?^CO+RGl#&(BZ9$qnvp
zYwck#;_l^;xu?L2hsThprLJP+pS7DEkjB`R-J`51!48lBPI~li;sIFc2@|^M4&xtd
zFaOuD?OY&6JIOPWW}JemY|3yMn=3Ix#n~K>@NfOJ+%C}S=LUgFNWDtIq#fXaU@GsE
zTf=?w{Si%LzmtK3^&5qus{!4%@o}k}-LlHd@v0De*cS+~D?L6F!P$u&cS1tRt91IC
z3wwP=5RWtK$MI33-n`s|5~t@HW0H^lH$x*u(TB{4u~UDcCSFj)&0;v3{QoO^1^&dF
zi+8fa2ZX%^nV9M`@d^FyNS~1eS_v5dby2rM#4&)#WhKDMpfkbNiqdDyDbC^b@dhVo
z+HIHxqmgG04M}9rDag=xv#4$*0;W2bDNSLeAQ3kQgxRHpd50X_y
za>boUG?BbWjJN@K&gem#%(iv1sd2DB8Arj?uosqNC(l0VEG6}E{m6m?zTxa9l^a?8s
z=fUrghI9$0l)gK9IW4&U+@f*o1ulNO>R31`B4uu9vm`dd?`w@|(E`j-5Ku00i(|vg
zsSBlN$m3(9j?~OafM105l0BU(uJ*g7FrlCr+J5R6y-XNjUU=d(nZQEU`wtS4w<{0j
z-8!x9RNQEQN)(5Q_(CPOf|BnDjCJU$K8|x;>eIJvZ~%BjB5H~;&awDi!-nLD@(#Ka
z3};gzd6+jC#TPb%gc*y-W<>^-8{s7YeEaEps)gX}9&8>82TxQq(T8kV1S6mTv^qMrUnfOozg=W`bd(
z1)=VcA4?ow_J~zGE8f!moeeN5D69+leQkji9$t=w|z@I-d?6pfI
zl71R8Gld6F44<%I6+ys`fYnH(6o=>j95w>yqD=$m4_h0pdC
z$gnA;0=7#mr1U|%rUEQI>K4(Cj6NO_4)IG1(MubSKeIH76!0W0!*{>~y>+^UzFiiy
zo1Ze!X(c+;-Ea+7L0v?+HM#Ow!6vY7u;
zQ`}@~5Z20L|MH@&^wLrILnt@uPRy=Pp~RYdvLs4-fkwPEu(~Lt8~x*pUb5bTAAQ0l
z$$yXoI~)u6l*@X$5G?t(WwK69Z;Z37w8#_x0C^Zd7ouH1o>rwuo^ofQpxYG6H;}0K
zf=k~}9{*dwYegmPB2PIRCF2`z7BIu1gGxuBFvQb-1~F{Nbc?X-V*#4w_@=e+zdHX2
z=_PnvZWrdnPSi|>Otqa+`ZkKsf1P+K>$dt-*YWtVic00?u1kf%A8E5Oo2a2A_M#8(
z)9wVH`d2vBI*D2Vm{4Fw&ihVpVfDpv+(Q$hD)S8hRXeJM$ZwFV?jG9e>Z?}}XN
z`u^;jj0x$q0gCw8ou&&s0zWmgfcvAS{kpPNzm%^HDF%uqn3HO7Vb6drKk28-$NPur
z*ga8x85OsY>1Y?8hl;mHcY0E&{_ygbiC3ki4~cIx+lqY$lilNo27~fk#Mt?d{C0D!
zF!apglk#)bwN^8Tlyk>WZP=)ffYguzcvmw)2#PT{_6#gZv=r4
zT6LT9gx#BLHD}gej_rh;417-i^in^0MXHOX2jc`@*Yt8ixiIf4?RzHg%5>fKgd?x^
z;(nGCdGdOc!CBj0c;s6at1lP{M~_4F+yqX4d{Nyj^m2;L;dbDx2-a^{VqYG^-S|OX
z7>zPV4Cqm!lpq|922Ven5F5$A&Zap0ue-M`MW=qFZ6|S_Y5W(>c*dn5=BiTW3WpCk
zW+9fC58E92Rca63Pz;O?HsLdC1h@BdJa80@jlZkADx%JhJmURIZp&Irt>-j;ayvf9oPc6PsS^n-KeZ*}h%94rOH1#BvRj?V!@JI}-9i=<}SB`~&|-=X>-f;3Wu
z&3$I+qjxt4qU@|P?5kcyYRO09-_$s!>LSjQsCwuOPOz&1CS$K(%*hr~H`|CBe9vb7
ze7Mi-o(yrYf_Vu-*N|@+U_heLtD)_rS$8FCM=6Tb-E(*;dk;(~!>m7|>96B6P{ZUNOvcl}Ao>W&HX^>bY3^w2{c!Mw
z5`Qzbuap1&Z|N4i6ZnngTAtj^7I?06<+
[PATCH 3/6] doc: Comment out some of the default chapters
I'll leave them in for now as a template for how things looked originally, this can be removed later. Signed-off-by: Peter Hutterer --- doc/Wayland/en-US/Wayland.xml |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/doc/Wayland/en-US/Wayland.xml b/doc/Wayland/en-US/Wayland.xml index 20119f5..acec682 100644 --- a/doc/Wayland/en-US/Wayland.xml +++ b/doc/Wayland/en-US/Wayland.xml @@ -5,9 +5,14 @@ ]> http://www.w3.org/2001/XInclude"; /> + http://www.w3.org/2001/XInclude"; /> + + -- 1.7.7.6 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 4/6] Hook up autotools for publican
automake doesn't seem to provide a sensible method to install a directory of
stuff in $(docdir). Do it manually then.
CC: Gaetan Nadon
Signed-off-by: Peter Hutterer
---
Gaetan - can you check this please, it seems less-than-ideal, especially
since it builds every time I run make, even if no source has changed.
Makefile.am |2 +-
configure.ac |5 +
doc/Makefile.am |1 +
doc/Wayland/.gitignore |1 +
doc/Wayland/Makefile.am | 35 +++
doc/Wayland/publican.cfg |2 ++
6 files changed, 45 insertions(+), 1 deletions(-)
create mode 100644 doc/Makefile.am
create mode 100644 doc/Wayland/.gitignore
create mode 100644 doc/Wayland/Makefile.am
diff --git a/Makefile.am b/Makefile.am
index 016bb76..332f9b4 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1,4 +1,4 @@
-SUBDIRS = src protocol
+SUBDIRS = src protocol doc
ACLOCAL_AMFLAGS = -I m4 ${ACLOCAL_FLAGS}
diff --git a/configure.ac b/configure.ac
index fc623e8..b709e3c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -51,8 +51,13 @@ fi
AC_PATH_PROG(XSLTPROC, xsltproc)
AM_CONDITIONAL([HAVE_XSLTPROC], [test $XSLTPROC != ""])
+AC_PATH_PROG(PUBLICAN, publican)
+AM_CONDITIONAL([HAVE_PUBLICAN], [test $PUBLICAN != ""])
+
AC_CONFIG_FILES([Makefile
wayland-scanner.m4
+doc/Makefile
+doc/Wayland/Makefile
src/Makefile
src/wayland-server.pc
src/wayland-client.pc
diff --git a/doc/Makefile.am b/doc/Makefile.am
new file mode 100644
index 000..f8046e7
--- /dev/null
+++ b/doc/Makefile.am
@@ -0,0 +1 @@
+SUBDIRS = Wayland
diff --git a/doc/Wayland/.gitignore b/doc/Wayland/.gitignore
new file mode 100644
index 000..33b78ca
--- /dev/null
+++ b/doc/Wayland/.gitignore
@@ -0,0 +1 @@
+Wayland
diff --git a/doc/Wayland/Makefile.am b/doc/Wayland/Makefile.am
new file mode 100644
index 000..854da79
--- /dev/null
+++ b/doc/Wayland/Makefile.am
@@ -0,0 +1,35 @@
+if HAVE_PUBLICAN
+EXTRA_DIST = Wayland
+noinst_DATA = Wayland
+
+publican_sources = \
+ $(srcdir)/en-US/Wayland.ent \
+ $(srcdir)/en-US/Architecture.xml \
+ $(srcdir)/en-US/Author_Group.xml \
+ $(srcdir)/en-US/Book_Info.xml \
+ $(srcdir)/en-US/Chapter.xml \
+ $(srcdir)/en-US/Preface.xml \
+ $(srcdir)/en-US/Wayland.xml \
+ $(srcdir)/en-US/Revision_History.xml \
+ $(srcdir)/en-US/images/icon.svg \
+ $(srcdir)/en-US/images/wayland-architecture.png \
+ $(srcdir)/en-US/images/wayland.png \
+ $(srcdir)/en-US/images/x-architecture.png
+
+
+Wayland: publican.cfg $(publican_sources)
+ publican build --lang en-US --format html,pdf
+
+clean-local:
+ -rm -rf Wayland
+
+install-data-local:
+ $(MKDIR_P) $(DESTDIR)$(docdir)
+ cp -R $(builddir)/Wayland $(DESTDIR)$(docdir)
+
+uninstall-local:
+ -rm -rf $(DESTDIR)$(docdir)/Wayland/*
+ -rmdir $(DESTDIR)$(docdir)/Wayland
+
+EXTRA_DIST = $(publican_sources) publican.cfg
+endif
diff --git a/doc/Wayland/publican.cfg b/doc/Wayland/publican.cfg
index 80ff134..810c735 100644
--- a/doc/Wayland/publican.cfg
+++ b/doc/Wayland/publican.cfg
@@ -4,3 +4,5 @@
xml_lang: "en-US"
type: Book
brand: common
+tmp_dir: Wayland
+
--
1.7.7.6
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 5/6] Generate the docbook description for the protocol from wayland.xml
Convert the wayland.xml protocol description to a docbook-compatible format and hook it up to the publican sources. Signed-off-by: Peter Hutterer --- doc/Wayland/.gitignore |1 + doc/Wayland/Makefile.am |9 ++- doc/Wayland/en-US/Wayland.xml |1 + doc/Wayland/protocol-to-docbook.xsl | 113 +++ 4 files changed, 122 insertions(+), 2 deletions(-) create mode 100644 doc/Wayland/protocol-to-docbook.xsl diff --git a/doc/Wayland/.gitignore b/doc/Wayland/.gitignore index 33b78ca..cf78754 100644 --- a/doc/Wayland/.gitignore +++ b/doc/Wayland/.gitignore @@ -1 +1,2 @@ Wayland +en-US/Protocol.xml diff --git a/doc/Wayland/Makefile.am b/doc/Wayland/Makefile.am index 854da79..099efb2 100644 --- a/doc/Wayland/Makefile.am +++ b/doc/Wayland/Makefile.am @@ -17,9 +17,13 @@ publican_sources = \ $(srcdir)/en-US/images/x-architecture.png -Wayland: publican.cfg $(publican_sources) +Wayland: docbook-xsl publican.cfg $(publican_sources) publican build --lang en-US --format html,pdf +# This must be run befor the publican run +docbook-xsl: $(top_srcdir)/protocol/wayland.xml protocol-to-docbook.xsl + $(AM_V_GEN)$(XSLTPROC) protocol-to-docbook.xsl $(top_srcdir)/protocol/wayland.xml > $(srcdir)/en-US/Protocol.xml + clean-local: -rm -rf Wayland @@ -31,5 +35,6 @@ uninstall-local: -rm -rf $(DESTDIR)$(docdir)/Wayland/* -rmdir $(DESTDIR)$(docdir)/Wayland -EXTRA_DIST = $(publican_sources) publican.cfg +EXTRA_DIST = $(publican_sources) publican.cfg protocol-to-docbook.xsl + endif diff --git a/doc/Wayland/en-US/Wayland.xml b/doc/Wayland/en-US/Wayland.xml index acec682..829d362 100644 --- a/doc/Wayland/en-US/Wayland.xml +++ b/doc/Wayland/en-US/Wayland.xml @@ -10,6 +10,7 @@ http://www.w3.org/2001/XInclude"; /> --> http://www.w3.org/2001/XInclude"; /> + http://www.w3.org/2001/XInclude"; /> diff --git a/doc/Wayland/protocol-to-docbook.xsl b/doc/Wayland/protocol-to-docbook.xsl new file mode 100644 index 000..e50d80d --- /dev/null +++ b/doc/Wayland/protocol-to-docbook.xsl @@ -0,0 +1,113 @@ + +http://www.w3.org/1999/XSL/Transform";> + + + + + + + + +Wayland Protocol Specification + + + + + + + + + + + + + + + + + + +protocol-- + + + + + + - + + + + + + + +Requests provided by + + + + + +Events provided by events + + + + + +Enums provided by enums + + + + + + + + + + + + + Type: + + + Value: + + + + + + + + + + + +protocol-interface--- + + :: + +- + + + + + +:: arguments + + + + + +:: values + + + + + + + + -- 1.7.7.6 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 6/6] Hack up distcheck for publican
Publican requires a read-write source tree, see http://bugzilla.redhat.com/show_bug.cgi?id=798484 And it currently cannot build out-of-tree, so we need to copy the sources into the _build tree and generate Protocol.xml into that tree too (we'd have to do this anyway since automake creates a read-only source tree, so we can't just link). CC: Gaetan Nadon Signed-off-by: Peter Hutterer --- Gaetan, if you have any better suggestions I'd love to hear them. doc/Wayland/Makefile.am | 22 ++ 1 files changed, 18 insertions(+), 4 deletions(-) diff --git a/doc/Wayland/Makefile.am b/doc/Wayland/Makefile.am index 099efb2..0ac9fff 100644 --- a/doc/Wayland/Makefile.am +++ b/doc/Wayland/Makefile.am @@ -1,5 +1,4 @@ if HAVE_PUBLICAN -EXTRA_DIST = Wayland noinst_DATA = Wayland publican_sources = \ @@ -16,16 +15,31 @@ publican_sources = \ $(srcdir)/en-US/images/wayland.png \ $(srcdir)/en-US/images/x-architecture.png +# publican does not support out-of-tree builds and during make distcheck the +# source tree is read-only so we can't chdir and/or dump the protocol there +# copy the tree into _build, leaving a marker file to clean up after +# distclean +# See https://bugzilla.redhat.com/show_bug.cgi?id=798484 for the chmod +copy-sources: + if ! test -e "en-US/"; then \ + mkdir en-US/; \ + touch en-US/need-distclean; \ + cp -r $(srcdir)/en-US/* en-US; \ + chmod u+w en-US/images; \ + fi Wayland: docbook-xsl publican.cfg $(publican_sources) - publican build --lang en-US --format html,pdf + publican build --config=$(srcdir)/publican.cfg --lang en-US --format html,pdf # This must be run befor the publican run -docbook-xsl: $(top_srcdir)/protocol/wayland.xml protocol-to-docbook.xsl - $(AM_V_GEN)$(XSLTPROC) protocol-to-docbook.xsl $(top_srcdir)/protocol/wayland.xml > $(srcdir)/en-US/Protocol.xml +docbook-xsl: copy-sources $(top_srcdir)/protocol/wayland.xml $(srcdir)/protocol-to-docbook.xsl + $(AM_V_GEN)$(XSLTPROC) $(srcdir)/protocol-to-docbook.xsl $(top_srcdir)/protocol/wayland.xml > $(builddir)/en-US/Protocol.xml clean-local: -rm -rf Wayland + if test -e "en-US/need-distclean"; then \ + rm -rf en-US; \ + fi install-data-local: $(MKDIR_P) $(DESTDIR)$(docdir) -- 1.7.7.6 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] protocol: fix make distcheck
On 02/28/2012 09:50 PM, Peter Hutterer wrote: Distribute all source files that we need for buildling. Plus, remove the html file on make clean. Signed-off-by: Peter Hutterer --- protocol/Makefile.am |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/protocol/Makefile.am b/protocol/Makefile.am index 9c6cc49..4939557 100644 --- a/protocol/Makefile.am +++ b/protocol/Makefile.am @@ -1,7 +1,8 @@ if HAVE_XSLTPROC -doc_DATA = wayland.html wayland-protocol.css +dist_doc_DATA = wayland.html wayland-protocol.css wayland.xml -wayland.html: wayland.xml protocol.xsl - $(AM_V_GEN)$(XSLTPROC) protocol.xsl wayland.xml> $@ +wayland.html: $(srcdir)/wayland.xml $(srcdir)/protocol.xsl + $(AM_V_GEN)$(XSLTPROC) $(srcdir)/protocol.xsl $(srcdir)/wayland.xml> $@ +CLEANFILES = wayland.html endif patches like this are almost always good :) devilhorns ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] protocol: Clarify the documentation for the fullscreen protocol
On Tue, 28 Feb 2012 16:48:26 + Rob Bradford wrote: > From: Rob Bradford > > --- > protocol/wayland.xml | 53 - > 1 files changed, 34 insertions(+), 19 deletions(-) > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > index 5cc13a8..3631289 100644 > --- a/protocol/wayland.xml > +++ b/protocol/wayland.xml > @@ -431,12 +431,22 @@ > > > > - Map the surface as a fullscreen surface. On the output the > - surface is assigned to. The client can use different fulllscreen > - method to fix the size mismatch issue: default, scale, driver > - and fill. And the framerate parameter is used for "driver" method, > - to indicate the preferred framerate. framerate=0 means that the > - app does not care about framerate > +Map the surface as a fullscreen surface. If an output parameter is > +given then the surface will be made fullscreen on that output. If the > +client does not specify the output then the compositor will apply its > +policy - usually choosing the output on which the surface has the > +biggest surface area. > + > +The client may specify a method to resolve a size conflict between > the > +output size and the surface size - this is provided through the > +fullscreen_method parameter. > + > +The framerate parameter is used only when the fullscreen_method is > set > +to "driver", to indicate the preferred framerate. framerate=0 > indicates > +that the app does not care about framerate. > + > +The compositor must reply to this request with a configure event with > +the dimensions for the output on which the surface will be made > fullscreen. > > > > @@ -445,19 +455,24 @@ > > > > - Hints to indicate compositor how to deal with this fullscreen surface. > - "default" means the client has no preference on fullscreen > - behavior, policies are determined by compositor. > - "scale" means the client prefers scaling by the compositor. > - Scaling would always preserve surface's aspect ratio. > - And the surface is centered. > - "driver" means the client wants to switch video mode to the > - smallest mode that can fit the client buffer. If the > - sizes do not match, black borders are added. > - "fill"means the client wants to add blackborders to the > - surface. This would be preferring 1:1 pixel mapping > - in the monitor native video mode. The surface is > - centered. > +Hints to indicate compositor how to deal with a conflict between the > +dimensions for the surface and the dimensions of the output. As a > hint > +the compositor is free to ignore this parameter. > + > +"default" The client has no preference on fullscreen behavior, > +policies are determined by compositor. > + > +"scale" The client prefers scaling by the compositor. Scaling would > +always preserve surface's aspect ratio with surface centered on the > +output > + > +"driver" The client wants to switch video mode to the smallest mode > +that can fit the client buffer. If the sizes do not match the > +compositor must add black borders. > + > +"fill" The surface is centered on the output on the screen with no > +scaling. If the surface is of insufficient size the compositor must > +add black borders. > > > Looks good to me, thanks. Can we have summary attributes to the enums themselves, or would those be redundant? Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
