ChanServ changed the topic of #wayland to: | 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]
kts has quit [Quit: Leaving]
adia has joined #wayland
fmuellner has joined #wayland
manuel_ has joined #wayland
Lucretia has quit [Read error: No route to host]
Lucretia has joined #wayland
manuel_ has quit [Ping timeout: 480 seconds]
<wlb> weston/main: Emre Ucan * ivi-shell: listen output_created signal ivi-shell/ ivi-layout-private.h ivi-layout.c
<wlb> weston/main: Emre Ucan * ivi-shell: listen output_destroyed_signal ivi-shell/ ivi-layout-private.h ivi-layout.c
<wlb> weston Merge request !1030 merged \o/ (ivi-layout: listen output events
<heeen> what are the tty related settings in weston systemd service files for
tzimmermann has joined #wayland
<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> heeen, this seems to be somewhat related:
d42 has quit []
* heeen clicks
<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.
<heeen> on device we are using
<heeen> export QT_WAYLAND_CLIENT_BUFFER_INTEGRATION=linux-dmabuf-unstable-v1
<wlb> weston/main: Daniel Stone * tests: Explicitly use desktop-shell for text-test tests/text-test.c
<wlb> weston/main: Daniel Stone * tests: Use test-desktop-shell more widely tests/ bad-buffer-test.c event-test.c keyboard-test.c linux-explicit-synchronization-test.c plugin-registry-test.c pointer-test.c presentation-test.c roles-test.c subsurface-test.c surface-global-test.c surface-test.c touch-test.c viewporter-test.c xwaylan
<wlb> weston/main: Daniel Stone * tests: Use weston-test-desktop-shell by default tests/ weston-test-fixture-compositor.c weston-test-fixture-compositor.h
<heeen> export QT_QPA_PLATFORM=eglfs
<wlb> weston Merge request !1046 merged \o/ (tests: Use test-desktop-shell more widely
<pq> I was thinking more like Plymouth or such.
<pq> I don't know how it would handle CONFIG_VT=n.
<heeen> does eglfs imply fbdev
<pq> it definitely should not
<pq> EGL + fbdev is an unholy union that might exist only on some proprietary driver stacks.
<pq> and I'd hope those days are long gone, too, but who knows
<heeen> fwiw we are on etnaviv
<pq> if you use upstream/FOSS, you're safe :-)
<MrCooper> pq: I remember running into that issue with Xorg a long time ago, pressed Ctrl-C in the X session and it killed Xorg :)
<MrCooper> or maybe startx/xinit
<pq> heh
Consolatis_ has joined #wayland
Consolatis is now known as Guest413
Consolatis_ is now known as Consolatis
Guest413 has quit [Ping timeout: 480 seconds]
<wlb> weston Merge request !1050 opened by Marius Vlad (mvlad) ivi-shell: Missing removal of destroy listener and desktop-shell UAF [IVI shell]
<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!]
sav10 has quit []
kts has joined #wayland
kts has quit [Quit: Leaving]
cnsvc has quit [Ping timeout: 480 seconds]
devilhorns has quit []
cnsvc has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
<wlb> wayland-protocols/main: Demi Marie Obenour * xdg-shell: Replace an HTTP link with HTTPS stable/xdg-shell/xdg-shell.xml
<wlb> wayland-protocols/main: Demi Marie Obenour * xdg-shell: Add specific errors stable/xdg-shell/xdg-shell.xml
<wlb> wayland-protocols/main: Demi Marie Obenour * xdg-shell: window menus are optional stable/xdg-shell/xdg-shell.xml
<wlb> wayland-protocols/main: Demi Marie Obenour * Add xdg-shell.unresponsive error stable/xdg-shell/xdg-shell.xml
<wlb> wayland-protocols Merge request !120 merged \o/ (Add specific errors for xdg_shell
kts has joined #wayland
ybogdano has joined #wayland
<wlb> wayland-protocols Merge request !173 opened by Jonas Ådahl (jadahl) build: Bump version to 1.28
<wlb> wayland-protocols/main: Jonas Ådahl * build: Bump version to 1.28
<wlb> wayland-protocols Merge request !173 merged \o/ (build: Bump version to 1.28
AJ_Z0 has quit [Quit: I have to return some videotapes]
tlwoerner_ has joined #wayland
AJ_Z0 has joined #wayland
MaxbackNov2nd[m] has quit []
<wlb> Merge request !46 opened by Jonas Ådahl (jadahl) releases: Add wayland-protocols 1.28
floof58 is now known as Guest431
Max1 has joined #wayland
floof58 has joined #wayland
<wlb> Merge request !46 merged \o/ (releases: Add wayland-protocols 1.28
<wlb> Jonas Ådahl * releases: Add wayland-protocols 1.28 releases.html
tlwoerner has quit [Ping timeout: 480 seconds]
<Max1> Is there a `#define`d constant that tells me what version of an interface is included in the Wayland headers?
Guest431 has quit [Ping timeout: 480 seconds]
<emersion> there is no #define, but there is a field
<emersion> XXX_interface.version
<emersion> XXX_interface is a `struct wl_interface`
<Max1> Hmm, that might be enough. Thanks!
Company has joined #wayland
ybogdano is now known as Guest432
Guest432 has quit [Read error: Connection reset by peer]
ybogdano has joined #wayland
kts has quit [Ping timeout: 480 seconds]
slattann has joined #wayland
slattann has quit []
AJ_Z0 has quit [Ping timeout: 480 seconds]
AJ_Z0 has joined #wayland
nurupo has quit [Quit:]
nurupo has joined #wayland
mvlad has quit [Remote host closed the connection]
fmuellner has quit [Ping timeout: 480 seconds]
jlaunay has left #wayland [#wayland]
luc4 has joined #wayland
fmuellner_ has joined #wayland
ybogdano has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
fmuellner_ has quit [Ping timeout: 480 seconds]
jlco_ has quit []
fmuellner has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
jlco has joined #wayland
jlco has quit []
jlco has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
luc4 has quit [Ping timeout: 480 seconds]
sav10 has joined #wayland
sav10 has quit []
sav10 has joined #wayland
Major_Biscuit has quit [Ping timeout: 480 seconds]
Ampera has quit [Quit: Like a fart in an elevator, my transgressions are soon forgotten]
Ampera has joined #wayland
sav10 has quit [Remote host closed the connection]
dcz_ has quit [Ping timeout: 480 seconds]
jmdaemon has joined #wayland
danvet has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
floof58 has quit [Remote host closed the connection]
floof58 has joined #wayland
luc4 has joined #wayland
floof58 has quit [Remote host closed the connection]
floof58 has joined #wayland
hardening has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
rv1sr has quit []
ybogdano has joined #wayland