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
Seirdy has quit [Quit: exiting 3.2]
Seirdy has joined #wayland
pnowack has quit [Quit: pnowack]
immibis has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
tdeo has quit [Remote host closed the connection]
tdeo has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
Seirdy has quit [Ping timeout: 480 seconds]
Seirdy has joined #wayland
bim9262_ has quit []
bim9262 has joined #wayland
bim9262 has quit []
bim9262 has joined #wayland
Seirdy has quit [Quit: exiting 3.2]
boistordu_ex has joined #wayland
boistordu has quit [Ping timeout: 480 seconds]
Seirdy has joined #wayland
zebrag has quit [Quit: Konversation terminated!]
tzimmermann has joined #wayland
jgrulich has joined #wayland
dcz_ has joined #wayland
immibis has joined #wayland
emersion has quit [Read error: Connection reset by peer]
emersion has joined #wayland
bl4ckb0ne has quit [Read error: Connection reset by peer]
bl4ckb0ne has joined #wayland
kennylevinsen has quit [Read error: Connection reset by peer]
kennylevinsen has joined #wayland
danvet has joined #wayland
hardening has joined #wayland
novakane has joined #wayland
novakane has quit [Quit: WeeChat 3.3]
novakane has joined #wayland
leon-p_ has joined #wayland
leon-p has quit [Ping timeout: 480 seconds]
pnowack has joined #wayland
rgallaispou has joined #wayland
rasterman has joined #wayland
novakane has quit [Quit: WeeChat 3.3]
novakane has joined #wayland
fmuellner has joined #wayland
<tzimmermann> danvet, could you take a lok at a documentation patch. it's the final patch for gem_prime_mmap cleanups https://lore.kernel.org/all/20211108102846.309-4-tzimmermann@suse.de/
<tzimmermann> oh, wrong channel
NeoCron has joined #wayland
<DemiMarieObenour[m]> Is it always safe to dispatch keyboard events to a toplevel or popup surface, or do I need to be able to dispatch them to subsurfaces? If the latter, how should I know which one to dispatch to in a rootless compositor?
NeoCron has quit []
fmuellner has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
flacks has quit [Quit: Quitter]
flacks has joined #wayland
novakane has quit [Quit: WeeChat 3.3]
marmarek has joined #wayland
<pq> emersion, thanks for the comments on Pixel's color :-)
<emersion> :)
jgrulich has quit [Ping timeout: 480 seconds]
<wlb> weston Issue #562 opened by () XDG_RUNTIME_DIR is not set in arm device(weston run failure in arm device) https://gitlab.freedesktop.org/wayland/weston/-/issues/562
<wlb> wayland-protocols/main: Simon Ser * linux-dmabuf: add note about pre-multiplied alpha https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/40cb7d47e639 unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
<wlb> wayland-protocols Merge request !125 merged \o/ (linux-dmabuf: add note about pre-multiplied alpha https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/125)
<wlb> weston Issue #562 closed \o/ (XDG_RUNTIME_DIR is not set in arm device(weston run failure in arm device) https://gitlab.freedesktop.org/wayland/weston/-/issues/562)
<wlb> weston Merge request !702 closed (kiosk-shell: add zorder support)
novakane has joined #wayland
pnowack has quit [Quit: pnowack]
pnowack has joined #wayland
tzimmermann has quit [Quit: Leaving]
<wlb> weston Merge request !724 opened by () desktop-shell: Do not leave views in layers upon shell destruction https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/724
<wlb> wayland Merge request !188 opened by () WIP: Add connection buffer size control https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/188
zebrag has joined #wayland
rgallaispou has quit [Read error: Connection reset by peer]
<vyivel> a question regarding presentation-time: it mentions "content update" a lot, but what's the intended behavior for commits that have associated presentation feedback but don't update content?
<vyivel> specifically I'm interested in sequence "attach buffer, add feedback 1, commit, add feedback 2, commit, page flip"
flacks has quit [Quit: Quitter]
Narrat has joined #wayland
flacks has joined #wayland
<pq> vyivel, why on Earth would you want to do that?
<pq> vyivel, asking in another way: you post no content update - when do you expect that to complete? Immediately (as there is nothing to update), or when the last real content update completed (as that's the last time you actually did anything)?
<pq> or maybe it simply doesn't complete, because there is nothing to do, so the compositor does not repaint
<pq> vyivel, I would say there is no intended behavior, because posting a no-update and asking when it completes is... well, no idea what the answer should be.
<vyivel> well, *I* definitely wouldn't want to do that :)
<emersion> pq, mpv may do it for audio sync
<vyivel> i just wonder what would be the best way for a compositor to handle this
<vyivel> for reference, in the situation I mentioned Weston sends "presented" to feedback 2 and then to feedback 1
<vyivel> iirc
<vyivel> perhaps this situation should've been a protocol error
<swick> meh, IMO both are content updates even if they are the same content
<vyivel> so if they're both content updates, does this mean second one supersedes the first one? so feedback 1 is discarded and feedback 2 is presented, right?
<swick> *that* is the real question
<vyivel> also that would mean an contentless commit with feedback would force compositor to rerender to get proper timings, i assume
___nick___ has joined #wayland
<vyivel> which doesn't sound nice to me
<swick> discarding it seems to be the most sensible option
<swick> but then again, it's not specified
<vyivel> another answer would be "present feedback 1 and discard feedback 2", as feedback 2 doesn't have content to present at all
<vyivel> so, any possible behavior (except discarding both) can be justified in one way or another
<swick> oh, I just noticed you said feedback 1 is discarded
<swick> I would very much expect feedback 1 to say presented and feedback 2 say discarded
pnowack has quit [Quit: pnowack]
<vyivel> yeah, that makes the most sense to me too, now that I'm thinking about it
<swick> do we define anywhere that content updates get retired in order?
<vyivel> i don't think so
<swick> okay, presentation time says "the user did not see the content update because it was superseded or its surface destroyed" to the discarded case. that implies that as long as the content update was not superseded it was presented to the user
<swick> so, treat it like any other content update and ignore that nothing actually changed, i.e. what weston does
<vyivel> and for "presented" it says "the associated content update was displayed to the user" which assumes the existence of said content update :P
<swick> and it was displayed to the user
<vyivel> does weston also rerender on feedback-only commit?
<vyivel> can't really test right now
<swick> don't know
<emersion> damage will be empty, so it's more of a wakeup
pnowack has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
___nick___ has quit [Ping timeout: 480 seconds]
leon-p_ has quit [Ping timeout: 480 seconds]
Narrat has quit []
<qyliss> Is there a matrix of what Wayland servers implement what protocols somewhere?
dcz_ has quit [Ping timeout: 480 seconds]
<emersion> nope
<qyliss> is there some pitfall I should know about before trying to make one?
novakane has quit [Quit: WeeChat 3.3]
<qyliss> thanks
pnowack has quit [Quit: pnowack]
zebrag has quit [Ping timeout: 480 seconds]
zebrag has joined #wayland
hardening has quit [Ping timeout: 480 seconds]
norkki has joined #wayland
danvet has quit [Ping timeout: 480 seconds]
leon-p has joined #wayland
ryoshu has quit [Remote host closed the connection]
ryoshu has joined #wayland