ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
garnacho has quit [Ping timeout: 480 seconds]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
eeyue has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
garnacho has joined #wayland
larunbe has joined #wayland
alarumbe has quit [Ping timeout: 480 seconds]
alarumbe has joined #wayland
lsd|2 has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
Dami_Lu has joined #wayland
larunbe has quit [Ping timeout: 480 seconds]
eeyue has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
Guest13693 has quit [Remote host closed the connection]
cool110 has joined #wayland
Leopold_ has quit [Remote host closed the connection]
cool110 is now known as Guest14133
pbsds is now known as Guest14138
Guest14138 has quit [Read error: Connection reset by peer]
pbsds has joined #wayland
Guest14133 has quit [Ping timeout: 480 seconds]
JayBeeFOSS has quit [Ping timeout: 480 seconds]
JayBeeFOSS has joined #wayland
glennk has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
garnacho has quit [Ping timeout: 480 seconds]
<orowith2os[m]> I wonder if it's possible to have more than one xdg_popup per wl_surface
<orowith2os[m]> not in a chain, but a wl_surface actually has two separate xdg_popups, both active
systwi has quit [Remote host closed the connection]
Leopold_ has joined #wayland
crazybyte0 has quit [Read error: Connection reset by peer]
crazybyte0 has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
cool110 has joined #wayland
cool110 is now known as Guest14148
Leopold__ has joined #wayland
Leopold__ has quit [Remote host closed the connection]
Leopold_ has quit [Ping timeout: 480 seconds]
Guest14148 has quit [Remote host closed the connection]
cool110_ has joined #wayland
cool110_ is now known as Guest14150
<danieldg> orowith2os[m]: consider multi-seat, with two cursors over two elements both getting a tooltip popup. Or, both touch and mouse interactions generating popups.
<orowith2os[m]> I'm guessing that's a yes, then
<danieldg> I'd check to see if you can make it happen on existing compositors too
nerdopolis has quit [Ping timeout: 480 seconds]
mclasen has quit [Ping timeout: 480 seconds]
Dami_Lu has quit [Remote host closed the connection]
Dami_Lu has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
eeyue has quit [Read error: Connection reset by peer]
Leopold_ has joined #wayland
andyrtr has quit [Quit: ZNC 1.8.2 - https://znc.in]
andyrtr has joined #wayland
Company has quit [Quit: Leaving]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
<YaLTeR[m]> Firefox can show a tooltip while a popup is open, but in that case the tooltip will use a subsurface for some reason
<YaLTeR[m]> GTK can show a tooltip while a popup is open I think
<YaLTeR[m]> at least if the compositor lets the pointer enter the parent surface during a popup grab
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
tzimmermann has joined #wayland
kts has joined #wayland
Leopold_ has quit [Remote host closed the connection]
rgallaispou has joined #wayland
shoragan has quit [Quit: quit]
sima has joined #wayland
Leopold has joined #wayland
glennk has joined #wayland
pH5 has quit [Remote host closed the connection]
mtretter has quit [Remote host closed the connection]
Leopold has quit [Remote host closed the connection]
Leopold has joined #wayland
Leopold has quit [Remote host closed the connection]
mvlad has joined #wayland
<wlb> wayland.freedesktop.org/main: José Expósito * libinput 1.25.0 release https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/0c904e93ed0f libinput/doc/ 1.25.0/.buildinfo 1.25.0/_images/button-debouncing-wave-diagram.svg 1.25.0/_images/button-scrolling.svg 1.25.0/_images/clickfinger-distance.svg 1.25.0/_images/clickfinger.svg 1.25.0/_images/edge-scrolling.svg 1.25.0/_images/gesture-2fg-ambigu
Leopold has joined #wayland
rasterman has joined #wayland
crazybyte08 has joined #wayland
cvmn has joined #wayland
caveman has quit [Ping timeout: 480 seconds]
cvmn has quit [Remote host closed the connection]
crazybyte0 has quit [Ping timeout: 480 seconds]
crazybyte08 is now known as crazybyte0
caveman has joined #wayland
<wlb> wayland.freedesktop.org Issue #6 opened by José Expósito (JoseExposito) CI: zlib signature error https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/issues/6
jlco has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
jlco has joined #wayland
<wlb> wayland.freedesktop.org Merge request !74 opened by José Expósito (JoseExposito) ci: use Alpine Linux instead of Arch as base image https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/74
narodnik has quit [Quit: WeeChat 4.1.2]
Leopold has quit [Remote host closed the connection]
Leopold has joined #wayland
fmuellner has joined #wayland
kts has quit [Ping timeout: 480 seconds]
anarsoul has quit [Remote host closed the connection]
anarsoul has joined #wayland
<wlb> weston Issue #865 opened by Neal Gompa (ニール・ゴンパ) (Conan_Kudo) Add support for listening and reconfiguring the keyboard layout from locale1 https://gitlab.freedesktop.org/wayland/weston/-/issues/865
leon-anavi has joined #wayland
Leopold has quit [Remote host closed the connection]
<wlb> wayland.freedesktop.org Issue #6 closed \o/ (CI: zlib signature error https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/issues/6)
<wlb> wayland.freedesktop.org Issue #6 closed \o/ (CI: zlib signature error https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/issues/6)
<wlb> wayland.freedesktop.org/main: José Expósito * ci: use Alpine Linux instead of Arch as base image https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/3f75884f99eb .gitlab-ci.yml
<wlb> wayland.freedesktop.org Merge request !74 merged \o/ (ci: use Alpine Linux instead of Arch as base image https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/74)
<wlb> wayland.freedesktop.org Merge request !63 merged \o/ (ci: call meson setup for the libinput build https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/63)
<wlb> wayland.freedesktop.org/main: Peter Hutterer * ci: call meson setup for the libinput build https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/89f2ba21c887 .gitlab-ci.yml
Brainium has joined #wayland
garnacho has joined #wayland
systwi has joined #wayland
<Eighth_Doctor> are there any weston folks here?
kts has joined #wayland
<Eighth_Doctor> I just filed the request for having weston respond to locale1 for keyboard settings, and I was wondering if anyone would be able to take a look into it sooner rather than later
<Eighth_Doctor> the context for this is that I'm trying to port Anaconda (the RH/Fedora installer) to run on Weston: https://github.com/rhinstaller/anaconda/pull/5401
kts has quit []
<pq> Eighth_Doctor, that's interesting. Probably not me personally. What does daniels think?
<Eighth_Doctor> Weston was pretty much the only compositor I could find that would match the mix of things that Anaconda did on X11
<Eighth_Doctor> notably, having VNC support :)
<Eighth_Doctor> and a path to also adding RDP support :D
kts has joined #wayland
<Eighth_Doctor> also, it's not glitchy as hell as some of the other ones I tried :P
<Eighth_Doctor> Weston is now the default compositor for Anaconda's firstboot program too: https://github.com/rhinstaller/initial-setup/pull/149
<Eighth_Doctor> pq: the only gaps I've found are related to not having a way to dynamically reconfigure anything in Weston
<Eighth_Doctor> outputs, keyboard configuration, input methods, etc.
<Eighth_Doctor> there was a patchset 10 years ago that would have also introduced weston-control and a mechanism that could be used for this purpose, but it didn't land: https://lists.freedesktop.org/archives/wayland-devel/2013-April/008542.html
<pq> yeah, that might be a lot of work
<Eighth_Doctor> for the anaconda case, most of the things I don't need to worry about right now... but responding to locale1 for keyboard configuration would cover the basic needs
<pq> I would think that dynamic reconfiguration should also be persistent, and not like xrandr etc making the next start-up a mess.
<Eighth_Doctor> yes, ideally it would trigger writing to weston.ini
<Eighth_Doctor> but I don't think anything in weston does that
<Eighth_Doctor> in that respect, it follows the xserver model in only reading persistent config
<Eighth_Doctor> it does, however, lack a weston.ini.d config thing
<pq> We barely have NIH'd code to read weston.ini, extending that is probably not the best idea. Personally I'd like to see Weston using some library for this that does it all.
<Eighth_Doctor> yeah
<pq> You wouldn't happen to have any suggestions for such lib?
<Eighth_Doctor> I might actually
<Eighth_Doctor> pq: three options I can think of: libeconf, libconfuse, and libconfig
<Eighth_Doctor> pq: I think libeconf would actually be the best choice for being able to make it easy to support layered configuration in weston
<Eighth_Doctor> a number of other projects use it, notably pam does
<Eighth_Doctor> oh and util-linux
<pq> and dynamic change and write-back support?
<Eighth_Doctor> libeconf doesn't do writing config
<Eighth_Doctor> only parsing
mclasen has joined #wayland
<Eighth_Doctor> pq: for read+write, inih and iniparser are good options
<pq> cool, I'm trying to find the old Weston issue to list these in, I thought there was one...
<Eighth_Doctor> I would probably go with inih over iniparser
<Eighth_Doctor> since inih more closely matches Weston's existing ini parsing
<Eighth_Doctor> though if I'm being honest, if we could, I'd change to TOML instead
<pq> I think we could also do something completely different than current weston.ini, if it's attractive enough.
<Eighth_Doctor> there are a lot more implementations and it's standardized in a way that ini is not
<soreau> pq: that route probably looks a lot like kanshi with weston supporting wlr-output-management protocol
<soreau> then you'd get wlr-randr support for free too
<pq> maybe that means we need to write a second Weston frontend, but that would be a good long-term exercise anyway, because people are supposed to be able to do that, and right now it's practically intractable.
<pq> frontend is the component that defines e.g. configuration formats and policies
<Eighth_Doctor> soreau: funnily enough, zamundaaa and I were talking about that in the context of kwin... it seems kde's dpms protocol is more powerful, and it might be worth making an ext- protocol formally to supersede both wlr-output-management and kde-dpms that compositors can implement
<Eighth_Doctor> because the situation sucks as it currently stands
<emersion> how more powerful?
<emersion> wlr-output-management doesn't do "DPMS"
<emersion> ("DPMS" is a legacy name for power management)
eeyue has joined #wayland
<emersion> wlr-output-power-management does "DPMS"
<zamundaaa[m]> The dpms protocol only differs from the wlroots one in that it has an event for whether or not dpms is supported
<emersion> when is that not supported?
<zamundaaa[m]> In nested sessions
<emersion> wlroots unmaps the surface in that case
<zamundaaa[m]> And in general, virtual outputs
<emersion> it would be fine to do nothing as well
<emersion> i think it makes sense to allow "turning off" a virtual output
<wlb> weston Issue #488 closed \o/ (Deprecate and eventually delete non-libseat launchers https://gitlab.freedesktop.org/wayland/weston/-/issues/488)
<emersion> IOW: not sure it's worth adding a special-case in the protocol for
<soreau> seems like someone should make a MR for s/wlr/ext/ of wlr-output-management and then let the bikeshedding commence ;)
<wlb> weston/main: Colin Kinloch * clients/stacking: Fix widget user_data cast type https://gitlab.freedesktop.org/wayland/weston/commit/3f919e3d92ae clients/stacking.c
<wlb> weston Merge request !1438 merged \o/ (clients/stacking: Fix widget user_data cast type https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1438)
<emersion> yeah i'm not trying that lol
* any1 hides
<zamundaaa[m]> Yeah. I'd have to check if the capability thing is even used anywhere
<emersion> we should probably just re-open wlr-protocols tbh
<emersion> i was against it, but it just feels like nothing good is coming out of it
<zamundaaa[m]> Oh, talking about wlr-protocols, could you take a look at https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/merge_requests/123?
<emersion> ah right
<Eighth_Doctor> soreau: I am seriously tempted
<soreau> Eighth_Doctor: it won't happen if no one moves it forward
<zamundaaa[m]> Fwiw I don't see KWin adopting the wlroots or an ext output management protocol. At least not as a replacement for the kde proto
<soreau> that's their problem though
<emersion> zamundaaa[m]: last time i looked at it i thought the KDE one could sit on top of the wlr one?
<emersion> that would be nice
<emersion> i've tried hard to make the protocol externally-extensible when designing the wlr proto
<Eighth_Doctor> the fragmentation on these basic protocols is extremely irritating because all the little utilities with incompatibilities or unknown uselenessness makes things very hard
<Eighth_Doctor> *uselessness even
<zamundaaa[m]> It would be possible, but possibly more effort than supporting two entire protocols. KWin's internal architecture is almost entirely ignorant of the underlying protocol
<emersion> ;_;
<zamundaaa[m]> I'll give implementing it a try when I have time
<emersion> let me know if the wlr proto is lacking in some way
<Eighth_Doctor> maybe I should just take the existing one and submit it :/
Leopold has joined #wayland
<Eighth_Doctor> then I can drop the dumb "unstable" name that exists
<wlb> weston/main: Derek Foreman * libweston: Clip damage to paint node visible region https://gitlab.freedesktop.org/wayland/weston/commit/e74f2897b940 libweston/compositor.c
<Eighth_Doctor> I don't think that protocol has changed in a backwards incompatible way in forever
<wlb> weston Merge request !1441 merged \o/ (libweston: Clip damage to paint node visible region https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1441)
jkl has quit [Quit: Gone.]
<emersion> yeah, a lot of protocols predate the "staging" era
<Eighth_Doctor> the reason I hadn't bothered before is that the wayland-protocols rules are too onerous right now
<Eighth_Doctor> but supposedly the rules will be relaxed for ext-
<Eighth_Doctor> at some point
<Eighth_Doctor> maybe
<emersion> i don't think so
jkl has joined #wayland
<Eighth_Doctor> arent you the one that opened the MR for that?
kts has quit [Quit: Leaving]
<emersion> yeah, but i don't think it's a good idea to clutter ext- with protos that may be specific to a single compositor
<Eighth_Doctor> yes, but who would do that?
<Eighth_Doctor> right now, the current situation is that it's too hard to get an xdg protocol, and there are effectively no avenues for protocols that are adopted by some and ignored by others
Guest14150 has quit [Remote host closed the connection]
cool110 has joined #wayland
<wlb> wayland-protocols Merge request !192 closed (governance: relax ACK requirements for the ext namespace)
cool110 is now known as Guest14185
<emersion> ext is that avenue
<soreau> the more protocols that get upstreamed to w-p, the more chance that the ecosystem utilities as a whole will start cooperating better together
<Eighth_Doctor> emersion: not right now, even ext protocols are stuck
<emersion> some are stuck because of disagreements between compositors
<emersion> some are stuck because only a single compositor cares
<emersion> either way, the solution isn't that MR to relax rules
<Eighth_Doctor> true
<Eighth_Doctor> the solution needs to be that a single NACK can't kill everything
<emersion> nobody has been NACK'ing
<emersion> it's just unresolved discussions, or missing ACKs
<emersion> (ext can't be NACK'ed anyways)
<Eighth_Doctor> well then, I guess I'll try with output-management then
<Eighth_Doctor> we'll see how that goes, watching ximion's adventure though was somewhat disheartening
jkl has quit [Quit: Gone.]
<emersion> but the latter probably not a good idea
<emersion> still unsure how these mode aspect ratio flags should get exposed to users
jkl has joined #wayland
<Eighth_Doctor> hmm, that would be needed for Weston too
<Eighth_Doctor> since it exposes configuring the aspect ratio
<emersion> i think the right thing to do is to disregard modes with flags, and let the compositor set it depending on fullscreen surface aspect ratio
<emersion> and/or a dedicated aspect ratio protocol
<emersion> but that needs a modeset
<Eighth_Doctor> I am not sure why aspect ratio is a settable thing
<emersion> sigh
<Eighth_Doctor> it's usually derived from the WxH, no?
<Eighth_Doctor> or am I missing something here?
kts has joined #wayland
<emersion> the EDID allows setting a picture aspect ratio different from mode aspect ratio
<Eighth_Doctor> O.o
<emersion> well, not EDID, rather the HDMI InfoFrames and such
<Eighth_Doctor> okay I guess
<Eighth_Doctor> is that what makes "black bars"?
<pq> non-square pixels are a thing
<Eighth_Doctor> oh right, that
<Eighth_Doctor> I should have remembered that, since I know of OLED panels like that
<emersion> if you watch a 16:9 movie on a 4:3 screen, you'd use a 4:3 mode with a 16:9 picture aspect ratio
<emersion> pq, i think that's unrelated though?
<pq> picture aspect ratio is about non-square pixels, AFAIK
<emersion> vsyrjala: ^ do you know details?
privacy has quit [Quit: Leaving]
<emersion> pq, that doesn't match my recollection of the EDID spec
<emersion> CTA*
<emersion> but maybe i'm misremembering
<pq> I can't think of what else it could be, if not for non-square pixels. Otherwise there would be no need to send anything else than width and height.
<pq> in pxiels
<emersion> and as always now i'm even more confused than before
<emersion> but fairly sure it's not about non-square pixels at least?
nerdopolis has joined #wayland
pH5 has joined #wayland
<wlb> weston Issue #866 opened by Pekka Paalanen (pq) RFC: Modernizing configuration management https://gitlab.freedesktop.org/wayland/weston/-/issues/866 [Weston frontend]
lsd|2 has joined #wayland
<pq> emersion, are those about CEA modes? VIC? They don't look familiar.
<emersion> this is the definition of picture aspect ratio
<pq> I'm thinking more of DRM_CLIENT_CAP_ASPECT_RATIO
Leopold has quit [Remote host closed the connection]
<emersion> that's the same thing
<emersion> this cap enables the picture aspect ratio flags in mode
<emersion> i kind of wish ATOMIC didn't implicitly enabled this cap…
mtretter has joined #wayland
shoragan has joined #wayland
<pq> emersion, if look at CTA-861-H, section 4.1 Aspect Ratio, there is a table with lots of modes with Pixel Aspect Ratio other than 1:1.
<emersion> right, but that's not the picture aspect ratio flag
<pq> how is it not?
<emersion> picture aspect ratio ≠ pixel aspect ratio
<emersion> well, it's just two different concepts?
<pq> looking at the table, pixel aspect ratio is derived from resolution and picture aspect ratio.
<pq> IOW, picture aspect ratio can be chosen to result in either square of non-square pixels, depending on each mode. Some modes do not even have a square pixel variant.
<pq> *or
<pq> this is the VIC list
<pq> picture aspect ratio flags in KMS are just used for choosing the right VIC, because resolution alone is not enough
<pq> and there's a ton of VICs with non-square pixels - like there are MPEG etc. videos as well, I believe
<pq> FWIW, Wayland clients can provide non-square pixels to the compositor using wp_viewport, but we do not have a way to tell clients what would match the display.
<emersion> hm, ok
<pq> or does fractional scaling help there?
<emersion> no, it just sends a single factor
<pq> d'oh
cmichael has joined #wayland
<wlb> wayland Merge request !362 opened by Simon Ser (emersion) build: add a gen-scanner-test target https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/362
kts has quit [Ping timeout: 480 seconds]
Guest14185 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest14192
Guest14192 has quit [Remote host closed the connection]
cool110_ has joined #wayland
cool110_ is now known as Guest14193
mxz has joined #wayland
Company has joined #wayland
cmichael has quit [Quit: Leaving]
lsd|2 has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
garnacho has quit [Ping timeout: 480 seconds]
kts has joined #wayland
Leopold_ has joined #wayland
kts has quit [Ping timeout: 480 seconds]
lsd|2 has joined #wayland
kts has joined #wayland
leandrohrb56 has joined #wayland
zxrom has joined #wayland
<zxrom> My two different old Microsoft IntelliPoint 3 and 4 mice are behaving strangely. More than a year ago, the scroll wheel started working spontaneously. Perhaps the new mouse input processing module has removed protection against this behavior of these mice? I have already disassembled and cleaned everything from dust. It did not help. Who has a similar problem? Anyone have any ideas?
<bl4ckb0ne> there has been a change recently regarding scrolling wheel
<bl4ckb0ne> what's your compositor?
<zxrom> Recently is it a year and a half or two years ago? It seems there was another input module before.
<zxrom> XOrg, LXDE,Openbox
<zxrom> libinput
<zxrom> ArchLinux
privacy has joined #wayland
<zxrom> This bug shook my nerves! This works on taskbar buttons often. I usually leave the mouse pointer there.
<zxrom> :D
<zxrom> bl4ckb0ne, Perhaps from high resolution mouse wheel scrolling to return the old behavior?
* bl4ckb0ne shrugs
glennk has quit [Ping timeout: 480 seconds]
<bl4ckb0ne> cant say much about x11 DE
<zxrom> Is it possible to disable high resolution mouse wheel scrolling to return the old behavior?*
<zxrom> I wonder if this module misses real mouse wheel triggers or erroneously generates them internally due to some algorithms? I have not seen this behavior of the wheel in Windows.
kts has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
tzimmermann has quit [Quit: Leaving]
Brainium has joined #wayland
zxrom has quit [Quit: Leaving]
garnacho has joined #wayland
rgallaispou has left #wayland [#wayland]
glennk has joined #wayland
rv1sr has joined #wayland
occivink has quit [Quit: WeeChat 3.7.1]
mclasen has quit [Ping timeout: 480 seconds]
occivink has joined #wayland
<vyivel> from compositor side, is there a way to stop new clients from connecting?
<kchibisov> Instantly kill them?
<vyivel> that's what i'm doing right now but maybe there's a better way
<kchibisov> It boils down to unix socket APIs.
<vyivel> right
<emersion> you can close the listener
<emersion> but i don't think libwayland lets you access it
<emersion> we have a function to disconnect all clients
<kchibisov> they want a way to not add new clients, but keep the already connected ones, I think.
<vyivel> the context is i'm doing some cleaning up between wl_display_destroy_clients() and wl_display_destroy() which involves dispatching events though now i'm realising i don't really need to do that
mclasen has joined #wayland
<vyivel> nope, still do
<vyivel> whatever, client_created listener with wl_client_destroy() works
privacy has quit [Ping timeout: 480 seconds]
leon-anavi has quit [Quit: Leaving]
eeyue has quit [Ping timeout: 480 seconds]
cool110 has joined #wayland
cool110 is now known as Guest14209
Guest14193 has quit [Ping timeout: 480 seconds]
mclasen has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
narodnik has joined #wayland
qyliss has quit [Quit: bye]
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
rv1sr has quit []
eeyue has joined #wayland
eeyue has quit [Ping timeout: 480 seconds]
eeyue has joined #wayland
eeyue has quit [Ping timeout: 480 seconds]
mohit8158226 has quit [Quit: mohit8158226]
mohit8158226 has joined #wayland
qyliss has joined #wayland
eeyue has joined #wayland
qaqland_ has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
qaqland has quit [Ping timeout: 480 seconds]
qaqland_ is now known as qaqland
rasterman has quit [Quit: Gettin' stinky!]
eeyue has quit [Ping timeout: 480 seconds]
mclasen has joined #wayland
Leopold_ has quit [Remote host closed the connection]
columbarius has joined #wayland
Guest14209 has quit [Remote host closed the connection]
co1umbarius has quit [Ping timeout: 480 seconds]
cool110 has joined #wayland
cool110 is now known as Guest14223
fmuellner has joined #wayland
that_guy has quit [Quit: I'M OUT]
Guest14223 has quit [Remote host closed the connection]
cool110_ has joined #wayland
cool110_ is now known as Guest14229
that_guy has joined #wayland
that_guy has quit [Ping timeout: 480 seconds]
that_guy has joined #wayland
mvlad has quit [Remote host closed the connection]
nurupo_ has joined #wayland
nurupo has quit [Ping timeout: 480 seconds]