ChanServ changed the topic of #wayland to: | 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 script from util/modular/ to release wayland-utils, the server path is removed because it's been moved to gitlab, but apparently 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 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
<emersion> a minimal script doing the same thing as xorg's is
<emersion> (but with GitLab releases instead of the web server)
<emersion> (it also formats the announcement email)
<emersion> i'm using the same for Weston as well
<ofourdan> I see
<ofourdan> thanks! will give that a try then
<ofourdan> funny that glab is actually hosted on… github :)
<ofourdan> ah, actually it is
<wlb> weston Merge request !993 opened by Simon Ser (emersion) Add
<emersion> here, the missing weston patch
<MrCooper> ofourdan: the issue addressed by could also be avoided by the Wayland compositor's XWM code running on a separate thread from the Wayland protocol handling code, right?
<swick> pq: no, not that I know
<emersion> MrCooper: that sounds like synchronization hell
<emersion> we do it in gamescope and… ehhh
<emersion> also, if you have some mutexes, maybe a deadlock is still possible
<pq> I would not want to add threads into the mess that is Weston's XWM. :-/
<jadahl> MrCooper: weston tried to do off-thread xwm but then didn't
<pq> jadahl, it tried?
<jadahl> iirc it made things too complex
<jadahl> pq: i have some vague memory of it
<emersion> i'd likle to convert back gamescope to merge back the XWM and Wayland code at some point
<jadahl> at least in a patch series
<pq> I don't, maybe it was before my time.
<jadahl> i don't think it was before your time
<jadahl> maybe it was "wayland-demos" at the time
<MrCooper> k, so possible in theory, but not really practical; thanks guys
<MrCooper> can it be avoided with XCB instead of Xlib?
<emersion> it depends if you use the XCB blocking API i suppose
<emersion> if you don't, maybe?
<pq> did XCB even have an API to see if a *_reply() function would block?
<pq> or is there a way to never call any *_reply()?
<emersion> you wouldn't use *_reply()
<emersion> i think someone had a patch for this in wlroots…
<emersion> hmm, can't find it
<MrCooper> pq: there's xcb_poll_for_reply/event
<emersion> right, and then you need a big switch?
<MrCooper> though unfortunately there's no bullet-proof way to integrate those with an event loop that I know of
<wlb> weston Issue #660 opened by manuel alfayate (vanfanel) modesetting is done on first run with mode=current
cool110 has quit [Remote host closed the connection]
remyabel2 has quit [Quit: remyabel2]
cool110 has joined #wayland
<wlb> weston Issue #658 closed \o/ (Missing spanish accents in VIM on Weston-Terminal
dcz_ has joined #wayland
<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)
jmdaemon has quit [Ping timeout: 480 seconds]
eroc1990 has quit [Quit: The Lounge -]
eroc1990 has joined #wayland
<MrCooper> one can dream :)
<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 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?
<ofourdan> nope
<emersion> well, consider sending them a patch :P
<emersion> hm, right, not very wide-spread yet
<emersion> the project has become official not too long ago
<ofourdan> I am not sure adding a golang package to maintain myself is my best interest :)
<emersion> what's up with all of these golang haters here :/
<ofourdan> oh, I do not hate golang, I just do not think digging that rabbit hole is my iterest, I am just being selfish
<emersion> oh, okay, i guess i'm just used to people praising rust and despising go then
<ofourdan> (I guess I do not know enough of golang to actually have an opinion)
<emersion> fair enough!
<emersion> if we wanted to share the script, where would it live?
<ofourdan> I think it could remain in wayland/wayland
<emersion> and then we just invoke it from different dir as needed?
<ofourdan> yup
<emersion> that would wfm
<emersion> especially if generalizing is a small diff
<ofourdan> wayland/wayland seems like a natural place to go for that
<ofourdan> want a mr?
<emersion> sure
immibis has quit [Ping timeout: 480 seconds]
<wlb> wayland Merge request !265 opened by Olivier Fourdan (ofourdan) build: Make generic
cool110 has quit [Remote host closed the connection]
cool110 has joined #wayland
vyivel has quit [Remote host closed the connection]
bl4ckb0ne has quit [Remote host closed the connection]
emersion has quit [Remote host closed the connection]
emersion has joined #wayland
bl4ckb0ne has joined #wayland
vyivel has joined #wayland
<ofourdan> emersion: there is a typo in in releases.html ("Auguest 23, 2022"), want me to fix it while I am updating it for wayland-utils?
<ofourdan> oh, actually, it's in two places
<emersion> oh, yes, please do!
<ofourdan> k
<emersion> daniels: for more info on that POSIX thing, see
<emersion> the paragraph with "Historical systems have also been unreliable given the common construct"
<emersion> note the use of "historical" :P
rgallaispou has quit [Ping timeout: 480 seconds]
<wlb> Merge request !43 opened by Olivier Fourdan (ofourdan) releases: add wayland-utils 1.0.91
<emersion> ofourdan: you can push directly to main for the website if you want
<emersion> (that's what we've been doing so far)
<ofourdan> I was wondering, but I saw a few previous MR in gitlab :)
<emersion> yeah, these are for larger and more controversial changes
<ofourdan> (it's safer, considering my typing skills!)
<emersion> for releases we don't bother
<wlb> Merge request !43 merged \o/ (releases: add wayland-utils 1.0.91
<wlb> Olivier Fourdan * releases: Fix typo Auguest -> August releases.html
<wlb> Olivier Fourdan * releases: add wayland-utils 1.0.91 releases.html
<ofourdan> thanks!
<emersion> daniels, pq: do you want/need to land one of these before release?
<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. :-)
<wlb> weston Issue #650 closed \o/ (Crash in wl_signal_add when activating a window
<wlb> weston Issue #649 closed \o/ (Crash in weston_signal_emit_mutable on surface destruction
<wlb> weston/main: Marius Vlad * libweston/backend-x11: Tracking previous events over multiple calls libweston/backend-x11/x11.c
<wlb> weston/main: Marius Vlad * libweston/input: Assert if we're still having a notify listener installed libweston/input.c
<wlb> weston Merge request !989 merged \o/ (llibeston/backend-x11: Tracking previous events over multiple calls
<pq> whee
<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
<emersion> yup, i've seen that one in the past
<emersion> wlroots is definitely blocking in a few places
<ofourdan> fwiw, I had last looked into this in 2016 for a vlc bug, so it's a bit old, I had to do some bug archeology
<ofourdan> so maybe it's possible to avoid blocking entirely, but that would be very tricky
<emersion> well
<emersion> i think it's pretty doable
<ofourdan> it depends on what libs you rely on as well
rgallaispou has joined #wayland
midgard has joined #wayland
ybogdano has joined #wayland
hardening has quit [Read error: Connection reset by peer]
devilhorns has joined #wayland
cabal704 has joined #wayland
alatiera has quit [Ping timeout: 480 seconds]
zebrag has joined #wayland
floof58 has quit [Ping timeout: 480 seconds]
floof58 has joined #wayland
<wlb> weston Merge request !994 opened by Colin Kinloch (ColinKinloch) Add devenv for running from the build directory
tzimmermann has quit [Quit: Leaving]
jmdaemon has joined #wayland
devilhorns_ has joined #wayland
devilhorns has quit [Remote host closed the connection]
Hypfer has quit [Ping timeout: 480 seconds]
Hypfer has joined #wayland
devilhorns_ has quit []
bhawan has joined #wayland
alatiera has joined #wayland
<wlb> weston/main: Simon Ser * build: bump to version 10.0.93 for the RC1 release
<wlb> Simon Ser * releases: add weston 10.0.93 releases.html
cheka has joined #wayland
slattann has quit []
slattann has joined #wayland
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 -]
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]
cabal704 has joined #wayland
danvet has quit [Ping timeout: 480 seconds]
jmdaemon has quit [Quit: WeeChat 3.6]