Compositors now have more control over how the backend creates its
renderer. Currently all backends create an EGL/GLES2 renderer, so
the necessary attributes for creating the context are passed to a
user-provided callback function. It is responsible for initializing
provided wlr_egl and to return a renderer. On fail, return 0.
Fixes#987
When the X11 server sends an expose event, that means that "this
rectangle here (the event contains x,y,width,height) has undefined
contents on your window; please redraw that". This means that we need a
swap. However, so far the code does not actually enforce that a swap
happens.
For example, start rootston, switch to another workspace and then switch
back. The rootston window will not be redrawn (before commit
52b058c2a3, it would just be fully white; after that commit it will
show whatever was visible on the old workspace). This is because the
drawing code concludes that nothing needs to be done. However, in fact a
swap is necessary.
This reverts commit e79d924588, because its optimisation is already
done now: wlr_output_update_needs_swap() emits a signal, which is
handled by wlr_output_damage with a call to wlr_output_schedule_frame().
This function does nothing if a frame is already pending. Thus, the
optimisation from commit e79d924588 now happens implicitly.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When resizing rootston with the mouse, the result is really slow. One
can see that rootston needs quite a while for drawing the newly visible
area. This is because every single expose event is handled on its own
and causes (apparently) a full repaint or at least a swap.
This commit improves things by only causing a new frame if none is
pending already.
With this change, there is almost no delay in rootston drawing the newly
visible area.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Before this commit, the x11 server would fill any exposed area with
white before the wlroots x11 backend got a chance to do anything. This
was e.g. visible when running rootston and resizing the window: When the
window becomes larger, the new area is filled with black.
By just not setting a back pixel value, this commit gets rid of this
behaviour.
Signed-off-by: Uli Schlachter <psychon@znc.in>
handle_x11_event() and x11_handle_input_event() react to different kinds
of events, so it does not make much of a difference if
x11_handle_input_event() signals if it handled an event or not.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The xcb_connection_t instance that is used here comes from
XGetXCBConnection(), is created by XOpenDisplay(), and is owned by the
returned Display*. Calling xcb_disconnect() directly on it leads to
various use-after-frees during shutdown, as reported by valgrind. The
first one of the about 30 errors is:
Invalid read of size 4
at 0x71F2051: xcb_take_socket (in /usr/lib64/libxcb.so.1.1.0)
by 0x78551DD: ??? (in /usr/lib64/libX11.so.6.3.0)
by 0x7855A14: _XFlush (in /usr/lib64/libX11.so.6.3.0)
by 0x7858504: _XGetRequest (in /usr/lib64/libX11.so.6.3.0)
by 0x7838966: XFreeGC (in /usr/lib64/libX11.so.6.3.0)
by 0x783238B: XCloseDisplay (in /usr/lib64/libX11.so.6.3.0)
by 0x4E680C2: wlr_x11_backend_destroy (backend.c:333)
by 0x4E57E94: wlr_backend_destroy (backend.c:39)
by 0x4E629FB: multi_backend_destroy (backend.c:47)
by 0x4E62B5A: handle_display_destroy (backend.c:90)
by 0x50B7E9F: ??? (in /usr/lib64/libwayland-server.so.0.1.0)
by 0x50B8476: wl_display_destroy (in /usr/lib64/libwayland-server.so.0.1.0)
Address 0xc14dda0 is 0 bytes inside a block of size 21,152 free'd
at 0x4C2DD18: free (vg_replace_malloc.c:530)
by 0x4E680A5: wlr_x11_backend_destroy (backend.c:330)
by 0x4E57E94: wlr_backend_destroy (backend.c:39)
by 0x4E629FB: multi_backend_destroy (backend.c:47)
by 0x4E62B5A: handle_display_destroy (backend.c:90)
by 0x50B7E9F: ??? (in /usr/lib64/libwayland-server.so.0.1.0)
by 0x50B8476: wl_display_destroy (in /usr/lib64/libwayland-server.so.0.1.0)
by 0x40C54E: main (main.c:84)
Block was alloc'd at
at 0x4C2EA1E: calloc (vg_replace_malloc.c:711)
by 0x71F0C60: xcb_connect_to_fd (in /usr/lib64/libxcb.so.1.1.0)
by 0x71F4BD4: xcb_connect_to_display_with_auth_info (in /usr/lib64/libxcb.so.1.1.0)
by 0x7854AA1: _XConnectXCB (in /usr/lib64/libX11.so.6.3.0)
by 0x7845481: XOpenDisplay (in /usr/lib64/libX11.so.6.3.0)
by 0x4E681B6: wlr_x11_backend_create (backend.c:376)
by 0x4E580EE: wlr_backend_autocreate (backend.c:99)
by 0x40C27D: main (main.c:35)
Normally, one would expect this to crash during XCloseDisplay() when
xcb_disconnect() is called again and frees the same data again (glibc would
detect a double free). However, XCloseDisplay() tries to clean up some internal
caches first for which it has to send requests to the X11 server (e.g. the
XFreeGC() above). This fails since the file descriptor was already closed,
which causes an IO error. Xlib's _XDefaultIOError() handles this by printing an
error message and calling exit(1).
Thus, the only symptom of this problem was compositors exiting
mid-shutdown and printing an error message:
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
after 6 requests (6 known processed) with 0 events remaining.
Fixes: https://github.com/swaywm/wlroots/issues/745
Signed-off-by: Uli Schlachter <psychon@znc.in>
The backend destroy signal is emitted before the output_remove
signal is. When the destroy signal is emitted listeners remove
their output_remove listener, so the output_remove signal is never
received and listeners have an invalid output pointer.
The correct way to solve this would be to remove the output_remove
signal completely and use the wlr_output.events.destroy signal
instead. This isn't yet possible because wl_signal_emit is unsafe
and listeners cannot be removed in listeners.
This backports some changes to #319 to fix the screenshooter data
format. This also adds wlr_backend_get_renderer which will be
useful to support multiple renderers.
In pointer.c, some axis event was emitted even if the event pointer did not have
current axis.
In X11 backend pointer scroll events seem to be composed of both BUTTON_PRESS
and BUTTON_RELEASE. Therefore we should skip one of them (RELEASE) to avoid
event duplication.
