<tpw_rules>
so i did. it's not on the twitter yet in fairness
<tpw_rules>
hearty congratulations though. i will have to try it soon
<tpw_rules>
the edge kernel will work independently of the edge mesa right?
<axboe>
marcan: dumb question, since that post is specifically for that distro - what else do I need outside of the kernel bits? if I missed another post, feel free to point me at it...
<tpw_rules>
mesa?
<axboe>
that's it?
<axboe>
asahi/mesa.git
<chadmed>
yep just the kernel and the main branch from asahi/mesa
<chadmed>
dont forget to update m1n1 with the DTs from the kernel you build
<axboe>
that I already did
<chadmed>
oh and you need the latest m1n1
<axboe>
that too
<tpw_rules>
does dcp actually need the gpu involed?
<tpw_rules>
or did they just sort of get released at the same time?
<chadmed>
no dcp has been working for several weeks
<axboe>
that I'm already running
<axboe>
hmm might be tough to retrofit mesa without recompiling the world here, I think I'll give it a spin on the m1 pro with an asahi install
<chadmed>
what distro are you using? its possible meson has set up mesa with an incorrect libdir and dri-drivers-path
<chadmed>
i had to manually set them to /usr/lib64 and /usr/lib64/dri respectively with gentoo (though the ebuild now takes care of that automatically for users)
<axboe>
I'm on debian
<axboe>
looks like it ships 22.4
<tpw_rules>
dumb mesa question: does the version linked into apps need to be the same as the version driving the GPU?
<chadmed>
the default libdir for a straight meson setup with no options is /usr/local/lib64 so if thats wrong for debian you need to make a new build dir with the correct meson options and reinstall the mesa branch
<axboe>
chadmed: sure, I'm more worried about 22.4 vs 23.0-devel
<chadmed>
i updated mesa on gentoo without rebuilding the world and it worked fine
<axboe>
chadmed: what version was it running prior?
<chadmed>
22.3
<axboe>
sweet
<tpw_rules>
the blog post mentions there might be "UAPI" breakage but i'm not sure where exactly that split is
<chadmed>
the UAPI split was before public release so unless you were testing some old picked branch of lina's you shouldnt have uapi issues with the release kernel and asahi/mesa
<tpw_rules>
so uapi connects the kernel and userspace
<chadmed>
yeah, they will be kept in sync for public releases now so even if there are changes required to make it upstreamable you shouldnt notice them
<chadmed>
mesa handles all that internally and apps shouldnt care about it
<tpw_rules>
i guess there are not a huge number of apps that directly depend on mesa
<axboe>
building
jamespmorgan has joined #asahi
<axboe>
63s
<axboe>
these laptops never cease to amaze
<chadmed>
ikr its nuts
<chadmed>
i had half a mind to set up distcc back to my build server to "save battery" but the 10 core m1 pro compiles almost everything faster than my overclocked server while using less energy so whats the point
<axboe>
I've got faster build boxes, but you need a big build to warrant moving off the laptop now
<chadmed>
what options did you feed to meson for configuring?
<axboe>
--prefix=/usr
<axboe>
but looks like I may have some conflicting libs here
jamespmo_ has quit [Ping timeout: 480 seconds]
<axboe>
I'll give it a go on the test laptop tomorrow
unicordion has joined #asahi
<marcan>
tpw_rules: lol, I forgot I had the crossposter disabled...
<marcan>
< tpw_rules> dumb mesa question: does the version linked into apps need to be the same as the version driving the GPU? <- mesa isn't linked into apps
<marcan>
it's an OpenGL implementation and OpenGL has a very well defined ABI, that's why you can replace it with nvidia's blob
<marcan>
axboe: ^
<tpw_rules>
https://packages.debian.org/sid/libgbm-dev this is why it's claimed to be a dependency of several packages in nix. but yeah i looked and mostly it's used through opengl's abi
<marcan>
also you need CONFIG_DRM_APPLE and CONFIG_DRM_ASAHI
<tpw_rules>
and it might even be there just for headers
marvin24 has joined #asahi
marvin24_ has quit [Ping timeout: 480 seconds]
unicordion has quit [Remote host closed the connection]
unicordion has joined #asahi
<tpw_rules>
marcan: is that modeset config necessary for dcp and gpu, or just gpu?
<marcan>
dcp and gpu because xorg gets confused by the two drm devices
<marcan>
really just dcp, it's just that it works by accident without it if you don't have the gpu driver
* tpw_rules
ok, thank you
* tpw_rules
learned today that command+enter does /me
<marcan>
the way it works is apps are supposed to open the DCP DRM device
<marcan>
mesa does the render offload to the GPU behind the scenes (kmsro)
unicordion has quit [Quit: unicordion]
osaka1990 has quit [Read error: Connection reset by peer]
WindowPain_ has joined #asahi
WindowPain has quit [Ping timeout: 480 seconds]
tinstew has joined #asahi
joske has joined #asahi
<joske>
chadmed: maybe update your PR for audio PM pretty please? :-)
SSJ_GZ has joined #asahi
<mps>
axboe: yesterday Glanzman wrote all needed things and steps for getting gpu on debian, on #asahi-alt channel, maybe reading backlog there could help to sort out problem
<kettenis>
marcan: xorg really shouldn't need a config file for this
<kettenis>
but I guess the code that is supposed to select a driver still is a mess for non-PCI graphics
kh has joined #asahi
kh has quit [Remote host closed the connection]
tinstew has quit [Ping timeout: 480 seconds]
LinuxM2 has joined #asahi
SSJ_GZ has quit [Ping timeout: 480 seconds]
SSJ_GZ has joined #asahi
<marcan>
kettenis: yeah, don't look at me... as far as I can tell this is the "intended" way to do it.
<marcan>
it really should just autodetect it by looking for devices with actual outputs first (it actually already does that for secondaries), but I dunno
<marcan>
it's Xorg and ~nobody is working on Xorg
<marcan>
I'm slowly resolving to stop taking bug reports related to Xorg environments because a lot of it is upstream issues and nobody is working on it
<marcan>
e.g. anything related to DPI scaling
<marcan>
I'll probably pull off some hack to force switch everyone on Xorg by default to Wayland (as far as SDDM settings) when we actually push the GPU driver to production or something. they can change it back if they want, but it's just never going to work properly in all aspects.
<marcan>
(everyone=people on the desktop distro)
SSJ_GZ has quit [Ping timeout: 480 seconds]
<as400>
chadmed: when using "ondemand" governor I was able to go to 5.31W on my mbp 14. Yes, I know it's not optimal. Still looks like using this governor it's using less power.
<marcan>
as400: that means you have processes waking up the CPU.
<marcan>
ondemand is just slower and therefore less likely to put the CPU into higher power states
pip[m]1 has joined #asahi
<marcan>
you need to fix the wakeups, not change the governor.
pip[m]1 has left #asahi [#asahi]
<marcan>
chadmed: I've seen my MBP14 get into a weird state when I boot it up with the lid closed, which I think causes SDDM to suspend
<marcan>
it ends up warm and then I can't wake it up
<marcan>
I'm pretty sure there's something that ends up in an infinite loop or IRQ storm or something
<marcan>
I need to look into that
<as400>
marcan: you might be right. I'm doing it out curiosity. And one thing I noticed is that ondemand puts CPUs in lower states much more often than schedutil.
joske has quit [Quit: Leaving]
<marcan>
yes, because schedutil actually takes into account short latencies and is intended for modern SoCs
<marcan>
while ondemand dates back to the beginnings of cpufreq on Pentium III systems and is designed for CPUs which have horrible switching latencies
<marcan>
on schedutil, just doing "cat" on the relevant sysfs files is likely to put the CPU running "cat" into the max perf state or close
<marcan>
that never happens with ondemand (assuming you're sleeping between cats)
<marcan>
schedutil is likely to actually save power on modern systems (moreso when we implement deep sleep), google "race-to-idle"
<marcan>
and it's also a requirement to have good desktop responsiveness, otherwise you end up stuttering every time something starts happening until ondemand catches up
<as400>
marcan: you mean deep-idle ?
<marcan>
yeah, sorry, deep idle
<as400>
I was looking for information about it but couldn't find anything useful tbh
guillaume_g has joined #asahi
<mps>
marcan: I'm strongly against idea to force users to wayland. distro users doesn't like to be forced to anything and of you make these changes users will start to fill bug reports on distros
<mps>
s/and of/and if/
<as400>
mps: but xorg is just obsolete and nobody is working on it...
<mps>
as400: that not true. some people works on xorg and make updates from time to time
<marcan>
mps: I don't care :)
<marcan>
our packages and package update scripts cater to the average user. the average user wants to be on wayland after the GPU driver lands.
<marcan>
non-average users are free to switch the default back to X11
<marcan>
if you don't like it, uninstall asahi-desktop-meta or go with the minimal image
<mps>
marcan: I don't ask to fix bugs or add features, just ask to not make intentionally hard to use it
<marcan>
asahi-desktop-meta means "we will make this as painless as possible assuming you're happy with our intended desktop experience"
<marcan>
changing a default is not making it "intentionally hard to use"
<waldi>
and given that there is a translation layer from X to wayland, you can use both anyway
<marcan>
I should probably remind everyone: "asahi-meta" means "I want my machine to work". "asahi-desktop-meta" means "I trust marcan & co to make my desktop experience be good by default"
<marcan>
you are free to uninstall asahi-desktop-meta, but then don't complain if updates mean you have to go tweak settings to make things work the way you want again, or to improve things, because that will happen sometimes
<marcan>
if you uninstall asahi-meta, we will not take bug reports from you
<mps>
waldi: yes, and I switch between xorg and sway from time to time, so for me personally it is not big issue, but I'm having distro users in my 'advocate' mind
<ar>
wayland is still not ready, as libinput maintainers refuse to implement basic functionality that was available for touchpads and trackpoints (ok, that's not a concern on macs…), and wayland compositors still have annoying bugs with, for example, menu "subwindow" placement
<marcan>
ar: wayland is at the point where its bugs and annoyances are about on par with the xorg bug and annoyances
<marcan>
and once the GPU driver lands there are significant problems with xorg which will not go away any time soon (e.g. no vsync)
<marcan>
therefore wayland becomes the better option
<marcan>
again, people are free to pick their poison
<marcan>
but we *will* be switching to wayland by default
<marcan>
and other distros have done that ages ago already
<marcan>
even with the TearFree patches you get no vsync on apple machines
<mps>
marcan: ah, ok, now I understand, you will not intentionally criple xorg usage. sorry for noise
<marcan>
and that is unlikely to ever be supported because it doesn't look like the hardware does at all
<marcan>
mps: dude I'm literally just talking of changing the default to wayland, I already said that, I'm not sure what you understood
<marcan>
I even shipped an xorg conf with the alpha GPU driver stuff to make xorg actually work (it doesn't work by default because its device selection algorithm is broken by default, see what kettenis said)
<mps>
marcan: I missread and missunderstood you comment above
<marcan>
even though the blogpost told people to use wayland
<marcan>
by "force switch" I mean I will edit their SDDM config to switch to wayland, because all existing users on xorg should be switched to wayland, because there is no way to determine intent ("xorg by default" vs "xorg on purpose") and the majority will be of the former category
<marcan>
that is a one-time action on package upgrade
<marcan>
if you don't like it, choose xorg again on the login screen
<marcan>
the only way it will get reset again is if you start playing really weird games with pacman package versions, it won't happen by accident
<mps>
yes, yes, now I don't see any issue
<marcan>
FWIW, when Asahi first shipped the alpha I chose Xorg because I think it was faster than Wayland without a GPU driver, and because KWin/Xwayland fractional scaling still wasn't working which made Firefox end up blurry, and I didn't have time to chase down these things since the actual "desktop experience" part of everything was quite rushed
<marcan>
those concerns no longer apply; the Xwayland on KWin stuff got fixed and Wayland is a significantly smoother experience than Xorg with drivers
SSJ_GZ has joined #asahi
<marcan>
*personally* I still have a partial Xorg blocker (inputleap/barrierd support) but that's me, and it looks like progress is being made there plus there's at least a Wayland version of the client anyway
<kujeger>
it'll be interesting when the fractional scaling stuff for wayland lands in released versions of the various compositors, right now non-integer scaling is still kind of blurry in e.g. sway
<marcan>
kujeger: it works well in kwin except for some glitching in weird cases. I hope the bikeshedding about how to do the rounding "perfectly" I hear happened trickles down into that and fixes it
<marcan>
though FWIW: as far as I know non-KDE desktops mostly implement fractional scaling via output scaling and... guess what, that's how macOS does it too.
<marcan>
true native fractional scaling is hard and Wayland will have a leg up on macOS there if it all gets implemented nicely and works
<kujeger>
iirc the wayland protocol got merged a few days ago, and code using it already exists in unreleased form
<marcan>
(because the disadvantage of output scaling is you burn more GPU power by pushing more pixels)
<marcan>
kujeger: I think KDE has been doing its own thing for a while now
<marcan>
Qt has natively supported fractional scaling for ages
<marcan>
but fractional scaling creates piles of corner cases for interactions, and as far as I know that's why that protocol took so long to work out
<kujeger>
following the PR has been a rollercoaster for sure
<kujeger>
but I hope it results in a really good experience across DEs
<marcan>
yeah, I'm looking forward to the state of things mid-2023 or so, looks like ~everything is coming together nicely on the desktop side
<_jannau_>
I would expect Xorg with tearfree to be less broken with dcp. It should receive fake vblank irq on framebuffer swaps
<marcan>
_jannau_: there is no vblank IRQ support so there is no vblank ioctl support so clients just freewheel even when they think they are vsynced
MajorBiscuit has joined #asahi
<marcan>
lina removed the fake IRQ thing because it was broken, right?
<marcan>
TearFree doesn't change the way xorg implements client vsync (which is apparently based on explicit vblank queries which don't work)
<kujeger>
marcan: with pipewire, the current/soon-ish state of wayland etc it sure looks like 2023 will be a good time for a modern linux desktop, year of the linux desktop jokes aside
<marcan>
they'd have to implement the vblank emulation in xorg proper for this to work somewhat better
<kujeger>
I've been using wayland/xwayland exclusively for years and it's been just steadily getting better and better
<ChaosPrincess>
how does stuff to know when to flip buffers when there is no vblank interrupt?
<marcan>
the hardware flips buffers
<marcan>
that's how it works on every modern display controller
<ChaosPrincess>
what about stuff like VRR and such?
<mps>
I built xorg with tearfree patch and enabling it 'Option "TearFree" "on"' then xorg even doesn't start
<marcan>
presumably you just queue a flip and the hardware issues it at the earliest possible time, quantized to whatever it can do or whatever
<marcan>
software buffer flipping has been broken for ~20 years
<marcan>
(because you cannot guarantee latencies any more so you cannot guarantee the actual flip happens during vblank)
<marcan>
so every display controller implementation switched to hardware double-buffering of the registers with automatic flips
<marcan>
but as we know Xorg is stuck 20-30 years in the past :)
<marcan>
macOS switched to this model ages ago (Wayland is basically doing what macOS does)
<marcan>
and DCP is strictly built with this model in mind, hence it works well for macOS and Wayland, not so much Xorg
<_jannau_>
she removed the drm_vblank initilisation, dcp still emits vblank events after page swap. I'm not sure if those are still registered as vblank irqs
<marcan>
_jannau_: that function is misnamed, it's not a vblank event, what it really is is a swap complete event
<marcan>
there is no vblank emulation/IRQs without the actual vblank stuff
<marcan>
xorg gets errors on the relevant ioctls and so never waits
<marcan>
so without TearFree you get tearing in glxgears at a bajillion FPS. with TearFree you get a smooth glxgears, still at a bajillion FPS behind the scenes
<marcan>
because Xorg apparently doesn't tie compositor page flips to the actual app swap interval, it instead relies on vblank IRQs to throttle clients and those don't work
<marcan>
same reason some KDE animations are way too fast on xorg (as they've always been on Asahi, since simpledrmfb also doesn't have vblank IRQs of course)
<marcan>
but are the right speed in Wayland
<marcan>
I think in principle you could emulate the vblank stuff by queuing dummy page flips and waiting on those, but it sounds like a recipe for corner cases and pain and higher power usage
<marcan>
I don't think we want to go there
<marcan>
incidentally, I looked at the relevant Xorg code and it's also broken :)
<marcan>
it tries to use a newer API and fall back to an older one, but the logic for that is busted so it always uses the newer one
<_jannau_>
yes, I thought about that but I fear that it leads to a ton of bugs for clients doing swaps
<marcan>
not that it matters since neither work for us
<marcan>
but so much is broken about xorg, really...
<marcan>
it's clear ~nobody cares any more
<_jannau_>
i.e. the workaround will hurt the well behaved clients
<_jannau_>
the modeset driver's atomic modeset implementation was/is apparently that broken that it was forcefully disabled on kernel side
<sven>
lovely :D
<sven>
imho that getting into the kernel is a strong argument for just how broken xorg is
<ar>
so, what one should say about bugs in wayland compositors that have been reported 4+ years ago, that are prevalent across gnome, plasma, and sway? ;)
<ar>
(like the menus placement i mentioned)
leitao has joined #asahi
leitao has quit []
kh has joined #asahi
<kh>
My task bar becomes huge on asahi-linux-edge on wayland KDE, does anyone know how to fix this? https://ibb.co/C7Zmy2J
<kh>
linux-asahi-edge*
LinuxM1 has joined #asahi
leitao has joined #asahi
kh has quit [Ping timeout: 480 seconds]
LinuxM1 has quit [Quit: Leaving]
LinuxM2 has quit [Quit: Leaving]
tinstew has joined #asahi
<chadmed>
as400: thats a decent temp fix i guess but wont be suitable once we have EAS worked out properly since it ignores that, and will end up using more power
<chadmed>
marcan: im actually not using sddm at the moment but the behaviour is similar. the machine ends up hotter and pulling more juice in suspend than just locking the session and turning the screen off. i can resume successfully at will though
abby has quit [Remote host closed the connection]
abby has joined #asahi
<chadmed>
joske: im preparing a new branch with p ovik's suggestions so just ignore that PR for now
kh has joined #asahi
<kh>
I forgot to mention the model, it's j293
<chadmed>
right click it, click enter edit mode and then change the panel height
<kh>
Thanks that worked
<kh>
Everything else still looks huge though (e.g. calendar)
<chadmed>
your scaling settings are probably wrong then
<chadmed>
change them in system settings->display
<kh>
Nah, the scaling is the same yet everything looks so much bigger compared to X
<kh>
Maybe it's a KDE thing
<kh>
'
<kh>
chadmed: Sorry by everything I meant stuff on the taskbar
<kh>
Apps like Firefox scale fine
abby has quit [Remote host closed the connection]
abby has joined #asahi
tinstew has quit [Read error: Connection reset by peer]
kh has quit [Remote host closed the connection]
veloek has quit [Ping timeout: 480 seconds]
gladiac has joined #asahi
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
joske has joined #asahi
<joske>
chadmed: yes, I tried to manually apply the changes to latest asahi branch, but it didn't work. I'll wait until you have a new version
<chadmed>
ill sort it all out tomorrow (GMT+10). the PR is redundant, you can just pick the commits from the branch once i push it
<as400>
chadmed: don't know about schedutil but with ondemand when screen is off it takes 3.19W. Have to try with schedutil. For the future schedutil is probably the only way.
<as400>
And the same with s2idle here. It gets hotter and takes more juice than with screen off.
tinstew has joined #asahi
<joske>
chadmed: no worries, take your time
<as400>
About the battery - is it possible that charge controller in m1 macs has two "modes" ? Like "high current" and "high voltage" ? That was the case with my Lenovo Ideapad. And when I was using the default, which was "high voltage" the battery health was deteriorating very fast.
piroko9 has joined #asahi
<ChaosPrincess>
trying out the new gpu driver: why is the cursor and the task bar so huge?
<piroko9>
good morning. does this room have the matrix.org bridge banned? I tried to join this room yesterday from my matrix account (nick piroko) but was met with a ban error
<as400>
ChaosPrincess: change panel settings and scaling in Plasma settings
joske has quit [Quit: Leaving]
<as400>
piroko9: yes, matrix bridge is banned
<piroko9>
alright. good to know at least. thanks :)
<as400>
irc only now
<piroko9>
anyway I came here to say yesterday, I've been dabbling with asahi linux on my various macs since the day it was announced, and I was blown away by the latest state of the project
<piroko9>
in one update came brightness control, headphone jack support *and* GPU acceleration
<ChaosPrincess>
ok, i found how to shrink the cursor, but the task bar is still big
<ChaosPrincess>
and yes, i have scaling set to 150
<piroko9>
this team is incredible and I just wanted to say thank you for your insanely awesome work
<as400>
ChaosPrincess: right click on panel, enter edit mode, change height
<ChaosPrincess>
ty
<as400>
yw\
leitao has joined #asahi
leitao has quit []
tinstew has quit [Remote host closed the connection]
<marcan>
kh: Check your DPI settings as the post mentioned. DPI forcing should be disabled.
<marcan>
both that and the scaling settings are stored independently for wayland and X
<marcan>
piroko9: thanks :)
<marcan>
ChaosPrincess: I saw the cursor thing on some machines. not sure what causes it, but it smells like a KDE bug.
<ChaosPrincess>
its even weirder
leitao has joined #asahi
kh has joined #asahi
<kh>
marcan: It's disabled
<ChaosPrincess>
i set cursor to 24 px, it applied and was that way for a bit, but now its back to being huge except when i hover over the top bar of the window, and there it goes back to small
<kh>
I'm assuming ChaosPrincess has the same issue as me as well\
<ChaosPrincess>
smells very much like userspace bug
<marcan>
ChaosPrincess: log out and back in
<marcan>
but yes
<ChaosPrincess>
logging out and back in did not help
<marcan>
kh: toggle both that and the DPI scale around and log out and back in
<ChaosPrincess>
in fact, i had to do it for the settings to even apply
<kh>
marcan: I played around with it previously but it didn't really change anything
<marcan>
what machine is this?
<kh>
j293
<kh>
When I dropped the scale task bar did shrink but so did everything else
<marcan>
the taskbar being huge at first is normal, just resize it
<marcan>
not sure if it just resets and saves separately or the coordinates are different to x11
<marcan>
I also noticed konsole tends to open tiny windows at first
<marcan>
the calendar though, looks normal to me, same as on xorg
<marcan>
wait no now it's huge, what lol
<marcan>
oh but it's resizable
<marcan>
just resize it
<marcan>
going back to xorg broke it
<marcan>
tl;dr coordinates are different on x11 and wayland, so anything saved shows up differently on the other or something like that
<kh>
Oh I did not notice that
<kh>
Ty
<marcan>
it seems the default calendar size is the minimum, so xorg never shows up tiny, but then saves its coordinates and the next time you're on wayland it's huge
<jannau>
I think there was a fix konsole opening tiny last week or the week before that
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
beeblebrox has joined #asahi
beeblebrox has quit [Remote host closed the connection]
piroko9 has quit [Remote host closed the connection]
<marcan>
kh: That is expected behavior, yes (because RT code runtime is unpredictable if you're switching frequencies)
<marcan>
that only happens when an RT task is runnable, which hopefully isn't very often unless you're running real time audio apps
UnicornsOnLSD has joined #asahi
UnicornsOnLSD is now known as jmshrv
<jmshrv>
Hi, I've been unable to install Asahi on my laptop - the installer fails to boot into the new recovery and bootloops even though I'm 99% sure I'm following the instructions at the end. Here's a video showing the process: https://youtu.be/q9NPPEX3Z8Q
<jmshrv>
This MacBook is a bit weird since it had to be repaired and jumped straight from 12.0 to 12.6 as the logic board was replaced, but I doubt that's the issue. I was able to install Asahi before the repair, but that was basically a different laptop based on how much was replaced lol
jmshrv_ has joined #asahi
jmshrv has quit [Ping timeout: 480 seconds]
jmshrv_ is now known as jmshrv
veloek has joined #asahi
aaron465 has joined #asahi
gladiac has joined #asahi
<marcan>
jmshrv: that almost looks like 12.3 doesn't like something about your laptop
<marcan>
maybe it has something to do with that Apple bug and repaired machines?
<jmshrv>
Yeah that sounds exactly like what's happening
<jmshrv>
What a fun edge case
<jmshrv>
My gut instinct was that it wasn't happy with 12.3 because it never ran it or something, but that would be pretty stupid
<marcan>
I wonder if 12.3.1 fixed it. that had an iBoot update.
<aaron465>
hihi! I've been out of the channel for a while but excited about Asahi again thanks to the GPU driver (big love for that). I am running Gnome (Wayland) and trying to set fractional scaling. In general it is working but the gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']" is not persisting reboot. I am trying to figure out what is different between this and my Arch desktop where I do the same thing with no problems...
<aaron465>
Could that be related to Asahi or should I continue doing general Gnome related searching?
<marcan>
aaron465: unlikely to be specific to Asahi, that sounds like a gnome bug/issue
<marcan>
jmshrv: I can try adding 12.3.1 to the installer, though that will need m1n1 changes before you can use it with the GPU/DCP
<aaron465>
marcan: thanks. Second question is I keep getting WiFi disconnects; are there any differences there (asahi-edge kernel) vs the regular asahi kernel (it seems like a new problem)?
<jmshrv>
marcan: That would be great :)
<marcan>
aaron465: no changes to wifi
<jmshrv>
Could the 12.4 firmware used for M2 work here, or would that be way more effort than adding 12.3.1?
<marcan>
use expert mode, pick 12.3.1 when prompted
<marcan>
you can also try 12.4 and 13.0 in expert mode; the former should work but is unsupported (expect no GPU, might be able to test whether it works, also it's supposed to be an M2 only build) and 13.0 is completely untested but you can try it if nothing else works just to see
<marcan>
if 12.3.1 works and gets you to a desktop let me know and I'll make the m1n1 changes to make the DCP/GPU bleeding edge drivers enabled
<jmshrv>
marcan: It's only listing 12.4 and 12.3 for the OS:
<jmshrv>
Choose the macOS version to use for boot firmware:
<jmshrv>
1: 12.4
<jmshrv>
(If unsure, just press enter)
<jmshrv>
2: 12.3
<jmshrv>
» Version (2): 12.3.1
jacksonchen666 has quit [Ping timeout: 480 seconds]
<marcan>
what installer version does it show at the top?
<jmshrv>
v0.5.1-1-gd69b61c5cc87
<marcan>
I'm confused... is my version comparison logic broken again?
<marcan>
oh wait no
<marcan>
duh, the data list
<marcan>
jmshrv: try again now (might need a 5 minute delay for the GitHub cache to expire)
jacksonchen666 has joined #asahi
ptudor_ has joined #asahi
cylm has joined #asahi
ptudor has quit [Ping timeout: 480 seconds]
dordoka has joined #asahi
dordoka has quit []
Chai-T-Rex has quit [Remote host closed the connection]
<jmshrv>
Oh I was just checking the version of the installer, my bad
<marcan>
oh yeah that didn't change
<jmshrv>
It's showing 12.3.1 now, will let you know if it works :)
<marcan>
I checked and the DCP/AGX firmwares are identical save for build IDs, so if it works for you I'll push the m1n1 update to map the new firmware version and you should be good to go
<Soni>
marcan: can we send you fan art?
<marcan>
fan art... like of my face?
jmshrv has quit [Remote host closed the connection]
<Soni>
uh not really
<Soni>
literal fan art
<marcan>
I dunno how this works lol
<marcan>
I know lina gets fan art but that seems more common with vtubers
piroko9 has joined #asahi
<Soni>
we mean it's literally a fan XD
<marcan>
oh.
<marcan>
I mean
<piroko9>
is it expected that the currently implemented sleep mode on the edge kernel would make my laptop warm if kept in my bag? or is it more likely that my computer woke itself up
<marcan>
:p
<Soni>
may we?
<marcan>
piroko9: depending on model there seem to be sleep issues sometimes
<piroko9>
roger
<marcan>
Soni: I mean yes but I'm still confused
<marcan>
piroko9: what model?
<piroko9>
m1 pro mbp
<marcan>
okay yeah, lots of reports for that one
<piroko9>
cool cool
<aaron465>
same for me actually on sleep. I didn't look into that yet though so didn't mention it. Pressing suspend button seems to work, lid suspend seems like a no (and/or it wakes back up after some time)
bcrumb has joined #asahi
<marcan>
I need to add a current log thing to the battery driver, so we can debug this stuff
<marcan>
and just generally debug suspend, I barely had a chance to look into it beyond the stuff that completely broke it
<marcan>
I know the keyboard/trackpad is a problem
<bcrumb>
hi marcan
jmshrv has joined #asahi
<piroko9>
aaron465: you have to explicitly enable lid suspend in kde settings if you haven't
<piroko9>
it's set to just turn the display off by default
<jmshrv>
marcan: That worked, was able to boot into a TTY. I'm using the minimal install, should be able to set up KDE later today
<marcan>
cool, let me push m1n1 then, thanks for finding this :)
<jmshrv>
np, wasn't expecting it to be such a weird edge case
jmshrv has quit []
<marcan>
I'm going to leave this as expert-only for now since it's such a weird edge case, so we don't proliferate 12.3.1 just in case
<marcan>
but I'll properly tag a build and push it to the production installer so we can tell people who run into it what to do
<ChaosPrincess>
macbook pro opus? :P
<jannau>
fortunately I decided to ignore the patch level version in the dcp fw version check. otherwise it would reject 12.3.1 as firmware version even though it's reported as compatible to 12.3.0
<marcan>
jannau: m1n1 sets compat as 12.3.0
<marcan>
oh wait, you check the firmware version, not the compat version?
<marcan>
you're supposed to check the compat version lol
<jannau>
I check both
<marcan>
the idea is we check compat only unless a new version adds optional but backwards compatible features, in which case we use version to check for that
<marcan>
and for the latter, the check ideally needs to be done with an actual vercmp style greater-than check, not a hard match
<marcan>
the only piece that should care about exact actual firmware versions is m1n1
<marcan>
compat can be checked for exactly since we define the "blessed" versions and those are all that should go in compat
<marcan>
for DCP right now, I think it should just drop the unknown version check for the version field
<jannau>
I spent too much time thinking whether I want reject missing properties
<marcan>
in this case I think we want to reject missing props, since this is critical information
<jannau>
yes, I still want to be able to report the actual fw_version though
<jannau>
yes, I came to the same conclusion. missing information should have been only valid for a transitional period to allow everyone to update m1n1
<marcan>
you can just report it numerically as %d.%d.%d :)
Guest1279 has quit [Quit: G-line: User has been permanently banned from this network.]
vx has joined #asahi
vx is now known as Guest1361
gladiac has quit [Quit: k thx bye]
delsol has joined #asahi
bcrumb has joined #asahi
piroko has joined #asahi
<bcrumb>
what process is tasked to move vmlinuz from lib/modules to boot/ ?
<bcrumb>
to vmlinuz-linux-asahi
bcrumb has quit []
piroko has quit []
piroko has joined #asahi
leitao has joined #asahi
bcrumb has joined #asahi
<bcrumb>
so, the asahi edge kernel is seriously a big improvement
<bcrumb>
very smooth
bcrumb has quit []
bcrumb has joined #asahi
<bcrumb>
though for some reason my kde stuff looks kinda blurry, not sure what part of my configuration could be affecting my UI, I set up wayland before it was cool and had it work with 150 DPI, i turned that off though before updating
<bcrumb>
what was apple native, 255 dpi or smth like that?
delsol has quit [Quit: Leaving...]
bcrumb has quit []
mkurz has joined #asahi
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mkurz has quit []
mkurz has joined #asahi
leitao has joined #asahi
mkurz has quit [Remote host closed the connection]
mkurz has joined #asahi
piroko9 has quit [Quit: nyaa~]
jamespmo_ has joined #asahi
jamespmorgan has quit [Ping timeout: 480 seconds]
bcrumb has joined #asahi
<marcan>
don't set font DPI
<marcan>
it's mentioned in the article
<marcan>
that setting should be off in wayland
<marcan>
use output scale instead
<bcrumb>
marcan: I've tried that, but then the fonts start blurring at anything beyond 100%, which is tiny, are the fonts high dpi for you?
<bcrumb>
if i know this is not expected behaviour i can go fix it, but otherwise everything works wonderfully even with forced dpi
<marcan>
fonts look fine for me, did you log out and back in after changing the settings?
<marcan>
it's normal for stuff to look blurry when first applying until you restart
<marcan>
but it's barely noticeable, and macOS does the same thing. KDE at 150% looks pretty similar to macOS tbh, as far as font rendering.
<bcrumb>
ok, let me see if i haven't reset post playing around with scaling by accident, since i saw that update at runtime
bcrumb has quit [Quit: WeeChat 3.7.1]
yuyichao_ has joined #asahi
bcrumb has joined #asahi
yuyichao has quit [Read error: Connection reset by peer]
<bcrumb>
works, i don't know what I like better though :/
<bcrumb>
force font looks much sharper, will this setting not be supported in the future?
nate8_ has left #asahi [Leaving]
<marcan>
this is being fixed in wayland, see the above bug
<marcan>
forcing DPI is likely to cause other issues with apps and is not really supported on wayland
LinuxM1 has joined #asahi
<bcrumb>
aight cool
<bcrumb>
btw, where should i raise an issue about a USB device not being recognized at boot time?
<sven>
does this happen on the vanilla asahi distro?
<bcrumb>
both edge and vanilla i think
<sven>
so you can reliably reproduce it there without any changes to the kernel or the initrd?
<bcrumb>
changes to the initrd, no, although the same stuff used in the initrd has formerly also allowed the usb device ( mouse with usb antenna ) to work
<bcrumb>
since the changes to the initrd are exacty those in that systemd PR
<bcrumb>
i'll go into the vanilla kernel once more
<bcrumb>
to confirm
<sven>
right, it sounds like you’re missing some modules
<bcrumb>
because, do note
<sven>
possibly atcphy and/or nvmem
<bcrumb>
that usb device does work when i just reconnect
<bcrumb>
post boot
<marcan>
fwiw the modules should be in the initramfs as of recent asahi-scripts
<marcan>
unless I missed something
<marcan>
bcrumb: that's something else (I think, sven?)
<sven>
yeah, that sounds like something else then
<bcrumb>
yep, that is why i mentioned
<sven>
righth, I just double check with everyone who messes with the boot process because there have multiple people who messed up so far
<sven>
can you get the full dmesg output?
<bcrumb>
yes
<bcrumb>
hold on
<bcrumb>
this is why i just want to open an issue somewhere though
<bcrumb>
to dig first myself
rvalue has quit [Ping timeout: 480 seconds]
<sven>
I assume this is in the typec ports?
<bcrumb>
yes
<bcrumb>
also lsmod shows that the above modules are there, but we knew that
<sven>
ok, and with the latest kernel from a day or two ago? I recently fixed a race
<bcrumb>
yeah, so from rc6 5-1 to rc8 3-1
<bcrumb>
was the upgrade
<bcrumb>
scripts 1129 1206
<sven>
ok, then please paste the dmesg somewhere
<bcrumb>
yep sec
WindowPain_ is now known as WindowPain
bcrumb has quit [Quit: WeeChat 3.7.1]
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<axboe>
Glanzmann: lol shoot, didn't have to build them myself then :)
<axboe>
Glanzmann: works well or me, except chromium
<Glanzmann>
axboe: If you want to build yourself. I put a gpu.sh and mesa.sh script in the m1-debian git repository. Btw. if you figure out more kernel configs that work with the new kernel. let me know. Currently the only config that works for me is mps config (which is also in the m1 debian repository). When I try the reference config the kernel does not boot. When I try my old config, it also hangs with some late
<Glanzmann>
probeing keyboard backlight stuff.
<Glanzmann>
axboe: What is the issue with chromium?
<Glanzmann>
axboe: Never mind, I see. I'll put it on my bug list.
LinuxM1 has joined #asahi
<zzywysm>
Glanzmann: is there a particular type of kernel config for apple silicon you want me to make?
<mps>
Glanzmann: just for info, chromium works for me on alpine linux
<axboe>
mps: oh yeah? with hardware accel on?
<axboe>
if I have that on, it just sits and spins and spews some errors
<axboe>
unless loaded with LIBGL_ALWAYS_SOFTWARE=1
<mps>
axboe: hm, don't have idea. how to enable it?
<LinuxM1>
same for me, gpu acceleration on chromium won't start it, it's a problem with shared libraries
<axboe>
mps: go into settings, search for 'hardware'
<axboe>
a slider will show up
<Glanzmann>
zzywysm: Previously I used the debian testing arm64 config and enabled the asahi options. That config nolonger boots with the gpu stuff.
<mps>
aha, will try
<zzywysm>
Glanzmann: do you have any preferences? do you value a large amount of hardware compatibility, or do you like small more secure kernels? are you cool with kernel modules?
<Glanzmann>
zzywysm: I try to stick as close as possible to the Debian distro kernel.
<zzywysm>
the Debian distro kernel, like most distro kernels, is wildly bloated
<zzywysm>
any peripherals you use that i should make sure not to break?
<Glanzmann>
zzywysm: I know, I don't mind. Now that j`ey and jannau told me how to crosscompile.
<Glanzmann>
zzywysm: I only user usb devices like usb audio card, hdmi grabbers, cameras, mice, keyboards.
<Glanzmann>
oh and network cards.
<zzywysm>
k, give me a few hours
tinstew has joined #asahi
<mps>
axboe: hm, looks like hardware was enabled already
<Glanzmann>
LinuxM1: Maybe you just set it manuall. As root, run: echo 100 > /sys/devices/platform/led-controller/leds/kbd_backlight/brightness; # 0 means off 255 is the maximum value.
<Glanzmann>
jannau: WOrks for me.
LinuxM2 has joined #asahi
<Glanzmann>
jannau: Even the man over bord video smooth.
<LinuxM1>
Glanzmann, yes work!!!
<LinuxM1>
Glanzmann, so everytime i turn on i have to run that command? Isn't there a way to leave the backlight on?
<j`ey>
it should stay on that level
<Glanzmann>
LinuxM1: and if it doesn't just write a script that runs on boot,
<LinuxM1>
ah ok! a script with this command line
<mps>
LinuxM1: doesn't it works by default with kde?
<LinuxM1>
mps work on my macbook air M2, but not in MBP m1 Max
<mps>
ah, interesting
<LinuxM1>
to make it go to the MBP I had to give the command suggested before
<LinuxM2>
now i try reboot and i check if the backlight stays on
<LinuxM2>
in this username i use macbookpro m1 max
LinuxM2 has quit [Quit: Leaving]
leitao has joined #asahi
<LinuxM1>
very strange thing, I restarted the MBP m1 max with the backlight change given by the command suggested to me by glanzman, and now it remains stuck in the SSDM in the window where I should login, the touchpad does not work and the keyboard does the same which won't let me type
mkurz has quit [Read error: Connection reset by peer]
ariel has joined #asahi
ariel is now known as Guest1386
Guest1386 is now known as facekapow
facekapow has quit []
<axboe>
jannau: oops missed this, works!
<axboe>
jannau: it's the apple_dri that messes it up
<Glanzmann>
LinuxM1: Where did you put the command that I gave you?
bcrumb has joined #asahi
<bcrumb>
LinuxM1: try mashing fn+control+option+fn1 (or 2 or 3...) to get a login prompt in shell and change back the stuff you modified
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tinstew has joined #asahi
qabla has joined #asahi
<qabla>
hey guys
<qabla>
just wondering if its to be expected that battery on linux-asahi-edge would be running just about as much (maybe more?) than std asahi
<qabla>
losing about a % every 5-10 mins
<qabla>
im using i3 on xorg btw
<qabla>
is anyone experiencing similar issues?
mamba has joined #asahi
<qabla>
hello?
tinstew has quit [Ping timeout: 480 seconds]
<ar>
please be patient. people involved in the project are in a lot of different timezones
<qabla>
ok i have mmy element logging so i'll just hop off ric, but if anyone has an answer please feel free im still here
qabla has quit [Quit: leaving]
<ar>
also, 1% every 5-10 minutes would still be ~500-1000 minutes → ~8-16 hours, which sounds… reasonable?
<opticron>
looks like DCP is edge-only for both M1 and M2, so that should provide some power savings I think...
<opticron>
but edge also activates GPU
<opticron>
and depending on whether your DE (I know nothing about i3) is offloading to it, it could be saving power or not
<ar>
opticron: i3 is a simple non-compositing tiling wm
<jannau>
gpu rendering should more efficient as long as i3 doesn't redraw a bazillion times due to the vblank irq issue
mamba_ has joined #asahi
mamba has quit [Quit: Reconnecting]
mamba_ is now known as mamba
cylm has quit [Quit: WeeChat 3.6]
LinuxM1 has quit [Quit: Leaving]
LinuxM2 has joined #asahi
<LinuxM2>
chromium with gpu enabled in wayland not work:
<LinuxM2>
chromium
tinstew has joined #asahi
<LinuxM2>
chromium/usr/lib/chromium/chromium: error while loading shared libraries: libre2.so.9: cannot open shared object file: No such file or directory
c10l has quit [Quit: Bye o/]
c10l has joined #asahi
LinuxM2 has quit [Remote host closed the connection]
LinuxM2 has joined #asahi
<psykose>
that's not related to anything except not having the latest version of libre2 installed
<LinuxM2>
psykose, So can it be resolved?
<psykose>
try pacman -Syu :)
<LinuxM2>
My system is updated, that command launch it every day
Moprius has joined #asahi
abbe_ is now known as abbe
amw has quit [Ping timeout: 480 seconds]
<axboe>
LinuxM2: reinstall libre2?
<LinuxM2>
pacman -S libre2 ? There is no specific library with this name
<piroko>
it's re2
<piroko>
but it won't fix it
<piroko>
something is out of sync
<piroko>
(I have the same issue)
<axboe>
rolling distro fun?
<LinuxM2>
ah ok! I'm not the only one to have this problem with Chromium
<LinuxM2>
In my systems I have always used chromium, I don't love firefox
<axboe>
until chromium worked with 16k pages I did use firefox and quite liked it, but got drawn back to chromium from force of habit (and because I'm using it on other platforms)...
<axboe>
but sounds like chromium just needs to get re-linked, if re2 was updated to .10
<axboe>
of FF had better/smoother scrolling, I'd probably still use it
<axboe>
*if
<LinuxM2>
We hope it will be placed soon
jamespmo_ has joined #asahi
jamespmorgan has quit [Ping timeout: 480 seconds]
LinuxM2 has quit [Quit: Leaving]
Moprius has quit [Quit: bye]
mkurz has quit [Ping timeout: 480 seconds]
<psanford>
i think i've run into a 16k page issue with an application using jemalloc. DuckDB v0.6.0 segfaults consistently for me on asahi/nixos. It looks like they just switched to jemalloc in a recent version. Downgrading to a version before they switched to jemalloc works fine. Are there upstream jemalloc patches for 16k pages?
<povik>
23:03 < axboe> of FF had better/smoother scrolling, I'd probably still use it
<povik>
yeah, why does firefox either have chopped scrolling, or annoyingly interpolated?
tinstew has quit [Ping timeout: 480 seconds]
<j`ey>
psanford: jemalloc supports 16K.. but you have to build it to support it
<psanford>
do you have details on building jemalloc properly for 16k pages?
<j`ey>
yeah trying to find it
<j`ey>
--with-lg-page=16
<j`ey>
or 14 (thats 16K, =16 is 64K but should work)
<psanford>
great i'll try that. I'm curious how distros will handle that in their packaging systems