Age | Commit message (Collapse) | Author |
|
This allows the kernel to access our buffer damage. Some drivers
can take advantage of this, e.g. for PSR2 panels (Panel Self
Refresh) or for transfer over USB.
Closes: https://github.com/swaywm/wlroots/issues/1267
|
|
If a subsurface is being placed below a subsurface right above it, this
should be a noop. However, `node` pointed to the subsurface that was
moved, which resulted in `subsurface->parent_pending_link` being
inserted into itself, breaking parent's pending subsurface list.
This commit separates finding the requested node and getting it's `prev`
field, fixing the issue.
|
|
This reverts commit 85757665e6e1393773b36282aa244feb10b7a5fe.
We now check if the output is enabled within wlr_output_send_frame, no
need to handle this explicitly in the DRM backend. This also fixes a
race which was introduced with this commit: if we schedule the flip,
disable and commit the output before the flip happens,
output.frame_pending will not be reset to false. We than always fail to
enable the output subsequently:
00:07:13.276 [INFO] [sway/commands.c:257] Handling command 'output DP-2 enable'
00:07:13.276 [DEBUG] [sway/commands.c:428] Subcommand: enable
00:07:13.276 [DEBUG] [sway/config/output.c:204] Merging on top of existing output config
00:07:13.276 [DEBUG] [sway/config/output.c:227] Config stored for output DP-2 (enabled: 1) (-1x-1@-1.000000Hz position 0,0 scale -1.000000 subpixel unknown transform -1) (bg /home/phoenix/Pictures/Wallpapers/mine/oper.jpg fill) (dpms 1) (max render time: -1)
00:07:13.276 [DEBUG] [sway/config/output.c:351] Turning on output DP-2
00:07:13.276 [DEBUG] [sway/config/output.c:360] Set preferred mode
00:07:13.276 [DEBUG] [wlr] [backend/drm/drm.c:465] connector DP-2: Can't enable an output without a buffer
00:07:13.276 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
00:07:13.277 [DEBUG] [sway/config/output.c:329] Output DPI: 162.560000x161.364706
00:07:13.277 [DEBUG] [sway/config/output.c:400] Auto-detected output scale: 1.000000
00:07:13.277 [DEBUG] [sway/config/output.c:430] Committing output DP-2
00:07:13.277 [DEBUG] [wlr] [types/wlr_output.c:729] Tried to commit a buffer while a frame is pending
since the basic_output_test will always fail.
Reset frame_pending to false even if the output has been disabled in the
meantime.
Fixes https://github.com/swaywm/wlroots/issues/3109
|
|
Similar to commit 85757665e6e1 ("backend/drm: Check if output is enabled
before sending frame event"), check if the output is still enabled
before sending the frame event. This fixes the bug not only for the DRM
backend, but for wayland and X11 as well.
|
|
This should fix the following backtrace, seen on my desktop with one
output disabled:
#0 atomic_crtc_commit (conn=0x270f5c0, state=0x270f6d0, flags=0, test_only=<optimized out>) at ../backend/drm/atomic.c:178
drm = 0x1ae9c10
output = 0x270f5c0
crtc = 0x0
modeset = false
active = false
mode_id = 43989232
gamma_lut = 0
prev_vrr_enabled = <optimized out>
vrr_enabled = <optimized out>
atom = {req = 0x270f5c0, failed = 48}
ok = <optimized out>
#1 0x00007f1104f33128 in drm_crtc_commit (conn=conn@entry=0x270f5c0, state=state@entry=0x270f6d0, flags=flags@entry=0, test_only=test_only@entry=true) at ../backend/drm/drm.c:339
__PRETTY_FUNCTION__ = "drm_crtc_commit"
drm = <optimized out>
crtc = 0x0
ok = <optimized out>
#2 0x00007f1104f34e6c in drm_connector_test (output=output@entry=0x270f5c0) at ../backend/drm/drm.c:488
conn = 0x270f5c0
unsupported = <optimized out>
#3 0x00007f1104f35424 in drm_connector_commit (output=0x270f5c0) at ../backend/drm/drm.c:578
conn = 0x270f5c0
#4 0x00007f1104f600b7 in wlr_output_commit (output=output@entry=0x270f5c0) at ../types/wlr_output.c:837
now = {tv_sec = 7732, tv_nsec = 623813006}
pre_event = {output = 0x270f5c0, when = 0x7ffecc1be570}
back_buffer = 0x0
scale_updated = <optimized out>
geometry_updated = <optimized out>
committed = <optimized out>
event = {output = 0x0, committed = 4401048, when = 0x29f38f0}
#5 0x0000000000433047 in apply_output_config (oc=oc@entry=0x29f38f0, output=output@entry=0x2710720) at ../sway/config/output.c:431
wlr_output = 0x270f5c0
output_box = <optimized out>
#6 0x0000000000433aaf in apply_output_config_to_outputs (oc=0x2308400) at ../sway/config/output.c:649
current = 0x29f38f0
name = <optimized out>
wildcard = true
id = "Dell Inc. DELL U2410 F525M9AK0MML\000\060\060\060ACD7\000\000\000\000\000\000\000\220\063\240\002\000\000\000\000L5C\000\000\000\000\000\377\377\377\377\000\000\000\000\377\377\377\377\000\000\000\000\377\377\377\377\000\000\000\000\377\377\377\377\000\000\000\000\355\240E\000\000\000\000\000\377\377\377\377\000\000\000\000@\206+\002\000\000\000\000`\260.\002\000\000\000"
sway_output = 0x2710720
tmp = 0x2242030
seat = <optimized out>
#7 0x000000000043df6b in cmd_output (argc=<optimized out>, argv=0x2a03390) at ../sway/commands/output.c:108
error = <optimized out>
output = <optimized out>
background = false
#8 0x0000000000410304 in execute_command (_exec=_exec@entry=0x2975d20 "output * dpms off", seat=0x22a3280, seat@entry=0x0, con=con@entry=0x0) at ../sway/commands.c:291
res = <optimized out>
argc = 4
argv = 0x2a03370
handler = 0x479230 <handlers+560>
cmd = <optimized out>
matched_delim = 0 '\000'
containers = 0x0
using_criteria = false
__PRETTY_FUNCTION__ = "execute_command"
exec = 0x28f63c0 "output * dpms off"
head = 0x0
res_list = 0x2a2e9d0
#9 0x0000000000418b65 in ipc_client_handle_command (client=client@entry=0x2a6ac80, payload_length=<optimized out>, payload_type=IPC_COMMAND) at ../sway/ipc-server.c:645
line = <optimized out>
res_list = <optimized out>
json = <optimized out>
length = <optimized out>
__PRETTY_FUNCTION__ = "ipc_client_handle_command"
buf = 0x2975d20 "output * dpms off"
#10 0x000000000041964c in ipc_client_handle_readable (client_fd=<optimized out>, mask=<optimized out>, data=0x2a6ac80) at ../sway/ipc-server.c:267
pending_length = <optimized out>
pending_type = <optimized out>
client = 0x2a6ac80
read_available = 31
buf = "i3-ipc\021\000\000\000\000\000\000"
received = 14
#11 0x00007f1104fc3492 in wl_event_loop_dispatch () from /nix/store/ridk7k2ka6dbk4ly7qqjgmc523s4fj89-wayland-1.19.0/lib/libwayland-server.so.0
No symbol table info available.
#12 0x00007f1104fc1135 in wl_display_run () from /nix/store/ridk7k2ka6dbk4ly7qqjgmc523s4fj89-wayland-1.19.0/lib/libwayland-server.so.0
No symbol table info available.
#13 0x000000000041ac10 in server_run (server=server@entry=0x47b0c0 <server>) at ../sway/server.c:261
No locals.
#14 0x000000000041a3fc in main (argc=<optimized out>, argv=0x7ffecc1bec68) at ../sway/main.c:395
verbose = 0
debug = 0
validate = 0
allow_unsupported_gpu = 0
long_options = {{name = 0x45b516 "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x45ee69 "config", has_arg = 1, flag = 0x0, val = 99}, {name = 0x45b51b "validate", has_arg = 0, flag = 0x0, val = 67}, {
name = 0x45b524 "debug", has_arg = 0, flag = 0x0, val = 100}, {name = 0x45b3ac "version", has_arg = 0, flag = 0x0, val = 118}, {name = 0x45a55c "verbose", has_arg = 0, flag = 0x0, val = 86}, {name = 0x45b52a "get-socketpath",
has_arg = 0, flag = 0x0, val = 112}, {name = 0x45b539 "unsupported-gpu", has_arg = 0, flag = 0x0, val = 117}, {name = 0x45b549 "my-next-gpu-wont-be-nvidia", has_arg = 0, flag = 0x0, val = 117}, {name = 0x0, has_arg = 0,
flag = 0x0, val = 0}}
config_path = 0x0
usage = 0x45b830 "Usage: sway [options] [command]\n\n -h, --help", ' ' <repeats 13 times>, "Show help message and quit.\n -c, --config <config> Specify a config file.\n -C, --validate Check the validity of the config file, th"...
c = <optimized out>
where the second output is not enabled:
(gdb) frame 4
#4 0x00007f1104f600b7 in wlr_output_commit (output=output@entry=0x270f5c0) at ../types/wlr_output.c:837
837 in ../types/wlr_output.c
(gdb) p output->enabled
$3 = false
(gdb)
The culprit being that since 604674dc54a3b2cb4b73de267c8c2bcae259c4b6 we
always try to perform a commit, even on a disabled output.
|
|
|
|
If XWayland terminates for any reason, xwm_set_cursor() has to
to be called again, so the cursor has to stick around.
|
|
Looks like this instance was missed in
e035f2b9c42b39e3eff37d0fe98bfa6422877d7a.
Fixes #3110.
|
|
The protocol specifies that all requests (aside from destroy) are
ignored after the compositor sends the closed event. Therefore,
destroying the wlroots object and rendering the resource inert
when sending the closed event keeps things simpler for wlroots and
compositors.
|
|
|
|
Saves us from walking a list.
|
|
This allows wlr_buffer users to extend it with tjeir own state.
|
|
This function was weird because it copied some fields but not all.
|
|
This wlr_surface_state field was a special case because we don't
want to save the whole current state: for instance, the wlr_buffer
must not be saved or else wouldn't get released soon enough.
Let's just inline the state fields we need instead.
|
|
This allows to have multiple addons of different types with the same
owner.
|
|
|
|
|
|
|
|
This allows callers to use wlr_output_test to check whether a mode
can be enabled, for instance.
Closes: https://github.com/swaywm/wlroots/issues/2250
|
|
Some listeners weren't removed and caused a use-after-free with
e.g. vkms when used as a secondary GPU.
|
|
Add a very basic smoke test which uses VKMS to fire up the DRM
backend.
|
|
wl_fixed_t is a 32-bit data type, but our doubles are 64-bit. This meant
that two doubles that would map to the same wl_fixed_t could compare
unequal, and send a duplicate motion event.
Refs swaywm/sway#4632.
|
|
The protocol allows compositors to not send any keymap to Wayland
clients. Handle a keymap-less keyboard correctly by sending
WL_KEYBOARD_KEYMAP_FORMAT_NO_KEYMAP instead of erroring out in the
mmap call.
|
|
|
|
|
|
When testing a modeset, make sure the caller has also provided a
buffer. This allows df0e75ba05e2 ("output: try skipping buffer
allocation if the backend allows it") to work as expected with the
DRM backend.
Closes: https://github.com/swaywm/wlroots/issues/3086
|
|
When enabling an output, skip the empty buffer allocation if the
backend accepts modesets without a buffer.
This fixes mode-setting with the noop backend.
|
|
Add a bunch of new formats for Pixman: a few missing 32-bit ones,
some 16-bit and 32-bit formats as well.
Mostly based on a Weston patch [1].
[1]: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/664
|
|
These will be added to Pixman in the next commit.
|
|
The kernel orders the mode list from highest to lowest. Preserve
this ordering in the wlr_output.modes list.
|
|
|
|
According to the viewport protocol, upon wp_viewport::destroy():
> The associated wl_surface's crop and scale state is removed.
> The change is applied on the next wl_surface.commit.
Therefore, wp_viewport_destroy(viewport) should remove all viewport state.
Currently, wlroots does not remove the crop and scale state. Instead, a
client must do:
wl_fixed_t clear = wl_fixed_from_int(-1);
wp_viewport_set_source(viewport, clear, clear, clear, clear);
wp_viewport_set_destination(viewport, -1, -1);
wp_viewport_destroy(viewport);
This commit adds the necessary logic into viewport_destroy and makes
wlroots comply with the protocol.
|
|
The half-float formats depend on GL_OES_texture_half_float_linear,
not just the GL_OES_texture_half_float extension, because the latter
does not include support for linear magni/minification filters.
The new 2101010 and 16161616F formats are only available on little-
endian builds, since their gl_types are larger than a byte and thus
endianness dependent.
|
|
This change introduces a new function to check whether the renderer
has the needed GL extensions to read a given pixel format.
|
|
|
|
On little-endian, we can enable pixel formats which don't use
gl_type = GL_UNSIGNED_BYTE. See [1].
[1]: https://afrantzis.com/pixel-format-guide/
|
|
|
|
This is now unconditionally set to WLR_OUTPUT_STATE_BUFFER_SCANOUT.
|
|
This enum will get dropped in the next commit.
|
|
No backend uses these anymore.
|
|
We no longer require wlr_output_impl.{attach,rollback}_render to
be populated.
|
|
These are bools but should be pointers.
|
|
Unless we're dealing with a multi-GPU setup and the backend being
initialized is secondary, we don't need a renderer nor an allocator.
Stop initializing these.
|
|
We can now just rely on the common code for this.
|
|
|
|
We only accept SCANOUT, the buffer type should never be set to RENDER.
|
|
We can't nuke it completely, we still need it for multi-GPU.
|
|
Historically we haven't allowed direct scan-out for legacy KMS,
because legacy misses the functionality to make sure a buffer can
be scanned out. However with renderer v6 the backend can't figure
out anymore whether the buffer comes from its internal swap-chain,
because the backend doesn't have an internal swap-chain.
The legacy KMS API guarantees that the driver won't reject a buffer
as long as it's been allocated with the same parameters as the
previous one. Let's check this in legacy_crtc_test.
|
|
Sometimes we allocate a buffer with modifiers but then fail to
perform a modeset with it. This can happen on Intel because of
bandwidth limitations. To mitigate this issue, it's possible to
re-allocate the buffer with modifiers.
Add the logic to do so in wlr_output.
|
|
Some backends need a buffer in order to be able to perform a
modeset.
|