01:43wlb: weston Merge request !1180 opened by Leandro Ribeiro (leandrohrb) xwayland: Handle shell hint for client to choose dimensions https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1180
06:40wlb: weston/main: Michael Olbrich * compositor/text-backend: use xzalloc everywhere https://gitlab.freedesktop.org/wayland/weston/commit/00f08ec79c51 compositor/text-backend.c desktop-shell/shell.c
06:40wlb: weston Merge request !1178 merged \o/ (compositor/text-backend: use xzalloc everywhere https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1178)
06:48wlb: weston/main: Philipp Zabel * backend-vnc: rename vnc_convert_damage to vnc_region_global_to_output https://gitlab.freedesktop.org/wayland/weston/commit/12a7e4e16358 libweston/backend-vnc/vnc.c
06:48wlb: weston Merge request !1175 merged \o/ (backend-vnc: rename vnc_convert_damage to vnc_region_global_to_output https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1175)
10:28emersion: ofourdan: do you remember why the number of bits is stored instead of the actual size in !188?
11:28wlb: wayland/main: Simon Ser * 5 commits https://gitlab.freedesktop.org/wayland/wayland/compare/ab526f8d7c80433effd01c1994d50c618c0b7207...d72f9007c36f2f8ad2dc26178545e8a7f5b993a0
11:28wlb: wayland Merge request !282 merged \o/ (client: Improve handling of event queue destruction with attached proxies https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/282)
12:50pq: emersion, re: overscan; I think it comes from the older CRT having round corners and curved edges, and overscan making sure all the phosphor lights up properly, clipping image edges out in the process. :-)
12:51emersion: aha, got these mixed up
12:51pq: how wonderful that we still need to care about these things
12:51emersion: cute, another CRT explanation for historical gfx stuff
12:52emersion: yeah, really glad we have TVs with the latest and greatest technology 2023 has to offer
12:53pq: also, since it was known that receiver CRT will clip, the broadcast has some cruft at the edges that then got clipped.
12:53emersion: ok, so overscan is when clipping happens, and underscan is when there is letterboxing
12:53emersion: (from a user PoV)
12:53pq: meaning that also flat planels needed to clip as well -> overscan by default in TVs
12:53emersion: oh, that's why
12:54kennylevinsen: overscan by default makes me so very upset
12:54emersion: i wonder if HDMI content type helps
12:54emersion: ie, if I set HDMI content type, will it fix most TVs
12:54vsyrjala: iirc no
12:54pq: I believe HDMI has explicit under/overscan messages
12:55pq: do TV's actually listen to those? ha ha...
12:55vsyrjala: i don't recall if you can tell it to do anything. iirc it can tell you whether it indends to overscan vs. undescan for ce vs. it modes separately of course
12:55pq: some do, some don't, and so we need a workaround
12:56emersion: how does the source know how to set the margins correctly?
12:56emersion: some EDID thing?
12:56emersion: (can't remember of any)
12:56pq: vsyrjala, oh gosh, it was a message in the wrong direction
12:56emersion: i remember the user configuration UIs to setup margins though
12:57emersion: ah, ok, so some vague CTA stuff may help
12:57vsyrjala: hmm. there is under/overscan stuff in the avi infoframe
12:57emersion: but we don't know whether we picked CE or IT…
12:57pq: yeah, console games often(?) have margin setup UI
12:58emersion: vsyrjala: separate from the bars stuff?
12:58swick[m]: we really need a bit more info on modes for underscan, overscan and color range
12:59swick[m]: or we just figure it out from the EDID and then compare the modes with the KMS modes
12:59vsyrjala: emersion: yeah, and apparently we always set it for underscan. but i'm pretty sure many tvs still overscan
12:59emersion: vsyrjala: we = drm core or i915, out of curiosity?
12:59vsyrjala: drm_hdmi_avi_infoframe_from_display_mode
13:00emersion: ah core, nice
13:00emersion: since we set it, some TVs might obey and some might not, so margins really need to be user-configured
13:02vsyrjala: looks like vcdb allows the sink to declare what kinds of scan it supports. separately for different kinds of modes of course :/
13:03vsyrjala: iirc i once saw some recommendation document for braodcast tv subtitle/etc placement. can't recall the specific numbers
13:05emersion: hm right, because you can also place "unimportant" details in the image area which will be potentially overscanned
13:05emersion: which is impossible with the margins KMS props btw
13:06zamundaaa[m]: <emersion> "ok, so overscan is when clipping..." <- At least the overscan and underscan drm properties do the same thing afaik - they both pad the image on the borders
13:06emersion: (i wish the margins were signalling only, and wouldn't actually do anything to the buffers…)
13:07emersion: zamundaaa[m]: this discussion comes from https://lore.kernel.org/dri-devel/Y%2F3uqqeW73tiutgR@intel.com/T/#m0e2c1231ec816c28fa63713c236f09a7df951167
13:07vsyrjala: dunno if anything uses the avi bars info tbh. also dp has no such thing afaik
13:07emersion: the overscan and underscan props are not standard afaik
13:07emersion: vsyrjala: ah, good to know
13:10zamundaaa[m]: yes, they're not standard, but we support them in KWin
13:10zamundaaa[m]: I do have one question on that topic... does this possibly affect DisplayPort at all, or is it only HDMI and old connectors like VGA?
13:11emersion: ville has a branch with DP support for margins props
13:11vsyrjala: not sure there are any native dp monitors that overscan. but dp->hdmi converters are certainly a thing
13:11emersion: i haven't seen it on VGA
13:11emersion: only HDMI and TVout
13:12zamundaaa[m]: vsyrjala: We can detect those converts with the subconnector property though, right?
13:12vsyrjala: they look like normal dp
13:13vsyrjala: don't think we have any subconnector stuff hooked up for that
13:13emersion: I think we do?
13:13emersion: at least I've seen subconnector=HDMI on DP
13:14emersion: the other intern next to me back when I was at Intel implemented it :P
13:15vsyrjala: hmm. yes, apparently we do
13:15vsyrjala: totally forgot that landed
13:17vsyrjala: doesn't seem super robust though. my type-c -> hdmi dongle says 'Native'
13:19emersion: ah, sad
13:20emersion: maybe the interface type in the EDID could be more reliable, if set
13:20emersion: or is this what the kernel uses?
13:20vsyrjala: looks like it currently uses just the dpcd downstream port info
13:23vsyrjala: i did tweak some of other dp->hdmi stuff to also check the edid. but that still wouldn't help here since this dongle apparently doesn't claim to be a branch device at all
13:23emersion: rip
13:24zamundaaa[m]: I guess we'll keep on showing the setting for all connector types that support it then... except maybe eDP, it really shouldn't need it
13:24zamundaaa[m]: I hope
13:26vsyrjala: well, you might want to tweak the edp output size to get eg. 2x integer scaling or something like that
13:29zamundaaa[m]: I'm not sure what you're referring to. What does over/underscan have to do with integer scaling?
13:30vsyrjala: you could use the margins for other things than overscan compensation
13:32emersion: i'm not sure i'm following…
13:34vsyrjala: say you have an emulator rendering at 320x200, you set the mode to match that, set scaling mode=fullscreem, and configure the margins to get an exact integer multiple upscale factor
13:36pq: would that also work on a HDMI monitor that uses the infoframe bar data?
13:37vsyrjala: for external connectors the panel will be driven with the mode the user passed in, so no
13:37pq: ah
13:37pq: "scaling mode" is not infoframe data?
13:38zamundaaa[m]: vsyrjala: I'm only talking about hiding the setting from the user in our GUI, where we just give them a 0-100% overscan spinbox
13:38vsyrjala: pq: no. it just specifies how we set up the scaler
13:38zamundaaa[m]: That sounds like an interesting hack though, one that I hopefully never need to implement
13:39vsyrjala: i have occasionally pondered about exposing a 'fixed mode' property for all connector. would allow the same kind of scaler usage for external connectors that you get with internal ones atm
13:40pq: use of the scaler inside an external monitor?
13:40vsyrjala: scaler inside the gpu
13:40pq: display controller?
13:40vsyrjala: yes. right now with external monitors the monitor alwasy does the scaling
13:41pq: oh, right, to avoid monitor's scaler
13:41pq: but then, userspace can simply use the external monitor's native mode, and set up KMS scaling itself
13:42vsyrjala: if you have scalable planes
13:42pq: by plane props
13:43pq: is it common for hardware to have a scaler in/after CRTC but not on planes?
13:43vsyrjala: older intel hw was like that. well, there was usually one scalable sprite plane, primary/cursor could not be scaled
13:44vsyrjala: and current intel hw has usually two scalers per crtc. each one can scale one plane or the whole crtc
13:45vsyrjala: oh, and cursor still can't be scaled on its onw. only as part of the whole crtc
13:55vsyrjala: iirc there was some other proposal for defining the crtc viewport size independent of the mode via separate properties. but i think reconciling that with the way edp/lvds/etc. works currently would tricky
16:17wlb: wayland/main: Simon Ser * build: bump version to 1.21.91 for the alpha release https://gitlab.freedesktop.org/wayland/wayland/commit/344d31f871e7 meson.build
16:17wlb: wayland New tag: 1.21.91 https://gitlab.freedesktop.org/wayland/wayland/tags/1.21.91
16:28wlb: wayland.freedesktop.org/main: Simon Ser * releases: add Wayland 1.21.91 https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/cf92f7f78c1b releases.html
17:15wlb: weston/main: Alexandros Frantzis * xwayland: Handle shell hint for client to choose dimensions https://gitlab.freedesktop.org/wayland/weston/commit/2acd2c74891c xwayland/window-manager.c
17:15wlb: weston Issue #722 closed \o/ (Resize is broken for X windows https://gitlab.freedesktop.org/wayland/weston/-/issues/722)
17:15wlb: weston Merge request !1180 merged \o/ (xwayland: Handle shell hint for client to choose dimensions https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1180)
19:00emersion: pq, fyi: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d4563201f33a022fc0353033d9dfeb1606a88330
19:01emersion: (you were asking about this a while back)
22:33wlb: wayland Merge request !297 opened by Alexandros Frantzis (afrantzis) client: Do not warn about attached proxies on default queue destruction. https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/297