00:04exkc: whot1: i think it is both a touch pad and touch screen drvier
00:05exkc: maybe also stylus?
00:15soreau: exkc: not to be assumed
00:16exkc: alr
00:51exkc: sry
00:52karl3fox: That's legit soreau, ill go fixate my ADHD brain on something else for a bit
01:45karenw: Is it possible to force libdecor to select a different backend?
01:45karenw: s/backend/plugin
01:47riteo: karenw: I have no idea either but a quick workaround I use is copying the plugin I need to a random dir and set the libdecor plugin dir env var to point to it
01:47riteo: one sec I'll look it up cause I don't remember it by heart
01:48riteo: `LIBDECOR_PLUGIN_DIR`
01:48riteo: also a quick `git grep getenv` returns no envar that might do that, so I'm afraid it's not possible to force a specific plugin
01:49karenw: I guess I can just spin up `mutter --nested` and set WAYLAND_DISPLAY to e.g. force gtk backend
01:49karenw: I'll give the LIBDECOR PLUGIN DIR a go, thanks.
02:03riteo: yw
05:52vyivel: hm w-p 1.38 isn't on https://wayland.freedesktop.org/releases.html
11:01emersion: jadahl: ^
18:19dviola: hi, the issue I mentioned the other day with fonts disappearing after my monitor going off/on with bitcoin-qt also happens with other qt5 apps (keepassxc), so it's probably something else other than the app itself, how can I rule out this being a qt5 issue or a driver/xwayland issue?
18:31kennylevinsen: dviola: Drivers and Wayland are not involved in fonts. Wayland deals with stuff that has finished drawing
18:33dviola: makes sense
18:33kennylevinsen: Fonts would be dealt with by some combination of harfbuzz, pango, fontconfig - or whatever qt decided to use
18:35kennylevinsen: Not familiar with what font bits X11 might expose on the Xwayland side though
18:54dviola: I see, for some reason adding fonts like terminus-font makes things a little better, removing it makes it worse
18:55dviola: by worse I mean, fonts vanish, with terminus-font they're still readable
18:59soreau: maybe you can compare wayland and x11 backends with a qt app that supports both by setting QT_QPA_PLATFORM
18:59dviola: I'm puzzled because I can seem to only trigger this when running a wayland session with xwayland, doesn't happen at all if I run e.g. i3 and then sway+xwayland inside of it
19:00soreau: so it only happens with drm backend, not wayland backend?
19:00dviola: soreau: with xcb afaik, but yes
19:03dviola: soreau: i.e. it's fine with QT_QPA_PLATFORM=wayland but not with QT_QPA_PLATFORM=xcb
19:04dviola: with qt6 it's fine with both, xcb and wayland
19:04soreau: sounds like a qt5 xcb platform bug then?
19:04dviola: yeah
19:04soreau: and it sounds like you have enough to file a qt(5) issue..
19:05soreau: but since it's working in qt6, maybe the answer is to upgrade to qt6
19:06dviola: right, thanks
19:06soreau: 👍
23:21dviola: I think something on kernel 6.11.6-arch1-1 introduced a regression, now sway on QEMU has the mouse inverted down
23:22dviola: WLR_RENDERER=pixman makes it go away
23:25dviola: qemu -device virtio-vga-gl -display gtk,gl=on
23:25dviola: will need to bisect but I wonder if 6.12 makes it go away