08:54 <kidplayer666> i saw the release of hdmi support!! real nice! (guessing that dp alt is cooking too)

09:14 <MichaelLong> kidplayer666, where and how it hdmi support released?

09:15 <kidplayer666> Apparently with the new kernel, for laptops with an hdmi port

09:17 <MichaelLong> kidplayer666, I'm only aware of this post: https://social.treehouse.systems/@marcan/111435705255320195

09:17 <MichaelLong> which is really nice!

09:18 <kidplayer666> https://usercontent.irccloud-cdn.com/file/yHzl2uzP/1701595093.JPG

09:18 <kidplayer666> I saw this one

09:18 <MichaelLong> kidplayer666, ohh

09:19 <MichaelLong> I'll have to test immediately :> thx

09:19 <kidplayer666> lol

09:19 <kidplayer666> You’re welcome

09:19 <kidplayer666> MichaelLong: tell us the results

09:32 <MichaelLong> great it works for me! There was one minor kosmetic irritation: I'm using a LG 38WN95C-W display that has a resolution of 3840x1600, after pluging in KDE however selected 3840x2160. Probably an EDID issue? But great work really :)

10:19 <ydalton> kidplayer666: hopefully, but we'll have to wait as hdmi != dp alt mode

10:26 <PaulFertser> MichaelLong: a resolution higher than the display supports was selected and it still works? Something doesn't sound right there.

10:28 <MichaelLong> PaulFertser, not sure how that worked but the displayed screen was cropped and blurred on the 2160p resolution. But I could easily select the correct resolution from the kscreen menu.

10:31 <MichaelLong> could be a one off issue, was not able to reproduce it when pluggin the hdmi a couple of times

10:44 <ydalton> rebooting into the new kernel, i see the addition of the dcpext DT node, but it's disabled, as expected

10:52 <sven> altmode will probably take a while longer. the bigger issues are still inside atcphy and typec/tipd, but we're slowly making progress there

10:54 <ydalton> sven: thanks for the news!

11:31 <janneg> dp only mode on atc-phy3 of 14-/16-inch macbook pros worked so far without issue. so that part might avoided the usb curse somehow

11:33 <janneg> MichaelLong: interesting. can you still select 3840x2160 in kde's display settings? we only forward modes reported by the dcp firmware

11:42 <sven> yeah, if atcphy isn’t coupled to dwc3 or acio it should be stable

11:42 <sven> there’s still something strange with the pipehandler vs. dwc3 vs. atcphy bringup though in my current tree :/

11:46 <PaulFertser> Hm, so there's no direct access to EDID data via dcp?

11:52 <janneg> PaulFertser: not hooked in the expectation that it might cause trouble

11:54 <ydalton> EDID is basically data from a monitor showing what modes are possible?

11:58 <sven> pretty much

11:58 <PaulFertser> Also information about manufacturer and model, and physical size (needed to get DPI right)

12:00 <PaulFertser> https://paste.debian.net/1300014/

12:00 <PaulFertser> And information related to colour capabilities, gamma etc.

12:00 <janneg> dcp reports the size (although in centimeters and not in millimeter)

12:02 <ydalton> wait, is that from the X server?

12:03 <PaulFertser> I'm kind of surprised you do not trust the common software layers to do the right thing with the EDID info. But knowing how much you care about visual aspects I conclude you have some veryy valid reasons for that.

12:03 <ydalton> that paste bin

12:03 <PaulFertser> ydalton: yes, plain Xorg.

12:04 <PaulFertser> ydalton: but that's Xorg running on an SBC, so not really related to Asahi. I just wanted to give an example of EDID to show what's there available inside.

12:05 <janneg> https://gist.github.com/jannau/496ca6f9b5978207108295b1ec4a9cc9

12:06 <ydalton> janneg, PaulFertser: ah thanks! i always wondered how the GPUs got the modes from the monitors connected to them

12:06 <janneg> apparently dcp stopped reporting the display size there

12:08 <janneg> PaulFertser: I do not trust the common software layers to arrive at the same results as the dcp firmware and that might cause issues in the form of failing to modeset at all

12:13 <PaulFertser> btw, can someone probably explain what the deal with all that fractional scaling issues really is? I was assuming that it doesn't concern text at all as most applications are using vector fonts and they're scaled automatically correctly (taking DPI into account) for very long time, and the problem is only with bitmap graphics of UI elements, they become too tiny? Is it still common to use bitmaps

12:13 <PaulFertser> for icons etc?

12:14 <PaulFertser> janneg: ah, I see, if the modesetting is basically all outsourced to DCP firmware then no wonder.

12:15 <PaulFertser> ydalton: for the reference, it's basically just an EEPROM connected via I2C.

12:31 <ydalton> PaulFertser: over HDMI?

12:33 <sven> yeah, hdmi has i2c lines. for DP it’s sent over the AUX channel iirc

12:33 <PaulFertser> ydalton: https://pinoutguide.com/Video/hdmi_pinout.shtml DDC clock/data

13:56 <kidplayer666> PaulFertser: i think it’s mainly on gnome where it’s still experimental, and while most of the desktop appears ok, anytbing x11 gets horribly grainy

13:56 <kidplayer666> KDE is fine on that regard though

14:39 <PaulFertser> kidplayer666: I've read the post about it but I'm not understanding the basics. Why is scaling of any kind is involved at all when all the fonts used are vector (OpenType/TTF etc)?

14:40 <PaulFertser> I remember issues with very old apps which were built without "layouts"/"flexible containers" where the UI element positions were hardcoded in pixels, yes, but all the modern toolkits have dynamic layout, so, again, they're always fractionally scaled. So what's left, the UI icons?

14:40 <kidplayer666> PaulFertser: I am not qualified or knowlegable to know the specifics, but x11 does not support fractional scaling properly. KDE gets around this on wayland by just letting x11 apps apply their own scaling. Gnome tries to apply the scaling to the whole thing and it goes wack

14:41 <kidplayer666> iirc

14:43 <PaulFertser> kidplayer666: all vector fonts in X11 are scaled to provide the right size in "pt" (physical dimensions), and layouts are dynamic, so what exactly is missing?

14:43 <kidplayer666> no idea. As i said, all i know is that it goes wack

14:45 <PaulFertser> kidplayer666: do you mean wayland forces rescaling of all rootless Xwayland windows?

14:45 <kidplayer666> i do not know. i think gnome tries to force scaling while kde is chill about it

14:45 <PaulFertser> I'd be grateful for someone to unconfuse me.

14:47 <PaulFertser> You mean Wayland compositor that's part of gnome is telling wayland to rescale Xwayland regions and there's no way to have it not to?

14:50 <kidplayer666> PaulFertser: I'd be grateful too, I am just repeating some bits i heard here and there

14:50 <kidplayer666> no idea how mutter and the kde compositor actually work

15:06 <MichaelLong> janneg, sorry I was only able to check it just now: I can still see the wrong resolution. But I have totally forgotten I'm running a cheap chinese KVM-switch in between. The wrong resolution is also advertised on at least one other system currently connected. I'll see if I can find another HDMI cable to connect it directly to the display....

15:33 <janneg> MichaelLong: ah, it's probably in the EDID from the KVM then. does the wrong resolution get's advertized in macOS as well?

15:34 <MichaelLong> janneg, most likely I'll check next time, sorry for the noise :)

19:48 <Nefsen402> I tried using HDMI and it worked for my display. It litup 4k at 60Hz. I also discovered that you guys are handling clam shell mode! That was a surprise. But then I manually hit the suspend button. The display did come offline, but refused to ever come back online. Even after a hotplug, it's dead jim. journalctl -k logs: https://ozal.ski/dcp-log.txt

20:52 <cy8aer> HDMI with mbp and 12.x firmware: is it reinstall m1n1 stage 1 with 13.5 the old way?

20:53 <cy8aer> (delete partition and install with efi only and get back the old efi settings=

20:58 <cy8aer> and m1n1 1.4.8 minimum...