00:48 wlb: wayland Issue #467 opened by oiaohm (oiaohm) libwayland-client feture request default failsafe Client Side Decorations. https://gitlab.freedesktop.org/wayland/wayland/-/issues/467
06:30 wlb: wayland Issue #467 closed \o/ (libwayland-client feture request default failsafe Client Side Decorations. https://gitlab.freedesktop.org/wayland/wayland/-/issues/467)
07:18 wlb: wayland Issue #467 closed \o/ (libwayland-client feture request default failsafe Client Side Decorations. https://gitlab.freedesktop.org/wayland/wayland/-/issues/467)
07:48 wlb: wayland/main: Vlad Zahorodnii * server: Clarify fd ownership in wl_client_create() https://gitlab.freedesktop.org/wayland/wayland/commit/17965d99e854 src/wayland-server.c
07:48 wlb: wayland Merge request !395 merged \o/ (server: Clarify fd ownership in wl_client_create() https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/395)
10:18 wlb: weston Merge request !1519 opened by Marius Vlad (mvlad) timeline: Print ids in order with sub-surfaces client https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1519
11:20 KarenTheDorf: Why are there both wl_keyboard_destroy and wl_keyboard_release and similar in wayland-client.h? Should I always use _release where supported?
11:26 kennylevinsen: KarenTheDorf: wl_keyboard_release, the destructor, was added later in version 3. wl_keyboard_destroy does not send a request, and just removes the object, so that's not what you want.
11:27 KarenTheDorf: Time to go check all the _destroy calls I've written actually call destructors of the same name. Urgh.
11:29 kennylevinsen: The destroy request is usually also the destructor - the protocol documentation wayland.app specifies this with the "type: destructor" tag.
11:30 kennylevinsen: The core protocol just unfortunately had them retrofitted to some objects as the release request
11:32 KarenTheDorf: I'm guessing the oversight was because you don't actually destroy the *keyboard*, just the object representing it. Unlike e.g. a surface? (That's kind of moot as a client application though, just me guessing)
11:36 kennylevinsen: It's related to a raciness in objects removed by the server
11:36 kennylevinsen: If they are just deleted immediately, the client might still be making calls to the object after it happened but before the client learned that it was gone
11:39 KarenTheDorf: So a true destructor call using wayland-client.h will send a message to the server to destory the serverside object, as well as destroying the local proxy, right? While wl_keyboard_destroy and friends just deletes the proxy.
11:40 kennylevinsen: Yes. So before (some 8 years ago), the server would delete it all and tell the client that the seat global went away, expecting things to be fine.
11:41 kennylevinsen: Now, it now lets the client remove them gracefully, avoiding the race
11:42 KarenTheDorf: Riiight, oh yuck now I see the problem. My assumption was that objects exist on the server as stubs that do nothing if they 'go away'.
11:42 KarenTheDorf: I wasn't expecting the server to ever pull them out from under me, as you said that's a horrible race condition.
11:43 kennylevinsen: That's also the newer approach - when needed, the server goes from having a real object to having an inert placeholder until the client finally gets rid of it
11:43 kennylevinsen: ensures that nothing breaks
11:43 kennylevinsen: It's also a problem that is very specific to objects created and destroyed by the server (globals). The vast majority of objects are client owned, which have no such issue.
11:58 wlb: wayland Issue #468 opened by Simon Ser (emersion) protocol: cannot send input event immedately after new wl_seat capability https://gitlab.freedesktop.org/wayland/wayland/-/issues/468 [Protocol]
12:16 KarenTheDorf: Why is there a magic "+8" to map between wayland keycodes and xkbcommon keycodes? The spec just says it's "platform specific".
12:18 kennylevinsen: It's an X11 thing
12:18 kennylevinsen: X11, in the *very* early days, decided that all buttons was to be handled the same - the first 8 IDs being mouse buttons
12:19 kennylevinsen: So there's a +8 offset for keyboard events
12:19 kennylevinsen: I don't remember all the details, but that's the gist of it at least
12:20 mclasen: everything in X is space constraint
12:20 mclasen: those fixed size events
12:20 mclasen: from a different era
12:21 kennylevinsen: bits don't grow on trees, we can't waste 'em!
12:22 kennylevinsen: if only there was some middle-way between bit packing everything and "we'll just bundle a web browser. or two."
12:23 KarenTheDorf: The more I learn about wayland the more refreshing it seems to be compared to X or Win32. It's like it's the only display server protocol designed this side of the 1980s.
12:24 KarenTheDorf: Okay there's also Mir's native protocol but we don't talk about that.
12:24 KarenTheDorf: Even Mir doesn't talk about that
12:35 mclasen: X was designed for remote operation on < 10mbit/s networks ...
12:43 wlb: weston Merge request !1520 opened by Chirag Khurana (chiragkhurana) Draft: clients: simple-im: handle proper destruction of objects https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1520
14:12 jadahl: the /120 way of communicating fractional scale is a bit unfortunate. with 1.75 on a 4K screen, the actual scale to end up with an int monitor size is ~1.752, but that means the clients and the compositor get different idea of how a logical WxH sized actual buffer should be. how do other compositors deal with this?
14:35 zamundaaa[m]: jadahl: we round the scale to 1/120ths on the compositor side
14:52 kennylevinsen: same in wlroots. If it was wl_fixed it would be the same but /255 :/
14:52 kennylevinsen: Well, in sway at least
14:56 kennylevinsen: We don't try to fit the scale to give int monitor size. I'm not sure if that's the right solution either to the problem of filling the screen when resolution isn't a multiple of the scale...
14:57 mclasen: seems like a thing that a protocol should have the answer to...
14:58 kennylevinsen: discussion and ideas welcome?
14:59 kennylevinsen: There's somewhat conflicting requirements between "use this exact scale for your integer logical cooedinates" and "fill exactly this amount of pixels"
15:00 mclasen:is of the opinion that the core protocol should be in device pixels
15:00 zamundaaa[m]: mclasen: something something v2
15:01 kennylevinsen: asjusting the scale isn't the worst idea I gave heard, but it probably requires pretty arbitrary scale fractions and there's plenty of bugs related to even the limited fractions currently used :/
15:02 mclasen: Company: this is a discussion you wanted to have
15:02 emersion: i'm really skeptical about core protocol being device pxels
15:02 emersion: pixels*
15:05 kennylevinsen: I'm not sure if it would be a problem to use buffer coordinates for everything, but not super fond of having to support both in all interfaces
15:12 kennylevinsen: there's some things that would be annoying - like, if a configure is in buffer pixels you also need to know what the compositor understands your scale to be if you want to get the logical size, which is needed if you want to change scale...
15:14 kennylevinsen: And without a dedicated scale ack you can't assume it's the last commited scale. But then you get into a dedicated separate scale communication protocol like I recall was the case for zamundaaa[m]'s V2 proposal, which is arguably more complex than just "work in all physical pixels"
15:15 kennylevinsen: we should just outlaw content on multiple monitors
15:15 kennylevinsen: Fixes everything
15:16 mclasen: yeah, thats another thing: just kill wl_output
15:16 mclasen: no monitors - no problems
15:16 zamundaaa[m]: wl_output doesn't change anything here
15:16 zamundaaa[m]: And if you want scale changes for things like zoom, neither does multi monitor
15:17 kennylevinsen: +1 to killing it, but yeah it's not the cause of this specific issue
15:27 ifreund: I too would love it if wl_output didn't exist
15:40 Company: jadahl, mclasen, emersion, kennylevinsen, zamundaaa[m]: I have opinions (some pretty strong) on that topic with the recent experiences in GTK 4.14
15:41 Company: we had some discussions in gnome-land about that, but I wondered about setting up a call to discuss that with more compositor people
15:44 Company: one opinion is that applications need device pixels, and that means compositor and app need to guarantee that the pixels the app sends matches the device exactly
15:46 Company: so you can't use ~1.752, you need to use 1920/1097 (if that's what you actually want, and I don't think you should want that, you should rather not offer 175%)
15:47 Company: (but that's one of the less strong opinions I have)
15:50 daniels: right, so you would fudge the scaling factor to one which doesn't suck for the target resolution?
15:50 Company: the thing where apps want device pixels is placing subsurfaces - if you do that with application units, you need a way to ensure those can be specified in device pixels
15:50 Company: daniels: yes, like Apple does I think
15:50 Company: daniels: only offer ones that properly divide width and height of the monitor
15:50 emersion: what if a surface is half on a 1x device, half on a 1.3 device?
15:51 mclasen: I think you never want that
15:51 Company: emersion: if that is a real concern, you need a way to tell the app and have it create 2 buffers (potentially via subsurfaces)
15:52 mclasen: it happens when dragging a window over, but its not a use case to design the protocol for
15:52 Company: yeah, it doesn't matter for transient operations if device pixels don't match
15:52 Company: same in the shell's overview
15:52 Company: or alt-tab overlay
15:54 zzag: pq: if the compositor creates a resource, introduces that object to the client and destroys the resource, then that object can linger in the client's object map. If a new object is created with the same id, then the client will be terminated. Is this expected behavior or an oversight?
15:54 zzag: oh
15:54 Company: emersion: there are 3 use cases for device pixels: 1. text hinting, 2. raster image viewing (certain apps care a lot that the image looks good) and 3. retro games that want to use a NEAREST-like filter
15:54 zzag: and the client is notified about the fact that the resource has been destroyed on the compositor side by a destructor event
15:55 zzag: so the client calls wl_proxy_destroy() when it receives the destructor event
15:55 zzag: actually let me write an example protocol to show the problematic sequence of events
15:55 emersion: none of these need device pixels at the wl level though?
15:56 Company: emersion: no - not necessarily
15:56 Company: emersion: device pixels come up with placement and sizing of surfaces and buffers mainly
15:56 Company: emersion: on the protocol level
15:57 mclasen: its just that we have a hard time guaranteeing them device pixels at the application level with current state of the protocol
15:57 mclasen: round wrong in one place, and you get a dozen "blurry text" bug
15:57 mclasen: s
15:57 Company: I don't have an opinion on device pixel usage on the protocol level atm
15:58 Company: that may change once I have an idea about the best solutions for open issues though
15:58 Company: like subsurface placement or how compositors should do scale factor selection
15:59 Company: actually, surface placement, too
15:59 Company: because you can get seams if you want to attach 2 toplevels next to each other
16:00 Company: in a tiling wm, or with a panel
16:00 Company: or with wl_magnets_v1
16:00 zzag: pq: an example protocol: https://invent.kde.org/-/snippets/3131
16:00 zzag: the problematic event sequence would be
16:00 zzag: - fun_manager_v1.fun
16:00 zzag: - fun_v1.joke
16:00 zzag: - fun_v1.joke
16:00 zzag: - fun_v1.done
16:00 zzag: - fun_manager_v1.fun # this can terminate the client if object ids are reused
16:01 vyivel: that's a lot of fun
16:02 vyivel: do we actually use destructor events anywhere
16:02 ifreund: I mean, wl_callback doesn't seem likely to go away
16:03 vyivel: wl_callback is special
16:03 vyivel: it has no requests
16:03 vyivel: i think pq had a blogpost about all this somewhere
16:03 zzag: callbacks are different because wl_callback is created by the client but it's destroyed by the compositor
16:03 zzag: this however
16:03 ifreund: ah right, that one is actually ok
16:03 zzag: is a case where the compositor creates an object and destroys it
16:03 vyivel: yeah the solution is not destroying the object
16:03 ifreund: yeah pq's blogpost was critical reading before I started writing my own protocols
16:04 KarenTheDorf: Can you link that blogpost for a relative newbie? Thanks.
16:04 ifreund: https://ppaalanen.blogspot.com/2014/07/wayland-protocol-design-object-lifespan.html
16:04 vyivel: yeah, "Do not use destructor events"
16:05 ifreund: yep
16:05 zamundaaa[m]: the context for this was that we wanted to send a list in a Plasma-private protocol
16:05 vyivel: although the reasoning doesn't mention id reuse
16:05 zamundaaa[m]: destructor events are completely fine for that
16:05 KarenTheDorf: This ties in to my earlier question with "why does wayland client have wl_keyboard_destroy as well as wl_keyboard_release and friends", server getting to destroy objects is ick.
16:05 zamundaaa[m]: as there will never be a request on the list object
16:07 ifreund: KarenTheDorf: the answer to that question is "we messed up and forgot to add a destroy request before tagging wayland 1.0"
16:07 ifreund: (we as in the wayland community as a whole, I personally wasn't around back then)
16:08 KarenTheDorf: I know, was answered earlier. From what I understood if the server just pulls a wl_seat or one of it's capabilities, there is either 1) a race because the client might still be sending requests using that id, or 2) a server leak as the object has to stay as an inert stub forever. Hence the _release methods.
16:08 ifreund: personally, I have my clients just hard exit if the compositor doesn't support these basic fixes like wl_keyboard_release
16:08 daniels: zzag: you can't do that - you need to define a fun_v1.you_should_destroy_this_now event, and a fun_v1.destroy request
16:09 ifreund: KarenTheDorf: you're now talking about a slightly different issue, the fact that global removal is missing
16:09 zzag: daniels: got it. thanks!
16:09 ifreund: this one can't really be fixed on a protocol level but can be mitigated by compositors
16:10 KarenTheDorf: Is there a way to see what was added/changed in a specific protocol version (other than git blame on the xml)?
16:10 ifreund: for example wlroots waits for a while after sending wl_global.remove before actually destroying the global on its side
16:11 vyivel: KarenTheDorf: new stuff has "since" attribute
16:12 KarenTheDorf: Not everything is "new", like e.g. keymaps now much be MAP_PRIVATE since wl_seat 7, wl_surface::damage being obsoleted, etc.
16:12 daniels: a good general principle for protocol design is 'nothing like wl_seat'
16:14 KarenTheDorf: daniels: I might have to quote that in a blog post. :D
16:18 daniels: KarenTheDorf: please feel free, along with a note that the person who wrote wl_seat is very sorry about it, and has learned a lot about good protocol design since then
16:18 KarenTheDorf: The best protocol is always the one written with hindsight. The second best protocol is the one we have today.
16:19 KarenTheDorf: *stares at wl_shell*
16:19 daniels: tbf wl_shell was always intended to be a placeholder for a real shell protocol
16:21 Company: that's why we have the real protocols now, with the wlr prefix
16:24 KarenTheDorf: I'm impressed that wl_shell has actually been taken out back and shot by basically every compositor instead of remaining in existance forever.
16:35 mclasen: I've wondered if wl_output shouldn't share that fate
16:38 Company: a problem with wl_output is that it's unclear to me what the purpose of monitor/output APIs is for applications
16:39 Company: if the application doesn't even know where it is, why does it matter where it could be?
16:39 ifreund: I agree, it doesn't make any sense to expose wl_output in a ideal policy over mechanism world
16:39 kennylevinsen: Mostly none, except for some specific scenarios like screen recording or layer shell
16:39 ifreund: wl_surface.preferred_buffer_scale and similar events could replace it
16:40 ifreund: layer shell and screencopy could easily implement their own privelidged output listing
16:40 KarenTheDorf: xdg_set_fullscreen uses wl_output, but with hindsight that could be something that lives in xdg_shell somewhere instead of in wayland.xml.
16:40 KarenTheDorf: *xdg_toplevel_set_fullscreen
16:40 vyivel: xdg-output maybe
16:41 ifreund: I have no idea how clients are supposed to be able to meaningfully choose a fullscreen output
16:41 kennylevinsen: Yeah, that's only a vague hint anyway and an app has no good way of deciding where to be fullscreened in the first place
16:41 ifreund: I think "start window on output" belongs in compositor config
16:41 ifreund: xdg-output also shouldn't exist... there have been discussions of deprecating it/renaming to xwayland_output
16:42 Company: well
16:42 Company: you could decide to make outputs useful
16:42 emersion: some clients let the user select from a list with the wl_output description, or have a CLI flag with output names
16:42 Company: "this is a projector"
16:42 Company: "this is the primary output"
16:42 Company: stuff like that
16:42 emersion: what will apps do with this information?
16:43 Company: presentation apps will present on the projector for example
16:43 mclasen: its a nice touch
16:43 emersion: a "projector" as in the hardware device?
16:43 Company: and games will probably like to spawn on the primary
16:44 zamundaaa[m]: Company: the primary thing is a really bad example
16:44 Company: emersion: yeah, or "beamer" or whatever the term is for that
16:44 emersion: "projector" might not be a good idea, maybe i use a projector for something else than presentation
16:44 zamundaaa[m]: Games abusing the primary display thing for placement is a source of a lot of annoyance and uder facing issues
16:44 emersion: or i want to present on not-a-projector
16:45 KarenTheDorf: I mean, on my personal machines I just assume games will just fullscreen on the primary. If I want them elsewhere I have to change the primary... Some games let you pick from an in-app settings screen. Most don't.
16:45 Company: emersion: I was thinking about defaults, there's always corner cases where you want something else
16:45 emersion: Company: what i mean is that it'
16:45 zamundaaa[m]: Tagging the surface with "for presentation" makes much more sense than tagging the output
16:45 Company: but then, I was just trying to give examples for making outputs useful
16:46 emersion: Company: what i mean is that it's better to have a semantic hint, rather than a low-level one
16:46 emersion: "output good for presentation" is better than "this is a projector"
16:46 emersion: up to the compositor to set projectors as "good for presentation" by default if they like
16:47 zamundaaa[m]: I really wouldn't put that in the output
16:47 zamundaaa[m]: The compositor might want to not put normal windows on a projector by default for example
16:48 emersion: but yeah, maybe better to tag a surface as "this is dong presentation stuff btw" instead
16:48 emersion: doing*
16:48 Company: it depends on what the outputs are for - and if you want apps to meaningfully interact with them
16:48 emersion: that way it works if you unplug a projector and re-plug another one, for instance
16:48 kennylevinsen: Something something content type?
16:49 LaserEyess: emersion: imo functionality like this can be combined with https://wayland.app/protocols/content-type-v1, but from the other end
16:49 Company: of course, most of the time, apps think that what they want to do with outputs is a good idea when it isn't
16:49 emersion: that's an issue yeah
16:49 LaserEyess: compositors can know what apps want to do "game", "present", and then apps can know "this monitor is good for presenting"
16:50 kennylevinsen: And yeah, when I'm presenting it's usually on a random meeting-room mounted flat screen. Detection for suitability could perhaps be "largest physical dimensions"
16:50 LaserEyess: is it not still up to the compositor to place the app on the output regardless of what the app requests?
16:50 zamundaaa[m]: LaserEyess: kind of, but ignoring the app's requested output can break legit usages
16:51 LaserEyess: well then you're stuck between "this is a feature users want" and "but it goes against The Wayland Philosophy™ to let apps do it"
16:51 zamundaaa[m]: Like right now we don't have the "for presentation" hint, so if you just place both fullscreen windows from LibreOffice Impress on a single screen, that would be bad
16:52 Company: but if you screw it up, it's also bad
16:52 Company: ie if you put the notes on the presentation screen so everyone can read them
16:52 zamundaaa[m]: Yes, but currently compositors don't really have more information than the apps to do it better
16:52 LaserEyess: well I have good and bad news about that mode of failure
16:52 LaserEyess: good news: people are used to it and won't fault wayland
16:53 LaserEyess: bad news: no OS gets that right
16:53 zamundaaa[m]: That's why I want a protocol with apps to tag their surfaces, so that we can do better when apps make use of that
16:53 LaserEyess: so basically extend content-type
16:53 Company: LaserEyess: more good news: it's how /r/livestreamfail came into existence!
16:53 zamundaaa[m]: I'm not convinced content type is the right protocol for that, but yes
16:54 kennylevinsen: LaserEyess: there isn't much value in adding a feature that would be wrong most of the time just because things are also wrong most of the time on other OS's and people are used to it
16:54 zamundaaa[m]: Something like it for toplevels
16:54 kennylevinsen: In that case, doing nothing is pretty much no different - just pretend it was a messed up auto-placement :)
16:55 Company: wl_always_broken_v1
16:55 LaserEyess: the feature is wrong in well defined ways, though, and more importantly it's sort of expected by end users, as sad as that is for the ecosystem
16:55 LaserEyess: not that wayland can't do better
16:55 LaserEyess: but the status quo is what people live with every day
16:55 emersion: zamundaaa[m]: EDID + user pref
16:55 LaserEyess: the status quo on other OSes*
16:56 zamundaaa[m]: emersion: I'm not saying the compositor can't figure out which display is a projector, but that it doesn't know which windows need to go on it
16:56 Company: if we go by other OSes we need wl_recall_v1 and I don't think we do
16:57 KarenTheDorf: Something like `xdg_toplevel_set_fullscreen_hint(_toplevel, XDG_FULLSCREEN_HINT_PRESENTATION)` instead of `xdg_toplevel_set_fullscreen(_toplevel, _output)`? (Or HINT_GAMING or HINT_WHATEVER)
16:58 emersion: zamundaaa[m]: right, that for sure
16:58 LaserEyess: Company: again, wayland can do better, but I don't think it can do it "well", not unless something like wl_recall_v1 did exist, or at least wl_read_the_users_mind_v1
16:59 kennylevinsen: LaserEyess: if I had to pick between known broken and nothing, I'd pick nothing because it's more predictable and the easier thing to have habits for...
16:59 Company: zamundaaa[m]: netwm_window_type_v1
16:59 zamundaaa[m]: KarenTheDorf: no, it should be independent of fullscreen or not
17:00 Company: I'm not sure that tagging doesn't end up a huge mess once the number of tags grows too much
17:00 KarenTheDorf: Fair enough, I'm just assuming the usecase from my experience (raw vulkan/opengl applications)
17:01 kennylevinsen: LaserEyess: But as the use-cases are already well-established so we have a reasonable chance and defining a protocol that if used right will actually do what the user wants
17:02 kennylevinsen: Instead of "most of the time, kind of"
17:03 Company: we should just put SSD on fullscreen windows, then users can move them to the right output themselves
17:03 Company: problem solved!
17:03 daniels: presentation apps have a 'switch displays' button for this exact reason
17:03 zamundaaa[m]: Company: you can already move fullscreen windows in KWin
17:04 daniels: you can't always get it right, but you can try to get it right as often as possible
17:04 zamundaaa[m]: If you hold Meta, you can just drag them between screens. But it's not something the user should need to do
17:04 Company: zamundaaa[m]: I always assume that KDE can do it, but also that most people wouldn't know how
17:04 daniels: and yes, declaring intent on the surface ('this is my presentation window') is much better than declaring properties of the output and having the app say 'use this output'
17:06 Company: daniels: the app cannot show a different UI with that though - adding a "Maximize on presentation output" button for example
17:06 zamundaaa[m]: Company: yeah, this one is pretty hidden. As a more visible and intuitive thing, you can move them between screens in the overview
17:07 KarenTheDorf: Watch the world burn: Add SSDs to Mutter, but only when fullscreen.
17:12 mclasen: what other tags would there be, apart from 'presentation' ?
17:13 kennylevinsen: "definitely not presentation oh God please don't share this"?
17:13 kennylevinsen: The content type thing has "game"
17:13 Company: "put on main monitor" and/or "put on side monitor" maybe
17:14 Company: like, OBS should probably go to the side
17:14 kennylevinsen: A non-presentation, auxillary/control/notes type window would make sense maybe
17:15 Company: but you get into window relationships with that, too
17:15 Company: "this is a utility window for this other window"
17:15 zamundaaa[m]: kennylevinsen: sensitive content could be a valid hint, yeah. Though it might make more sense to have that be in content type
17:15 Company: for multi-window gimp style stuff
17:15 mclasen: "zone 1"
17:16 zamundaaa[m]: about "game", if some compositor wants to have special placement for games, sure
17:16 Company: I think "game" is weird, because it's unclear what that means
17:16 kennylevinsen: Company: multi-window gimp feels like a whole other use-case though. A presentation doesn't feel like it needs association, it's just two windows of different types in different screens
17:17 Company: should the browser tag itself as "game" when I open a game website?
17:17 kennylevinsen: For content type, game is about low-latency mode for monitors
17:17 kennylevinsen: Theoretically?
17:17 zamundaaa[m]: kennylevinsen: I don't think any compositor uses it for that
17:17 LaserEyess: yes and special modes like VRR, etc.
17:17 Company: kennylevinsen: is https://www.testufo.com/ a game then?
17:18 zamundaaa[m]: but VRR and more lax rules for color accuracy with KMS offloading are good examples for how it might be used
17:18 Company: I wonder if that should be "low-latency" mode instead of "game"
17:18 kennylevinsen: zamundaaa[m]: tbf I'd want permanent game mode for any monitor having it to not get seasick from effective input delay :/
17:18 zamundaaa[m]: Company: if the browser opens a whole separate window exclusively for a game, sure. If not, then not
17:18 Company: solitaire is a game but doesn't want low latency
17:18 LaserEyess: I think they're separate usecases, but low-latency is a good content type
17:18 Company: the testufo is not a game but wants low latency
17:19 emersion: it's not a content-type
17:19 zamundaaa[m]: kennylevinsen: KWin just always sends "graphics", which is supposed to make TVs detect the input as a PC. I haven't been able to test it though
17:19 emersion: a content type is a high-level hint
17:19 emersion: "i want low latency" is a lower level one
17:19 LaserEyess: it's also monitor specific, which goes back to "I am an app that is a game and wants to be placed on a low latency, high refresh rate monitor"
17:20 LaserEyess: which would be nice to be able to specify
17:20 Company: I don't think people want their games on the "low latency" monitor though
17:20 LaserEyess: yes they do
17:20 Company: they want their games on the monitor they play games on
17:20 LaserEyess: those are usually one and the same
17:20 zamundaaa[m]: From bug reports about the annoying "primary monitor" thing, people want games to start on the monitor that they start the game on
17:21 Company: I'm not sure they're the same
17:21 Company: I don't even know which of my monitors has the lowest latency
17:21 LaserEyess: well if we're talking about real world examples, it's not really something you can actually know
17:21 kennylevinsen: Stuff *not* starting on the focused output is one of windows most frustrating behaviors...
17:22 LaserEyess: you can only use surrogates
17:22 Company: we should just train an AI
17:22 Company: and let it decide the monitor to place windows on
17:22 Company: problem solved!
17:22 LaserEyess: and now we're back to wl_recall_v1
17:23 KarenTheDorf: Windows generally seems to start stuff on the monitor that had focus on launch. *Except* full screen programs (games) that always seem to open on the primary.
17:23 Company: Windows starts stuff on the monitor where the mouse pointer is
17:23 LaserEyess: not always, which is indeed a real PITA when using it
17:24 zamundaaa[m]: Where Windows starts stuff barely matters, when a decent chunk of apps are "smart" and remember their position for you. Even when it's on the wrong display
17:24 Company: apps remembering things only works if your monitor config is static
17:24 kennylevinsen: that we don't let them do that is one of the best Wayland features
17:24 zamundaaa[m]: I've even had an app remember its position so well that it placed its window on a screen that wasn't connected anymore. Luckily we don't have those sorts of problems on Wayland
17:25 KarenTheDorf: Company: Yeah, I've had apps open up outside the bounds of my monitors before now after a reconfiguration.
17:26 LaserEyess: ok how about this as a usecase: I frequently plug in my laptop to an external monitor to run mpv on, and I have to focus the external monitor before mpv opens otherwise it will start on my laptop's screen. But it's a pretty clear intent to have a media player run on the giant monitor/tv that was just connected
17:27 LaserEyess: it would be nice if the compositor could let mpv start on the bigger monitor with some hint
17:28 LaserEyess: I think this is something that no other OS does right, but that wayland could theoretically do right given content-type as well as another protocol for the compositor to let apps know some properties of the monitor
17:29 zamundaaa[m]: LaserEyess: letting apps know things about the monitor is not a good way to achieve this sort of thing
17:29 kennylevinsen: Hmm, not really. Case in point: My laptop monitor is obviously smaller than my desktop monitors, and if I open mpv on the smallest screen to play a video (the laptop), it's because I want it to play *there* as I'm doing something else on the others or don't want it to be as big when watching in the office.
17:29 kennylevinsen: If mpv used a hint I'd need to disable it or have my compositor ignore it
17:30 kennylevinsen: I feel that it's different than the more obvious presentation example at least
17:30 LaserEyess: it is different, hence bringing it up
17:30 zamundaaa[m]: LaserEyess: but if you want a "content type" for window placement, and have your compositor do something smart with it, I don't see why not
17:31 LaserEyess: zamundaaa[m]: but I need some way to know if this thing is a "TV" or "VR", or *something*
17:31 zamundaaa[m]: Why would the app need to know that?
17:32 zamundaaa[m]: The compositor controls window placement, and it has as much information about the displays as you can get
17:32 kennylevinsen: I guess mpv could let you specify the content-type, and if you thought it was presentation (your big screen would likely be the most presentation capable) you could ask for that. Or it could set it to video, and configure your compositor to use the big screen for video by default
17:34 kennylevinsen: (I'm a bit hesitant about the latter as it's not obviously the right thing due to many common video sources not justifying a forced cinema experience...)
17:38 kennylevinsen: Maybe "cinema" would be good to distinguish from a plain video source
17:49 mclasen: https://gitlab.gnome.org/GNOME/gtk/-/issues/6727 is the kind of issue we get when dealing with monitors in Wayland
17:57 LaserEyess: zamundaaa[m]: maybe the app doesn't need to know it, but I think generic "content-type" isn't enough
17:58 emersion: mclasen: sounds like just a GTK bug?
17:58 nickdiego[m]: fwiw, in chromium, which also has this sort of "monitor metadata" API, we're also dealing with similar issues
17:58 mclasen: yeah, sure but the bugs are caused by the messy situation of trying to combine some data from wl_output with data from xdg_output
17:58 mclasen: and dealing with different versions of those
17:58 mclasen: or their absence
17:59 mclasen: it is just all around far too messy for the little benefit that monitors offer
17:59 nickdiego[m]: actually, any toolkit/middleware (which browsers usually act as) which expose that kind of abstraction to clients are currently broken under Wayland I guess
17:59 emersion: just require the latest version of each and don't expose anything if missing?
18:00 emersion: yeah, supporting the full matrix is a mess
18:00 nickdiego[m]: what about backward compatibility? eg: stable apis on which apps rely on 👀
18:00 wlb: wayland-protocols/main: Xaver Hugl * staging/tearing-control: clarify what happens after wl_surface destruction https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/e71ed40ad7af staging/tearing-control/tearing-control-v1.xml
18:00 wlb: wayland-protocols Merge request !300 merged \o/ (staging/tearing-control: clarify what happens after wl_surface destruction https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/300)
18:03 nickdiego[m]: not sure if xdg-toplevel-drag folks are around. I have a few quick doubts after giving chromium's patch a try
18:05 nickdiego[m]: kwin (sole impl of the protocol so far) sends data_source.dnd_drop_performed and then cancelled when the drop happens within "non-target" surfaces, is that WAI or a impl bug? afaict the spec is not clear about that
19:29 kennylevinsen: emersion: I'll follow up on the annoying yet-again-reopened issue in a minute, don't worry about it yet :P
19:30 emersion: was thinking about closing it + locking with a comment among the lines of "if you're not going to play by our rules, let's stop here"
19:32 vyivel: there should be a reply template specifically for csd lol
19:33 vyivel: i wonder if one could repurpose cage to add decorations to anything
19:34 soreau: what is the issue?
19:35 kennylevinsen: emersion: I'll respond once, then indeed lock if they keep going. Don't want others that trip over it to think they had a good idea and that we're somehow not cooperative enough to accept it, so want to cement it first
19:36 kennylevinsen: Considering the Factorio dev comment (which itself was fine) I wouldn't be surprised if other gamers came along, regurgitating such things blindly
19:37 emersion: i mean it's fine to continue discussing
19:37 emersion: but if they play the re-open issue game…
19:52 daniels: fully agree with you both fwiw
20:04 wlb: weston Issue #910 opened by n3rdopolis (n3rdopolis) When deactivating a Weston session, and then activating it, the application does not regain focus https://gitlab.freedesktop.org/wayland/weston/-/issues/910 [Desktop shell]
20:30 jadahl: zamundaaa[m]: so with a 1.75 (which is what the real scale would be rounded to), and a 3840 wide resolution, the logical width of the monitor would be 2194.3. how do you deal with that?
20:38 zamundaaa[m]: jadahl: with that particular value, there's nothing you need to deal with. 2194 * 1.75 = 3839.5, which rounds to 3840
20:39 zamundaaa[m]: But for values where it actually doesn't work out, well, there just are gaps in that case
20:40 jadahl: so you'll render and skip a pixel on the edge?
20:41 jadahl: of the monitor
20:42 jadahl: some how I want to travel back in time and add both a num and denom to not have to deal with this
20:50 zamundaaa[m]: That wouldn't fix it
20:51 jadahl: it'd fix not getting logical sizes that doesn't align with the monitor mode
20:53 zamundaaa[m]: Sure, but apps aren't fullscreen that often. For a maximized window to fill the screen properly, you need the size of that + DE panels on the screen to add up to the full screen
20:56 jadahl: could just make the panel height align with the physical grid
20:58 mclasen: that would be cheating in a way
20:58 mclasen: if it end up using non-integral application pixel sizes for the compositor chrome
20:58 mclasen: i agree that ultimatively, that is what you want: sizes in device pixels
20:59 jadahl: so its better not being able to use the whole monitor?
20:59 mclasen: it would be better to start over from scratch on fractional scaling
21:00 mclasen: imo, what we have now is not salvageable
21:15 zamundaaa[m]: jadahl: there's no "just" about it when the panel is just another Wayland surface
21:15 jadahl: true, that makes it trickier
21:17 jadahl: if we could tell clients the best buffer size that might make that easier
21:53 KarenTheDorf: Urgh, I don't get the wayland event loop. Why do I have to manually poll an fd to see if there is anything on the socket to read? (Failure to do so gets a crash with "Error sending request: Resource temporarily unavailable")
21:54 KarenTheDorf: https://pastebin.com/02th3RZ6 is what I was doing, but kaboom. Doing a poll on the wayland socket and only doing read_events if it's ready for read fixes the kaboom but I don't see why fixing my empty reads prevents an error *sending* requests.
22:00 wlb: wayland Issue #467 closed \o/ (libwayland-client feture request default failsafe Client Side Decorations. https://gitlab.freedesktop.org/wayland/wayland/-/issues/467)
22:05 daniels: KarenTheDorf: you’re forgetting to flush
22:09 KarenTheDorf: Where should the flush be? (There's a flush in that code, after the prepare_read/dispatch_pending loop
22:12 kennylevinsen: See the docs for wl_display_prepare_read_queue which has an example of how to dispatch manually instead of using wl_display_dispatch
22:18 KarenTheDorf: Well, poll() in that example blocks forever, which is what I'm trying to avoid. I suppose the extra waiting is wnough time to avoid overfilling the send buffer?
22:18 KarenTheDorf: It works, but now the wl_buffer doesn't get updated unless I jiggle the mouse or similar.
22:23 kennylevinsen: poll blocks forever if nothing is happening. The point if that snippet is that you substitute poll with your own event loop, which might also wake for other things than Wayland traffic.
22:24 kennylevinsen: If the buffer is not committed unless you jiggle the mouse despite flushing before sleeping in poll, it seems like you render and commit path is borked. You're not using threads are you?
22:25 kennylevinsen: (if you don't substitute the poll, you might as well just call wl_display_dispatch in a loop which does the whole shebang including poll)
22:27 KarenTheDorf: Only one thread
22:28 kennylevinsen: What is your trigger for rendering?
22:30 KarenTheDorf: Uh, there isn't one? It's a loop that sits in "while(!window.closed){ poll_events(); render(color++); }"
22:30 kennylevinsen: Yeah that doesn't make sense
22:31 kennylevinsen: Poll events without your own event loop means "wait until the server has something to say". It won't have something to say unless you ask it to.
22:32 kennylevinsen: If you want to render continuously at an opportune time, you'd subscribe to frame events for the surface and repaint in response to those as long as you think it makes sense to render.
22:33 kennylevinsen: (You'd then stop once there are no changes to render, and only restart rendering if the content would have changed - e.g., on keyboard input)
22:33 KarenTheDorf: If it has nothing to say, I'd expect it to just render the next frame early (which yes, means dropped frames and wastefulness, not ideal in a finished application but just what I expected to be able to do)
22:33 kennylevinsen: But you would never do poll(); render(); - the frame callback would be handled within the dispatch
22:35 kennylevinsen: That doesn't align with how poll works. It sleeps until the I/O event you asked for, and when rendering you're the one talking - not the server. Nothing to wake the poll.
22:36 kennylevinsen: Nothing stops you from polling with timeout though, just make sure you only read the Wayland connection when poll says it was readable.
22:37 kennylevinsen: (that's what an event loop would do for you anyway, not like you need to sleep forever just because the server doesn't have anything to say)
22:39 KarenTheDorf: I think I'm going down the wrong path by talking about poll. I think I fixed my code and it's not by using poll() but instead by sticking wl_display_flush() in a loop until it stops failing with EAGAIN.
22:40 kennylevinsen: Uhm
22:40 KarenTheDorf: Oh, only some of the time. Gah. I'm going to just punt wayland off to a background thread like I do with win32.
22:40 KarenTheDorf: Then it can block all it wants
22:40 kennylevinsen: Neither of those is right and you'll get a lot more pain from putting it in a thread
22:41 kennylevinsen: The right thing to do is just to use a frame callback, which is pretty easy. See wl_surface_frame.
22:42 kennylevinsen: Then wl_display_dispatch in a blind loop will work perfectly with properly refresh-throttled rendition, and unless you want to design an event loop, fidgeting with poll might not be the right way to spend time.
22:43 KarenTheDorf: Well, the idea of this was eventually I'd plug it in to a vulkan application. Which can run either with somethink akin to a frame callback (PRESENT_MODE_FIFO, might well use frame callbacks internally) but can also just run away and render faster than the screen (PRESENT_MODE_MAILBOX or IMMEDIATE)
22:43 KarenTheDorf: So I'm trying not to block in my wayland event handling, so that the vulkan side of things doesn't get forced to the refresh rate of the screen if it doesn't want to be.
22:46 kennylevinsen: Well, then see https://git.sr.ht/~kennylevinsen/wldim/tree/master/item/main.c#L357 - just skip the part where there are two fds polled, pfd[1] is a pipe for signal stuff.
22:47 kennylevinsen: Set the pool timeout to whatever you want, and your loop will run on any server event *or* if the timeout expires
22:48 kennylevinsen: It'll get your loop cranking, but at very irregular speed
22:49 KarenTheDorf: kennylevinesn: https://pastebin.com/pcAG8nsK This works, for now. But thank you for the link. Honestly, it is *incredibly* tempting to just say 'fps higher than the refresh of your screen is pointless' to users but... People like seeing 9001fps reported on a 60fps display :D
22:50 KarenTheDorf: I almost certainly want to poll for POLLOUT, rather than that busyloop.
22:51 kennylevinsen: Steal what you want :)