01:29 Company: "after all xdg_output properties have been sent (when the object is created and when properties are updated), a wl_output.done event is sent. This allows changes to the output properties to be seen as atomic, even if they happen via multiple events."
01:29 Company: How does that work with registering globals?
01:29 Company: like, once I register the wl_output global, doesn't that send a done?
01:30 Company: so if I then register the xdg_output global, does that send another done?
01:30 Company: do I need to make my app distinguish between those two?
01:31 Company: or do I only get one if I register them both right after each other?
01:31 Company: How does that work?
01:36 soreau: Company: when wl_display_roundtrip() is called, it sends a done event internally
01:38 Company: by whom? The app or the compositor?
01:38 soreau: events are from the compositor
01:38 soreau: you can see it in wl dbg output
01:39 Company: I'm not calling wl_display_roundtrip()
01:40 soreau: but in general, it's probably best practice to try and use the same registered object everywhere instead of trying to rebind.. might confuse the compositor
01:40 Company: but maybe something else does?
01:40 Company: I'm not rebinding
01:40 Company: I'm using wl_output and xdg_output
01:40 Company: those are 2 objects
01:40 Company: and xdg_output sends a wl_output.done even when it's done setting up
01:41 Company: and wl_output sends a wl_output.done event when it's done setting up
01:41 soreau: well it just depends on the protocol as to if there's a done event or not
01:41 soreau: IIRC
01:42 Company: what protocol?
01:44 soreau: e.g. https://wayland.app/protocols/xdg-output-unstable-v1#zxdg_output_v1:event:done https://gitlab.freedesktop.org/wayland/wayland/-/blob/main/protocol/wayland.xml?ref_type=heads#L2844
01:48 Company: yes
01:48 Company: so how many done events do I get?
01:48 Company: and when?
01:48 Company: xdg_output sends wl_output.done
01:48 Company: wl_output sends wl_output.done
01:49 Company: do they send the same event?
01:49 Company: do they send it twice?
01:49 Company: can I choose?
01:50 soreau: wl dbg should tell what your compositor does, no telling if it follows protocol or if this is clarified anywhere
01:50 Company: I would very much hope that this is clarified somewhere
01:50 danieldg: Company: often two done events after initial bind, but later (resolution changes) there's one
01:50 Company: because I would very much like to know if we're done or not
01:50 soreau: I would guess, whever you do the call to tickle the compositor to sneeze up the events you're looking for, it will send a done event per output
01:51 danieldg: Company: look at the order of what you send, and realize the compositor processes a request before moving to the next
01:52 danieldg: so you bind an output -> it produces events + done; you bind xdg-output, it sends *those* and then done
01:52 Company: danieldg: and if I bind in the other order I don't get a wl_output.done because wl_output isn't bound yet?
01:52 Company: danieldg: or some crap like that?
01:52 danieldg: think about how you'd bind in the other order
01:53 danieldg: you'll find it hard to do
01:53 Company: so I need to pretend that xdg_output isn't supported for the first done event
01:53 Company: because the compositor hasn't figured it out yet
01:53 danieldg: yep
01:54 Company: that's junk
01:54 danieldg: eh, just use a newer wl-output and don't use xdg-output
01:54 danieldg: problem solved
01:54 Company: well, we have that same problem elsewhere
01:55 Company: every time there's state from multiple protocols associated with objects
01:55 danieldg: the solution is the same, except when it isn't
01:55 Company: like, fractional scale for surfaces and configure events
01:55 danieldg: configure events in xdg batch things together
01:56 danieldg: those just go in the next frame
01:56 Company: every frame is perfect
01:56 Company: just not the first one
01:57 danieldg: you should get fractional scale before you get the configure and render the first frame
01:57 danieldg: if not, that's the compositor being wrong
01:59 Company: I need to have the fractional scale object created though
01:59 Company: otherwise it won't send it
01:59 danieldg: sure; just create it with the surface
02:00 danieldg: configure won't get sent until the first (no-attach) commit
02:00 Company: but I guess I need to create the fractional_scale before creating whatever role I use
02:00 danieldg: no, just that commit
02:01 Company: so that's only a problem for globals then?
02:01 danieldg: basically
02:01 Company: well, or objects that can't be committed
02:03 Company: that's still exceptionally crappy
02:03 Company: code-wise
02:03 danieldg: an easy solution is to do a sync after binding & creating, and don't process the dones until that
02:03 Company: because the client needs to juggle what state the compositor is in when sending done events
02:03 danieldg: but yeah, xdg-output makes a mess
02:04 Company: if I don't process the dones until then, I need to track what dones I still need to process
02:04 Company: that's also not much better
02:04 Company: kinda like XWindow configure counting after resizes
02:04 danieldg: just have a 'first' flag
02:05 danieldg: or... don't use xdg-output
02:05 Company: don't other protocols have the same problem?
02:05 danieldg: mostly no
02:05 Company: when they add state to some surface/output/seat/whatever?
02:06 danieldg: they tie things to particular events
02:06 danieldg: this is really an 'initial event' problem
02:07 danieldg: and xdg-output did not help by sharing the done event (imo that change was a mistake)
02:08 Company: not sharing the done event is a mistake, too
02:08 Company: because you don't know on updates if the other done event is gonna happen or not
02:09 danieldg: imo it should have defined: if you have xdg-output, its done event comes last; you can ignore wl-output-done
02:09 danieldg: but I suppose that would be harder to extend more
02:09 Company: define done events to be alphabetical?
02:10 Company: done events are always sent for all objects that have one, their order is always alphabetical
02:10 danieldg: alternatively, you just have events on xdg-output-manager instead
02:10 Company: that works outside of initialization
02:10 danieldg: have them include the output, then you just bind the manager first
02:11 danieldg: easy, no double done
02:11 danieldg: it does mean every event needs to carry the wloutput object, though
02:11 Company: does that help?
02:12 danieldg: it prevents double-done
02:12 Company: yeah, it does, because you bind the output
02:12 Company: so if you've bound all the managers, the output will be fine
02:17 danieldg: I guess it would be useful if protocols like fractional-scale would explicitly say 'this will always be sent prior to a configure event on the assocated xdg toplevel/popup/etc'
02:18 danieldg: maybe get that added?
02:20 Company: wasn't there an issue for that already?
02:20 Company: I remember talking about that here
02:21 danieldg: I don't read all words here
02:21 Company: can't find one in the repo
08:33 kennylevinsen: Company: wl_output::done is sent at the end each time the output has properties updated, not "once and for all". An output can have its modes change or have a new interface added, and so multiple done events are normal.
08:36 kennylevinsen: If the client bind xdg_output after output, I'd expect you to first get wl_output properties, done, xdg_output stuff (possibly also a repeat of wl_output props), done, as that's the order it asked for things in.
08:40 kennylevinsen: you also need to call get_xdg_output with wl_output, so that's the only order things can happen in
08:44 kennylevinsen: (that is, the events are not send when xdg_output_manager is bound, but when you call get_xdg_output with a specific wl_output you want extended - which requires both globals to already be bound, and so order is unimportant)
08:54 kennylevinsen: danieldg, Company: there is no configure sent on scale change, so it would be hard to order it with respect to them. They are sent whenever, for example when a window is dragged across multiple screens.
08:54 kennylevinsen: Oh company left
15:10 danieldg: kennylevinsen: so what should a compositor that resizes a window and also changes its scale send in order to get a single frame? Example trigger would be a workspace under sway moving to another output with different resolution and scale.
15:13 danieldg: because I think today that's almost always going to generate two frames, assuming an application state that isn't currently waiting on a frame callback when the changes are delivered
15:13 danieldg: I guess if you send scale first then conifgure, the compositor could discard the first frame as it doesn't have the ack'd configure
15:16 danieldg: I suppose I got stuck thinking of that case and forgot the more common 'dragged across a screen bounary' case :)
15:41 Company: danieldg: wouldn't you ideally want to require a scale change to always require a configure?
15:41 Company:aware that's not the case today, but wondering about the ideal case
15:42 danieldg: no, because usually it doesn't need a configure
15:43 danieldg: the usual cause of a scale change outside the initial setup is 'window was dragged to a higher-DPI screen'
15:43 danieldg: and window drags in general don't need reconfigures
15:44 danieldg: screen magnifiers or recorders could also trigger it without movement
15:44 Company: I was wondering from an application level
15:44 Company: but it depends on the design of the application
15:45 Company: I'm trying hard to make scale changes in GTK not require a resize, but that requries conscious effort
15:45 Company: because what usually happens is that text hinting depends on the scale
15:45 Company: and that causes relayout
15:46 Company: and then there's various apps like image viewers or (retro) games that want to align with the pixel grid
15:46 Company: which also causes subtle differences, especially with fractional scales
15:47 d_ed[m]: clients don't need a configure to resize themselves
15:48 Company: sure
15:48 danieldg: that's tricky, yep
15:48 Company: I was thinking about the benefit of having an extra path for scale changes without configuire
15:48 Company: vs scale changes with configure
15:49 Company: and those are both cases you want to support
15:49 Company: like, maximized/fullscreen windows with "move window to next monitor" is a use case where you want that
15:52 danieldg: I suspect the best you'll get today is sometimes rendering a frame that isn't ever shown
15:52 danieldg: if you delay rendering until after processing inbound events that'll usually not happen because they'll all arrive in one recvmsg() call
15:53 Company: fwiw, scale + size go through the same codepath in GTK
15:53 Company: but I think we detect which ones actually changed and skip stuff when things stayed the same
15:54 Company: and that was a deliberate choice, because that's the path that needs to deal with swapchains
15:56 Company: I wonder how much extra work that is if you have to recreate the swapchain twice - probably not too important
15:57 Company: though if it's something like gnome-boxes, there's quite a lot of code triggered there
16:14 danieldg: for text hinting you almost want two modes for scaling: legacy-layout that doesn't move glyphs from how they'd be located at scale=1, and a flowing layout that acts more like web browser zoom
16:15 danieldg: I'm not sure how often you'd actually need the legacy mode but I would not be surprised if some things need it
16:54 Company: danieldg: the legacy mode is necessary if the screen is significantly < 100dpi
16:54 Company: how much depends on the person
16:55 Company: because at that resolution you notice bad keming and hinting and it's worth it to adjust everything by 1px to make it look good
16:56 Company: once your > 300dpi you don't need hinting anymore because basically nobody notices
16:56 Company: so what you need depends pretty much on the hardware you want to support
16:57 Company: those numbers are rough estimates, deduced from the flamewars in the font-related issue trackers
17:09 danieldg: I'd expect that nobody would be happy with font redering at scale 1.1 then - you'll shift everything around and mess up careful pixel positioning, or you make everything ugly
17:21 Company: yeah
17:21 Company: which is why people with bad monitors don't scale stuff
17:21 Company: I mean, zoom in browsers is a pretty recent ivnention
17:22 Company: that coincides with better screens
17:22 danieldg: text zoom in browsers was there for ages
17:24 kennylevinsen: danieldg: if scale and configure happen in rapid succession, the client can always just immediately render in response and supercede their last frame before it was displayed. The compositor shouldn't start discarding frames as the scale is just a suggestion.
17:24 Company: text zoom used to do relayout
17:25 kennylevinsen: If the client is actively rendering it can also just wait for the next frame event to debounce things
17:28 danieldg: if a frame crosses a configure, doesn't the compositor discard the frame that doesn't have the most recent ack-configure in its commit? (yes, it doesn't have to discard it, but if it's doing a clean mutual resize of two surfaces it has to discard one of the two)
17:29 danieldg: maybe discard is the wrong word there, but waiting for another frame that fits the intended layout better
17:30 ifreund: danieldg: yes, thats what several compositors do (river and sway at least, perhaps more)
17:31 danieldg: that means that if you send scale first, then configure, you'll end up with only good frames displayed (and possibly one at the new scale but the wrong size discarded)
18:20 kennylevinsen: Compositors with transaction systems for coordinated tiling resize do that at least. Not sure if any stacking compositors would do that
22:22 graywolf: Hello. Is there a keynav alternative I could use on wayland?
22:23 psykose: something like https://github.com/moverest/wl-kbptr ?
22:24 graywolf: Ah yeah, looks promising, thanks
22:26 graywolf: Sorry, I am not very familiar with wayland's standardization process, but what does mean that protocal is -unstable and at the same time -v1?
22:28 psykose: -unstable doesn't mean anything anymore
22:28 psykose: -v1 means v1 since things start at v1