ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
ecloud has quit [Remote host closed the connection]
ecloud has joined #wayland
The_Company has quit []
<immibis> the_company, would that be wayland-yutani?
<immibis> the first person to call a wayland project yutani is going to get some chuckles
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
epony has quit [Remote host closed the connection]
jmdaemon has quit [Ping timeout: 480 seconds]
tawonga has joined #wayland
epony has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
jmdaemon has joined #wayland
tawonga has quit [Quit: WeeChat 4.0.1]
Brainium has quit [Quit: Konversation terminated!]
nerdopolis has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
carlos_ has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
<kchibisov> jadahl: I think I figured out what happens, but not sure who is at fault https://gitlab.gnome.org/GNOME/mutter/-/issues/2669#note_1790825
<kchibisov> I can say that what we're doing is sort of common though, with starting `xdg_toplevel::move`.
tawonga has joined #wayland
ahartmetz has quit [Ping timeout: 480 seconds]
tawonga has quit []
nerdopolis has joined #wayland
tawonga has joined #wayland
tawonga has quit []
tawonga has joined #wayland
tawonga has quit [Quit: WeeChat 4.0.1]
nerdopolis has quit [Ping timeout: 480 seconds]
epony has quit [Remote host closed the connection]
epony has joined #wayland
sima has joined #wayland
Plasm0duck has quit [Remote host closed the connection]
ManMower has quit [Remote host closed the connection]
ManMower has joined #wayland
fgdfgdfgd has quit [Remote host closed the connection]
fgdfgdfgd has joined #wayland
<wlb> weston/main: Daniel Stone * backend-wayland: Free pixel formats on shutdown https://gitlab.freedesktop.org/wayland/weston/commit/daac6fc91d1c libweston/backend-wayland/wayland.c
<wlb> weston Merge request !1315 merged \o/ (backend-wayland: Free pixel formats on shutdown https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1315)
epony has quit [Remote host closed the connection]
epony has joined #wayland
epony has quit [Remote host closed the connection]
tzimmermann has joined #wayland
epony has joined #wayland
Plasmoduck has quit [Quit: WeeChat 3.8]
rasterman has joined #wayland
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
epony has quit [Remote host closed the connection]
<wlb> weston Merge request !1318 opened by Daniel Stone (daniels) Clean up surface/view handling within desktop-shell https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1318 [Desktop shell]
epony has joined #wayland
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
cmichael has joined #wayland
fmuellner has joined #wayland
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
floof58 has quit [Quit: floof58]
floof58 has joined #wayland
gallo_ has joined #wayland
MrCooper has quit [Remote host closed the connection]
gallo has quit [Ping timeout: 480 seconds]
MrCooper has joined #wayland
<wlb> weston Merge request !1319 opened by Wujian Sun (wujiansun) Draft: Schedule connector disable for detached head for weston 11.0 https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1319
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
Dami_Lu has quit [Read error: Connection reset by peer]
MrCooper has quit [Remote host closed the connection]
rv1sr has joined #wayland
MrCooper has joined #wayland
tawonga has joined #wayland
<wlb> wayland-protocols Issue #152 opened by Mark Bolhuis (markbolhuis) xdg-decoration: No object vs set_mode client-side https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/152
<dv_> from what I see, the best way to show an application fullscreen on a specific display is to just pass a wl_output of the desired display to xdg_toplevel_set_fullscreen () ?
<pq> yup
tawonga has quit [Quit: WeeChat 4.0.1]
MrCooper has quit [Remote host closed the connection]
<dv_> but I don't know how to get the wl_output instances
<dv_> can this be done through XDG protocols?
<dv_> or is there a recommended protocol for this? I know there are multiple obsolete protocols in wayland by now
<emersion> wl_outputs are exposed as globals
MrCooper has joined #wayland
<dv_> through the registry_global_handler ?
<dv_> I mean, the `wl_registry_listener`'s `global` callback
MrCooper has quit [Remote host closed the connection]
<kennylevinsen> Yes, the same place you get all your other globals.
andyrtr has quit [Quit: ZNC 1.8.2 - https://znc.in]
andyrtr has joined #wayland
MrCooper has joined #wayland
floof58 has quit [Ping timeout: 480 seconds]
floof58 has joined #wayland
<wlb> weston/main: Philipp Zabel * frontend: Add tls-cert and tls-key config options https://gitlab.freedesktop.org/wayland/weston/commit/19a715b34848 compositor/main.c
<wlb> weston/main: Philipp Zabel * man: Document tls-cert and tls-key config options https://gitlab.freedesktop.org/wayland/weston/commit/3523de6b8fc6 man/ weston-rdp.man weston-vnc.man
<wlb> weston Merge request !1307 merged \o/ (frontend: Add tls-cert and tls-key config options https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1307)
floof58 has quit [Quit: floof58]
floof58 has joined #wayland
<wlb> weston/main: Simon Ser * clients/simple-dmabuf-egl: do not block until rendering completes https://gitlab.freedesktop.org/wayland/weston/commit/0349f152698e clients/simple-dmabuf-egl.c
<wlb> weston/main: Simon Ser * clients/simple-dmabuf-feedback: do not block until rendering completes https://gitlab.freedesktop.org/wayland/weston/commit/8c4128df5d16 clients/simple-dmabuf-feedback.c
<wlb> weston Merge request !1304 merged \o/ (clients/simple-dmabuf-{egl,feedback}: do not block until rendering completes https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1304)
<wlb> weston Merge request !728 merged \o/ (libweston: Decouple dbus helper to public namespace https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/728)
<wlb> weston/main: Christopher Obbard * libweston: Decouple dbus helper to public namespace https://gitlab.freedesktop.org/wayland/weston/commit/9e36620be7f5 include/libweston/dbus.h libweston/dbus.c libweston/launcher-libseat.c libweston/launcher-logind.c
<wlb> weston/main: Christopher Obbard * libweston: Split dbus support into seperate build option https://gitlab.freedesktop.org/wayland/weston/commit/463ebda4e43c libweston/dbus/dbus.c libweston/dbus/meson.build include/libweston/meson.build libweston/meson.build meson_options.txt
<emersion> oops, i let through a bad apple when doing wayland-devel moderation :/
<emersion> sorry about that
* emersion too used to accept anything that's not clearly spam
<emersion> maybe we can just ban this person?
tawonga has joined #wayland
epony has quit [autokilled: This host violated network policy and has been banned. Mail support@oftc.net if you think this is in error. (2023-07-14 11:13:52)]
nerdopolis has joined #wayland
<dv_> hmm. so, I want to have an underlying video stream (through GStreamer's `waylandsink`) and a surface with LVGL controls painted in it on top, as an overlay. that overlay surface is translucent wherever there are no LVGL controls.
<dv_> the common way to do that is to write an application that creates one toplevel window and hosts subsurfaces inside I guess.
<dv_> but, in this case, the video stream comes from one process, and the LVGL controls come from another process.
<dv_> is this still doable with subsurfaces?
<dv_> or can the kiosk shell be used for this purpose by now?
<pq> dv_, cross-process is not doable.
<pq> you'd need a special-purpose compositor for that
<dv_> and I can't have two fullscreen windows, right?
<dv_> one as overlay of the other?
<pq> correct
<dv_> damnb
<dv_> perhaps I could patch weston for this somehow
<pq> why are they separate processes to begin with?
<dv_> it is unfortunate that I can't maximize a window on a specific wl_output
Company has joined #wayland
<dv_> that would solve it I think
<pq> no, it wouldn't
<wlb> weston Merge request !1316 merged \o/ (hmi-controller: Do not call hmi_controller_destroy() from _create() https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1316)
<wlb> weston/main: Philipp Zabel * hmi-controller: Do not call hmi_controller_destroy() from _create() https://gitlab.freedesktop.org/wayland/weston/commit/1ffcc535ef5d ivi-shell/hmi-controller.c
<dv_> why not? if I maximize two windows on top of each other, on the same wl_output, I get what I want
<dv_> and this is an existing project where UI controls and video output are done by two separate components already - changing that now is not feasible
<pq> but you couldn't control who is on top
<kennylevinsen> And only the top one would be visible
<dv_> isn't there a z value for this?
<dv_> hang on, I remember having done this in the past
<pq> no z value that you could control from outside of the compositor
* dv_ looks
<dv_> ah, yeah, I had to patch weston back then to explicitly move the "video" surface to the bottom of the stack
<pq> if you cannot merge the two client processes, then you need a special-purpose compositor that knows the special window management rules you need
<pq> patching Weston sound like a possibility indeed
<kchibisov> I think the only protocol allowing z order is layer-shell.
<kennylevinsen> You could do with less than a full compositor if you import all your buffers into one of the processes, or into a third process.
<pq> I'm kinda guessing this is not a desktop use case at all, and the said patched weston could just run on DRM, which might be the quickest to get to work.
<dv_> right - this runs on an imx8m plus
<dv_> I did a vaguely similar project about a year ago, which is where I did patch weston to do what I said with the video surface. the UI there was done with Qt's QML, with a translucent borderless maximized window.
<dv_> here, the added difficulty is that I now have 2 screens attached, and for each one of them, there needs to be a video surface and a UI window overlayed on top
<dv_> the third process does sound interesting, but would require significant refactoring
<pq> Is Qt not able to embed a GStreamer "widget" without causing copies or loss of direct scanout?
<dv_> I tried that in the past, but this is potentially problematic, since then, all of the heavy weight compositing is 100% done by the GPU's 3D core
<dv_> which can be suboptimal performance-wise
<pq> I very much meant avoiding the GPU
<dv_> (this is specific to imx, which has the rather slow vivante GPUs)
<dv_> I am not aware of Qt supporting direct scanout like this
<pq> all it needs is a sub-surface
<pq> waylandsink might even be creating a sub-surface itself
<pq> I'm not sure
<dv_> passing on subsurfaces did not work well the last time I tried. but, note that Qt was used in that past project. it is _not_ used in this new one.
<dv_> this new project uses LVGL for its UI controls.
<pq> I've never heard of LVGL before.
<dv_> but, hmm - perhaps I can adjust its wayland driver to allow for passing a subsurface into it
<dv_> but, ah, no, subsurfaces only work within the same process
<pq> or more like getting the window's wl_surface out, so you can ask Gst waylandsink to nest in that?
<pq> yes, everything is always same-process, same connection
<dv_> nesting only works with subsurfaces, does it?
<pq> I'm suggesting to use waylandsink from inside the UI process
<pq> nesting?
<dv_> <pq>or more like getting the window's wl_surface out, so you can ask Gst waylandsink to nest in that?
<pq> you have to look into the Gst API which way it works
<dv_> I was asking in general that "nesting" a surface into another surface is only possible through subsurfaces, right? there is no other mechanism?
<pq> you can also write your own Gst plugin to get the dmabuf and handle the Wayland side yourself, if nothing existing seem to suit
<pq> right, for a single window, sub-surfaces are the way
<dv_> hm okay. so, my options are:
<pq> you could have multiple windows, like popups or related dialogs, but that's not really fitting here I think
<dv_> 1. customize weston to allow for maximizing windows on specific wl_outputs, with video surfaces always being put at the bottom
<pq> strike "allow for", you can simply force it
<dv_> 2. establish some form of IPC between the processes to send frames (ideally with dma-buf) to the process that runs the UI controls and place waylandsink in there to show these frames
<pq> and you can identify windows by app_id I think
<pq> if you are going to patch weston, you don't need the controls window maximized anymore either, you can just make weston put it where you want it
<dv_> the added complication here is that I have to use NXP's weston fork :(
<pq> I'm sorry.
<dv_> which hopefully is less crappy in version 10
<dv_> the 8.x fork was awful
<pq> that IPC could be Wayland, too
<dv_> I'm even considering pipewire atm, since the source frames come from a V4L2 capture
<pq> oh, that sounds good
<pq> so, why is the video thing in a separate process?
<pq> why not use Gst straight from the UI process?
<dv_> this project was not started by me. they made it that way because initially they sent frames through a named pipe to the UI process.
<dv_> I guess they wanted to fully establish separation of concerns and such.
<dv_> ah, nah, wait, strike that. confused it with a different detail.
<pq> what is that video process doing? Presumably more than just getting frames from V4L2 and sending to the UI process?
<dv_> no, so far, they just rendered without weston, straight to KMS, and the whole overlay thing is marked as a TODO
<dv_> it is doing color correction
<dv_> but at this point I do agree that at least splitting this pipeline into multiple parts is the way to go
<pq> yes, you cannot have multiple processes driving KMS planes on the same device at the same time - yes, I know some vendors did that by hacking the kernel to allow it
<pq> separation of concerns is nice, if the concerns are actually separable
<dv_> okay. I'll propose these changes to the others.
<dv_> on a sidenote, isn't this kind of use case a rather commonly found one? UI done by one process, video by another?
<dv_> I though this is part of why the kiosk shell exists
<daniels> pH5: your weston pipelines are failing because shared runners are disabled for your fork - any reason in particular?
<pq> dv_, kiosk-shell only forces whatever single window is on top to be fullscreen. It doesn't combine multiple clients into a single app.
eroc1990 has quit [Ping timeout: 480 seconds]
<dv_> true, but to me, it sounds like it would be a natural improvement for the kiosk shell
<dv_> to allow for easy VCR style overlays even with multiple processes
<dv_> or does anything design wise speak against that idea
<dv_> ?
<pq> dv_, it's not possible to combine multiple clients into a single app in general, because the rules of positioning each window depend on the use case. You need to be able to modify the window management rules as well. For that, the idea for Weston is "Lua shell".
<pq> the only design decision speaking against that is the desktop paradigm - you don't do that on desktops. But since this is not about desktops, it doesn't apply.
<pq> it's just a lack of interfaces to let you easily script what you need
<dv_> but do you use a kiosk shell on desktops?
<dv_> and, lua shell, interesting
<pq> kiosk-shell not a regular desktop, but I guess it would be described as a special desktop lacking multi-app support.
<daniels> right, kiosk-shell is there for the usecase of fullscreen apps and nothing else
<pq> A desktop kind of implies that you can open and see multiple apps at the same time.
<dv_> I associate flexible window arrangements and user driven navigation through said windows with "desktop"
<pq> and kiosk-shell only shows one app per output at a time
<pq> yes
<pq> kiosk-shell has none of that
<dv_> 2 maximized/fullscreen surfaces on top of each other, without the user being able to arrange them at all, that is not desktop
<dv_> so I guess what I am referring to is a "kiosk+"
eroc1990 has joined #wayland
<pq> Lua shell is still just a concept, but the idea is that you script your window manager a lot more easily than hacking on C code
<dv_> are there any known projects ongoing that aim to implement something like that? or have these been abandoned or not even started, instead focusing on the lua shell concept?
<dv_> I'm making notes for something I could potentially work on in the future, hence that question
<dv_> because this is not the first time I've had this usecase, and I strongly suspect I'm not alone with this
Lennon_ has quit [Quit: Lost terminal]
<pq> I only know about Weston, and the plan there is Lua shell.
<pq> all the details in that issue are probably outdated, but that would be the ticket to follow
<pq> dv_, daniels might be able to tell you more about Lua shell if you're interested in maybe developing it.
nerdopolis has quit [Ping timeout: 480 seconds]
Kerma has joined #wayland
<pH5> daniels: I hit not-enough-privileges in runner-gating.sh when I enable it. I think disabling runners was a partial attempt to disable those CI failures, I got distracted by something else.
<daniels> pH5: oh right - fixed now
<kennylevinsen> Heh, not enough? "You need to collect at least 10 privileges to open this door!"
MrCooper has quit [Remote host closed the connection]
kts has joined #wayland
<dv_> daniels: the concept of lua-shell sounds interesting. but no proof of concept exists yet?
MrCooper has joined #wayland
<pH5> daniels: ty
<pH5> kennylevinsen: the error message did not specify the required amount :)
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
pieguy128 has joined #wayland
Guest5815 has quit [Remote host closed the connection]
MrCooper has quit [Remote host closed the connection]
Kerma has quit []
MrCooper has joined #wayland
kts has quit [Quit: Konversation terminated!]
MrCooper has quit [Remote host closed the connection]
cmichael has quit [Quit: Leaving]
MrCooper has joined #wayland
mtretter is now known as mtr[afk]
mtr[afk] is now known as mtretter
<wlb> weston/main: Philipp Zabel * libweston: Add output parameter to weston_renderer::flush_damage() https://gitlab.freedesktop.org/wayland/weston/commit/155fa3a56a72 libweston/ compositor.c libweston-internal.h noop-renderer.c pixman-renderer.c renderer-gl/gl-renderer.c
<wlb> weston/main: Philipp Zabel * renderer-gl: only flush damage for surfaces used in the next output repaint https://gitlab.freedesktop.org/wayland/weston/commit/a401a1b247c7 libweston/renderer-gl/gl-renderer.c
<wlb> weston Merge request !1312 merged \o/ (Add output parameter to renderer->flush_damage() and use it in the GL renderer https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1312)
<emersion> jadahl: hm, so, we discussed with d_ed about whether window geometry would make sense for layer-shell, and as a result i have a xdg-shell question for you
<emersion> on one hand, the window geometry is defined as the "visible bounds"
<emersion> on the other hand, it's defined as being used for aligning/constraining/etc the surface
<emersion> so, what would be the proper window geometry for, say, weston-flower
<emersion> let's say i want weston-flower to snap to the edge of the screen, but not exactly at the flower's edge: i want to leave a bit of transparent margin
<emersion> let's say a compositor implements window border snapping, i want other windows to snap at weston-flower, but with a bit of transparent margin
<emersion> with that in mind, what is the proper window geometry for weston-flower? exactly match the flower border? or leave a bit of space?
<emersion> (the "real" use-case would not be weston-flower, but a macOS-style dock)
<emersion> basically: is the "visible bounds" a suggestion, or a requirement?
<leon-p> emersion: btw thanks for working on this again. Probably super annoying with all the nitpicks and different opinions, mine included. So just wanted so say that your efforts on this are appreciated!
<emersion> <3
jmdaemon has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
tzimmermann has quit [Quit: Leaving]
heapify has joined #wayland
heapify has quit [Quit: heapify]
heapify has joined #wayland
heapify has quit [Quit: heapify]
heapify has joined #wayland
<jadahl> emersion: I'd say having an invisible margin around weston-flower within the "window geometry" is "fine" if the intention is to pretend that is the intended "window". don't know how the dock in macosx works though, haven't used a mac for a decade so my memory is blurry
<jadahl> the shadow is "visible" so using a strict interpretation of "visible bounds" is already wrong
<emersion> jadahl: basically it displays a bunch of icons on the bottom of the screen, and maximized windows stop some distance away from the icon edges
<emersion> https://elementary.io/ has a similar dock
<jadahl> using an enlarged window geometry seems fine for that. having to add padding and margin sounds annoying
<emersion> okay
<jadahl> you'll end up with DOM+CSS if you don't stop at the door :P
<emersion> aha
<emersion> well, the question was whether we'd re-use this in layer-shell, or whether we'd use a separate concept
<jadahl> I guess that is the alternative? a separate padding/margin?
<emersion> yeah, something decoupled from xdg_surface.set_window_geometry's semantics
<jadahl> can you think of any reason why just using the window geometry would not work?
<emersion> well, i am not sure it is the right tool for the job
<emersion> are we mis-using or abusing it?
<jadahl> true
<jadahl> or using it? not sure
<emersion> also, set_window_geometry cannot go outside the bounds of the surface tree
<jadahl> panel padding is not the original intention, I guess, but it's also a rather trivial piece of data. "inside is mine, outside is fluff"
<jadahl> true, that is perhaps an issue
<emersion> in the dock case, the space above the dock might not be the surface
<jadahl> then you'd need to enlarge the surface too. a bit ugly
<emersion> yeah, wouldn't be the end of the world
<emersion> i wonder if there are more pathologic cases
<jadahl> solid pixel of 0,0,0,0
<emersion> :D
<jadahl> are there any situations where you want to have some things align to a "inner" margin, and some other to an "outer"?
<jadahl> e.g. you want "window geometry" to be as small as possible (e.g. touch the edge for weston-flower), and some other things touch the enlarged one only?
<emersion> hm
<emersion> i can't think of anything right now, but will keep thinking
heapify has quit [Quit: heapify]
<jadahl> did anyone take notes from the call some days ago btw? I missed it
heapify has joined #wayland
heapify is now known as Guest5994
heapify has joined #wayland
Guest5994 has quit [Ping timeout: 480 seconds]
heapify has quit [Quit: heapify]
ybogdano has quit [Remote host closed the connection]
ybogdano has joined #wayland
_DOOM_ has joined #wayland
<_DOOM_> Is there any reason why, as a client, we wouldn't want to use libwayland-server?
<jadahl> a client using libwayland-server to act as its own wayland server to some other client is perfectly supported
<orowith2os> _DOOM_ as *just* a client, it's not useful
<_DOOM_> Not even for that
<_DOOM_> I mean there are some useful stuff in there I mean.
<orowith2os> if you're doing something like gamescope, where you're a client of a compositor and a server to some other app, you'd want to use it
<orowith2os> huh
<_DOOM_> wl_signal, wl_listener, wl_event_loop.
<_DOOM_> I feel like even as just a client these are pretty useful.
<_DOOM_> I guess I was just wondering if for some reason libwayland-client and libwayland-server are somehow incompatible. I guess I was just checking for unknown unknowns.
natewrench has joined #wayland
natewrench has left #wayland [#wayland]
natewrench has joined #wayland
natewrench has left #wayland [#wayland]
<orowith2os> _DOOM_ aren't the two structured differently, and have different ways of representing stuff? Rereading some bits of the docs, libwayland-server has a more server-like way of doing things, libwayland-client is structured better for the client-side of things?
<_DOOM_> I've looked at the code.
<_DOOM_> They don't appear to represent things differently in code.
<_DOOM_> Although I understand what you mean.
<orowith2os> the protocol that's specified seems pretty different for both ends
<_DOOM_> you mean the wayland protocol itself?
<orowith2os> yeah
<_DOOM_> Well yeah.
<_DOOM_> But I still don't think that discounts the usefullness of wl_signal, wl_listener, and wl_event_loop for a client.
<emersion> libwayland-server is not supposed to be a generic utility/event loop library
<_DOOM_> I know
<_DOOM_> Why shouldn't I use those structures if it isn't going to breaking things though?
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
jess has joined #wayland
_DOOM_ has quit [Quit: WeeChat 4.0.2]
i509vcb has joined #wayland
_DOOM_ has joined #wayland
bodicceaII has quit [Ping timeout: 480 seconds]
bodiccea has joined #wayland
sima has quit [Ping timeout: 480 seconds]
_DOOM_ has quit [Quit: WeeChat 4.0.2]
bodiccea has quit [Read error: Connection reset by peer]
bodiccea has joined #wayland
bodiccea_ has joined #wayland
bodiccea has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
ahartmetz has joined #wayland
rv1sr has quit []
Cyrinux94 has quit []
Cyrinux94 has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
cool110 has joined #wayland
cool110 is now known as Guest6007
Guest6007 has quit [Remote host closed the connection]
cool110_ has joined #wayland
cool110_ is now known as Guest6008
nerdopolis has joined #wayland
Guest5828 has quit [Ping timeout: 480 seconds]
tent405 has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
tent405 has quit [Ping timeout: 480 seconds]
ahartmetz has quit [Quit: Konversation terminated!]
ahartmetz has joined #wayland
natewrench has joined #wayland