ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
ErrorNoI1ternet has quit [Remote host closed the connection]
nerdopolis has quit [Ping timeout: 480 seconds]
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
<i509vcb>
swap c and z
<DemiMarie>
https://github.com/CuarzoSoftware/Louvre claims to use the CPU and GPU more efficiently than Sway or Weston, and their benchmarks appear to show Sway using the GPU very inefficiently.
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
<fluix>
I'm curious about the FPS claims: is it saying wlroots rendering can drop to half the refresh rate (when there's lots of moving surfaces)?
<fluix>
kind of odd that it also only happens between... 2-19ish and 25+ surface
<kchibisov>
it's kind of odd that both weston and sway dropped to exactly 30 fps.
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
<kchibisov>
I'd assume it's because renderer can't make it in time, so it waits for next vblank?
<DemiMarie>
exactly @_oftc_kchibisov:matrix.org
<DemiMarie>
(also which Matrix room are you using?)
<kchibisov>
I don't use matrix.
NepNepdmsalwaysopen[m] is now known as NepNep[m]
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
privacy has joined #wayland
tzimmermann has joined #wayland
rv1sr has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
pstch has joined #wayland
<pstch>
hi there
<pstch>
what is the preferred protocol now to ensure that input to other clients is inhibited ? there is wlr-input-inhibitor-unstable-v1 (implemented in sway), but it's been deprecated in favor of a session locking protocol
sima has joined #wayland
sevz17 has quit [Quit: WeeChat 4.1.1]
<pstch>
I'm trying to design some form of secure password prompt, in an overlay layer-shell surface with a transparent background
<soreau>
is a transparent background secure if sensitive information could potentially show through?
<leon-p>
whether your surface gets keyboard focus is compositor policy
<leon-p>
you could watch for keyboard enter/leave events and maybe indicate in the UI whether your surface has focus
bim9262 has joined #wayland
leon-anavi has joined #wayland
qaqland is now known as Guest7309
qaqland has joined #wayland
mvlad has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
Guest7309 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
<pq>
DemiMarie, Weston definitely has (had? there has been some very recent work on the area) damage handling bugs that cause excessive texture uploads from wl_shm buffers which is definitely expensive.
<MrCooper>
emersion: heh, "that's not the issue" and then goes on to describe what could be explained by that issue :/
<pq>
Like, a simple surface move can cause a texture re-upload even without any damage. Would be worth re-testing on latest RC release, I think.
<pq>
Louvre has written a benchmark I have wanted to see for years. :-)
<Ermine>
Looks interesting
<pstch>
leon-p: well it is compositor policy if there is no protocol that provides it, but there were proposals for input inhibition
<pstch>
soreau: I mean secure as "the password cannot be stolen" not "hiding other screen contents"
<pq>
pstch, IOW, a globally modal dialog.
<pstch>
leon-p: yes I've looked at that :) but I'm afraid that its focus could be stolen by other apps
<pstch>
pq: yes and no, as I also want to dim the background (everything other than the dialog), and prevent other apps from stealing focus (by opening a new window)
<pq>
that's a globally modal dialog, indeed
<pstch>
dimming the background is to prove to the user that we are not an impersonating app, as fullscreen windows can't show a transparent background
<soreau>
so says the spec, hehe
<pq>
There is also the concern of an app locking out the user from their machine by displaying a globally modal dialog, which even without any malice can be annoying (cannot rearrange other windows in order to see what you want to answer the dialog). This is usability trade-off.
<pstch>
because of that, I think I need to use layer-shell, and combine that with the upcoming security-context protocol
<pstch>
pq: yes I've thought of that, but it's not a problem in my case
<pq>
ok
<pstch>
ah but maybe I'm wrong in thinking that I need input inhibition..
<pstch>
if I display a surface using layer-shell, in 'overlay', and no other app can use layer-shell, then no other app can steal the focus, right ?
<pq>
pstch, you mean you have a plan how to disallow random apps from using your dialog for random things?
<pstch>
pq: yes
<pstch>
all other apps would be sandboxed in that case, using a combination of kernel namespaces and wayland's security-context protocol
<pq>
cool
<pq>
A much more Wayland'y design would be to have an extension saying "This window is a passphrase input dialog." than trying to piece together a new use case from existing extensions that were perhaps never meant to be used that way. After all, Wayland design aims for policy, not mechanism, as much as possible.
<soreau>
I typically think input inhibiting in terms of compositor bindings. If you have something bound to KEY_A and that's part of the password or unlock sequence, input inhibition can be convenient
<pstch>
I'm just not sure how I can ensure that during the execution of the password prompt no other app can have access to input events (e.g. by stealing focus)
<pq>
OTOH, if you're just making an ad hoc system off what you happen to have, it's fine.
<soreau>
but also, what if you want to grab a new keybinding and ignore all compositor bindings from getting in the way?
<pstch>
pq: ah right, yes that would be an interesting thing to do. OTOH, prototyping using existing protocols can help define a future extension
<pq>
these questions around input inhibition are a good example: you're trying to figure out what all things you need to do in a client in order to stop a compositor from doing the wrong thing. If that responsibility was put onto the compositor instead, you would not need to guess what all is enough.
<pq>
oh, prototyping, sure
<pstch>
yes, very true
<pq>
although... what's there to prototype? If the protocol ends up being completely different, what did the prototype give you?
<pstch>
but still a bit frustrating that the screen-locking protocol seems to do everything I need, except that... I don't want to lock the session
<pq>
heh
<pstch>
I've been prototyping using the replacement for input-inhibition (screen-locking), and for now just assume my process wont crash
<kchibisov>
pstch: compositor is the one responsible for given focus.
<kchibisov>
also, layer-shell surface grabbing keyboard usually can't lose focus.
<kchibisov>
if it's on overlay, etc.
<kchibisov>
it's also all up to compositor policy.
<pstch>
kchibisov: right, but as I understand, there are protocols (and extensions) for asking the compositor to do that
<kchibisov>
and you have namespaces.
<kchibisov>
i don't know if there's a single one.
<pstch>
kchibisov: this "usually" is what I want to investigate
<kchibisov>
I mean, you can't protect against broken protocols.
<kchibisov>
you can't also protect against user having access to /dev/input.
<kchibisov>
if you know how to protect against user being in /dev/input, clearly you control a lot for your user already.
<pstch>
but users don't have access /dev/input do they ?
<kchibisov>
I can add myself to input group.
<kchibisov>
some users add themselves to it.
<pstch>
oh right, but by "users" here I mean sandboxed apps, which would be running using defined privileges
<kchibisov>
but sandboxed apps shouldn't have access to special protocols anyway.
<pstch>
they won't
<kchibisov>
then you don't have focus steeling.
<pstch>
ah right. I was confused.
<kchibisov>
And it's again a compositor policy.
<kchibisov>
usually compositor gives focus to a newly created window.
<kchibisov>
on the same workspace.
<kchibisov>
basically how wl-clipboard.
<pstch>
yes, this is the kind of issues I want to protect against
<kchibisov>
only compositor can protect against that.
<pstch>
as some existing protocols mandate that the compositor must not open new windows (or give them focus)
<pstch>
hmmm that's very unclear
<kchibisov>
I mean, why pinentry should prevent me to open window.
<kchibisov>
sounds like I won't use this pinentry.
<pstch>
because if a new window can be opened it would be able to steal input events from the pinentry ?
glennk has joined #wayland
<kchibisov>
but I need a new window to get a password.
<kchibisov>
because I don't know it.
<kchibisov>
I can only fetch it, but I don't know my passwords.
<pstch>
in this case, it's a disk decryption password that would not make sense to store on the system itself
bim9262 has quit [Ping timeout: 480 seconds]
<kchibisov>
disks are decrypted usually early on.
<kchibisov>
without any compositor running.
<pstch>
not in this case
<kchibisov>
unless you mount an encrypted disk.
bim9262 has joined #wayland
<kchibisov>
but why wouldn't I store key in my keychain?
<kchibisov>
Like I'm not sure what your use case is with focus steeling.
<kchibisov>
if user typing manually they are not affected by it.
<kchibisov>
so you likely trying to handle paste from clipboard focus stealing?
<pstch>
because it's the key for a layered plausibly-deniable encryption system, and the password being stored somewhere it would break the plausible-deniability of the data
<kchibisov>
So you type it manually?
<pstch>
why would users typing manually not be affected by it ?
<kchibisov>
because they don't see a responce that they type?
<pstch>
at that point it's already too late
<kchibisov>
one character leaking is too late for a massive password?
<pstch>
yes
<pstch>
because in my threat model, I need to protect the information of the existence of the password
<pstch>
if one character leaks, we know that there is a password starting by a specific letter
<kchibisov>
and how does it know whether it's a password or user just slammed a keyboard?
<pstch>
then the user can be coerced to provide that password, thwarting the efforts made to preserve the plausible deniability of the data unlocked by the password
<kchibisov>
Do you control compositor?
<pstch>
yes
<kchibisov>
then never give focus to anyone.
<pstch>
well when the password prompt is not in use, I still want the user to be able to open new applications and let the compositor give them focus
<kchibisov>
Define a layer-shell namespace where you never transfer focus to anyone.
<pstch>
both the input-inhibition and screen-locking protocols work well for my use case, except the first one is obsolete, and screen-locking... locks the screen, which is problematic in case the password prompt crashes
<kchibisov>
which will be a compositor policy.
<kennylevinsen>
pstch: screen locking also explicitly renders no other content visible
<kennylevinsen>
so rather than "screen locking does everything I need", it seems more like "screen locking does one thing (focus stealing) that I need" :)
<kchibisov>
if it's "pinentry" your compositor never transfers focus out of it.
<pstch>
kennylevinsen: yes, with screen locking the "dimmed background" needs to be implemented using a screenshot, indeed
<kchibisov>
Like if you control all the stack it's already possible to do what you want.
<pstch>
kchibisov: oh that's very interesting, I missed that feature of layer-shell
<emersion>
a keyboard-interactive overlay layer surface will keep focus
<kchibisov>
Can't you still with another overlay layer-shell?
floof58 has quit [Ping timeout: 480 seconds]
<pstch>
kchibisov: in my case it's not a problem, as adversaries cannot use layer-shell
<pstch>
right so I was just worried for nothing about focus stealing since layer surfaces already protect me from that
<pstch>
thanks for your help everyone
<kennylevinsen>
kchibisov: yes, other clients from a higher layer will get priority - or if you get in front of the current surface on the same layer
<pstch>
(all this protocol/extensions definition and specification is absolutely beautiful to me)
<kchibisov>
yeah, so you need some policy for such case as well.
<kennylevinsen>
but yeah, layer-shell is meant to be privileged anyhow, and doesn't have protections against other layer-shell users
<kchibisov>
but if they don't expose layer-shell it's likely fine...
manuel_ has joined #wayland
<pstch>
is a protocol being privileged something that is defined in the protocols themselves ?
<pstch>
or is i
<pstch>
or is it compositor policy to define which protocols are privileged ?
<emersion>
it's mostly compositor policy
<emersion>
some protocols have a warning "hey btw this proto is pretty dangerous if free-for-all"
<kchibisov>
Can you have a priv. protocol in xdg/wp namespace?
<pstch>
layer-shell doesn't, unfortunately
<emersion>
keyboard-shortcut-inhinit is… somewhat privileged but not really
<emersion>
maybe some compositors want set_fullscreen to be privileged
<emersion>
(as in, require something in the app manifest to allow fullscreen)
<kchibisov>
Ah, there's no serial in those requests.
<kchibisov>
So the app can fullscreen/unfullscreen in a loop.
floof58 has joined #wayland
<pstch>
so I wager a possible future extension of security-context would be to allow specifying the set of protocols available in the context ?
AnuthaDev has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
<kennylevinsen>
pstch: why would that be needed? the compositor controles what protocols it exposes
<kennylevinsen>
and there's a mechanism to filter globals
<kennylevinsen>
(wl_display_set_global_filter)
<pstch>
because a sandboxing engine may want to run an app and prevent it accessing some protocols
<emersion>
pstch: security-context is just about client identification, nothing more
<emersion>
the compositor is free to implement access control on top
<pstch>
ah, right
<pstch>
but then the sandboxing policy of a sandboxing engine actually depend on the compositor in use
<kchibisov>
Shouldn't compositor be in charge on how much to disable?
<pstch>
it's always in charge of everything, but it can be useful to allow the sandboxing engine to have a say in that
<kchibisov>
nah.
<pstch>
the sandboxing engine knows that an app is supposed to use some of the privileged protocols, the compositor doesn't
<kchibisov>
I mean, compositor just disables all of them.
<pstch>
all protocols ?
<kchibisov>
so you're stuck with just xdg-shell and that's about it.
<kchibisov>
and core.
<kchibisov>
like why would you advertise questionable protocols to untrusted clients.
<emersion>
at some point would be nice to allow a sandboxed app to get some select privileged globals
<kchibisov>
yeah, but it could be defined in compositor config.
<pstch>
right, so what compositors do right now is to consider everything that is not core/xdg-shell a privileged protocol that is then not exposed in security contexts ?
<emersion>
i wouldn't say that
<kchibisov>
pstch: they can do whatever, it's just _they have a way_ to do that now.
<emersion>
there are tons of non-privileged protos
<emersion>
xdg-deco, presentation-time, etc etc
<pstch>
kchibisov: the user of the system may want to allow a sandboxed app to access some protocols
<kchibisov>
pstch: write a config inside compositor.
<kennylevinsen>
pstch: that is possible, it's just now defined in the protocol how the compositor decides its policy
<kchibisov>
if sandboxed && appid == XYZ => allow layer-shell.
<kennylevinsen>
it could read a manifest, have its own config, etc.
<emersion>
there are multiple options yeah'
<kchibisov>
it's just the issue was to identify clients.
<kchibisov>
not to restrict them.
<kchibisov>
because if you can identify you can restrict.
<pstch>
but this ties the sandboxing engine to a single compositor with a compatible policy, wouldn't that be problematic with flatpak for example ?
<pstch>
I mean, how is security-context useful to flatpak if flatpak cannot rely on protocols not being available in the sandbox ?
<kennylevinsen>
it does not tie them together - any sandbox just specifies what app it runs, and the compositor decides what apps are allowed what
<kennylevinsen>
e.g., on sway I could have a config to allow specific apps screen share access
<pstch>
well this kind of policy decision is usually the role of the sandboxing engine
<kennylevinsen>
on gnome, you might have an option in the system config panel
<kchibisov>
kennylevinsen: and then our screenshare goes via dbus side channel, so security context is useless.
<emersion>
a lot of this hasn't been thought out yet
<pstch>
kchibisov: not necessarily, dbus can be isolated as well, it's just more config
<kennylevinsen>
pstch: not really, the final say is always in the service provider. Your sandbox might give filesystem access, but the filesystem enforces privileges. Sandbox gives wayland access, compositor enforces privileges, etc.
<kchibisov>
pstch: you better not see what terminals in flatpak do.
AnuthaDev has quit []
bim9262 has joined #wayland
<kchibisov>
Like they clearly shouldn't even exist there.
<kchibisov>
yet we have a mechanism allowing them to 'run everything and access root'.
<kennylevinsen>
pstch: and while sandbox config specifies what the application *wants*, compositor specifies what the user *grants*
<pstch>
that depends on the system configuration, in this system I'm describing it would not be the case
<pstch>
that prevents from being offered everywhere, not inside a specific security context
<kennylevinsen>
emersion: you could, but then each protocol would need an appropriate soft error I assume
<kchibisov>
pstch: it's for the client.
<emersion>
we've been trying to always allow compositors to deny requests in our protocols
<emersion>
like layer shell can send closed immediately etc
<kennylevinsen>
pstch: it is called each time a global is about to be offered to a client
<kennylevinsen>
sway for example hides xwayland_shell_v1 from all clients except the xwayland instance it started itself
<kchibisov>
kde does the same for input_method_v2 iirc.
<kennylevinsen>
I wonder if clients would need to know that it failed due to privilege
<emersion>
kennylevinsen: why would they?
<kennylevinsen>
say you want to present the user with an appropriate error, or in case of layer shell fall back to an xdg window
<kennylevinsen>
could be obscure for the user that the application just thinks the user immediately closed the window
<kennylevinsen>
(well, in case of layer shell a normal close would likely be "output disconnected", but you get the idea)
* emersion
shrugs
<emersion>
hard to say anyways, none of this exists
<kennylevinsen>
yup
i509vcb has quit [Quit: Connection closed for inactivity]
<pstch>
taking a concrete example : if flatpak wanted to provide a specific permission for inhibiting keyboard shortcuts (access to keyboard-shortcuts-inhibit), it would indeed need a mechanism to ensure that the protocol is available in a security context it created
<pstch>
but it would also need to know that this protocol is not generally accessible, otherwise the permission cannot actually be implemented
AnuthaDev has joined #wayland
<kennylevinsen>
pstch: whether an application gets permission to inhibit keyboard shortcuts is arguably user preference rather than a sandboxing decision
<kennylevinsen>
sandboxing is more about limiting which domains can be accessed, not enforcing fine-grained privileges (including user decisions) within those domains
<pstch>
ah, yes
<pstch>
still unfortunate for the pinentry in this sytem : it is needed that it is the only app having access to some protocols (the one enabling prompt impersonation)
<pstch>
ones*
<pstch>
of course it can be patched all of the compositors provided by the OS, but that's a lot of work
<emersion>
hm i'm not following
<pstch>
I'm trying to write an environment where the user can launch untrusted apps without fear of them impersonating the password prompt
<pstch>
of course, I can also chooose to only provide compositors with definitions (of which protocol is privileged) compatible with my use-case
<emersion>
you'll need to launch each untrusted app inside a sandbox, and then it's fine?
<pstch>
emersion: well that's what is done, but the sandboxing engine cannot know that layer-shell is not available *in* the sandbox, since it is an implementation detail of the compositor and neither something specified in the protools themselve nor something that can be configured for specific apps
<pstch>
(and this applies to all "privileged" protocols, not only layer-shell)
fmuellner has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
Fxzxmic has joined #wayland
bim9262 has joined #wayland
AnuthaDev has quit []
rasterman has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
Moprius has joined #wayland
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
Company has joined #wayland
manuel_ is now known as manwag
Fxzxmic has quit [Read error: Connection reset by peer]
Fxzxmic has joined #wayland
cmichael has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
fmuellner has quit []
<kchibisov>
If compositor sends a wl_keyboard::keymap what happens to the modifier state it send before? Is it discarded?
<kchibisov>
The situation we have is that user types with virtual keyboard, but then compositor could also do input itself. So you need to change keymaps between virtual-keyboard and compositor input.
bim9262 has quit [Ping timeout: 480 seconds]
<kchibisov>
I think the modifiers must be resend for the focused client when you change keymaps, since they are tied to it?
bim9262 has joined #wayland
glennk has joined #wayland
nerdopolis has joined #wayland
manuel_ has joined #wayland
Moprius has quit [Remote host closed the connection]
bnason6 has joined #wayland
manwag has quit [Ping timeout: 480 seconds]
bnason6 is now known as bnason
maxzor has joined #wayland
Fxzxmic has quit [Read error: Connection reset by peer]
Fxzxmic has quit [Read error: Connection reset by peer]
Fxzxmic has joined #wayland
Fxzxmic is now known as Fxzx_mic
Fxzx_mic is now known as Fxzxmic
sevz has joined #wayland
kts has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
maxzor has joined #wayland
privacy has quit [Quit: Leaving]
mohit8158 has quit [Quit: Ping timeout (120 seconds)]
bluetail has quit [Quit: Ping timeout (120 seconds)]
maxzor has quit [Ping timeout: 480 seconds]
rappet has quit [Remote host closed the connection]
trclst has quit [Remote host closed the connection]
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
rappet has joined #wayland
bluetail has joined #wayland
leon-anavi has quit [Quit: Leaving]
trclst has joined #wayland
bim9262 has joined #wayland
kts has quit [Ping timeout: 480 seconds]
sgm has joined #wayland
AnuthaDev has joined #wayland
manuel_ has quit [Quit: Leaving]
joe_ has joined #wayland
joe_ has quit []
flom84 has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
flom84 has quit []
Fxzxmic has quit [Quit: Konversation exit!]
flom84 has joined #wayland
bim9262 has joined #wayland
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
flom84 has quit [Remote host closed the connection]
tzimmermann has quit [Quit: Leaving]
AnuthaDev has quit []
lbia has quit [Quit: lbia]
fmuellner has joined #wayland
<DemiMarie>
pstch: it sounds like you are trying to make something similar to Qubes OS. I’m a Qubes OS developer.
<DemiMarie>
Qubes OS use X11 right now (technical debt) but will support Wayland eventually.
<DemiMarie>
I recommend requiring layer shell support in the compositor. Otherwise, you won’t be able to do privileged UI (like custom menus) in a cross-compositor way.
lbia has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
<pstch>
DemiMarie: yes, Qubes has been and is a big inspiration for this project
<DemiMarie>
pstch: thanks! If I may ask, why not use Qubes itself? Also, have you heard of Spectrum OS (https://spectrum-os.org)?
<pstch>
my main focus is on the integration of the ShuffleCake LPDS in a desktop environment
Moprius has joined #wayland
<pstch>
yes, both were big inspirations for me
Moprius has quit []
<DemiMarie>
pstch: ShuffleCake would be a useful addition to both, IMO. Though logs would need to be avoided.
<pstch>
I didn't use Qubes because I wanted tighter integration between the applications sandboxes and the host system
<DemiMarie>
Valid
<pstch>
NixOS enabled me to quickly configure an immutable-root system, and allows the use of store overlays so that software can be reused through the layers while still maintaining PD
<pstch>
SpectrumOS takes a much more radical approach to isolation (by defining a light custom TCB), that would make it a bit harder for me to experiment with practical uses of PD
<pstch>
PD is one of these things that seem really useful at first, but I find that in practice it's not easy to actually make it work
<pstch>
(the existence of a layer can leak through a quite formidable number of ways)
<pstch>
right now it's more of a toy project to see how far it's possible to go in this direction (wayland-proxy-virtwl
<pstch>
right now it's more of a toy project to see how far it's possible to go in this direction (AppVMs using wayland-proxy-virtwl + wayland security contexts + MergerFS + namespaced mounts and a custom GUI shell), but the practical long-term plan is to bring these changes to an existing project, so that the features can be used in a plausibly-deniable way
<pstch>
(using a toy OS centered around PD decreases the plausability of the denial, while one can always say that they didn't know that their sandboxed OS uses PD-storage by default, for example)
<DemiMarie>
This all seems really similar to SpectrumOS :)
<pstch>
it is, but I think there are significant differences appearing, and I do a lot of compromises that SpectrumOS's dev chose not to make
floof58 has quit [Ping timeout: 480 seconds]
floof58 has joined #wayland
cmichael has quit [Quit: Leaving]
Kerr has quit [Quit: Bye.]
joe_ has joined #wayland
joe_ has left #wayland [#wayland]
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
Kerr has joined #wayland
privacy has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
sima has quit [Ping timeout: 480 seconds]
i509vcb has joined #wayland
Brainium has joined #wayland
sgm has left #wayland [#wayland]
nerdopolis has quit [Ping timeout: 480 seconds]
bim9262 has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
LaserEyess has quit [Remote host closed the connection]
LaserEyess has joined #wayland
___nick___ has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
glennk has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
fmuellner has joined #wayland
mvlad has quit [Remote host closed the connection]
bim9262 has quit [Ping timeout: 480 seconds]
rv1sr has quit []
bim9262 has joined #wayland
lsd|2 has joined #wayland
i509vcb has quit [Quit: Connection closed for inactivity]