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
hays has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
soreau has quit [Remote host closed the connection]
soreau has joined #wayland
slattann has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
bluepqnuin has quit []
anomalous_creator[m] has quit []
MatrixTravelerbot[m]1 has quit []
psydroid[m] has quit []
zebrag has quit [Quit: Konversation terminated!]
nerdopolis has quit [Ping timeout: 480 seconds]
<yshui`>
I was reading on the SIGBUS problem with wl_shm, and also saw the thread about adding MAP_NOSIGBUS. And I was wondering if userfaultfd would be a used as an alternative solution, or is that dumb?
<yshui`>
would -> could
Company has quit [Quit: Leaving]
<yshui`>
also, does `mincore()` not work in this particular case?
<i509VCB>
userfaultfd looks interesting, although it assumes you have a dedicated thread to watch for faults.
<yshui`>
I am thinking the library can have a background thread that does just that.
<RAOF>
That would be somewhat of a departure :)
<RAOF>
`mincore()` doesn't work, because of the unavoidable race.
<yshui`>
Hmm, looks like `mincore()` doesn't think the absent pages are unmapped after `ftruncate()`
<i509VCB>
Messaging the correct thread about it being the failing thread would be easier at least
<yshui`>
Ah, also the race. time of check vs time of use I think?
<RAOF>
Indeed.
<yshui`>
do we care about the failure? with MAP_NOSIGBUS we also don't get indication whether the access failed.
<RAOF>
userfaultfd _could_ work, I think, but (a) that's extremely a linuxism, and (b) that's a pretty obscure hammer to be reaching for.
<RAOF>
_I_ care about the failure, but the protocol doesn't let you guarantee that you _can_ send a failure, so 🤷♀️
<i509VCB>
I guess if Unix 2 ever comes around the moral of the story is to make mmaped memory have it's size fixed at creation time :)
<i509VCB>
alas we need extensions
<yshui`>
indeed 😢
tzimmermann has joined #wayland
danvet has joined #wayland
jgrulich has joined #wayland
dcz_ has joined #wayland
slattann has quit []
rasterman has joined #wayland
mvlad has joined #wayland
hardening has joined #wayland
ybogdano has quit [Ping timeout: 480 seconds]
Net147 has quit [Read error: Connection reset by peer]
fahien has joined #wayland
Net147 has joined #wayland
<pq>
yshui`, did you also find out about memfd and sealing? More linuxisms.
<yshui`>
yeah, i did.
<yshui`>
Is linuxism bad? MAP_NOSIGBUS would be linuxism too.
<pq>
didn't some BSD flavor have MAP_NOSIGBUS already?
<pq>
anyway, there are people who care about the BSDs at least, and they will not be happy with linuxisms.
<pq>
Individual compositors could get away being linux-specific, but libwayland is such a low-level component in the stack that it should be more portable.
<yshui`>
OpenBSD has __MAP_NOFAULT, can't find anything on other BSDs.
hnhx[m] has joined #wayland
<yshui`>
I see, that makes sense
<emersion>
yshui`: patching a few compositors that want to avoid SIGBUS is easier than forcing all clients to use a Linux-specific API
<emersion>
the latter won't happen, ever
<emersion>
there will always be old or portable clients which don't use the linuxism
<yshui`>
But portable compositors wouldn't be to benefit from this?
<yshui`>
I saw the issue you reported to FreeBSD about file sealing 😄
<yshui`>
If file sealing is made portable maybe clients would start moving to it?
<emersion>
i won't
<pq>
If file sealing was a) available, b) had clear benefits, and c) there was pressure to use it, then sure.
<pq>
and maybe old clients that won't get updated could run through a proxy that converts them to sealed, but I don't see how to do that without incurring a significant runtime cost.
<pq>
all in all, seems like a lot of work compared to the gain
<yshui`>
does the current SIGBUS handler solution have draw backs? like does the compositor have to be especially careful when using it or it would break?
<pq>
I think the drawback is the use of a signal handler in general. It's archaic process-wide mechanism that is hard to make "composable" (i.e. let libraries use it without potentially messing up each other).
Leopold has joined #wayland
<pq>
and SIGBUS is something you cannot handle in an event loop, unlike most other useful signals via signalfd (linuxism).
<yshui`>
so avoiding it is beneficial even if the solution is platform specific? i see.
<yshui`>
if we are using linuxism anyway (signalfd), then we could use userfaultfd.
<pq>
I guess that depends
Azem has joined #wayland
<pq>
no
<pq>
each linuxism is a separate new obstacle
Azem has quit [Remote host closed the connection]
<pq>
just because libwayland has grown a BSD replacement for signalfd does not make it have a replacement for something else
<pq>
In fact, in hindsight, having an event loop implementation in libwayland-server (server only, not client) is seen as a mistake.
<yshui`>
i see..
<pq>
a shared wl_shm implementation in libwayland-server is starting to look like a mistake too
<yshui`>
why?
<pq>
request validation, sigbus...
<pq>
even the wl_shm buffer reference counting API is a bit out of hand
<yshui`>
it's better to let the compositor implementer, or libraries like wlroots worry about that?
MajorBiscuit has joined #wayland
<pq>
a lot of work to share a piece of code that is looking smaller and smaller compared to other things while having difficulties exposing a sufficient and reasonable API that is both stable and allows sharing that little piece of code.
<pq>
yes, so it is starting to seem
<yshui`>
i see..
<yshui`>
i think i learned a lot. all these challenges only a library like libwayland would need to consider
<qyliss>
I have an implementation of FreeDesktop CI for NetBSD I've been working on, but I thought I'd wait for NetBSD support in Wayland before I proposed it so I had a good example.
<yshui`>
that's not niche, is it? i can see things like flatpak would need that
<qyliss>
Replying to me? Flatpak is very Linux-specific
<yshui`>
qyliss: sorry, no. I think there is a user not identified with OFTC network maybe?
<qyliss>
ugh :(
<pq>
I cannot see who started talking about "niche", I only see yshui`'s reply.
<yshui`>
yeah, hnhx you need to register your nick with OFTC
<pq>
I think usually one would like to have CI support for the OS in the same MR that adds the OS support in libwayland to make sure it cannot regress, but I suppose there could be a chicken-and-egg problem there vs. ci-templates.
<yshui`>
let me forward their question:
<yshui`>
> I have a very niche question. Would it be possible to run a program that has a GUI in a chrooted environment in wayland?
<yshui`>
> I know that its possible in xorg but im not sure about wayland.
sumoon is now known as Guest2420
<qyliss>
pq: I'm a little fuzzy on the details, but my recollection is that fd.o would first like to see a repository where it could be used, so doing it all in a single MR would be quite complicated
<pq>
yes, it's possible. I suppose the simplest thing would be to bind-mount the Wayland socket there, but then the compositor does not know the client is restricted, in case that should make a difference.
<dottedmag>
there more details to take care of, right? XKB keymaps come to mind. Also, DRI access.
<pq>
qyliss, I don't know the polic of ci-templates project, but I think you can do it: fork both ci-templates and wayland, make a draft wayland MR that uses your forked ci-templates to prove your ci-templates MR works.
<qyliss>
hmm, okay, I can have another look into it
<pq>
dottedmag, keymaps come via Wayland as an fd, so not problem. DRI only if you actually want to use a GPU.
<qyliss>
it's been a while, so I also need to do things like update it for the latest NetBSD release
<dottedmag>
pq: as an fd of a single keymap that has everything in it? I missed this part, I thought compositors send non-processed keymaps to clients, and clients do their lookups of constituent parts from the filesystem
<pq>
I believe it has everything.
<dottedmag>
I see xkb_keymap_get_as_string in wlroots now, and that saves everything.
pH5 has quit [Ping timeout: 480 seconds]
mtretter has quit [Ping timeout: 480 seconds]
pH5 has joined #wayland
mtretter has joined #wayland
nerdopolis has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #wayland
dcz_ has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
Leopold__ has joined #wayland
Leopold_ has quit [Ping timeout: 480 seconds]
fmuellner has quit [Remote host closed the connection]
fmuellner has joined #wayland
rgallaispou has joined #wayland
Leopold__ has quit []
fahien has quit [Ping timeout: 480 seconds]
<wlb>
weston Merge request !1020 opened by Pekka Paalanen (pq) New screenshooter protocol and implementation https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1020 [Clients], [Core compositor], [GL renderer], [libweston API], [Pixman renderer], [Testing], [Utilities]
floof58 has quit [Read error: Connection reset by peer]
floof58 has joined #wayland
<any1>
I guess weston-screencooter's intended usage is completely different from that of ext-screencopy?
<pq>
any1, I suppose there is overlap, but not fully. For instance, I need the different pixel sources.
<any1>
pq: That pixel source stuff exposes a lot of implementation details
<pq>
exactly, that's why it's weston extension
<pq>
not for wayland-protocols
<any1>
'writeback' is interesting. I didn't know you could do that.
<pq>
KMS has a connector type "writeback", which may be exposed by some drivers on some hardware
rv1sr has joined #wayland
<pq>
Weston would have problems implementing things like "do not include cursors", because renderers or backends do not what a "cursor" is.
<pq>
*do not know
luna has joined #wayland
<any1>
That's why the wording is "should", not "must". ;)
<pq>
on a very quick look, ext-screencopy is more like a pipewire reinvention, isn't it?
<emersion>
that doesn't make sense to me
<any1>
Maybe there should be a capability flag to indicate whether the compositor can do that or not
<emersion>
if it's "should", then user selects "no cursor", still gets it, gets confused
<emersion>
pq, yes, but pipewire is over-engineered and complicated
<emersion>
the video side is a mess
<any1>
Yeah, pipewire is a bit over the top if you ask me.
<pq>
that input/cursor handling ext-screencopy seems to be something quite special - what's it for?
<emersion>
pq, vnc…
<any1>
And miracast
<pq>
oh, that explains a lot
<emersion>
remoting in general i guess
<pq>
yeah, ok
<pq>
that's quite a special use case, and not really alike screenshooting
<any1>
I originally proposed it as its own protocol names ext-cursor-spy-v1
<any1>
named*
<emersion>
yeah, i agree, pq
<pq>
I would recommend wording and designing that extension specifically for VNC and other similar remoting use cases, and not attempts to make it look like a generic screenshots-and-whatnot inteface.
<any1>
I really don't care where we put it. I would just really appreciate people making decisions and sticking with them.
<emersion>
i said i don't like it, be it as a separate ext or in screencopy, because it don't like the concept, not where we put it
<pq>
Currently I have no interest in VNC-server-as-a-client extensions. Not that I really look at much any protocol extensions these days.
<any1>
emersion: You don't want to have cursor capturing at all?
<pq>
So, I'm neutral.
<emersion>
but i don't have time to look into this regardless, so my opinion wouldn't really matter either way
<any1>
emersion: Your opinion matters most for this
devilhorns has joined #wayland
<any1>
It's won't move forward without your approval
<any1>
It*
<pq>
Usually one wouldn't care at all *how* a screenshot is recorded, but in Weston test suite it's important to control to test the different paths.
<pq>
Also on a set-top-box/TV with 4k video and a weak GPU, you'd want to force writeback always to avoid stalling the display.
<pq>
sure, it could be compositor config option, too
<any1>
pq: I think a config option would make more sense
<any1>
but I don't know your usecase exactly
<pq>
hence the test suite is the primary reason
<any1>
emersion: If I remove cursor capturing from ext-screencopy, do you think you might accept it then?
zebrag has joined #wayland
<pq>
emersion, you say pipewire is over-engineered and complicated. I'd say ext-screencopy is over-engineered and complicated. These opinions usually stem from not understanding or not considering the use cases the "complicated" system is designed for.
<emersion>
pq, i understand pipewire though. i helped design the DMA-BUF part of it
<emersion>
the more i know about it, the less it makes sense to me
<pq>
ok
<emersion>
pq, i think wtay is an audio expert, but just went with whatever for the video side
<emersion>
pq, also the contribution experience was a bit weird
<emersion>
things get merged without any review
<emersion>
any1: i'd need to look again at the protocol
<emersion>
pq, ext-screecopy is for both screenshots, screencasts and VNC
<pq>
that sounds messy
<emersion>
after all, a screenshot is a screencast with only one frame captured
<emersion>
but yeah, VNC needs more things
<pq>
I'm not so sure... screencasting may have considerable forward cost to set up, but then goes brrrr once it's up. Screenshots could be done with less setup but higher repeat cost. Also the UI to authorize each may be different. Maybe you want to give access to a single shot, not a video.
<pq>
and the VNC case is on a completely different level
<pq>
anyway, not a topic I can spend time on, so I shouldn't comment any further
<i509VCB>
The System76 folks have been working on their own screen capture protocol until something is standardized. Maybe ping drakulix in the screencast protocol proposal?
<any1>
cursor capturing is not just for VNC. It's also useful for RDP, Miracast and probably also some other things. Actually, a lot of the cursor stuff such as the position of the cursor isn't even needed for VNC, but some people wanted it included for some use-case of theirs
dcz_ has joined #wayland
<emersion>
VNC/RDP/Miracast, are all the same use-case
<emersion>
pq, what kind of setup cost are we talking about here?
<any1>
i509VCB: Do you have a link to that?
tzimmermann_ has joined #wayland
tzimmermann has quit [Ping timeout: 480 seconds]
tzimmermann_ has quit []
tzimmermann has joined #wayland
<emersion>
leandrohrb8: thanks for the mesa update, i'll have a look soon :)
rv1sr has quit [Remote host closed the connection]
rv1sr has joined #wayland
ybogdano has joined #wayland
devilhorns has quit []
MajorBiscuit has quit [Read error: Connection reset by peer]
<i509VCB>
Could it make sense to have the screen copy protocol provide a common "capture_surface" or something with a constructor to make it from a surface. Then a toplevel and workspace specific protocol could just return a capture_surface, but the constructors would differ?
<i509VCB>
Names pending bikeshed of course
immibis is now known as Guest2447
immibis has joined #wayland
<emersion>
protocols can't provide constructors for interfaces coming from other protocols
<emersion>
otherwise versionning is all messed up
<i509VCB>
Ok so it's a versioning pain outside of core protocol types
<emersion>
the core protocol is not special here
<emersion>
i'm not sure i fully understood your proposal
<emersion>
when you say "surface", do you mean literally wl_surface?
<i509VCB>
How come wl_buffer is okay for linux-dmabuf to create then?
<emersion>
wl_buffer is spec'ed to be stuck at v1
<emersion>
we could do that, but need to be careful
<i509VCB>
"surface" referencing an abstract description of a region being captured. Such as output, specific toplevel, workspace
<emersion>
mainly, we should use the object as an opaque handle, and not define any request/events on it besides destroy
<emersion>
that's a confusing use of surface
Guest2447 has quit [Ping timeout: 480 seconds]
<emersion>
each of the examples is made up of multiple source wl_surfaces
<emersion>
"source" may be a better name
<i509VCB>
Yeah source sounds better
drakulix[m] has quit [Quit: Reconnecting]
drakulix[m] has joined #wayland
drakulix[m] has quit []
drakulix[m] has joined #wayland
<emersion>
another way would be to have a capture_toplevel request in screencopy, taking an object from the other protocol
<i509VCB>
Hmm yeah that's an option
<i509VCB>
So the source would just recieve events describing what was captured?
<emersion>
the downside being that each source kind would need to be explicitly defined in screencopy
<i509VCB>
My idea was we would just have a destructor and capture request?
<i509VCB>
Everything else would be events?
<emersion>
i think there is a separate interface for that stuff
Leopold_ has joined #wayland
<emersion>
"session"
<i509VCB>
Specific capture options would be specified when the protocol object is created
<emersion>
if we go with a "source" interface stuck at v1, we can't add requests/events
<emersion>
if we go for capture_* requests, we don't need the "source" interface anymore
<i509VCB>
Would declaring that the compositor must support the source protocol at vX for vY of the toplevel capture protocol suffice? Or is it a hard line you won't cross?
<emersion>
that would end up being very messy
<drakulix[m]>
Is there any reason against a session type? Didn't you suggest that one on the MR yourself?
<emersion>
not clear what version you'd get in the end, can't ship a new screencopy version without bumping all other source protocols, etc
<i509VCB>
Essentially I am seeing if we can avoid duplicating the events 4 times
<emersion>
why would we need to duplicate?
<i509VCB>
How would the session type look in your mind specifically?
<i509VCB>
I might be missing some context
<emersion>
a session can be created from any kind of source
<emersion>
a session has the request to pass a buffer, and the events to know when the buffer is ready
<i509VCB>
So the session would depend on the source protocol objects
<emersion>
session = capture(source)
<i509VCB>
Ok
<i509VCB>
So the source would be opaque then
<i509VCB>
(or do I need more sleep)
<emersion>
it needs to, because it's stuck at v1
<emersion>
being stuck at v1 means we won't ever be able to add new requests/events
<emersion>
so the only safe way to do that is to have no requesr/event in the first place
<emersion>
any1: nah, an object, like wl_buffer
<emersion>
but unlike wl_buffer, don't make the mistake to define requests/events on it
<any1>
ahh, I see
<emersion>
the object only exists as a way to generically pass handles between protocols, without hardcoding anything
<emersion>
just like you can attach a wl_buffer coming from wl_shm or linux-dmabuf
<emersion>
on a wl_surface
<drakulix[m]>
So other protocols can define requests to create sources from whatever types and screencopy can accept any source to start the session, because source would be a completely opaque handle forever stuck at v1?
<emersion>
right
<emersion>
i'm not saying this is _the_ way to go, but it's _a_ way to do it
<any1>
Seems like a good idea
<drakulix[m]>
I mean it solves the problem of supporting ext_toplevel_info handles (whenever that gets merged) today and it also allows custom unstable extensions to use a common protocol (e.g. for capturing "workspaces"). Sure it is a little clunky, but if it works... I like it.
<emersion>
yeah, the upside is that other protocols can add as many sources as they want, without a need to update screencopy for these
<emersion>
the downside is that you get this extra object, so need to type more code in compositors
<any1>
But there would have to be a way to make a source out of wl_output. Maybe that can be part of ext-pixel-source-v1?
<emersion>
i'd just add this to screencopy itself
Nimr-alIslam has joined #wayland
<emersion>
if we wanted to use this concept of sources from somewhere else than screencopy, maybe it would make sense to split that in a separate protocol
<emersion>
but if not, we can keep things simple
<emersion>
pq, were there more downsides to interfaces stuck at v1 like wl_buffer?
<any1>
I always like to keep my units of abstraction small regardless...
devilhorns has joined #wayland
<i509VCB>
drakulix in smithay this would probably mean another family of get_dmabuf, read_shm_buffer like functions I believe?
<i509VCB>
Since we would be dealing with a source that could have some statically defined user data type
<drakulix[m]>
i509VCB: Not sure, I am following, the source is not a buffer as far as I am aware. (And not sure, if this is the right channel, if get into specifics for a potential implementation.)
Nimr-alIslam has quit [autokilled: This host violated network policy. Mail support@oftc.net if you feel this in error. (2022-10-05 18:17:27)]
<i509VCB>
Well not return a dmabuf, but instead the surface/output/workspace stored internally by the source user data on the server. It seems fine in my head, just a bit of inplementation detail
<drakulix[m]>
<i509VCB> "Well not return a dmabuf, but..." <- Possibly the source would not be a type implemented by the framework, but by downstream (for all variants they support). If object-safety is playing along this could even be just a trait.
tzimmermann has quit [Quit: Leaving]
Leopold_ has quit [Remote host closed the connection]
fmuellner has quit [Ping timeout: 480 seconds]
devilhorns has quit []
jmdaemon has joined #wayland
rv1sr has quit []
devilhorns has joined #wayland
robert_mader has quit [Quit: Leaving.]
dcz_ has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
mvlad has quit [Remote host closed the connection]