08:03MrCooper: zamundaaa: https://zamundaaa.github.io/wayland/2024/04/05/explicit-sync.html misrepresents my blog post it references, it's nothing to do with "effectively explicit sync through a backdoor"
08:10vyivel: yeah i was confused by this too
08:16YaLTeR[m]: same
08:53pq: emersion, I replied in gitlab about the output transform clarification.
08:54emersion: ty!
08:58pq: playing with a pen, paper and scissors should help understand :-)
08:59pq: cut a sheet of paper, label it as "buffer" and draw something totally asymmetric on it
09:00pq: take another sheet of paper, (cut out the inside,) mark the normal up and right orientation, and label it as the monitor
10:12zamundaaa[m]: MrCooper: as I see it, it's getting an acquire fence and using it as if the client had explicit sync support
10:12zamundaaa[m]: What would you describe it as instead?
10:19MrCooper: implicit sync in the protocol works the same regardless
10:20MrCooper: I didn't mention anything about explicit/implicit sync in my post because it's orthogonal
10:20MrCooper: the same issue is possible with explicit sync if the compositor is stupid
10:26zamundaaa[m]: Sure. I'm not saying your blog post is about explicit sync through a backdoor, only that it uses the kernel mechanism for explicit sync interop
10:27zamundaaa[m]: I can reword it to be more clear about that
10:27MrCooper: I'd appreciate that
10:38zamundaaa[m]: is it better now?
10:44MrCooper: yes, thanks
12:01wlb: wayland-protocols Issue #189 opened by Nelson Benítez León (nbenitez) Enhance DND protocol to be able to send scroll events to surface under https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/189
12:08wlb: wayland-protocols Issue #190 opened by Alex Folland (lexlexlex) Allow scroll whell during drag-and-drop dragging https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/190
12:12wlb: wayland-protocols Issue #190 closed \o/ (Allow scroll whell during drag-and-drop dragging https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/190)
13:58wlb: weston Merge request !1490 opened by Marius Vlad (mvlad) Deprecate weston_layer_entry_insert/weston_layer_entry_remove in favor of weston_view_move_to_layer() https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1490 [Core compositor]
14:45wlb: weston Merge request !1491 opened by Pekka Paalanen (pq) Improve test ICC profiles, switch default rendering intent https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1491 [color-lcms plugin], [Colour management], [Testing]
17:33wlb: weston Merge request !1492 opened by Derek Foreman (derekf) libweston-desktop: Store weston_surface in grabs https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1492 [libweston-desktop]
18:38Company: zamundaaa: have you ever considered a global or per-app setting in KDE to force apps to integer scale factors even though the desktop is using fractional scaling?
18:41zamundaaa[m]: no, not really. People have been asking for per-app scaling settings, but only for X11 apps so far
18:42zamundaaa[m]: I have considered faking a higher resolution to apps though, like the super resolution feature on Windows
18:42zamundaaa[m]: What would you want such a setting for?
18:44Company: I was looking at scaling settings and just wondered
18:44Company: there might be apps that can't properly deal with fractional scales - ie a common problem is seams - and you can trade those vs slight vlurriness
18:45Company: and yeah, another option to avoid that might be some form of supersampling
18:47Company: if I understand things correctly, Qt 6 and GTK 4 do render at fractional scales, but Mac OS does not
18:47Company: and it might be that users (or developers?) might want to switch between the 2 modes
18:54zamundaaa[m]: It wouldn't be difficult to implement per se, you can just filter out the global
18:55kennylevinsen: hmm? pretty sure macOS has fractional scales through its 5 very abstract "size" settings (a scale that goes from "larger text" to "more space")...
18:55zamundaaa[m]: MacOS only does integer scaling
18:56zamundaaa[m]: What you're talking about might be a global text size setting or something like that?
18:57Company: kennylevinsen: afaik MacOS renders apps at integer scales and then downscales them to the selected fractional scale
18:57kennylevinsen: No it's the whole UI, the control replaced their resolution controls when they added hiDPI support
18:58Company: so whatever Qt5/GTK3 does
18:58kennylevinsen: And the increments are certainly non-integer, but it may be that the apps render at 2x and are downscaled
18:59Company: I think you can also select "low resolution" and then it upscales or so
19:00Company: https://i.imgur.com/Rq6I80u.png is an example screenie of the extended list
19:02Company: Apple seems to pick resolutions that end up with integer sizes - which is why it lists pixel sizes instead of scale factors
19:02Company: I checked the list and they're all multiples of 16:9
19:03kennylevinsen: This is the UI I'm referring to: https://www.eizoglobal.com/support/compatibility/dpi_scaling_settings_mac_os_x/image01.jpg
19:04Company: that's the old UI for that I think?
19:05Company: still doesn't list scale factors though
19:05kennylevinsen: This is the older control panel yeah, just pulled a random screenshot. But whether it shows scale or resolution has traditionally depended on the monitor - external third party monitors got the resolution drop-down, internal panels and I think apple screens got the scale options
19:07Company: they still don't show the scale factor though I think?
19:07kennylevinsen: No they won't tell you what it is, just vague names for it...
19:09wlb: weston/main: Derek Foreman * gl-renderer: apply output transform before readback in repaint https://gitlab.freedesktop.org/wayland/weston/commit/527bc8aeb313 libweston/renderer-gl/gl-renderer.c
19:09wlb: weston Merge request !1485 merged \o/ (gl-renderer: apply output transform before readback in repaint https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1485)
19:10Company: "1920x1080, 2560x1440, 3008x1692, 3360x1890 and 3840x2160" are the scales for those 5 options, so that's 2/1, 3/2, 60/47 and 8/7 (what is up with the last 2?)
19:11kennylevinsen: That's some cursed fractions... :)
19:11kennylevinsen: https://developer.apple.com/documentation/appkit/nsscreen/1388385-backingscalefactor?language=objc
19:12Company: whatever you do with fractional scaling, it's all cursed - either you get seams on well-aligned boxes or blurry text
19:12kennylevinsen: Ah: https://developer.apple.com/documentation/appkit/nswindow/1419459-backingscalefactor
19:13kennylevinsen: Apple documents that one as, despite being a float, always being 1.0 or 2.0
19:13Company: huh
19:13kennylevinsen: But says "don't use it, use our coordinate space converters instead"
19:13Company: I would have expected it can be 3.0 or even 4.0
19:14kennylevinsen: Their "retina" panels aren't *that* high resolution, 3x would be pretty darn big...
19:15Company: I was thinking if you set the resolution to 1280x720 in that dropdown
19:15Company: it seems suitable to make apps render at 3x then
19:16wlb: weston Merge request !1493 opened by Derek Foreman (derekf) Backport some gl-renderer fixes https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1493
19:16kennylevinsen: True, there isn't a reason you couldn't do it
19:17kennylevinsen: But it's also not a normally exposed setting on their laptops so maybe it's not a "supported" use case.
19:18Company: technically, that means all their text is slightly blurry though
19:18Company: probably doesn't matter because their monitors are high enough dpi
19:19kennylevinsen: Either way, zamundaaa seems right that the apps render integer, and it just gets scaled to the selected fraction like we used to in Wayland... land
19:21kennylevinsen: To be fair, if you pick 3x scaling on these monitors you are probably doing out of visual accessibility needs and won't detect a slight clarity issue...
19:23kennylevinsen: Hmm. Although, if 2.0 is their normal hidpi for their "middle" setting, a 50% "more text" boost is already 3.0 scaling. You have a point.
19:23kennylevinsen: *bigger text
19:24Company: the laptop I have is a 14" with 4k resolution - I usually drive that at 200% but I have been using 250% accidentally for a while
19:25Company: and I'm not that blind
19:25kennylevinsen: Yeah I was thinking of 1.0 being the starting point, in which case 3x over base scale is very big. 50% over base scale isn't that much.
19:25kennylevinsen: Error on my part
19:25kchibisov: Company: apple emboldens all the fonts and doesn't do subpixel.
19:25kchibisov: so it's ok.
19:26kchibisov: Like because fonts are _thick_ enough, it's really hard to notice.
19:26kennylevinsen: No subpixel antialiasing is one of the few apple decisions I fully support
19:27kchibisov: I hate font embolden thing.
19:27kchibisov: it just breaks all the metrics, etc.
19:28YaLTeR[m]: also breaks websites for everyone else
19:28kchibisov: They also tend to change the setting to disable this mess.
19:28kchibisov: yeah, if you pick light font, it's like regular on apple stuff.
19:28kchibisov: But with broken glyph shapes.
19:29Company: YaLTeR[m]: fonts breaking everything is something that everyone should enjoy forever, so no pity from my side there
19:30Company: I also love that Apple's fix for crappy looking fonts is "buy better monitor"
19:31Company: the most rich people thing ever
19:48mclasen: its nice if you can assume working hw
21:32emersion: pq, daniels, jadahl: how does that release schedule sound? https://paste.sr.ht/blob/2a9d393b1755b227d577756f9480575474bb9d03
21:40daniels: emersion: with the caveat that I only started reading email yesterday and am still nowhere done, sgtm
21:40daniels: (is there anything I should be looking at as a priority?)