ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
c7s has quit [Ping timeout: 480 seconds]
pnowack has quit [Quit: pnowack]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
boistordu_old has joined #wayland
boistordu_ex has quit [Ping timeout: 480 seconds]
zebrag has quit [Ping timeout: 480 seconds]
m0nkeyC has quit [Remote host closed the connection]
dcz_ has joined #wayland
dcz has joined #wayland
dcz_ has quit [Ping timeout: 480 seconds]
danvet has joined #wayland
hardening has joined #wayland
shankaru has left #wayland [#wayland]
maxzor has joined #wayland
AJ_Z0 has quit [Ping timeout: 480 seconds]
AJ_Z0 has joined #wayland
<dottedmag>
daniels: Yes, but when exactly? Client is free to send every byte via separate `sendmsg(2)` call, and attach a fd to any of these messages, right?
jgrulich has joined #wayland
arin0v has joined #wayland
rasterman has joined #wayland
tzimmermann has joined #wayland
pnowack has joined #wayland
maxzor_ has joined #wayland
rgallaispou has joined #wayland
immibis has joined #wayland
immibis has quit [Remote host closed the connection]
rgallaispou has quit [Read error: Connection reset by peer]
<pq>
zamundaaa, please assume that disabling an overlay never requires a modeset, and file bugs against any DRM driver where that is false. Tell them I sent you. :-)
<emersion>
pq, i know one driver which might fail disabling an overlay
<pq>
zamundaaa, anyway, you can't even test if disabling an overlay needs something without first making that overlay active for real. Which you probably don't want to do.
<emersion>
and hw limitations make it so this can't be worked around in the driver
<emersion>
on amdgpu, the cursor plane can only be enabled if it matches the underlying plane's scaling
<pq>
emersion, AMD DC when the primary plane is not in use, and you want to disable one of the other active planes?
<emersion>
so, user-space can do the following:
<emersion>
- enable scaled primary plane + overlay + cursor, everything is fine
<emersion>
- disable overlay, fails because the cursor can no longer be painted
<emersion>
even allocating a fake FB in the driver wouldn't work iirc
<emersion>
there's been a long discussion about this on dri-devel
<pq>
Weston assumes that a CRTC cannot be active without a primary plane being active, sounds like we want to keep that assumption.
<pq>
Does this help with the AMD case?
<emersion>
not really, amdgpu doesn't care about primary plane being active (only intel does)
<pq>
no, but it compositor always keeps primary plane active, can you still end up in that trouble on AMD?
<emersion>
user-space should be prepared to fall back to unscaled primary plane + cursor
<pq>
*if
<emersion>
or alternatively scaled primary plane + no cursor
<zamundaaa[m]>
pq: my idea was that if a plane requires a modeset to be enabled, it'll require one to be disabled as well. But ofc that the reverse isn't necessarily true...
<pq>
zamundaaa[m], when would you ever be willing to do a modeset to enable an overlay?
<vsyrjala>
maybe amdgpu shouldn't expose scaling on the primayr plane...
<pq>
zamundaaa[m], I would recommend that when you are doing modesets, like lighting up a new output, don't use any extra planes at first.
<emersion>
vsyrjala: well this behaviour is fine in general, because the only guaranteed thing to work for legacy API is unscaled primary plane + cursor
<emersion>
as soon as user-space tries to scale FBs and use overlays, they should be prepared to have fallbacks and use the atomic API
<pq>
zamundaaa[m], then you would never enable an overlay with a modeset. This is a very good point, I don't think Weston takes care of this.
<pq>
or does it... maybe Weston does this implicitly, because it has no FB from the renderer when lighting up an output.
<pq>
so Weston cannot even test overlay configs
<zamundaaa[m]>
pq: yeah that approach was what I was thinking of as well
<kennylevinsen>
dottedmag: the wayland connection implementation should allow it to sent in any message before the last, but note that unix(7) indicates that ancillary data acts as a read barrier, so if you are not using one sendmsg, you would add it to the last message to allow a single recvmsg to read the message with ancillary data.
<vsyrjala>
emersion: what do you mean intel cares about priamry plane being active? we can have any arbitrary set of planes active
<kennylevinsen>
("it" being the fds of course)
<emersion>
vsyrjala: i tried enabling the overlay/cursor without the primary, and it failed
<pq>
zamundaaa[m], I think doing modesets with minimal planes usage is a good idea to make it more likely that things will work. You might also need to downgrade existing outputs to improve the chances of enabling a new output.
<vsyrjala>
emersion: not because the primary can't be active. you must have hit some other hw limit
<emersion>
vsyrjala: this was on an old sandybridge
<emersion>
so maybe things have changed
<vsyrjala>
no
<pq>
emersion, I think Weston will fall back down to unscaled primary plane and no other planes at all, if things start failing. Seems like a good idea in general.
<pq>
emersion, yup, and the corollary from that, re: zamundaaa[m]'s question, is that when you first enable an output, you don't have an FB from renderer, so you can't even test more complicated configurations, which makes you start with the minimal case always.
<emersion>
pq, hm, why don't you have an FB from the renderer?
<emersion>
i paint an FB when enabling an output
<zamundaaa[m]>
KWin does that, too
<pq>
emersion, because you want to know what KMS configuration you end up with before you actually render.
<emersion>
well, if you start with unscaled primary plane, then you can have an FB :P
<pq>
so you test the overlays before rendering to know what you need to render if anything.
<pq>
exactly!
<dottedmag>
kennylevinsen: That would be a prudent thing to do, however relying on it in server is... iffy? A misbehaving or broken client might cause accidental unrecoverable de-synchronization of fds.
<emersion>
right, and you can't test the overlays, because ALLOW_MODESET
<dottedmag>
So I suppose all reads in server should expect fd to be attached.
<kennylevinsen>
dottedmag: reading unix(7), both from reading the barrier information and the explicit example, that you will only get ancillary data with the last recvmsg if data is sent to you in a single sendmsg. So yeah, you need to wait till the last recv. A weird peer might attach the fd in an early sendmsg as a curve ball, but it is normally *last*
<zamundaaa[m]>
emersion: yep, thus my question about whether or not I can expect disabling an overlay to always work without a modeset
<kennylevinsen>
the wayland connection implementation means that we can get it in any message, in case a "stupid" client or server decide to not act like a single sendmsg :P
<pq>
and you don't have that FB on a fresh new output, because you haven't rendered yet, because you haven't tested KMS configurations yet. That means the only KMS configuration you *could* have is unscaled FB from renderer on primary plane and nothing else, which you cannot test before rendering, but also you don't need to: you just render the whole output image without overlays, and legacy modesetting guarantees
<kennylevinsen>
it just needs to arrive *before* the last byte
<pq>
make it work. Or not.
<dottedmag>
kennylevinsen: OK, so "expect it to come at the end, but prepare to have it anywhere". And, on the other hand, it is courteous for the server to send fds at the last socket message (if more than one message is used).
<dottedmag>
sounds right?
<pq>
kennylevinsen, dottedmag, why does any of that even matter? Doesn't the receiver queue up incoming bytes and fds, and wait until it has enough of both to dispatch the message at the head?
<pq>
for each message you know from the signature how many fds you take from the incoming fd queue
<dottedmag>
pq: I'm trying to understand if recvmsg(2) have to be used on all incoming bytes, which is not obvious from the protocol spec. Looks like it is so.
<pq>
I guess libwayland is quite that lax, but isn't it pretty close?
<pq>
dottedmag, er, why would you ever want to use anything else? You can't know in advance what do use, can you?
<dottedmag>
pq: That's only obvious if you know the spec intimately (I'm not). I might have missed a part where it says that fd is always attached to some specific bytes in the stream.
<pq>
dottedmag, no, I don't fds are attached to any specific bytes at all.
<pq>
+think
<pq>
why would you even care about that?
<emersion>
can i delete the spam comments from "Artem S. Tashkinov Artem S. Tashkinov"?
<dottedmag>
pq: I'm doing a toy compositor in pure Go (well, so far pure, I suppose I'll have to link to libxkbcommon and libinput at some point), and the requirement to do recvmsg means I can't use their built-in fd dispatching, and have to use a system thread for every client.
<daniels>
emersion: go to their user profile and hit the ! button
<daniels>
that'll generate a spam report so we can nuke them all
<dottedmag>
Which is fine for toy compositor, I'm just double-checking I'm not doing something silly.
<pq>
dottedmag, ok, that's something I could have never even imagined, so yeah, I suppose recvmsg should be explained somewhere.
<daniels>
dottedmag: Wayland uses SOCK_STREAM which is a byte-based rather than packet-based stream, so you already have no atomicity guarantees ... I mean what happens if you only partially write a message? should the FD be attached first (in which case it might arrive before your message) or afterwards (in which case it might arrive after your message)?
<emersion>
daniels: ack, thx
<daniels>
dottedmag: so indeed you need to pull in both,and then look aside from your byte-based message queue to the FD queue and pull FDs off as the signature indicates
<dottedmag>
daniels: I understand that, my only concern was if the header is free from any fds. If it is, then I can do a Go built-indispatch, and then based on opcode see if the message needs a recvmsg() handling.
<dottedmag>
However it is not, so it's recvmsg() and thread for every client. Not a big deal.
<pq>
dottedmag, Go doesn't have a simple fd dispatching thing that would allow you to process the fd yourself?
<pq>
that seems like a surprising omission, and throwing threads at it even more strange
<dottedmag>
pq: Unfortunately, no. You have to do UnixConn.Recvmsg() and pass SCM_RIGHTS and all the typical cmsg structures -- and that's outside of regular io.File interface that's hooked up to the scheduler and whatever event dispatching mechanism they use for a particular OS.
<pq>
D'oh.
<emersion>
dottedmag: hm that's surprising to me
<dottedmag>
Well, I suppose this wasn't a primary use-case for Google :)
<pq>
I mean, sure, calling recvmsg is complicacated, but not allowing you to say "do not read() on my behalf" is odd.
<emersion>
can't you go lower level instead of using io.Reader?
<dottedmag>
The lower level is UnixConn.Recvmsg, yes.
<emersion>
then use that and never Read()?
<pq>
dottedmag, I mean in the main loop? Is it not possible to register an fd to watched in the main loop and *not* have the framework call read() on it?
<emersion>
just like libwayland really
ppascher has quit [Ping timeout: 480 seconds]
<emersion>
pq, Go doesn't have an event loop
<emersion>
all calls are blocking
<dottedmag>
Yep. That's less convenient (and from the reading of source code UnixConn.Recvmsg blocks the goroutine/thread instead of putting fd into the event loop and parking it, freeing the thread for other work), but that's how it's going to be.
<pq>
what??
<dottedmag>
Well, the event loop is implicit in runtime.
<emersion>
instead, you start a goroutine (lightweight thread) if you don't want to block
<emersion>
this makes it so there's no synchronous/asynchronous debate
<pq>
so, threads for every little thing you might want to watch?
<emersion>
it's not a real thread
<dottedmag>
They are green threads, very lightweight (hundreds of bytes).
<dottedmag>
And they are dispatched on the thread pool of OS threads.
<pq>
and then you must assume that everything will run in parallel, because some of them might actually run in real threads rather than just co-routines in one thread?
<emersion>
yeah, communication between the goroutines is done via channels
<pq>
oookay. Thanks.
<emersion>
so typically for a network server you'd have one goroutine per client reading data and sending stuff on a channel
creich has quit [Remote host closed the connection]
<dottedmag>
This works quite well, until one of syscalls is not hooked into this dispatch/park-goroutine dance: then OS thread is blocked until the syscall returns. Scheduler is good enough to notice it and other goroutines don't starve, but now the wait is blocking the whole OS thread, and that's not an insignificant drain on resources.
<emersion>
and then you have select operations on channels and whatnot (similar to poll)
<dottedmag>
Fortunately, that's pretty rare. SCM_RIGHTS is the only example I can think of where it happened for me for the last 4 years or so.
<pq>
I'm happy I learnt Rust instead of Go. :-)
<dottedmag>
Different use-cases, different languages. Go is not an ideal choice of language for Wayland compositor, that's for sure. I'm just playing around.
<emersion>
pq: eh, for me it's exactly the contrary :P
<dottedmag>
Oh, I'm taking "Recvmsg is not hooked into event loop" back -- it actually is. So there is no blocked thread per client. Nice.
<dottedmag>
pq: Trying to implement Wayland in a different language highlights the areas where spec might be not clear enough, or C-centric. That's useful.
<dottedmag>
In a significantly different language, that is.
<pq>
dottedmag, btw. libwayland will do send queueing as well. It will cram up to 4 kB of messages into a single sendmsg call, plus any fds on top.
<pq>
so you really have just a byte stream for messages and an fd stream for fds, and not much sync between the two
agd5f has quit [Read error: Connection reset by peer]
<pq>
just strict ordering guarantees
flacks has quit [Quit: Quitter]
flacks has joined #wayland
<dottedmag>
pq: OK. WDYT if I to open a MR clarifying it a bit in the spec?
maxzor_ has joined #wayland
<pq>
dottedmag, in the docbook? Sure, that would be nice.
<kennylevinsen>
But we may not have it defined, but peers *should* send ancillary data on the *last* byte if possible. If you do it this way, the other peer has a chance of doing a single recvmsg with all data and ancillary data, while putting it anywhere else means that at least two recvmsg calls must be made... :(
<kennylevinsen>
(e.g., intentionally sending a header with fds followed by arguments would be bad)
<pq>
kennylevinsen, but all that is just basic optimization, right? The sender would need to go out of its way to call sendmsg twice to pessimize that.
<pq>
even then, I'm not sure if the kernel could deliver both sends for a single recvmsg.
<pq>
maybe?
<dottedmag>
I read something yesterday that someone checked and it could.
<pq>
since it's a stream and not datagram
<kennylevinsen>
yes, but it's not unthinkable that an implementation without a dedicated write connection buffer would be doing a series of sends for parts of the message
<dottedmag>
however messages up to the one that carries fds can be merged together.
<pq>
alright
<pq>
I also think you cannot sendmsg ancillary data without actual bytes to send as normal data.
<dottedmag>
Yes, this does not work either.
<pq>
If you send a garbage byte, then you corrupt the Wayland data stream.
<pq>
so if you have a request which has only an fd argument, you cannot send the fd separately from the message header.
<pq>
I suppose the same goes for recvmsg.
<emersion>
daniels: thanks for handling this!
<daniels>
emersion: np :)
rgallaispou has quit [Remote host closed the connection]
fmuellner has quit []
fmuellner has joined #wayland
<swick>
pq: fyi rust has asnyc which is very similar to goroutines
<pq>
yeah, but it doesn't forbid traditional event loops AFAIK
<swick>
well, the event loop becomes the async runtimes but yeah, you can implement that however you want
<pq>
This isn't good when I'm trying to tell people that blocking function calls (in C APIs) are bad, and solving them with threads (in C!) is worse. :-)
<pq>
if they also have thread-local implicit context data, the more fun blocking functions are
<alextee>
this gets stuck at: Cloning into 'wayland-protocols'...
<daniels>
alextee: yep, infrastructure issue, being worked on
<alextee>
ok thanks
<daniels>
itmt you can clone git://anongit.freedesktop.org/git/wayland/wayland-protocols
<alextee>
thanks, I'll probably wait though because it gets automatically pulled by gtk in some build script and it's more tedious to patch the .wrap file
cedric has quit []
cedric has joined #wayland
cedric is now known as bluebugs
luc4 has joined #wayland
arin0v has quit [Ping timeout: 480 seconds]
cvmn has quit [Ping timeout: 480 seconds]
st3r4g has joined #wayland
pnowack has quit [Quit: pnowack]
<alextee>
is it safe to use wayland-protocols as a meson subproject or is it something that should ideally be installed on the user's machine?
<alextee>
asking because gtk4 needs a higher version than what's available on ubuntu 20.04
cvmn has joined #wayland
<vyivel>
alextee: it's safe, it's just a bunch of xml files used to generate the code on build time
<alextee>
ah ok cool, thanks!
<Ariadne>
in alpine, a contributor submitted a package update for the latest wayland version (1.20.0), and now we are having a lot of problems with wl_proxy_marshal_flags missing.
<Ariadne>
we upgraded wayland-protocols already
<Ariadne>
am i missing something?
ikke has joined #wayland
<emersion>
hmm
<emersion>
Ariadne: what kind of issues? do you have an error message at hand?
<vyivel>
undefined references to `wl_proxy_marshal_flags'
<emersion>
when running clients compiled with an older version?
<ikke>
Their solution was to set LDFLAGS -lwayland
<Ariadne>
hmm, that would indicate that something is no longer pulling -lwayland into the linking flags
<Ariadne>
have you checked the wayland .pc files yet?
fmuellner has quit [Ping timeout: 480 seconds]
<ikke>
-lwayland-client
<ikke>
"Now normally I would just look for a source file to patch where I could add #include <wayland-client> but the file in question seems to be Unified_cpp_gfx_gl0.cpp which is generated-on-the-fly rather than being part of the firefox tarball ..."
<emersion>
libwayland.so doesn't exist…
<emersion>
there's only libwayland-server.so and libwayland-client.so
cvmn has quit [Ping timeout: 480 seconds]
<emersion>
so i'm a bit surprised -lwayland fixes it
<ikke>
emersion: yeah, I meant -lwayland-client
<emersion>
ah ok
<emersion>
i see the symbol in the so, fwiw
<emersion>
155: 000000000003e540 1231 FUNC GLOBAL DEFAULT 12 wl_proxy_marshal_flags
<emersion>
rebuilding wayland-protocols won't help, it's just a bunch of XML files
maxzor_ has quit [Ping timeout: 480 seconds]
<emersion>
by any chance, does firefox bundle its own libwayland?
<emersion>
using wayland-scanner 1.20 and linking to libwayland < 1.20 would result in this error
<emersion>
does this only happen with firefox, or also with other packages?
xantoz has quit [Ping timeout: 481 seconds]
wahfato has quit []
Narrat has joined #wayland
cvmn has joined #wayland
<emersion>
searching for wayland-client in the firefox tree, i don't ever see it looked up…
<emersion>
let me guess… dlopen shenanigans, and these are placeholders?
<vyivel>
"Wayland compatibility header, it makes Firefox build with wayland-1.2 and Gtk+ 3.10."
* emersion
regrets looking into this, can't unsee now
<jadahl>
emersion: I suggest you to not look at very similar dlopen magic in sdl then
<vyivel>
"Those strucures[sic] are just placeholders and will be replaced by real symbols from libwayland during run-time linking. We need to make them explicitly visible."
<emersion>
;_;
<vyivel>
why firefox
<jadahl>
because it might need to run on a system without libwayland-client.so
<emersion>
… this isn't how you do software
<emersion>
anyways
<emersion>
maybe adding the missing wl_proxy_marshal_flags prototype in this file might help then
<emersion>
maybe try this Ariadne?
<emersion>
cc ikke as well
<bl4ckb0ne>
why run time link? cant this be done properly?
<zubzub>
does this mean chromium is the only real browser left now? :p