1716108 - sway complains `Client bug: submitted a buffer whose size (1x1) is not divisible by scale` with wayland compositor enabled

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[ojab]

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:89.0) Gecko/20100101 Firefox/89.0

Steps to reproduce:

Started firefox nightly on sway/wlroots (latest master) with wayland compositor enabled

Actual results:

Firefox window are almost immediately stops updating, sway log shows a bunch of

00:10:20.650 [DEBUG] [wlr] [types/wlr_surface.c:189] Client bug: submitted a buffer whose size (1x1) is not divisible by scale (2)
00:10:20.675 [DEBUG] [wlr] [types/wlr_surface.c:189] Client bug: submitted a buffer whose size (1x1) is not divisible by scale (2)
00:10:20.683 [DEBUG] [wlr] [types/wlr_surface.c:189] Client bug: submitted a buffer whose size (1x1) is not divisible by scale (2)
00:10:20.700 [DEBUG] [wlr] [types/wlr_surface.c:189] Client bug: submitted a buffer whose size (1x1) is not divisible by scale (2)
00:10:20.716 [DEBUG] [wlr] [types/wlr_surface.c:189] Client bug: submitted a buffer whose size (1x1) is not divisible by scale (2)
00:10:20.733 [DEBUG] [wlr] [types/wlr_surface.c:189] Client bug: submitted a buffer whose size (1x1) is not divisible by scale (2)
00:10:20.749 [DEBUG] [wlr] [types/wlr_surface.c:189] Client bug: submitted a buffer whose size (1x1) is not divisible by scale (2)
00:10:20.760 [DEBUG] [wlr] [types/wlr_surface.c:189] Client bug: submitted a buffer whose size (1x1) is not divisible by scale (2)
00:10:20.761 [DEBUG] [wlr] [types/wlr_surface.c:189] Client bug: submitted a buffer whose size (1x1) is not divisible by scale (2)
00:10:20.766 [DEBUG] [wlr] [types/wlr_surface.c:189] Client bug: submitted a buffer whose size (1x1) is not divisible by scale (2)
00:10:20.783 [DEBUG] [wlr] [types/wlr_surface.c:189] Client bug: submitted a buffer whose size (1x1) is not divisible by scale (2)

Expected results:

No client errors in sway log.

Comment 1

[ojab]

I have fractional 1.5 scaling enabled in sway, maybe it matters.

Also firefox window updates stop almost immediately after start and WAYLAND_DEBUG shows

[3464559.385]  -> [e-mail](new id wl_callback@305)
[3464559.427] [e-mail]_id(305)
[3464559.436] [e-mail](3311)
[3464559.441]  -> [e-mail](new id wl_callback@305)
[3464559.475] [e-mail]_id(305)
[3464559.484] [e-mail](3311)
[3464559.489]  -> [e-mail](new id wl_callback@305)
[3464559.525] [e-mail]_id(305)
[3464559.534] [e-mail](3311)
[3464559.540]  -> [e-mail](new id wl_callback@305)
[3464559.577] [e-mail]_id(305)
[3464559.591] [e-mail](3311)
[3464559.596]  -> [e-mail](new id wl_callback@305)
[3464559.638] [e-mail]_id(305)
[3464559.648] [e-mail](3311)
[3464559.653]  -> [e-mail](new id wl_callback@305)
[3464559.688] [e-mail]_id(305)
[3464559.697] [e-mail](3311)

with [e-mail] number occasionally changing, but I guess it could be caused by this Client bug, so will create another ticket when it's fixed.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 3

[Robert Mader [:rmader]]

Thanks for testing. IIUC correctly that message is just harmless debug output - the freeze in turn is a known bug is Sway (most likely), see bug 1699754 / https://github.com/swaywm/sway/issues/6322

Comment 4

[Robert Mader [:rmader]]

Reading the spec again just made me realize that the warning is actually a protocol error:

The new size of the surface is calculated based on the buffer size transformed by the inverse buffer_transform and the inverse buffer_scale. This means that at commit time the supplied buffer size must be an integer multiple of the buffer_scale. If that's not the case, an invalid_size error is sent.

So we're violating the spec here and compositors should actually disconnect us with a protocol error - and may start doing so at any time.

Comment 5

[Robert Mader [:rmader]]

Attachment: Bug 1716108 - Do not set buffer scale when using compositor integration. r=stransky

Because NativeLayerWayland uses an invisible 1x1 pixel buffer for
moz_container_wayland which only serves as parent surface, not
holding any content.

If we set a buffer scale >1 to it, this would violate the spec:

The new size of the surface is calculated based on the buffer
size transformed by the inverse buffer_transform and the inverse
buffer_scale. This means that at commit time the supplied buffer
size must be an integer multiple of the buffer_scale. If that's
not the case, an invalid_size error is sent.

Currently compositors appear to not strictly follow this, only
printing warnings. This could change at any time though.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ac7313ea7af8
Do not set buffer scale when using compositor integration. r=stransky

Comment 7

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/ac7313ea7af8