We cannot handle just one of the two being NULL later down the road
(e.g. divide by zero in matrix projection code),
just ignore any such configure request.
Found through static analysis
The test was done after dereferencing output in pointer_handle_enter,
just move it up one line.
No reason pointer_handle_leave would not need the check if enter needs
it, add it there.
Found through static analysis.
These operations are done in 32-bit arithmetics before being casted to 64-bit,
thus can overflow before the cast.
Casting early fixes the issue.
Found through static analysis
recvmsg(3) returns 0 if the connection partner has shut down its socket.
The communicate function considered 0 a successful message, though, and
keeps calling recvmsg(3) again and again.
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
Updates the projection matrix for the cursor plane in the DRM backend,
when the cursor is set, so new cursor are uploaded with the correct
transformation.
This changes the `wlr_output_impl.set_cursor` function to take a
`wlr_texture` instead of a byte buffer. This simplifies the
DRM and Wayland backends since they were creating textures from
the byte buffer anyway.
With this commit, performance should be improved when moving the
cursor since outputs don't need to be re-rendered anymore.
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>
Guido Günther
emersion
Drew DeVault
Vincent Vanlaer
Dominique Martinet
Tobias Blass
Scott Anderson
Ilia Bozhinov
Markus Ongyerth
morganamilo
Uli Schlachter
Tancredi Orlando
Tony Crisci