10:49kennylevinsen: I wonder if anything bad would happen if a compositor decided to only advertise a single wl_output global, hiding all details about its output layout and having the scale just follow the preferred scale
10:50kennylevinsen: (ignoring privileged protocols requiring knowledge about the actual outputs like wlr_layer_shell and wlr_output_power_management of course)
10:51daniels: kennylevinsen: 'the' preferred scale being the one we'd send as preferred_scale for unmapped surfaces?
10:52kennylevinsen: Hmm yes this falls apart when you have multiple surfaces from the same client
10:52kennylevinsen: on multiple outputs
10:53kennylevinsen: well, you could make the hack worse with an output per active scale... :)
10:58wlb: wayland-protocols Merge request !315 opened by Sebastian Wick (swick) staging/xdg-toplevel-icon: Add new protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/315
11:23drakulix[m]: kennylevinsen: I think the only immediate issue here is api consuming outputs as targets not working as expected.
11:23drakulix[m]: xdg_toplevel::set_fullscreen most prominently, but also stuff like layer_shell or screencopy.
11:24kennylevinsen: yeah, set_fullscreen is one thing but I don't think an application can provide a usable value as argument anyway
11:24davidre: set_fullscreen can be useful for things like libreoffice impress
11:24YaLTeR[m]: configure bounds as well
11:24davidre: Where you can select a presentation screen
11:25davidre: and a notes screen
11:25YaLTeR[m]: ah, bounds is on the toplevel
11:25YaLTeR[m]: nvm
11:29Consolatis: kennylevinsen: out of interest, why do you think an application can not provide a usable value as argument for set_fullscreen?
11:30kennylevinsen: The application does not know the output placement and preferences, nor might it necessarily know the dimensions.
11:31kennylevinsen: So it does not know what screen is a good "presentation screen" for example. We had a discussion the other day about instead having the client associate a presentation content type with the surface, so that the compositor can pick a good output for presentation (say, an external monitor/projector instead of the laptop screen)
11:32kennylevinsen: even if it did have full output layout information, The Wayland Way is to leave this up to compositor policy.
11:34swick[m]: I would really like a set_fullscreen without outputs but surfaces giving hints towards what they are, and then some functionality for the app to request moving the fullscreen window to another output.
11:35swick[m]: but I also really would like a set_fullscreen thing that can span over multiple outputs
11:38davidre: <kennylevinsen> "So it does not know what..." <- But it knows by the balue of it having literally settings for it
11:39kennylevinsen: and how would those settings work, when apps do not know anything about the outputs?
11:40Consolatis: the decision might also come from some setting set by the user in the application, based on the output globals
11:40davidre: yes
11:40kennylevinsen: The application will not be able to present a very usable presentation of these though
11:41kennylevinsen: So if a newer version of wl_output is used you can say "DP-9", but that's more or less it
11:41kennylevinsen: This won't work for the presentation use-case for example
11:42davidre: But it works
11:42kennylevinsen: With modern laptops, the actual port changes like the wind, and it won't be configured in advance
11:42davidre: Libreoffice literally has that setting
11:42kennylevinsen: It might have a setting, but it won't do anything in many compositors and even if it did it cannot be set to the right thing
11:43Consolatis: usually users know what their monitors are called though (e.g. the vendor / model) or where they are connected. I think allowing applications to target a specific output when requesting fullscreen is a good thing (even though most would just supply NULL) there and let the compositor decide.
11:43kennylevinsen: what we discussed is a solution that lets libreoffice always do the right thing
11:43kennylevinsen: You don't, specifically, in the presentation scenario know in advance. You just plug in a laptop to a random meeting room screen, and a new output with an unknown name and random connector shows up
11:44kennylevinsen: You could try to go the other way and pick a random monitor that *isn't* the laptop monitor, but then we're also getting a bit fragile
11:44davidre: How would a compositor know a random output is "a presentation output"
11:45kennylevinsen: This is also before we start considering less standard scenarios, like large screens or VR where you might want the placement not to be "a screen" but "place and suitable dimensions for presentation"
11:45davidre: It would need user configuring ahead of time as well
11:45kennylevinsen: you most definitely do not want a powerpoint presentation to be fullscreen on an ultrawide
11:45davidre: or random heuristics
11:45Consolatis: right, I am not saying that there couldn't be other solutions but that should IMHO not result in the existing ability to be removed as it has its purpose.
11:46kennylevinsen: It is not really an existing ability. The current implementation is a hint ignored by many compositors.
11:46Consolatis: well, that is up to the compositor and the user choosing that compositor then :)
11:46davidre: Define many?
11:47davidre: KWin respects it
11:49zzag: mutter should respect it too
11:49zzag: at least i remember seeing such code there
11:50zzag: https://gitlab.gnome.org/GNOME/mutter/-/blob/650ef9b57fb958f2561efad76c6bfcefcebd5550/src/wayland/meta-wayland-xdg-shell.c#L515
11:52drakulix[m]: Cosmic does as well, but I don't think that is the point. The issue at hand is leaving this issue either completely to application (status quo) and thus also their settings ui or being able to potentially configure this globally in the compositor (which still could offer per-app preferences).
11:53kennylevinsen: Looking at wlroots compositors, I'm actually slightly surprised that sway seems to respect it. River, hikari, clay doesn't. niri does.
11:53drakulix[m]: I don't think anybody disagrees that the current "solution" works most of the time in practice (and is what users coming from other OSes expect). I would still argue it is clunky and that the compositor has more information.
11:55kennylevinsen: yeah the current solution was respected in more places than I anticipated, but I stand by that the compositor can make a better decision and be a better place to have logic for and configure what a good "presentation" output is
11:59kennylevinsen: (the compositor has the full EDID, DRM props including connection path, connection time and possibly history, and even if you had to set it manually, telling the compositor once where you present would the user to specify once and have all apps follow, rather than needing to fix this independently in many apps)
11:59kennylevinsen: *would let the user
12:00zamundaaa[m]: I don't think anyone here is saying that the app deciding the output is a better design, but we can add a better API without removing the old one in this case
12:01zamundaaa[m]: If it works well enough, apps that aren't games will port over to it
12:12wlb: weston Merge request !1522 opened by Marius Vlad (mvlad) libweston: Add frame rate support https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1522 [Core compositor], [Debug]
12:13wlb: weston Merge request !24 closed (libweston: Add surface-fps debug scope)
15:09bjorkintosh: so, what's a good wayland programming 101?
15:09kennylevinsen: bjorkintosh: depends, do you want to write a "raw" client or do you want to use toolkits to build UIs?
15:09kennylevinsen: If you want to play with wayland directly, start with a hello-wayland example and look around at wayland.app
15:10bjorkintosh: I aim to understand it.
15:10bjorkintosh: so the latter.
15:10kennylevinsen: https://github.com/emersion/hello-wayland
15:11kennylevinsen: https://wayland.app/protocols/
15:38bjorkintosh: thank you.
15:47KarenTheDorf: A wl_keyboard can't have focus on multiple windows right? (But there can be multiple wl_seats, each with their own wl_keyboard and therefore focus)
15:47KarenTheDorf: More formally: there will always be a wl_keyboard::leave before a new wl_keyboard::enter?
16:21prg: How does one disable a key in wayland?
16:21prg: Is there an xmodmap equivilent?
16:22emersion: it depends on the compositor, but here are some hints: https://github.com/swaywm/sway/wiki#load-a-modified-custom-xkb-keymap-xmodmap-equivalent
16:23prg: is this just for wlroots or? why does it depend on the compositor/
16:23prg: thank u btw
16:24emersion: the XKB keymap should work everywhere, but how you'd configure your compositor to use the custom keymap depends
16:24prg: or is this exclusive to sway?
16:25prg: Dang.. Shame there isn't a xmodmap tool for wayland yet
16:26prg: One of these days wayland will be ready to replace X11
16:27emersion: xmodmap doesn't exist "by design", one could say
16:28emersion: each compositor has its own way of configuring the keyboard
16:30kennylevinsen: prg: xmodmap is also the old, pre-1996 way of making simple keymap changes - not the tool recommended even under X11
18:03wlb: weston Merge request !1523 opened by Marius Vlad (mvlad) backend-drm: Print out planes IDs that have been excluded https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1523 [DRM/KMS backend]
18:05wlb: weston Merge request !1524 opened by Marius Vlad (mvlad) libweston: Don't add frame callbacks from occluded paint nodes https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1524 [DRM/KMS backend]