ChanServ changed the topic of #asahi-alt to: Asahi Linux: porting Linux to Apple Silicon macs | User-contributed/unofficial distribution ports | Logs: https://alx.sh/l/asahi-alt
jeisom has joined #asahi-alt
jeisom has quit [Remote host closed the connection]
jeisom has joined #asahi-alt
john-cabaj has quit [Ping timeout: 480 seconds]
jeisom has quit [Remote host closed the connection]
jeisom has joined #asahi-alt
mini_ has joined #asahi-alt
jeisom has quit [Remote host closed the connection]
jeisom has joined #asahi-alt
jeisom has quit [Remote host closed the connection]
jeisom has joined #asahi-alt
jeisom has quit [Remote host closed the connection]
jeisom has joined #asahi-alt
jeisom has quit [Remote host closed the connection]
jeisom has joined #asahi-alt
jeisom has quit [Remote host closed the connection]
jeisom has joined #asahi-alt
ciara has quit [Remote host closed the connection]
jeisom has quit [Remote host closed the connection]
ciara has joined #asahi-alt
jeisom has joined #asahi-alt
fugi8 has joined #asahi-alt
fugi has quit [Ping timeout: 480 seconds]
fugi8 is now known as fugi
eiln has joined #asahi-alt
jeisom has quit [Quit: Leaving]
betashell has joined #asahi-alt
betashell has quit [Remote host closed the connection]
possiblemeatball has quit [Quit: Quit]
kidplayer666 has joined #asahi-alt
kidplayer666 has quit [Quit: Connection closed for inactivity]
millenialhacker has joined #asahi-alt
millenialhacker_ has quit [Ping timeout: 480 seconds]
millenialhacker has quit [Quit: Konversation terminated!]
kidplayer666 has joined #asahi-alt
eiln has quit [Quit: WeeChat 4.1.2]
KxCORP has quit [Quit: Bye!]
KxCORP has joined #asahi-alt
_alice_ is now known as _alice
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-alt
utsweetyfish has quit [Ping timeout: 480 seconds]
ChaosPrincess has quit [Quit: ChaosPrincess]
ChaosPrincess has joined #asahi-alt
<leio> chadmed: am I missing something about libclc dep in mesa not being keyworded?
<chadmed> janneg: whats up with this actually
<sam_> would recommend using the pkgcheck GH action in your overlay if not already
<sam_> ::haskell has a more comprehensive setup too
<leio> I mean, I can get it keyworded, but I'm confused
<leio> and portage was utterly confused too after I did something partially and it decided to just go with the earlier version instead
<janneg> I forgot to file a keyword request. libclc is a build dependency for asahi since OpenGL 3.3
<leio> on that note, lets get your package.accept_keywords empty overall if you've got something else there?
<janneg> another minor issue is that llvm is only a build dependency for asahi but for simplicity I've just used the llvm use flag
<leio> stuff like https://github.com/chadmed/asahi-overlay/commit/f753dc54958acfbcf6 should have a revbump for users to actually get it
<ChaosPrincess> leio: i believe that https://packages.gentoo.org/packages/dev-util/spirv-llvm-translator needs to be keyworded too for mesa
<sam_> just shout at me if you need me
* sam_ heading off
<leio> sam_: ffmpeg! :P
<sam_> BYE
<leio> ChaosPrincess: yes
<leio> ChaosPrincess: and tiny-dfr should be in main tree by now! :)
<ChaosPrincess> sure, why not, i can make a pr
<j`ey> what about speakersafetyd etc
<j`ey> and the other asahi-audio stuff
<leio> can I test it on J475? :)
<leio> not that I could test tiny-dfr
<sam_> my amd64 mac will im sure soon be reaching the end of its macos life so i will be able to soon (TM)
<leio> but I mean all of it except mesa, but might need some more buy-in from chadmed instead of just taking things and dumping them in ;)
<leio> tiny-dfr works on very few laptops that actually have a touchbar, which are some old ones, iirc
<j`ey> what're the requirements to be included in the main tree?
<chadmed> tiny-dfr _only_ works on the apple silicon macs with touchbar
<chadmed> j`ey: theyre not that high, its the ongoing maintenance that is annoying that i dont want to deal with
<ChaosPrincess> t2 people made it work on intel, but they never bothered to upstream those particular patches :P
<chadmed> mirrored repos etc
<chadmed> the overlay is nice because as we've seen over the past couple of days with audio if shit hits the fan we can just push out fixes immediately and theres no mirroring, propagation, signing, QA etc required
<chadmed> ive always said once things settle down i will take the time to get them into ::gentoo
<chadmed> but i dont think that time is here just yet
<j`ey> at least the number of packages is pretty small in the overlay
<j`ey> and there will have to be an overlay for a long while anyway
<chadmed> also stupid bullshit like that lsp-plugins patch
<chadmed> i can fix that kinda stuff in a matter of minutes instead of hours
<chadmed> 17 packages and that includes virtual/linux-sources. its really not that bad
<j`ey> until markan starts finding more bugs :P
<chadmed> i think we're done for audio at the very least thank goodness
<leio> for https://github.com/chadmed/asahi-overlay/commit/46524253b73b3de9 I would put a !<lsp-plugins blocker
<sven> <chadmed> i think we're done for audio at the very least thank goodness <-- famous last words :D
<chadmed> "done" meaning "no more major stupid bugs"
<chadmed> i 100% expect we will be cutting a 1.6 at some point
<chadmed> leio: i think that belongs on asahi-audio and not the kernel. the kernel has no specific dep on lsp-pugins, its our DSP that does
<leio> it's a blocker, not a dep; to ensure no-one builds the kernel with the broken lsp-plugins
<sven> <ChaosPrincess> t2 people made it work on intel, but they never bothered to upstream those particular patches :P <-- unfortunately that's true for most of their patches :(
<j`ey> and ours >_>
<leio> but if you've got a >= somewhere on the fixed revision and expect everyone to have the package that has that, ok
<leio> brb, hopefully with some sweet OpenGL
<sven> j`ey: fair enough
<chadmed> we upstream most (all?) of our userspace patches
<j`ey> sven: I think markan said he wants to try upstream more stuff after the fedora release
<j`ey> I mean, it's totally fair enough, for the kernel to do it all downstream for a while. Im not complaining, just messing around :D
<sven> i've also been saying that i'll upstream more stuff once the usb mess is finally sorted out but alas :(
<j`ey> chadmed: yeah, fixing bugs and stuff, for sure
<j`ey> sven: hey, you got the thunderbolt dart upstream!
<sven> true, atcphy also won't be issue once it's stable since that touches nothing in the core
<sven> we'll see about tipd and the actual thunderbolt changes
<chadmed> did we actually need tbt core changes?
<sven> oh yes
<chadmed> just that NHI clusterfuck or is it even worse
<sven> it's worse
<sven> i'll also need a out-of-band notification to at least pcie
<chadmed> oh dear :D
<sven> possibly to the display port tunnel thing as well
<sven> and maybe also dwc3
<leio> still the gnome-shell race condition needing a manual gdm restart, and apparently also a huge cursor problem at places, making me ask what that https://github.com/chadmed/asahi-overlay/commit/f753dc54958acfbcf6 was about
<sven> it also looks like i'll have to re-implement pcie hotplug because ofc the normal pcie hotplug won't work correctly
<j`ey> leio: I think that was something liina found on stream
<leio> but otherwise https://i.imgur.com/9xRLwgX.png
<j`ey> leio: 189 GiB :o
<leio> I'm guessing we don't have a cursor hardware plane yet then
<j`ey> nope
<chadmed> leio: we have one it just doesnt support cursors of the size kwin/mutter ask it to draw so it takes out dcp/dcpext
<leio> e.g. in firefox at 300% HiDPI scale it's like it scales it up 3x and then up again another 3x; the cursor
<chadmed> so you need to force sw cursors until we find a not-disgusting way to make that work
<janneg> leio: no HW cursors with DCP. SW cursors are less tested and where buggy in Plasma but outright broken with kwin_wayland and multiple displays
<leio> looks like a problem with 300% scale; with 200% it looks correct
<chadmed> i want to have another go at getting overlay planes working properly over the christmas break. i got vlc in weston to render its video out to one of them but it was pretty broken and i didnt get further
<leio> janneg: if you've got any package.accept_keywords stuff for stuff you use, just throw it in a pastebin or something and I'll take care of it; least I can do after HDMI here :) even if you don't really mind, but stuff that some people use can just get keyworded; we should reach and go above amd64 coverage!
<leio> or anyone else really
utsweetyfish has joined #asahi-alt
<ChaosPrincess> if you are taking random requests for keywords, can i also get fonts-meta keyworded?
<j`ey> what does keyworded mean here, maybe unstable? or made stable?
<ChaosPrincess> unstable
<leio> stable tree I must leave to the arch teams via bugs; I don't do stable anywhere :)
<leio> so yes, talking of missing ~arm64 stuff
<leio> janneg: I don't think llvm can be build-time only in mesa, apple_dri.so links to libLLVM-17.so
<leio> here we go with the monitor flicker again, sigh
<leio> after getting AGX, I still don't have night light support. Missing GAMMA_LUT or whatever stuff? (yes, I know that's not the correct way to do that stuff, but it's what we have for now)
<j`ey> leio: eys GNOME doesnt support CTM
<j`ey> *yes
<j`ey> (kwin does)
<leio> don't know what that is
<leio> I hope they figure out a better way together with HDR work, but is that a yes on "GAMMA_LUT or whatever support missing in AGX and that's why"? :)
<j`ey> Current Transformation Matrix or something
<j`ey> (I keep thinking COlour Temperature matrix but I think thats wrong)
<chadmed> colour transform matrix
<leio> pushed libclc, looking at fonts-meta
<chadmed> leio: agx has nothing to do with it, its a dcp thing
<chadmed> and yes gamma_lut is missing and likely will be forever
<leio> that'd be a huge bunch of individual fonts keywordings or USE flag masking, going to the backlog for a bit
<j`ey> I keep putting off looking at CTM for wlroots
<leio> I did 17 for libclc and co; do we need 16?
<chadmed> the kwin implementation looks pretty nice but c++ makes my head spin so i didnt really study it further than "yeah that sure is a matrix with colour coefficients" so :p
<leio> lack of night light is a big issue to me, could you guide me in making something for GNOME? :)
<leio> and no, I would rather kill my eyes at night than use kwin/plasma
<janneg> :17 is fine as well. I did :16 because I had llvm-16 installed when I did the change
<ChaosPrincess> leio: https://pastebin.com/WK2syCzb those are the relevant ones
<j`ey> I can link you to the kwin impl, and then you can try find where mutter does the gamma_lut stuff and see if you can figure out how
<leio> ChaosPrincess: it's a few more :) NonsolvableDepsInStable: version 3: nonsolvable depset(rdepend) keyword(~arm64) stable profile (default/linux/arm64/17.0) (12 total): solutions: [ media-fonts/courier-prime, media-fonts/crosextrafonts-caladea, media-fonts/crosextrafonts-carlito, media-fonts/ipaex, media-fonts/khmer, media-fonts/mikachan-font-otf, media-fonts/mikachan-font-ttf, media-fonts/monafont, media-fonts/nanum, media-fonts/oldstandard, media-fonts/
<leio> opendesktop-fonts, media-fonts/paratype, media-fonts/paratype-astra, media-fonts/powerline-symbols, media-fonts/quivira, media-fonts/shinonome, media-fonts/signika, media-fonts/tibetan-machine-font, media-fonts/unfonts ]
<janneg> leio: if you build with swrat and/or opencl there is a runtime dependency. Drivers are linked all together apple_dri.so is a lie^Whardlink
<leio> janneg: ack
<leio> j`ey: sure, though I might give up fast too :)
<leio> done too much rust, might not feel like C++ to C conversion; hope the licenses are compatible
<leio> that looks like an awfully small commit
<j`ey> leio: at least you could make a bug for GNOME
eiln has joined #asahi-alt
<leio> given the existing bugs with existing implementation, it really needs to come with a MR :)
<leio> monitor hotplugs just lose GAMMA_LUT setting for a connector until restart very often, etc
possiblemeatball has joined #asahi-alt
<yuka> Is there any way to upgrade to 13.5 firmware to get the HDMI output?
<yuka> I'm on OS Firmware 12.3 according to asahi-diagnose
<eiln> yuka: the installer doesn't support updates yet but marcan might be cooking something up
<ChaosPrincess> install uefi-only, then use that to boot?
<yuka> ChaosPrincess: which menu point in the installer would I choose? I already have an installation, it only offers me to upgrade m1n1
<ChaosPrincess> resize disk, then install into free space
possiblemeatball has quit [Quit: Quit]
<yuka> btw who else will be at 37c3? shall we do an asahi meetup? :)
<leio> janneg: pygit2 used for tortoisehg or something out of tree?
<leio> and what for is intelhex
<leio> ah, intelhex provides binary tools too, good enough
<janneg> leio: I don't remember, discard pygit2 I don't even have it installed anymore
<leio> ok, all done in that case
<janneg> same for intelhex
possiblemeatball has joined #asahi-alt
qyliss has quit [Quit: bye]
eiln has quit [Quit: WeeChat 4.1.2]
qyliss has joined #asahi-alt
john-cabaj has joined #asahi-alt
ciara has quit [Remote host closed the connection]
ciara has joined #asahi-alt
<MichaelLong> I've just updated my gentoo installation after a longer time and along with it, also installed linux-6.6.0-p12, but unfortunately HDMI output is not working, Is this expected?
john-cabaj has quit [Ping timeout: 480 seconds]
<liv> j`ey: If I use `dracut` with `--hostmodules`, does it also include everything it includes without the `--hostmodules` option?
<leio> MichaelLong: did you get a m1n1 update and put it into use (I think update-m1n1?)? Is it a real full HDMI port? What is the macOS firmware version on that install, I hear asahi-diagnose is supposed to tell that
<MichaelLong> leio, thx for the hints, I'll check those. I was testing with the real HDMI port. It is working with the Fedora Asahi install though
<MichaelLong> ok ran update-m1n1 but rebooted but it didn't changed anything. asahi-diagnose says OS firmware: 12.3
<MichaelLong> ok running asahi-diagnose on my parallel fedora installations OS Firmware is on 13.5, that's probably the culprit
<janneg> MichaelLong: yes, the HDMI output is only supported with OS firmware 13.5
<MichaelLong> janneg, k good to know, I'll check what's going wrong with the update on my gentoo install.
<janneg> that has nothing in particular with your gentoo installation to do. the OS firmware version is determined by the macOS version on the 2.5GB apfs partition created by the asahi installer. It's currently not possible to update that directly
jacksonchen666 is now known as Guest10764
jacksonchen666 has joined #asahi-alt
Guest10764 has quit [Remote host closed the connection]
jacksonchen666 has quit [Quit: WeeChat 4.1.2]
jeisom has joined #asahi-alt
ciara has quit [Remote host closed the connection]
<j`ey> liv: Im not exactly sure what it does, just saw that thing with modprobe
ciara has joined #asahi-alt
hd73 has joined #asahi-alt
hd73 has quit []
<liv> Ah okay.
<liv> Thanks :)
<j`ey> liv: seems that it tries to create a smaller initramfs that works only on your machine
<j`ey> you could test by moving the current initramfs out the way and seeing if it works for you
<j`ey> or try the alternative modprobe.d paths
<tpw_rules> janneg: does the OS firmware matter? or just a firmware binary that needs to be extracted
<tpw_rules> it seems an awful lot like the first, would just like to confirm
<sven> DCP needs to run firmware 13.5
<tpw_rules> okay, so the problem is the macos partition for sure
* mps would like to see color temperature work on asahi
<sven> yes
<j`ey> mps: the apple drm driver supports CTM
<mps> j`ey: hm, how?
<j`ey> KDE supports it, but not much else yet
<mps> ah, that explains why it doesn't work in my case
<j`ey> presumably redshift or whatever uses the GAMMA_LUT property, that the dcp doesnt support
<mps> not sure if KDE on alpine will work
<j`ey> (and GNOME uses gamma, not CTM, so doesnt work there yet either)
<mps> and I'm not fan of these big DEs
<mps> though I'm testing sway to switch from xorg
<j`ey> sway (through wlroots) doesnt support it either yet :(
<mps> actually switched to sway on gru-kevin chromebook. it is lot better than with xorg
<j`ey> mps: switching to Modern Software :P
<mps> and I have sway in parallel with xorg macbooks
<mps> j`ey: yes :D
<mps> even installed pipewire
<mps> I managed to resist pulseadio
<mps> oh, forgot to announce that alpine now have speakersafetyd. Waiting for someone with knowledge about pipewire to test and teach me how to use all these 'batteries'
<mps> I managed to add all these thing to alpine and keep them up-to-date, except asahi-audio which I don't know to make properly
<mps> j`ey: OT but, when I studied about systems (any type) I learned that stability and security is inverse proportional to the number of elements (i.e. moving parts)
<mps> more 'moving parts' less stability and less security
<mps> or as Leonardo da Vinci told 'perfection is not when you don't have to add anything more but when you don't have to remove anything more' or similar to this. writing from the had and translating from my bad english
<j`ey> theres some truth to that of course, but if more maintenance/work is happening in the complex systems..
<mps> I like KISS (keep it simple stupid)
<j`ey> (I do somewhat agree.. but I've also come round to systemds way of doing things soo)
<mps> yes, I understand that nowadays all things needs more functionalities and as such they are becoming more complex
<mps> maybe I'm told earlier that I advocated switch to systemd on debian and after some time I saw that was a big mistake (shame on me)
<liv> j`ey: alternate modprobe.d paths didn't work :(
<j`ey> liv: hm
<j`ey> liv: run: cpio t < /boot/<path to initramfs> | grep modprobe
<liv> I might have found the solution, rebooting now...
<liv> okay I found the solution...
<liv> I did not mount /boot.
<liv> I feel so dumb right now...
<liv> anyhow I found the solution, ctrl/fn and alt/super have been swapped
<j`ey> didnt mount it when? also why not just alwways mount it
<j`ey> what was the solution?
<liv> Mounting /boot...
<j`ey> oh, before running dracut?
<liv> yeah...
<j`ey> ah
<liv> it didn't occur to me that it outputted to /boot/initramfs-*.img
<liv> The notch display still doesn't work, however.
<j`ey> depends what you mean
<j`ey> the display is intentionally cut to below the notch
<j`ey> (since userspace doesnt know about it)
<j`ey> if you boot with: apple_dcp.show_notch=1 it will use the full screen
<liv> Yeah I'd like to allow it to display "through" the notch
<liv> yeah
<liv> Since I have my bar there anyways
<j`ey> but full screen wont "work"
<liv> it looks something like this: https://0x0.st/HYpv.png
<liv> what does that mean?
<liv> about full screen?
<j`ey> if you full screen, stuff will get hidden behind the notch
<liv> ah okay
<liv> yeah that's obvious
<j`ey> then use the kernel option :)
<liv> :)
<liv> Oh, btw, I already had `options apple_dcp show_notch=1` inside `/lib/modprobe.d/apple-dcp.conf`
<liv> did not work
<liv> Also in `/etc/modprobe.d/apple-dcp.conf`