[PATCH] Fix activate transient_for when current window has no frame (e.g. menus)
---
src/xwayland/window-manager.c | 32
1 file changed, 28 insertions(+), 4 deletions(-)
diff --git a/src/xwayland/window-manager.c b/src/xwayland/window-manager.c
index a889278..4f06bee 100644
--- a/src/xwayland/window-manager.c
+++ b/src/xwayland/window-manager.c
@@ -659,6 +659,20 @@ weston_wm_kill_client(struct wl_listener *listener, void
*data)
kill(window->pid, SIGKILL);
}
+struct weston_wm_window *
+weston_wm_window_get_framed_parent(struct weston_wm_window *window)
+{
+ struct weston_wm_window *framed_window = window;
+ while (!framed_window->frame && framed_window->transient_for) {
+ framed_window = framed_window->transient_for;
+ }
+ if (framed_window->frame) {
+ return framed_window;
+ } else {
+ return NULL;
+ }
+}
+
static void
weston_wm_window_activate(struct wl_listener *listener, void *data)
{
@@ -694,13 +708,23 @@ weston_wm_window_activate(struct wl_listener *listener,
void *data)
}
if (wm->focus_window) {
- frame_unset_flag(wm->focus_window->frame, FRAME_FLAG_ACTIVE);
- weston_wm_window_schedule_repaint(wm->focus_window);
+ struct weston_wm_window *action_window =
weston_wm_window_get_framed_parent(wm->focus_window);
+ if (action_window) {
+ frame_unset_flag(action_window->frame,
FRAME_FLAG_ACTIVE);
+ weston_wm_window_schedule_repaint(action_window);
+ } else {
+ wm_log("window has no frame??\n");
+ }
}
wm->focus_window = window;
if (wm->focus_window) {
- frame_set_flag(wm->focus_window->frame, FRAME_FLAG_ACTIVE);
- weston_wm_window_schedule_repaint(wm->focus_window);
+ struct weston_wm_window *action_window =
weston_wm_window_get_framed_parent(wm->focus_window);
+ if (action_window) {
+ frame_set_flag(action_window->frame, FRAME_FLAG_ACTIVE);
+ weston_wm_window_schedule_repaint(action_window);
+ } else {
+ wm_log("window has no frame??\n");
+ }
}
}
--
1.8.4.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Rename invocations of frame_create that were missed by ee7fefcf
Thanks for catching these. Not sure how I missed it when I did the original
rename.
--Jason Ekstrand
On Oct 17, 2013 12:25 PM, "Cameron Stewart" wrote:
> For some reason it not only compiled with different parameters but the
> method succeeded and just failed later.
> ---
> clients/gears.c| 2 +-
> clients/view.c | 2 +-
> clients/wscreensaver.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/clients/gears.c b/clients/gears.c
> index 30f4e68..93a86b4 100644
> --- a/clients/gears.c
> +++ b/clients/gears.c
> @@ -404,7 +404,7 @@ gears_create(struct display *display)
> gears = zalloc(sizeof *gears);
> gears->d = display;
> gears->window = window_create(display);
> - gears->widget = frame_create(gears->window, gears);
> + gears->widget = window_frame_create(gears->window, gears);
> window_set_title(gears->window, "Wayland Gears");
>
> gears->display = display_get_egl_display(gears->d);
> diff --git a/clients/view.c b/clients/view.c
> index f5b1843..cedef08 100644
> --- a/clients/view.c
> +++ b/clients/view.c
> @@ -251,7 +251,7 @@ view_create(struct display *display,
> }
>
> view->window = window_create(display);
> - view->widget = frame_create(view->window, view);
> + view->widget = window_frame_create(view->window, view);
> window_set_title(view->window, title);
> g_free(title);
> view->display = display;
> diff --git a/clients/wscreensaver.c b/clients/wscreensaver.c
> index 9a2c47a..47f6c8a 100644
> --- a/clients/wscreensaver.c
> +++ b/clients/wscreensaver.c
> @@ -200,7 +200,7 @@ create_wscreensaver_instance(struct wscreensaver
> *screensaver,
> window_get_wl_surface(mi->window),
> output);
> } else {
> - mi->widget = frame_create(mi->window, mi);
> + mi->widget = window_frame_create(mi->window, mi);
> }
> widget_set_redraw_handler(mi->widget, redraw_handler);
>
> --
> 1.8.4.1
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 4/4] udev-seat: Repick seat after a new device was added
Signed-off-by: Jonas Ådahl
---
src/input.c | 2 +-
src/udev-seat.c | 5 +
src/udev-seat.h | 1 +
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/input.c b/src/input.c
index 0a4568b..afa4459 100644
--- a/src/input.c
+++ b/src/input.c
@@ -45,7 +45,7 @@ static void unbind_resource(struct wl_resource *resource)
wl_list_remove(wl_resource_get_link(resource));
}
-void
+WL_EXPORT void
weston_seat_repick(struct weston_seat *seat)
{
const struct weston_pointer *pointer = seat->pointer;
diff --git a/src/udev-seat.c b/src/udev-seat.c
index 4ef7ff3..ffaf08a 100644
--- a/src/udev-seat.c
+++ b/src/udev-seat.c
@@ -128,6 +128,9 @@ device_added(struct udev_device *udev_device, struct
udev_input *input)
device->output = output;
}
+ if (input->enabled == 1)
+ weston_seat_repick(&seat->base);
+
return 0;
}
@@ -263,6 +266,8 @@ udev_input_enable(struct udev_input *input, struct udev
*udev)
if (udev_input_add_devices(input, udev) < 0)
return -1;
+ input->enabled = 1;
+
return 0;
}
diff --git a/src/udev-seat.h b/src/udev-seat.h
index 5bf7caa..4cb6f07 100644
--- a/src/udev-seat.h
+++ b/src/udev-seat.h
@@ -39,6 +39,7 @@ struct udev_input {
struct wl_event_source *udev_monitor_source;
char *seat_id;
struct weston_compositor *compositor;
+ int enabled;
};
--
1.8.1.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 3/4] input: Unmap pointer sprite when no more pointer devices are connected
Signed-off-by: Jonas Ådahl --- src/input.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/input.c b/src/input.c index de46433..0a4568b 100644 --- a/src/input.c +++ b/src/input.c @@ -1717,6 +1717,9 @@ weston_seat_release_pointer(struct weston_seat *seat) wl_fixed_from_int(0), wl_fixed_from_int(0)); + if (pointer->sprite) + pointer_unmap_sprite(pointer); + seat_send_updated_caps(seat); } } -- 1.8.1.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 2/4] input: Unset focus of seat device when releasing last reference
When the last input device with a certain capability is removed, unset
the focus of the seat device associated with the capability.
Signed-off-by: Jonas Ådahl
---
src/input.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/input.c b/src/input.c
index a5cad7c..de46433 100644
--- a/src/input.c
+++ b/src/input.c
@@ -1678,6 +1678,7 @@ weston_seat_release_keyboard(struct weston_seat *seat)
{
seat->keyboard_device_count--;
if (seat->keyboard_device_count == 0) {
+ weston_keyboard_set_focus(seat->keyboard, NULL);
seat_send_updated_caps(seat);
}
}
@@ -1712,6 +1713,10 @@ weston_seat_release_pointer(struct weston_seat *seat)
seat->pointer_device_count--;
if (seat->pointer_device_count == 0) {
+ weston_pointer_set_focus(pointer, NULL,
+wl_fixed_from_int(0),
+wl_fixed_from_int(0));
+
seat_send_updated_caps(seat);
}
}
@@ -1744,6 +1749,7 @@ weston_seat_release_touch(struct weston_seat *seat)
{
seat->touch_device_count--;
if (seat->touch_device_count == 0) {
+ weston_touch_set_focus(seat, NULL);
seat_send_updated_caps(seat);
}
}
--
1.8.1.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 1/4] evdev: Reference count input device's seat capabilities
When the only input device of a certain seat capability is unplugged,
stop advertising the capability.
Signed-off-by: Jonas Ådahl
---
src/compositor.h | 9 +
src/evdev.c | 11 +++
src/evdev.h | 7 +++
src/input.c | 58 +---
4 files changed, 78 insertions(+), 7 deletions(-)
diff --git a/src/compositor.h b/src/compositor.h
index a19d966..8ce2229 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -460,6 +460,9 @@ struct weston_seat {
struct weston_pointer *pointer;
struct weston_keyboard *keyboard;
struct weston_touch *touch;
+ int pointer_device_count;
+ int keyboard_device_count;
+ int touch_device_count;
struct weston_output *output; /* constraint */
@@ -1109,11 +1112,17 @@ weston_seat_init(struct weston_seat *seat, struct
weston_compositor *ec,
const char *seat_name);
void
weston_seat_init_pointer(struct weston_seat *seat);
+void
+weston_seat_release_pointer(struct weston_seat *seat);
int
weston_seat_init_keyboard(struct weston_seat *seat, struct xkb_keymap *keymap);
void
+weston_seat_release_keyboard(struct weston_seat *seat);
+void
weston_seat_init_touch(struct weston_seat *seat);
void
+weston_seat_release_touch(struct weston_seat *seat);
+void
weston_seat_repick(struct weston_seat *seat);
void
diff --git a/src/evdev.c b/src/evdev.c
index 48e5470..89015f5 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -558,6 +558,7 @@ evdev_configure_device(struct evdev_device *device)
if ((device->caps &
(EVDEV_MOTION_ABS | EVDEV_MOTION_REL | EVDEV_BUTTON))) {
weston_seat_init_pointer(device->seat);
+ device->seat_caps |= EVDEV_SEAT_POINTER;
weston_log("input device %s, %s is a pointer caps =%s%s%s\n",
device->devname, device->devnode,
device->caps & EVDEV_MOTION_ABS ? " absolute-motion"
: "",
@@ -567,11 +568,13 @@ evdev_configure_device(struct evdev_device *device)
if ((device->caps & EVDEV_KEYBOARD)) {
if (weston_seat_init_keyboard(device->seat, NULL) < 0)
return -1;
+ device->seat_caps |= EVDEV_SEAT_KEYBOARD;
weston_log("input device %s, %s is a keyboard\n",
device->devname, device->devnode);
}
if ((device->caps & EVDEV_TOUCH)) {
weston_seat_init_touch(device->seat);
+ device->seat_caps |= EVDEV_SEAT_TOUCH;
weston_log("input device %s, %s is a touch device\n",
device->devname, device->devnode);
}
@@ -595,6 +598,7 @@ evdev_device_create(struct weston_seat *seat, const char
*path, int device_fd)
container_of(ec->output_list.next, struct weston_output, link);
device->seat = seat;
+ device->seat_caps = 0;
device->is_mt = 0;
device->mtdev = NULL;
device->devnode = strdup(path);
@@ -642,6 +646,13 @@ evdev_device_destroy(struct evdev_device *device)
{
struct evdev_dispatch *dispatch;
+ if (device->seat_caps & EVDEV_SEAT_POINTER)
+ weston_seat_release_pointer(device->seat);
+ if (device->seat_caps & EVDEV_SEAT_KEYBOARD)
+ weston_seat_release_keyboard(device->seat);
+ if (device->seat_caps & EVDEV_SEAT_TOUCH)
+ weston_seat_release_touch(device->seat);
+
dispatch = device->dispatch;
if (dispatch)
dispatch->interface->destroy(dispatch);
diff --git a/src/evdev.h b/src/evdev.h
index 5e4d11a..e146d1a 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -49,6 +49,12 @@ enum evdev_device_capability {
EVDEV_TOUCH = (1 << 4),
};
+enum evdev_device_seat_capability {
+ EVDEV_SEAT_POINTER = (1 << 0),
+ EVDEV_SEAT_KEYBOARD = (1 << 1),
+ EVDEV_SEAT_TOUCH = (1 << 2)
+};
+
struct evdev_device {
struct weston_seat *seat;
struct wl_list link;
@@ -80,6 +86,7 @@ struct evdev_device {
enum evdev_event_type pending_event;
enum evdev_device_capability caps;
+ enum evdev_device_seat_capability seat_caps;
int is_mt;
};
diff --git a/src/input.c b/src/input.c
index 1313b52..a5cad7c 100644
--- a/src/input.c
+++ b/src/input.c
@@ -447,11 +447,11 @@ seat_send_updated_caps(struct weston_seat *seat)
enum wl_seat_capability caps = 0;
struct wl_resource *resource;
- if (seat->pointer)
+ if (seat->pointer_device_count > 0)
caps |= WL_SEAT_CAPABILITY_POINTER;
- if (seat->keyboard)
+ if (seat->keyboard_device_count > 0)
caps |= WL_SEAT_CAPABILITY_KEYBOARD;
- if (seat->touch)
+ if (seat->touch_device_count > 0)
caps |= WL_SEAT_CAPABILITY_TOUCH;
wl_resource_for_each(resource, &seat->base_resource_list) {
@@ -1628,8 +1628,12 @@ wes
Re: [RFC] wl_surface video protocol extension
The key point I was trying to make is that the media player needs to be able to predict when frames will be displayed. All its prediction calculations will be based on a fixed scanout rate. If the scanout rate changes, all bets are off, and we have to start again from scratch trying to predict the scanouts again. So, with regards to the scanout rate changing, we will need an event to tell us that so we can redo the prediction calculations. So, if the scanouts are T=100 and then T=200, we would have to have somehow predicted that, and as a result set the buffer1, T=100 buffer2, T=200 or in actual fact, to allow for inaccuracy the media player would set: buffer1, T = 80 buffer2, T = 180 This will then ensure that buffer1 would be displayed at T=100, and buffer2 would be displayed at T=200. But we would only know to set T=80 for buffer1 if we had been able to predict when the actual frame will be. So, I guess I am still asking for an API that would return these predicted values from the graphics driver. Also, If buffer2 has T=200. What is the 200 being compared to in order to decide to display the buffer or not? This will not be the timestamp on the presentation callback will it? There is also the matter of clock sync. Is T=100 referenced to the system monotonic clock or some other clock. Video and Audio sync is not achieved by comparing Video and Audio time stamps. You have a global system monotonic clock, and sync Video to the system clock, and sync Audio to the system clock. A good side effect of this is that Audio and Video are then in sync. The advantage of this syncing to the system monotonic clock is that you can then run Video and Audio in separate thread, different CPUs, whenever, but they will always be in sync. Kind Regards James ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 2/2] protocol: add state set functions for maximized and fullscreen.
On 10/15/2013 10:53 PM, Kristian Høgsberg wrote: - transient for shouldn't take position. What? I think that is necessary. It is relative to the parent surface. - New keyboard focus protocol: instead of active surface meaning "has keyboard focus" we need something that works in a touch-only environment and we need a more generic way to create surfaces that don't take keyboard focus. I propose a new xdg_surface.activate event that indicates that the surface has been activated (by clicking or touching or alt-tabbing to it (or hovering in case of sloppy focus)). When a surface is "the active surface", the client can choose to assign kb focus (xdg_surface.take_keyboard_focus) to any of its surfaces. Please allow clients to take the active themselves, maybe with a xdg_surface.take_active request, and clients can decide themselves whether a click or hover activates them. The compositor should not activate surfaces due to events done to the surface (it can still activate them due to things like alt+tab shortcuts and due to the current active surface being unmapped). This will allow clients to decide not to activate themselves, to make the rules vary depending on where the events happen, and so that point-to-type is a per-client rule, not a global one. Hostile clients will not be able to grab the active, as the active request will contain an event id that triggered it, and the compositor can ignore it if the event is not a keystroke or mouse event to that client. - We need to solve stacking - how does a wayland shell raise an applications and all its surfaces correctly. The two ideas I have are either 1) let the client raise its surfaces when it's active (uses the same xdg_surface.activate event as above) and just let the client control which surfaces to raise and in which order in response to being activated or 2) let the client describe above/below relation between its surfaces and make sure the shell respects these constraints when raising a surface (eg, toolbars above documents, but no relation between individual toolbar surfaces or doc surfaces. Raising a document raises all the toolbox surfaces to be on top, but doesn't affect other documents and preserves the stacking order of the toolbox surface). I am in favor of a hybrid approach. Version 1 above should always work: a client can make a bunch of surfaces, not communicate any relationship information about them to the compositor, and always have complete knowledge and control over what order they are composited in. It can insure that top-to-bottom order of 3 surfaces is A,B,C by raising B and then raising A. And the compositor must *NEVER* raise surfaces itself. Surfaces are ONLY raised in response to a request from the client. This means the client always knows exactly what order they are in. However the compositor should also support a tree of parent relationships between surfaces, which a client may choose to use. Each surface has a "parent", which is either null or another surface. If surface A has a parent of B, a raise of B will also raise A, and a map/unmap of B will map/unmap A. A client can at any moment change the parent of any surface to any other one except it can't make a loop, changing the tree will not change the state or position of any surface even if it is "wrong", the tree only controls what happens when requests are made to parents. The reasons for supporting the tree (rather than have the client do everything) are: 1. Pagers and task switchers can use this tree to determine that a bunch of surfaces are related 2. Compositors may be able to take advantage of knowledge that two surfaces are 'stuck together' and will raise as a unit. In particular it can take advantage of everything being done for subsurfaces. 3. Familiarity and resemblence to other window systems. I believe these child surfaces and "subsurfaces" are EXACTLY the same thing. The only difference is that raising a subsurface puts it just above the top-most subsurface with the same parent, while raising a non-subsurface puts it at the top of it's layer, above surfaces belonging to other clients. Merging sub, transient, and popup surfaces will simplify wayland and provide advantages to both that currently only exist for one or the other. Because nothing happens unless raise or map requests are made from the client, the client is still in control. It can change the tree any way it wants before doing a raise request. The common example of a floating dialog over two main windows would be accomplished by the client changing the parent of the dialog to the main window it is raising. This ability to change the tree avoids the need to send a directed acyclic graph to the compositor, vastly simplifying the compositor api. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] Rename invocations of frame_create that were missed by ee7fefcf
For some reason it not only compiled with different parameters but the method
succeeded and just failed later.
---
clients/gears.c| 2 +-
clients/view.c | 2 +-
clients/wscreensaver.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/clients/gears.c b/clients/gears.c
index 30f4e68..93a86b4 100644
--- a/clients/gears.c
+++ b/clients/gears.c
@@ -404,7 +404,7 @@ gears_create(struct display *display)
gears = zalloc(sizeof *gears);
gears->d = display;
gears->window = window_create(display);
- gears->widget = frame_create(gears->window, gears);
+ gears->widget = window_frame_create(gears->window, gears);
window_set_title(gears->window, "Wayland Gears");
gears->display = display_get_egl_display(gears->d);
diff --git a/clients/view.c b/clients/view.c
index f5b1843..cedef08 100644
--- a/clients/view.c
+++ b/clients/view.c
@@ -251,7 +251,7 @@ view_create(struct display *display,
}
view->window = window_create(display);
- view->widget = frame_create(view->window, view);
+ view->widget = window_frame_create(view->window, view);
window_set_title(view->window, title);
g_free(title);
view->display = display;
diff --git a/clients/wscreensaver.c b/clients/wscreensaver.c
index 9a2c47a..47f6c8a 100644
--- a/clients/wscreensaver.c
+++ b/clients/wscreensaver.c
@@ -200,7 +200,7 @@ create_wscreensaver_instance(struct wscreensaver
*screensaver,
window_get_wl_surface(mi->window),
output);
} else {
- mi->widget = frame_create(mi->window, mi);
+ mi->widget = window_frame_create(mi->window, mi);
}
widget_set_redraw_handler(mi->widget, redraw_handler);
--
1.8.4.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
XWayland: fails to build on MIPS
Hello, I tried XWayland build instructions on http://wayland.freedesktop.org/xserver.html on MIPS. I try to build xserver with: git clone git://anongit.freedesktop.org/xorg/xserver -b xwayland-1.12 cd xserver ./autogen.sh --prefix=/usr The last command outputs this: autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --force -I m4 And even after an hour, the build does not go further. What is wrong? Thanks for your help, Christophe ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] wl_surface video protocol extension
On 10/17/2013 06:36 AM, Frederic Plourde wrote: See, at time T=100, for example, if there's this in the queue : buffer1,T=75 buffer2,T=99 buffer3,T=110 The compositor will drop buffer1 and present buffer2 right away since buffer2 it's the most recent "past" buffers... And looking at your suggestion #4, if we're having this at time T=112 : buffer3,T=110 I don't see why we should drop buffer3 instead of displaying it (we have no newer frames in the queue... but we definitely want to display something, right ?) Any clarifications here could be very enlightning.. I think his concern is what happens if the scanouts happen at T=100 and then T=200 and this is in the queue: buffer1, T=101 buffer2, T=200 This will skip showing buffer1 since the first scanout is too early, and the second scanout prefers buffer2. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] wl_surface video protocol extension
Plus of course the same for the next buffer, so you know e.g. how long a buffer was on screen etc. How does that sound? So, the information you propose, with timestamps, gives us timestamps from events in the past. Is there any way to deterministically ensure that a particular frame is displayed at a particular scanout that we would decide on in advance. The problem is, if I timestamp a frame for time X and the scan out actually happens as time X - 1 microsecond, I really wanted not to miss that scanout. It would be easier to be able to specify a particular scanout. Hi James, I understand your question, but pinopointing a particular scanout makes less sense, as Pekka said, in the case where monitor refresh rate can change without notice. I guess in that case, you'd probably miss your "expected" scanout and present the buffer on the next vsync, but remember, you can't know in advance when that scanout is going to happen. So just to summarize what we've got so far : - pre-submission timing (queueing buffers with expected presentation times) - presentation callbacks (that's currently done by another team at Collabora) - Output refresh rate change/adaptation notification back to clients (we'll be working on that soon) and, as Pekka said, I'm kinda in favor of keeping "higher-level info", like latency predictors for any higher-lever library API on top of what we're doing now. What do you think ? > So, I would propose the following. > 1) sequence number the frames at the display rate. > 2) provide an api for the application to predict the time of each frame > number in the sequence. I.e The next 5 frames will display at time > X1,X2,X3,X4,X5. Also provide a way to determine the "frame submited to > frame displayed" latency. So the user application knows how many frames in > advance it needs to do the submit. > 3) provide an api for the application to ensure that a frame it submits > will get displayed at display rate sequence number X. > 4) If frame X has already past, only display it if there are now newer > frames in the quene, otherwise drop it. About that point #4 here, I've already started to work on the implementation bits, and I was thinking about doing it like this : See, at time T=100, for example, if there's this in the queue : buffer1,T=75 buffer2,T=99 buffer3,T=110 The compositor will drop buffer1 and present buffer2 right away since buffer2 it's the most recent "past" buffers... And looking at your suggestion #4, if we're having this at time T=112 : buffer3,T=110 I don't see why we should drop buffer3 instead of displaying it (we have no newer frames in the queue... but we definitely want to display something, right ?) Any clarifications here could be very enlightning.. Cheers :) ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] event-loop: fix blocking timerfd read
If we call wl_event_source_check() on a timerfd, our dispatcher will block
on the timerfd read(). Avoid calling read() if no epoll-event was
reported.
Note: The internal tick-count of a timerfd is never decreased. So once we
get signaled a read event, a following read() is guaranteed to succeed
_if_ no other operation is called on the timerfd in between. Therefore,
there is no need for us to make the read() non-blocking (even with
clock-changes we never block). However, to be safe for future changed,
just ignore EAGAIN safely.
Also remove the comment about read() failure. The only reasons the read
can currently fail is EINTR or invalid parameters. The latter cannot
happen in our setup so ignore it. EINTR shouldn't happen as
syscall-restart is the default behavior so we simply return if a user
changed it. Better safe than sorry.
Signed-off-by: David Herrmann
---
src/event-loop.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/src/event-loop.c b/src/event-loop.c
index d323601..d340e3c 100644
--- a/src/event-loop.c
+++ b/src/event-loop.c
@@ -172,10 +172,15 @@ wl_event_source_timer_dispatch(struct wl_event_source
*source,
uint64_t expires;
int len;
- len = read(source->fd, &expires, sizeof expires);
- if (len != sizeof expires)
- /* Is there anything we can do here? Will this ever happen? */
- fprintf(stderr, "timerfd read error: %m\n");
+ if (ep->events != 0) {
+ len = read(source->fd, &expires, sizeof expires);
+ if (len != sizeof expires) {
+ if (len >= 0 || (errno != EINTR && errno != EAGAIN))
+ fprintf(stderr,
+ "timerfd read error (%d): %m\n", len);
+ return 0;
+ }
+ }
return timer_source->func(timer_source->base.data);
}
--
1.8.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] wl_surface video protocol extension
> > There are various artifacts that appear as a result of frame rate > adaption. > > One of these is field dominance. This is where the top field is displayed > > for longer than the bottom field. This results in the appearance of > > flickering lines to the viewer. > > If you could determine how long the top field was presented to the user, > > you could maybe make adjustments to make the bottom field appear for a > > similar amount of time. > > Ok, you want to know how long a frame (buffer) has been on. > Presentation timestamp tells you when the frame started to show, so > maybe you could use the presentation timestamp of the next frame as the > ending timestamp for this frame? > > Btw. would you need to know or set the scanout "phase" of top vs. bottom > field for each frame on an interlaced display and video? > On an interlaced display, we would need to make sure we can ensure the phase is correct. I.e. the top field from the media goes into the top field of the scanout. So, I guess the answer is yes. But, I would hope that we could send the full frame, containing a top and bottom field and the hardware ensure it goes to the correct top/bottom scanout. > > So, I would propose the following. > > 1) sequence number the frames at the display rate. > > 2) provide an api for the application to predict the time of each frame > > number in the sequence. I.e The next 5 frames will display at time > > X1,X2,X3,X4,X5. Also provide a way to determine the "frame submited to > > frame displayed" latency. So the user application knows how many frames > in > > advance it needs to do the submit. > > 3) provide an api for the application to ensure that a frame it submits > > will get displayed at display rate sequence number X. > > 4) If frame X has already past, only display it if there are now newer > > frames in the quene, otherwise drop it. > > To me, all that sounds like a library API of somewhat higher level than > display server protocol. We just need to make sure the protocol has > everything to support such a library. > > I think item 4 is already implied in the protocol. > > Also, monitor refresh rates may change, which is why I think a > timestamp is better in the protocol than a sequence number tied to a > refresh rate. Another thing missing in the protocol sketch is an event > notifying the client about current output refresh rate changes. > > > Summary: > > For the best video streaming experience, timestamps on the frame are not > > very useful, what is useful is predicting exactly when the frame will > > actually be displayed to the user. > > I hope the three timestamps would allow you to estimate everything you > need: > - when you queued a buffer (sent the request) > - the timestamp you asked the buffer to be presented at > - the timestamp the buffer really was presented > > Plus of course the same for the next buffer, so you know e.g. how long > a buffer was on screen etc. > > How does that sound? > > So, the information you propose, with timestamps, gives us timestamps from events in the past. Is there any way to deterministically ensure that a particular frame is displayed at a particular scanout that we would decide on in advance. The problem is, if I timestamp a frame for time X and the scan out actually happens as time X - 1 microsecond, I really wanted not to miss that scanout. It would be easier to be able to specify a particular scanout. Thanks, > pq > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Making Wayland accessible
Hi Matthias, thanks for starting the discussion. I will add some points below. On 10/15/2013 10:05 PM, Matthias Clasen wrote: > As part of the ongoing GNOME Wayland porting effort, the GNOME > accessibility (a11y) team has been looking into what it would take to > make our existing a11y tools (ATs) and infrastructure work under Wayland. FWIW, most of the stuff we did on the recent Montreal Summit was related with Wayland. You can find a summary on this wiki page: https://wiki.gnome.org/Accessibility/Hackfests/Montreal2013 > > Most a11y features will probably end up being implemented in the > compositor: > > - input tweaks like slow keys or bounce keys or hover-to-click > naturally fit in the event dispatching in the compositor > > - display changes like zoom or color adjustments are already handled > in gnome-shell under X > > - the text protocol should be sufficient to make on-screen keyboards > and similar tools work > > The remaining AT of concern is orca, our screen reader, which does not > easily fit into the compositor. Here are some examples of the kinds of > things orca needs to do to support its users: > > - Identify the surface that is currently under the pointer (and the > corresponding application that is registered as an accessible client) FWIW2, there is a running conversation about that here: https://mail.gnome.org/archives/gnome-accessibility-devel/2013-October/msg6.html > > - Warp the pointer to a certain position (see > https://bugzilla.gnome.org/show_bug.cgi?id=70 for a description of > how this is used) Also tracking mouse position (More about that here, https://bugzilla.gnome.org/show_bug.cgi?id=710012, although it doesn't include a description about how it is used). > > - Filter out certain key events and use them for navigation purposes. > This is currently done by capturing key events client-side and sending > them out again via at-spi, which will probably continue to work, even > if it is awkward and toolkit authors would really like to get rid of it > > All of these features violate the careful separation between clients > that Wayland maintains, so that probably calls for some privileged > interface for ATs. Most of the people I asked (mostly after Wayland related presentations on GUADEC and others) pointed to that direction. > I would appreciate feedback and discussion on this. > > Has anybody else thought about these problems already ? > > Are there better ways to do these things under Wayland ? > BR -- Alejandro Piñeiro ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] wl_surface video protocol extension
On Thu, 17 Oct 2013 09:38:41 +0100 James Courtier-Dutton wrote: > Hi, > > I have extensive experience with video streaming and display having worked > on the xine video player. > Setting time stamps on a stream of video frames is not the entire solution. > The biggest problem with displaying video on computer displays is "frame > rate adaption". > I.e. The frame rate of the video frames might not equal the frame rate of > the display. > What is really needed is a predictor. > I.e. If I send this frame to the video hardware, what is the exact time it > will be displayed. > A predictor might be difficult, so some callback after the frame is > displayed giving the exact time the frame was displayed would also help. > The video player could then use this information to adjust the frame > submission to ensure the frame was displayed closer to when it needs to be. Hi James, that is exactly what is being planned, but was not mentioned yet: presentation timestamp events coming from the compositor, telling the client when the wl_buffer actually hit the screen. Then you know what timestamp you asked, when you queued it, and what actually happened, and can work out the statistics on the difference. > There are various artifacts that appear as a result of frame rate adaption. > One of these is field dominance. This is where the top field is displayed > for longer than the bottom field. This results in the appearance of > flickering lines to the viewer. > If you could determine how long the top field was presented to the user, > you could maybe make adjustments to make the bottom field appear for a > similar amount of time. Ok, you want to know how long a frame (buffer) has been on. Presentation timestamp tells you when the frame started to show, so maybe you could use the presentation timestamp of the next frame as the ending timestamp for this frame? Btw. would you need to know or set the scanout "phase" of top vs. bottom field for each frame on an interlaced display and video? > So, I would propose the following. > 1) sequence number the frames at the display rate. > 2) provide an api for the application to predict the time of each frame > number in the sequence. I.e The next 5 frames will display at time > X1,X2,X3,X4,X5. Also provide a way to determine the "frame submited to > frame displayed" latency. So the user application knows how many frames in > advance it needs to do the submit. > 3) provide an api for the application to ensure that a frame it submits > will get displayed at display rate sequence number X. > 4) If frame X has already past, only display it if there are now newer > frames in the quene, otherwise drop it. To me, all that sounds like a library API of somewhat higher level than display server protocol. We just need to make sure the protocol has everything to support such a library. I think item 4 is already implied in the protocol. Also, monitor refresh rates may change, which is why I think a timestamp is better in the protocol than a sequence number tied to a refresh rate. Another thing missing in the protocol sketch is an event notifying the client about current output refresh rate changes. > Summary: > For the best video streaming experience, timestamps on the frame are not > very useful, what is useful is predicting exactly when the frame will > actually be displayed to the user. I hope the three timestamps would allow you to estimate everything you need: - when you queued a buffer (sent the request) - the timestamp you asked the buffer to be presented at - the timestamp the buffer really was presented Plus of course the same for the next buffer, so you know e.g. how long a buffer was on screen etc. How does that sound? Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: SIGBUS when writing to a wl_shm surface on a full tmpfs / ftruncate() vs fallocate()
On 17/10/2013 09:24, Pekka Paalanen wrote: On Wed, 16 Oct 2013 19:29:47 +0200 Olivier BLIN wrote: [...] > Having a small tmpfs is likely a common use in the embedded world, and > it would be nice to avoid such obscure crashes if possible. > What do you think of using fallocate() when supported instead of > ftruncate() in wayland/weston? Hi, I think this would be a good idea. I have hit the SIGBUS myself before, and did not know about fallocate() and friends. Does the glibc fallback still avoid the application dying on SIGBUS if space runs out? Hi Pekka, I have tried inlining the internal glibc fallback in my uClibc-based test application, and it also avoids the segfault, since it is using write() on the fd instead of writing on the mmaped file. write() will just error out with ENOSPC, and posix_fallocate() will forward this error code. And actually, the glibc fallback is smarter than what I initially wrote, it is not filling the file with zero, it is just writing one byte for every block (with means for each 4k page on a tmpfs). So, it seems to be a good compromise to use posix_fallocate() instead of ftruncate(). posix_fallocate() is more portable than fallocate(), which is Linux-specific and exposes flags which we do not need. I guess we can just use posix_fallocate() instead of ftruncate() for all shm allocations, regardless of the kernel version. For resize operations like shm_pool_resize() in wayland-cursor, we can also use posix_fallocate() to initialize the extra space when growing instead of using ftruncate(). Thanks for your feedback -- Olivier Blin - SoftAtHome This message and any attachments herein are confidential, intended solely for the addressees and are SoftAtHome.s ownership. Any unauthorized use or dissemination is prohibited. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. This message and any attachments herein are confidential, intended solely for the addressees and are SoftAtHome.s ownership. Any unauthorized use or dissemination is prohibited. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] wl_surface video protocol extension
Hi, I have extensive experience with video streaming and display having worked on the xine video player. Setting time stamps on a stream of video frames is not the entire solution. The biggest problem with displaying video on computer displays is "frame rate adaption". I.e. The frame rate of the video frames might not equal the frame rate of the display. What is really needed is a predictor. I.e. If I send this frame to the video hardware, what is the exact time it will be displayed. A predictor might be difficult, so some callback after the frame is displayed giving the exact time the frame was displayed would also help. The video player could then use this information to adjust the frame submission to ensure the frame was displayed closer to when it needs to be. There are various artifacts that appear as a result of frame rate adaption. One of these is field dominance. This is where the top field is displayed for longer than the bottom field. This results in the appearance of flickering lines to the viewer. If you could determine how long the top field was presented to the user, you could maybe make adjustments to make the bottom field appear for a similar amount of time. So, I would propose the following. 1) sequence number the frames at the display rate. 2) provide an api for the application to predict the time of each frame number in the sequence. I.e The next 5 frames will display at time X1,X2,X3,X4,X5. Also provide a way to determine the "frame submited to frame displayed" latency. So the user application knows how many frames in advance it needs to do the submit. 3) provide an api for the application to ensure that a frame it submits will get displayed at display rate sequence number X. 4) If frame X has already past, only display it if there are now newer frames in the quene, otherwise drop it. Summary: For the best video streaming experience, timestamps on the frame are not very useful, what is useful is predicting exactly when the frame will actually be displayed to the user. Kind Regards James ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: SIGBUS when writing to a wl_shm surface on a full tmpfs / ftruncate() vs fallocate()
On Wed, 16 Oct 2013 19:29:47 +0200 Olivier BLIN wrote: > Hi, > > When creating a wl_shm pool with os_create_anonymous_file(), the > underlying storage file is created on a tmpfs, and its size is set with > ftruncate(). > Though, when the tmpfs isn't big enough to hold this file, there is no > error at the pool creation, since it is handled as a sparse file and its > size is not reserved on the filesystem. > > This has nasty side-effects, the client using the wl_shm surface from > this pool will happily continue to use it, and has no way to properly > catch errors when writing to the surface. > The client will just receive a SIGBUS when writing to the shm surface, > just after having drained the tmpfs of space. > In simple-shm, the crash usually occurs in the initial memset() just > after the buffer creation, but for clients not doing an initial clear, > the crash can occur in less obvious places, like > pixman_image_composite() in my case. > > A solution could be to pre-allocate the shm pool, by using fallocate() > or posix_fallocate() instead of ftruncate(). > On newer Linux kernels (>= 3.5), the fallocate() operation is optimized > for tmpfs (kernel commit e2d12e22c59ce714008aa5266d769f8568d74eac), it > mostly allocates the pages and marks them as dirty. > > On older kernels, the fallocate() operation won't be supported on tmpfs, > but the glibc will fallback on its internal implementation that fills > with zero (glibc commit a95a608f1b07a5c6e562294c570e89645d9b6176 for the > syscall support and older commit > bb8e0116cd59b11053154fb4adbad9f06a344147 for the fallback). > uClibc git master also supports fallocate(), but it does not seem to > have a fallback (uClibc commit 5643900913f64c00f1c2958914586708efa5a473). > > Usages of ftruncate() and os_create_anonymous_file() are in wayland > (wayland-cursor) and weston (shm clients, compositor-wayland, xkb keymap). > Some users are already doing a memset() on the full shm buffer after its > creation, but still, crashing with a SIGBUS is not the nicest way to fail. > > Having a small tmpfs is likely a common use in the embedded world, and > it would be nice to avoid such obscure crashes if possible. > What do you think of using fallocate() when supported instead of > ftruncate() in wayland/weston? Hi, I think this would be a good idea. I have hit the SIGBUS myself before, and did not know about fallocate() and friends. Does the glibc fallback still avoid the application dying on SIGBUS if space runs out? Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
