neonking has quit [Remote host closed the connection]
neonking has joined #wayland
neonking has quit [Remote host closed the connection]
txtsd has quit [charon.oftc.net liquid.oftc.net]
andyrtr has quit [charon.oftc.net liquid.oftc.net]
pounce has quit [charon.oftc.net liquid.oftc.net]
eck has quit [charon.oftc.net liquid.oftc.net]
rails[m] has quit [charon.oftc.net liquid.oftc.net]
mtretter has quit [charon.oftc.net liquid.oftc.net]
pounce has joined #wayland
ali_moh has joined #wayland
ali_moh has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-07 02:26:38)]
klltkr has joined #wayland
khfeng has joined #wayland
diacritica[m]1 has joined #wayland
diacritica[m]1 has quit [Remote host closed the connection]
the_rat_ has joined #wayland
the_rat_ has quit [Remote host closed the connection]
blue__penquin has joined #wayland
shankaru1 has joined #wayland
klltkr has quit [Ping timeout: 480 seconds]
khfeng has quit [Remote host closed the connection]
khfeng has joined #wayland
DrNick has quit []
hardening has joined #wayland
DrNick has joined #wayland
danvet has joined #wayland
letoram19 has joined #wayland
letoram19 has quit [Remote host closed the connection]
tomke has quit [Remote host closed the connection]
dvim has joined #wayland
dvim has quit [Remote host closed the connection]
Kray has joined #wayland
Kray has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-07 06:58:26)]
andyrtr has joined #wayland
rgallaispou has joined #wayland
tomke has joined #wayland
pnowack has joined #wayland
eck has joined #wayland
dlaflamme has joined #wayland
dlaflamme has quit [Remote host closed the connection]
yoslin has quit [Quit: WeeChat 3.1]
yoslin has joined #wayland
<pq>
tomke, specifying the protocol dependency happens by saying so in the MR description.
<tomke>
ok, thanks! I've done that :)
<tomke>
pq, when you find some time please have a look if my MRs make sense
<pq>
tomke, no promises, sorry. I've even forgot what the conclusion from our discussion was.
<tomke>
we discussed this approx 2 months ago and I've finally got IP rights for drawing a rect so I'm at liberty of sharing it :)
<pq>
haha, cool :-)
<pq>
if possible, I'd like to defer this to others, I'm not alone maintaining here (I hope!)
<tomke>
sure, by all means do so, the more the merrier
<tomke>
I'm not an expert on those things so I'd appreciate some feedback
<emersion>
tomke, i don't understand the wayland protocol
<emersion>
and the place for a use-case-specific protocol would be in the client
co3umbarius has joined #wayland
<emersion>
and in the compositor, vendored
<pq>
emersion, the protocol is the only way to create a buffer, that when painted, produces pixels of color (0, 0, 0, 0). If that's what you're asking?
<emersion>
hm. so a solid color protocol of some sort?
<emersion>
the description doesn't read this way
<pq>
yes, but not just solid color
co2umbarius has quit [Ping timeout: 480 seconds]
<pq>
well, it's a punch-through hole (which as a concept would need more explaining, I agree)
<pq>
the aim to have a sub-surface that is both opaque and 100% see-through.
<emersion>
that really doesn't seem useful for generic wayland clients
<pq>
yeah
<emersion>
this seems like an embedded specific protocol
<pq>
it could still be EXT, right?
<emersion>
opaque and see-through…?
<soreau>
click-on but see-through
<soreau>
alpha = 0, input = 1(?)
<pq>
yes, that "conflict" cannot be realized by anything in existing protocols, hence a new extension is needed
<emersion>
soreau, doesn't seem related to input events
<emersion>
otherwise you could just use set_input_region
<pq>
the client wants to paint an area with (0,0,0,0) *without* blending.
<pq>
but setting the opaque region does not guarantee no-blending
<emersion>
and the compositor magically puts something under it?
<pq>
yeah.... that's the catch
<emersion>
that sounds like a pretty bad protocol tbh
<pq>
or maybe it's not even the compositor controlling the hw plane underneath
<emersion>
ehhh
<pq>
maybe it's some video passthrough? but tomke can explain what he needs this for :-)
<emersion>
now that also sounds like a KMS API mis-use
<pq>
yup
<tomke>
sorr, I was updating the commit message
<tomke>
so the idea behind this:
<tomke>
embedded platforms ofen have video underlay instead of overlay
<emersion>
i remember something about weird hw drivers where the producer needs to directly attach its stream to the KMS plane, or something
<emersion>
but please, keep that off of wayland-protocols
<tomke>
in order to actually see a video content the graphics plane mus have some transparent pixels
<emersion>
potential for mis-use is just too high
<pq>
emersion, why keep that off wayland-protocols? Wasn't the EXT category for this stuff?
<emersion>
EXT wasn't meant for hacks
<emersion>
platform-specific hacks
<pq>
and we have the protocol extension adoption site, where all major compositors and toolkits can say "we will never support this", so people will know. ;-)
<emersion>
wayland-protocols is supposed to ensure *some* protocol quality
<tomke>
Weston paints everything starting with opaque background and then adds more stuff using Porter-Duff SRC OVER so all pixels remain opaque
<emersion>
"this is just magic undefined stuff" isn't that
<tomke>
not really, no
co4umbarius has joined #wayland
<pq>
emersion, I think this proposal just needs a lot more documentation about why, how, and where. <- tomke
<pq>
then we can discuss if it's appropriate
<emersion>
even with docs, this still looks like a massive hack
<emersion>
but yeah, maybe it'll help
<tomke>
it's a fairly simple see-through rect to add some transparent pixels to the graphics plane
<pq>
tomke, awful hacks often are simple, so that's not a justification ;-)
<tomke>
pq, fair point :)
<pq>
there should be some use case for it that does not involve violating e.g. KMS UAPI design
co3umbarius has quit [Ping timeout: 480 seconds]
<tomke>
Weston supports a number of hardware planes, but there's always a base plane that's entirely opaque
<pq>
like maybe you have a video processing hardware block beyond what the KMS driver controls, controlled by e.g. a V4L2 driver, and you really want to have those (0,0,0,0) pixels in the KMS FB.
<emersion>
that sounds like a Weston issue now
<pq>
yes, that one is a weston issue
<pq>
there is an idea how to make Weston use underlays automatically, automatically creating the punch-through as needed
<pq>
but that also cannot work for the hardware arrangement I described above with a non-KMS driver beyond
<emersion>
yeah, the punch-through hole should be completelycontrolled by the compositor, not by clients
<tomke>
Weston uses a valid design assuming typical PC architecture with video overlay
<pq>
tomke, weston never meant to be limited to PC architecture
<tomke>
Client needs to specify the "video" surface dimensions
<emersion>
why?
<emersion>
can't the client just draw transparent pixels?
<tomke>
because the Wayland way of specifying surface dimensions is bu attaching a wl_buffer to it
<emersion>
then weston knows by *magic* what the size of the underlay is
<pq>
I'm having a huge deja vu here, so it would have been really nice to summarize the IRC discussion from couple month back first. :-)
<pq>
we're just repeating it all now
<emersion>
alright, i'll wait for a summary then
<tomke>
attaching a regular buffer with (0,0,0,0) pixels works like adding a transparent film over an opaque background
<tomke>
it doesn't make the graphics any less opaque
<emersion>
that's because of the weston issue
<pq>
emersion, no, that's because what Wayland defines.
<tomke>
No, that's how alpha-blending is meant to work
<emersion>
wayland doesn't say that outputs have an opaque background
<pq>
emersion, don't we have fullscreen protocol explicitly adding an opaque backgrop?
<pq>
*drop
<tomke>
No, I think it's Weston's design decission to always start with an opaque background and add more layers over it
<emersion>
pq, that's specific to xdg-shell fullscreen
<emersion>
and also
<pq>
emersion, what other fullscreen do we have?
<emersion>
it doesn't say "it must be black"
<emersion>
it says "a neutral color, e.g. black"
<emersion>
"transparent" would work too
<tomke>
there's a speciall fullscreen shell but it can only do one client at a time
<tomke>
so not good
<pq>
emersion, eh... now you're just bending words
<pq>
it's meant to be opaque, exactly to *stop* seeing through it what might lie below
<emersion>
with border fill covering the rest of the output. The content of the border fill is undefined, but should be assumed to be in some way that attempts to blend into the surrounding area (e.g. solid black).
<tomke>
not intentionally, i really don't know that much about this stuff
<emersion>
pq, the intention is that the other windows underneath aren't painted
<emersion>
but there's nothing said about a mandatory solid black clear color
<pq>
emersion, and the underlay is one of those underneath windows
<emersion>
the underlay isn't a window
<pq>
who cares, the whole point pf that protocol feature is to stop it from showing.
<emersion>
it's a magic platform-specific thing
<emersion>
no, the protocol only mentions the "surface tree"
<emersion>
hm, "other screen content"
<pq>
taking a few steps back, there is no Wayland spec saying one way or another about the transparency of an output or "surface tree" or whatever, IIRC
<emersion>
yeah
<pq>
the point of the punch-through is to emulate an overlay with an underlay or with external hardware, AFAIU
<emersion>
well, w/e. just write up the docs, and we'll see
<emersion>
but that still sounds like a terrible idea to me
<tomke>
then a red "video player" with moving video subsurface
<tomke>
and bouncing ball and triangle on top
<tomke>
the video plane is underneath the graphics plane
<pq>
right, and just like discussed last time, this is something that weston should be able to do on its own without any punch-through protocol extensions.
<tomke>
and it's visible because of hte alpha-cutout buffer that basically replaces a rectangular area of creen with (0,0,0,0)
<pq>
...assuming the usual "single KMS devices controls the monitor"
<pq>
*device
<tomke>
I don't have any driver KMS at all
<pq>
how can you use weston at all then? :-)
<tomke>
sure, as you can see
<pq>
how?
<tomke>
I've added a custom backend
<pq>
aha
<pq>
so, all this what we have discussed again, would be necessary background information for the MRs to be able to evaluate them.
<tomke>
should I put it in the MR comment?
<tomke>
or do you have some other preferred place?
<pq>
in the descrioptions
<tomke>
ok
<pq>
If this protocol extension cannot even be used in Weston without your custom backend (which I assume is not upstreamable?) then that undermines the justification to have it upstream.
<pq>
knowing such details is crucial in reviewing the proposal
<pq>
As you can see, I can *imagine* IMO reasonable justification for the proposal, but if that is not real, then there's no point.
<emersion>
can always be standardized once there's a real reason for it to be
<pq>
yeah
<glennk>
tomke, is the cutout rectangle something set for the hardware so it skips reading data from surfaces above the video underlay in that rectangle entirely?
<emersion>
i don't think so…
soreau has quit [Ping timeout: 480 seconds]
<tomke>
no
<tomke>
it's just a transparent hole in the grapghics plane
<tomke>
if you draw a small window over that hole the window will partially cover the video plane
<tomke>
50% translucent window will show as 50% graphics over 50% video content from hardware underlay
<tomke>
all windows under the hole (in Z-order) including the backgrond are completely painted over
<tomke>
all windows above the hole (in Z-order) are drawn as usual and may conver some/all of the hole
<tomke>
it's like layers in Photosop
<glennk>
so the hardware pipe is two planes, one video underlay, and a framebuffer where weston is painting all its surfaces onto?
<tomke>
exacty, video at the bottom, and graphics above
agd5f has quit [Read error: Connection reset by peer]
agd5f has joined #wayland
<tomke>
any parts of the framebuffer that are transparent show the video "layer" using Photoshop-speak
<tomke>
Currently all pixels in the framebuffer are completely opaque
<glennk>
basically the thing you want is for a given surface to paint using porter-duff SRC rather than OVER to be able to fill with a translucent key color
<glennk>
?
<tomke>
yes
<tomke>
that's exactly whe the MR does
Artem3-t has joined #wayland
Artem3-t has quit [Remote host closed the connection]
<glennk>
tomke, as far as i can tell the MR is not actually doing what i described, instead it is adding a special surface type that only exists virtually, and contains 0,0,0,0, rendered by the weston paint pipeline
<glennk>
what i mean is for an arbitrary surface to be composited using SRC by setting blend mode on that surface from the client, the client for instance clears the data to 0,0,0,0, then weston composites that surface using SRC instead of OVER
<tomke>
can this be done now?
<tomke>
if that's the case the MR is not needed
<tomke>
I've jus updated MR description, so hopefully it will be somewhat clearer why I wrote it
<glennk>
no, similarly requires a protocol extension to add the blend mode, the main advantages i see are A: probably more generally useful outside of your specific use case, and B: more efficient in terms of hardware fill rate overall
<tomke>
not sure about the fill rate, either client or compositor has to do the same job
<glennk>
the client can bake it into its other rendering, and weston has one less surface to composite
<glennk>
also client may not have to repaint itself each frame
<tomke>
ah, I see
<tomke>
it doesn't do that now
<tomke>
only resize triggers repaint
<glennk>
another possibility i could see would be an optional protocol for converting the opaque surface hint into an actual mandate, and weston would use SRC for it
<tomke>
otherwise it's pointless to keep attaching identical cut-outs
<tomke>
I'm not sure I follow with the opaque hint, my understanding is that it's supposed to ignore alpha even if present
DrNick has quit [Ping timeout: 480 seconds]
<pq>
The opaque region right now is a hint that the alpha channel on that area can be assumed to be 1.0, and a compositor is free to use that information any way it wants. It's not a straight proxy for blending mode, although that is often the end effect.
<pq>
Controlling blending mode is an idea, but it's less direct than a "make me a punch-through buffer".
<pq>
blending mode control dips into the direction of mechanism while on Wayland we try to emphasize intent
<Levans>
+
<glennk>
i can buy into that argument
<pq>
good points, though
<glennk>
i think i like punch through surface a bit better than alpha cutout, since its affecting color data as well as alpha
<glennk>
as a complete aside, i have a vague memory of seeing a prototype display with a real alpha channel somewhere
<tomke>
my old LCD alarm clock has one ;)
<tomke>
I was thinking of adding a non-0 alpha but I couldn't find good enough justification for it
<glennk>
a key color might be useful for some old video hardware?
<tomke>
the last thing I saw with this technology was an old VHS camera...
dpzmick8 has joined #wayland
dpzmick8 has quit [Remote host closed the connection]
<tomke>
it's trivial to add to the MR - just pass RGBA alongside with and height
<glennk>
my .02 cents would be yagni and v2 protocols are cheap :-)
<tomke>
that was my approach too
<pq>
tomke, a good thing to explain in MRs is "what do you need to test this for real".
<glennk>
i've heard test cases can do such things
<pq>
Like weston test suite? That's going to be tough. :-)
co4umbarius has left #wayland [#wayland]
<tomke>
Would something like glReadPixels() do?
<tomke>
(not that I know anything about weston test suite)
<pq>
At most you could read back (0,0,0,0), not the underlay contents.
<pq>
The test framework does have screenshooting, but IIRC it assumes opaque pixels, might not even read back alpha at all.
<pq>
That is fixable, but getting the underlay not really.
<tomke>
you wouldn't be able to read video pixels from the underlay using CPU
<pq>
Instead, we would need to use writeback connectors of VKMS to take the screenshot.
<glennk>
the scope of the test i had in mind would only check that the framebuffer gets the punch through pixel values in the correct region
<pq>
which means we also need buffers that are suitable for VKMS planes, i.e. from VGEM
<glennk>
the existence of an underlay plane would be outside of scope for the code in this MR
<pq>
VGEM and writeback screenshots are in development, but I'm not sure VKMS has multiple planes yes
<tomke>
not on embedded system
<pq>
*yet
<pq>
after you have all that, then you still have the problem of how to get a buffer on the underlay
<pq>
solution to that is basically to not use punch-through protocol at all, but let weston come up with the underlay configuration and the hole on its own.
<tomke>
I'd really stop at graphics plane containing transparent pixels as this is the extent of this MR
<pq>
glennk, yeah, that would confirm the immediate effect of the protocol, but not for things like KMS still using XRGB pixel format, meaning its opaque anyway.
<glennk>
pq, well, you could limit the test check for now to just check rgb data equaling punch out color
<pq>
I was kind of asking, what does one need to see this extension in action for real, actually seeing stuff like in tomke's video.
<pq>
getting it tested in CI is another matter
<tomke>
perhaps RPi can do similar thing
<tomke>
I havent tried but it should have video underlay
<pq>
which is exposed by the FOSS KMS driver just like all planes, right?
<tomke>
and a graphics feeder does does the alpha-blending
<tomke>
I have no idea
<pq>
so you would need Weston to set content on the underlay plane...
<tomke>
yup
<pq>
...which is exactly what your proposal avoids and works around :-)
<tomke>
yes
<tomke>
well, Weston in cooperation with the client, both using a non-existing extension for making video surfaces on RPi
<glennk>
one real world use case i have seen in the wild were on set top boxes where decoded video was blended on scanout and not accessible by the CPU
<tomke>
yes
columbarius has joined #wayland
<tomke>
sometimes it's not available to GPU either
<tomke>
hence the separate video pipeline and hardware blending
<glennk>
good point, the hardware i was thinking of didn't have a gpu
wCPO2 has joined #wayland
wCPO2 has quit [autokilled: spambot. Dont mail support@oftc.net with questions (2021-06-07 11:37:35)]
<pq>
on such set-top boxes, even still the protected video would go through Weston. We have the extensions for HDCP and to not even try to look at the pixels.
<tomke>
yes, any video, however protected, would still be playable this way on Weston by a wayland video client
<tomke>
as long as Weston backend can sychronise video posion on the underlay with framebuffer updates
<tomke>
I'll add this to the MR description as this is a good point that I missed
<pq>
I think this is a good to not need the punch-through protocol extension.
<pq>
*a good reason
<pq>
if the video goes through Weston, then Weston will have all the information needed to create any holes on its own, when it assingns KMS planes
<pq>
and if the video happens to be below other surfaces in the scenegraph to begin with, then there is no need to punch-through anything
<tomke>
how would you handle video window resize?
<pq>
atomic KMS
<tomke>
as in dragging a corner of the video player window to make it bigger/smaller
<pq>
yes
<tomke>
so how the client sends "I want this size from now on" message to the compositor?
<pq>
every update to the video image, be it simply update or a resize, is explicitly sent via Wayland and processed refresh by refresh.
<pq>
just like all Wayland apps: it does wl_surface.attach and commit with a buffer of the new size.
<pq>
if necessary, using sync'd sub-surface to keep the player decorations and video in sync.,
<pq>
works also with protected buffers that the compositor cannot read
<tomke>
what buffer? you didn't want a punch-through one
<pq>
the video buffers
<tomke>
but those are not available
<pq>
we are assuming that video goes through Weston
<pq>
protected buffers' *content* is not available, but the buffer handles are.
<pq>
metadata is well available, just not be pixels
<tomke>
not for me
<pq>
ok, that is more things for you to explain :-)
<pq>
IOW, you are saying that the video is *not* going through Weston.
<pq>
in that case I understand the need of punch-through driven from the client, as Weston is not in control of the video at all
<pq>
and synchronization becomes a problem
<tomke>
I can do this for unprotected buffers and use GPU (or 2D blitter sould I fancy wrinting a new renderer)
<pq>
I'm afraid I've lost which use case we are even talking about.
<pq>
What I meant with all the above, the set-top box use case in general has no need to punch-through protocol extension, not even with protected buffers.
<pq>
But maybe there is a different use case, also on set-top boxes?
<tomke>
assuming protected content I can split video pipeline between 2 processes so that one decodes and feeds data through the video pipeline
<tomke>
while the other controls presentation (i.e. position and scale in sync with framebuffer updates)
<pq>
oh! please explain that in the MRs, that is not at all obvious
<tomke>
ok, but after the meeting
<pq>
and is fundamental to understand the use of the protocol extension
<tomke>
sure thing, looks like I've been doing embedded stuff for too long :)
<pq>
Unless said otherwise, people tend to assume the standard KMS model where you have a single process responsible for everything on a display.
shankaru1 has quit []
blue__penquin has quit []
blue__penquin has joined #wayland
actatux has joined #wayland
actatux has quit [Remote host closed the connection]
<tomke>
ok, desc updated
<tomke>
here also single process controls everything on a display
<tomke>
compositor is supposed to post framebuffer updates in sync with video position/size updates
<tomke>
so that the cutout is always aligned with video content
<tomke>
client just feeds video data into the pipeline
<pq>
but standard KMS has no such concept of "feeding video data" externally
rails[m] has joined #wayland
txtsd has joined #wayland
mtretter has joined #wayland
<tomke>
pq, so KMS system could potentially use your solution
<tomke>
send video buffers without CPu/GPU touching the content
<pq>
yeah, because every video frame goes explicitly through Weston, so Weston manages the KMS state vs. content, but Weston itself does not necessarily need access to content.
<tomke>
and feed those buffers to the video plane in backend
<tomke>
yes
<tomke>
but is a bit of a different use case
<pq>
Right. Streams use case (name from EGLStreams; just connect the pipes and magic happens) does not exist in upstream DRM AFAIK.
<tomke>
(reading in a hurry about EGLStreams)
<emersion>
anything with streams makes it complicated to synchronize buffer content updates with state updates
<pq>
tomke, EGLStreams has been pretty much rejected as a design.
<pq>
only NVIDIA implements it
<emersion>
… and they're in the process of implementing what everybody else uses
<emersion>
(DMA-BUFs, GBM, etc)
shankaru1 has joined #wayland
jgoody has joined #wayland
jgoody has quit [Remote host closed the connection]
<tomke>
after a very quick skim I think it's nothing like EGLStreams
<tomke>
for starters you don't see or care for buffers
<zzag>
emersion: that sounds really promising. in kwin, we have an issue where restarting compositing can be break existing streams (the consumer texture gets destroyed during restart). tying client buffers to opengl context is not a really good idea!
rachelfish has joined #wayland
rachelfish has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-07 14:08:29)]
<tomke>
in pq's system individual video frame goes into Weston and backend draws punch-through and places the frame on a video underlay
<tomke>
in my MR a place-holder buffer goes into Weston and backend draws punch-through hole and positions/scales video to align
<tomke>
the actual video frames travel to the video underlay through side channel (hardware pipeline) bypassing Weston
<pq>
it doesn't matter what you call the "buffer" that weston gets, it's not the real buffer, and Weston doesn't get one every video frame... does it?
<tomke>
no, one everytime there's a change to video or window dimensions
<pq>
ok, so it's half-way between upstream model and streams model.
<tomke>
so possibly just one - at startup
<pq>
so the sink for your video stream, when it gets a resize, will it also wait for Weston to ack the resize before it continues with the new sized video?
<tomke>
yes
<tomke>
otherwise it would fall apart
<pq>
ok - indeed
soreau has joined #wayland
<pq>
nothing like that exists in upstream DRM I believe, so this is all a big surprise to people
sca has quit []
erc has quit [Ping timeout: 480 seconds]
soreau has quit [Remote host closed the connection]
soreau has joined #wayland
<tomke>
yes, and the 3D driver is not a full drm driver either, it does have dma-buf and prime support, but that's about it
<tomke>
hence custom backend because i couldn't use the drm one
evulish has joined #wayland
gwizon has joined #wayland
evulish has quit [Remote host closed the connection]
gwizon has quit [Ping timeout: 480 seconds]
AJ_Z0 has quit []
AJ_Z0 has joined #wayland
andreas has joined #wayland
andreas has quit []
tom has joined #wayland
columbarius has quit [Quit: columbarius]
columbarius has joined #wayland
tom has quit []
hir0pro has joined #wayland
hir0pro has quit [Remote host closed the connection]
hir0pro has joined #wayland
hir0pro has quit [Remote host closed the connection]
hir0pro has joined #wayland
columbarius has quit [Quit: columbarius]
columbarius has joined #wayland
columbarius has quit []
columbarius has joined #wayland
shankaru1 has quit []
bch18 has joined #wayland
bch18 has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-07 15:27:59)]
shankaru1 has joined #wayland
ViCi has joined #wayland
ViCi has quit [Remote host closed the connection]
blue__penquin has quit []
<emersion>
daniels: got around to finishing my wlroots dmabuf-hints impl
jiqiren has joined #wayland
jiqiren has quit [Remote host closed the connection]
abstruse has joined #wayland
abstruse has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-07 17:14:33)]
co1umbarius has joined #wayland
jn__ has joined #wayland
jn__ has quit [Remote host closed the connection]
columbarius has quit [Ping timeout: 480 seconds]
erc has joined #wayland
khfeng has quit [Ping timeout: 480 seconds]
rtyler has joined #wayland
rtyler has quit [Remote host closed the connection]
Moorwen has joined #wayland
Moorwen has quit [Remote host closed the connection]
DrNick has joined #wayland
<daniels>
emersion: awesome!
tzimmermann has joined #wayland
vihta has joined #wayland
vihta has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-07 18:43:03)]
hir0pro_ has joined #wayland
tigermousr has joined #wayland
tigermousr has quit [Remote host closed the connection]
hir0pro has quit [Ping timeout: 480 seconds]
hir0pro_ has quit []
hir0pro has joined #wayland
gwizon has joined #wayland
gwizon has quit [Remote host closed the connection]
sunarch has joined #wayland
hir0pro has quit [Quit: hir0pro]
klltkr has joined #wayland
dullin has joined #wayland
dullin has quit [Remote host closed the connection]
tzimmermann has quit [Quit: Leaving]
klltkr has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
klltkr has joined #wayland
klltkr has quit []
klltkr has joined #wayland
klltkr has quit []
klltkr has joined #wayland
klltkr has quit []
klltkr has joined #wayland
klltkr has quit []
sunarch_ has joined #wayland
sunarch_ has quit []
sunarch has quit [Ping timeout: 480 seconds]
solarsparq has joined #wayland
solarsparq has quit [Remote host closed the connection]
tdeo has quit [Remote host closed the connection]
danvet has quit [Ping timeout: 480 seconds]
matze has joined #wayland
matze has quit [Remote host closed the connection]
Seirdy0 has quit []
Seirdy has joined #wayland
caipora has joined #wayland
caipora has quit [Remote host closed the connection]
amahl has joined #wayland
amahl has quit [Ping timeout: 480 seconds]
shankaru1 has quit []
doppo_ has joined #wayland
doppo_ has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-07 22:19:02)]
hardening has quit [Ping timeout: 480 seconds]
rdorsch has joined #wayland
rdorsch has quit [Remote host closed the connection]
Arnavion has quit [Quit: Arnavion]
lad has joined #wayland
lad has quit [Remote host closed the connection]
Arnavion has joined #wayland
LexDolgov-t has joined #wayland
LexDolgov-t has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-07 23:06:05)]
pnowack has quit [Quit: pnowack]
co2umbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
co3umbarius has joined #wayland
co2umbarius has quit [Ping timeout: 480 seconds]
co4umbarius has joined #wayland
co3umbarius has quit [Ping timeout: 480 seconds]
fahien has quit [Quit: Ping timeout (120 seconds)]
leandrohrb has quit [Quit: Ping timeout (120 seconds)]