00:09 tommybomb: looks good
01:16 marex: this is probably not the best place to ask, but ...
01:16 marex: [328:328:0221/011510.720137:ERROR:wayland_event_watcher.cc(38)] libwayland: xdg_wm_base@23: error 4: xdg_surface geometry (500 x 272) is larger than the configured fullscreen state (480 x 272)
01:17 marex: I get this ^ when I start chromium 109 on stm32mp15xx board with 480x272 panel
01:17 marex: i.e. chromium --start-fullscreen --kiosk
01:29 bl4ckb0ne: looks like a chromium bug
01:30 soreau: but it works on wlroots wayland backend if I set that 'mode' and use the same options..
01:30 soreau: it looks like error 4 is https://wayland.app/protocols/xdg-shell#xdg_wm_base:enum:error:entry:invalid_surface_state "the client provided an invalid surface state" which seems like whatever compositor you're using is assuming this is a client bug
01:36 marex: weston
01:37 marex: I have seen this with gstreamer before too, I need to recheck that one
01:41 soreau: I get the same error from chromium when I try weston wayland backend with that resolution
01:41 marex: scratch that, gstreamer seems just fine on this one
01:41 soreau: but it works with wayfire
01:41 marex: btw weston 10.0.2
01:42 marex: soreau: it works fine with weston with other resolution panels too
01:42 marex: I wonder if chromium is doing some weird rounding
01:42 soreau: idk why weston thinks this is an error though.. what if this is the client surface minimum size? or the min size was larger than the output resolution in some dimension?
01:43 marex: if I stick a breakpoint into libweston/desktop/xdg-shell.c line 770 , and run BT once that triggers , I should get a backtrace all the way into chromium, right ?
01:43 soreau: no?
01:43 marex: no ... I won't, coz chromium isnt linked against this
01:44 marex: https://bugs.chromium.org/p/chromium/issues/detail?id=875197 well
01:45 marex: "since version 97 a minimum size limit of 500px now also applies to app windows"
01:46 marex: I don't want to dig into (last time I checked 89 GiB) of chromium git repo Y_Y
01:47 soreau: maybe try a different compositor, or hack weston to remove that conditional and see if everything happens to work out
01:48 marex: no, better fix this the right way
01:49 marex: I mean, if someone hard-coded 500px into chromium, it should be easy enough to find with git grep, and then patch+rebuild
01:54 marex: chromium$ git grep '\<500\>' | wc -l
01:54 marex: 11593
01:54 marex: hmmmm, OK, that ... is more than I expectedc
01:56 soreau: https://wayland.app/protocols/xdg-shell#xdg_toplevel:request:set_min_size
01:57 marex: soreau: thanks, that does indeed limit it a lot
01:58 soreau: marex: try setting WAYLAND_DEBUG=1 for chromium and grep for set_min_size
01:58 soreau: here I get 5 calls, and the width is always 500
01:59 marex: indeed
01:59 marex: [ 555599.622] -> xdg_toplevel@28.set_min_size(532, 121)
01:59 marex: [ 555602.154] -> xdg_toplevel@28.set_min_size(532, 121)
01:59 marex: [ 555607.348] -> xdg_toplevel@28.set_min_size(500, 0)
01:59 marex: [ 555638.572] -> xdg_toplevel@28.set_min_size(500, 0)
01:59 marex: [ 555645.575] -> xdg_toplevel@28.set_min_size(500, 1)
01:59 marex: I get these ...
02:00 soreau: you probably could grep the source for set_min_size too, if you're aiming to rebuild it
02:00 marex: I suspect the top two are likely the toolbar
02:00 marex: soreau: I am already looking around, but I suspect this gets called through layers of abstraction
02:00 marex: but then, I might be able to put gdb breakpoint in there
02:03 marex: ui/ozone/platform/wayland/host/xdg_toplevel_wrapper_impl.cc seems like the only sane place
02:07 marex: chrome/browser/ui/views/frame/browser_view_layout.h
02:07 marex: 51 static constexpr int kMainBrowserContentsMinimumWidth = 500;
02:07 marex: dang
04:05 marex: so yeah, that one is the change ... now how to upstream that into chromium, urgh
04:13 soreau: there's even some options you think that might help, like --window-size or --ozone-override-screen-size, but none of them affect the minimum size apparently
04:17 soreau: and if you want to patch chromium, maybe those options or some other new option should be able to override the default
04:26 marex: soreau: I had a look at the contribution guidelines, ugh ... I just sent email to the commit authors with a oneliner patch, let's see what happens
07:27 kennylevinsen: soreau, marex: when the window state is fullscreen: "The window geometry specified in the configure event is a maximum; the client cannot resize beyond it."
07:34 soreau: I see, https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/423 https://wayland.app/protocols/xdg-shell#xdg_toplevel:enum:state:entry:fullscreen
07:35 soreau: but where is the part that says set_min_size() is meaningless when fullscreen
07:39 kennylevinsen: in set_min_size: "The compositor can use this information to allow or disallow different states like maximize or fullscreen and draw accurate animations.", but also: "The client should not rely on the compositor to obey the minimum size."
07:41 kennylevinsen: so the compositor *might* just block fullscreen altogether, or not and request a size smaller than min which must be obeyed. Either is fine by the protocol it seems.
09:01 pq: soreau, weston thinks it is an error, because the protocol spec defines it to be an error.
09:04 pq: yeah, Weston could just refuse the fullscreening request completely if min_size indicates the client cannot do it. Would that be better?
09:05 pq: I bet then naive clients will get confused when they didn't get to be fullscreen like they asked... but that's again a client bug
09:39 soreau: it would make more sense if the compositor would scale the image down, preserving aspect, center and apply black borders if needed, in the case that it is larger than the output geometry
09:40 soreau: it's nice that there is the freedom to implement what you want without regard for the written spec..
09:41 pq: soreau, but then the window becomes unreadable, if eve the client is unable to make it any smaller.
09:41 pq: *even
09:42 pq: soreau, it is very much regarding the written spec.
09:43 pq: compositor that do not send the error are not implementing the protocol as spec'd
09:43 soreau: indeed
09:44 soreau: also, it's nice to have fullscreen semi-transparent terminal with blurred desktop contents blended
09:45 soreau: instead of boring black
09:45 pq: maximized, sure
12:06 pq: swick[m], I tought of adding rendering intents to the protocol. Technically it looks like it should be defined independently for each image description factory, but that's also very redundant at first. What do you think?
12:19 pq: oh, we already have rendering intents, but not inside image description - makes sense
12:29 wlb: wayland-protocols Merge request !195 opened by Jonas Ådahl (jadahl) xdg-output: Remove and tweak contradicting examples https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/195 [xdg-output]
12:32 wlb: wayland-protocols/main: Simon Ser * xdg-output: clarify goal https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/cf838fd316f7 unstable/xdg-output/xdg-output-unstable-v1.xml
12:32 wlb: wayland-protocols Merge request !190 merged \o/ (xdg-output: clarify goal https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/190)
12:34 wlb: wayland Merge request !279 closed (meson: do not build under Windows and macOS)
12:34 wlb: wayland-protocols Merge request !168 closed (meson: do not build under Windows and macOS)
14:27 swick[m]: pq: I'm not sure about rendering intents outside ICC
14:28 pq: swick[m], you mean everything else would be random magic perceptual?
14:29 swick[m]: jup
14:29 swick[m]: but I also started to wonder about separating the video signal description from the parametric description
14:29 pq: with the exception of a client using an output image description directly
14:30 pq: what do you mean?
14:30 swick[m]: if the image description of the output and input is the same there is no conversion required and thus the rendering intent is meaningless
14:32 swick[m]: urgh, wait, I got it wrong in my head again
14:33 pq: yes, I've been thinking about writing down that if a client uses the output image description directly on a surface, then rendering that surface on that output will be "no conversion".
14:34 pq: so overrride render intent, but on that output only
14:34 pq: and only as long as the image description is current on that output
14:36 swick[m]: so an image description tells us the colorimetry for a specific output in a specific viewing environment. no matter how we get that colorimetry (ICC or params), we need a rendering intent when we want to convert that to the image description of the output.
14:37 swick[m]: so I guess it makes sense to keep it outside of the image description
14:38 swick[m]: but also supporting different rendering intents requires specific support for them in the compositor
14:39 swick[m]: probably makes sense to make them all optional except for perceptual
15:34 wlb: wayland/main: Peter Hutterer * protocol: add wl_pointer's axis relative physical direction https://gitlab.freedesktop.org/wayland/wayland/commit/1ef773be76ec protocol/wayland.xml
15:34 wlb: wayland Issue #344 closed \o/ (Communicate scroll inversion/natural scrolling flag to clients https://gitlab.freedesktop.org/wayland/wayland/-/issues/344)
15:34 wlb: wayland Merge request !183 merged \o/ (protocol: add wl_pointer's axis relative physical direction https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/183)
22:45 tommybomb: Hi, I wanted to know why most inputs are put through the wayland protocol, but the gamepad (controller) is not. Any info is welcomed, thanks.