ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
Spawns_Carpeting has quit [Ping timeout: 480 seconds]
Spawns_Carpeting has joined #wayland
mahkoh has quit [Ping timeout: 480 seconds]
mahkoh has joined #wayland
Brainium has joined #wayland
Brainium has quit []
amadaluzia has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
garnacho has quit [Ping timeout: 480 seconds]
Spawns_Carpeting has quit []
Spawns_Carpeting has joined #wayland
AJ_Z0 has quit [Read error: Connection reset by peer]
AJ_Z0 has joined #wayland
Drakulix has quit [Ping timeout: 480 seconds]
Drakulix has joined #wayland
amadaluzia has quit []
nerdopolis has quit [Ping timeout: 480 seconds]
glennk has joined #wayland
garnacho has joined #wayland
<dery>
Update: I'm still investigating the weird "ECONNRESET" issue when sending wl_display.error and close(2)-ing with my custom server code
<dery>
it looks like the issue comes from the fact that I so a sendmsg(2) and close(2) right away
<dery>
I played with ioctls and it looks like the send buffer is still full by the time I close, triggering an ECONNRESET as the client is still reading said buffer
<dery>
If wayland-client and wayland-server really do not have any safeguards for this, I'm starting to believe that this might be the smallest race condition ever
<dery>
like, from my extremely coarse readings it takes as little as 3-4 µsecs to flush said buffers between returning from a function calling sendmsg to calling close for the buffer to be flushed
<dery>
we're talking about, like, less than 1k of data, FTR
mahkoh has quit [Remote host closed the connection]
mahkoh has joined #wayland
kts has joined #wayland
mahkoh has quit [Ping timeout: 480 seconds]
mahkoh has joined #wayland
kts has quit [Quit: Leaving]
__0x1eaf has quit [Ping timeout: 480 seconds]
mahkoh has quit [Remote host closed the connection]
mahkoh has joined #wayland
kts has joined #wayland
stellaartois has quit [Remote host closed the connection]
stellaartois has joined #wayland
FreeFull has quit []
<dery>
FTR I also applied the patch that mahkoh sent and it does not make a difference in this case, the issue is really that I somehow manage to close the socket so fast that the client errors out while reading the actual error message itself
<dery>
Supposing that my diagnosis is correct, I chose to opt for a middleground: I poll and wait for the socket to hang up (POLLHUP) or an arbitrary timeout (250ms), whichever happens first.
<dery>
I think that the only proper fix would be to either handle the sockets "asynchronously", that is give them give them a non-blocking timeout of 10 seconds before force closing, or have some sort of protocol aknowledge
stellaartois has quit [Remote host closed the connection]
<mahkoh>
FYI I have a 5 second timeout in my compositor before I close the read end of the connectuon
<dery>
blocking timeout?
<dery>
I'm too lazy to make it asynchronous, that's why I chose sub-second timeouts
<dery>
I mean it's an error case, hopefully it won't get called much :P
<dery>
anyways that's great news, I think I'm on the right track then :D
<mahkoh>
There is nothing blocking in my compositor.
<dery>
yea that's good
<mahkoh>
Getting errors to clients is essential for debugging clients. It's not something to be treated as rare.
<dery>
fair
<dery>
I mean I'd be tempted to have a 10s timeout too but since it's blocking that'd be really unpleasant
<dery>
and it's an application-specific proxy so hopefully that'll never happen
<dery>
I'll probably improve it later :D
FreeFull has joined #wayland
<dery>
In the meantime I'm bumping it to 1sec, you're right that debugging is important
<selckin>
think the proper way is using shutdown and close after that finishes, but been ages since i did any socket programming
<dery>
I already tried, unfortunately it doesn't block on write
<dery>
It _should_ with SO_LINGER but that doesn't seem to happen either :/
<dery>
basically all literature concerns the AF_INET family which works pretty differently from AF_LOCAL
<dery>
it's so obscure to the point that googling '"AF_LOCAL" "flush"' sent me to a copy of the wayland source-code lmao
<selckin>
think read & wait for client to close the socket after shutdown, and if they don't you do it with a timeout, but maybe thats also not for af_local
<dery>
but apparently the error is compositor->client, not the opposite
<dery>
so reading the incoming buffer only buys me time
<dery>
a sleep is equivalent
<dery>
that's why I'm skipping the read, it doesn't matter apparently
mahkoh has quit [Ping timeout: 480 seconds]
mahkoh has joined #wayland
kts has quit [Quit: Leaving]
fmuellner has joined #wayland
mahkoh has quit [Read error: No route to host]
mahkoh has joined #wayland
__0x1eaf has joined #wayland
sally_ has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
narodnik2 has quit []
narodnik2 has joined #wayland
coldfeet has joined #wayland
cmichael has joined #wayland
dcz_ has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
Moprius has joined #wayland
MrCooper_ is now known as MrCooper
<MrCooper>
UndeadLeech: even for plane = 0?
<UndeadLeech>
No rendering in general works, just no direct scanout.
<UndeadLeech>
So primary plane should be all good.
<UndeadLeech>
It's odd because I swear it worked in 2023, but I went to the latest available kernel for the device in 2024 and it didn't fix it. So I'm a bit confused about that part.
<MrCooper>
if it works for plane 0, does the format really have more planes?
<MrCooper>
format/modifier
<MrCooper>
to be clear, I mean the plane argument of gbm_bo_get_handle_for_plane
<UndeadLeech>
Yeah the overlay planes are definitely available and appropriate. Most compositors check for that first anyway, I know mine does and I'd assume so does weston. The error happens while trying to create the framebuffer.
<UndeadLeech>
Smithay (the library I use) doesn't check for the return value so it fails at the addfb2 call, weston seems to check for -1 so it just aborts after the handle_for_plane call.
nerdopolis has joined #wayland
<MrCooper>
the plane in this GBM API has nothing to do with KMS planes
<MrCooper>
are you trying to pass KMS plane IDs to it?
<UndeadLeech>
No I'm doing everything right. It works just fine on other devices and I haven't found a compositor where direct scanout works on this device.
<UndeadLeech>
Unless you're suggesting both me and weston accidentally wrote the same bug.
<MrCooper>
you still haven't clearly answered whether or not the issue happens when passing 0 for the second parameter of gbm_bo_get_handle_for_plane
<MrCooper>
if it does, it sounds like a Mesa issue
<UndeadLeech>
Just checked the lib's code and -1 is with 0 as plane.
<UndeadLeech>
If I'm reading this right, I think plane count is 1 and plane 0 returns -1.
<UndeadLeech>
Haven't verified it, but like 80% sure that's the way this should work.
<UndeadLeech>
MrCooper: Why are you saying Mesa, rather than the kernel for example?
<UndeadLeech>
This is using the lima driver if that helps.
coldfeet has quit [Quit: Lost terminal]
zamundaaa[m] has joined #wayland
<zamundaaa[m]>
gbm is implemented by Mesa, not the kernel
<zamundaaa[m]>
It sounds like you're a bit confused between buffer planes and kms planes
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
cmichael has quit [Quit: Leaving]
kts has joined #wayland
cmeissl[m] has joined #wayland
<cmeissl[m]>
The code in smithay should be pretty similar to what weston does. UndeadLeech is talking about dmabuf provided through the dmabuf protocol. No kms planes are passed to the functions. The dmabuf is successfully imported into gbm. What seems to fail is creating the fb because gbm_bo_handle_for_plane for the imported bo returns -1.
<cmeissl[m]>
The code in smithay should be pretty similar to what weston does. UndeadLeech is talking about dmabuf provided through the dmabuf protocol. No kms planes are passed to the functions. The dmabuf is successfully imported into gbm. What seems to fail is creating the fb because gbm_bo_handle_for_plane for the imported bo returns -1.
<pooyam>
I guess Wayland does not support a "shared system clipboard" natively. What add-on feature do programs use for this? Like if a program saves a string to clipboard, how do other apps become aware of it?
<FreeFull>
But from my experience, with most compositors, the clipboard ends up working very close to how it works on X11
<pooyam>
FreeFull, thanks
<FreeFull>
At least, from an user's perspective
dcz_ has quit [Quit: Konversation terminated!]
<danieldg>
yes, if you're not snooping on the clipboard, it has the same basic features
Brainium has joined #wayland
__0x1eaf has quit [Ping timeout: 480 seconds]
___nick___ has quit [Remote host closed the connection]
Brainium has quit [Read error: Connection reset by peer]
Brainium has joined #wayland
Brainium has quit [Read error: Connection reset by peer]
Brainium has joined #wayland
Brainium has quit [Read error: No route to host]
Brainium has joined #wayland
Brainium has quit [Read error: Connection reset by peer]
Brainium has joined #wayland
Brainium has quit [Read error: Connection reset by peer]
Brainium has joined #wayland
AJ_Z0 has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
[@_oftc_FreeFull:matrix.org](https://matrix.to/#/@_oftc_FreeFull:matrix.org) ext data control is for clipboard managers. The normal clipboard is in the core protocol - wl_data_offer and wl_data_source
<danieldg>
there's also the primary selection protocol
Brainium has quit [Read error: No route to host]
Brainium has joined #wayland
IMTheNachoMan has quit [Quit: Connection closed for inactivity]