06:17 wlb: weston Issue #966 opened by () Crash on cleanup when failing to bind to Xwayland https://gitlab.freedesktop.org/wayland/weston/-/issues/966
06:56 exxxxkc: hi
07:37 ity: Hi, we are using libwayland-client; Our xdg_toplevel::configure handler is slow, and we have issues where that makes certain events which should have immediate feedback, such as xdg_toplevel::close, take much longer - is there some way to work around this ?
07:50 vyivel: ity: make xdg_toplevel.configure handler faster?
07:51 vyivel: also i feel like you're doing something wrong, xdg_toplevel.configure handler should just store the size and do nothing else until xdg_surface.configure
12:23 exxxxkc: hey
12:24 exxxxkc: I have a wired touch screen that would send ABS_PRESSURE to userland
12:24 exxxxkc: libput dont support ABS_PRESSURE on userland
12:24 dviola: hi, I have a qt 5.x app that misbehaves when running it from xwayland, some fonts appear to vanish after turning my monitor off and on again, this happens with different compositors (sway, hyprland, weston), but it doesn't under X11 (with or without a compositor)
12:25 dviola: I've been trying to compile xwayland, but I can only reproduce it when xwayland is running with -rootless
12:25 dviola: my question is: is there a way I can run xwayland -rootless myself? or is that something the comositor have to do?
12:25 ofourdan: only the compositor
12:25 exxxxkc: * libput dont support ABS_PRESSURE on toruch screen
12:26 dviola: I would like to try to compile xwayland myself to see if it's a regression
12:26 dviola: but I have a difficult time trying to do that
12:26 exxxxkc: dviola: how much u know about libinput
12:27 dviola: exxxxkc: I know what it is, but nothing more than that
12:28 exxxxkc: ah
12:28 ofourdan: are these fonts core x11 fonts or xft? I suspect the latter.
12:28 exxxxkc: how dead the chat?
12:28 dviola: xft, I think
12:28 ofourdan: can you try setting XWAYLAND_NO_GLAMOR=1 in /etc/environment, restart your sessio nand see if that helps?
12:29 dviola: I think I just tried that already, let me try one more time
12:30 zamundaaa[m]: exxxxkc: you not getting a response to what isn't even a question within 5 minutes does not mean the chat is dead...
12:30 exxxxkc: yeah
12:31 zamundaaa[m]: If you have a question, it might help to ask it
12:31 exxxxkc: i should say how active the chat
12:31 dviola: yeah, doesn't help
12:31 exxxxkc: whatever
12:31 exxxxkc: wait r u matrix?
12:31 exxxxkc: *from
12:31 ofourdan: dviola: which hardware/driver is that?
12:32 ofourdan: and does that happen with non-Qt apps as well?
12:32 zamundaaa[m]: exxxxkc: yes
12:32 dviola: 03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Navi 22 [Radeon RX 6700/6700 XT/6750 XT / 6800M/6850M XT] (rev c5)
12:32 dviola: amdgpu
12:32 exxxxkc: matrix root id?
12:32 exxxxkc: *room
12:33 dviola: ofourdan: no, it happens with _one_ qt app as far as I am aware
12:33 zamundaaa[m]: exxxxkc: #_oftc_#wayland:matrix.org
12:33 ofourdan: humm, I doubt this is an Xwayland bug
12:33 dviola: ofourdan: I thought that it would be because it works fine with X11
12:34 dviola: I am aware that doesn't mean much but...
12:34 exkc: test
12:35 ofourdan: when you say turning off and on your monitor, it's the only monitor on the system, so turning it off means your system goes headless?
12:36 dviola: right, single monitor setup
12:36 dviola: I suspect some dpms thing because I tried turning off the monitor via sway itself, e.g. timeout 600 'swaymsg "output * power off"' resume 'swaymsg "output * power on"' and can't reproduce it
12:37 davidre: exxxxkc if libinput does not support pressure on touch screens at all, I think the best way is to open an issue on libinput repo with information about your device and what events it prodices
12:37 exxxxkc: davidre: the touch screen is weird
12:37 davidre: But the whole stack does not support pressure from touch , i.e. wl_touch does not have touch either
12:37 dviola: only when I turn it off physically
12:37 davidre: what supports pressure is tablets
12:38 exxxxkc: yep
12:38 exxxxkc: but my touch screen is weird
12:38 exxxxkc: it dont support pressure but it use ABS_pressure
12:39 davidre: Best still to file an issue
12:39 davidre: so maybe libinput can adda a quirk for it and makre it work
12:40 exxxxkc: it is working but
12:40 davidre: whot: is probably already asleep
12:40 davidre: so it doesnt get lost
12:41 exxxxkc: libinput dont support one of its cool unique feature
12:41 davidre: Yeah so file an issue with the info
12:41 davidre: so it can add support
12:41 davidre: Not sure you will get anything else here right now
12:42 exxxxkc: I want a discussion about itbut I'm a bit doubtfull on making a issue
12:42 exxxxkc: anyway i will make one
12:43 davidre: thanks. An issue is a good place to have an async discussion :)
12:44 exxxxkc: oh by the way I saw some issue regarding a tablet that has the similar toruchscreen but but that issue isn't related tothat unique feature of the toruchscreen
12:46 ofourdan: dviola: maybe a daft idea, but does it help if you try to create a fake monitor in xrandr, e.g. xrandr --setmonitor fake 0/1024x768/0+0+0 none
12:47 dviola: ofourdan: I'll try that
12:48 ofourdan: my theory is that somehow the resources associated with the font get lost when all monitors get removed
12:50 dviola: the app is bitcoin-qt from https://github.com/bitcoin/bitcoin -- I'm running it with ./bitcoin-qt -connect=0 otherwise it starts synchronizing, I just want to deal with the GUI part for now
12:51 ofourdan: ah, it's an open source app apparently
12:53 ofourdan: all I have here are laptops, so I don't have a way to physically unplug all monitors from any of my systems - besides, I have no amd system here.
12:53 dviola: ah
12:54 davidre: ofourdan: you could hack your compositor to remove all wl_outputs :D
12:54 ofourdan: I could…
12:54 davidre: Usability might suffer a bit :D
12:54 ofourdan: there's ssh
12:56 ofourdan: if you run mutter --headless, by default, there is no monitor
12:57 ofourdan: but I am not sure this is the same as startign the client with a monitor, then removing the monitor
13:01 dviola: ofourdan: I'm compiling their qt6 port, looks like they'll switch to that soon, just want to see if I can reproduce it with that, then I'll try your xrandr suggestion
13:03 davidre: dviola: Does the app force X connection somehow
13:03 davidre: given that it's Qt it should do wayland fine...
13:05 ofourdan: that's a good point, how certain are we this is actually using Xwayland?
13:05 dviola: looks like the issue is gone with the qt6 port
13:05 dviola: davidre: good question: I can only reproduce it when I don't have the qt5-wayland plugin installed, i.e. when the app runs with the xcb plugin, if I install the qt5-wayland package (on archlinux) the issue never occurs, so maybe the answer is yes?
13:06 dviola: why I don't just use the qt5-wayland package, well... I could. but I want to figure out why the issue happens with xcb
13:06 davidre: ok then it is indeed using qt5
13:07 davidre: But do you also have qt6-wayland?
13:07 dviola: davidre: nope
13:07 davidre: So it seems a client side issue somehow if just upgrading qt makes it work
13:07 dviola: right
13:08 dviola: could be some qt5 issue?
13:08 davidre: But if there are no problems on X or when using wayland directly I wonder how worth it is to invesigate
13:08 davidre: since qt 5 is EOL
13:08 davidre: and qt supports wayland fine
13:23 dviola: ofourdan: I have some questions about the xrandr suggestion, should I do that from Xwayland (non-headless)?
13:23 ofourdan: yeah
13:23 dviola: ah, let me try
13:23 ofourdan: before removing the "real" monitor - This is just an idea though, unlikely to help much.
13:24 dviola: np, happy to try anyway
13:26 ofourdan: the command I gave you was wrong btw, it should read instead: xrandr --setmonitor fake 1024/520x768/320+0+0 none
13:27 ofourdan: (not that it would make any difference I presume)
13:30 dviola: I tried that but it doesn't look like it did anything, I could not see the fake output after doing a `xrandr`, should there be something there? and the issue is not present when running it non-headless
13:31 ofourdan: xrandr --listmonitors should list the "fake" monitor
13:31 dviola: I can only trigger it with -rootless
13:31 dviola: ah ok
13:32 ofourdan: it is just to make sure at least one monitor remains, as a test, to see if that helps
13:32 dviola: yeah I see the fake one with --listmonitors
13:33 dviola: I can't trigger the issue with and without that, only when the wayland compositor spawns the Xwayland process itself with -rootless)
13:34 ofourdan: when running rootful, Xwayland keeps the monitor - only when running rootless it reclects on the actual monitors, that doesn't mean the bug is with Xwayland rootless though.
13:35 dviola: I see
13:35 ofourdan: s/keeps the monitor/create its own logical monitor/
13:38 ofourdan: maybe try assigning the fake monitor to the real output?
13:40 ofourdan: nah…
13:40 dviola: I thought I'd post some screenshots, this is how it looks like normally: http://0x0.st/X0Yr.png -- after I turn the monitor off/on: http://0x0.st/X0Ys.png
13:41 ofourdan: that reminds me of when the textures for the fonts were disposed, with some other driver
13:42 dviola: the strange thing is that not all fonts are gone
13:43 dviola: I remember having some font issues on this machine too, a long time ago... some scissor bug that mareko fixed it: https://bugs.freedesktop.org/show_bug.cgi?id=110214
13:43 dviola: not sure it's related
13:43 dviola: that was on X, with xterm... but back then I didn't have the dedicated GPU
13:46 dviola: it looks like it was fixed by pepp, sorry
13:47 dviola: anyway, I could try to reproduce it on another machine... but my other machines are laptops and I don't know how to turn the monitor off on those
13:55 dviola: I had a few of those scissor bugs, this was another one:
13:55 dviola: https://bugs.freedesktop.org/show_bug.cgi?id=110355
13:55 dviola: that's the one that mareko fixed it
13:57 dviola: anyway, thanks for your help y'all, happy to test something else if you want to investigate the bug, otherwise I'm happy to just use that qt6 port
13:59 dviola: s/fixed it/fixed/
14:49 MrCooper: ofourdan: FWIW, GPU / drivers shouldn't really matter for this issue when glamor is disabled in Xwayland?
14:50 ofourdan: yes, although I am not sure whre the font are actually stored, could be client side.
14:50 ofourdan: (in which case disabling glamor in Xwayland would make no difference, presumably)
14:52 MrCooper: the client doesn't use HW acceleration either without glamor
14:53 ofourdan: humm, right, it would use swrast
16:26 ofourdan: hey, anyone could approve the post from jose exposito to the xorg mailing list?
16:27 ofourdan: duh, wrong channel!
17:01 ity: vyivel: "just make the handler faster" is a non-solution - is there really no way to peek into the queue? And we will look into the xdg_surface::configure, thank you.
18:00 kennylevinsen: ity: no, there is no way to peek into the queue. But if you have a very long running handler (that must be on the main thread) where you wanted to place such "peeks", it sounds like you have a way to break up the work to do it incrementally and let regular dispatches make the app responsive.
18:01 kennylevinsen: plenty of ways to do that: if you have an event loop it will have a way to register an idle event, otherwise you could just have your "while (wl_display_dispatch() != -1) { ... }" loop check if it has work to do in between dispatch calls and keep track.
18:03 kennylevinsen: or try to move that work to a thread
18:18 ity: Like, do the work after all events were processed? Hmm
18:34 kennylevinsen: If it's not that it takes long but you just don't want it to happen during the configure as important stuff happens after, yeah - idle handlers would be stuff that's run at the end after everything else is processed but before you go to sleep for more stuff.
18:35 kennylevinsen: if it takes too long so that it will block the process, break it up into chunks or use a thread for it