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
alexmitchellmus has quit [Ping timeout: 480 seconds]
smurray has quit [Ping timeout: 480 seconds]
yongxiang has quit [Ping timeout: 480 seconds]
daniels has quit [Read error: Connection reset by peer]
wangledorf_ has quit [Read error: Network is unreachable]
JPEW has quit [Remote host closed the connection]
cyberpear has quit [Remote host closed the connection]
ecocode_ has quit [Read error: Connection reset by peer]
zmike has quit [Read error: Connection reset by peer]
panzeroceania has quit [Ping timeout: 480 seconds]
Cwiiis has quit [Ping timeout: 480 seconds]
rburton has quit [Ping timeout: 480 seconds]
Ariadne has quit [Ping timeout: 480 seconds]
hwentlan_ has quit [Ping timeout: 480 seconds]
yongxiang has joined #wayland
alexmitchellmus has joined #wayland
Cwiiis has joined #wayland
zmike has joined #wayland
Seirdy has quit [Quit: exiting 3.2]
caveman has joined #wayland
<caveman>
any reason wayland moved to oftc instead of libera?
Seirdy has joined #wayland
ecocode_ has joined #wayland
columbarius has joined #wayland
<caveman>
firefox segfaults with wayland. is this common these days?
<Sachiel>
works well enough in my experience
co1umbarius has quit [Ping timeout: 480 seconds]
<anarsoul>
caveman: you should probably ping firefox devs. It works well on gnome wayland session for me though.
<caveman>
ok.
<Seirdy>
caveman: ping your distro people first though, if you're using a firefox distro package.
wangledorf_ has joined #wayland
<Seirdy>
fedora stable and flatpak beta work for me on sway
smurray has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
caveman has quit [Quit: caveman]
leon-p_ has joined #wayland
leon-p has quit [Read error: Connection reset by peer]
Seirdy has quit [Quit: exiting 3.2]
daniels has joined #wayland
Ariadne has joined #wayland
boistordu_old has joined #wayland
boistordu_ex has quit [Ping timeout: 480 seconds]
caveman has joined #wayland
JPEW has joined #wayland
bluebugs has quit []
panzeroceania has joined #wayland
rburton has joined #wayland
haasn` has quit []
hwentlan_ has joined #wayland
haasn has joined #wayland
<caveman>
any xdotool for wayland?
cyberpear has joined #wayland
zebrag has quit [Remote host closed the connection]
<pq>
We definitely should document that content updates retire in order *for the wl_surface*, that otherwise it could be random which one gets displayed in the end.
<emersion>
a content update is a wl_surface.commit, and an empty content update is still a content update, imho
<pq>
I would assume that Weston just doesn't repaint an update without damage - I would certainly expect that, but I'm not sure what it actually does.
<pq>
and in Weston a repaint with the surface as part of the scenegraph is required for triggering feedback, so a no-damage update would just pend indefinitely.
<pq>
emersion, see, see!! (re: matrix of Wayland support) :-D
<pq>
and no, I didn't prod anyone
<pq>
emersion, maybe you updated the frame callback case?
<pq>
which I don't like, but blargh - and I suppose Weston becomes non-conforming once it gets more optimized or is already
<pq>
emersion, yeah, that's the definition of "concept update", but it does not say that an update without damage needs to be "presented" ASAP like an update with damage is.
<pq>
*content
<pq>
running the repaint machinery when there is nothing to do...
<vyivel>
emersion: i'm getting confused a bit, is the logic in wlr surface synced MR correct then? (with destroying feedback A and replacing it with B)
<emersion>
audio sync with low video frame rate is the use case i have in mind
<emersion>
vyivel: yeah
<emersion>
i believe so
<vyivel>
ok, thanks everyone
<pq>
emersion, if your video is low rate, then how do you do A/V sync at a higher than video rate?
<pq>
besides, isn't it the audio clock that drives video sync, and not the other way around?
<emersion>
i don't know how mpv works, but it does this
<pq>
since audio clock is always much much more precise than the frame clock
<emersion>
by "this", i mean empty content updates with presentation feedback
<pq>
yuck.
<emersion>
mpv also does frame interpolation
<emersion>
not sure how everything fits together
<pq>
I would expect Weston to not repaint without damage, which means that a request for feedback without damage will be depending any unrelated damage to trigger a repaint so that the feedback gets sent.
<pq>
IOW, the result and when the feedback is delivered would be random.
<pq>
so if there are any bug reports that one needs to wiggle their mouse to have fluent display...
MrCooper_ is now known as MrCooper
<MrCooper>
VRR might make this even more fun
<pq>
also cannot really special-case feedback to be sent without repaint, because then the timestamp would be... what? not from the next pageflip which is what I would apps to expect if they expect something.
<pq>
going through repaint just because someone asked seems silly - if apps want this hack, they might as well fake damage too to make it more obvious that their doing something strange.
<pq>
*they're
<pq>
FWIW, when I wrote the Weston implementation for presentation-time feedback, I do not recall ever thinking about what it would do with no-damage updates.
<DemiMarieObenour[m]>
Under what circumstances can a subsurface get keyboard focus?
<pq>
That's a good question. Right now it is not special-cased in the spec in any way, but also keyboard focus is up to window manager policy.
<pq>
That's something that might be good to spec for sub-surfaces specifically under a particular shell extension.
<pq>
the problem is, protocol spec does not govern or even make recommendations to window manager policy
<DemiMarieObenour[m]>
Is “subsurfaces never ever get keyboard focus” an okay policy to implement, or will it break things?
<DemiMarieObenour[m]>
yes, I know it is okay from a spec perspective, but so is never giving pointer focus to subsurfaces, and that breaks gedit’s menus
<pq>
menus are not supposed to be sub-surfaces to begin with
<pq>
there is the xdg_popup role for those IIRC
<pq>
it would also hint to some kind of keyboard event routing problem inside that version of GTK, because it totally could route those events correctly regardless of whether the main or sub-surface has keyboard focus.
<pq>
a client that does *not* want keyboard focus on a sub-surface would likely set the sub-surface input region to empty, which means it cannot be clicked and so shouldn't get keyboard focus
<pq>
and any window switched like traditional Alt+Tab would never target sub-surfaces
<pq>
*switcher
<pq>
or is gedit an X11 client in your case?
<DemiMarieObenour[m]>
nope, Wayland client ― my compositor doesn’t even implement XWayland 🤣
<DemiMarieObenour[m]>
so far keyboard events not being sent to subsurfaces does not seem to break anything, though
<DemiMarieObenour[m]>
next question: does clicking on a surface give it keyboard focus or just pointer focus?
<pq>
pointer focus is usually given by just hovering (no buttons down), no click needed
<pq>
What a click does depends on window manager policy. Usually it activates the window. Activating a window means assigning it keyboard focus as well, because people expect keyboard events to go to the active window.
<DemiMarieObenour[m]>
gotcha
<DemiMarieObenour[m]>
are there any significant compositors where it does not do that?
<pq>
the catch in Wayland is that this is all per wl_seat
<DemiMarieObenour[m]>
in my case wl_seat is guaranteed to be a singleton
<pq>
I wouldn't know, but I also know other compositors poorly
<DemiMarieObenour[m]>
Which one do you use personally?
<pq>
I don't :-P
<DemiMarieObenour[m]>
Still use X11?
<DemiMarieObenour[m]>
My catch is that my compositor is rootless and not really supposed to implement any policies of its own, since it has no idea what the root compositor is.
<pq>
yup, a setup that is over 15 years old
<DemiMarieObenour[m]>
🤣
<DemiMarieObenour[m]>
That is still perfectly valid, though!
<DemiMarieObenour[m]>
Let me guess: Awesome or XMonad?
<pq>
I want to work on my tasks instead of fixing my desktop so that I could work on my tasks. ;-)
<pq>
fluxbox
fmuellner has joined #wayland
<DemiMarieObenour[m]>
There is value in not being tempted to tinker with one’s own setup.
<pq>
Aye. 20 years ago tinkering with the setup was a way to have fun. Now, it's a PITA, there are more important things to do. I blame getting a job in the field.
cvmn has joined #wayland
caveman has quit [Ping timeout: 480 seconds]
cvmn has quit [Quit: bbl]
caveman has joined #wayland
<DemiMarieObenour[m]>
imagines a Wayland compositor that allows for external window managers
<pq>
that was an explicit anti-goal when designing Wayland, and automotive has implemented that
<barix>
you mean ivi-shell? i heard there was some funky stuff in that protocol
<pq>
ivi-shell in weston upstream is just an API shim, the real stuff is somewhere else plugging into ivi-shell.