ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
eluks has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
lsd|2 has joined #wayland
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
Company has quit [Remote host closed the connection]
vsyrjala_ has joined #wayland
eluks has joined #wayland
vsyrjala has quit [Ping timeout: 480 seconds]
eluks has quit [Remote host closed the connection]
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
cvmn has joined #wayland
caveman has quit [Remote host closed the connection]
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
eruditehermit has joined #wayland
eluks has quit [Remote host closed the connection]
glennk has quit [Ping timeout: 480 seconds]
<eruditehermit>
ofourdan: hello, are you around?
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
<eruditehermit>
ofourdan: I have a new input-leap for you to test if you're interested and have time. I've tested it on many systems now and it should work so I'm wondering if your system is different in any way.
eluks has quit [Remote host closed the connection]
karenw has quit [Ping timeout: 480 seconds]
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
Brainium has quit [Quit: Konversation terminated!]
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
mxz__ has joined #wayland
eluks has quit [Remote host closed the connection]
mxz_ has quit [Ping timeout: 480 seconds]
mxz has quit [Ping timeout: 480 seconds]
eluks has joined #wayland
mxz__ is now known as mxz
mxz_ has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
feaneron has quit [Ping timeout: 480 seconds]
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
kts has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
sima has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
bodiccea has quit [Quit: Leaving]
kts has quit [Quit: Leaving]
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
balrog_ has joined #wayland
balrog has quit [Ping timeout: 480 seconds]
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
tzimmermann has joined #wayland
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
<ofourdan>
hey, here now
<ofourdan>
fwiw, the last one I tried for you last week was working fine
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
glennk has joined #wayland
eruditehermit has quit [Remote host closed the connection]
eruditehermit has joined #wayland
eluks has quit [Remote host closed the connection]
<eruditehermit>
beautiful, I didn't know the logger existed
<eruditehermit>
it should show up in gnomes application thing too
<eruditehermit>
basically the .desktop file is shipping now too
<ofourdan>
gone dropped the system try long ago, you have to use an extension iirc
<ofourdan>
*GNOME
<eruditehermit>
hmm, I probably have the extension then
<eruditehermit>
there are some apps that minimize to the tray and don't die, where do they go in gnome?
<ofourdan>
ah, indeed, that's very possible, I suspects Ubuntu adds it to the default install
<eruditehermit>
yeah that's probably it
<eruditehermit>
distro specific installs
<eruditehermit>
i could spin up some fedora/arch VMs
<eruditehermit>
anyway, if you're interested in testing to see if your initial bugs/issues were fixed i'd be interested to know
<eruditehermit>
you said it already worked last time?
<ofourdan>
I'm installing it now, as we speak
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
<ofourdan>
doesn't seem to work here, sorry
<eruditehermit>
bummer
<eruditehermit>
what's the distro and setup?
eluks has joined #wayland
<eruditehermit>
others have had success on fedora
<ofourdan>
client and server do not seem to communicate, conenction from the client to theserver gets continuously refised - I tried diabling SSL (as I had issues with IL and SSL support when I was wormign on inplementing EI support) but that doesn't seem to help
<eruditehermit>
ofourdan: what DE are you using?
<MrCooper>
eluks: please fix your IRC setup
<ofourdan>
I tried with GNOME and KDE, but as I said the issue is not with the desktop, it's the communication
<ofourdan>
the client cannot conenct to the server
<eruditehermit>
I know that portal has an issue with KDE 5.27
<ofourdan>
it's not the portal :)
<ofourdan>
brb
<eluks>
MrCooper: thanks, will do so in some minutes. I seem to not be identified on my bouncer for the oftc network, even though i identified myself yesterday.
<MrCooper>
FWIW, the main issue is that you keep disconnecting and reconnecting (while on channels)
<eluks>
Can I assume the connection of the bouncer to the oftc network is instable, or can it also be the connection of my client (smartphone) to the bouncer?
<zzag>
ofourdan: what's the usecase for the _XWAYLAND_ALLOW_COMMITS property? (I think I might have asked such a question in the past, I don't remember)
<ofourdan>
it's used by the X11 window manager part of the Wayland compositor to tell Xwayland when to commit the wl_surface
<MrCooper>
zzag: it allows the compositor to prevent Xwayland from attaching buffers, e.g. while resizing a window or during a _NET_WM_SYNC transaction
<zzag>
MrCooper: can you please elaborate on the _NET_WM_SYNC part? what should a wayland compositor do?
rasterman has joined #wayland
<eruditehermit>
ofourdan: on your client side, did you set it to autodetect or did you explicitly type in the IP address of the server? I have to type in the address of the server.
<MrCooper>
zzag: when a _NET_WM_SYNC transaction starts, set _XWAYLAND_ALLOW_COMMITS such that Xwayland won't attach buffers to the surface, then when the transaction finishes clear it again
<zzag>
MrCooper: I see.. Should the wayland compositor be concerned about buffer starvation? For example, the compositor starts a transaction/blocks commits -> clients renders a new frame and acks _NET_WM_SYNC -> the compositor unblocks commits -> ... -> a new transaction starts
<zzag>
is it possible that no buffer will be attached in the "..." period?
<MrCooper>
emersion: what exactly do you see racing with what?
<emersion>
if the compositor is slow, Xwayland might still queue a new surface commit before the compositor has a chance to set _XWAYLAND_ALLOW_COMMITS?
<emersion>
disclaimer, i have a very vague idea how _NET_WM_SYNC works
<MrCooper>
zzag: not sure, IIRC Xwayland will attach a buffer immediately once the property is cleared, if there are new contents
<zzag>
so I've been wondering about the _XWAYLAND_ALLOW_COMMITS approach
<ofourdan>
oh kwin wasn't using allow commits at all before?
<zzag>
yes, tbf we had been unaware of that property
<MrCooper>
zzag: one potential issue with _XWAYLAND_ALLOW_COMMITS is that if the client uses PresentPixmap to update the window contents, that might not actually complete before _XWAYLAND_ALLOW_COMMITS is re-allowed
<MrCooper>
right, xwl_window_set_allow_commits adds the xwl_window to xwl_screen->damage_window_list, so xwl_screen_post_damage will attach a new buffer for it
mriesch has joined #wayland
<zzag>
MrCooper: okay... but that's going to work as expected only if the client renders **after** the compositor sets _XWAYLAND_ALLOW_COMMITS to true, isn't it?
<MrCooper>
in theory it is possible for another _XWAYLAND_ALLOW_COMMITS change to prevent that, in practice I think it could only happen if both _XWAYLAND_ALLOW_COMMITS change requests are part of the same client display connection flush
<MrCooper>
zzag: nope, it happens if there are any new contents since the last time a buffer was attached
<MrCooper>
(any damage)
<zzag>
MrCooper: ah... 🤦 I think I've missed the most important part. xwl_screen_post_damage() gets called every time Xwayland is about to return to spinning the event loop, right?
<zzag>
xwl_screen_post_damage() gets called by block_handler() in xwayland-screen.c
<MrCooper>
yep, exactly
<zzag>
and the block_handler() is registered by RegisterBlockAndWakeupHandlers()
<zzag>
okay, cool
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
Company has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
mclasen has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
eluks has quit [Remote host closed the connection]
fmuellner has joined #wayland
eruditehermit has quit [Quit: Konversation terminated!]
bindu_ has quit [Remote host closed the connection]
cvmn has quit [Remote host closed the connection]
bindu has joined #wayland
caveman has joined #wayland
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
RAOF has quit [Remote host closed the connection]
RAOF has joined #wayland
<zzag>
ofourdan: MrCooper: what are your thoughts about Xwayland synchronizing wl_surface::opaque_region with _NET_WM_OPAQUE_REGION? it would be sort of awkward to have Xwayland care about NetWM properties, but on the other hand, I'm not sure that the XSHAPE will gain opaque region as a native feature and for some wayland compositors supporting _NET_WM_OPAQUE_REGION creates architectural challenges
<zzag>
as far as I know, wlroots-based compositors (cc emersion) and kwin would be interested in such a feature
<emersion>
+1
<zzag>
it would also help with _XWAYLAND_ALLOW_COMMITS being easier to handle
<zzag>
because currently there are glitches caused by opaque region getting out of sync
<emersion>
MrCooper: is there an upside to _XWAYLAND_ALLOW_COMMITS vs. deferring surface commits in the compositor?
<MrCooper>
one problem with this is that mutter currently ignores wl_surface::opaque_region for Xwayland windows
<emersion>
that should be fine no?
<emersion>
mutter can continue to ignore if it has its own logic
<MrCooper>
emersion: it avoids the race you described, and avoids Xwayland wasting effort on commits which will just be ignored
<emersion>
right
<emersion>
potentially copying stuff around
<emersion>
or rendering
<zzag>
MrCooper: it could continue using _NET_WM_OPAQUE_REGION. for example, Xwayland also sets the input region: mutter ignores it but kwin (and wlroots-based compositors too?) uses it
<MrCooper>
k, then doing the same for the opaque region seems fair enough to me
<MrCooper>
well, I guess _NET_WM_OPAQUE_REGION isn't quite the same thing as the input region though?
<MrCooper>
the former is supposed to be between the client and WM, isn't it?
RAOF has quit [Remote host closed the connection]
RAOF has joined #wayland
<emersion>
or the X11 compositor?
<emersion>
(since it's transparency-related)
<ofourdan>
yes, X11 compositor
<ofourdan>
(in many cases, the x11 window manager is also the compositor)
mclasen has quit [Ping timeout: 480 seconds]
kts has joined #wayland
<MrCooper>
the point being that the X server isn't supposed to do anything with it
<emersion>
either we have a weird quirk in all Wayland compositors, either we have it in Xwayland
<ofourdan>
yes, I would like to keep the window managerment logic in the window manager, and do not leak it in the Xserver.
<emersion>
_NET_WM_OPAQUE_REGION is not really window management
<ofourdan>
it's still a NET_WM_* property
<emersion>
even if it has "WM" in its name - it's just the originating spec
<ofourdan>
and there's a caveat there
<ofourdan>
the opaque region applies to the window as shown on screen. Some Wayland compositors apply a different scaling to the Xwayland surface (kwin does that, mutter does that now with GNOME 47) and the coordinates of the region boxes need to be scaled, something alien to Xwayland in that case
<ofourdan>
opaque region is a optimization for the compositor, I reckon it belongs to the compositor
<emersion>
that should be fine no? all that comes from Xwayland needs to be scaled, opaque region included?
<zzag>
ofourdan: the key thing here is that it's unlikely that XSHAPE is going to change to support opaque regions, but on the other hand, there are wayland compositors that struggle with supporting _NET_WM_OPAQUE_REGION because it doesn't fit the wl_surface abstractions
<ofourdan>
well thta would break existing compoisitors which do that now, presumably
mclasen has joined #wayland
<zzag>
ofourdan: we don't need the opaque region to be provided in _NET_WM_OPAQUE_REGION to support it
<zzag>
to support scaling it*
<emersion>
special-casing Xwayland in all compositors is just such a pain
<zzag>
emersion: yes!!!
<emersion>
it's like Xwayland scaling: we just don't support it in wlroots because it's a pain
<ofourdan>
well, you have to provide an X11 window manager anyhow to support X11 and hence Xwayland
<emersion>
but not an X11 compositor
<emersion>
and that prop is read by the X11 compositor
<ofourdan>
true
<emersion>
i think the X11 server isn't even supposed to look at window props (but Xwayland does)
tzimmermann has joined #wayland
<ofourdan>
the X11 server can do whatever it wants really :)
<ofourdan>
it has access to all of that
<emersion>
i mean in the ideal where it doesn't touch WM props etc
<ofourdan>
right :)
<mclasen>
there's plenty of prior art for X servers to read or set properties
<ofourdan>
the problem is should the xserver do it. My point being, I wonder how existing Wayland compositors / X11 window managers, which alredy read and take the NET_WM_OPAQUE_REGION property into account would behave if the opaque region is also translated in Xwayland - IOW, I wonder if that might break existing compositors, especially those who do different scaling for Xwayland.
feaneron has joined #wayland
feaneron has quit []
<zzag>
ofourdan: as far as I know, there are two wayland compositors that read _NET_WM_OPAQUE_REGION: mutter and kwin. mutter ignores wl_surface::opaque-region. kwin won't be affected if xwayland sets the opaque region for Xwayland surfaces, the opaque region will be still scaled as expected (kwin has a notion of client global scale factor)
<ofourdan>
"mutter ignores wl_surface::opaque-region" ← for Xwayland surfaces
<zzag>
yeah
<ofourdan>
also, the compositor won't update the content which is hidden behind an opaque region (that's the goal), if that comes from Wayland instead of X11, the event queues being separate, I wonder if that could induce some more visual glitches on resize. Worth a try I guess :)
<ofourdan>
(or maybe I worry too much)
kts has joined #wayland
<ofourdan>
but as you said, even if Xwayland does that translation, nothing stops a compositor to listen to the net_wm_opaque_region property and ignore the wl_surface opaque region for Xwayland surfaces, so eventualyl, that remains a compositor choice.
<zzag>
yeah, exactly
coldfeet has quit [Remote host closed the connection]
__nick__ has joined #wayland
mclasen has quit [Remote host closed the connection]
___nick___ has quit [Remote host closed the connection]
aleasto has joined #wayland
___nick___ has joined #wayland
kts has quit [Quit: Leaving]
Moprius has joined #wayland
Moprius_ has joined #wayland
feaneron has quit [Ping timeout: 480 seconds]
Moprius has quit [Ping timeout: 480 seconds]
Brainium has joined #wayland
feaneron has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
<zzag>
wl_surface commits -> (N milliseconds later) -> the compositor paints a new frame -> (N milliseconds later) -> Xwayland commits a new buffer
<zzag>
MrCooper: ofourdan: I figured out what causes bouncing.. kwin (and I guess mutter?) does the following currently: send a sync request, block wl_surface commits, and configure the window(s) -> (a few moments later) -> the clients repaints the window and acks the sync request -> the compositor sees that the sync request has been acked so it updates its private state associated with the window (e.g. update the geometry) and unblocks
<zzag>
if I make kwin wait until Xwayland commits something to update the window geometry, it appears there are no issues when resizing gedit now
<zzag>
there are still issues when resizing chromium, but I suspect that it may not support NET_WM_SYNC properly
<vyivel>
does any browser support frame perfect resizing at all
<zzag>
heh indeed :D
nysach has joined #wayland
nysach has quit [Remote host closed the connection]
bjorkintosh has quit [Ping timeout: 480 seconds]
bjorkintosh has joined #wayland
Moprius_ has quit []
mclasen has joined #wayland
sima has quit [Ping timeout: 480 seconds]
psykose has joined #wayland
___nick___ has quit [Remote host closed the connection]
nysach has joined #wayland
nysach has quit [Remote host closed the connection]
rv1sr has quit []
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
eruditehermit has joined #wayland
eruditehermit has quit [Quit: Konversation terminated!]
vsyrjala has quit [Ping timeout: 480 seconds]
nysach has joined #wayland
nysach has quit [Remote host closed the connection]
vsyrjala has joined #wayland
mclasen has quit [Quit: mclasen]
mclasen has joined #wayland
plouton has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
mclasen has joined #wayland
PorkrollPosadist has joined #wayland
caveman has quit []
glennk has quit [Ping timeout: 480 seconds]
Brainium has quit [Read error: Connection reset by peer]
<bluetail>
I noticed some applications like thunar report "disconnected from wayland compositor". Is that a known issue under wayland? It happened just by searching through huge folders.
<bluetail>
I noticed other applications do the same thing when theres enough load - or simply a slow disk involved for instance from sshfs
<bluetail>
but it's not always the case
<bluetail>
with thunar at least I can reproduce, but I didn't see anything interesting in WAYLAND_DEBUG and there was no coredump. Therefore probably no crash.
<soreau>
have you tried with more than one compositor? could be something the server is doing (wrong)
<psykose>
sounds like older libwayland and the socket gets filled up as the client doesn't read it in the middle of a blocking operation (iterating through a lot of files in thunar) so if you move your mouse the server kills the client for being unresponsive
<linkmauve>
bluetail, the proper way to fix that is to run the blocking operations on a different thread from the UI.
<bluetail>
soreau psykose I am on sway with latest wlroots and dev versions of said programs
<linkmauve>
So that the UI can be responsive at all times.
<bluetail>
I think thats the right guess linkmauve