ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
alatiera has quit [Quit: Connection closed for inactivity]
mclasen has quit []
mclasen has joined #wayland
mvlad has quit [Remote host closed the connection]
mclasen has quit [Remote host closed the connection]
mclasen_ has joined #wayland
mclasen_ has quit [Read error: Connection reset by peer]
glennk has quit [Ping timeout: 480 seconds]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #wayland
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
checkfoc_us has quit []
checkfoc_us has joined #wayland
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
karmavil[m] has quit [Quit: Client limit exceeded: 20000]
Brainium has quit [Quit: Konversation terminated!]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
garnacho has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
privacy has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
diamondburned[m] is now known as Diamonditshe[m]
jkl__ has joined #wayland
jkl has quit [Ping timeout: 480 seconds]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
ShapeShifter499 has joined #wayland
Leopold_ has joined #wayland
Company has quit [Quit: Leaving]
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
mxz has quit [Ping timeout: 480 seconds]
jkl__ has quit []
eroc1990 has quit [Quit: The Lounge - https://thelounge.chat]
jkl has joined #wayland
eroc1990 has joined #wayland
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
privacy has quit [Quit: Leaving]
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
kts has joined #wayland
kts has quit [Remote host closed the connection]
Leopold has joined #wayland
mxz has joined #wayland
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #wayland
glennk has joined #wayland
Leopold has quit [Remote host closed the connection]
Leopold has joined #wayland
sima has joined #wayland
kts has joined #wayland
Leopold has quit [Remote host closed the connection]
kts has quit [Remote host closed the connection]
rasterman has joined #wayland
kts has joined #wayland
rv1sr has joined #wayland
garnacho has joined #wayland
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
tzimmermann has joined #wayland
Leopold_ has joined #wayland
ShapeShifter499 has quit [Remote host closed the connection]
nniro_ is now known as nniro
Leopold__ has joined #wayland
kts has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
Leopold_ has quit [Remote host closed the connection]
kts has joined #wayland
Leopold__ has quit [Remote host closed the connection]
leon-anavi has joined #wayland
Bugies has joined #wayland
rgallaispou has joined #wayland
rasterman has joined #wayland
kts has quit [Ping timeout: 480 seconds]
Leopold has joined #wayland
kts has joined #wayland
Leopold has quit [Remote host closed the connection]
<wlb> weston Issue #873 opened by Debojit Das (new_user_0) Touchscreen not rotating along with display. https://gitlab.freedesktop.org/wayland/weston/-/issues/873
glennk has quit [Ping timeout: 480 seconds]
mclasen has joined #wayland
glennk has joined #wayland
kts has quit [Ping timeout: 480 seconds]
mclasen has quit [Remote host closed the connection]
mclasen has joined #wayland
mclasen_ has joined #wayland
mclasen has quit [Remote host closed the connection]
mvlad has joined #wayland
mclasen_ has quit [Remote host closed the connection]
mclasen has joined #wayland
Brainium has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
mclasen has quit [Ping timeout: 480 seconds]
<emersion> what should i do about this?
<emersion> that seems… wrong
fmuellner has joined #wayland
eroc1990 has quit [Read error: Connection reset by peer]
eroc1990 has joined #wayland
<kennylevinsen> from drm_fourcc.h: "Some Broadcom modifiers take parameters, for example the number of vertical lines in the image. Rseerve the lower 32 bits for modifier type, and the next 24 bits for parameters." - but why would you do that :(
JayBeeFOSS has quit [Ping timeout: 480 seconds]
<emersion> cc sima daniels ^
JayBeeFOSS has joined #wayland
kts has joined #wayland
mclasen has joined #wayland
<pq> did that stuff really make it to kernel upstream?
paulk has quit [Quit: WeeChat 3.0]
mclasen has quit [Remote host closed the connection]
<pq> I'm guessing that kernel reviewers never realized that drm_fourcc.h itself never uses fourcc_mod_broadcom_mod() macro.
kts has quit [Quit: Leaving]
<pq> or fourcc_mod_broadcom_param()
<sima> ok this is hilariously broken and should never have landed
<emersion> phew
<sima> so from a very quick look at vc4 kernel code it does look fixable
<sima> as in, if the param is 0 we use the pitch passed in as metadata and not this funny modifier param business
<sima> ideally Someone(tm) would check if we could also rely on the passed-in pitch for when the parameter is set
<pq> the doc for these is confusing, but I'm guessing that "vertical lines" is actually the width of "columns", not image width
<sima> but yeah good job on tossing 24bits into the dustbin lolz
<sima> pq, yeah it's just what addfb calls pitch
<sima> or well, should have been
<pq> is it? it does not sound like pitch to me
<sima> oh I got confused I guess
<sima> hm
<sima> it's just stored in a register called pitch0 :-)
<pq> sounds like there are 4 different valid values for the parameter: 32, 64, 128, and 256
kts has joined #wayland
<pq> so it shouldn't be any problem to enumerate all accepted modifiers verbatim
<sima> hm yeah maybe not sure ...
<sima> yeah just enumerate them
<sima> and replace the comments above the macros with a "absolutely do not use this in any new code at all"
<pq> maybe the kernel patch makes sense, apart from the two unused macros, while the wlroots patch is bogus?
<sima> oh normalizing modifiers is complete bogus
<sima> I'm just looking for the best way to fix this mess without breaking anything
<pq> first patch the kernel to delete the unused macros, and anyone who screams about that is getting modifiers totally wrong in userspace :-)
nerdopolis has joined #wayland
<sima> emersion, I dropped a comment onto that mr
<emersion> #define fourcc_mod_broadcom_mod() rand()
<sima> pq, it might break the userspace drivers if we delete those
<emersion> ty sima
<sima> but yeah ideally we ditch them everywhere and replace them with hardcoded enumerations
<pq> sima, how could they be right in using those macros?
<sima> pq, not right, but also it'd be a build-time regression
<pq> "oh, sorry, here's the revert" :trollface:
<sima> whether the code is right depends a bit on where they're used
<sima> if it's just the modifier for an allocated buffer, then it would work if we switch to "only these explicitly documented combos are correct" world
<pq> nope, I don't understand what the bcm modifier doc says.
<sima> if the userspace also uses the "canonicalized" values for supported format enumeration purposes, then the userspace code is broken ofc
selckin1 has quit []
<sima> pq, just looking at the macros the DRM_FORMAT_MOD_*_HEIGHT() that take a parameter seem good
<sima> the ones without the parameter are the bogus canonicalized stuff
<pq> now I'm thinking the modifier HEIGHT is related to image height
<sima> pq, yeah reading the doc the column height seems to be the height of the buffer, rounded up appropriately
<sima> pq, yeah
<pq> just like stride is related to image width
<sima> so the metadata parameter would need to be the alignment value used
qaqland has joined #wayland
<sima> or whatever is used to decide how that rounding up works
mclasen has joined #wayland
paulk has joined #wayland
<sima> so yeah I guess the existing modifiers are for the dust bin, and we need new ones
<pq> is that SAND format even usable at all? Aren't all APIs everywhere missing "column pitch" from the width,height,stride tuple?
<pq> therefore the funny idea of using a format modifier to carry more free parameters
ity has joined #wayland
<sima> lol c91acda3a380b in the kernel broke this
<sima> given no one screamed, we might just be able to toss it outright
<sima> this enforces proper "did you list that specific modifier in your plane's modifier list" semantics
<sima> which vc4 very much doesn't
<pq> \o/
<sima> emersion, good news ^^
<sima> well only landed in 6.5 but still
<pq> but maybe no-one uses these for DRM FBs?
<sima> maybe
<sima> vc4 has code to support it at least
<sima> but yeah quick summary: a) this is totally broken b) we plugged this specific leak at least in kms in 6.5
mclasen_ has joined #wayland
<sima> pq, emersion also I'm thinking that even if someone reports a regression, if we cover the usual values for 720/1080/4k (both i & p) we should be good
mclasen has quit [Ping timeout: 480 seconds]
<sima> to cover regressions, if they pop up
<sima> since video
<sima> so not super worried about this anymore, but it's still bad
<any1> The latest vendor patched kernel for rpi is 6.1
<sima> yeeeehaw :-(
<sima> they'll notice in time I guess
<sima> https://paste.debian.net/hidden/a89e01f3/ example kernel fix if regressions are reported
<sima> or whatever magic values are actually used in practice
<sima> (I'm guessing in reality is some rounding to dram page size or something like that)
ity has quit [Quit: WeeChat 4.1.2]
nerdopolis has quit [Ping timeout: 480 seconds]
mclasen_ has quit [Ping timeout: 480 seconds]
mclasen has joined #wayland
Company has joined #wayland
narodnik has quit [Quit: WeeChat 4.1.2]
mclasen has quit [Remote host closed the connection]
<sima> emersion, dropped another comment into the mr, pls ping me since I tend to suck at keeping on top of gitlab pings :-/
<emersion> cool ty!
mripard_ has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
<Company> so, with compositors doing direct scanout of non-fullscreen windows with this libliftoff work landing everywhere - is it relevant if the application buffers are opaque? Or is it fine to use transparency on overlay planes?
<mripard_> sima: thanks
<emersion> it's always nice to know when a buffer is opaque
<pq> Company, if you can provide guarantees of opaqueness via pixel format or wl_surface opaque region, it does increase the probability of being able use a KMS plane for it.
<Company> most application code doesn't bother because it just wasn't an issue
<pq> but it's not a strict requirement
<Company> and I'm wondering if I should file bugs / add comments for them every time
<Company> they just create an AR24 buffer because why not?
<pq> I think it would be good to teach people to think about opaqueness.
<pq> even if the compositor does not use KMS planes, knowing that a surface is opaque will allow reducing the GPU work.
<Company> yeah, the whole opaque region story
<pq> isn't that reason enough?
<Company> apparently not or everyone would be doing it already...
<pq> maybe they didn't know about even that
Leopold_ has joined #wayland
<Company> actually, most of those buffers ended up in GTK and where composited there, that only gets relevant with the recent offloading work
<pq> if GTK knew they were opaque, also GTK could probably save in GPU work?
<Company> the 2 cases where I recently figured out they use RGBA is the webpage dmabufs used by Epiphany and the videos GStreamer sends to GTK from its GL pipeline
<Company> yes, GTK could probably optimize things, too
<Company> but it doesn't - even the opaque region is a custom codepath still when we could deduce it from the render tree
<Company> I've wondered how much we could gain there - because there's often cases where backgrounds get overdrawn multiple times
<Company> like text editors draw the window background first and then draw the text area's background on top
<pq> I suppose that depends on the number of polygons painted vs. their area.
<Company> but of course, the text area oftenends up with rounded corners and then...
<Company> it's 2 huge triangles (or maybe 2 huge and 16 smaller ones if it 9-slices because of rounded corners)
<Company> but the problem there is the number of pixels touched
<pq> the area, yes
<Company> but then, text editors usually aren't limited by draw performance
kts has quit [Ping timeout: 480 seconds]
kts has joined #wayland
<Company> but I think it could help to do those optimizations to achieve smoother scrolling on lower-powered hardware, like rpi and such
<Company> that also tells you how important it is I guess
<emersion> could also help battery-powered devices
<pq> battery life, yes
<Company> yeah, there's probably a lot that could be done there, but it's both hard to measure and there's bigger fish there
<Company> nobody is gonna praise longer battery life when they switch from vscode or whatever to vim in a terminal as their editor
<Company> and if they did, it'd be because they don't run all the background tasks anymore that are compiling everything on every keypress
<sima> Company, yeah reducing wasted memory bandwidth for rendering is a really hard one that needs all the details right
<sima> you need incremental drawing with buffer_age and damage rectangles everywhere
<sima> that's already a big one depending upon hw
<sima> then app needs to draw it all in one go (one render pass in vulkan, gl with a good driver no glsync or readback or anything like that) or you hurt tiled renders real bad
<sima> then the entire opaqueness thing
<sima> and it's all end-to-end, if anything in the app -> renderer -> protocol -> compositor -> display driver/hw screws up it's over
ity has joined #wayland
dri-logg1r has joined #wayland
dri-logger has quit [Ping timeout: 480 seconds]
privacy has joined #wayland
<Company> yeah
<Company> but the cases that are worth optimizing are always the ones where those features don't work
<Company> like scrolling in a text editor turns the damaged region into the full window and all your damage rects don't help you
kts has quit [Ping timeout: 480 seconds]
alatiera has joined #wayland
nerdopolis has joined #wayland
ity has quit [Quit: WeeChat 4.2.1]
dogukan has joined #wayland
ity has joined #wayland
qaqland has quit [Ping timeout: 480 seconds]
dogukan has quit [Quit: Konversation terminated!]
nerdopolis has quit [Ping timeout: 480 seconds]
ity has quit [Quit: WeeChat 4.2.1]
Guest790 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest1098
Guest1098 has quit [Remote host closed the connection]
cool110_ has joined #wayland
cool110_ is now known as Guest1100
mclasen has joined #wayland
Guest1100 has quit [Remote host closed the connection]
ity has joined #wayland
cool110- has joined #wayland
cool110- has quit [Remote host closed the connection]
cool110- has joined #wayland
<MrCooper> pq: re https://gitlab.freedesktop.org/wayland/weston/-/issues/871 it's doubtful that compositing would make a big difference with Xorg; in particular, it wouldn't directly affect how XVideo handles colour space conversion and scaling
ity has quit [Remote host closed the connection]
ity has joined #wayland
<MrCooper> Company: FWIW, optimizing all those things is particularly important for software rendering, some of the lower-hanging fruit for that
<Company> I am well aware of the theory
<Company> but I'm also aware that software rendering doesn't even support buffer-age yet
<MrCooper> hmm, not even the native Wayland platform?
<MrCooper> anyway, should be fixable
<Company> LIBGL_ALWAYS_SOFTWARE=1 gtk4-widget-factory
<Company> and no damage tracking will happen
<Company> all of that is a case of "only 24h in a day" - other stuff is more important, but in theory it'd be cool to have
<MrCooper> huh yeah, only GBM platform seems to support buffer age with llvmpipe
ity has quit [Quit: WeeChat 4.2.1]
<zamundaaa[m]> Damage tracking might not happen on the client side, but opaque culling is still done on the compositor side
<MrCooper> I suspect it's some kind of silly oversight with the Wayland platform
<Company> lavapipe does damage tracking iirc
<swick[m]> Company: when you can break API you really should switch any kind of importing buffers to assume the imported image is opaque by default
<emersion> that sounds pretty error prone…
<Company> swick[m]: people need to specify the buffer format - and they'll always pick RGBA
<Company> because RGBA is just less work
<Company> see also: cairo_surface_create()
<swick[m]> sure, but then just have another HAS_ALPHA flag
<swick[m]> and internally switch it to an opaque variant if it's not set
<swick[m]> whoever actually needs alpha will notice and turn it on
<Company> everyone will turn it on
<Company> because otherwise sometimes stuff is black
Leopold_ has quit [Remote host closed the connection]
<pq> MrCooper, compositing does not forbid Xv?
<Company> people will treat it as _set_not_buffy (TRUE)
<Company> *buggy
<MrCooper> pq: nope
<pq> MrCooper, so there is code to route Xv adapters through a compositing manager?
<MrCooper> of course not :)
<pq> MrCooper, then how does it work? Breaks into pieces?
<swick[m]> Company: dunno man, I think a lot of people just choose RGBA without thinking and if you make them think they will more likely do the right thing
<MrCooper> if it's an overlay, the compositing will only affect the colour key, not the video content itself; otherwise it's just a textured blit
<swick[m]> but if they always get alpha by accident they will never notice and never have to think
<Company> yeah, I know
<Company> but your fix doesn't work either
<Company> because then they will think for 5s until they find the has_alpha toggle, set it, and continue not thinking about it
<pq> MrCooper, sounds like it'll break into pieces then, if it bypasses the compositing manager on its way to screen.
<Company> and all that toggle will be known for is the stack overflow posts where people go "oh, it's buggy if you don't set it"
<swick[m]> if it's buggy, they need alpha...
<MrCooper> pq: an overlay will break if the window isn't displayed at its canonical position, a texture XVideo adapter works fine with compositing
ity has joined #wayland
<swick[m]> sure, maybe there are cases where only some data contains actual alpha and a lot of other cases don't, but this still seems like a good improvement overall
<swick[m]> because you definitely get all those cases where alpha is not required at all
<Company> sure, but the way to go there is education
<swick[m]> no offense, but you do that by creating APIs that make it hard to do the wrong thing
<Company> sure, I'll wait for that API to appear
<Company> because for opaqueness the problem is that you need to do deliberate work to check if your stuff is opaque, so the opaque-by-default approach doesn't work
<swick[m]> you're basically saying a better API is not better because it can still be misused
<swick[m]> and that's really weird to me
<pq> MrCooper, interesting. I only have hazy recollections from many years ago, that the coming of compositing managers somehow made Xv break.
<Company> I'm saying it's not a better API
ity has quit [Remote host closed the connection]
ity has joined #wayland
<swick[m]> it's obvious that it's better. if alpha is not required generally in a call to import a buffer, then the new API gives you opaqueness even if the user mindlessly chooses RGBA
<MrCooper> pq: yes, at the time most Xv adaptors were overlay based, and there were issue with compositing; these days Xorg drivers mostly expose only textured adaptors (as does Xwayland) for that reason
<Company> no, it's obviously worse
<pq> MrCooper, aha, thanks.
<Company> because it causes broken results in cases where an alpha-by-default API wouldn't
<swick[m]> it breaks by giving and obvious error that can be fixed
<Company> yes, but it's giving you an error
<swick[m]> yes, and that's a good thing
<Company> only if you can guarantee that it is caught during testing
<Company> and doesn't end up in users' hands
bnason has joined #wayland
<Company> it's basically why HTML won and XHTML lost
<kennylevinsen> no XHTML lost because it added no value
<kennylevinsen> strictly XML does not function any different from the non-XML form - it's just aesthetic for the person looking at said markup
<Company> it's also much easier to parse spec-compliant XML than it is to write HTML parsers
<kennylevinsen> (HTML's deviations from XHTML are now strictly defined, including auto-opening and auto-ending tags)
<Company> you can almost use a regexp!
<kennylevinsen> Quite the contrary, xml namespaces! dtd you need to download during parsing! :)
<kennylevinsen> html just has a handful of rules like "<body> open implicitly ends <head>, body-only tags implicitly open <body>"
<Company> xml wants everything to be quoted, too and html can do fine without that
<kennylevinsen> that doesn't make it harder to parse, it's just a small syntax difference
<Company> I didn't actually check if that's true - it might very well be harder to parse
<Company> mostly because I've watched lots of fun talks on how json parsers work
<kennylevinsen> yeah, fully spec compliant JSON with all the bells and whistles is... quirky
<Company> anyway, the problem with opaqueness is that people will almost always go with transparent and then think they'll "fix it later"
<Company> so I think the cairo approach of letting people explicitly say that the want transparency is the best one: It makes them consider if they should care about it, but if they don't want to, they don't end up with brokenness
<Company> and that's basically the approach with Wayland/dmabuf formats, too - you have to pick one and it makes you consider which one
<ManMower> we should scan client buffers to make sure they actually use alpha, and disconnect them for using opaque ARGB buffers.
<Company> kill all the video players!
<ManMower> ooi, do they at least set an opaque region?
<Company> I don't even know what video players do
<kennylevinsen> well, letting people explicitly say that they want transparency vs. defaulting to be opaque kind of sounds like the same thing... :)
<Company> *Explicitly say what format they want
rasterman has joined #wayland
<Company> so you need to be explict about opaque, too
<YaLTeR[m]> ManMower: then game devs will come knocking who set format to xrgb then use alpha channel as internal data storage
cool110- has quit [Remote host closed the connection]
<Company> like zwp_linux_buffer_params_v1::create() could come without a format and default to XRGB unless you called like zwp_linux_buffer_params_v1::set_format() before
<ManMower> YaLTeR[m]: well, 2 things. one is that I was joking, and the other is that I would never suggest scanning an XRGB buffer, because that's a completely legit use case.
cool110 has joined #wayland
cool110 is now known as Guest1103
<Company> you're meant to scan ARGB buffers anyway
<kennylevinsen> Those precious 8MB of unused alpha-channel in a 4k buffer...
ity has quit [Quit: WeeChat 4.2.1]
<Company> XRGB is known to be opaque already
<kennylevinsen> we're not meant to *scan* ARGB buffers, we're just meant to composite them with blending
<kennylevinsen> or offload them if we can
<Company> kennylevinsen: it's a fun question if your PNG loader should load into RGB vs XRGB buffers
<kennylevinsen> Although I have had a long-standing project idea of a test compositor that actively scanned submitted buffers to report correctness of e.g. damage and opaqueness
<ManMower> while I haven't read the entire discussion, this comes to mind as a case where using alpha when not necessary leads to underleveraging available display hardware: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1258
<Company> with those 20k images, you can end up with almost 100MB of junk bytes
<YaLTeR[m]> Company: I think gpus don't like 24-bit formats
<Company> YaLTeR[m]: yeah - but GPUs also don't like OOMing
ity has joined #wayland
<Company> and I think RGB is readable everywhere
cool110_ has joined #wayland
cool110_ is now known as Guest1105
<Company> also, mpv uses XR30 to play my video, so my GStreamer GTK plugin dissing does not apply to other video players
Guest1103 has quit [Ping timeout: 480 seconds]
<Company> afaik GStreamer doesn't have an XRGB format though, so I might be able to diss it in general, not just the plugin
<Company> but YaLTeR[m] would know that better than me
<YaLTeR[m]> when I tried alpha formats from the caps in gst paintable sink, everything broke
<YaLTeR[m]> although allegedly it's supposed to work
<Company> there's a difference between actually having alpha and making sure to not advertise alpha
Leopold_ has joined #wayland
<Company> and I think GStreamer has no way to have 32bit RGBX buffers
<Company> well, unless you use the new dmabuf stuff, where you can just use DRM_FORMAT_XR24
<Company> but I was thinking memory RGB buffers
<daniels> BGRx and RGBx have always been supported as raw video formats in GSt
<Company> good to know - maybe people just forgot to add them to the plugins I looked at
garnacho has joined #wayland
Guest1105 has quit [Remote host closed the connection]
cool110- has joined #wayland
ity has quit [Quit: WeeChat 4.2.1]
zxrom has joined #wayland
kts has joined #wayland
Leopold_ has quit [Remote host closed the connection]
<MrCooper> Company: FWIW, non-ancient AMD GPUs don't actually support 3-byte RGB formats, GL_RGB uses 4 bytes per pixel
ity has joined #wayland
<Company> so it's all faked in the driver again
tzimmermann has quit [Quit: Leaving]
leon-anavi has quit [Remote host closed the connection]
garnacho has quit [Ping timeout: 480 seconds]
mclasen has quit [Ping timeout: 480 seconds]
narodnik has joined #wayland
andreasbackx has joined #wayland
___nick___ has joined #wayland
kts has quit [Quit: Leaving]
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
flom84 has joined #wayland
flom84 has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
Leopold_ has joined #wayland
vincejv_ has joined #wayland
selckin has joined #wayland
vincejv has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
vincejv_ has quit []
vincejv has joined #wayland
glennk has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
mort_ has joined #wayland
Leopold_ has joined #wayland
andreasbackx has quit [Remote host closed the connection]
Leopold_ has quit [Remote host closed the connection]
garnacho has joined #wayland
MajorBiscuit has joined #wayland
MajorBiscuit has quit []
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
mclasen has joined #wayland
Leopold_ has joined #wayland
mclasen has quit []
mclasen has joined #wayland
rv1sr has quit []
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
privacy has quit [Remote host closed the connection]
codecolla has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
<zamundaaa[m]> Gmail seems to be swallowing some notification emails from fdo gitlab lately... If I don't respond somewhere in time, please feel free to ping me about it here or anywhere else that isn't gitlab
<zamundaaa[m]> drakulix: all your responses to my dmabuf MR are missing from my emails for example
<zamundaaa[m]> But the ones from Simon seem to be all there
<drakulix[m]> zamundaaa[m]: I have had the same problem in reverse. Your answers are missing, but Simons come through.
Leopold_ has quit [Remote host closed the connection]
<zamundaaa[m]> Guess we have to check wayland-protocols threads manually for now :/
___nick___ has quit [Ping timeout: 480 seconds]
<emersion> or find a better email provider
sima has quit [Ping timeout: 480 seconds]
<drakulix[m]> I self-host the address in question and my logs don't show any rejected mails for today. So this isn't necessarily looking like a problem on our side.
<emersion> hm
cool110- has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest1133
Guest1133 has quit [Remote host closed the connection]
cool110_ has joined #wayland
cool110_ is now known as Guest1135
Leopold_ has joined #wayland
<Company> zamundaaa[m]: I've had gmail mark random gitlab.fdo mails as spam
Leopold_ has quit [Remote host closed the connection]
<zamundaaa[m]> hmm, nothing in spam
<zamundaaa[m]> maybe it's a Gitlab issue
vaxry_ has joined #wayland
Leopold_ has joined #wayland
vaxry has quit [Remote host closed the connection]
vaxry_ has quit [Read error: Connection reset by peer]
<emersion> i tweaked a few knobs, hopefully should be a bit better now
mvlad has quit [Remote host closed the connection]
qaqland has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #wayland
vaxry has joined #wayland
Leopold has quit [Remote host closed the connection]
vaxry has quit [Read error: Connection reset by peer]
Leopold_ has joined #wayland
privacy has joined #wayland
vaxry has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
d42 has quit []
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
lsd|2 has joined #wayland
nerdopolis has joined #wayland
codecolla has quit [Quit: Leaving]
Th3C1ph3r3r has joined #wayland
Th3C1ph3r3r has quit [Quit: leaving]
d42 has joined #wayland