[PATCH wayland-web] Updated additional dependencies for a cleaner Ubuntu 12.04 LTS system.
--- ubuntu12.04.html | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/ubuntu12.04.html b/ubuntu12.04.html index 804433e..7576fd4 100644 --- a/ubuntu12.04.html +++ b/ubuntu12.04.html @@ -15,7 +15,8 @@ Building Weston on Ubuntu 12.04/h1 XWayland on an Ubuntu 12.04 LTS system, on May 23rd, 2014. This system had previously been used to compile Xlib programs, and thus already had some dependencies (such as git, the compiler, and X11 header files) -installed./p +installed. Dependencies were last updated from a successful build +on October 20th, 2014./p pParallel make (codemake -j 9/code) will probably work on all packages but only the ones shown were compiled this way./p @@ -39,6 +40,7 @@ mkdir -p $ACLOCAL_PATH span class=comment# dependencies for libwayland:/span sudo apt-get install doxygen span class=comment# or use --disable-documentation/span +sudo apt-get install xmlto span class=comment# or use --disable-documentation/span span class=comment# libwayland-*:/span git clone git://anongit.freedesktop.org/wayland/wayland @@ -253,6 +255,12 @@ cd libxkbfile make amp;amp; make install cd .. +git clone git://anongit.freedesktop.org/xorg/proto/scrnsaverproto +cd scrnsaverproto +./autogen.sh --prefix=$WLD +make amp;amp; make install +cd .. + span class=comment# XWayland:/span git clone git://anongit.freedesktop.org/xorg/xserver cd xserver -- 1.7.12 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Reusing wl_egl_window for multiple EGL surfaces
On Sat, 25 Oct 2014 17:14:32 -0700 Virtual Presence virtualpresence.u...@gmail.com wrote: Hi, I am writing a simple multi-threaded multi-context GLES2 Wayland client. As required by Wayland and MESA EGL bindings i do create a wl_egl_window to pass on to EGL window surface creation. I was wondering if there is any spec or rule that disallows reuse of the same wl_egl_window for multiple EGLWindowSurface. I was wondering if i could use the same underlying wl_egl_window resize bindings to cause multiple resizes. If i cannot do the same i would like to know of a spec/rule/guide (say like an EGL spec) that lists all the creation, management, deletion and usage of this object. Hi, I cannot understand what you could possibly achieve by creating several EGLSurfaces for the same window. What do you want to do? Are you perhaps attempting to render different parts of a single window in different GL contexts and so using different EGLSurfaces with some clipping magic? Maybe relying that GLX (not EGL IIRC!) required the color buffers to be shared between clients/contexts? Or do you simply want a dummy EGLSurface for each context, and then use FBOs to do the work, without ever calling eglSwapBuffers except for the one context that actually draws in the window? Because there are no Pixmaps in EGL Wayland? I can't quote a spec off-hand, but I know the EGL Wayland platform does not support partial rendering. Every time you call eglSwapBuffers, the whole buffer content must be valid, as the display server is free to take the whole buffer as the new window contents. That's actually a Wayland specification: every buffer must be completely drawn, as the display server is allowed to use all of it, even if the associated damage is only a part of it. So, I don't think it is explicitly forbidden anywhere to create several EGLSurfaces for the same wl_egl_window, but it just doesn't make sense. The different (E)GL contexts using the different EGLSurfaces would be fighting over whose buffer ends up on screen. As such, I expect that case to be untested, and so likely hit bugs. FWIW, you'd be looking for an EGL Wayland platform specification, and one has not been written AFAIK, as has not been written for many of the other platforms either. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH Weston 1/1] desktop-shell: implement autolaunch
On Fri, 24 Oct 2014 14:47:00 -0700 Bryce Harrington br...@osg.samsung.com wrote: On Fri, Oct 24, 2014 at 01:18:51PM +0300, Pekka Paalanen wrote: And, while you're at it - as this was written for kiosk mode, it spawns a shell script which just restarts the video player in a loop. Can we please add an autostart param to weston_client_run/start (as a new enum with WESTON_CLIENT_RESTART, not bool) and to the config (as a bool) which lifts most of desktop_shell_client_destroy/check_desktop_shell_crash_too_early/respawn_desktop_shell_process? I'm not sure that's feasible. Watching the process exit is not used to trigger respawn for weston-desktop-shell, but losing the wl_client is. These two events happen in arbitrary order, and we recently fixed a related bug by exactly not respawning based on process exit. We want weston-desktop-shell to respawn if the compositor disconnects it, even if the actual process gets left behind due to malfunction. Restart for autolaunch OTOH would be based on process exit rather than losing the connection. IOW, weston_client_start() and the existing respawn mechanism are intended for special purpose known clients, while the panel launchers and the autolaunch feature are meant for running arbitrary programs (that might not even be clients themselves/directly or at all). I'm not sure if adding restart to autolaunch is in scope... there are many aspects to configure for restart (delays, when to give up) so I'd rather maybe keep with the script. Or systemd user session. After all, the autolaunch is just a quick'n'useful hack when no session manager (systemd or other) is available. Hmm, the several special cases / hacks here maybe suggests some generalization is needed? The two cases I described are very different. weston_client_start() is usually used to launch DE helper applications that need special privileges, and therefore the Wayland connection is created before-hand. It is part of our security mechanisms. What would you refactor here? Also, for X, there is typically a .xinitrc, .gnomerc, or similar that's executed as a shell script during system launch. Do we have plans for adding something similar for weston? Like a .westonrc? This patch adds exactly that. Well, a place to tell what to execute automatically when the compositor becomes ready, anyway. Btw. there is already also the primary client feature in Weston. An application may launch Weston and be the only normal client to Weston then. Weston will quit when this client disconnects. It is controlled by WESTON_SERVER_SOCKET environment variable, which is set to an open file descriptor number. Weston does not create a listening socket in this case. Obviously that is a very different case than start-up scripts. If not, perhaps this feature gives us a place for hanging startup scripts? Yes. We already have lots of logic to find a weston.ini file, why would we add more logic to similarly find a .westonrc? We can just say in weston.ini what to execute. I think that is also more clear, because the only file that Weston needs to find on its own is weston.ini, and so it's a single point of failure rather than finding two, if something goes wrong. Note, that you can have any number of autolaunch entries. You don't need a separate script if you just start a bunch of one-off apps. (Not saying that shell scripts are the best way to do autostart of applications, but it has been a tradition...) Well, if you are building a DE, you write a plugin for it in any case, and that plugin can then spawn and manage the helper apps if it needs to. This autolaunch on the other hand is very much a hack, which is useful in the odd cases where writing a plugin is not appropriate. A demo setup that automatically starts a video player at boot, for instance, which is the very case behind this patch. One might see this similar to script based init vs. systemd. I do like systemd, but I don't think we should make Weston a generic process manager. For the odd hacks, being able to run scripts and other random stuff just via weston.ini is useful. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland 1/2] tests: add test for callback serials
The callback returns always with the same serial,
which is not right (it's serial, not constant...).
This test highlights the bug.
Signed-off-by: Marek Chalupa mchqwe...@gmail.com
---
tests/display-test.c | 55
1 file changed, 55 insertions(+)
diff --git a/tests/display-test.c b/tests/display-test.c
index a1e45b1..eb4ba1c 100644
--- a/tests/display-test.c
+++ b/tests/display-test.c
@@ -593,3 +593,58 @@ TEST(threading_read_after_error_tst)
display_destroy(d);
}
+
+static void
+sync_callback(void *data, struct wl_callback *wl_callback, uint32_t serial)
+{
+ int *got = data;
+ static uint32_t last_serial = 0;
+
+ /* if this is the first callback, just copy the value of serial */
+ if (*got == 0)
+ last_serial = serial;
+ else
+ ++last_serial;
+
+ /* since we only call display_sync, nothing else can increase the
+* serial, so the serails must be sequential */
+ assert(serial == last_serial
+ Serial is not sequential);
+
+ ++(*got);
+}
+
+static const struct wl_callback_listener sync_listener = {
+ sync_callback
+};
+
+#define CB_NUM 1000
+static void
+callback_serial_tst_main(void)
+{
+ int i, got = 0;
+ struct wl_callback *cb;
+ struct client *client = client_connect();
+
+ for (i = 0; i CB_NUM; ++i) {
+ cb = wl_display_sync(client-wl_display);
+ wl_callback_add_listener(cb, sync_listener, got);
+ }
+
+ wl_display_flush(client-wl_display);
+ wl_display_roundtrip(client-wl_display);
+
+ assert(got == CB_NUM Lost some callback);
+
+ client_disconnect(client);
+}
+
+TEST(callback_serial_tst)
+{
+ struct display *d = display_create();
+
+ client_create(d, callback_serial_tst_main);
+ display_run(d);
+
+ display_destroy(d);
+}
--
1.9.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland 2/2] server: use next serial in display_sync
Display sync sends always the same serial (if nothing intervenes and increases the serial for the sync). Signed-off-by: Marek Chalupa mchqwe...@gmail.com --- src/wayland-server.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/wayland-server.c b/src/wayland-server.c index 674aeca..54284fa 100644 --- a/src/wayland-server.c +++ b/src/wayland-server.c @@ -717,7 +717,7 @@ display_sync(struct wl_client *client, return; } - serial = wl_display_get_serial(client-display); + serial = wl_display_next_serial(client-display); wl_callback_send_done(callback, serial); wl_resource_destroy(callback); } -- 1.9.3 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland] client: read_events should return -1 after an error
When a thread is sleeping, waiting until another thread read
from the display, it always returns 0. Even when an error
occured. In documentation stands:
return 0 on success or -1 on error. In case of error errno will
be set accordingly
So this is a fix for this.
Along with the read_events, fix a test so that it now complies
with this behaviour (and we have this tested)
Signed-off-by: Marek Chalupa mchqwe...@gmail.com
---
src/wayland-client.c | 5 +
tests/display-test.c | 4 ++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/wayland-client.c b/src/wayland-client.c
index b0f77b9..1a70dc7 100644
--- a/src/wayland-client.c
+++ b/src/wayland-client.c
@@ -1187,6 +1187,11 @@ read_events(struct wl_display *display)
while (display-read_serial == serial)
pthread_cond_wait(display-reader_cond,
display-mutex);
+
+ if (display-last_error) {
+ errno = display-last_error;
+ return -1;
+ }
}
return 0;
diff --git a/tests/display-test.c b/tests/display-test.c
index eb4ba1c..6ce9fe5 100644
--- a/tests/display-test.c
+++ b/tests/display-test.c
@@ -384,9 +384,9 @@ thread_read_error(void *data)
* thread should be woken up or it will block indefinitely.
*/
c-display_stopped = 1;
- assert(wl_display_read_events(c-wl_display) == 0);
+ assert(wl_display_read_events(c-wl_display) == -1);
- wl_display_dispatch_pending(c-wl_display);
+ assert(wl_display_dispatch_pending(c-wl_display) == -1);
assert(wl_display_get_error(c-wl_display));
pthread_exit(NULL);
--
1.9.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] connection: Leave fd open in wl_connection_destroy
Hi,
at first glance I didn't like returning fd from wl_connection_destroy, but
at the other, I did!
If you think about the connection as a buffer for the fd (and that is
really the case),
then it make sense to do something like:
create conn -- destroy conn
fd -- | connection | fd
--
The race in threaded environment is real (one thread closes fd, say 6,
other thread opens new fd
- it will get the first free value which is 6 - and the first thread close
the 6 again and we're in trouble..)
So it's important to close every fd only once.
For me it's OK and:
Reviewed-by: Marek Chalupa mchqwe...@gmail.com
On 30 September 2014 14:43, Benjamin Herr b...@0x539.de wrote:
Calling close() on the same file descriptor that a previous call to
close() already closed is wrong, and racy if another thread received
that same file descriptor as a eg. new socket or actual file.
There are two situations where wl_connection_destroy() would close its
file descriptor and then another function up in the call chain would
close the same file descriptor:
* When wl_client_create() fails after calling wl_connection_create(),
it will call wl_connection_destroy() before returning. However, its
caller will always close the file descriptor if wl_client_create()
fails.
* wl_display_disconnect() unconditionally closes the display file
descriptor and also calls wl_connection_destroy().
So these two seem to expect wl_connection_destroy() to leave the file
descriptor open. The other caller of wl_connection_destroy(),
wl_client_destroy(), does however expect wl_connection_destroy() to
close its file descriptor, alas.
This patch changes wl_connection_destroy() to indulge this majority of
two callers by simply not closing the file descriptor. For the benefit
of wl_client_destroy(), wl_connection_destroy() then returns the
unclosed file descriptor so that wl_client_destroy() can close it
itself.
Since wl_connection_destroy() is a private function called from few
places, changing its semantics seemed like the more expedient way to
address the double-close() problem than shuffling around the logic in
wl_client_create() to somehow enable it to always avoid calling
wl_connection_destroy().
Signed-off-by: Benjamin Herr b...@0x539.de
---
src/connection.c| 7 +--
src/wayland-private.h | 2 +-
src/wayland-server.c| 2 +-
tests/connection-test.c | 8 ++--
4 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/src/connection.c b/src/connection.c
index f292853..c5daca6 100644
--- a/src/connection.c
+++ b/src/connection.c
@@ -189,13 +189,16 @@ close_fds(struct wl_buffer *buffer, int max)
buffer-tail += size;
}
-void
+int
wl_connection_destroy(struct wl_connection *connection)
{
+ int fd = connection-fd;
+
close_fds(connection-fds_out, -1);
close_fds(connection-fds_in, -1);
- close(connection-fd);
free(connection);
+
+ return fd;
}
void
diff --git a/src/wayland-private.h b/src/wayland-private.h
index 67e8783..db76081 100644
--- a/src/wayland-private.h
+++ b/src/wayland-private.h
@@ -86,7 +86,7 @@ int wl_interface_equal(const struct wl_interface *iface1,
const struct wl_interface *iface2);
struct wl_connection *wl_connection_create(int fd);
-void wl_connection_destroy(struct wl_connection *connection);
+int wl_connection_destroy(struct wl_connection *connection);
void wl_connection_copy(struct wl_connection *connection, void *data,
size_t size);
void wl_connection_consume(struct wl_connection *connection, size_t size);
diff --git a/src/wayland-server.c b/src/wayland-server.c
index 674aeca..7caeb30 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -670,7 +670,7 @@ wl_client_destroy(struct wl_client *client)
wl_map_for_each(client-objects, destroy_resource, serial);
wl_map_release(client-objects);
wl_event_source_remove(client-source);
- wl_connection_destroy(client-connection);
+ close(wl_connection_destroy(client-connection));
wl_list_remove(client-link);
free(client);
}
diff --git a/tests/connection-test.c b/tests/connection-test.c
index 659bf68..4497128 100644
--- a/tests/connection-test.c
+++ b/tests/connection-test.c
@@ -57,6 +57,7 @@ TEST(connection_create)
connection = setup(s);
wl_connection_destroy(connection);
+ close(s[0]);
close(s[1]);
}
@@ -74,6 +75,7 @@ TEST(connection_write)
assert(memcmp(message, buffer, sizeof message) == 0);
wl_connection_destroy(connection);
+ close(s[0]);
close(s[1]);
}
@@ -92,6 +94,7 @@ TEST(connection_data)
wl_connection_consume(connection, sizeof message);
wl_connection_destroy(connection);
+ close(s[0]);
Re: [PATCH libinput] evdev: Pass along device overflow information
On 26/10/14 11:11 PM, Peter Hutterer wrote:
On Fri, Oct 24, 2014 at 01:18:06PM -0500, Derek Foreman wrote:
Currently libinput users just see choppy input if the kernel event queue
overflows. This patch passes along an event so the caller can at least
log it.
any reason you didn't just log it through libinput if that's all you want to
do?
not a big fan of having an event for what is essentially an implementation
detail in the public API.
That's fair - I guess there's nothing the caller can (or should) do in
response to this anyway.
New patch to follow.
Cheers,
Peter
---
src/evdev.c| 1 +
src/libinput-private.h | 3 +++
src/libinput.c | 18 ++
src/libinput.h | 5 +
4 files changed, 27 insertions(+)
diff --git a/src/evdev.c b/src/evdev.c
index d8e3e5a..157bed7 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -929,6 +929,7 @@ evdev_device_dispatch(void *data)
to the current state */
ev.code = SYN_REPORT;
evdev_device_dispatch_one(device, ev);
+notify_overflowed_device(device-base);
rc = evdev_sync_device(device);
if (rc == 0)
diff --git a/src/libinput-private.h b/src/libinput-private.h
index 5a975d9..4606565 100644
--- a/src/libinput-private.h
+++ b/src/libinput-private.h
@@ -212,6 +212,9 @@ void
notify_removed_device(struct libinput_device *device);
void
+notify_overflowed_device(struct libinput_device *device);
+
+void
keyboard_notify_key(struct libinput_device *device,
uint32_t time,
uint32_t key,
diff --git a/src/libinput.c b/src/libinput.c
index 5780a92..81528b7 100644
--- a/src/libinput.c
+++ b/src/libinput.c
@@ -171,6 +171,7 @@ libinput_event_get_pointer_event(struct libinput_event
*event)
abort(); /* not used as actual event type */
case LIBINPUT_EVENT_DEVICE_ADDED:
case LIBINPUT_EVENT_DEVICE_REMOVED:
+case LIBINPUT_EVENT_DEVICE_OVERFLOW:
case LIBINPUT_EVENT_KEYBOARD_KEY:
break;
case LIBINPUT_EVENT_POINTER_MOTION:
@@ -197,6 +198,7 @@ libinput_event_get_keyboard_event(struct libinput_event
*event)
abort(); /* not used as actual event type */
case LIBINPUT_EVENT_DEVICE_ADDED:
case LIBINPUT_EVENT_DEVICE_REMOVED:
+case LIBINPUT_EVENT_DEVICE_OVERFLOW:
break;
case LIBINPUT_EVENT_KEYBOARD_KEY:
return (struct libinput_event_keyboard *) event;
@@ -223,6 +225,7 @@ libinput_event_get_touch_event(struct libinput_event
*event)
abort(); /* not used as actual event type */
case LIBINPUT_EVENT_DEVICE_ADDED:
case LIBINPUT_EVENT_DEVICE_REMOVED:
+case LIBINPUT_EVENT_DEVICE_OVERFLOW:
case LIBINPUT_EVENT_KEYBOARD_KEY:
case LIBINPUT_EVENT_POINTER_MOTION:
case LIBINPUT_EVENT_POINTER_MOTION_ABSOLUTE:
@@ -248,6 +251,7 @@ libinput_event_get_device_notify_event(struct
libinput_event *event)
abort(); /* not used as actual event type */
case LIBINPUT_EVENT_DEVICE_ADDED:
case LIBINPUT_EVENT_DEVICE_REMOVED:
+case LIBINPUT_EVENT_DEVICE_OVERFLOW:
return (struct libinput_event_device_notify *) event;
case LIBINPUT_EVENT_KEYBOARD_KEY:
case LIBINPUT_EVENT_POINTER_MOTION:
@@ -831,6 +835,20 @@ notify_removed_device(struct libinput_device *device)
}
void
+notify_overflowed_device(struct libinput_device *device)
+{
+struct libinput_event_device_notify *overflowed_device_event;
+
+overflowed_device_event = zalloc(sizeof *overflowed_device_event);
+if (!overflowed_device_event)
+return;
+
+post_base_event(device,
+LIBINPUT_EVENT_DEVICE_OVERFLOW,
+overflowed_device_event-base);
+}
+
+void
keyboard_notify_key(struct libinput_device *device,
uint32_t time,
uint32_t key,
diff --git a/src/libinput.h b/src/libinput.h
index 9cc6f52..39c9f92 100644
--- a/src/libinput.h
+++ b/src/libinput.h
@@ -230,6 +230,11 @@ enum libinput_event_type {
*/
LIBINPUT_EVENT_DEVICE_REMOVED,
+/**
+ * Signals that the kernel event queue for the device has overflowed.
+ */
+LIBINPUT_EVENT_DEVICE_OVERFLOW,
+
LIBINPUT_EVENT_KEYBOARD_KEY = 300,
LIBINPUT_EVENT_POINTER_MOTION = 400,
--
2.1.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
[PATCH libinput] evdev: Log evdev event queue overflows
Log a message when the kernel event queue overflows and events are dropped.
After 10 messages logging stops to avoid flooding the logs if the condition
is persistent.
---
src/evdev.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/evdev.c b/src/evdev.c
index 1b4ce10..c786537 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -912,6 +912,7 @@ evdev_sync_device(struct evdev_device *device)
static void
evdev_device_dispatch(void *data)
{
+ static int overflows = 0;
struct evdev_device *device = data;
struct libinput *libinput = device-base.seat-libinput;
struct input_event ev;
@@ -924,6 +925,15 @@ evdev_device_dispatch(void *data)
rc = libevdev_next_event(device-evdev,
LIBEVDEV_READ_FLAG_NORMAL, ev);
if (rc == LIBEVDEV_READ_STATUS_SYNC) {
+ if (overflows 10) {
+ overflows++;
+ log_info(libinput, Kernel evdev event queue
+overflow for %s\n, device-devname);
+ if (overflows == 10)
+ log_info(libinput, No longer logging
+evdev event queue
overflows\n);
+ }
+
/* send one more sync event so we handle all
currently pending events before we sync up
to the current state */
--
2.1.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] evdev: Log evdev event queue overflows
A couple of questions on this one:
Is it ok to limit logging to 10 messages like this?
Should I be doing that on a per device basis instead of globally?
(I'm totally unattached to the specifics of the log text, I believe X
says something clever about how it's not the X server's fault to avoid
silly bug reports...)
Thanks
On 27/10/14 09:26 AM, Derek Foreman wrote:
Log a message when the kernel event queue overflows and events are dropped.
After 10 messages logging stops to avoid flooding the logs if the condition
is persistent.
---
src/evdev.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/evdev.c b/src/evdev.c
index 1b4ce10..c786537 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -912,6 +912,7 @@ evdev_sync_device(struct evdev_device *device)
static void
evdev_device_dispatch(void *data)
{
+ static int overflows = 0;
struct evdev_device *device = data;
struct libinput *libinput = device-base.seat-libinput;
struct input_event ev;
@@ -924,6 +925,15 @@ evdev_device_dispatch(void *data)
rc = libevdev_next_event(device-evdev,
LIBEVDEV_READ_FLAG_NORMAL, ev);
if (rc == LIBEVDEV_READ_STATUS_SYNC) {
+ if (overflows 10) {
+ overflows++;
+ log_info(libinput, Kernel evdev event queue
+ overflow for %s\n, device-devname);
+ if (overflows == 10)
+ log_info(libinput, No longer logging
+ evdev event queue
overflows\n);
+ }
+
/* send one more sync event so we handle all
currently pending events before we sync up
to the current state */
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-web] Updated additional dependencies for a cleaner Ubuntu 12.04 LTS system.
Reviewed-by: Bryce Harrington b.harring...@samsung.com On Mon, Oct 27, 2014 at 12:25:05AM -0700, Jon A. Cruz wrote: --- ubuntu12.04.html | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/ubuntu12.04.html b/ubuntu12.04.html index 804433e..7576fd4 100644 --- a/ubuntu12.04.html +++ b/ubuntu12.04.html @@ -15,7 +15,8 @@ Building Weston on Ubuntu 12.04/h1 XWayland on an Ubuntu 12.04 LTS system, on May 23rd, 2014. This system had previously been used to compile Xlib programs, and thus already had some dependencies (such as git, the compiler, and X11 header files) -installed./p +installed. Dependencies were last updated from a successful build +on October 20th, 2014./p pParallel make (codemake -j 9/code) will probably work on all packages but only the ones shown were compiled this way./p @@ -39,6 +40,7 @@ mkdir -p $ACLOCAL_PATH span class=comment# dependencies for libwayland:/span sudo apt-get install doxygen span class=comment# or use --disable-documentation/span +sudo apt-get install xmlto span class=comment# or use --disable-documentation/span span class=comment# libwayland-*:/span git clone git://anongit.freedesktop.org/wayland/wayland @@ -253,6 +255,12 @@ cd libxkbfile make amp;amp; make install cd .. +git clone git://anongit.freedesktop.org/xorg/proto/scrnsaverproto +cd scrnsaverproto +./autogen.sh --prefix=$WLD +make amp;amp; make install +cd .. + span class=comment# XWayland:/span git clone git://anongit.freedesktop.org/xorg/xserver cd xserver -- 1.7.12 ___ 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
[WESTON PATCH 1/1] compositor: Add idle timeout option to weston.ini
Weston's idle timeout can already be set via the '-i' command-line
option, but this patch lets users specify it also via weston.ini.
Note that the command-line option takes precedence over the .ini,
should the option be set by both.
This patch also Updates weston.ini man page with idle-timeout bits
https://bugs.freedesktop.org/show_bug.cgi?id=83921
Signed-off-by: Frederic Plourde frederic.plou...@collabora.co.uk
---
man/weston.ini.man | 19 +--
src/compositor.c | 6 +-
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/man/weston.ini.man b/man/weston.ini.man
index c05a221..a5566b0 100644
--- a/man/weston.ini.man
+++ b/man/weston.ini.man
@@ -62,21 +62,21 @@ Comment lines are ignored:
.RS 4
.nf
.IR #comment
.fi
.RE
.PP
The section headers are:
.PP
.RS 4
.nf
-.BR coreThe core modules
+.BR coreThe core modules and options
.BR libinputInput device configuration
.BR shell Desktop customization
.BR launcherAdd launcher to the panel
.BR screensaver Screensaver selection
.BR output Output configuration
.BR input-methodOnscreen keyboard input
.BR keyboardKeyboard layouts
.BR terminalTerminal application options
.BR xwaylandXWayland options
.BR screen-shareScreen sharing options
@@ -85,21 +85,21 @@ The section headers are:
.PP
Possible value types are string, signed and unsigned 32-bit
integer, and boolean. Strings must not be quoted, do not support any
escape sequences, and run till the end of the line. Integers can
be given in decimal (e.g. 123), octal (e.g. 0173), and hexadecimal
(e.g. 0x7b) form. Boolean values can be only 'true' or 'false'.
.RE
.SH CORE SECTION
The
.B core
-section is used to select the startup compositor modules.
+section is used to select the startup compositor modules and general options.
.TP 7
.BI shell= desktop-shell.so
specifies a shell to load (string). This can be used to load your own
implemented shell or one with Weston as default. Available shells
in the
.IR __weston_modules_dir__
directory are:
.PP
.RS 10
.nf
@@ -139,20 +139,35 @@ directory are:
.fi
.RE
.BI gbm-format=format
sets the GBM format used for the framebuffer for the GBM backend. Can be
.B xrgb,
.B xrgb2101010,
.B rgb565.
By default, xrgb is used.
.RS
.PP
+.RE
+.TP 7
+.BI idle-time=seconds
+sets Weston's idle timeout in seconds. This idle timeout is the time
+after which Weston will enter an inactive mode, fading the screen to
+black and possibly starting screensavers (if opt-in), etc.
+
+.IR Important
+: This option may also be set via Weston's '-i' command
+line option and will take precedence over the current .ini option. This
+means that if both weston.ini and command line define this idle-timeout
+time, the one specified in the command-line will be used. On the other
+hand, if none of these sets the value, default idle timeout will be
+set to 300 seconds.
+.RS
.SH LIBINPUT SECTION
The
.B libinput
section is used to configure input devices when using the libinput input device
backend.
.PP
Available configuration are:
.TP 7
.BI enable_tap= true
diff --git a/src/compositor.c b/src/compositor.c
index 4540911..015037f 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -4603,21 +4603,21 @@ int main(int argc, char *argv[])
*(*backend_init)(struct wl_display *display,
int *argc, char *argv[],
struct weston_config *config);
int i, fd;
char *backend = NULL;
char *shell = NULL;
char *modules = NULL;
char *option_modules = NULL;
char *log = NULL;
char *server_socket = NULL, *end;
- int32_t idle_time = 300;
+ int32_t idle_time = -1;
int32_t help = 0;
char *socket_name = NULL;
int32_t version = 0;
int32_t noconfig = 0;
int32_t numlock_on;
struct weston_config *config = NULL;
struct weston_config_section *section;
struct wl_client *primary_client;
struct wl_listener primary_client_destroyed;
struct weston_seat *seat;
@@ -4701,20 +4701,24 @@ int main(int argc, char *argv[])
ec = backend_init(display, argc, argv, config);
if (ec == NULL) {
weston_log(fatal: failed to create compositor\n);
ret = EXIT_FAILURE;
goto out_signals;
}
catch_signals();
segv_compositor = ec;
+ if (idle_time 0)
+ weston_config_section_get_int(section, idle-time, idle_time,
-1);
+ if (idle_time 0)
+ idle_time = 300; /* default idle timeout, in seconds */
ec-idle_time = idle_time;
ec-default_pointer_grab = NULL;
for (i = 1; i argc; i++)
weston_log(fatal: unhandled option: %s\n, argv[i]);
if (argc 1) {
ret = EXIT_FAILURE;
[weston] Makefile.am: Link weston_multi_resource against rt library
This fixes this build failure: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/../../../../x86_64-unknown-linux-gnu/bin/ld: clients/weston_multi_resource-multi-resource.o: undefined reference to symbol 'clock_gettime@@GLIBC_2.2.5' /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/../../../../x86_64-unknown-linux-gnu/bin/ld: note: 'clock_gettime@@GLIBC_2.2.5' is defined in DSO /lib64/librt.so.1 so try adding it to the linker command line /lib64/librt.so.1: could not read symbols: Invalid operation --- Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index b2d6893..0c08acb 100644 --- a/Makefile.am +++ b/Makefile.am @@ -419,7 +419,7 @@ weston_simple_touch_LDADD = $(SIMPLE_CLIENT_LIBS) libshared.la weston_multi_resource_SOURCES = clients/multi-resource.c weston_multi_resource_CFLAGS = $(AM_CFLAGS) $(SIMPLE_CLIENT_CFLAGS) -weston_multi_resource_LDADD = $(SIMPLE_CLIENT_LIBS) libshared.la -lm +weston_multi_resource_LDADD = $(SIMPLE_CLIENT_LIBS) libshared.la -lrt -lm endif if BUILD_SIMPLE_EGL_CLIENTS -- 2.1.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v3] wayland-util: added wl_strtol/wl_strtoul utility functions
Can I also suggest that we don't make this public API? These are internal
helpers for libwayland, not designed for any consumers. We've been burned
by making too much internal helper API public before.
On Mon, Oct 27, 2014 at 2:42 AM, Marek Chalupa mchqwe...@gmail.com wrote:
On 22 October 2014 13:32, Imran Zaman imran.za...@gmail.com wrote:
strtol/strtoul utility functions are used extensively in
weston/wayland, and are not bug-free in their current form.
To avoid definition in weston and wayland, its wrapped
in functions with appropriate input and output checks.
Test cases are also updated.
Signed-off-by: Imran Zaman imran.za...@gmail.com
---
src/scanner.c| 5 +-
src/wayland-client.c | 5 +-
src/wayland-util.c | 55
src/wayland-util.h | 4 ++
tests/fixed-test.c | 142
+++
5 files changed, 204 insertions(+), 7 deletions(-)
diff --git a/src/scanner.c b/src/scanner.c
index 809130b..165b12b 100644
--- a/src/scanner.c
+++ b/src/scanner.c
@@ -315,7 +315,6 @@ start_element(void *data, const char *element_name,
const char **atts)
struct description *description;
const char *name, *type, *interface_name, *value, *summary,
*since;
const char *allow_null;
- char *end;
int i, version;
ctx-loc.line_number = XML_GetCurrentLineNumber(ctx-parser);
@@ -404,9 +403,7 @@ start_element(void *data, const char *element_name,
const char **atts)
message-destructor = 0;
if (since != NULL) {
- errno = 0;
- version = strtol(since, end, 0);
- if (errno == EINVAL || end == since || *end !=
'\0')
+ if (!wl_strtol(since, NULL, 0, (long *)version))
This is baad. You cannot use the int version here, because in wl_strol you
write sizeof(long) on the address
of version and if sizeof(version) is smaller than sizeof(long) then you
overwrite memory. I'm getting ugly SIGSEGV
because of that.
fail(ctx-loc,
invalid integer (%s)\n, since);
} else {
diff --git a/src/wayland-client.c b/src/wayland-client.c
index b0f77b9..fd98705 100644
--- a/src/wayland-client.c
+++ b/src/wayland-client.c
@@ -824,13 +824,12 @@ wl_display_connect_to_fd(int fd)
WL_EXPORT struct wl_display *
wl_display_connect(const char *name)
{
- char *connection, *end;
+ char *connection;
int flags, fd;
connection = getenv(WAYLAND_SOCKET);
if (connection) {
- fd = strtol(connection, end, 0);
- if (*end != '\0')
+ if (!wl_strtol(connection, NULL, 0, (long *)fd))
return NULL;
flags = fcntl(fd, F_GETFD);
diff --git a/src/wayland-util.c b/src/wayland-util.c
index b099882..a930364 100644
--- a/src/wayland-util.c
+++ b/src/wayland-util.c
@@ -26,6 +26,8 @@
#include stdio.h
#include string.h
#include stdarg.h
+#include errno.h
+#include ctype.h
#include wayland-util.h
#include wayland-private.h
@@ -361,6 +363,59 @@ wl_map_for_each(struct wl_map *map,
wl_iterator_func_t func, void *data)
for_each_helper(map-server_entries, func, data);
}
+WL_EXPORT bool
+wl_strtol(const char *str, char **endptr, int base, long *val)
+{
+ char *end = NULL;
+ long v;
+
+ if (!str || !val)
+ return false;
+ if (!endptr)
+ endptr = end;
+
+ errno = 0;
+ v = strtol(str, endptr, base);
+ if (errno != 0 || *endptr == str || **endptr != '\0')
+ return false;
+
+ *val = v;
+ return true;
+}
+
+WL_EXPORT bool
+wl_strtoul(const char *str, char **endptr, int base, unsigned long *val)
+{
+ char *end = NULL;
+ unsigned long v;
+ int i = 0;
+
+ if (!str || !val)
+ return false;
+
+ /* check for negative numbers */
+ while (str[i]) {
+ if (!isspace(str[i])) {
+ if (str[i] == '-')
+ return false;
+ else
+ break;
+ }
+ i++;
+ }
+
+ if (!endptr)
+ endptr = end;
+
+ errno = 0;
+ v = strtoul(str, endptr, base);
+ if (errno != 0 || *endptr == str || **endptr != '\0')
+ return false;
+
+ *val = v;
+ return true;
+}
+
static void
wl_log_stderr_handler(const char *fmt, va_list arg)
{
diff --git a/src/wayland-util.h b/src/wayland-util.h
index fd32826..c66cc41 100644
--- a/src/wayland-util.h
+++ b/src/wayland-util.h
@@ -36,6 +36,7 @@ extern C {
#include stddef.h
#include inttypes.h
#include stdarg.h
+#include stdbool.h
/* GCC
Re: [PATCH Weston 1/2] desktop-shell: refactor panel_add_launcher
Ok, I split the patches and here's the
one doing the refactor, below.
Dan : the other patch (the one adding autolaunch per se) still
needs a comment from you before I can update it. See below for the
conversation, I'd like to have your comments about using/not using
weston_client_start() and about adding an autostart param to it
and to the config. thanks :)
*
Some other desktop-shell bits will be (re)using most of panel_add_launcher
code, so this patch extracts useful bits and pieces into a new function,
parse_launcher_path.
Signed-off-by: Frederic Plourde frederic.plou...@collabora.co.uk
---
clients/desktop-shell.c | 38 --
1 file changed, 24 insertions(+), 14 deletions(-)
diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c
index 961a9b2..c8e2810 100644
--- a/clients/desktop-shell.c
+++ b/clients/desktop-shell.c
@@ -597,72 +597,82 @@ load_icon_or_fallback(const char *icon)
cairo_move_to(cr, 4, 16);
cairo_line_to(cr, 16, 4);
cairo_stroke(cr);
cairo_destroy(cr);
return surface;
}
static void
-panel_add_launcher(struct panel *panel, const char *icon, const char *path)
+parse_launcher_path(char *path, struct wl_array *envp_array, struct wl_array *argv_array)
{
- struct panel_launcher *launcher;
char *start, *p, *eq, **ps;
int i, j, k;
- launcher = xzalloc(sizeof *launcher);
- launcher-icon = load_icon_or_fallback(icon);
- launcher-path = xstrdup(path);
+ struct wl_array *envp = envp_array;
+ struct wl_array *argv = argv_array;
- wl_array_init(launcher-envp);
- wl_array_init(launcher-argv);
+ wl_array_init(envp);
+ wl_array_init(argv);
for (i = 0; environ[i]; i++) {
- ps = wl_array_add(launcher-envp, sizeof *ps);
+ ps = wl_array_add(envp, sizeof *ps);
*ps = environ[i];
}
j = 0;
- start = launcher-path;
+ start = path;
while (*start) {
for (p = start, eq = NULL; *p !isspace(*p); p++)
if (*p == '=')
eq = p;
if (eq j == 0) {
- ps = launcher-envp.data;
+ ps = envp-data;
for (k = 0; k i; k++)
if (strncmp(ps[k], start, eq - start) == 0) {
ps[k] = start;
break;
}
if (k == i) {
-ps = wl_array_add(launcher-envp, sizeof *ps);
+ps = wl_array_add(envp, sizeof *ps);
*ps = start;
i++;
}
} else {
- ps = wl_array_add(launcher-argv, sizeof *ps);
+ ps = wl_array_add(argv, sizeof *ps);
*ps = start;
j++;
}
while (*p isspace(*p))
*p++ = '\0';
start = p;
}
- ps = wl_array_add(launcher-envp, sizeof *ps);
+ ps = wl_array_add(envp, sizeof *ps);
*ps = NULL;
- ps = wl_array_add(launcher-argv, sizeof *ps);
+ ps = wl_array_add(argv, sizeof *ps);
*ps = NULL;
+}
+
+static void
+panel_add_launcher(struct panel *panel, const char *icon, const char *path)
+{
+ struct panel_launcher *launcher;
+
+ launcher = xzalloc(sizeof *launcher);
+ launcher-icon = load_icon_or_fallback(icon);
+ launcher-path = xstrdup(path);
+
+ parse_launcher_path(launcher-path, launcher-envp, launcher-argv);
launcher-panel = panel;
wl_list_insert(panel-launcher_list.prev, launcher-link);
launcher-widget = widget_add_widget(panel-widget, launcher);
widget_set_enter_handler(launcher-widget,
panel_launcher_enter_handler);
widget_set_leave_handler(launcher-widget,
panel_launcher_leave_handler);
widget_set_button_handler(launcher-widget,
--
1.9.1
Frédéric Plourde
Principal Software engineer
T :: (450) 415-0855
@:: frederic.plou...@collabora.co.uk
+
Open First ! We're hiring !
Our current opportunities can
be found here: http://bit.ly/Collabora-Careers
Visit Collabora on the Web at
https://www.collabora.com
On 14-10-24 06:18 AM, Pekka Paalanen wrote:
On Fri, 24 Oct 2014 10:28:57 +0100
Daniel Stone dan...@fooishbar.org wrote:
Hi,
On 22 October 2014 14:53, Pekka Paalanen pekka.paala...@collabora.co.uk
wrote:
+ pid = fork();
+ if (pid 0) {
+ fprintf(stderr, "fork failed: %m\n");
+ goto out;
+ }
+
+ if (pid)
+ goto out;
+
+ argvpp = argv.data;
+ if (execve(argvpp[0], argvpp, envp.data) 0) {
+ fprintf(stderr, "execl '%s' failed: %m\n", argvpp[0]);
+ exit(1);
+ }
Hmm. Can we please use weston_client_start here instead of open-coding it?
weston_client_start() does not support passing in environment
explicitly. It also automatically sets up WAYLAND_SOCKET environment
variable and creates a connection (wl_client) before the program even
starts.
I do not think it makes sense to use weston_client_start()
Re: Reusing wl_egl_window for multiple EGL surfaces
I see. Thank you for the info. What i am trying to do is have multiple contexts with its own EGLSurface but sharing the same window or wl_surface on wayland, where one thread renders a gl_triangle and the other rendering gears. This was a simple client to teach myself queues and IPC of wayland, ofcourse it doesnt reflect real world clients. So with this setup i was wondering if a resize on the wl_egl_window will seamlessly take effect on both EGLSurfaces. Since there is no spec could it be possible that different wayland EGL implementations will have different interpretations on if/how to reuse the wl_egl_window OR are implementations explicitly discouraged, may be to prevent themselves from blowing up in weird ways, from reusing the same wl_egl_window concurrently? Also i am assuming reuse of the wl_egl_window non-concurrently is permitted and wont have issues? On Mon, Oct 27, 2014 at 12:36 AM, Pekka Paalanen ppaala...@gmail.com wrote: On Sat, 25 Oct 2014 17:14:32 -0700 Virtual Presence virtualpresence.u...@gmail.com wrote: Hi, I am writing a simple multi-threaded multi-context GLES2 Wayland client. As required by Wayland and MESA EGL bindings i do create a wl_egl_window to pass on to EGL window surface creation. I was wondering if there is any spec or rule that disallows reuse of the same wl_egl_window for multiple EGLWindowSurface. I was wondering if i could use the same underlying wl_egl_window resize bindings to cause multiple resizes. If i cannot do the same i would like to know of a spec/rule/guide (say like an EGL spec) that lists all the creation, management, deletion and usage of this object. Hi, I cannot understand what you could possibly achieve by creating several EGLSurfaces for the same window. What do you want to do? Are you perhaps attempting to render different parts of a single window in different GL contexts and so using different EGLSurfaces with some clipping magic? Maybe relying that GLX (not EGL IIRC!) required the color buffers to be shared between clients/contexts? Or do you simply want a dummy EGLSurface for each context, and then use FBOs to do the work, without ever calling eglSwapBuffers except for the one context that actually draws in the window? Because there are no Pixmaps in EGL Wayland? I can't quote a spec off-hand, but I know the EGL Wayland platform does not support partial rendering. Every time you call eglSwapBuffers, the whole buffer content must be valid, as the display server is free to take the whole buffer as the new window contents. That's actually a Wayland specification: every buffer must be completely drawn, as the display server is allowed to use all of it, even if the associated damage is only a part of it. So, I don't think it is explicitly forbidden anywhere to create several EGLSurfaces for the same wl_egl_window, but it just doesn't make sense. The different (E)GL contexts using the different EGLSurfaces would be fighting over whose buffer ends up on screen. As such, I expect that case to be untested, and so likely hit bugs. FWIW, you'd be looking for an EGL Wayland platform specification, and one has not been written AFAIK, as has not been written for many of the other platforms either. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] cairo-util: fix shadows for small clients
On 10/15/2014 01:16 AM, Marek Chalupa wrote: + shadow_height = height / 2; + + /* when the height is odd, we need some part of the +* shadow to be one pixel higher. Let's choose the +* upper one */ + if (height % 2 != 0 !fy) + ++shadow_height; This does the same thing: shadow_height = (height + (fy ? 0 : 1)) / 2; If there is any chance height is negative you want to use 1 rather than /2. This is because it always rounds in the same direction (down rather than toward zero). I don't think negative height happens here, however. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 3/6] Attach output profiles and build corresponding LUTs
On Wednesday 15 October 2014, 21:56:53, Bryce Harrington wrote:
On Mon, Oct 13, 2014 at 07:40:48PM +0200, Niels Ole Salscheider wrote:
This patch allows to attach an ICC profile to each output.
Signed-off-by: Niels Ole Salscheider niels_...@salscheider-online.de
---
src/cms-colord.c | 4 +++-
src/cms-helper.c | 16 +++-
src/cms-helper.h | 3 ++-
src/cms-static.c | 1 +
src/compositor.c | 18 ++
src/compositor.h | 2 ++
6 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/src/cms-colord.c b/src/cms-colord.c
index 4ff3aac..5696ea3 100644
--- a/src/cms-colord.c
+++ b/src/cms-colord.c
@@ -155,8 +155,9 @@ colord_update_output_from_device (struct cms_output
*ocms)
gint percentage;
/* old profile is no longer valid */
- weston_cms_destroy_profile(ocms-p);
+ weston_cms_destroy_profile(ocms-o, ocms-p);
ocms-p = NULL;
+ wl_signal_emit(ocms-o-profile_signal, ocms-o);
ret = cd_device_connect_sync(ocms-device, NULL, error);
if (!ret) {
@@ -384,6 +385,7 @@ colord_dispatch_all_pending(int fd, uint32_t mask,
void *data)
}
weston_cms_set_color_profile(ocms-o, ocms-p);
+ wl_signal_emit(ocms-o-profile_signal, ocms-o);
}
g_list_free (cms-pending);
cms-pending = NULL;
diff --git a/src/cms-helper.c b/src/cms-helper.c
index c063c77..4e20f28 100644
--- a/src/cms-helper.c
+++ b/src/cms-helper.c
@@ -25,6 +25,8 @@
#include stdlib.h
#include string.h
#include stdio.h
+#include fcntl.h
+#include unistd.h
#ifdef HAVE_LCMS
#include lcms2.h
@@ -63,6 +65,13 @@ weston_cms_set_color_profile(struct weston_output *o,
uint16_t *red = NULL;
uint16_t *green = NULL;
uint16_t *blue = NULL;
+ int fd;
+
+ fd = open(p-filename, 0);
+ o-colorspace = weston_colorspace_from_fd(fd , 0, o-compositor);
+ close(fd);
error checking on the file open
+ if (o-colorspace == NULL)
+ o-colorspace = o-compositor-srgb_colorspace;
if (!o-set_gamma)
return;
@@ -96,13 +105,18 @@ weston_cms_set_color_profile(struct weston_output *o,
}
void
-weston_cms_destroy_profile(struct weston_color_profile *p)
+weston_cms_destroy_profile(struct weston_output *o,
+ struct weston_color_profile *p)
{
if (!p)
return;
#ifdef HAVE_LCMS
cmsCloseProfile(p-lcms_handle);
#endif
+
+ weston_colorspace_destroy(o-colorspace);
+ o-colorspace = o-compositor-srgb_colorspace;
+
free(p-filename);
free(p);
}
diff --git a/src/cms-helper.h b/src/cms-helper.h
index 6e5594d..3fd17b3 100644
--- a/src/cms-helper.h
+++ b/src/cms-helper.h
@@ -67,6 +67,7 @@ weston_cms_create_profile(const char *filename,
struct weston_color_profile *
weston_cms_load_profile(const char *filename);
void
-weston_cms_destroy_profile(struct weston_color_profile *p);
+weston_cms_destroy_profile(struct weston_output *o,
+ struct weston_color_profile *p);
#endif
diff --git a/src/cms-static.c b/src/cms-static.c
index ad54fd1..c7dce58 100644
--- a/src/cms-static.c
+++ b/src/cms-static.c
@@ -58,6 +58,7 @@ cms_output_created(struct cms_static *cms, struct
weston_output *o)
weston_log(cms-static: loading %s for %s\n,
profile, o-name);
weston_cms_set_color_profile(o, p);
+ wl_signal_emit(o-profile_signal, o);
}
}
diff --git a/src/compositor.c b/src/compositor.c
index 4f959a4..61b70e7 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -3516,6 +3516,20 @@ weston_compositor_remove_output(struct
weston_compositor *compositor,
}
}
+static void
+weston_output_notifier_profile(struct wl_listener *listener, void *data)
+{
+/* TODO:
+ struct weston_output *output = (struct weston_output *) data;
+ struct weston_compositor *ec = output-compositor;
+ struct weston_resource *resource;
+
+ for each wl_cms resource {
+ wl_cms_send_output_colorspace_changed(resource, output);
+ }
+*/
Is this supposed to be TODO'd out?
If so, could use an explanatory statement.
Not really... It is implemented now.
+}
+
WL_EXPORT void
weston_output_destroy(struct weston_output *output)
{
@@ -3736,10 +3750,14 @@ weston_output_init(struct weston_output *output,
struct weston_compositor *c,
wl_signal_init(output-frame_signal);
wl_signal_init(output-destroy_signal);
+ wl_signal_init(output-profile_signal);
wl_list_init(output-animation_list);
wl_list_init(output-resource_list);
wl_list_init(output-feedback_list);
+
Re: [RFC PATCH v2 0/6] Initial per-surface color management
The support to mask the area of a surface so that its color space is not converted has been removed. Instead, the color profile of the main output of that surface can be attached if an application has a need to display uncorrected colors. I had a discussion regarding this with Zoxc on the IRC channel. Does it make sense to have a surface that is displayed uncorrected on multiple outputs with different output profiles? If so then this is not enough to detect that no color conversion should be applied at all. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: libinput: Support for long press key detection?
On 10/26/2014 05:35 AM, Carsten Haitzler (The Rasterman) wrote: to implement longpress you need to implement timeouts - this is where it begins getting high level and far more hairy than libinput is. toolkits already do this and have timeout infra with their mainloop handling. That's not always true, especially for very simple toolkits (GLUT for example), and for demo code that shows how to use a window system api. Should they also do press vs drag handling too with hysteresis. I think having the compositor do this would be an excellent idea. Currently it is very annoying that the rule for switching from click to drag varies somewhat between applications. hover detection and whether a click is a double would be immensely useful too. And get keyboard repeat in there too. You are right that libinput should not do this. I see it as something the compositor does. It is just like the gestures for touch. Then where is the drag point? n pixels from first touch? Yes. The rule for sending a drag started event is some integration of mouse motion and speed and second and third derivatives exceeding some threshold. It also needs to be per-device, some of them may be able to include pressure or other controls. at boundary of widget? No, obviously not. If the client gets a drag started event, it is free to remember that fact and not do anything about it until it gets motion outside the widget. often dragging out of the widget cancels the click action - again widget sets do this. Of course the client does this. When the mouse goes outside the widget it stops dragging. Compositor does not care. Any feedback such as changing the cursor is done by the client. should libinput do it? you are looking at a long and obstacle-filled slippery slope to put this kind of thing in libinput. I see it as immensely simpler than the api to communicate user preferences for this stuff to clients, which is going to be required if multiple seats and outputs and remote desktops are used. Also gestures are already being done this way. The mouse and keyboard should not be different. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v3] wayland-util: added wl_strtol/wl_strtoul utility functions
On 10/27/2014 09:51 AM, Jasper St. Pierre wrote: + if (!wl_strtol(since, NULL, 0, (long *)version)) This is baad. You cannot use the int version here, because in wl_strol you write sizeof(long) on the address of version and if sizeof(version) is smaller than sizeof(long) then you overwrite memory. I'm getting ugly SIGSEGV because of that. That is annoying since it means an integer version must be provided as well (plus the annoyance that on some platforms it will not complain and work if you call the wrong function). I think it would be better now to make this function return the value, and set errno on any error. Or make the error indicator an output parameter. I'd also dump the base parameter as it is not being used by anybody. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-web] Updated additional dependencies for a cleaner Ubuntu 12.04 LTS system.
Looks good to me! I'll check if this is also needed for the 14.04 instructions. Probably it is. Also when I did these instructions, I just wrote what I found worked by pretty much blind searching. I am wondering if I missed some method to compile all known xorg/proto stuff in one step. I notice that xcb support seems to compile all it's prototypes in one step. Anybody familiar with the X code base know if I missed something? On 10/27/2014 12:25 AM, Jon A. Cruz wrote: --- ubuntu12.04.html | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/ubuntu12.04.html b/ubuntu12.04.html index 804433e..7576fd4 100644 --- a/ubuntu12.04.html +++ b/ubuntu12.04.html @@ -15,7 +15,8 @@ Building Weston on Ubuntu 12.04/h1 XWayland on an Ubuntu 12.04 LTS system, on May 23rd, 2014. This system had previously been used to compile Xlib programs, and thus already had some dependencies (such as git, the compiler, and X11 header files) -installed./p +installed. Dependencies were last updated from a successful build +on October 20th, 2014./p pParallel make (codemake -j 9/code) will probably work on all packages but only the ones shown were compiled this way./p @@ -39,6 +40,7 @@ mkdir -p $ACLOCAL_PATH span class=comment# dependencies for libwayland:/span sudo apt-get install doxygen span class=comment# or use --disable-documentation/span +sudo apt-get install xmlto span class=comment# or use --disable-documentation/span span class=comment# libwayland-*:/span git clone git://anongit.freedesktop.org/wayland/wayland @@ -253,6 +255,12 @@ cd libxkbfile make amp;amp; make install cd .. +git clone git://anongit.freedesktop.org/xorg/proto/scrnsaverproto +cd scrnsaverproto +./autogen.sh --prefix=$WLD +make amp;amp; make install +cd .. + span class=comment# XWayland:/span git clone git://anongit.freedesktop.org/xorg/xserver cd xserver ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-web] Updated additional dependencies for a cleaner Ubuntu 12.04 LTS system.
On Mon, Oct 27, 2014, at 11:39 AM, Bill Spitzak wrote: Looks good to me! I'll check if this is also needed for the 14.04 instructions. Probably it is. Uh oh. I targeted the wrong file, as this was actually against 14.04. Just hard coordinating this code from a hospital waiting room with poor wifi (aka difficult to ssh back to my Linux box). Should I clean up and resubmit? -- Jon A. Cruz j...@joncruz.org ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: libinput: Support for long press key detection?
On Mon, 27 Oct 2014 11:16:16 -0700 Bill Spitzak spit...@gmail.com said: On 10/26/2014 05:35 AM, Carsten Haitzler (The Rasterman) wrote: to implement longpress you need to implement timeouts - this is where it begins getting high level and far more hairy than libinput is. toolkits already do this and have timeout infra with their mainloop handling. That's not always true, especially for very simple toolkits (GLUT for example), and for demo code that shows how to use a window system api. glut is a pretty primitive toolkit and doesn't do a very large amount of things most of the full toolkits do, like have any timed infra. you could do it with a slave thread though. Should they also do press vs drag handling too with hysteresis. I think having the compositor do this would be an excellent idea. Currently it is very annoying that the rule for switching from click to drag varies somewhat between applications. hover detection and whether a click is a double would be immensely useful too. And get keyboard repeat in there too. You are right that libinput should not do this. I see it as something the compositor does. It is just like the gestures for touch. now you're higher level - compositor. slight problem here is that to do click cancellation the compositor would need to know the geometry of every clickable element (button) within every surface at all times. this kind of violates a lot of wayland design principles. click vs drag is more universal though, but then we need to creat new event protocols for indicating this drag begin event for instance. another event for longpressed etc. - the compositor does have mainloop infra and thus timeouts don't have to be hacked into threads just to stuff one into the wrong layer. Then where is the drag point? n pixels from first touch? Yes. The rule for sending a drag started event is some integration of mouse motion and speed and second and third derivatives exceeding some threshold. It also needs to be per-device, some of them may be able to include pressure or other controls. at boundary of widget? No, obviously not. If the client gets a drag started event, it is free to remember that fact and not do anything about it until it gets motion outside the widget. often dragging out of the widget cancels the click action - again widget sets do this. Of course the client does this. When the mouse goes outside the widget it stops dragging. Compositor does not care. Any feedback such as changing the cursor is done by the client. should libinput do it? you are looking at a long and obstacle-filled slippery slope to put this kind of thing in libinput. I see it as immensely simpler than the api to communicate user preferences for this stuff to clients, which is going to be required if multiple seats and outputs and remote desktops are used. Also gestures are already being done this way. The mouse and keyboard should not be different. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-web] Updated additional dependencies for a cleaner Ubuntu 12.04 LTS system.
On Mon, Oct 27, 2014 at 11:39:39AM -0700, Bill Spitzak wrote: Looks good to me! I'll check if this is also needed for the 14.04 instructions. Probably it is. Also when I did these instructions, I just wrote what I found worked by pretty much blind searching. I am wondering if I missed some method to compile all known xorg/proto stuff in one step. I notice that xcb support seems to compile all it's prototypes in one step. Anybody familiar with the X code base know if I missed something? xcb has all protocol headers in one repository, in X they're separate repositories so you have to build them separately. Cheers, Peter On 10/27/2014 12:25 AM, Jon A. Cruz wrote: --- ubuntu12.04.html | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/ubuntu12.04.html b/ubuntu12.04.html index 804433e..7576fd4 100644 --- a/ubuntu12.04.html +++ b/ubuntu12.04.html @@ -15,7 +15,8 @@ Building Weston on Ubuntu 12.04/h1 XWayland on an Ubuntu 12.04 LTS system, on May 23rd, 2014. This system had previously been used to compile Xlib programs, and thus already had some dependencies (such as git, the compiler, and X11 header files) -installed./p +installed. Dependencies were last updated from a successful build +on October 20th, 2014./p pParallel make (codemake -j 9/code) will probably work on all packages but only the ones shown were compiled this way./p @@ -39,6 +40,7 @@ mkdir -p $ACLOCAL_PATH span class=comment# dependencies for libwayland:/span sudo apt-get install doxygen span class=comment# or use --disable-documentation/span +sudo apt-get install xmlto span class=comment# or use --disable-documentation/span span class=comment# libwayland-*:/span git clone git://anongit.freedesktop.org/wayland/wayland @@ -253,6 +255,12 @@ cd libxkbfile make amp;amp; make install cd .. +git clone git://anongit.freedesktop.org/xorg/proto/scrnsaverproto +cd scrnsaverproto +./autogen.sh --prefix=$WLD +make amp;amp; make install +cd .. + span class=comment# XWayland:/span git clone git://anongit.freedesktop.org/xorg/xserver cd xserver ___ 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 libinput] evdev: Log evdev event queue overflows
On Mon, Oct 27, 2014 at 09:33:45AM -0500, Derek Foreman wrote:
A couple of questions on this one:
Is it ok to limit logging to 10 messages like this?
IMO yes.
Should I be doing that on a per device basis instead of globally?
you are doing it per-device here, I'm not sure what you mean with the
question, sorry.
(I'm totally unattached to the specifics of the log text, I believe X
says something clever about how it's not the X server's fault to avoid
silly bug reports...)
that's a different error message, caused when the server-internal EQ
overflows. and the reason for the message is because the backtrace that X
prints then shows the input code as culprit, when the real issue is 5-6
stack frames up the stack. this wouldn't be necessary here, though we could
theoretically run into the same issue: if rendering delays reading from the
input fds for too long, we can trigger SYN_DROPPED.
Cheers,
Peter
On 27/10/14 09:26 AM, Derek Foreman wrote:
Log a message when the kernel event queue overflows and events are dropped.
After 10 messages logging stops to avoid flooding the logs if the condition
is persistent.
---
src/evdev.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/evdev.c b/src/evdev.c
index 1b4ce10..c786537 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -912,6 +912,7 @@ evdev_sync_device(struct evdev_device *device)
static void
evdev_device_dispatch(void *data)
{
+ static int overflows = 0;
struct evdev_device *device = data;
struct libinput *libinput = device-base.seat-libinput;
struct input_event ev;
@@ -924,6 +925,15 @@ evdev_device_dispatch(void *data)
rc = libevdev_next_event(device-evdev,
LIBEVDEV_READ_FLAG_NORMAL, ev);
if (rc == LIBEVDEV_READ_STATUS_SYNC) {
+ if (overflows 10) {
+ overflows++;
+ log_info(libinput, Kernel evdev event queue
+overflow for %s\n, device-devname);
+ if (overflows == 10)
+ log_info(libinput, No longer logging
+evdev event queue
overflows\n);
+ }
+
/* send one more sync event so we handle all
currently pending events before we sync up
to the current state */
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] evdev: Log evdev event queue overflows
On Mon, Oct 27, 2014 at 09:26:39AM -0500, Derek Foreman wrote:
Log a message when the kernel event queue overflows and events are dropped.
After 10 messages logging stops to avoid flooding the logs if the condition
is persistent.
---
src/evdev.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/evdev.c b/src/evdev.c
index 1b4ce10..c786537 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -912,6 +912,7 @@ evdev_sync_device(struct evdev_device *device)
static void
evdev_device_dispatch(void *data)
{
+ static int overflows = 0;
tbh, I'd prefer some naming like syn_dropped_received or somesuch.
'overflow' has a lot of different meanings, syn_dropped means exactly one
thing.
same goes for the message, if you put SYN_DROPPED in there it's really easy
to google for it (e.g. libevdev has a page that details what happens).
Kernel evdev event queue overflow is harder to figure out, so we'd have to
explain it more often to peopl on the lists.
ack to the rest.
Cheers,
Peter
struct evdev_device *device = data;
struct libinput *libinput = device-base.seat-libinput;
struct input_event ev;
@@ -924,6 +925,15 @@ evdev_device_dispatch(void *data)
rc = libevdev_next_event(device-evdev,
LIBEVDEV_READ_FLAG_NORMAL, ev);
if (rc == LIBEVDEV_READ_STATUS_SYNC) {
+ if (overflows 10) {
+ overflows++;
+ log_info(libinput, Kernel evdev event queue
+ overflow for %s\n, device-devname);
+ if (overflows == 10)
+ log_info(libinput, No longer logging
+ evdev event queue
overflows\n);
+ }
+
/* send one more sync event so we handle all
currently pending events before we sync up
to the current state */
--
2.1.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
ANNOUNCE: New Wayland Live CD ISOs
Hi. I have decided to announce new ISOs for my Wayland live CD, named in honor my favorite celebrity, Rebecca Black. http://sourceforge.net/projects/rebeccablackos/files/2014-10-27/ These ISOs have been built by SVN revision 3013, and are based on Utopic, with Wayland/Weston 1.6+ (master). SuperTux2, which has recently ported to SDL2, is now on the ISO, which is the means there is a native SDL2 application on the ISO, other than the demos (finally). The WaylandLoginManager: Now supports Wayland servers that run as Wayland clients, such as Kwin, and Greenisland, although there aren't any selectable sessions that use this yet. Now filters all data sent to the communication FIFO with grep running as daemon, so that it can't be crashed, as although I haven't heard of any of the vulnerabilities through the bash read command, it's better to be safe. Now be reloaded, without it losing fast user switching data, and jumping to the wrong tty. Now starts all fallback text dialogs as the daemon user instead of root, in the case Weston fails to start on particular hardware. Also, I tried to make a few efforts to control the ISO size, and there where a few changes to select better default applications on the Weston panel, for better desktop like usability. They are all now native Wayland applications, except for the xterm dedicated to starting xwayland apps instead. Like the last ISOs, these have GTK, Qt, SDL, Enlightenement for Wayland toolkits, and Gnome Shell and Weston and Enlightenment and SWC for Wayland desktops. Unfortunately this ISO does not have Orbital, Hawaii, or Calligra, as it is depending on libweston, which is yet to be merged, Hawaii is depending on some yet to be merged changes in QtWayland's QtCompositor for screen handling, and Calligra's QT5 port is paused, (but I hear they plan to overhaul the Qt 5 port in the near future.) In a future ISO, once I figure out how to run it, and it becomes more runnable, I will have kwin/plasma as a selectable Wayland session. md5sum: c538d6209cf8c5924961bc5075aa6865 RebeccaBlackLinux_DevDbg_i386.iso 64948e151ec09f422ae23b1658cea512 RebeccaBlackLinux_i386.iso 4efb20c5912e27571554638d35815a2b RebeccaBlackLinux_Revisions_i386.txt a1427af2bb1c3b7f10c6c68d3ac79599 RebeccaBlackLinux_Source_i386.tar.gz ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: libinput: Support for long press key detection?
On 10/27/2014 04:08 PM, Carsten Haitzler (The Rasterman) wrote: You are right that libinput should not do this. I see it as something the compositor does. It is just like the gestures for touch. now you're higher level - compositor. slight problem here is that to do click cancellation the compositor would need to know the geometry of every clickable element (button) within every surface at all times. Can you explain why that would be needed? I figured if a client cancelled a click it would just ignore the events after that. This would not cause any information to be lost, the client would get all the press/release/move events it does now, so I don't see any reason the compositor needs to know, or if it does need to know then the compositor would need to know this information with the current version of Wayland. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-web] Updated additional dependencies for a cleaner Ubuntu 12.04 LTS system.
On 10/27/2014 01:44 PM, Jon A. Cruz wrote: On Mon, Oct 27, 2014, at 11:39 AM, Bill Spitzak wrote: Looks good to me! I'll check if this is also needed for the 14.04 instructions. Probably it is. Uh oh. I targeted the wrong file, as this was actually against 14.04. Just hard coordinating this code from a hospital waiting room with poor wifi (aka difficult to ssh back to my Linux box). Should I clean up and resubmit? I just checked and the 14.04 instructions have --disable-documentation, which is why they worked (they also have the screen saver proto files that you added). Probably it would be best if the 14.04 instructions built the documentation, since patching that up is something a new developer might do first. I still have the 12 machine so I can try building on that and see if this is needed. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
