10:06vyivel: if i take a geometry provided with xdg_surface.set_window_geometry, stash is somewhere, and later use the size with xdg_toplevel.configure, is it reasonable to expect the toplevel to assume the previous size?
10:07vyivel: in other words, do xdg_surface.set_window_geometry and xdg_toplevel.configure sizes have the same semantics?
10:08kchibisov: configure is a hint from compositor, set_window_geometry is client telling about area.
10:09kchibisov: I know from practise, that it's _not the case_.
10:10kchibisov: e.g. mutter could resize you to something else sometimes.
10:11kchibisov: Like I clearly remember things like configure(0x0) -> set_window_geometry(800x600) -> configure(800x570).
10:12kchibisov: though, if by semantics you mean _usable area_ they do both represent usable area.
10:15vyivel: hm okay
10:15vyivel: trying to store floating geometry to restore it from maximized state later
10:16pq: vyivel, are you a client or a compositor?
10:16vyivel: compositor
10:17pq: I see nothing wrong doing that, but also there is no guarantee the client honours a size hint.
10:17kchibisov: vyivel: the _approach_ is doing a layout transaction and remembering a position.
10:18kchibisov: So you send a configure to clients changing and wait for their buffers to arrive with some timeout.
10:18vyivel: that's what i already do and it's not exactly relevant to my question
10:19kchibisov: yeah, but until you actually get a _buffer_ you can't do anything.
10:19kchibisov: like it's all just hints in the end of the day, it's not like any of that can raise protocol error (except for entering maximize).
13:20pq: swick[m], was that an ack for the whole of "color effect, calibration, compromised" doc?
13:20swick[m]: I guess
13:21pq: you guess?
13:21swick[m]: definitely better than not having it
13:21pq: alright, thanks
13:21swick[m]: yes :)
13:50Naybs808: Hey
13:52Naybs808: Does wayland have an open source repo anywhere?
13:52emersion: yes, check out our website
13:54pq: the link is in the channel topic
13:58Naybs808: thanks
14:07ErrorNoInternet: hi, i was wondering if wayland allows me to use one gpu for displaying and another one for rendering? i have an nvidia (:/) optimus laptop which has a really weak intel gpu. on Xorg, i simply use my nvidia GPU to render something like KDE Plasma, and the rendered frames get sent to my iGPU (hooked up to the display). on wayland (at least wlroots), it seems like i can only use one GPU with
14:07ErrorNoInternet: WLR_DRM_DEVICES...
14:11MrCooper: ErrorNoInternet: this is mostly up to the Wayland compositor implementation, the protocol itself doesn't really limit what's possible
14:12kennylevinsen: ErrorNoInternet: the first gpu specified to WLR_DRM_DEVICES is used for rendering
14:12kennylevinsen: at least, for rendering *by the compositor*
14:13kennylevinsen: client applications make their own decisions about gpu to use
14:13zamundaaa[m]: ErrorNoInternet: check out https://invent.kde.org/plasma/kwin/-/wikis/Environment-Variables#kwin_drm_devices for KWin
14:18ErrorNoInternet: kennylevinsen: WLR_DRM_DEVICES isn't working on my dGPU ("not a KMS device"), tried on both nvidia and nouveau (nouveau gives a MMIO read error or something), so i guess it can *only* be used for rendering, but not displaying?
14:19ErrorNoInternet: specifying a second device with WLR_DRM_DEVICES just causes wlroots to fall back to that when the first one fails
14:20ErrorNoInternet: not sure if kwin does the same though, i'll do some more testing later since i've only got hyprland, sway, and wayfire (all wlroots)
14:26MrCooper: ErrorNoInternet: did you load the nvidia_drm module with the modeset=1 parameter?
14:39wlb: weston Merge request !1386 opened by Marius Vlad (mvlad) desktop-shell/input-panel: Re-work the input surface mapping https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1386
14:41ErrorNoInternet: MrCooper: yes
15:18wlb: weston/main: Aske Bækdal Møller * clients: keyboard: fix delete before cursor https://gitlab.freedesktop.org/wayland/weston/commit/33ec3898d0ae clients/keyboard.c
15:18wlb: weston Merge request !1227 merged \o/ (clients: keyboard: fix delete before cursor https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1227)
19:27bwidawsk: Is there a specific callout that pointer,keyboard,touch all shall be the same version as seat? Same for data_device_manager
19:27vyivel: bwidawsk: all objects created with some other object have the same version
19:28vyivel: it's specified in the wayland docs somewhere
19:28bwidawsk: vyivel: yeah, was trying to find it
19:28bwidawsk: mostly for my curiosity
19:29vyivel: https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Versioning
19:32bwidawsk: vyivel: thanks!
19:32bwidawsk: I read through that and missed it the first time
21:09wlb: weston Merge request !1387 opened by Marius Vlad (mvlad) build: bump to version 12.0.94 for the RC2 release https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1387
21:14wlb: weston/main: Marius Vlad * build: bump to version 12.0.94 for the RC2 release https://gitlab.freedesktop.org/wayland/weston/commit/7d7ce84cc670 meson.build
21:14wlb: weston Merge request !1387 merged \o/ (build: bump to version 12.0.94 for the RC2 release https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1387)
21:16wlb: weston New tag: 12.0.94 https://gitlab.freedesktop.org/wayland/weston/tags/12.0.94
21:25wlb: wayland.freedesktop.org Merge request !70 opened by Marius Vlad (mvlad) releases: add weston 12.0.94 release https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/70
21:26wlb: wayland.freedesktop.org Merge request !70 merged \o/ (releases: add weston 12.0.94 release https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/70)
21:26wlb: wayland.freedesktop.org/main: Marius Vlad * releases: add weston 12.0.94 release https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/a1832f754e97 releases/weston-12.0.94.tar.xz releases/weston-12.0.94.tar.xz.sig releases.html