marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | "Does XXX work yet?": https://alx.sh/fs | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-alt #asahi-stream #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
matteo has joined #asahi
jnn has joined #asahi
jn has quit [Ping timeout: 480 seconds]
pb17 has quit [Ping timeout: 480 seconds]
matteo has quit [Remote host closed the connection]
matteo has joined #asahi
KxCORP5894 has quit [Quit: Bye!]
KxCORP5894 has joined #asahi
pb17 has joined #asahi
tobhe_ has joined #asahi
tobhe has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
john-cabaj has joined #asahi
ten1572377432463050 has quit [Remote host closed the connection]
ten1572377432463050 has joined #asahi
pb17 has quit [Ping timeout: 480 seconds]
john-cabaj has quit [Quit: john-cabaj]
glem has quit [Ping timeout: 480 seconds]
pb17 has joined #asahi
jgowdy has joined #asahi
systwi has joined #asahi
shiggitay_ has joined #asahi
shiggitay_ has quit [Remote host closed the connection]
JayBeeFOSS has quit [Remote host closed the connection]
JayBeeFOSS has joined #asahi
matteo has quit [Remote host closed the connection]
<PaulFertser>
LarstiQ: here someone said that even moving cursor on external display makes sound stutter.
<PaulFertser>
LarstiQ: so if you do not experience that it would be interesting to know if you use wireplumber or pulseaudio and what soundcard is playing the sound.
<PaulFertser>
LarstiQ: and you're using latest evdi from Nix packages, right?
<LarstiQ>
wireplum, bluetooth headset
<PaulFertser>
I checked the logs, it was frek.
<LarstiQ>
PaulFertser: ~latest though some days old. The module is loaded but perhaps not active without a displaylink device at home
<PaulFertser>
LarstiQ: oh, that's not representative then :)
<LarstiQ>
I can test actual displaylink behaviour next week :)
<PaulFertser>
LarstiQ: thank you
vx has quit [Quit: G-Line: User has been permanently banned from this network.]
vx has joined #asahi
chadmed has joined #asahi
Frontal has quit [Remote host closed the connection]
<jannau>
ls
shiggitay has quit [Ping timeout: 480 seconds]
jeffmiw has quit [Ping timeout: 480 seconds]
f_ has joined #asahi
pb17 has quit [Ping timeout: 480 seconds]
andymandias_ has joined #asahi
ten1572377432463050 has quit [Quit: Ping timeout (120 seconds)]
ten1572377432463050 has joined #asahi
andymandias has quit [Ping timeout: 480 seconds]
ncopa has quit [Quit: Alpine Linux, the security-oriented, lightweight Linux distribution]
ncopa has joined #asahi
wille-io has quit [Ping timeout: 480 seconds]
pb17 has joined #asahi
<ouzel8>
ne Linux, the security-oriented, lightweight Linux distribution)
<ouzel8>
* ncopa (~ncopa@gbr2-dev1.alpinelinux.org) has joined
<ouzel8>
* wille-io has quit (Ping timeout: 480 seconds)
<ouzel8>
Any news about if, and when we will see a component for sleep power control, and power optimisation on Fedora for "Apple silicon". It is currently unusable foe day to day, hour to hour use.
<chadmed>
i got 15 hours of battery life out of my macbook today
jeffmiw has joined #asahi
<ouzel8>
Ah, so I suppose it will work a day.
wille-io has joined #asahi
<ouzel8>
But sleep is definitely inefficient.
<ouzel8>
So like overnight, or three days it definitely runs flat.
<ouzel8>
It seems most people are aware of this, but no news yet.
oneiros has quit [Remote host closed the connection]
<LarstiQ>
that said I use it day to day, hour to hour. What it doesn't manage is sleeping over the weekend
cylm has joined #asahi
<chadmed>
the major PM issues are on the pro/max/ultra socs anyway
<chadmed>
if you have a base m1 or m2 you won't really notice massive power drain. sure there are things we could be doing (e.g. hw video decode) but like i said i already get 12-15 hours out of an 80% charge most days
<LarstiQ>
M1 Pro here
jeffmiw has quit [Ping timeout: 480 seconds]
<chadmed>
yeah those definitely have issues. my 14" can stretch to about 8 hours if im _very_ conservative with use :p
<LarstiQ>
that's still several times longer than my previous thinkpad
<chadmed>
my work stinkpad barely lasts 2 hours at the desktop
pb17 has joined #asahi
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi
matteo has joined #asahi
matteo has quit [Ping timeout: 480 seconds]
<sven>
my work machine also slows down due to power saving mode the moment it’s not connected anymore
<sven>
and that thing is already slow without that power savings crap :D
jeffmiw has joined #asahi
<sven>
unfortunately back then the choice was x86 macbook or this weird machine I have now :(
<iyes>
does using a 16k pagesize kernel mean that everything will generally use more RAM, because the memory allocations of various applications might be more wasteful/inefficient because of having to map larger pages?
<iyes>
i am honestly surprised by just how high my RAM usage % is on asahi, compared to x86 linux systems, and i wonder if this might have something to do with it
<alice>
yes
<nicolas17>
iyes: well not every memory allocation gets rounded up to a whole page
<nicolas17>
libc gets a whole page and then multiple allocations are put in it
<iyes>
yeah i know that malloc implementations will sub-allocate
<iyes>
but still
<nicolas17>
perhaps one other difference you're seeing is that in your x86 system, GUI apps end up allocating VRAM in the GPU
<nicolas17>
here there is only one pool of memory
<iyes>
oh! and that counts towards used RAM % as linux reports it?
<nicolas17>
system-wide, it has to, since that RAM is clearly not "free"
<nicolas17>
per-process, I'm not sure how well it's tracked
jeffmiw has quit [Ping timeout: 480 seconds]
<nicolas17>
and on discrete-GPU systems it may be counted as virtual memory used by the process anyway
<iyes>
yeah virtual memory is a whole another story
<iyes>
ive seen applications that have >1TB of virutal memory use lol
<iyes>
im guessing from huge sparse mappings that end up unused, mapped files, GPU memory, etc etc
<iyes>
i kinda love the linux kernel's overcommit-based memory management strategy