The deleted includes are redundant, because other headers will include
the necessary files. Additionally, they cause build failures, because
including EGL/egl.h or EGL/eglext.h directly, instead of through
wlr/render/egl.h or wlr/render/interface.h, will mean that
MESA_EGL_NO_X11_HEADERS will not have been defined, and so the EGL
headers will attempt to pull in unnecessary X11 headers that may not
exist on the system.
For the headers produced by glgen.sh, the includes couldn't simply be
deleted, because no other header would include the EGL headers. Neither
wlr/render/egl.h or wlr/render/interface.h felt appropriate to include,
so I opted instead to copy the MESA_EGL_NO_X11_HEADERS definition before
the EGL includes.
backend/headless/output.c:132:3: error: format specifies type 'long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat]
++backend->last_output_num);
^~~~~~~~~~~~~~~~~~~~~~~~~~
backend/noop/output.c:72:3: error: format specifies type 'long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat]
++backend->last_output_num);
^~~~~~~~~~~~~~~~~~~~~~~~~~
backend/wayland/output.c:294:3: error: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat]
++backend->last_output_num);
^~~~~~~~~~~~~~~~~~~~~~~~~~
backend/x11/output.c:150:3: error: format specifies type 'long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat]
++x11->last_output_num);
^~~~~~~~~~~~~~~~~~~~~~
* wlr_output: Indicate modes link
* wlr_output: Introduce preferred flag
This indicates an outputs preferred mode.
* drm: Set preferred flag for an outputs preferred mode
This improves the way the output numbers are handled for the noop
backend. Instead of using the number of active outputs plus one, the
last used number is stored and new outputs will increment it. This
fixes the situation where you start with one output, create a second,
close the first, and create a third. Without this, both outputs will be
NOOP-2, which causes an issue since the identifier will also be
identical. With this, the last output is NOOP-3 and the outputs can be
distinguished.
This improves the way the output numbers are handled for the headless
backend. Instead of using the number of active outputs plus one, the
last used number is stored and new outputs will increment it. This
fixes the situation where you start with one output, create a second,
close the first, and create a third. Without this, both outputs will be
HEADLESS-2, which causes an issue since the identifier will also be
identical. With this, the last output is HEADLESS-3 and the outputs can
be distinguished.
This improves the way the output numbers are handled for the x11
backend. Instead of using the number of active outputs plus one, the
last used number is stored and new outputs will increment it. This
fixes the situation where you start with one output, create a second,
close the first, and create a third. Without this, both outputs will be
X11-2, which causes an issue since the identifier will also be
identical. With this, the last output is X11-3 and the outputs can be
distinguished.
This improves the way the output numbers are handled for the wayland
backend. Instead of using the number of active outputs plus one, the
last used number is stored and new outputs will increment it. This
fixes the situation where you start with one output, create a second,
close the first, and create a third. Without this, both outputs will be
`WL-2`, which causes an issue since the identifier will also be
identical. With this, the last output is `WL-3` and the outputs can be
distinguished.
This is the first step towards being able to run via DRM leasing and on render
nodes.
Test with:
export WLR_BACKENDS=drm
export WLR_SESSION=noop
export WLR_DRM_DEVICES=/dev/dri/renderD128
If *changed_outputs is not supplied by the calling function, track the local
allocation with a bool variable and free the allocation at the end of the
function.
On DRM resume, such as switching back to a TTY, the output needs to be
modeset to the current mode. However, wlr_output_set_mode will return
early when attempting to set the mode to the current mode. This just
steps around wlr_output_set_mode and calls drm_connector_set_mode
directly.
There is no point in modesetting an output to a mode that it is already
set to. Modesetting will cause the output to briefly flicker which is
undesirable for a noop. This returns early in `drm_connector_set_mode`
when attempting to modeset to the current mode.
In order for a surface to be used as a cursor plane framebuffer, it
appears that requiring the buffer to be linear is sufficient.
GBM_BO_USE_SCANOUT is added in case GBM_BO_USE_LINEAR isn't sufficient
on untested hardware.
Fixes#1323
Removed wlr_drm_plane.cursor_bo as it does not serve any purpose
anymore.
Relevant analysis (taken from the PR description):
While trying to implement a fix for #1323, I found that when exporting
the rendered surface into a DMA-BUF and reimporting it with
`GBM_BO_USE_CURSOR`, the resulting object does not appear to be valid.
After some digging (turning on drm-kms debugging and switching to legacy
mode), I managed to extract the following error: ```
[drm:__setplane_check.isra.1 [drm]] Invalid pixel format AR24
little-endian (0x34325241), modifier 0x100000000000001 ``` The format
itself refers to ARGB8888 which is the same format as
`renderer->gbm_format` used in master to create the cursor bo. However,
using `gbm_bo_create` with `GBM_BO_USE_CURSOR` results in a modifier of
0. A modifier of zero represents a linear buffer while the modifier of
the surface that is rendered to is `I915_FORMAT_MOD_X_TILED` (see
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/uapi/drm/drm_fourcc.h?h=v4.20.6#n263).
In order to fix this mismatch in modifier, I added the
`GBM_BO_USE_LINEAR` to the render surface and everything started to work
just fine. I wondered however, whether the export and import is really
necessary. I then decided to test if the back buffer of the render
surface works as well, and at least on my hardware (Intel HD 530 and
Intel UHD 620) it does. This is the patch in this PR and this requires
no exporting and importing.
I have to note that I cheated in order to import DMA_BUFs into a cursor
bo when doing the first tests, since on import the Intel drivers check
that the cursor is 64x64. This is strange since cursor sizes other than
64x64 have been around for quite some time now
(https://lists.freedesktop.org/archives/mesa-commit/2014-June/050268.html).
Removing this check made everything work fine. I later (while writing
this PR) found out that `__DRI_IMAGE_USE_CURSOR` (to which
`GBM_BO_USE_CURSOR` translates) has been deprecated in mesa
(https://gitlab.freedesktop.org/mesa/mesa/blob/master/include/GL/internal/dri_interface.h#L1296),
which makes me wonder what the usecase of `GBM_BO_USE_CURSOR` is. The
reason we never encountered this is that when specifying
`GBM_BO_USE_WRITE`, a dumb buffer is created trough DRM and the usage
flag never reaches the Intel driver directly. The relevant code is in
https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gbm/backends/dri/gbm_dri.c#L1011-1089
. From this it seems that as long as the size, format and modifiers are
right, any surface can be used as a cursor.
When a wlroots compositor runs as a systemd user unit there is no
session associated with the compositor process. Instead we need to
attach to an active and graphical user session.
This change first looks for an available session for the process, and if
there isn't one falls back to display in the oldest available graphical
session.
This work was modeled after a similar change to mutter -
https://gitlab.gnome.org/GNOME/mutter/merge_requests/150.
We create the EGL config with GBM_FORMAT_ARGB8888, but then initialize GBM BOs
with GBM_FORMAT_XRGB8888. This mismatch confuses Mesa.
Instead, we can always use GBM_FORMAT_ARGB8888, and use DRM_FORMAT_XRGB8888
when calling drmModeAddFB2.
Fixes https://github.com/swaywm/wlroots/issues/1438
Frame events group logically connected pointer events. It makes sense to make
the backend responsible for sending frame events, since once the events are
split (ie. once the frame events are stripped) it's not easy to figure out
which events belongs to which frame again.
This is also how Weston handles frame events.
Fixes https://github.com/swaywm/wlroots/issues/1468
Set the default "wlroots - " title when the title argument to the
set_title functions is NULL. Otherwise, for at least the Wayland
backend, we'd crash because xdg_toplevel_set_title doesn't handle a NULL
pointer.
When there aren't enough CRTCs for all outputs, we try to move a CRTC from a
disabled output to an enabled one. When this happens, the old output's state
wasn't changed, so the compositor thought it was still enabled and rendering.
This commit marks the old output as WLR_DRM_CONN_NEEDS_MODESET and sets its
current mode to NULL.
The noop backend is similar to headless, but it doesn't contain a
renderer. It can be used as a place to stash views for when there's no
physical outputs connected.
As evdev-proto is installed by CI some files have been missed:
../examples/pointer-constraints.c:2:10: fatal error: 'linux/input-event-codes.h' file not found
#include <linux/input-event-codes.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~
../examples/relative-pointer-unstable-v1.c:5:10: fatal error: 'linux/input-event-codes.h' file not found
#include <linux/input-event-codes.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~
Values from libdrm are likely more reliable than raw values from the EDID. We
were already using values from libdrm, but they were overwritten by parse_edid.
See drm.c:
wlr_conn->output.phys_width = drm_conn->mmWidth;
wlr_conn->output.phys_height = drm_conn->mmHeight;
This commit changes `scan_drm_connectors` to add new outputs to the end of the
list. That way, it's easier to understand what's going on with indices.
When we need to destroy outputs, we now walk the list in reverse order. This
ensures indices remain correct while iterating and removing items from the
list.
We now also make outputs without a CRTC disappear (those are in
WLR_DRM_CONN_NEEDS_MODESET state).
The renderer redesign is going to need the render fd before the backend
is fully started, so we have to move the wl registry code to when the
backend is created instead of when it is started.
We also need to stash the wl_keyboard and emit it to library users
later, once they've added their listeners and started the backend.
There was a missing copy_drm_surface_mgpu call in drm_connector_schedule_frame
so we asked for a pageflip with an unknown BO, resulting in ENOENT.
Additionally, this commit makes schedule_frame return a bool indicating
failures. This allows schedule_frame_handle_idle_timer to only set
frame_pending to true if a frame has been successfully scheduled. Thus, if a
pageflip fails, rendering won't be blocked forever anymore.
In case a pageflip is already pending, true is returned because a frame has
already been scheduled and will be sent sometime soon.
This allows the legacy interface to be used instead of atomic if needed. This
is a workaround to make some Intel GPUs work (if this variable is unset) as
well as to make some AMD GPUs work (if this variable is set).
If a pageflip is pending before cleanup, it's still pending after. This
is used line 1177: drm_connector_cleanup is called and
conn->pageflip_pending is checked afterwards.
Fixes#1297
This prevents the idle event to be activated on a destroyed
output.
This also makes the backend responsible for free-ing modes, as it
is the one allocating them and adding them to the list. Note that
the DRM backend (the only one using modes) already frees them.
This desynchronizes our rendering loop with the vblank cycle.
In case a compositor doesn't swap buffers but schedules a frame,
emitting a frame event immediately enters a busy-loop.
Instead, ask the backend to send a frame when appropriate. On
Wayland we can just register a frame callback on our surface. On
DRM we can do a no-op pageflip.
Fixes#617Fixesswaywm/sway#2748
When a pageflip is pending, we'll get a DRM event for the connector
in the future. We don't want to free the connector immediately
otherwise we'll use-after-free in the pageflip handler.
This commit adds a new state, "DISAPPEARED". This asks the pageflip
handler to destroy the output after it's done pageflipping.
Sessions can now be retrieved from a backend in a more general manner.
Multi-backend gets back its `session` field that contains the session
if one was created, removing the interfacing from multi backend with the
drm backend directly. This adds the possibility to use sessions even
without the drm backend.
It additionally fixes the bug that 2 session objects got created when
WLR_BACKENDS were set to "libinput,drm".
To allow vt switching without drm backend (and drm fd) on logind, start
listening to PropertiesChanged signals from dbus and parse the session
"Active" property when no master fd was created (this does not change
current drm backend behaviour in any way).
This commit allows outputs that need a CRTC to steal it from
user-disabled outputs. Note that in the case there are enough
CRTCs, disabled outputs don't loose it (so there's no modeset
and plane initialization needed after DPMS). CRTC allocation
still prefers to keep the old configuration, even if that means
allocating an extra CRTC to a disabled output.
CRTC reallocation now happen when enabling/disabling an output as
well as when trying to modeset. When enabling an output without a
CRTC, we realloc to try to steal a CRTC from a disabled output
(that doesn't really need the CRTC). When disabling an output, we
try to give our CRTC to an output that needs one. Modesetting is
similar to enabling.
A new DRM connector field has been added: `desired_enabled`.
Outputs without CRTCs get automatically disabled. This field keeps
track of the state desired by the user, allowing to automatically
re-enable outputs when a CRTC becomes free.
This required some changes to the allocation algorithm. Previously,
the algorithm tried to keep the previous configuration even if a
new configuration with a better score was possible (it only changed
configuration when the old one didn't work anymore). This is now
changed and the old configuration (still preferred) is only
retained without considering new possibilities when it's perfect
(all outputs have CRTCs).
User-disabled outputs now have `possible_crtcs` set to 0, meaning
they can only retain a previous CRTC (not acquire a new one). The
allocation algorithm has been updated to do not bump the score
when assigning a CRTC to a disabled output.
This commit implements device type discovery by calling two ioctls
(DRM_IOCTL_VERSION and EVIOCGVERSION) on the device. These iocts are
specific to drm and input devices respectively, therefore we can
determine the device type based on which one returns an error.
This commit handles better situations in which the number of
connected outputs is greater than the number of available CRTCs.
It'll enable as many outputs as possible, and transfer CRTCs to
outputs that need one on unplug.
This changes CRTC and plane reallocation to happen after scanning
DRM connectors instead of on modeset.
This cleanups CRTCs and planes on unplug to allow them to be
re-used for other outputs.
On modeset, if an output doesn't have a CRTC, the desired mode is
saved and used later when the output gains a CRTC.
Future work includes giving priority to enabled outputs over
disabled ones for CRTC allocation. This requires the compositor to
know about all outputs (even outputs without CRTCs) to properly
modeset outputs enabled in the compositor config file and disable
outputs disabled in the config file.
The VT the compositor was started from was not activated after exiting
the compositor, which resulted in arriving on a blank VT. This commit
fixes that by introducing a new field in direct_session struct that
stores the last active VT so that it can be activated in
direct_session_destroy.
This prevents receiving modesetting requests from the compositor
while we don't have the whole picture (ie. while we haven't yet
scanned all connectors).
This also makes connectors without CRTCs disabled (they can't be
enabled yet even if some CRTCs are free'd -- this is future work).
A few pedantic changes and unused variables (1-4), and genuine bugs (5,
6).
The reports with the corresponding files and lines numbers are as
follows.
1. backend/libinput/tablet_pad.c@31,44,57
"Allocator sizeof operand mismatch"
"Result of 'calloc' is converted to a pointer of type 'unsigned int',
which is incompatible with sizeof operand type 'int'"
2. types/tablet_v2/wlr_tablet_v2_pad.c@371
"Allocator sizeof operand mismatch"
"Result of 'calloc' is converted to a pointer of type 'uint32_t', which
is incompatible with sizeof operand type 'int'"
3. types/wlr_cursor.c@335
"Dead initialization"
"Value stored to 'dx'/'dy' during its initialization is never read"
4. rootston/xdg_shell.c@510
"Dead initialization"
"Value stored to 'desktop' during its initialization is never read"
5. types/tablet_v2/wlr_tablet_v2_pad.c@475
"Dereference of null pointer"
"Access to field 'strips' results in a dereference of a null pointer
(loaded from field 'current_client')"
The boolean logic was incorrect (c.f. the check in the following
function).
6. examples/idle.c@163,174,182
"Uninitialized argument value"
"1st function call argument is an uninitialized value"
If close_timeout != 0, but simulate_activity_timeout >= close_timeout,
the program would segfault at pthread_cancel(t1).
The major device number does not indicate the device type on FreeBSD,
and AFAIK the only way to differentiate between DRM, input, and other
devices is checking the fd path. This commit implements that.
The drmDropmaster and drmSetmaster calls are necessary, because the
implicit drop (that should occur when the DRM fd is closed) seems not
to be working in some scenarios (e.g. if you have a tmux session
running - maybe the fd is retained somehow by tmux?). This is a
problem, because once you exit the compositor, you can't start it (or
any other program that wants to be DRM master) again until you close
all your tmux sessions.
On some systems (most notably laptops with two GPUs) there are GPUs that
don't have attached outputs. However, we still want to load those GPUs
because they could still be used by the compositor for rendering.
