ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
Ermine has quit [Read error: Connection reset by peer]
Ermine has joined #wayland
jmdaemon has joined #wayland
wargreen has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
cool110_ has joined #wayland
cool110 has quit [Remote host closed the connection]
<republic83>
I do not show the needed form in sports, it's not like I am entire outsider but... By hand the compiler can be written again also, it's nested hw structures, and little bit of playing with different operand buffers, I am capable of writing the whole compiler too. It's not very huge problem.
republic83 was kicked from #wayland by ChanServ [You are not permitted on this channel]
Leopold_ has quit [Remote host closed the connection]
<pq>
emersion, yes please, do post changes to presentation-time extension instead of taking the liberty of silently sending events that are clearly against the wording. This seems to be another example of abusing low-level mechanics for something it was not intended, just because it happens to work on anything you tried with.
dcz_ has quit [Ping timeout: 480 seconds]
<pq>
what's misleading in presentation-time for fixed refresh rate?
<pq>
The quoted sentence is definitely about VRR and not about headless.
<pq>
it is also about things like USB displays that transmit whatever they have bandwidth for, meaning they take variable times for different updates
<MrCooper>
pq: I think he meant misleading as in: If the client workload doesn't allow hitting the next refresh cycle anyway, the client can't just use the presentation-time feedback refresh value for its simulation time, similar to how it can't just use what wlroots sends there with VRR
<pq>
MrCooper, well, if it doesn't hit the next, then it may hit the next after. But yes, there is a very strong assumption that clients are able to complete drawing in less than one refresh period for optimal results.
<pq>
The design for presentation-time is: draw on frame callback, use presentation-time feedback to estimate when that drawing will be shown.
<pq>
And if a compositor delays sending frame callbacks, it makes clients more likely to miss their expectations.
<pq>
but also reduce latency for super-fast clients
<pq>
Any more smart timings like a client delaying its own start of drawing are simply left for other extension or future additions to take care of.
<pq>
That's all it was designed for, and it still seems to achieve that design goal, and no further.
<emersion>
i should probably just give up on the whole security thing
<emersion>
all clients can use privileged protocols and i should just leave it at that
<emersion>
zzag: you wouldn't be interested in security by any chance?
<d_ed[m]>
on the KDE side we are interested in finding something
<d_ed[m]>
but it's not definite in any direction, using the cgroup of the connection owner is also on the cards
<emersion>
i see (that's not something i'll be implementing)
<emersion>
i'll just close that MR saying that no consensus could be found
<emersion>
pq, i don't have the resources to discuss the VRR stuff any more
<jadahl>
emersion: IIRC the last time I looked, what I didn't like was that every piece of metadata was undefined without any way to discover what it may mean without googling around hopefully finding documentation defining things elsewhere.
<jadahl>
d_ed[m]: how does crash recovery and reconnecting work with !68 btw?
<d_ed[m]>
We would have to pass FDs to our long-lasting helper and restore them
<qyliss>
jadahl: what's the alternative? encoding every sandbox mechanism that could possibly exist into the spec?
<d_ed[m]>
it'd be more code, but doable
<d_ed[m]>
(probably, I haven't implemented !68)
<d_ed[m]>
Or maybe a oneliner in flatpak to look for a different FLATPAK_WAYLAND_DISPLAY first and then have the helper implement the server side of !68
<d_ed[m]>
client side it'd make no difference
<pq>
emersion, good, because presentation-time was simply not designed for VRR. It only acknowledges VRR enough to step out of the way and say "I don't know".
<emersion>
i have no intention to change my compositor, fwiw
<pq>
as usual
<pq>
just don't go telling people that presentation-time as-is can be used for something it was never meant for
<pq>
if someone wants to use it for new things, they can propose the protocol version bump to let it happen
<MrCooper>
emersion: a problem with wlroots' behaviour is that the client may incorrectly assume there's a fixed refresh rate, and extrapolate based on that
<MrCooper>
(incorrectly but legitimately, based on the spec)
<pq>
If something is unspecified, we can argue which way it should be, but when it's explicitly written down as "must be zero", there is really no excuse to do something else.
<MrCooper>
agreed
<pq>
We know a lot more about frame scheduling today than we did at the time presentation-time was designed, so protocol development should continue to explicitly incorporate and define new things. The old interface is just not enough.
<swick[m]>
emersion: I'm just not convinced that we can safely accept on a listening fd provided by the client. For me that's the blocking thing and I need a clear explanation of why it is safe to do. I also don't really have the time to dick into it far enough to provide that explanation myself.
<emersion>
sigh
<swick[m]>
I know...
<swick[m]>
d_ed: looking up the cgroup from a connection is just as racy as looking up anything else
<swick[m]>
I have a kernel patch laying around for pidfd support which can be used to get rid of the race but then the question becomes: what are you going to do with the cgroup?
<swick[m]>
I guess it gives you the same information as the !68 right now
<swick[m]>
but it is very linux specific
<emersion>
i think your comment about /dev/fd/ was about BSDs
<emersion>
the re-open trick only works on Linux
<emersion>
but:
<emersion>
- i don't care about clients changing flags, i care about BSDs
<emersion>
- you don't care about non-Linux, and you care about clients changing flags
<emersion>
so we're all good?
<swick[m]>
mh, maybe
ahartmetz has joined #wayland
<swick[m]>
like I said, I can't tell if this is sufficient to be safe
<emersion>
i don't understand what you request
<swick[m]>
that's the problem: I'm not sure. it seems risky and I don't know enough to say this is fine.
<swick[m]>
with pidfd+cgroup I'm at least reasonable sure that it's safe
<emersion>
it's not the same kind of safety issue
<emersion>
we're talking about safety against clients outside of sandboxes here
<emersion>
which can echo malware >>~/.bashrc anyways
<emersion>
switching flags is the least of my worries
<swick[m]>
I'm not going to nack anything here fwiw
<MrCooper>
emersion pq: for VRR, an interval in which the next refresh may happen might work, instead of a single value
<pq>
perhaps, I'm not sure how I'd use it in a client
<swick[m]>
we're not even getting things right for FRR right now yet everyone talks about VRR :s
fmuellner has joined #wayland
<jadahl>
qyliss: outsource it to the document that was added and if you want some super special secret sandbox engine then just spell it out how that it's not limited to the documented cases
<qyliss>
but the document is already there?
<qyliss>
or by last time you looked, did you mean before the document was added?
<emersion>
sandboxes are just like app_ids
<jadahl>
qyliss: the document is there, but protocol documentation doesn't mention it, and just effectively makes everything undefined
<emersion>
we don't have a registry for app_id
<jadahl>
that's not really true
<emersion>
from my PoV it is
<pq>
which statement?
<kennylevinsen>
I don't think we currently have a trend of documenting used identifiers (e.g. app_id), but we could make example uses and suggest possible ways to derive them
nerdopolis has joined #wayland
<kennylevinsen>
the document with some extra detail also lives right by the protocol, so it's not hard to find
<jadahl>
kennylevinsen: it's not easy to find unless you're browsing the git repo, which I wouldn't say is the or should be the primary way one consumes protocol documentation
<jadahl>
kennylevinsen: even an app id has more meaning (it should map to a .desktop file)
<jadahl>
but sandbox engine is completely opaque, while the current way it is used in compositors that actually use sandbox app ids it adds various extra meaning to e.g. the toplevel app id
<kennylevinsen>
yeah for xdg_shell's set_api it may (but does not have to) match the id from a desktop entry
<kennylevinsen>
I think similar suggestion would be fine here
zvarde198830320677919168 has quit [Quit: Ping timeout (120 seconds)]
zvarde198830320677919168 has joined #wayland
<kennylevinsen>
re: doc location, if we start to have docs beside xml files it should be in distro packages as well, so ti'll be for every way you browse protocols
<kennylevinsen>
not just git
<kennylevinsen>
jadahl: if we do something similar to xdg_shell (which suggests a way to set it, and suggests compostior use), would that be enough without a registry of values?
<kennylevinsen>
if we end up having docs beside protocols, we could (should?) probably also have them visible there
<jadahl>
kennylevinsen: plain suggestions makes it useless for flatpak which needs an actual specification how to use it
<kennylevinsen>
but that's no different than xdg_shell's app_id though?
<kennylevinsen>
why is this different?
<jadahl>
what do you mean? I can't really see the similarity
<jadahl>
the sandbox engine gives meaning to the metadata passed, and when it has meaning, compositors can use the metadata for anything other than dumb opaque grouping, e.g. finding .desktop files, looking up entries in the permission store, etc
<kennylevinsen>
A primary purpose for the compositor would be similar to that of xdg_shell's app_id, yes?
<kennylevinsen>
i.e., identify and group applications
<kennylevinsen>
(possibly now also permission store stuff as it can be trusted)
<jadahl>
without specified meaning to the metadata, it's not really useful for anything other than being able to know that clients "inside" that sandbox can't themself open new security contexts
<kennylevinsen>
xdg_shell's set_app_id suggests the use of the desktop entry specification. It does not - and cannot - require that it comes from there, as not all xdg_toplevels have .desktop files in the first place.
<kennylevinsen>
it does make a demand for d-bus activatable applications
<kennylevinsen>
("For D-Bus activatable applications, the app ID is used as the D-Bus service name.
<kennylevinsen>
would specification to the same extend be sufficient? I believe app_id's worked fine so far?
<kennylevinsen>
maybe with the addition that it should be persistent and unqiue, to specifically cater to the permission thing
<jadahl>
kennylevinsen: if you define/suggest what 'app_id' means, how does that help if it's more strictly specified for a sandbox engine? and how would you document instance id?
<jadahl>
app_id from xdg-shell is quite unreliable, so wouldn't say it's a very good success story, but that's primarily a client issue I guess
<qyliss>
Instance ID might as well be opaque, right? It's just a way to identify that two instances of the same application are in different sandboxes.
<kennylevinsen>
it is fine if a sandbox engine choses to define formats more strictly as it choses the value, protocol should just be as strict as needed to serve the purpose.
<kennylevinsen>
I'm not sure I fully follow the intent or need for instance_id
<kennylevinsen>
we definitely need a few more words in the spec as to what it is for
<jadahl>
qyliss: for the protocol everything is opaque, but for flatpak, instance ID has meaning
<qyliss>
kennylevinsen: instance ID is important because if I have two instances of the same application open, I want to be able to identify that
<qyliss>
think about a Qubes-like system where different instances get differently coloured window decorations, for example
<qyliss>
"work" and "personal" instances of Firefox, or something
<qyliss>
jadahl: right, yeah. to do anything useful with instance ID apart from treating it as an opaque token you'd need sandbox-specific integration.
<jadahl>
yes, and what is insisted on is that the specificatioun not should define or link to sandbox specific documentation
<qyliss>
gotcha
<qyliss>
imo it would make sense to link to the docs
<qyliss>
specifications have non-normative stuff in them all the time
<kennylevinsen>
"The sandbox engine may further specify the format and meaning of the (application|instance) id."?
<kennylevinsen>
linking to flatpak from documentation that flatpak devs reference to implement the protocol and write the docs would be a bit weird and... cyclic. :P
<kennylevinsen>
maintaining an unofficial list is an option, but suggesting that the sandbox engine devs should provide the info seem fine?
<qyliss>
oh yeah
MajorBiscuit has joined #wayland
Company has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
dnk has quit [Remote host closed the connection]
dnk has joined #wayland
<wlb>
wayland Issue #382 opened by Veldora (Veldora) "Error 71 (Protocol error) dispatching to Wayland display" - when moving thunderbird from monitor with low scaling (e.g. 100 %) to monitor with higher scaling (e.g. 125 %). https://gitlab.freedesktop.org/wayland/wayland/-/issues/382
<emersion>
MrCooper: 8-bit formats have an _SRGB variant in vulkan, which transparently encodes/decodes
<emersion>
for other formats you need to manually do the encoding/decoding in a shader
<emersion>
so, when rendering to a non-8-bit format, you need to have a second subpass to encode to sRGB
nerdopolis has joined #wayland
wargreen has joined #wayland
<MrCooper>
I see
<pq>
emersion, it sounds like you intend to do color transformations after blending? But for blending you would first need to get everything into a single common colorspace. How do you envision that working?
<emersion>
it's easy to add color operations before blending
<pq>
ok, so just not highlighted in the post, cool
<emersion>
yes, it's something we already have
rv1sr has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
<wlb>
wayland Issue #382 closed \o/ ("Error 71 (Protocol error) dispatching to Wayland display" - when moving thunderbird from monitor with low scaling (e.g. 100 %) to monitor with higher scaling (e.g. 125 %). https://gitlab.freedesktop.org/wayland/wayland/-/issues/382)
<Company>
I had another thought wrt yesterday's discussion about threaded rendering in GTK
<Company>
we have a Cairo renderer in GTK
<Company>
so I can prototype the Wayland parts without having to think about GL
<Company>
and easily do the "make the render thread hand off the wl_buffer to the main thread" thing for example
<Company>
also, the Cairo renderer is slower, so the gains are more visible, yay!
<d_ed[m]>
FWIW, Qt has threaded GL rendering. We might be able to help if you have specific questions or need a reference implementation.
jmdaemon has quit [Ping timeout: 480 seconds]
ahartmetz has quit [Remote host closed the connection]
emery has joined #wayland
dnk has quit [Remote host closed the connection]
kts has joined #wayland
pochu has quit [Quit: leaving]
tzimmermann has quit [Quit: Leaving]
gusnan has quit [Read error: Connection reset by peer]
gusnan has joined #wayland
gspbirel56873 has quit []
gspbirel56873 has joined #wayland
dcz_ has joined #wayland
rv1sr has quit [Ping timeout: 480 seconds]
cmichael has quit [Quit: Leaving]
MajorBiscuit has quit [Ping timeout: 480 seconds]
cath has quit [Remote host closed the connection]
abcdw has quit [Remote host closed the connection]
rosefromthedead has quit [Remote host closed the connection]
tommybomb has quit [Remote host closed the connection]
ogromny has quit [Read error: Connection reset by peer]
moses has quit [Read error: Connection reset by peer]
cpli has quit [Remote host closed the connection]
kchibisov has quit [Read error: Connection reset by peer]
tsujp has quit [Remote host closed the connection]
elibrokeit has quit [Remote host closed the connection]
rpigott has quit [Remote host closed the connection]
txtsd has quit [Remote host closed the connection]
leon-p_ has quit [Remote host closed the connection]
sumoon has quit [Remote host closed the connection]
c7s has quit [Remote host closed the connection]
kennylevinsen has quit [Remote host closed the connection]
WhyNotHugo has quit [Remote host closed the connection]
ifreund has quit [Read error: Connection reset by peer]
kindablue has quit [Remote host closed the connection]
dnkl_ has quit [Remote host closed the connection]
novakane has quit [Remote host closed the connection]
kchibisov has joined #wayland
cath has joined #wayland
leon-p has joined #wayland
cpli has joined #wayland
ogromny has joined #wayland
dnkl has joined #wayland
WhyNotHugo has joined #wayland
kennylevinsen has joined #wayland
moses has joined #wayland
tommybomb has joined #wayland
tsujp has joined #wayland
abcdw has joined #wayland
txtsd has joined #wayland
novakane has joined #wayland
rpigott has joined #wayland
rosefromthedead has joined #wayland
sumoon has joined #wayland
c7s has joined #wayland
ifreund has joined #wayland
elibrokeit has joined #wayland
kindablue has joined #wayland
rv1sr has joined #wayland
dnk has joined #wayland
kts has quit [Quit: Konversation terminated!]
republic83 has quit [Quit: Quit]
gspbirel56873 has quit []
gspbirel56873 has joined #wayland
rederick29 has joined #wayland
kts has joined #wayland
kts has quit [Quit: Konversation terminated!]
floof58 has quit [Read error: Connection reset by peer]
iomari891 has quit [Ping timeout: 480 seconds]
floof58 has joined #wayland
sima has quit [Ping timeout: 480 seconds]
rv1sr has quit []
rederick29_ has joined #wayland
rederick29_ has quit []
mvlad has quit [Remote host closed the connection]
rederick29_ has joined #wayland
rederick29 has quit [Ping timeout: 480 seconds]
dcz_ has quit [Ping timeout: 480 seconds]
jmdaemon has joined #wayland
Brainium has joined #wayland
floof58 is now known as Guest1172
floof58 has joined #wayland
Guest1172 has quit [Ping timeout: 480 seconds]
dnk has quit [Remote host closed the connection]
pyromancy has quit [Quit: pyromancy]
i509vcb has joined #wayland
nerdopolis has quit []
nerdopolis has joined #wayland
rederick29_ has quit [Remote host closed the connection]
Net147 has quit [Quit: Quit]
Net147 has joined #wayland
BenjaminBreeg has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
jmdaemon has joined #wayland
cuolarrrrrrrrrrrrrrrrrrrrrrrrr has joined #wayland