ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
alatiera has quit [Quit: Connection closed for inactivity]
mclasen has quit []
mclasen has joined #wayland
mvlad has quit [Remote host closed the connection]
mclasen has quit [Remote host closed the connection]
mclasen_ has joined #wayland
mclasen_ has quit [Read error: Connection reset by peer]
glennk has quit [Ping timeout: 480 seconds]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #wayland
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
checkfoc_us has quit []
checkfoc_us has joined #wayland
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
karmavil[m] has quit [Quit: Client limit exceeded: 20000]
Brainium has quit [Quit: Konversation terminated!]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
garnacho has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
privacy has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
diamondburned[m] is now known as Diamonditshe[m]
jkl__ has joined #wayland
jkl has quit [Ping timeout: 480 seconds]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
ShapeShifter499 has joined #wayland
Leopold_ has joined #wayland
Company has quit [Quit: Leaving]
Leopold_ has quit [Remote host closed the connection]
eroc1990 has quit [Read error: Connection reset by peer]
eroc1990 has joined #wayland
<kennylevinsen>
from drm_fourcc.h: "Some Broadcom modifiers take parameters, for example the number of vertical lines in the image. Rseerve the lower 32 bits for modifier type, and the next 24 bits for parameters." - but why would you do that :(
JayBeeFOSS has quit [Ping timeout: 480 seconds]
<emersion>
cc sima daniels ^
JayBeeFOSS has joined #wayland
kts has joined #wayland
mclasen has joined #wayland
<pq>
did that stuff really make it to kernel upstream?
paulk has quit [Quit: WeeChat 3.0]
mclasen has quit [Remote host closed the connection]
<pq>
I'm guessing that kernel reviewers never realized that drm_fourcc.h itself never uses fourcc_mod_broadcom_mod() macro.
kts has quit [Quit: Leaving]
<pq>
or fourcc_mod_broadcom_param()
<sima>
ok this is hilariously broken and should never have landed
<emersion>
phew
<sima>
so from a very quick look at vc4 kernel code it does look fixable
<sima>
as in, if the param is 0 we use the pitch passed in as metadata and not this funny modifier param business
<sima>
ideally Someone(tm) would check if we could also rely on the passed-in pitch for when the parameter is set
<pq>
the doc for these is confusing, but I'm guessing that "vertical lines" is actually the width of "columns", not image width
<sima>
but yeah good job on tossing 24bits into the dustbin lolz
<sima>
pq, yeah it's just what addfb calls pitch
<sima>
or well, should have been
<pq>
is it? it does not sound like pitch to me
<sima>
oh I got confused I guess
<sima>
hm
<sima>
it's just stored in a register called pitch0 :-)
<pq>
sounds like there are 4 different valid values for the parameter: 32, 64, 128, and 256
kts has joined #wayland
<pq>
so it shouldn't be any problem to enumerate all accepted modifiers verbatim
<sima>
hm yeah maybe not sure ...
<sima>
yeah just enumerate them
<sima>
and replace the comments above the macros with a "absolutely do not use this in any new code at all"
<pq>
maybe the kernel patch makes sense, apart from the two unused macros, while the wlroots patch is bogus?
<sima>
oh normalizing modifiers is complete bogus
<sima>
I'm just looking for the best way to fix this mess without breaking anything
<pq>
first patch the kernel to delete the unused macros, and anyone who screams about that is getting modifiers totally wrong in userspace :-)
<sima>
pq, it might break the userspace drivers if we delete those
<emersion>
ty sima
<sima>
but yeah ideally we ditch them everywhere and replace them with hardcoded enumerations
<pq>
sima, how could they be right in using those macros?
<sima>
pq, not right, but also it'd be a build-time regression
<pq>
"oh, sorry, here's the revert" :trollface:
<sima>
whether the code is right depends a bit on where they're used
<sima>
if it's just the modifier for an allocated buffer, then it would work if we switch to "only these explicitly documented combos are correct" world
<pq>
nope, I don't understand what the bcm modifier doc says.
<sima>
if the userspace also uses the "canonicalized" values for supported format enumeration purposes, then the userspace code is broken ofc
selckin1 has quit []
<sima>
pq, just looking at the macros the DRM_FORMAT_MOD_*_HEIGHT() that take a parameter seem good
<sima>
the ones without the parameter are the bogus canonicalized stuff
<pq>
now I'm thinking the modifier HEIGHT is related to image height
<sima>
pq, yeah reading the doc the column height seems to be the height of the buffer, rounded up appropriately
<sima>
pq, yeah
<pq>
just like stride is related to image width
<sima>
so the metadata parameter would need to be the alignment value used
qaqland has joined #wayland
<sima>
or whatever is used to decide how that rounding up works
mclasen has joined #wayland
paulk has joined #wayland
<sima>
so yeah I guess the existing modifiers are for the dust bin, and we need new ones
<pq>
is that SAND format even usable at all? Aren't all APIs everywhere missing "column pitch" from the width,height,stride tuple?
<pq>
therefore the funny idea of using a format modifier to carry more free parameters
ity has joined #wayland
<sima>
lol c91acda3a380b in the kernel broke this
<sima>
given no one screamed, we might just be able to toss it outright
<sima>
this enforces proper "did you list that specific modifier in your plane's modifier list" semantics
<sima>
which vc4 very much doesn't
<pq>
\o/
<sima>
emersion, good news ^^
<sima>
well only landed in 6.5 but still
<pq>
but maybe no-one uses these for DRM FBs?
<sima>
maybe
<sima>
vc4 has code to support it at least
<sima>
but yeah quick summary: a) this is totally broken b) we plugged this specific leak at least in kms in 6.5
mclasen_ has joined #wayland
<sima>
pq, emersion also I'm thinking that even if someone reports a regression, if we cover the usual values for 720/1080/4k (both i & p) we should be good
mclasen has quit [Ping timeout: 480 seconds]
<sima>
to cover regressions, if they pop up
<sima>
since video
<sima>
so not super worried about this anymore, but it's still bad
<any1>
The latest vendor patched kernel for rpi is 6.1
<Company>
so, with compositors doing direct scanout of non-fullscreen windows with this libliftoff work landing everywhere - is it relevant if the application buffers are opaque? Or is it fine to use transparency on overlay planes?
<mripard_>
sima: thanks
<emersion>
it's always nice to know when a buffer is opaque
<pq>
Company, if you can provide guarantees of opaqueness via pixel format or wl_surface opaque region, it does increase the probability of being able use a KMS plane for it.
<Company>
most application code doesn't bother because it just wasn't an issue
<pq>
but it's not a strict requirement
<Company>
and I'm wondering if I should file bugs / add comments for them every time
<Company>
they just create an AR24 buffer because why not?
<pq>
I think it would be good to teach people to think about opaqueness.
<pq>
even if the compositor does not use KMS planes, knowing that a surface is opaque will allow reducing the GPU work.
<Company>
yeah, the whole opaque region story
<pq>
isn't that reason enough?
<Company>
apparently not or everyone would be doing it already...
<pq>
maybe they didn't know about even that
Leopold_ has joined #wayland
<Company>
actually, most of those buffers ended up in GTK and where composited there, that only gets relevant with the recent offloading work
<pq>
if GTK knew they were opaque, also GTK could probably save in GPU work?
<Company>
the 2 cases where I recently figured out they use RGBA is the webpage dmabufs used by Epiphany and the videos GStreamer sends to GTK from its GL pipeline
<Company>
yes, GTK could probably optimize things, too
<Company>
but it doesn't - even the opaque region is a custom codepath still when we could deduce it from the render tree
<Company>
I've wondered how much we could gain there - because there's often cases where backgrounds get overdrawn multiple times
<Company>
like text editors draw the window background first and then draw the text area's background on top
<pq>
I suppose that depends on the number of polygons painted vs. their area.
<Company>
but of course, the text area oftenends up with rounded corners and then...
<Company>
it's 2 huge triangles (or maybe 2 huge and 16 smaller ones if it 9-slices because of rounded corners)
<Company>
but the problem there is the number of pixels touched
<pq>
the area, yes
<Company>
but then, text editors usually aren't limited by draw performance
kts has quit [Ping timeout: 480 seconds]
kts has joined #wayland
<Company>
but I think it could help to do those optimizations to achieve smoother scrolling on lower-powered hardware, like rpi and such
<Company>
that also tells you how important it is I guess
<emersion>
could also help battery-powered devices
<pq>
battery life, yes
<Company>
yeah, there's probably a lot that could be done there, but it's both hard to measure and there's bigger fish there
<Company>
nobody is gonna praise longer battery life when they switch from vscode or whatever to vim in a terminal as their editor
<Company>
and if they did, it'd be because they don't run all the background tasks anymore that are compiling everything on every keypress
<sima>
Company, yeah reducing wasted memory bandwidth for rendering is a really hard one that needs all the details right
<sima>
you need incremental drawing with buffer_age and damage rectangles everywhere
<sima>
that's already a big one depending upon hw
<sima>
then app needs to draw it all in one go (one render pass in vulkan, gl with a good driver no glsync or readback or anything like that) or you hurt tiled renders real bad
<sima>
then the entire opaqueness thing
<sima>
and it's all end-to-end, if anything in the app -> renderer -> protocol -> compositor -> display driver/hw screws up it's over
ity has joined #wayland
dri-logg1r has joined #wayland
dri-logger has quit [Ping timeout: 480 seconds]
privacy has joined #wayland
<Company>
yeah
<Company>
but the cases that are worth optimizing are always the ones where those features don't work
<Company>
like scrolling in a text editor turns the damaged region into the full window and all your damage rects don't help you
kts has quit [Ping timeout: 480 seconds]
alatiera has joined #wayland
nerdopolis has joined #wayland
ity has quit [Quit: WeeChat 4.2.1]
dogukan has joined #wayland
ity has joined #wayland
qaqland has quit [Ping timeout: 480 seconds]
dogukan has quit [Quit: Konversation terminated!]
nerdopolis has quit [Ping timeout: 480 seconds]
ity has quit [Quit: WeeChat 4.2.1]
Guest790 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest1098
Guest1098 has quit [Remote host closed the connection]
cool110_ has joined #wayland
cool110_ is now known as Guest1100
mclasen has joined #wayland
Guest1100 has quit [Remote host closed the connection]
ity has joined #wayland
cool110- has joined #wayland
cool110- has quit [Remote host closed the connection]
cool110- has joined #wayland
<MrCooper>
pq: re https://gitlab.freedesktop.org/wayland/weston/-/issues/871 it's doubtful that compositing would make a big difference with Xorg; in particular, it wouldn't directly affect how XVideo handles colour space conversion and scaling
ity has quit [Remote host closed the connection]
ity has joined #wayland
<MrCooper>
Company: FWIW, optimizing all those things is particularly important for software rendering, some of the lower-hanging fruit for that
<Company>
I am well aware of the theory
<Company>
but I'm also aware that software rendering doesn't even support buffer-age yet
<MrCooper>
hmm, not even the native Wayland platform?
<Company>
all of that is a case of "only 24h in a day" - other stuff is more important, but in theory it'd be cool to have
<MrCooper>
huh yeah, only GBM platform seems to support buffer age with llvmpipe
ity has quit [Quit: WeeChat 4.2.1]
<zamundaaa[m]>
Damage tracking might not happen on the client side, but opaque culling is still done on the compositor side
<MrCooper>
I suspect it's some kind of silly oversight with the Wayland platform
<Company>
lavapipe does damage tracking iirc
<swick[m]>
Company: when you can break API you really should switch any kind of importing buffers to assume the imported image is opaque by default
<emersion>
that sounds pretty error prone…
<Company>
swick[m]: people need to specify the buffer format - and they'll always pick RGBA
<Company>
because RGBA is just less work
<Company>
see also: cairo_surface_create()
<swick[m]>
sure, but then just have another HAS_ALPHA flag
<swick[m]>
and internally switch it to an opaque variant if it's not set
<swick[m]>
whoever actually needs alpha will notice and turn it on
<Company>
everyone will turn it on
<Company>
because otherwise sometimes stuff is black
Leopold_ has quit [Remote host closed the connection]
<pq>
MrCooper, compositing does not forbid Xv?
<Company>
people will treat it as _set_not_buffy (TRUE)
<Company>
*buggy
<MrCooper>
pq: nope
<pq>
MrCooper, so there is code to route Xv adapters through a compositing manager?
<MrCooper>
of course not :)
<pq>
MrCooper, then how does it work? Breaks into pieces?
<swick[m]>
Company: dunno man, I think a lot of people just choose RGBA without thinking and if you make them think they will more likely do the right thing
<MrCooper>
if it's an overlay, the compositing will only affect the colour key, not the video content itself; otherwise it's just a textured blit
<swick[m]>
but if they always get alpha by accident they will never notice and never have to think
<Company>
yeah, I know
<Company>
but your fix doesn't work either
<Company>
because then they will think for 5s until they find the has_alpha toggle, set it, and continue not thinking about it
<pq>
MrCooper, sounds like it'll break into pieces then, if it bypasses the compositing manager on its way to screen.
<Company>
and all that toggle will be known for is the stack overflow posts where people go "oh, it's buggy if you don't set it"
<swick[m]>
if it's buggy, they need alpha...
<MrCooper>
pq: an overlay will break if the window isn't displayed at its canonical position, a texture XVideo adapter works fine with compositing
ity has joined #wayland
<swick[m]>
sure, maybe there are cases where only some data contains actual alpha and a lot of other cases don't, but this still seems like a good improvement overall
<swick[m]>
because you definitely get all those cases where alpha is not required at all
<Company>
sure, but the way to go there is education
<swick[m]>
no offense, but you do that by creating APIs that make it hard to do the wrong thing
<Company>
sure, I'll wait for that API to appear
<Company>
because for opaqueness the problem is that you need to do deliberate work to check if your stuff is opaque, so the opaque-by-default approach doesn't work
<swick[m]>
you're basically saying a better API is not better because it can still be misused
<swick[m]>
and that's really weird to me
<pq>
MrCooper, interesting. I only have hazy recollections from many years ago, that the coming of compositing managers somehow made Xv break.
<Company>
I'm saying it's not a better API
ity has quit [Remote host closed the connection]
ity has joined #wayland
<swick[m]>
it's obvious that it's better. if alpha is not required generally in a call to import a buffer, then the new API gives you opaqueness even if the user mindlessly chooses RGBA
<MrCooper>
pq: yes, at the time most Xv adaptors were overlay based, and there were issue with compositing; these days Xorg drivers mostly expose only textured adaptors (as does Xwayland) for that reason
<Company>
no, it's obviously worse
<pq>
MrCooper, aha, thanks.
<Company>
because it causes broken results in cases where an alpha-by-default API wouldn't
<swick[m]>
it breaks by giving and obvious error that can be fixed
<Company>
yes, but it's giving you an error
<swick[m]>
yes, and that's a good thing
<Company>
only if you can guarantee that it is caught during testing
<Company>
and doesn't end up in users' hands
bnason has joined #wayland
<Company>
it's basically why HTML won and XHTML lost
<kennylevinsen>
no XHTML lost because it added no value
<kennylevinsen>
strictly XML does not function any different from the non-XML form - it's just aesthetic for the person looking at said markup
<Company>
it's also much easier to parse spec-compliant XML than it is to write HTML parsers
<kennylevinsen>
(HTML's deviations from XHTML are now strictly defined, including auto-opening and auto-ending tags)
<Company>
you can almost use a regexp!
<kennylevinsen>
Quite the contrary, xml namespaces! dtd you need to download during parsing! :)
<kennylevinsen>
html just has a handful of rules like "<body> open implicitly ends <head>, body-only tags implicitly open <body>"
<Company>
xml wants everything to be quoted, too and html can do fine without that
<kennylevinsen>
that doesn't make it harder to parse, it's just a small syntax difference
<Company>
I didn't actually check if that's true - it might very well be harder to parse
<Company>
mostly because I've watched lots of fun talks on how json parsers work
<kennylevinsen>
yeah, fully spec compliant JSON with all the bells and whistles is... quirky
<Company>
anyway, the problem with opaqueness is that people will almost always go with transparent and then think they'll "fix it later"
<Company>
so I think the cairo approach of letting people explicitly say that the want transparency is the best one: It makes them consider if they should care about it, but if they don't want to, they don't end up with brokenness
<Company>
and that's basically the approach with Wayland/dmabuf formats, too - you have to pick one and it makes you consider which one
<ManMower>
we should scan client buffers to make sure they actually use alpha, and disconnect them for using opaque ARGB buffers.
<Company>
kill all the video players!
<ManMower>
ooi, do they at least set an opaque region?
<Company>
I don't even know what video players do
<kennylevinsen>
well, letting people explicitly say that they want transparency vs. defaulting to be opaque kind of sounds like the same thing... :)
<Company>
*Explicitly say what format they want
rasterman has joined #wayland
<Company>
so you need to be explict about opaque, too
<YaLTeR[m]>
ManMower: then game devs will come knocking who set format to xrgb then use alpha channel as internal data storage
cool110- has quit [Remote host closed the connection]
<Company>
like zwp_linux_buffer_params_v1::create() could come without a format and default to XRGB unless you called like zwp_linux_buffer_params_v1::set_format() before
<ManMower>
YaLTeR[m]: well, 2 things. one is that I was joking, and the other is that I would never suggest scanning an XRGB buffer, because that's a completely legit use case.
cool110 has joined #wayland
cool110 is now known as Guest1103
<Company>
you're meant to scan ARGB buffers anyway
<kennylevinsen>
Those precious 8MB of unused alpha-channel in a 4k buffer...
ity has quit [Quit: WeeChat 4.2.1]
<Company>
XRGB is known to be opaque already
<kennylevinsen>
we're not meant to *scan* ARGB buffers, we're just meant to composite them with blending
<kennylevinsen>
or offload them if we can
<Company>
kennylevinsen: it's a fun question if your PNG loader should load into RGB vs XRGB buffers
<kennylevinsen>
Although I have had a long-standing project idea of a test compositor that actively scanned submitted buffers to report correctness of e.g. damage and opaqueness
<Company>
with those 20k images, you can end up with almost 100MB of junk bytes
<YaLTeR[m]>
Company: I think gpus don't like 24-bit formats
<Company>
YaLTeR[m]: yeah - but GPUs also don't like OOMing
ity has joined #wayland
<Company>
and I think RGB is readable everywhere
cool110_ has joined #wayland
cool110_ is now known as Guest1105
<Company>
also, mpv uses XR30 to play my video, so my GStreamer GTK plugin dissing does not apply to other video players
Guest1103 has quit [Ping timeout: 480 seconds]
<Company>
afaik GStreamer doesn't have an XRGB format though, so I might be able to diss it in general, not just the plugin
<Company>
but YaLTeR[m] would know that better than me
<YaLTeR[m]>
when I tried alpha formats from the caps in gst paintable sink, everything broke
<YaLTeR[m]>
although allegedly it's supposed to work
<Company>
there's a difference between actually having alpha and making sure to not advertise alpha
Leopold_ has joined #wayland
<Company>
and I think GStreamer has no way to have 32bit RGBX buffers
<Company>
well, unless you use the new dmabuf stuff, where you can just use DRM_FORMAT_XR24
<Company>
but I was thinking memory RGB buffers
<daniels>
BGRx and RGBx have always been supported as raw video formats in GSt
<Company>
good to know - maybe people just forgot to add them to the plugins I looked at
garnacho has joined #wayland
Guest1105 has quit [Remote host closed the connection]
cool110- has joined #wayland
ity has quit [Quit: WeeChat 4.2.1]
zxrom has joined #wayland
kts has joined #wayland
Leopold_ has quit [Remote host closed the connection]
<MrCooper>
Company: FWIW, non-ancient AMD GPUs don't actually support 3-byte RGB formats, GL_RGB uses 4 bytes per pixel
ity has joined #wayland
<Company>
so it's all faked in the driver again
tzimmermann has quit [Quit: Leaving]
leon-anavi has quit [Remote host closed the connection]
garnacho has quit [Ping timeout: 480 seconds]
mclasen has quit [Ping timeout: 480 seconds]
narodnik has joined #wayland
andreasbackx has joined #wayland
___nick___ has joined #wayland
kts has quit [Quit: Leaving]
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
flom84 has joined #wayland
flom84 has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
Leopold_ has joined #wayland
vincejv_ has joined #wayland
selckin has joined #wayland
vincejv has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
vincejv_ has quit []
vincejv has joined #wayland
glennk has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
mort_ has joined #wayland
Leopold_ has joined #wayland
andreasbackx has quit [Remote host closed the connection]
Leopold_ has quit [Remote host closed the connection]
garnacho has joined #wayland
MajorBiscuit has joined #wayland
MajorBiscuit has quit []
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
mclasen has joined #wayland
Leopold_ has joined #wayland
mclasen has quit []
mclasen has joined #wayland
rv1sr has quit []
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
privacy has quit [Remote host closed the connection]
codecolla has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
Gmail seems to be swallowing some notification emails from fdo gitlab lately... If I don't respond somewhere in time, please feel free to ping me about it here or anywhere else that isn't gitlab
<zamundaaa[m]>
drakulix: all your responses to my dmabuf MR are missing from my emails for example
<zamundaaa[m]>
But the ones from Simon seem to be all there
<drakulix[m]>
zamundaaa[m]: I have had the same problem in reverse. Your answers are missing, but Simons come through.
Leopold_ has quit [Remote host closed the connection]
<zamundaaa[m]>
Guess we have to check wayland-protocols threads manually for now :/
___nick___ has quit [Ping timeout: 480 seconds]
<emersion>
or find a better email provider
sima has quit [Ping timeout: 480 seconds]
<drakulix[m]>
I self-host the address in question and my logs don't show any rejected mails for today. So this isn't necessarily looking like a problem on our side.
<emersion>
hm
cool110- has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest1133
Guest1133 has quit [Remote host closed the connection]
cool110_ has joined #wayland
cool110_ is now known as Guest1135
Leopold_ has joined #wayland
<Company>
zamundaaa[m]: I've had gmail mark random gitlab.fdo mails as spam
Leopold_ has quit [Remote host closed the connection]
<zamundaaa[m]>
hmm, nothing in spam
<zamundaaa[m]>
maybe it's a Gitlab issue
vaxry_ has joined #wayland
Leopold_ has joined #wayland
vaxry has quit [Remote host closed the connection]
vaxry_ has quit [Read error: Connection reset by peer]
<emersion>
i tweaked a few knobs, hopefully should be a bit better now
mvlad has quit [Remote host closed the connection]
qaqland has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #wayland
vaxry has joined #wayland
Leopold has quit [Remote host closed the connection]
vaxry has quit [Read error: Connection reset by peer]
Leopold_ has joined #wayland
privacy has joined #wayland
vaxry has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
d42 has quit []
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]