Re: protocol questions
2013/3/30 Matthias Clasen matthias.cla...@gmail.com Here are a few questions/observations I had while studying the protocol docs: - The use of serials in events seems a bit inconsistent. Most wl_pointer events have serials, but axis doesn't. wl_keyboard enter/leave events do. wl_data_offer.enter does, but the corresponding leave/motion events don't. Is there a rationale for this ? - Various input events have a time field. The spec doesn't really say anything about this. What is it good for, and what units are these - monotonic time ? The time can be used to calculate whether two clicks are a double click for instance. The timestamps are sent by evdev, and i think they are monotonic, but i'm not sure. - It looks like I can't trigger a popup from a key or touch event, because set_popup requires a serial that corresponds to an implicit pointer grab. That is sad, I like the menu key... Yes, this is a known bug which needs to be addressed. - Still on popups, I don't see a way for the client to dismiss the popup, or is that handled by just destroying the surface ? I think the only other way apart destroying it is unmapping it, that is attaching a null buffer to the surface. - Buffer transformations - fun. How do these relate to each of the following ? - resize edges - transient offset - buffer attach x/y - input/opaque/damage regions - surface x/y in motion events - What is a wl_touch.frame event ? Weston doesn't seem to generate those... - Various strings in the protocol: title, class, output model/make. Are all of these required/known to be UTF-8 ? The class is documented as being a file path, which is bad news wrt to encodings... - The wl_pointer interface seems to be a bit weak wrt to device properties. I would at least expect to learn about the number of buttons and right-handed vs left-handed, etc. Thanks for any insights you can share about these questions. Matthias ___ 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: protocol questions
Hi, On 30 March 2013 05:31, Matthias Clasen matthias.cla...@gmail.com wrote: Here are a few questions/observations I had while studying the protocol docs: - The use of serials in events seems a bit inconsistent. Most wl_pointer events have serials, but axis doesn't. wl_keyboard enter/leave events do. wl_data_offer.enter does, but the corresponding leave/motion events don't. Is there a rationale for this ? Yes: serials are used for events which can be used to trigger other events, e.g. setting the pointer, launching a popup, starting a drag, etc. This is not something you tend to do from scroll or data events. - Various input events have a time field. The spec doesn't really say anything about this. What is it good for, and what units are these - monotonic time ? Monotonic (ideally) time in an undefined domain, i.e. they're only meaningful on relation to each other. - It looks like I can't trigger a popup from a key or touch event, because set_popup requires a serial that corresponds to an implicit pointer grab. That is sad, I like the menu key... Yeah, that'd be great to fix! - Still on popups, I don't see a way for the client to dismiss the popup, or is that handled by just destroying the surface ? Indeed, just destroy the surface or attach a NULL buffer. - Buffer transformations - fun. How do these relate to each of the following ? - resize edges - transient offset - buffer attach x/y - input/opaque/damage regions - surface x/y in motion events All the latter occur on surfaces rather than buffers, so are unaffected. Buffer transforms are meant to support situations like where your screen is rotated 90°, and your client can also render rotated in order to avoid that extra blit. So it doesn't affect the event pipeline at all, only the display pipeline. - What is a wl_touch.frame event ? Weston doesn't seem to generate those... It's meant to indicate a natural boundary between touch events, à la a full EV_SYN. So you'd send touch events for every finger down, followed by frame, at which point you could perform gesture processing. - The wl_pointer interface seems to be a bit weak wrt to device properties. I would at least expect to learn about the number of buttons and right-handed vs left-handed, etc. wl_pointer is an aggregation of mice, not a single mouse, so we can't necessarily sensibly expose number of buttons. For right vs. left-handed, I'd expect the compositor to do the swap and clients never have to worry about it. If you want to expose that configuration, that should occur through private protocol. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 21/21] docs: Add details about grabs
I think that there is a typo in the text, you wrote But there is way for clients to take an explicit grab. Instead, instead of But there is NO way.. BR, renoX ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: protocol questions
On Sat, Mar 30, 2013 at 7:56 AM, Daniel Stone dan...@fooishbar.org wrote: - Various input events have a time field. The spec doesn't really say anything about this. What is it good for, and what units are these - monotonic time ? Monotonic (ideally) time in an undefined domain, i.e. they're only meaningful on relation to each other. What can you do with them ? For the use case that Giulio mentioned (double-click detection), I'd need to know at least if the difference between two times is seconds or milliseconds or microseconds... - Still on popups, I don't see a way for the client to dismiss the popup, or is that handled by just destroying the surface ? Indeed, just destroy the surface or attach a NULL buffer. Good to know. I don't think the spec mentions at all that 'attach NULL buffer' == unmap. - Buffer transformations - fun. How do these relate to each of the following ? - resize edges - transient offset - buffer attach x/y - input/opaque/damage regions - surface x/y in motion events All the latter occur on surfaces rather than buffers, so are unaffected. Buffer transforms are meant to support situations like where your screen is rotated 90°, and your client can also render rotated in order to avoid that extra blit. So it doesn't affect the event pipeline at all, only the display pipeline. That sounds right for resize edgets and motion events, certainly. For some of the others, at least the wording of the spec is not always very clear on this point. E.g. for buffer attach x/y, the wl_surface.attach docs say: The x and y arguments specify the location of the new pending buffer's upper left corner, relative to the current buffer's upper left corner. See how it talks about the current buffer's upper left corner. Should that say 'the surface's upper left corner, then ? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 21/21] docs: Add details about grabs
You are right, thanks. On Sat, Mar 30, 2013 at 9:16 AM, renoX reno...@gmail.com wrote: I think that there is a typo in the text, you wrote But there is way for clients to take an explicit grab. Instead, instead of But there is NO way.. BR, renoX ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston] compositor: add information about the fbdev backend to --help output
--- src/compositor.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/src/compositor.c b/src/compositor.c index c3e6bed..7a656e7 100644 --- a/src/compositor.c +++ b/src/compositor.c @@ -3467,7 +3467,8 @@ usage(int error_code) Core options:\n\n --version\t\tPrint weston version\n -B, --backend=MODULE\tBackend module, one of drm-backend.so,\n - \t\t\t\tx11-backend.so or wayland-backend.so\n + \t\t\t\tfbdev-backend.so, x11-backend.so or\n + \t\t\t\twayland-backend.so\n -S, --socket=NAME\tName of socket to listen on\n -i, --idle-time=SECS\tIdle time in seconds\n --modules\t\tLoad the comma-separated list of modules\n @@ -3483,6 +3484,11 @@ usage(int error_code) --current-mode\tPrefer current KMS mode over EDID preferred mode\n\n); fprintf(stderr, + Options for fbdev-backend.so:\n\n + --tty=TTY\t\tThe tty to use\n + --device=DEVICE\tThe framebuffer device to use\n\n); + + fprintf(stderr, Options for x11-backend.so:\n\n --width=WIDTH\t\tWidth of X window\n --height=HEIGHT\tHeight of X window\n -- 1.8.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston] compositor: don't let weston terminate with dpms set to off if possible
This will not catch the cases where weston crashes, but it's at least
better than the current state.
---
src/compositor.c | 28 +++-
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/src/compositor.c b/src/compositor.c
index a3d1ede..7a656e7 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -3236,10 +3236,15 @@ weston_version(int *major, int *minor, int *micro)
static int on_term_signal(int signal_number, void *data)
{
- struct wl_display *display = data;
+ struct weston_compositor *ec = data;
weston_log(caught signal %d\n, signal_number);
- wl_display_terminate(display);
+
+ /* Turn DPMS back on, so we're not left with a black screen */
+ if (ec-state == WESTON_COMPOSITOR_SLEEPING)
+ weston_compositor_dpms(ec, WESTON_DPMS_ON);
+
+ wl_display_terminate(ec-wl_display);
return 1;
}
@@ -3577,15 +3582,9 @@ int main(int argc, char *argv[])
display = wl_display_create();
loop = wl_display_get_event_loop(display);
- signals[0] = wl_event_loop_add_signal(loop, SIGTERM, on_term_signal,
- display);
- signals[1] = wl_event_loop_add_signal(loop, SIGINT, on_term_signal,
- display);
- signals[2] = wl_event_loop_add_signal(loop, SIGQUIT, on_term_signal,
- display);
wl_list_init(child_process_list);
- signals[3] = wl_event_loop_add_signal(loop, SIGCHLD, sigchld_handler,
+ signals[0] = wl_event_loop_add_signal(loop, SIGCHLD, sigchld_handler,
NULL);
if (!backend) {
@@ -3610,6 +3609,13 @@ int main(int argc, char *argv[])
exit(EXIT_FAILURE);
}
+ signals[1] = wl_event_loop_add_signal(loop, SIGTERM, on_term_signal,
+ ec);
+ signals[2] = wl_event_loop_add_signal(loop, SIGINT, on_term_signal,
+ ec);
+ signals[3] = wl_event_loop_add_signal(loop, SIGQUIT, on_term_signal,
+ ec);
+
catch_signals();
segv_compositor = ec;
@@ -3642,6 +3648,10 @@ int main(int argc, char *argv[])
wl_display_run(display);
out:
+ /* Turn DPMS back on, so we're not left with a black screen */
+ if (ec-state == WESTON_COMPOSITOR_SLEEPING)
+ weston_compositor_dpms(ec, WESTON_DPMS_ON);
+
/* prevent further rendering while shutting down */
ec-state = WESTON_COMPOSITOR_OFFSCREEN;
--
1.8.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: protocol questions
Hi, On 30 March 2013 13:34, Matthias Clasen matthias.cla...@gmail.com wrote: On Sat, Mar 30, 2013 at 7:56 AM, Daniel Stone dan...@fooishbar.orgwrote: - Various input events have a time field. The spec doesn't really say anything about this. What is it good for, and what units are these - monotonic time ? Monotonic (ideally) time in an undefined domain, i.e. they're only meaningful on relation to each other. What can you do with them ? For the use case that Giulio mentioned (double-click detection), I'd need to know at least if the difference between two times is seconds or milliseconds or microseconds... Oh sorry, milliseconds. Just with an undefined base, i.e. they don't necessarily correlate to gettimeofday() or CLOCK_MONOTONIC. - Still on popups, I don't see a way for the client to dismiss the popup, or is that handled by just destroying the surface ? Indeed, just destroy the surface or attach a NULL buffer. Good to know. I don't think the spec mentions at all that 'attach NULL buffer' == unmap. Mapping rules are specific to the surface type, but yes, indeed I can't think of any surface roles where that isn't the case. - Buffer transformations - fun. How do these relate to each of the following ? - resize edges - transient offset - buffer attach x/y - input/opaque/damage regions - surface x/y in motion events All the latter occur on surfaces rather than buffers, so are unaffected. Buffer transforms are meant to support situations like where your screen is rotated 90°, and your client can also render rotated in order to avoid that extra blit. So it doesn't affect the event pipeline at all, only the display pipeline. That sounds right for resize edgets and motion events, certainly. For some of the others, at least the wording of the spec is not always very clear on this point. E.g. for buffer attach x/y, the wl_surface.attach docs say: The x and y arguments specify the location of the new pending buffer's upper left corner, relative to the current buffer's upper left corner. See how it talks about the current buffer's upper left corner. Should that say 'the surface's upper left corner, then ? Yeah, except the wording to be a little more subtle to clarify that that the position change happens a) in surface co-ordinates, and b) when the buffer is attached. But this is the one I'm least sure about, in all honesty. :) Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 0/2] More documentation additions
From: Matthias Clasen mcla...@redhat.com I've received some clarifications on questions I asked about the protocol. These patches add that information to the docs, so it isn't lost. Matthias Clasen (2): docs: Document granularity of timestamps docs: Add information about serials and timestamps doc/Wayland/en_US/Protocol.xml | 16 protocol/wayland.xml | 20 2 files changed, 28 insertions(+), 8 deletions(-) -- 1.8.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: protocol questions
On sábado, 30 de março de 2013 09.34.24, Matthias Clasen wrote: - Various input events have a time field. The spec doesn't really say anything about this. What is it good for, and what units are these - monotonic time ? Monotonic (ideally) time in an undefined domain, i.e. they're only meaningful on relation to each other. What can you do with them ? For the use case that Giulio mentioned (double-click detection), I'd need to know at least if the difference between two times is seconds or milliseconds or microseconds... The protocol needs to specify the unit. It can't be dependent on the device driver, that makes no sense. If it's in milliseconds, it will overflow every 49.7 days. If it's microseconds, it will overflow every 71.6 minutes. It also needs to specify which timestamps are in the same time domain. Can two timestamps be compared to each other only if: - they are in the same input device (same mouse, same keyboard), but not across devices - they are in the same seat, but not across seats - they are in input event messages, but not other types of messages that carry timestamps - no restriction For example, imagine the case of trying to ensure that a Ctrl key was pressed before a mouse click happened, after the events were plucked out of the event stream. Or is there another, recommended way of doing that, such as by using the serials? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] compositor: add information about the fbdev backend to --help output
Hi, Looks good to me. It would be good to add this to man /weston.man too. Thanks, Emilio On 03/30/2013 03:18 PM, Philipp Brüschweiler wrote: --- src/compositor.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/src/compositor.c b/src/compositor.c index c3e6bed..7a656e7 100644 --- a/src/compositor.c +++ b/src/compositor.c @@ -3467,7 +3467,8 @@ usage(int error_code) Core options:\n\n --version\t\tPrint weston version\n -B, --backend=MODULE\tBackend module, one of drm-backend.so,\n - \t\t\t\tx11-backend.so or wayland-backend.so\n + \t\t\t\tfbdev-backend.so, x11-backend.so or\n + \t\t\t\twayland-backend.so\n -S, --socket=NAME\tName of socket to listen on\n -i, --idle-time=SECS\tIdle time in seconds\n --modules\t\tLoad the comma-separated list of modules\n @@ -3483,6 +3484,11 @@ usage(int error_code) --current-mode\tPrefer current KMS mode over EDID preferred mode\n\n); fprintf(stderr, + Options for fbdev-backend.so:\n\n + --tty=TTY\t\tThe tty to use\n + --device=DEVICE\tThe framebuffer device to use\n\n); + + fprintf(stderr, Options for x11-backend.so:\n\n --width=WIDTH\t\tWidth of X window\n --height=HEIGHT\tHeight of X window\n ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] RDP compositor take 5
Hardening,
This is looking really good. I only have a couple comments on the
code below that should take all of 5 minutes to address.
That said, It's segfaulting on me a lot. Most of them seem to have to
do with wl_seat. I really don't know why. Also, it works with
freerdp, but doesn't work with rdesktop; why is this?
--Jason Ekstrand
On Thu, Mar 28, 2013 at 6:40 PM, Hardening rdp.eff...@gmail.com wrote:
Sorry, my previous post was broken.
This patch is the 5th version of the FreeRDP based compositor.
Changes from last version:
* dropped tiling for raw surfaces (not required)
* corrected remoteFx encoding to have all rects of a damage
event into a single remoteFx frame
* added a mode to read the client socket in an env variable
* handle NS codec
* misc corrections after Jason Ekstrand review
* changes to compile against last version of FreeRDP 1.1
---
configure.ac |7 +
src/Makefile.am | 16 +-
src/compositor-rdp.c | 1007
++
3 files changed, 1029 insertions(+), 1 deletion(-)
create mode 100644 src/compositor-rdp.c
diff --git a/configure.ac b/configure.ac
index 355063d..ed06d0b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -168,6 +168,13 @@ AS_IF([test x$enable_fbdev_compositor = xyes], [
PKG_CHECK_MODULES([FBDEV_COMPOSITOR], [libudev = 136 mtdev = 1.1.0])
])
+AC_ARG_ENABLE([rdp-compositor], [ --enable-rdp-compositor],,
+ enable_rdp_compositor=no)
+AM_CONDITIONAL([ENABLE_RDP_COMPOSITOR],
+ [test x$enable_rdp_compositor = xyes])
+if test x$enable_rdp_compositor = xyes; then
+ PKG_CHECK_MODULES(RDP_COMPOSITOR, [freerdp = 1.1.0])
+fi
AC_ARG_WITH(cairo-glesv2,
AS_HELP_STRING([--with-cairo-glesv2],
diff --git a/src/Makefile.am b/src/Makefile.am
index d56daa0..d33ebc5 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -98,7 +98,8 @@ module_LTLIBRARIES = \
$(drm_backend) \
$(wayland_backend) \
$(headless_backend) \
- $(fbdev_backend)
+ $(fbdev_backend)\
+ $(rdp_backend)
noinst_LTLIBRARIES =
@@ -214,6 +215,19 @@ fbdev_backend_la_SOURCES = \
launcher-util.c
endif
+if ENABLE_RDP_COMPOSITOR
+rdp_backend = rdp-backend.la
+rdp_backend_la_LDFLAGS = -module -avoid-version
+rdp_backend_la_LIBADD = $(COMPOSITOR_LIBS) \
+ $(RDP_COMPOSITOR_LIBS) \
+ ../shared/libshared.la
+rdp_backend_la_CFLAGS =\
+ $(COMPOSITOR_CFLAGS)\
+ $(RDP_COMPOSITOR_CFLAGS) \
+ $(GCC_CFLAGS)
+rdp_backend_la_SOURCES = compositor-rdp.c
+endif
+
if ENABLE_DESKTOP_SHELL
desktop_shell = desktop-shell.la
desktop_shell_la_LDFLAGS = -module -avoid-version
diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
new file mode 100644
index 000..95241e5
--- /dev/null
+++ b/src/compositor-rdp.c
@@ -0,0 +1,1007 @@
+/*
+ * Copyright © 2013 Hardening rdp.eff...@gmail.com
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and
+ * its documentation for any purpose is hereby granted without fee, provided
+ * that the above copyright notice appear in all copies and that both that
+ * copyright notice and this permission notice appear in supporting
+ * documentation, and that the name of the copyright holders not be used in
+ * advertising or publicity pertaining to distribution of the software
+ * without specific, written prior permission. The copyright holders make
+ * no representations about the suitability of this software for any
+ * purpose. It is provided as is without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+ * SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+ * FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+ * SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
+ * RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
+ * CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
+ * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
+
+#include stdlib.h
+#include string.h
+#include errno.h
+#include linux/input.h
+
+#include freerdp/freerdp.h
+#include freerdp/listener.h
+#include freerdp/update.h
+#include freerdp/input.h
+#include freerdp/codec/color.h
+#include freerdp/codec/rfx.h
+#include freerdp/codec/nsc.h
+
+#include compositor.h
+#include pixman-renderer.h
+
+#define MAX_FREERDP_FDS 32
+
+struct rdp_compositor_config {
+ int width;
+ int height;
+ char *bind_address;
+ int port;
+ char *rdp_key;
+ char *server_cert;
+ char *server_key;
+ char *extra_modes;
+ int
Re: [PATCH 01/21] docs: Reorder some sections
Ok, so I like moving Compositors up a bit but I'm thinking a more natural place to put it would be after Architecture so that the reader has a better idea of what we mean by a compositor before they start reading about types of compositors. --Jason Ekstrand On Sat, Mar 30, 2013 at 12:11 AM, matthias.cla...@gmail.com wrote: From: Matthias Clasen mcla...@redhat.com Move the 'Types of Compositors' section right after the Overview, and move the 'Client API' part after the protocol spec. --- doc/Wayland/en_US/Wayland.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/Wayland/en_US/Wayland.xml b/doc/Wayland/en_US/Wayland.xml index 30fa3f2..44ccc1d 100644 --- a/doc/Wayland/en_US/Wayland.xml +++ b/doc/Wayland/en_US/Wayland.xml @@ -6,10 +6,10 @@ book xi:include href=Book_Info.xml xmlns:xi=http://www.w3.org/2001/XInclude; / xi:include href=Overview.xml xmlns:xi=http://www.w3.org/2001/XInclude; / + xi:include href=Compositors.xml xmlns:xi=http://www.w3.org/2001/XInclude; / xi:include href=Architecture.xml xmlns:xi=http://www.w3.org/2001/XInclude; / xi:include href=Protocol.xml xmlns:xi=http://www.w3.org/2001/XInclude; / - xi:include href=Library.xml xmlns:xi=http://www.w3.org/2001/XInclude; / - xi:include href=Compositors.xml xmlns:xi=http://www.w3.org/2001/XInclude; / xi:include href=ProtocolSpec.xml xmlns:xi=http://www.w3.org/2001/XInclude; / + xi:include href=Library.xml xmlns:xi=http://www.w3.org/2001/XInclude; / /book -- 1.8.1.4 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 10/21] docs: Improve wl_shm and wl_shm_pool protocol docs
On Sat, Mar 30, 2013 at 12:11 AM, matthias.cla...@gmail.com wrote: From: Matthias Clasen mcla...@redhat.com Reword some paragraphs, and spell out 'file descriptor'. --- protocol/wayland.xml | 73 +++- 1 file changed, 49 insertions(+), 24 deletions(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index cc009eb..31d7ce8 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -196,20 +196,21 @@ The wl_shm_pool object encapsulates a piece of memory shared between the compositor and client. Through the wl_shm_pool object, the client can allocate shared memory wl_buffer objects. - The objects will share the same underlying mapped memory. - Reusing the mapped memory avoids the setup/teardown overhead and - is useful when interactively resizing a surface or for many - small buffers. + All objects created through the same pool share the same + underlying mapped memory. Reusing the mapped memory avoids the + setup/teardown overhead and is useful when interactively resizing + a surface or for many small buffers. Perhaps All wl_buffer objects would be better /description request name=create_buffer - description summary=create wl_buffer from pool - Create a wl_buffer from the pool. The buffer is created a - offset bytes into the pool and has width and height as - specified. The stride arguments specifies the number of bytes - from beginning of one row to the beginning of the next. The - format is the pixel format of the buffer and must be one of - those advertised through the wl_shm.format event. + description summary=create a buffer from the pool + Create a wl_buffer object from the pool. Should go in summary + + The buffer is created offset bytes into the pool and has + width and height as specified. The stride arguments specifies + the number of bytes from beginning of one row to the beginning + of the next. The format is the pixel format of the buffer and + must be one of those advertised through the wl_shm.format event. A buffer will keep a reference to the pool it was created from so it is valid to destroy the pool immediately after creating @@ -226,15 +227,19 @@ request name=destroy type=destructor description summary=destroy the pool - Destroy the pool. + Destroy the shared memory pool. Summary + + The mmapped memory will be released when all + buffers that have been created from this pool + are gone. /description /request request name=resize description summary=change the size of the pool mapping This request will cause the server to remap the backing memory - for the pool from the fd passed when the pool was creating but - using the new size. + for the pool from the file descriptor passed when the pool was + created, but using the new size. /description arg name=size type=int/ @@ -243,26 +248,41 @@ interface name=wl_shm version=1 description summary=shared memory support - Support for shared memory buffers. + A global singleton object that provides support for shared + memory. + + Clients can create wl_shm_pool objects using the create_pool + request. + + At connection setup time, the wl_shm object emits one or more + format events to inform clients about the valid pixel formats + that can be used for buffers. /description enum name=error - entry name=invalid_format value=0/ - entry name=invalid_stride value=1/ - entry name=invalid_fd value=2/ + description summary=wl_shm error values + These errors can be emitted in response to wl_shm requests. + /description + entry name=invalid_format value=0 summary=buffer format is not known/ + entry name=invalid_stride value=1 summary=invalid size or stride during pool or buffer creation/ + entry name=invalid_fd value=2 summary=mmapping the file descriptor failed/ /enum enum name=format - entry name=argb value=0/ - entry name=xrgb value=1/ + description summary=pixel formats + This describes the memory layout of an individual pixel. + /description + entry name=argb value=0 summary=32-bit ARGB format/ + entry name=xrgb value=1 summary=32-bit RGB format/ /enum request name=create_pool description summary=create a shm pool - This creates wl_shm_pool object, which can be used to create - shared memory based wl_buffer objects. The server will mmap - size bytes of the passed fd, to use as backing memory for then - pool. + Create a new wl_shm_pool object. summary + + The pool can be
Re: [PATCH 11/21] docs: Improve the wl_data_* procol docs
Matthias, A few general comments about this one. First, there are several places where you change the name of an argument to a function. While I think this technically doesn't break anything, we need to be careful here. The wayland protocol definition is a public API so we can't just go around changing it. Updating descriptions is just fine. Feel free to ask Kristian and get a different answer, but I think we should leave argument names alone. My other comment is that we should avoid documentation for the sake of documentation. I'll admit that the protocol documentation is currently vary sparse and it needs to be fleshed out. However, added comments don't necessarily add anything. One example is the destroy request below. It's pretty obvious from the name exactly what that request does. Adding documentation at that point is simply information redundancy that the reader has to sort through. More comments below. --Jason Ekstrand On Sat, Mar 30, 2013 at 12:11 AM, matthias.cla...@gmail.com wrote: From: Matthias Clasen mcla...@redhat.com Add a few missing summaries and descriptions, spell out file descriptor, use hyphens in drag-and-drop, don't use hyphens in 'mime type', and reword a few things. --- protocol/wayland.xml | 95 +++- 1 file changed, 65 insertions(+), 30 deletions(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 31d7ce8..2417c0e 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -348,22 +348,26 @@ /description request name=accept - description summary=accept one of the offered mime-types - Indicate that the client can accept the given mime-type, or - NULL for not accepted. Use for feedback during drag and drop. + description summary=accept one of the offered mime types + Indicate that the client can accept the given mime type, or + NULL for not accepted. + + Used for feedback during drag-and-drop. /description arg name=serial type=uint/ - arg name=type type=string allow-null=true/ + arg name=mime_type type=string allow-null=true/ /request request name=receive description summary=request that the data is transferred To transfer the offered data, the client issues this request - and indicates the mime-type it wants to receive. The transfer - happens through the passed fd (typically a pipe(7) file - descriptor). The source client writes the data in the - mime-type representation requested and then closes the fd. + and indicates the mime type it wants to receive. The transfer + happens through the passed file descriptor (typically created + with the pipe system call). The source client writes the data + in the mime type representation requested and then closes the + file descriptor. Actually, we should leave that as pipe(7) It's common UNIX documentation convention because it tells the reader which man page to read. + The receiving client reads from the read end of the pipe until EOF and the closes its end, at which point the transfer is complete. @@ -372,15 +376,19 @@ arg name=fd type=fd/ /request -request name=destroy type=destructor/ +request name=destroy type=destructor + description summary=destroy data offer + Destroy the data offer. + /description +/request I don't think this really adds anything. event name=offer - description summary=advertise offered mime-type + description summary=advertise offered mime type Sent immediately after creating the wl_data_offer object. One event per offered mime type. /description - arg name=type type=string/ + arg name=mime_type type=string/ /event /interface @@ -394,11 +402,11 @@ request name=offer description summary=add an offered mime type - This request adds a mime-type to the set of mime-types + This request adds a mime type to the set of mime types advertised to targets. Can be called several times to offer multiple types. /description - arg name=type type=string/ + arg name=mime_type type=string/ /request request name=destroy type=destructor @@ -408,9 +416,11 @@ /request event name=target - description summary=a target accepts an offered mime-type + description summary=a target accepts an offered mime type Sent when a target accepts pointer_focus or motion events. If a target does not accept any of the offered types, type is NULL. + + Used for feedback during drag-and-drop. /description arg name=mime_type type=string allow-null=true/ @@ -418,8 +428,9 @@ event name=send description summary=send the data - Request for data from another
Re: [PATCH 00/21] Documentation improvements
Matthias, First, I want to reiterate my thanks for working on this. There's a lot that could use some filling in. In general, I think you're doing a great job. There are a lot of little consistency things that you're fixing as well as grammar problems etc. That said, I think I'm done reading your changes for now. At this point, I find myself mostly making the same comments over and over again. So, instead of going through it line-by-line, I'll make my comments in one place here and wait for the second version. 1. I said this in one of the e-mails, but avoid unneeded documentation. The documentation as is is fairly sparse and needs to be filled in. However, too much documentation can sometimes be a bad thing too. For example, on events called destroy it's pretty obvious what it does: It destroys the object. Adding a comment really doesn't help and just makes for more to wade through. Also, you have a lot of the serial of the X event comments. Again, these don't really add anything. If there is something special or noteworthy about the serial argument on a particular event, go ahead and document it. 2. There are several places where you add a one-line summary at the beginning of the documentation block. This is what the summary tag is for. Having it as a single line at the top of the block as well will simply make people more confused. Particularly if the wayland XML is used go generate comments that are to be parsed by something like doxygen or javadoc. That said, fixing capitalization in the summaries wouldn't be bad. I have a few more general comments at the tops of the reply e-mails I sent out. Keeping all this in mind, I'd like you to go back through and make a second version. Looks good so far! --Jason Ekstrand On Sat, Mar 30, 2013 at 3:42 PM, Jason Ekstrand ja...@jlekstrand.net wrote: Matthias, Thanks for working on this! My brief reading indicates that you've done a pretty good job over-all. I'm going throgh your patches now and so you can expect patch-by-patch comments shortyly. --Jason Ekstrand On Sat, Mar 30, 2013 at 12:11 AM, matthias.cla...@gmail.com wrote: From: Matthias Clasen mcla...@redhat.com Hi, I spent some time going over the documentation, trying to fill gaps in my understanding - and in the documentation. Here are the resulting patches. Matthias Clasen (21): docs: Reorder some sections docs: Slight rewording docs: Improve the 'Types of Compositors' section docs: Improve the 'Connect time' section doc: Improve various sections of the documentation docs: Consistency fixes docs: Improve wl_display protocol docs docs: Improve the wl_registry protocol docs docs: Improve wl_callback protocol docs docs: Improve wl_shm and wl_shm_pool protocol docs docs: Improve the wl_data_* procol docs docs: Improve wl_shell/wl_shell_surface docs docs: Improve wl_surface protocol docs docs: Improve the wl_seat protocol docs docs: Improve wl_pointer protocol docs docs: Improve wl_keyboard protocol docs docs: Improve wl_touch protocol docs docs: Improve the wl_output protocol docs docs: Improve wl_region protocol docs docs: Add details about surfaces docs: Add details about grabs doc/Wayland/en_US/Compositors.xml | 119 +++--- doc/Wayland/en_US/Protocol.xml| 108 +++--- doc/Wayland/en_US/Wayland.xml | 4 +- protocol/wayland.xml | 768 +- 4 files changed, 598 insertions(+), 401 deletions(-) -- 1.8.1.4 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 2/2] docs: Add information about serials and timestamps
On Sat, Mar 30, 2013 at 1:09 PM, matthias.cla...@gmail.com wrote: From: Matthias Clasen mcla...@redhat.com Add some information about serials, timestamps and their uses to the Input section in the protocol overview. --- doc/Wayland/en_US/Protocol.xml | 16 1 file changed, 16 insertions(+) diff --git a/doc/Wayland/en_US/Protocol.xml b/doc/Wayland/en_US/Protocol.xml index b94e9ca..5c7ef76 100644 --- a/doc/Wayland/en_US/Protocol.xml +++ b/doc/Wayland/en_US/Protocol.xml @@ -241,6 +241,22 @@ with a pointer grab. /para para + To avoid race conditions, input events that are likely to + trigger further requests (such as button presses, key events, + pointer motions) carry serial numbers, and requests such as + wl_surface.set_popup require that the serial number of the + triggering event is specified. The server maintains a + monotonically increasing counter for these serial numbers. +/para +para + Input events also carry timestamps with millisecond granularity. + Their base is undefined, so they can't be compared against + system time (as obtained with clock_gettime or gettimeofday). + They can be compared with each other though, and for instance + be used to identify sequences of button presses as double + or triple clicks. I think this should be re-worded. It's correct, it just seems awkward. For example: Input events also carry timestamps in milliseconds. The base for these timestamps is left up to the compositor. Therefore, they should not be compared against anything except other compositor-provided timestamps. +/para +para See xref linkend=protocol-spec-interface-wl_seat/ for the protocol description. /para -- 1.8.2 ___ 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] docs: Add a note about unmapping surfaces without content
Looks Good! --Jason Ekstrand On Sat, Mar 30, 2013 at 1:36 PM, matthias.cla...@gmail.com wrote: From: Matthias Clasen mcla...@redhat.com Explanation received on wayland-devel indicates that it is expected compositor behaviour to unmap surfaces without content. --- protocol/wayland.xml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 718a4a5..548b1b9 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -923,6 +923,9 @@ Only if wl_surface.attach is sent with a NULL wl_buffer, the following wl_surface.commit will remove the surface content. +It is up to the compositor implementation how it will treat +a surface without content; a common behaviour is to unmap +the surface until it gets defined content again. /description arg name=buffer type=object interface=wl_buffer allow-null=true/ -- 1.8.2 ___ 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 1/2] docs: Document granularity of timestamps
I don't know that these extra comments are needed. This information is provided in the protocol documentation. Also, if we do want them, timestamp in milliseconds seems nicer to read than timestamp with millisecond granularity. --Jason Ekstrand On Sat, Mar 30, 2013 at 1:09 PM, matthias.cla...@gmail.com wrote: From: Matthias Clasen mcla...@redhat.com This information is necessary to make any use of these fields. --- protocol/wayland.xml | 20 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 2a27b1b..718a4a5 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -543,7 +543,7 @@ is provided by the x an y arguments, in surface local coordinates. /description - arg name=time type=uint/ + arg name=time type=uint summary=timestamp with millisecond granularity/ arg name=x type=fixed/ arg name=y type=fixed/ /event @@ -1249,7 +1249,7 @@ focused surface. /description - arg name=time type=uint/ + arg name=time type=uint summary=timestamp with millisecond granularity/ arg name=surface_x type=fixed/ arg name=surface_y type=fixed/ /event @@ -1269,10 +1269,12 @@ The location of the click is given by the last motion or enter event. +The time argument is a timestamp with millisecond +granularity, with an undefined base. /description arg name=serial type=uint/ - arg name=time type=uint/ + arg name=time type=uint summary=timestamp with millisecond granularity/ arg name=button type=uint/ arg name=state type=uint/ /event @@ -1305,7 +1307,7 @@ scroll distance. /description - arg name=time type=uint/ + arg name=time type=uint summary=timestamp with millisecond granularity/ arg name=axis type=uint/ arg name=value type=fixed/ /event @@ -1368,10 +1370,12 @@ event name=key description summary=key event A key was pressed or released. +The time argument is a timestamp with millisecond +granularity, with an undefined base. /description arg name=serial type=uint/ - arg name=time type=uint/ + arg name=time type=uint summary=timestamp with millisecond granularity/ arg name=key type=uint/ arg name=state type=uint/ /event @@ -1408,7 +1412,7 @@ of its surfaces. /description arg name=serial type=uint/ - arg name=time type=uint/ + arg name=time type=uint summary=timestamp with millisecond granularity/ arg name=surface type=object interface=wl_surface/ arg name=id type=int summary=ID of the touch sequence/ arg name=x type=fixed/ @@ -1420,7 +1424,7 @@ Notifies the client that a touch has ended. /description arg name=serial type=uint/ - arg name=time type=uint/ + arg name=time type=uint summary=timestamp with millisecond granularity/ arg name=id type=int/ /event @@ -1429,7 +1433,7 @@ Notifies the client that the position of a contact point has changed. /description - arg name=time type=uint/ + arg name=time type=uint summary=timestamp with millisecond granularity/ arg name=id type=int summary=ID of the touch sequence/ arg name=x type=fixed/ arg name=y type=fixed/ -- 1.8.2 ___ 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: protocol questions
What about long int type to store the time stamps? Even in microseconds it will take longer than 100 years to overflow 2^63. NK On Sat, Mar 30, 2013 at 9:55 AM, Thiago Macieira thiago.macie...@intel.comwrote: On sábado, 30 de março de 2013 09.34.24, Matthias Clasen wrote: - Various input events have a time field. The spec doesn't really say anything about this. What is it good for, and what units are these - monotonic time ? Monotonic (ideally) time in an undefined domain, i.e. they're only meaningful on relation to each other. What can you do with them ? For the use case that Giulio mentioned (double-click detection), I'd need to know at least if the difference between two times is seconds or milliseconds or microseconds... The protocol needs to specify the unit. It can't be dependent on the device driver, that makes no sense. If it's in milliseconds, it will overflow every 49.7 days. If it's microseconds, it will overflow every 71.6 minutes. It also needs to specify which timestamps are in the same time domain. Can two timestamps be compared to each other only if: - they are in the same input device (same mouse, same keyboard), but not across devices - they are in the same seat, but not across seats - they are in input event messages, but not other types of messages that carry timestamps - no restriction For example, imagine the case of trying to ensure that a Ctrl key was pressed before a mouse click happened, after the events were plucked out of the event stream. Or is there another, recommended way of doing that, such as by using the serials? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ 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: protocol questions
On sábado, 30 de março de 2013 17.52.33, Nick Kisialiou wrote: What about long int type to store the time stamps? Even in microseconds it will take longer than 100 years to overflow 2^63. That requires changing the protocol. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] protocol: Introduce logical surface protocol
Hi, On 30 March 2013 20:40, Jason Ekstrand ja...@jlekstrand.net wrote: On Fri, Mar 29, 2013 at 12:02 PM, Daniel Stone dan...@fooishbar.org wrote: Yeah, we need to define API here. For EGL, it'd be a matter of the EGL implementation sending an event in between register_buffer and buffer_available, such that when you called eglCreateImageKHR(egl_dpy, EGL_WAYLAND_FOREIGN_BUFFER_WL, buffer), it would be able to supply an EGLImage. To go to a SHM buffer would almost certainly require a round trip, in order to ensure synchronisation with GL. (Which would hopefully be done by the client rather than the compositor, especially if it involves ReadPixels ...) Ok, I guess I can see that working. It still seems somewhat ill-defined to me, but maybe that's because I just don't know mesa internals well enough. Well, it's the counterpart to the server side: in the compositor, when we bind a wl_buffer with EGL_WAYLAND_BUFFER_WL, 'something' occurs such that the pointer to a Wayland buffer object magically becomes a valid bound EGLImage. The details are completely implementation-specific; wl_drm passes a GEM handle, other implementations pass file descriptors or physical memory addresses, synchronisation is implementation-specific, etc etc. One question worth answering: Why don't we just have a wl_embeded_compositor interface and make the web pages or whatever clients to this? It could be a really simple interface. It really doesn't take that much work to set up the basics for a compositor. If you're worried about having to write code to handle inputs, you'll have to do that yourself anyway if the client is planning to composite the foreign surface itself. I'm not seeing a whole lot of benefit over the nested compositors approach particularly when you think about the complexity we're adding. It's a good question. The main reason for me comes down to this: we have two totally valid usecases, one of which calls for the surface being embedded as a subsurface, and the parent process not being involved beyond that. If we force the parent process to be involved, we're incurring unnecessary context switches and latency. So I'm taking it as a given that we need a child buffer attachment to its surface needs to hit the real compositor with no added copies or even context switches. However, the other totally valid usecase calls for in-client compositing through rendering APIs such as GL (e.g. embedding a WebGL scene or video with a CSS transform). For that case, we need the client to essentially act as a subcompositor. But getting all that plumbing in is a massive amount of work - especially for every browser which has to implement it - and it means that the two different usecases are hitting totally, totally different paths. I don't think it'll be a net win in terms of either predictably working, long-term maintainability, or even conceptual clarity. I'll happily accept that the two usecases are orthogonal though, and perhaps with some modifications to the subsurface protocol, we could split the protocols into a simple wl_foreign_subsurface (for the server compositing_mode), and wl_foreign_composited_surface (client compositing_mode) with all the client-side buffer handling. Would that help? Cheers, Daniel But yeah, this is why I split the events: one to provide the new_id for the buffer, another to let the client know it was available for use, and then all manner of private protocol in between to actually enable those target APIs to use the buffer. Thanks for taking a look! Cheers, Daniel On Mar 29, 2013 11:06 AM, Daniel Stone dan...@fooishbar.org wrote: Hi Jonas, On 17 March 2013 09:13, Jonas Ådahl jad...@gmail.com wrote: A logical surface is a special kind of surface that never gets its own buffer attached, or opaque region set etc. It is obtained by using a surface handle that can be shared in some way between clients. A handle is a server wide unique identifier retrieved from the server given a real surface. Currently a logical surface is limited to only be usable as a sub-surface. I've been thinking about exactly the same thing, but with additional complications to the usecases. There are two I think we need to support: - export a surface from client A such client B can create a subsurface with it - export a surface from client A such that client B can act as its own compositor, i.e. being notified of incoming buffers and being able to import them The latter is required for things like WebGL where you end up rendering to a transformed surface. I do really like the acquire_handle vs. release_handle semantics, but I've gone a slightly different way here. For the exporting client (let's call it the child), the surface becomes a new surface role, which is only capable of being exported; it can't, e.g., be a shell surface at the same time. For the importing client, it gets a
Re: [PATCH 03/21] docs: Improve the 'Types of Compositors' section
Hi, On 30 March 2013 20:48, Jason Ekstrand ja...@jlekstrand.net wrote: Some of this stuff has been somewhat re-defined lately and may not be up-to-date. You may want to talk to Kristian or Daniel and see what the current line-of-thought on types of compositors is. I like the fact that you expanded on things quite a bit. I'm kinda flattered, but also a very poor person to ask about the current state of system vs. session compositors. :) Cheers, Daniel --Jason Ekstrand On Sat, Mar 30, 2013 at 12:11 AM, matthias.cla...@gmail.com wrote: From: Matthias Clasen mcla...@redhat.com Turn the bullet-point lists into full paragraphs. --- doc/Wayland/en_US/Compositors.xml | 119 +++--- 1 file changed, 46 insertions(+), 73 deletions(-) diff --git a/doc/Wayland/en_US/Compositors.xml b/doc/Wayland/en_US/Compositors.xml index d5311fa..f674776 100644 --- a/doc/Wayland/en_US/Compositors.xml +++ b/doc/Wayland/en_US/Compositors.xml @@ -5,57 +5,53 @@ ] chapter id=chap-Compositors titleTypes of Compositors/title + + para +Compositors come in different types, depending on which +role they play in the overall architecture of the OS. + /para + section id=sect-Compositors-System-Compositor titleSystem Compositor/title para - itemizedlist - listitem - para - ties in with graphical boot - /para - /listitem - listitem - para - hosts different types of session compositors - /para - /listitem - listitem - para - lets us switch between multiple sessions (fast user switching, - secure/personal desktop switching) - /para - /listitem - listitem - para - multiseat - /para - /listitem - listitem - para - linux implementation using libudev, egl, kms, evdev, cairo - /para - /listitem - listitem - para - for fullscreen clients, the system compositor can reprogram the - video scanout address to source from the client provided buffer. - /para - /listitem - /itemizedlist + A system compositor can run from early boot until shutdown. + It effectively replaces the kernel vt system, and can tie in + with the systems graphical boot setup and multiseat support. +/para +para + A system compositor can host different types of session + compositors, and let us switch between multiple sessions + (fast user switching, or secure/personal desktop switching). +/para +para + A linux implementation of a system compositor will typically + use libudev, egl, kms, evdev and cairo. +/para +para + For fullscreen clients, the system compositor can reprogram the + video scanout address to read directly from the client provided + buffer. Does this really need to be 4 separate paragraphs? /para /section section id=sect-Compositors-Session-Compositor titleSession Compositor/title para + A session compositor is responsible for a single user session. + If a system compositor is present, the session compositor will + run nested under the system compositor. Nesting is feasible because + the protocol is asynchronous; roundtrips would be too expensive + when nesting is involved. If no system compositor is present, a + session compositor can run directly on the hw. + /para + para + X applications can continue working under a session compositor + by means of a root less X server that is activated on demand. + /para +para + Possible examples for session compositors include itemizedlist - listitem - para - nested under the system compositor. nesting is feasible because - protocol is async, roundtrip would break nesting - /para - /listitem - listitem - para +listitem + para gnome-shell /para /listitem @@ -66,17 +62,12 @@ /listitem listitem para - compiz? - /para - /listitem - listitem - para - kde compositor? + kwin /para /listitem listitem para - text mode using vte + kmscon /para /listitem listitem @@ -89,29 +80,17 @@ fullscreen X session under wayland /para /listitem - listitem - para - can run without system compositor, on the hw where it makes - sense - /para -
Re: [PATCH 2/2] docs: Add information about serials and timestamps
Hi, On 30 March 2013 22:37, Jason Ekstrand ja...@jlekstrand.net wrote: I think this should be re-worded. It's correct, it just seems awkward. For example: Input events also carry timestamps in milliseconds. The base for these timestamps is left up to the compositor. Therefore, they should not be compared against anything except other compositor-provided timestamps. I think 'unspecified' provides a little more clarity than 'left up to the compositor', but that really is bikeshedding. :) Even then though, I think you're guaranteeing too much: I'm not sure we even currently guarantee that timestamps are comparable across all compositor interfaces. They certainly have to be comparable per-interface, but that's it I think. Kristian? Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: protocol questions
Hi, On 30 March 2013 16:55, Thiago Macieira thiago.macie...@intel.com wrote: On sábado, 30 de março de 2013 09.34.24, Matthias Clasen wrote: Monotonic (ideally) time in an undefined domain, i.e. they're only meaningful on relation to each other. What can you do with them ? For the use case that Giulio mentioned (double-click detection), I'd need to know at least if the difference between two times is seconds or milliseconds or microseconds... The protocol needs to specify the unit. It can't be dependent on the device driver, that makes no sense. If it's in milliseconds, it will overflow every 49.7 days. If it's microseconds, it will overflow every 71.6 minutes. Yes, they are in milliseconds, I just explained it poorly. It also needs to specify which timestamps are in the same time domain. Can two timestamps be compared to each other only if: - they are in the same input device (same mouse, same keyboard), but not across devices - they are in the same seat, but not across seats - they are in input event messages, but not other types of messages that carry timestamps - no restriction Personally, I think either #1 or #2. Definitely not #3 or #4. We want to be able to use the evdev timestamps rather than gettimeofday() when we receive it, so we can ensure that if someone clicks twice slowly, and the compositor takes a while to process the same event, it's not interpreted as a double-click. For example, imagine the case of trying to ensure that a Ctrl key was pressed before a mouse click happened, after the events were plucked out of the event stream. Or is there another, recommended way of doing that, such as by using the serials? Hmmm. I was going to say using the event order, but it all depends on which order the devices were read in. So I guess for this case we'd need to go with #2. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
More about clipboard and selection in wayland
Hi, I have already sent a email about the clipboard and selection in wayland a few weeks ago[1] (mainly about middle button paste). After reading more about clipboard and selection protocol in wayland, I have more questions about the limitation of the protocol. 1, as mentioned in my previous email[1], there is no support for middle button paste right now. This is totally different from either normal clipboard or dnd. (p.s. If this is added in the future, what should be the name of it since the clipboard right now is taking the name selection). 2, about clipboard manager (or the similar function provided by clipboard manager in X11). The bear protocol doesn't seems to support selection access after a program quit (not to mention other advanced features provided by clipboard manager like clipboard history). Krh mentioned in a bug report[2] that there is a more advanced implementation in weston now, but the only thing I have found that may be related is the src/clipboard.c file in weston, which at least doesn't work out-of-box for weston-terminal. Is that a simple implementation of clipboard manager in the compositor? Any documentation how it should work? Haven't found any documentation about what the application should do (e.g. info the clipboard manager or at least the compositor about going to exit) in order to support it. IMHO, it is still a good idea to make it possible for having a standalone clipboard manager to provide some advanced feature. 3, about clipboard access and monitoring. According to the protocol, the client will only receive wl_data_device::data_offer event and the wl_data_offer object will only be valid when the client has a input focus. Why is this constraint added, This means 1) It is impossible to monitor the clipboard (since the client will not always have a focus) 2) it is impossible for a cli clipboard access, both of which are useful features that are possible (and easy) to implement in X. Having to provide a serial and having ::accept and ::recieve as separate request/event make this even harder. Is there any reason this is designed in such a way? [1] http://www.mail-archive.com/wayland-devel@lists.freedesktop.org/msg07467.html [2] https://bugs.freedesktop.org/show_bug.cgi?id=52077#c1 Yichao Yu ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/21] Documentation improvements
On Sat, Mar 30, 2013 at 6:32 PM, Jason Ekstrand ja...@jlekstrand.net wrote 1. I said this in one of the e-mails, but avoid unneeded documentation. The documentation as is is fairly sparse and needs to be filled in. However, too much documentation can sometimes be a bad thing too. For example, on events called destroy it's pretty obvious what it does: It destroys the object. Adding a comment really doesn't help and just makes for more to wade through. Also, you have a lot of the serial of the X event comments. Again, these don't really add anything. If there is something special or noteworthy about the serial argument on a particular event, go ahead and document it. No doubt, there can be too much verbiage in docs. But I don't think the wayland protocol docs are even close the point of 'too much documentation'. And since the spec that needs to be precise enough to guarantee interoperatibility, you shouldn't assume that anything is obvious. Your example proves the point: an event does not do anything, it just informs you about something. You thought it was obvious and got it wrong... 2. There are several places where you add a one-line summary at the beginning of the documentation block. This is what the summary tag is for. Having it as a single line at the top of the block as well will simply make people more confused. Particularly if the wayland XML is used go generate comments that are to be parsed by something like doxygen or javadoc. That said, fixing capitalization in the summaries wouldn't be bad. For judging formatting questions like this, I recommend proof-reading the generated docs. That's what I looked at when making those changes. I have a few more general comments at the tops of the reply e-mails I sent out. Keeping all this in mind, I'd like you to go back through and make a second version. Looks good so far! Sure. It might be a while before I find another chunk of time to sink into this, though. Thanks for the review ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
