ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
sima has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
CME has quit [Ping timeout: 480 seconds]
Calandracas has joined #wayland
CME has joined #wayland
Brainium_ has quit []
glennk has quit [Ping timeout: 480 seconds]
kasper93 has joined #wayland
paulk has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
paulk has joined #wayland
larunbe has joined #wayland
alarumbe has quit [Ping timeout: 480 seconds]
adamtajti_ has joined #wayland
adamtajti has quit [Read error: Connection reset by peer]
<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 ?
kode54 has quit [Ping timeout: 480 seconds]
<vyivel>
ity: make xdg_toplevel.configure handler faster?
<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
rgallaispou has quit [Remote host closed the connection]
dviola has joined #wayland
<exxxxkc>
hey
<exxxxkc>
I have a wired touch screen that would send ABS_PRESSURE to userland
<exxxxkc>
libput dont support ABS_PRESSURE on userland
<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)
<dviola>
I've been trying to compile xwayland, but I can only reproduce it when xwayland is running with -rootless
<dviola>
my question is: is there a way I can run xwayland -rootless myself? or is that something the comositor have to do?
<ofourdan>
only the compositor
<exxxxkc>
* libput dont support ABS_PRESSURE on toruch screen
<dviola>
I would like to try to compile xwayland myself to see if it's a regression
<dviola>
but I have a difficult time trying to do that
<exxxxkc>
dviola: how much u know about libinput
Moprius has quit [Ping timeout: 480 seconds]
<dviola>
exxxxkc: I know what it is, but nothing more than that
<exxxxkc>
ah
<ofourdan>
are these fonts core x11 fonts or xft? I suspect the latter.
<exxxxkc>
how dead the chat?
<dviola>
xft, I think
<ofourdan>
can you try setting XWAYLAND_NO_GLAMOR=1 in /etc/environment, restart your sessio nand see if that helps?
<dviola>
I think I just tried that already, let me try one more time
<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...
<exxxxkc>
yeah
<zamundaaa[m]>
If you have a question, it might help to ask it
<exxxxkc>
i should say how active the chat
<dviola>
yeah, doesn't help
<exxxxkc>
whatever
<exxxxkc>
wait r u matrix?
<exxxxkc>
*from
<ofourdan>
dviola: which hardware/driver is that?
<ofourdan>
and does that happen with non-Qt apps as well?
<dviola>
ofourdan: I thought that it would be because it works fine with X11
exkc has joined #wayland
<dviola>
I am aware that doesn't mean much but...
<exkc>
test
<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?
<dviola>
right, single monitor setup
<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
<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
<exxxxkc>
davidre: the touch screen is weird
<davidre>
But the whole stack does not support pressure from touch , i.e. wl_touch does not have touch either
<dviola>
only when I turn it off physically
<davidre>
what supports pressure is tablets
<exxxxkc>
yep
<exxxxkc>
but my touch screen is weird
<exxxxkc>
it dont support pressure but it use ABS_pressure
<davidre>
Best still to file an issue
Brainium has joined #wayland
<davidre>
so maybe libinput can adda a quirk for it and makre it work
<exxxxkc>
it is working but
<davidre>
whot: is probably already asleep
<davidre>
so it doesnt get lost
<exxxxkc>
libinput dont support one of its cool unique feature
<davidre>
Yeah so file an issue with the info
<davidre>
so it can add support
<davidre>
Not sure you will get anything else here right now
<exxxxkc>
I want a discussion about itbut I'm a bit doubtfull on making a issue
<exxxxkc>
anyway i will make one
<davidre>
thanks. An issue is a good place to have an async discussion :)
<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
<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
<dviola>
ofourdan: I'll try that
<ofourdan>
my theory is that somehow the resources associated with the font get lost when all monitors get removed
<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
<ofourdan>
ah, it's an open source app apparently
<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.
<dviola>
ah
<davidre>
ofourdan: you could hack your compositor to remove all wl_outputs :D
<ofourdan>
I could…
<davidre>
Usability might suffer a bit :D
<ofourdan>
there's ssh
<ofourdan>
if you run mutter --headless, by default, there is no monitor
<ofourdan>
but I am not sure this is the same as startign the client with a monitor, then removing the monitor
<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
<davidre>
dviola: Does the app force X connection somehow
<davidre>
given that it's Qt it should do wayland fine...
pramodvu has joined #wayland
<ofourdan>
that's a good point, how certain are we this is actually using Xwayland?
<dviola>
looks like the issue is gone with the qt6 port
<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?
<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
<davidre>
ok then it is indeed using qt5
<davidre>
But do you also have qt6-wayland?
<dviola>
davidre: nope
<davidre>
So it seems a client side issue somehow if just upgrading qt makes it work
<dviola>
right
<dviola>
could be some qt5 issue?
<davidre>
But if there are no problems on X or when using wayland directly I wonder how worth it is to invesigate
<davidre>
since qt 5 is EOL
<davidre>
and qt supports wayland fine
Fxzxmic has joined #wayland
Fxzxmic has quit []
Fxzxmic has joined #wayland
Fxzxmic has quit []
Fxzxmic has joined #wayland
Fxzxmic has quit []
Fxzxmic has joined #wayland
<dviola>
ofourdan: I have some questions about the xrandr suggestion, should I do that from Xwayland (non-headless)?
<ofourdan>
yeah
<dviola>
ah, let me try
<ofourdan>
before removing the "real" monitor - This is just an idea though, unlikely to help much.
<dviola>
np, happy to try anyway
Fxzxmic has quit []
Fxzxmic has joined #wayland
<ofourdan>
the command I gave you was wrong btw, it should read instead: xrandr --setmonitor fake 1024/520x768/320+0+0 none
<ofourdan>
(not that it would make any difference I presume)
<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
<ofourdan>
xrandr --listmonitors should list the "fake" monitor
pramodvu has quit [Quit: Konversation terminated!]
<dviola>
I can only trigger it with -rootless
pramodvu has joined #wayland
<dviola>
ah ok
<ofourdan>
it is just to make sure at least one monitor remains, as a test, to see if that helps
iomari891 has joined #wayland
<dviola>
yeah I see the fake one with --listmonitors
<dviola>
I can't trigger the issue with and without that, only when the wayland compositor spawns the Xwayland process itself with -rootless)
<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.
<dviola>
I see
<ofourdan>
s/keeps the monitor/create its own logical monitor/
<ofourdan>
maybe try assigning the fake monitor to the real output?
garnacho has quit [Read error: Connection reset by peer]
<dviola>
that was on X, with xterm... but back then I didn't have the dedicated GPU
<dviola>
it looks like it was fixed by pepp, sorry
<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
<dviola>
I had a few of those scissor bugs, this was another one:
<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
<dviola>
s/fixed it/fixed/
gryffus has joined #wayland
kts has joined #wayland
<MrCooper>
ofourdan: FWIW, GPU / drivers shouldn't really matter for this issue when glamor is disabled in Xwayland?
<ofourdan>
yes, although I am not sure whre the font are actually stored, could be client side.
<ofourdan>
(in which case disabling glamor in Xwayland would make no difference, presumably)
<MrCooper>
the client doesn't use HW acceleration either without glamor
<ofourdan>
humm, right, it would use swrast
gryffus has quit [Remote host closed the connection]
gryffus has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
lsd|2 has joined #wayland
Fxzxmic has quit [Quit: Konversation exit!]
glennk has quit [Remote host closed the connection]
pramodvu has quit [Read error: Connection reset by peer]
pramodvu has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
iomari891 has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
kts has quit [Quit: Leaving]
Guest7098 has quit [Quit: Connection closed for inactivity]
<ofourdan>
hey, anyone could approve the post from jose exposito to the xorg mailing list?
<ofourdan>
duh, wrong channel!
<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.
karenw has joined #wayland
pramodvu has quit [Quit: Konversation terminated!]
pramodvu has joined #wayland
leon-anavi has quit [Quit: Leaving]
louis-g2 has quit [Quit: WeeChat 3.8]
rgallaispou has joined #wayland
<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.
<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.
<kennylevinsen>
or try to move that work to a thread
garnacho has quit [Ping timeout: 480 seconds]
kts has joined #wayland
<ity>
Like, do the work after all events were processed? Hmm
dviola has quit [Quit: WeeChat 4.4.2]
<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.
<kennylevinsen>
if it takes too long so that it will block the process, break it up into chunks or use a thread for it
kts has quit [Quit: Leaving]
tzimmermann has quit [Quit: Leaving]
anarsoul has joined #wayland
nysach has joined #wayland
nysach has quit [Remote host closed the connection]