ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
Ampera has joined #wayland
thevar1able1 has joined #wayland
thevar1able has quit [Read error: Connection reset by peer]
Brainium has quit [Quit: Konversation terminated!]
nerdopolis has quit [Ping timeout: 480 seconds]
repetitivestrain has joined #wayland
cool110_ has joined #wayland
cool110 has quit [Remote host closed the connection]
immibis has quit [Remote host closed the connection]
bodiccea_ has quit [Remote host closed the connection]
bodiccea_ has joined #wayland
immibis has joined #wayland
Seirdy has joined #wayland
hardening has joined #wayland
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
dcz_ has joined #wayland
tzimmermann has joined #wayland
jmdaemon has joined #wayland
remyabel2 has quit [Quit: remyabel2]
danvet has joined #wayland
rasterman has joined #wayland
<pq>
swick, have you been talking with Troy on some other forum perhaps? Just curious.
remyabel2 has joined #wayland
andyrtr_ has joined #wayland
cool110_ has quit [Remote host closed the connection]
dcz_ has quit [Ping timeout: 480 seconds]
andyrtr has quit [Ping timeout: 480 seconds]
andyrtr_ is now known as andyrtr
cool110 has joined #wayland
Company has joined #wayland
slattann has joined #wayland
<ofourdan>
humm, I am having some diffculties using the release.sh script from util/modular/ to release wayland-utils, the server path is removed because it's been moved to gitlab, but apparently release.sh doesn't know that
<emersion>
ofourdan: i'd recommend against using that cript
<emersion>
script*
<ofourdan>
(and I do remember which script I used the last time, of course)
<emersion>
it's super old, big, and hard to debug/patch
<ofourdan>
I mean I do _not_ remember
<emersion>
it'd recommend using GitLab releases instead
<emersion>
the minimal actions are:
<ofourdan>
yet it's the one ref'ed in the releasing.md doc of weston
<ofourdan>
(that I copied)
<emersion>
ninja -C build/ dist
<emersion>
gpg --detach-sig <tarball>
<emersion>
then tag the release and upload the files in GitLab
<ofourdan>
MrCooper: I do not think there is any Wayland compositor out there actually immune to the issue fixed by xorg/xserver!972
<ofourdan>
(and, as a bonus, I consider X11 server grabs as something really bad that apps should never do so I am even happy to set it being ignored in Xwayland rootless)
<ofourdan>
my ideal Wayland compositor would have its X11 parts and the Wayland parts separate (and ideally, the X11 WM bits could be replaced, so that you could have different X11 WM)
<pq>
indeed. That would essentially mean a window management API exposed by compatible Wayland compositors. :-)
<ofourdan>
exactly
<pq>
given that all the differentiation must be in the Wayland compositor anyway, wouldn't the ideal outcome be a single XWM implementation shared?
<pq>
Weston's xwaayland.so is separate, but it doesn't allow the window manager to be agnostic of X11, because X11 works so different from Wayland.
nerdopolis has joined #wayland
<pq>
libX11 or XCB API does not leak into the Wayland WM, but the Wayland WM still needs to care about some X11'y concepts.
<emersion>
why would you want to switch the XWM of a Wayland compositor?
<emersion>
if you want to share code, why use a separate process? why not a library? (in which case you end up with wlroots)
<ofourdan>
emersion: you mean appart from the flexibility and fun? Having separate processes (or threads) would avoid potential deadlocks between X11 and Wayland, as in xorg/xserver!972
<emersion>
well, then you get all of the fun in synchronizing both threads/processes as discussed above
<emersion>
a better architecture is to never block
<ofourdan>
x11 wm require blocking, at one point or anohter
<emersion>
hm, why is that?
<emersion>
xcb limitation or something else?
<emersion>
ofourdan: thanks for the wayland-utils release!
<emersion>
nit: "information" is uncountable
<ofourdan>
no, by design - xcb adds a lot of flexibility in this, but some requests for x11 wm need sync
<emersion>
do you have examples of such requests?
<ofourdan>
ah right good point,. last minute chnage!
<ofourdan>
memory fails me atm, but I could try to find out if you want
<ofourdan>
emersion: btw, th release script I used is generic, no project name hardcoded :)
<emersion>
yeah, i'd be interested to see if there really is no way to do it
<ofourdan>
it's just a trivial change from yours, name="$(meson introspect "$build_dir" --projectinfo | jq -r .descriptive_name)"
<emersion>
ah, nice, didn't think of using meson to figure out the project name
<emersion>
figuring it out from the Git URL seemed like pain
<ofourdan>
and risky
<emersion>
yea
<emersion>
adn sadly glab has no simple command to figure it out either
<ofourdan>
glab is convenient, yet I had to install golang to build it :)
<emersion>
it's not in your distribution's package repository?
<emersion>
i assume the "needs rework" ones will miss it
<emersion>
!989 has one R-b
<daniels>
yeah, !989 can and probably should go in, but need to stare at it a bit harder
rv1sr has joined #wayland
cyberpear has joined #wayland
<ofourdan>
emersion: back to your question about blocking X11 requests, both Xlib and xcb have a number of blocking requests (e.g. xcb_get_extension_data()), but even hidden being things like xcb_put_image() called from cairo, etc. But even for For window management, querying the x11 tree usually requires a server grab (to avoid a new window to come up in between while its fetches the tree), etc. or when data is
<ofourdan>
needed from the xserver, like to retrieve data such as xcb_get_property()/xcb_get_property_reply(), basically anything taht calls wait_for_reply() or _xcb_conn_wait() (like _xcb_out_send())
<ofourdan>
xcb is definitely a best bet there (even though mutter is stuck with Xlib, because gdk is still xlib), but even wit hxcb, there are a bnumber of blocking calls that can trigger a deadlock
<pq>
daniels, if you want 989 in, better push the button. Not sure there is anyone else to push it. :-)
<daniels>
pq: yeah, was just giving it a quick run under asan
<emersion>
ofourdan: yes. my question was whether or not it was possible to build a non-blocking xwm with xcb, without using the _reply() family of functions
<emersion>
the extension stuff i'm not too worried about, it's only used once at startup
<ofourdan>
emersion: if you're interested, I just have sway hang with the reproducer for xorg/xserver!972
slattann has quit [Read error: Connection reset by peer]
bodiccea_ has quit [Remote host closed the connection]
bodiccea has joined #wayland
cool110 has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
cool110 has joined #wayland
ybogdano is now known as Guest2132
ybogdano has joined #wayland
Guest2132 has quit [Ping timeout: 480 seconds]
river has joined #wayland
river has left #wayland [#wayland]
rain1 has joined #wayland
<rain1>
hi
<rain1>
what is the best way to serve vnc from a xwayland/weston host?
<emersion>
this isn't supported yet
<emersion>
there is a patch for it
<emersion>
this is supported by some other compositors
<rain1>
thank you
<rain1>
which compositor would you recommend for vnc support? and is the patch also worth trying?
<rain1>
as an alternative top vnc, I also tried to expose with xrdp remote desktop protocol, but it gave a blank screen. has anyone had success with running an rdp server on a wayland host?
dcz_ has quit [Ping timeout: 480 seconds]
rv1sr has quit []
ybogdano is now known as Guest2140
ybogdano has joined #wayland
Guest2140 has quit [Ping timeout: 480 seconds]
<any1>
xrdp and x11vnc won't do you any good with wayland.
<any1>
weston has an rdp backend. wlroots based compositors and MIR have wayvnc
hergertme_ has quit [Remote host closed the connection]
hergertme has joined #wayland
hergertme has quit [Remote host closed the connection]
bhawan has quit [Remote host closed the connection]
remyabel2 has joined #wayland
immibis has joined #wayland
cabal704 has quit [Read error: Connection reset by peer]