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
Hypfer has quit [Ping timeout: 480 seconds]
slattann has joined #wayland
<JoshuaAshton>
Hello!
<JoshuaAshton>
jadahl: What's the release cadence of the wayland-protocols repo? It would be nice to start landing the xwayland-shell stuff in places.
fmuellner has quit [Ping timeout: 480 seconds]
Hypfer has joined #wayland
ybogdano has joined #wayland
ybogdano has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
slattann has quit [Quit: Leaving.]
xyb has joined #wayland
xyb_ has joined #wayland
xyb has quit [Ping timeout: 480 seconds]
slattann has joined #wayland
zvarde1988303 has quit []
zvarde1988303 has joined #wayland
xyb__ has joined #wayland
xyb_ has quit [Ping timeout: 480 seconds]
xyb__ has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
sav10 has joined #wayland
zebrag has quit [Quit: Konversation terminated!]
<DemiMarie>
What object ID allocation algorithm does Wayland use?
sav10 has quit []
Company has quit [Quit: Leaving]
kts has joined #wayland
kts has quit [Quit: Leaving]
jekstrand has quit [Ping timeout: 480 seconds]
eroux has joined #wayland
jekstrand has joined #wayland
<kennylevinsen>
DemiMarie: next available, see wl_map
<DemiMarie>
kennylevinsen: does the situation ever arise where there is one high-numbered object that keeps the map from being shrunk?
<dottedmag>
It may in pathological cases, however the algorithm won't be changed because libwayland expects it.
<dottedmag>
Pathological cases: allocate 1B+1 objects, free first 1B objects.
<dottedmag>
Any changes to the algorithm alas are wayland 2 material.
<DemiMarie>
What about adding a new request and event to change the ID of an object?
<i509VCB>
A request to change object ids sounds pretty messy
<dottedmag>
I think we've had this discussion already.
<dottedmag>
This is backward compatibilty change.
<dottedmag>
And a solution for non-problem
<i509VCB>
ideally in wayland 2 id allocation algorithms would be a client dependent thing, the server just gets ids and a range it can use
<dottedmag>
Yeah, just strike out one sentence from wayland protocol spec in wayland 2. but it will break existing compositors.
hardening has joined #wayland
<dottedmag>
Also clients behaving in the manner that causes the map to be sparse are quite suspicious. If a compositor wants to prevent its resource usage balooning it may disconnect clients that cross, say, 1M ID boundary.
dcz_ has joined #wayland
<DemiMarie>
i509vcb: why do you say that a request to change object IDs sounds messy?
<i509VCB>
requests to change ids could be quite racy
<kennylevinsen>
Making the map N big requires actually holding N objects at once due to always issuing next available. That the map becomes sparse doesn't really matter if N is acceptable to the server, which it can easily assert.
<i509VCB>
It would have to be fully symmetric
<dottedmag>
kennylevinsen: I think the use-case here is protection against adversarial clients. These clients don't have to have any state.
<dottedmag>
DemiMarie: What is your goal?
<DemiMarie>
dottedmag: robustness under arbitrary worst-case conditions
<DemiMarie>
and not having to use a hash table or tree for the map
<kennylevinsen>
the same still holds. they can't get there for free, and the server can cap max objects per client.
<dottedmag>
DemiMarie: disconnect clients that allocate big IDs. Case closed. No backward compatibility breakage needed.
<DemiMarie>
kennylevinsen: it might indeed be a non-issue for Wayland. I was thinking more of ID-based RPC protocols in general.
<DemiMarie>
more generally, ensuring that if a connection uses a lot of resources temporarily and then no longer needs them, the extra resources can be reliably and promptly released.
<dottedmag>
DemiMarie: if it's not Wayland, then don't specify in RPC spec object allocation algorithm the way Wayland did.
<DemiMarie>
dottedmag: it is still an interesting question what the optimal algorithm is.
<DemiMarie>
(albeit one off-topic for this channel)
rv1sr has joined #wayland
eroc1990 has quit [Remote host closed the connection]
<DemiMarie>
back to on-topic: what do people think about my extended wl-shm MR?
eroc1990 has joined #wayland
<i509VCB>
The extended wl-shm MR is interesting, I just need to find time to make an implementation in smithay
<DemiMarie>
i509VCB: Should v2 and v3 be split?
<DemiMarie>
(I designed the protocol so that every compositor using libwayland-server for wl-shm gets v2 for free)
<i509VCB>
v2 was offset only I recall
<DemiMarie>
Correct. An earlier version also allowed for pools greater than 2³² - 1 bytes, but that was decided against.
<DemiMarie>
sorry, 2³¹ - 1 bytes
<i509VCB>
probably a wise decision to make v3 a separate thing
<i509VCB>
especially considering that some protocols need a revision to state whether the wl_shm usage flags are needed
<DemiMarie>
yeah
<i509VCB>
wl_surface and wl_shm is easy, just state that if the wl_buffer is backed by wl_shm, the buffer must have the read flag set
<i509VCB>
some other protocols (screencopy I believe) need a revision to make this explicit
<DemiMarie>
screencopy writes to a wl_buffer
<DemiMarie>
IIUC
<DemiMarie>
which reminds me: what happens if the client sends a file descriptor that is on a FUSE file system the client controls, then refuses to service FUSE requests?
<i509VCB>
if the FUSE requests are failed, the mapping would fail?
<DemiMarie>
not failed, ignored
<DemiMarie>
so that the compositor hangs forever in state D
<i509VCB>
how would you detect that?
<DemiMarie>
you can’t in general
<DemiMarie>
you can require memfds, or give up on the “shared” part and instead use io_uring (which is asynchronous) to access the files
<i509VCB>
requiring memfds is going to be controversial unless it's only on Linux (and maybe FreeBSD 13+)
<DemiMarie>
another option is to use fstatfs(2) to check that the file is on ramfs or tmpfs
<dottedmag>
That's interesting. Should the protocol specify time limit for serving the requests and allow to disconnect clients that can't keep up? Or is it up to compositor?
<DemiMarie>
but that prohibits some interesting use-cases
<DemiMarie>
theoretically a compositor can disconnect any client for any reason
<DemiMarie>
the problem here is that the compositor is blocked indefinitely in kernel mode, and won’t even die if sent SIGKILL IIUC
<dottedmag>
Yeah, this requires some async or interruptible API for sure.
<dottedmag>
It starts to feels there is a book "how to write robust compositor" that ought to be written.
danvet has joined #wayland
<DemiMarie>
This also assumes that the kernel will not just fail the mmap() call, which it probably should (assuming the FUSE FS owner is sandboxed).
<DemiMarie>
At least Linux will fail open() calls if the FUSE filesystem is not run by a process that can send a SIGSTOP to the opener. Other calls should probably have similar checks.
<i509VCB>
Is there a write up somewhere of using io_uring to read from something you'd typically mmap? Although does this keep a file open or do I have to constantly reopen?
<dottedmag>
DemiMarie: are there similar situations? A file on NBD/NFS "non-responsive" mount?
<DemiMarie>
i509VCB: 1. Don’t panic, most sandboxes (except Android) block FUSE, and a non-sandboxed process can do much worse things.
<DemiMarie>
2. Not that I am aware of, and yes, you need the file open.
<DemiMarie>
dottedmag: Arguably those are system misconfigurations a compositor should not try to (and generally cannot) work around
manuel_ has joined #wayland
<DemiMarie>
Thoughts on wayland-protocols MR !149 vs !143?
<DemiMarie>
Personally I think !149 is on a much sounder mathematical foundation.
hardening has quit [Ping timeout: 480 seconds]
<kennylevinsen>
That is a given, issue lies in adoption due to complexity
<DemiMarie>
IMO it is actually much simpler from a client perspective. From a compositor perspective, I think (based purely on intuition) that an incomplete implementation of !149 would be about as good for users as a complete implementation of !143, and at least the wlroots MR is not that complex.
<DemiMarie>
I could easily see !143 being merged, only to be eventually deprecated.
<kennylevinsen>
It introduces a lot of new concepts, and I haven't had time to read it.
<DemiMarie>
!149 or the wlroots MR?
manuel_ has quit [Ping timeout: 480 seconds]
<kennylevinsen>
!143 really only does one thing: add a scale event, which happens to be fractional
<kennylevinsen>
The wlroots MR
<vyivel>
i've realised a pretty "fun" thing yesterday: !149 doesn't even communicate the preferred scale factor
<DemiMarie>
oops
<vyivel>
it tells coordinate space scale factor to the client, but it doesn't mean the client has to rerender
<vyivel>
because it means nothing by itself
<vyivel>
i propose merging !143 (without rounding algorithm stuff) to convey scale
<DemiMarie>
does that mean that !143 and !149 are actually complementary, rather than competing?
<vyivel>
then, rename !149 to coordinate-scale or smth and merge it too
<vyivel>
DemiMarie: !149 is an implementation of what !143 asks for, so to say
<DemiMarie>
vyivel: what do you mean?
<vyivel>
and clients like SDL could get away with only using !143 i think, if they are simple enough
<kennylevinsen>
I initially tried to make the !143 orthogonal to things that fix coordinate systems for subsurfaces. It temporarily derailed with rounding complexity, but we're back to the original form now.
<vyivel>
DemiMarie: !143 tells "hey i want this scale factor please", !149 tells "i'm using this coordinate space now"
<DemiMarie>
vyivel: nice
<kennylevinsen>
Although aligning on fractional number type would be nice lol
<vyivel>
so a client that wants perfect™ rendering listens to !143 event and sets client scale factor via !149 (it is assumed the server sends same scale factor via both, otherwise wtf is it doing)
<kennylevinsen>
"so inputs go in wl_fixed, I get my scaling factor in v120, and set it in 8_24"
<vyivel>
yeah that part sucks
<vyivel>
i'd prefer !143 to use 8_24 tbh
<vyivel>
although maybe using fixed everywhere won't cause much rounding issues... idk
<kennylevinsen>
I'm fine either way. Reason I didn't use wl_fixed was mainly that Daniels who authored wl_fixed said "don't" :D
<kennylevinsen>
No idea about the merits of 8_24. We already have v120 somewhere else.
<vyivel>
v120 is for hi-res scrolling iirc
<vyivel>
and 120 is because that's what linux uses?
<dottedmag>
i509VCB: IORING_OP_WRITE takes source buffer+size, and offset to write into, so it's a direct substitute for "memcpy into mmaped file", I think
rasterman has joined #wayland
m5zs7k has quit [Ping timeout: 480 seconds]
m5zs7k has joined #wayland
MajorBiscuit has joined #wayland
Major_Biscuit has joined #wayland
kts has joined #wayland
<pq>
i509VCB, to my understanding io_uring does not define replacements for things like mmap. Instead, it makes all such operations an asynchronous request-reply, which means that you never block in kernel mode asking for e.g. mmap; you just get the reply later. So it's the old syscalls, but in a different transport than a synchronous function call.
<pq>
at least on a high level
<pq>
would io_uring save you from SIGBUS or page faults if you mmap through it and then access the map as before? I would not think so.
MajorBiscuit has quit [Ping timeout: 480 seconds]
mvlad has joined #wayland
<emersion>
vyivel: no, because that's what Windows uses!
<vyivel>
ah :S
<emersion>
(Windows API for high-res scroll events)
adia has quit [Read error: Connection reset by peer]
<daniels>
heeen: that binds it to a virtual terminal so the DRM backend can switch it into graphics mode
<heeen>
we are building a qtwayland compositor and it seems to work without that
<heeen>
is it a requirement of weston only, or weston if it uses something else than openGL for comnpsiting?
devilhorns has joined #wayland
<daniels>
no not really, it's just TTY management in general, which is also useful if you want to restore text mode, switch to other VTs, etc
<daniels>
if it works for you without that, then great
<daniels>
(we outsource everything to libseat now anyway)
<pq>
heeen, there is one thing you really need to make absolutely sure about VTs though: input inhibition.
<heeen>
can you elaborate
<pq>
heeen, somehow you must ensure that the VT/tty stops getting (keyboard etc.) input when your compositor is running. Simply opening input device nodes does not do that.
<pq>
heeen, if you fail in that, then anything typed into, say, a text editor in the desktop, will also be typed into the VT.
<pq>
if that VT for some reason has an open shell...
<heeen>
I think I haven't fully grasped the correlation here yet
<heeen>
this device has a touchscreen
<heeen>
and usb ports
<pq>
I think it is not a good idea to assume that no system running that compositor will ever have a keyboard attached.
<heeen>
if I plug in a keyboard without a compositor, that goes to the VT that displays the linux console, right?
<pq>
yes
<pq>
and if you start your compositor, that keyboard *still* does to the VT, *and* to your compositor if your compositor opens the device.
<heeen>
but I want it to go to the compositor, so I need to grab the VT, like with the TTY arguments to systemd?
<pq>
I'm not sure the TTY arguments to systemd do it on their own. Logind might, though.
<pq>
heeen, do you understand the danger? That's a good start before trying to figure out how to stop it.
kts has joined #wayland
<heeen>
I think I do understand the issue. even if the VT shows the console login, someone might enter the root password or it might be empty or something
<pq>
the opposite
<pq>
Even if you see your desktop and you are typing into something completely harmless like a text editor, those same key events might be going to the tty as well.
<heeen>
yes
<pq>
if the tty has a login prompt, with luck, you might be able to log in and run bad commands when you are thinking you are writing a text file.
<pq>
or maybe the tty has a shell open already
<heeen>
and someone might accidentally or with bad intentions enter root<enter><enter> and have an invisible root shell
<pq>
you just don't see, because DRM KMS is showing something else
<pq>
yes
<pq>
I remember this actually being a problem with Weston many years ago.
<pq>
so how to stop that
<heeen>
you mentioned logind and/or systemd
<pq>
tty has ioctls that can stop input to them, but you need something to use them. I suspect logind does that if you ask logind for the right things, because otherwise Weston would have the problem today.
<pq>
another thing might be ioctls on each evdev device separate to "grab" them, denying the input events from going anywhere else. I *think* that should work.
<pq>
One thing that does NOT help, is physical seat configuration. As the kernel routes the input internally, it has no concept of physical seats. Seats are a userspace invention completely.
<pq>
this just a lot of background information, and I'm not sure how much of it is of concern to you
<pq>
but I think it's good to know
<heeen>
mhm
<heeen>
does anyone know if those systemd settings are actually related to this, or a prerequsite to actually detach the input from the console (and possibly restore on exit)?
<heeen>
or just required for some DRM switch
<pq>
That I'm not sure. I don't tend to run Weston as a systemd service myself.
<heeen>
I'm not sure why it works for us without them input issues notwithstanding
kts has quit [Quit: Leaving]
<heeen>
we haven't tested with keyboard actually because right now it is a prototype with no physical keyboard
<pq>
well, DRM KMS does not care about the VT/tty at all. If someone is DRM master, they can tell the display to display anything they want.
<pq>
I'm not sure what switching the tty to graphics mode actually does... maybe it stops fbcon harder, in case you used fbdev?
<pq>
DRM KMS has its own "override fbcon/fbdev" logic, AFAIU
<pq>
heeen, if you don't actually need VTs for anything, maybe consider turning them completely off in the kernel build?
<pq>
then they definitely won't interfere :-)
<pq>
CONFIG_VT=n
<heeen>
noted
<pq>
however, some userspace might be unhappy if they expect VT to exist, even if just to turn them off.
<dottedmag>
Is there a good set of small Wayland clients with little-to-no-dependencies beyond libwayland? I'm playing with a making compositor for macOS, and would like to have some test clients to see how it works. I know of wleird repo, but I'd also like to see some clients that do normal things.
<dottedmag>
... and don't bring up a ton of dependencies that never were built under macOS
nerdopolis has joined #wayland
<emersion>
dottedmag: imv, foot, weston examples…
d42 has joined #wayland
<zamundaaa[m]>
<vyivel> "i've realised a pretty "fun..." <- Of course it does, and even in the same way as !143
<pq>
the "simple" programs from weston clients (examples) specifically, they don't need even Cairo.
<zamundaaa[m]>
With !143 the client gets a logical size + a scale factor to calculate the pixels for the buffer
<zamundaaa[m]>
With !149 the client gets the pixel size + a scale factor to calculate the logical size. Or to directly use in its rendering
jmdaemon has quit [Ping timeout: 480 seconds]
<vyivel>
scale_factor event only conveys that future coordinates received from the server will be scaled by the given factor
<vyivel>
it doesn't mean that the client has to interpret said factor as the scale it needs to render at
<zamundaaa[m]>
The client doesn't have to do anything, ever
<zamundaaa[m]>
With !143 it can ignore the scale event too
<vyivel>
sure it can
<vyivel>
but the event in !143 conveys the *preferred scale* for the client to use
<vyivel>
event in !149 conveys the value the server uses
<zamundaaa[m]>
!143 does not convey any preferred scale
<zamundaaa[m]>
The scale is really given in the form of the logical size
<vyivel>
when the window is moved between outputs, the compositor will send a new scale factor
<vyivel>
it has no reason to send a new size, as the logical size is preserved between outputs
<zamundaaa[m]>
That just tells the client which resolution of buffers would be preferred
<zamundaaa[m]>
Which is exactly the same as !149 does
<zamundaaa[m]>
vyivel: !149 doesn't change that
<vyivel>
so when a client receives wp_fractional_scale_v1.scale_factor event, it must immediately rerender?
<zamundaaa[m]>
It can. It doesn't need to
<vyivel>
well¸ if it doesn't need to, the user will see a blurry surface
<zamundaaa[m]>
The compositor should, if it wants to have sane visuals, scale clients that are using the wrong scale for their current output. Just like with the integer buffer scale
<zamundaaa[m]>
vyivel: Yes. Same as in !143
<zamundaaa[m]>
Documenting the ideal behavior of the client when the scale changes in the protocol would be good though
<vyivel>
consider two cases: 1) only a new scale factor is sent, 2) a new scale factor and new size is sent
<vyivel>
if the client has to rerender on server-side scale factor change, it will issue a useless frame in case 2
<dottedmag>
emersion: thanks
<vyivel>
if the client doesn't have to rerender, it might incorrectly ignore case 1
<zamundaaa[m]>
Yeah, those are the two options. Sending an explicit configure event would probably be best
<dottedmag>
pq: thanks
<vyivel>
hm
<vyivel>
maybe the protocol has to state that a client should reply to a scale_factor event with a corresponding set_scale_factor...
<vyivel>
i thought the idea was that sending factors by themselves carries no meaning
<vyivel>
so both the client and the compositor can pretty much spam factors in a row without any side effect
slattann has quit []
rv1sr has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
<zamundaaa[m]>
The client can do that. Unless it does other requests, the scale has no effect
<zamundaaa[m]>
If we specify that the client should only apply the new scale once a configure event happens, the server can do the same too
cvmn has joined #wayland
rv1sr has quit []
hardening has joined #wayland
tzimmermann has quit [Quit: Leaving]
floof58 has quit [Quit: floof58]
floof58 has joined #wayland
rv1sr has joined #wayland
cvmn has quit [Ping timeout: 480 seconds]
rv1sr has quit []
rv1sr has joined #wayland
sav10 has joined #wayland
smallville7123 has quit [Quit: Konversation terminated!]