ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
AJ_Z0 has quit [Read error: Connection reset by peer]
AJ_Z0 has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
ity has joined #wayland
<Eighth_Doctor>
akselmo: 👋
wt has joined #wayland
Brainium has quit []
fmuellner has quit [Ping timeout: 480 seconds]
garnacho has quit [Ping timeout: 480 seconds]
vincejv is now known as Guest21191
vincejv has joined #wayland
Guest21191 has quit [Ping timeout: 480 seconds]
sally_ is now known as sally
m5zs7k has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
m5zs7k has joined #wayland
glennk has joined #wayland
sima has joined #wayland
wt has quit [Quit: Konversation terminated!]
tzimmermann has joined #wayland
sima has quit [Ping timeout: 480 seconds]
sima has joined #wayland
feaneron has quit [Ping timeout: 480 seconds]
sima is now known as Guest21194
sima has joined #wayland
andymandias has quit [Read error: Connection reset by peer]
andymandias has joined #wayland
alarumbe has quit []
garnacho has joined #wayland
coldfeet has joined #wayland
coldfeet has quit []
kts has joined #wayland
kts has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
<bluetail>
Can somebody give me an approximation when wayland support is more wide-spread? Major software developers still focus on X, and their wayland versions/fixes that are required to be there someday are years in the future. Take JUCE - even the newest version has issues on xwayland with awkward race conditions, re-centering and so on. I recently wrote
<bluetail>
to one of the stake-holders and they told me that they lack proper framework. It's "convoluted" they say.
<Ermine>
well, unless they put enough effort into supporting wayland, and stop focusing on x, those programs won't get wayland support out of the blue
<Ermine>
but gnome dropping x support and kde freezing hopefully will give strong enough signal to everyone
<jadahl>
bluetail: issues on Xwayland sounds like it could be compositors bugs. for regular X11 clients that e.g. don't do a limited subset of unsupported things (e.g. screen capture via X11, using XTEST), there should be no difference when it comes to plain window management
kts has joined #wayland
<bluetail>
jadahl that probably is true. However, everything I see in sway for instance that uses X is buggy af. To the point where it randomly steals focus while I type, opening a file dialog and what not. It's not for me to criticize sway...... it just feels so alpha, honestly. And the stakeholders have no easy way fixing it when they rely on frameworks
<bluetail>
that don't yet have official wayland support. And you should look deeper. SILK.NET is the same shoe. Using GLFW backend you can't get a window to open, you need to use SDL. Recently had to do that workaround in one of my contributions. But it's just so hard to decipher what one needs to do and why.
<bluetail>
I must actively prevent from applications raising their own message toasts - as then I cant type, shortcut inhibitor doesnt help ...
<bluetail>
We even updated our SILK.NET backend and it wasn't fixed. The issue is that the window never commits its buffer under GLFW
<Ermine>
you need to draw something onto it before it appears
<Ermine>
i've encountered this issue on the first page of opengl tutorial, when there were no glDraw calls
<bluetail>
well, it is a fork of something that somebody in the past has made, and we are all non-paid contributors
<Ermine>
so are wayland devs
<bluetail>
But the mental load. I really try. And it's not easy. I feel it's something I'm not cognitively able to do in all the depth required.
<MrCooper>
bluetail: sounds like sway's rootless Xwayland support might not be as good as other compositors
<bluetail>
yea and whos gonna do it? dump it all on one person ? idk, for my feeling, he's doing a hella lot of stuff, there could be more contributors... there's quite a bit of a skill-ceiling. Well, high-quality contributions, not some poor LLM contributions.
<Ermine>
you shouldn't be the one person
<bluetail>
no I'm not that one person but I feel like for instance kennylevinsen historically did everything I ever had a problem with and I just feel bad coming back with new issues without helping them out. They may be close to burn out even. idk
<Ermine>
stakeholders of aforementioned should start working with wayland community imo
<Ermine>
because they happen to have misconcepton about it
<Ermine>
or are trying to do things that worked or happened to work in X11, instead of thinking about the end goal
<kennylevinsen>
I having a low period for personal reasons, but I am only bothered by pokes if they come with unreasonable expectations (deadlines, "YOU HAVE TO HELP ME", "this project is useless without <xyz fix/feature>", ...)
<kennylevinsen>
(unfortunately, many users seem to get *more* unreasonable expectations when they get stuff for free than when they pay for something :/ )
<kennylevinsen>
bluetail: Do try xwayland-satellite, which is universal and skips the compositors own xwm/xwayland support entirely, and contains some "hacks" to help with common quirks (like being able "unscale" X11 windows I think)?
<bluetail>
Yea full ack, they can eff off if they don't expect boundaries
<bluetail>
Thanks I will.
<bluetail>
s/expect/respect
<kennylevinsen>
we would like the X stuff to get better, but X11 stuff is tricky and idk if anyone really understands it well - our "colleagues" working on Mutter and Kwin might have a headstart in already having an X11 WM they're familiar with (and could maybe reuse?)
lanodan has quit [Ping timeout: 480 seconds]
<kennylevinsen>
but whether everything seems "fully ready" really depends on use - e.g., I ran without Xwayland for the longest time without even noticing it was missing, while others might depend heavily on obscure, closed-source X11 apps that (ab)use every quirk
<jadahl>
the difficult clients tend to be wine, motif (to some degree) and Java
<Eighth_Doctor>
we in kwin benefit from the fact that our compositor is incredibly flexible and powerful
<jadahl>
if you ever have an issue, feel free to ask to see if it's fixed in mutter; I could *try* to see how it was fixed
<kennylevinsen>
:)
<Eighth_Doctor>
likewise, zamundaaa and zzag are able to help on the kwin side
<jadahl>
iirc wlroots to some degree inherited mutter/gnome-shell's list of logic to derive an "app ID" to fix some xwm issue
<Eighth_Doctor>
I suspect that for a lot of the ecosystem, what we do in kwin is closer to what free-standing wayland compositors want to do
<kennylevinsen>
I'm sure there will be many useful things in both mutter and kwin, even if they need a bit of translation to a wlroots/sway paradigm
<jadahl>
right
<jadahl>
problem is you need to learn about X11 window management
<kennylevinsen>
:(
<Eighth_Doctor>
yeah, that part is going to suck no matter how you slice it
<jadahl>
and it's a mine field with lots of caveats and design decisions that were mistakes
<jadahl>
that clients rely on
<kennylevinsen>
Hyrum's law strikes again
<Eighth_Doctor>
it's what makes solutions like xwl-sat attractive, even if I don't think it could ever reasonably work
<kennylevinsen>
even though it will have limits I was quite surprised by how well it worked in common use-cases
<kennylevinsen>
an interesting project at least
<Eighth_Doctor>
yeah, I was surprised too
<Eighth_Doctor>
tbh, I'm surprised nobody has made an xwl library to allow all the different wayland compositors to share integration logic
<bluetail>
kennylevinsen xwayland-satelite works for my use-case. Thanks.
TimRex has joined #wayland
<TimRex>
So.. I popped in here the other day with an issue I couldn't unravel.. regarding:
<TimRex>
```Display Queue} wl_display#1.error(wp_linux_drm_syncobj_surface_v1#93, 3, "Release or Acquire point set but no buffer attached")```
<kennylevinsen>
the possible thread issue where we suspected that one thread called `wl_surface_commit` while another thread was using the surface (e.g., by calling mesa WSI)?
<TimRex>
It was a strange one, that I couldn't repro outside of my Arch box.. and only in Gnome.. and only when I was using my own custom CSD's.. (while libdecor seemed fine)
<TimRex>
A couple upstream package updates later and... it seems to be fixed.. so.. yay? Doesn't mean I'm not doing something dumb somewhere but, hope against hope.. this may not have been of my own making
<TimRex>
Those updates include minor point releases mutter (48.3.1 --> 48.4) , gnome-shell (48.2 --> 48.3), and linux kernel 6.15.3 --> 6.15.4.. think I'm going to call it a win and with any luck it stays that way
<kennylevinsen>
my immediate gut feeling it was racing and minor changes mean the probabilities of winning the rest on your machine has been tipped in your favor
<kennylevinsen>
*winning the race
<TimRex>
That's very probably the case.. but I lack the background to really be able to reason about what should/is happening in terms of a well behaving wayland client.. it's any wonder I got this far ;)
<TimRex>
In any case.. just wanted to say thanks for the pointers from those that were around
<ifreund>
I think I need a version of wl_display_dispatch_queue_pending() that only dispatches a maximum of 1 event
<ifreund>
the context is a client library for a dynamic language that has a feature similar to "exceptions"
<ifreund>
if an event handler "raises" an exception, I can't longjmp out of the dispatcher callback since that would break assumptions held by libwayland
<ifreund>
which means that the C dispatcher callback I give to libwayland can only store the values and then pass them to the dynamic language's event handler after wl_display_dispatch_queue_pending() returns
<ifreund>
however, this doesn't work either since the dynamic languages event handler for one event affects how further events are processed by libwayland since it may create/destroy objects
<ifreund>
does anyone see a better way around this problem than a version of wl_display_dispatch_queue_pending() that only dispatches a maximum of 1 event?
TimRex has quit [Quit: Page closed]
<any1>
pass everything through your own event queue?
earthman has joined #wayland
<earthman>
Hi all :)
<earthman>
Is it possible to use Weston RDP backend to serve a login window such that users can RDP in and log in to their own sessions?
<earthman>
I tried searching Github for "--backend=rdp-backend.so" but I couldn't find anyone using it in that way.
<ifreund>
any1: I don't follow, could you be a bit more specific?
<ifreund>
what events would my "own event queue" store?
<any1>
ifreund: For every callback that's dispatched by display_dispatch, put an event onto a queue, then handle those events one at a time
<any1>
Might be tedious, but if you're writing a language wrapper, perhaps it doesn't make a difference?
<ifreund>
any1: I think you're describing what I already attempted, which didn't work since the event handlers need to be invoked before libwayland dispatches further events
<ifreund>
this is because an event handler might create/destroy an object, affecting how further events are dispatched
<any1>
ahh, sorry
<any1>
yeah, object lifetimes are a pain. :/
<ifreund>
no problem, it's a good thought but sadly thwarted by Wayland object lifetime semantics :/
<ifreund>
I think I'll send a libwayland patch adding wl_display_dispatch_queue_pending_single()
<any1>
You could use threads to solve this, but that would be icky
<ifreund>
I guess so yeah, but I really don't want to
<ifreund>
there's no reason this shouldn't be able to work single-threaded
<davidre>
<ifreund> "I think I'll send a libwayland..." <- would it be more flexible to add a version where you can limit the amount of events you want to dispatch
<davidre>
like in C APIS where you tell how big your buffer is :D
<davidre>
But then again the most use cases are probably one or all
<ifreund>
davidre: yes, it wouldn't be any harder to do that
coldfeet has joined #wayland
<ifreund>
I can't think of a use-case for some value that's not 1 or all though
coldfeet has quit []
<daniels>
earthman: I haven't see someone implementing a login window, I'm afraid - it would be a cool project though!
<earthman>
I admit I'm a noob when it comes to wayland servers, compositors, greeters, etc... :)
<earthman>
I think I should run Weston with the RDP backend
<earthman>
then run greetd or something
<earthman>
I tried sddm-greeter since I had SDDM but it can't find Qt platform for some reason
<jadahl>
fwiw, you can get a "login window" with gdm and gnome-remote-desktop, but then it'll (for the time being) only work with gnome-shell/gnome-kiosk after logging in
earthman_ has joined #wayland
earthman has quit [Remote host closed the connection]
<jadahl>
getting gnome-remote-desktop working with weston would be an interesting project though
<earthman_>
btw the reason I'm using RDP is because VNC was mirroring my physical session instead of starting a separate session or at least locking the physical one
<earthman_>
i.e. accessing the VNC session unlocks the irl PC in the living room. less than ideal XD
<jadahl>
that doesn't really need to be tied to the remote desktop protocol
<jadahl>
just how the remote desktop server decides to implement it
<pq>
For racing wl_surface_commit(), one could e.g. hack Mesa to add a delay before every call. That should make the race reliably won/lost to ease fixing.
hugeblank has quit [Quit: WeeChat 4.6.3]
kts has joined #wayland
coldfeet has joined #wayland
coldfeet has quit [Quit: Lost terminal]
fmuellner has quit []
fmuellner has joined #wayland
kts has quit [Ping timeout: 480 seconds]
narodnik has quit [Quit: WeeChat 4.6.3]
feaneron has joined #wayland
nerdopolis has joined #wayland
sima has quit [Remote host closed the connection]
Guest21194 has quit [Remote host closed the connection]
xjuan has joined #wayland
<karolherbst>
suggesting a list of games reminds me of the issue I was running on windows like a long time ago. I was doing stuff with mingw and were wondering why my discrete GPU was powering up and down constantly and causing stalls in the shell. Turns out "sh.exe" was also a game binary's name, so now every time sh.exe got launched (which got trigered by
<karolherbst>
shell built-ins) windows decided to power up the GPU and stalling my shell 🙃
<karolherbst>
but that also means if you need a list of games, windows drivers might have them somewhere
fmuellner has quit []
fmuellner has joined #wayland
Moprius has joined #wayland
sima has joined #wayland
sima is now known as Guest21212
sima has joined #wayland
Moprius has quit []
OrkobackJul2[m] is now known as Orko[m]
<kchibisov>
Does anyone has a ref. on how Wayland's tablet v2 protocol maps to w3c's PointerEvent. It seems that both firefox and chrome don't expose PointerEvent's tablet related properties under Wayland yet.
coldfeet has joined #wayland
bindu_ has joined #wayland
fmuellner has quit []
bindu has quit [Ping timeout: 480 seconds]
coldfeet has quit []
coldfeet has joined #wayland
Moprius has joined #wayland
lanodan has joined #wayland
narodnik has joined #wayland
coldfeet has quit [Quit: Lost terminal]
Moprius has quit []
hugeblank has joined #wayland
narodnik has quit [Ping timeout: 480 seconds]
kts has joined #wayland
kts has quit [Quit: Leaving]
fmuellner has joined #wayland
sally has quit [Quit: ZNC 1.9.1+deb2+b3 - https://znc.in]
mohit81582263530690 has quit [Remote host closed the connection]
mohit81582263530690 has joined #wayland
xjuan has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
xjuan has joined #wayland
xjuan has quit [Remote host closed the connection]
riteo has joined #wayland
bitblt_ has joined #wayland
bitblt has quit [Ping timeout: 480 seconds]
bitblt_ is now known as bitblt
sima has quit [Ping timeout: 480 seconds]
<DemiMarie>
ifreund: I think if the callback raises an exception, your only options are either to post an implementation error to the client or to crash the process.
<DemiMarie>
In other words, callbacks raising an exception should be considered a programming error.
<ifreund>
DemiMarie: Ive been using the word exception just because I thought it would communicate the idea clearly
<ifreund>
the same mechanism is used for debugging and more in the language I am working with
<ifreund>
Also, I'm writing a client not a server
karenw has joined #wayland
fmuellner has quit []
fmuellner has joined #wayland
AJC_Z0 has joined #wayland
AJ_Z0 has quit [Read error: Connection reset by peer]
AJC_Z0 is now known as AJ_Z0
fmuellner has quit [Read error: Connection reset by peer]
Brainium has joined #wayland
<danieldg>
ifreund: you should catch the exception at the highest level of your application (the callback itself) and then enqueue it for propagation and continue handling the other events. If you have to stop handling future events, then perhaps have a prologue that re-queues events post exception handling.
<danieldg>
that or make event handling two-phase so you control the whole dispatch yourself instead of having libwayland do it