On Thu, 24 Mar 2016 11:16:54 -0500 Derek Foreman <[email protected]> wrote:
> On 24/03/16 10:10 AM, Pekka Paalanen wrote: > > From: Pekka Paalanen <[email protected]> > > > > X11 is the only backend that still used the input event loop. > > > > This patch is an identical rewrite of > > 6deb09ef8a72164947cdfa5f2414e292c7672c9c which was then reverted in > > 3bebe6461a9de5d8c5c7da0261c70cd250fa1fde for reasons unrecorded. This > > patch is also the revert of 22ba60e514e074e4bdee1529aa8d22600712f001. > > I couldn't remember why 6deb09ef8a was reverted, so I dug through the > mailing list archives and found a rather amusing thread between you and > I. :) > > Reviewed-by: Derek Foreman <[email protected]> > > For both patches. Cool, pushed: 94cb06a..87953b7 master -> master > (Now, is it worthwhile to revert d540f4bb to remove the unneeded > complexity?) I probably wouldn't. It shouldn't cause harm, but I'd lean on not changing it. Thanks, pq > > Originally input devices were moved into their own event loop in > > 7ea10864c2fc7370f5ada88a3fc91ab5f188da00 and the reason for that is > > explained in 7dbf5e2ea744bde56b65ba45b935b77df4a783e1. > > > > The idea behind the input event loop was that it would be beneficial to > > process and relay input events to clients just once during an output > > repaint cycle, because clients cannot update the image on screen any > > faster anyway. All input events also carry a timestamp, so we didn't > > lose any timing information. This was supposed to save power by reducing > > the process wake-ups and context switches. There was also a mention of > > reducing lag. > > > > However, the concept of an output repaint loop does not really work out > > when you have several outputs, but the input devices are not exclusive > > to a certain output. > > > > The logic for driving the input event loop in Weston core was written to > > assume a single output. When you have multiple outputs with independent > > repaint cycles, the input event loop handling becomes fairly random, one > > output freezes input while another output thaws it, etc. > > > > The DRM backend stopped using the input event loop when it started using > > the libinput input backend, which became the default in > > 3f5e906268448f2d84b115c5f3d22165ce0021b1, and the old code was finally > > ripped out in 823ad33ef34fa32b14b300d987fb9d2e2a42e9c4. > > > > Signed-off-by: Pekka Paalanen <[email protected]> > > --- > > src/compositor-x11.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/src/compositor-x11.c b/src/compositor-x11.c > > index f1cb71b..91a7c2e 100644 > > --- a/src/compositor-x11.c > > +++ b/src/compositor-x11.c > > @@ -1576,6 +1576,7 @@ x11_backend_create(struct weston_compositor > > *compositor, > > { > > struct x11_backend *b; > > struct x11_output *output; > > + struct wl_event_loop *loop; > > struct weston_config_section *section; > > int i, x = 0, output_count = 0; > > int width, height, scale, count; > > @@ -1705,8 +1706,9 @@ x11_backend_create(struct weston_compositor > > *compositor, > > x = pixman_region32_extents(&output->base.region)->x2; > > } > > > > + loop = wl_display_get_event_loop(compositor->wl_display); > > b->xcb_source = > > - wl_event_loop_add_fd(compositor->input_loop, > > + wl_event_loop_add_fd(loop, > > xcb_get_file_descriptor(b->conn), > > WL_EVENT_READABLE, > > x11_backend_handle_event, b); > > >
pgpRe2Y12uwoT.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
