marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-stream #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
user982492 has joined #asahi
Augur[m] has joined #asahi
goldsoultheory_ has joined #asahi
goldsoultheory has quit [Ping timeout: 480 seconds]
nobodynada has quit [Ping timeout: 480 seconds]
nobodynada has joined #asahi
nobodynada has quit [Ping timeout: 480 seconds]
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nobodynada has joined #asahi
user982492 has joined #asahi
rohin2 has quit [Ping timeout: 480 seconds]
user982492_ has joined #asahi
user982492 has quit [Read error: Connection reset by peer]
nobodynada has quit [Ping timeout: 480 seconds]
robinp[m] has joined #asahi
rohin2 has joined #asahi
nobodynada has joined #asahi
nobodynada has quit [Ping timeout: 480 seconds]
nobodynada has joined #asahi
l3k has joined #asahi
l3k has quit [Quit: leaving]
tertu2 has joined #asahi
tertu has quit [Ping timeout: 480 seconds]
robinp[m] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nobodynada has quit [Ping timeout: 480 seconds]
nobodynada has joined #asahi
mika_ has joined #asahi
kov has quit [Quit: Coyote finally caught me]
kov has joined #asahi
phiologe has joined #asahi
mika_ has quit []
mika_ has joined #asahi
robinp[m] has joined #asahi
PhilippvK has quit [Ping timeout: 480 seconds]
marvin24_ has joined #asahi
marvin24 has quit [Ping timeout: 480 seconds]
user982492_ has quit [Remote host closed the connection]
robinp[m] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
user982492 has joined #asahi
mika_ has quit [Quit: mika_]
robinp[m] has joined #asahi
robinp[m] has quit []
robinp[m] has joined #asahi
robinp[m] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
marvin24 has joined #asahi
marvin24_ has quit [Ping timeout: 480 seconds]
rohin2 has quit [Ping timeout: 480 seconds]
robinp[m] has joined #asahi
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
user982492 has joined #asahi
goldsoultheory_ has quit [Quit: Leaving]
nobodynada has quit [Quit: leaving]
<kettenis>
jmr2: you could try booting linux from an external USB drive
everslick_ has quit [Remote host closed the connection]
everslick_ has joined #asahi
FireFox317 has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
FireFox317 has joined #asahi
<nsklaus_>
listening to the stream, i'm happy to hear asahi won't have the notch and will set resulutions to not use the area on the upper screen where the notch is.
<nsklaus_>
*upper part of the screen
<nsklaus_>
apple itself will probably will do the same, when it come to its sense in two years or so
darkapex1 has joined #asahi
gabuscus has quit [Remote host closed the connection]
darkapex has quit [Ping timeout: 480 seconds]
gabuscus has joined #asahi
bps2 has joined #asahi
user982492 has quit [Remote host closed the connection]
user982492_ has joined #asahi
user982492_ has quit []
<sven>
looks like the mailbox driver finally hit linux-next as well :-)
<j_ey>
great1
<j_ey>
sven: seems like subpage protection is always on for the t6000 dart
<sven>
fun
<j_ey>
(according2markan)
<sven>
checking if we can somehow make use of that instead of swiotlb is somewhere on my TODO list :D
<sven>
but first usb2 then rtkit and then finally nvme!
<j_ey>
:-)
aleasto has joined #asahi
VinDuv_ has joined #asahi
VinDuv has quit [Ping timeout: 480 seconds]
VinDuv_ is now known as VinDuv
<kov>
nsklaus_, could you tell me a bit more about the notch bit? is it some hardware configuration? I got told KMS couldn't do that by itself (well, I was told it could not ignore a part of the screen, I guess it can set a default resolution...)
<dottedmag>
kov: Pretend that the resolution is smaller than native, only display that on the screen.
<kov>
dottedmag, that something the display controller will do?
<dottedmag>
kov: Frankly I'm not sure. First I thought it's not hard to just manipulate framebuffer offsets a bit, but that means framebuffers have to be allocated for the whole screen and then returned to userspace with some unused bits before the the "start" pointer, but now I'm not sure DRM can do that.
<kov>
yeah, daniels told me that wasn't how kms worked, but I guess advertising the highest 16x10 resolution as native sounds doable?
darkapex1 has quit [Ping timeout: 480 seconds]
<nsklaus_>
kov: i have no idea how asahi team plan to do it, i'm not hardware dev, i'm just linux user, i was just reacting to marcan's stream where at the beginning he said what he intended to do (if possible). but, seeing macos does just that when running an app in fullscreen mode (not using the upper part of the screen where the notch is, rendering everything below that Y point) i suppose
<nsklaus_>
linux will try to do the same, just, all the time rather than just when some app goes fullscreen. but for the technical details, it's best to ask people will real qualifications to answer properly
<kov>
I see
<kov>
yeah, that's definitely something the compositors can do, like gnome-shell and kwin can decide what part of the screen apps will use, I was hoping we can have a solution at the kernel level though to save us the trouble ;D
<jix>
no idea what happens under the hood, but on xorg with xrandr you can almost add a black bar using --transform .. you can get a smaller framebuffer by scaling and you can shift the output to get a black bar... problem is it's still stretched and it moves parts offscreen
<nsklaus_>
i think it can be done at gfx driver level rather than in software configuration mode
<kov>
I think I may do some of the work on gnome-shell/mutter, my idea was to start with just ignoring the notch, then iterating on adding that screen space back - detecting it, moving the clock (the notch will cover it), and doing the fullscreen ignores the notch area
<nsklaus_>
what i mean is that linux would always avoid using the upper part of the screen, not just in X session, but in tty too, just everywhere
<kov>
yeah, that was what I was hoping, but I was being told KMS doesn't do that
<nsklaus_>
to me gnome is an abomination
<kov>
I respect your opinion
<nsklaus_>
i mean, i tend to avoid it like plague, so i wouldn't know the first thing about it, last time i touched gnome was in the early 2000s
<nsklaus_>
gnome2 era
<kettenis>
for a plain framebuffer this is trivial
<kov>
nsklaus_, don't worry, I know about the gnome part =)
<nsklaus_>
kettenis: i might be wrong but, it seemed to me that, every gfx driver (kms, gpu, framebuffer,..) would take an x and a y axis coordinate to start rendering at said location, so it would be as simple as passing an offset to it ?
<kov>
I just don't know about the kernel bits, thus why I'm wondering, because I was told by people who know what they are talking about KMS could not ignore the area, it can however tell us where the dead space is
<kov>
however, if it's just a matter of changing the resolution to the highest 16x10 one, then maybe it's not that hard to get no notch by default
<kov>
we'll see
<chadmed>
well the screen itself is 70px taller than a normal 16:10 res, so you would just give the framebuffer a 16:10 res and then shift it down by 35px, assuming it spawns in the middle of the screen
<chadmed>
this _might_ be something you can do with the display controller, just have it present a screen space of "normal" dimensions. userspace wouldnt even have to know about the 70px above 16:10 where the notch is
<kov>
that'd be great
<nsklaus_>
all i can say is that i was glad to hear marcan acknowledge that it didn't make any sense in linux world to support that, and it would require lots of big projects (desktop environments, apps , etc) to support it and probably noone would bother, so best to bypass that 'notch' altogether.
<kov>
I think eventually we'd want to recover the space for people who really want it, but it would be a nice place to start
<j_ey>
^ he said that too
<nsklaus_>
i'd be happy to loose 70px in top of the screen and be done with this 'notch' nonsense
<j_ey>
so you keep saying!
<chadmed>
the only problem i can see wrt the notch is fullscreen things like games, but in that case youd probably just give the game a 16:9 res and put up with it being letterboxed
<kov>
nsklaus_, yeah but linux is about choice™
<mini>
depends if other manufacturers follow the design choice ro not
<kov>
chadmed, yeah, that seems to be what mac os does
<kov>
and that'd need to be the compositor's job
<chadmed>
other than that, all the major DEs have ways to "accommodate" it. kde's menu bar equivalent has spacer widgets, so you can just put one under the notch and nothing will collide with it
<kov>
yeah, and we'd ideally do those things by default when we detect the dead space
<chadmed>
kov: dont most linux games just deal with SDL directly instead of going through the DE?
<nsklaus_>
j_ey: yes, well sorry about that. i didn't want to spam the channel, i'll keep quiet about it now
<chadmed>
nsklaus_: cat's out of the bag :P
<kov>
chadmed, but if they're running on wayland they'll need to go through the compositor anyway, unless the compositor enables a bypass mode
<kov>
(I'm not so sure about X, but I think if a compositor is running they'd have to go through the compositor as well)
<kov>
as in, SDL just opens an X window (or wayland surface, has it been ported?), it doesn't write directly to the framebuffer, unless you're using a fb/kms backend and running on a console
<chadmed>
SDL can apparently draw surfaces directly to wayland
<kov>
yeah, when it creates a surface it's talking to the compositor (wayland is just a protocol), the compositor will decide what to do wit it
<chadmed>
right yeah
<klange>
Please don't make me relive my memories of the days when GLX would use overlays and laugh at your puny compositor...
<kov>
yeah, X is a more special beast
<chadmed>
"special" is right
<kov>
but I think even those tricks won't work if you're running XWayland, it'll end up as a surface controlled by the wayland compositor anyway ;D
<chadmed>
yeah i know csgo does this, havent experimented with scaling though. its a good test case because the game has hardcoded limits for resolution/aspect scaling to prevent people gaining competitive advantages with wide or tall screens
<kov>
nice
<chadmed>
performance is generally terrible via XWayland though sadly, at least it is on nvidia
<chadmed>
and kwin_x11 is not getting any new features as of a few weeks ago
<kov>
I haven't used it for much more than chrome (under gnome), I don't really feel that much overhead
<chadmed>
yeah i just mean for games. csgo specifically.
<kov>
makes sense
<kov>
so I guess for games you really want to stay on X for now
<chadmed>
that said, that could just be an nvidia thing. im still running a gtx780 because i refuse to spend any more money on the PC ecosystem
<kov>
right, I use it with intel graphics, so you know, not gaming haha
<chadmed>
intel's wayland support is pretty good too. ive had some issues on my macbook but that might be related to nvme power management or something else quirky on the later intel macs
<kov>
well tbf I did play a few steam games, but not the kind that requires that much of the GPU, things like Invisible Inc., FTL
<chadmed>
apparently you can pass an environment variable to SDL to tell it to hook wayland directly. ill need to see if this works with any of my source engine games at some point
<kov>
for WoW and HotS I've been using either a PC or the mac mini
<chadmed>
by directly i mean without XWayland
<kov>
a PC as in a windows PC with a 1080, and moonlight
<kov>
(but looking forward to playing WoW with quality 10 on the macbook pro 14" m1 max 32 gpu cores xD)
darkapex has joined #asahi
<chadmed>
im slowly coming around to the idea of buying a macbook, but i dont want all my desktop hardware to be useless until the thunderbolt/usb-c drivers are done and i am far too stupid to be of any help with either given how complex they are
<chadmed>
but my vibe analysis tells me we wont get M1 pro/max mac minis until Q2 next year so i might have to bite the bullet
<kov>
yeah... that's more or less my thinking, I think they may even skip pro/max for minis
<kov>
and keep it at the base M models, so the next one would be M2
<kov>
I guess they want to keep that segment for the iMac Pro
<chadmed>
nah theyre definitely coming, we have schematics and renders for the chassis
<chadmed>
theyve just been delayed because of how rooted global supply chains are. word is theyve barely enough chips for the macbooks even
<kov>
I've seen the renders, but do the schematics confirm it's M1 Pro/max?
<kov>
because if not I'm still betting on A15-based M2
kaprests_ has joined #asahi
kaprests_ has quit [Quit: leaving]
<chadmed>
i dont think theyll release the M2 so close to the M1P/M
<chadmed>
plus theyll want to start being seen as a legitimate contender in the workstation/server space. thus, they will release manycore mac minis/mac pros based on the M1 design before they will come with an M2
<chadmed>
im sure someones got that infographic link lying around somewhere, but it looks like we will be getting minis/pros with M1 Pro/Max based multi-chip packages.
<kov>
I won't complain for being wrong tbh =D
coderobe has joined #asahi
gpanders[m] has joined #asahi
jbowen has joined #asahi
gpanders[m]1 has joined #asahi
rohin2 has joined #asahi
bps2 has quit [Ping timeout: 480 seconds]
daniels has joined #asahi
<daniels>
fwiw on the notch, the thing to do is:
<daniels>
* expose the 16:10 mode as the default to userspace, and offset the primary plane in Y when it's in use so the notch is avoided (there have been patches for a CRTC background-colour property if DCP supports this, but they never landed due to lack of open userspace for them)
<daniels>
* similar to 3D modes, add a new mode flag for notchful modes, which are not shown to userspace unless they opt in to a new DRM client cap for it
<daniels>
* create a new CRTC property for the notch area
<daniels>
* smart userspace can set the client cap, see the notchful modes and the CRTC property, and render around it
<daniels>
(you'd have to do the equivalent for Wayland, where fullscreen only meant 16:10 unless you opted in to notch awareness)
<marcan>
#1 was my idea, yeah
<marcan>
good to hear about the right way to implement notch-awareness
<marcan>
do you have any good ideas about how to represent the notch shape itself?
<marcan>
ultimately it's a bitmap mask; I don't know how it is on these machines, but at least on Androids I've seen software is expected to antialias/mask the edge
<daniels>
huh, TIL about Android ... I mean you could certainly just expose a bitmask as a blob property, but rect would be easier for now and almost certainly sufficient?
<marcan>
*memsets the framebuffer*
rohin2 has quit [Ping timeout: 480 seconds]
<marcan>
oh wow, the antialiased edges are done in hardware
<marcan>
well, that makes software's life easier
<marcan>
wonder if this is display controller magic, or in the TCON
<marcan>
shitty phonecam shot, but you get the idea
<marcan>
also, it's not just the notch
<marcan>
there are also rounded corners on the top left and right
<daniels>
yeah
<marcan>
that also needs to be exposed to userspace
<ar>
i'm kinda surprised notch information isn't present in DT
<marcan>
it only has a boolean flag, yeah
<marcan>
but it's probably because they couldn't figure out a good way to represent the particulars generically...
<daniels>
is the grey/black split your doing (i.e. literally what's in the fb), or can you program a background colour for areas not covered by a plane?
rohin2 has joined #asahi
<marcan>
just what's in the fb
<daniels>
gotcha
<marcan>
I memset 1MiB and it landed there :p
<daniels>
heh
<ar>
(also, i wonder how long it'll take for them to switch to under-display cameras ;) )
<j_ey>
1MiB .. is not a lot of screen is it
<marcan>
not on these retina ones, no...
<marcan>
and this is why they use framebuffer compression for macos/agx
bps2 has joined #asahi
jbowen has quit [Ping timeout: 480 seconds]
rohin2 has quit [Ping timeout: 480 seconds]
Bey0ndB1nary has joined #asahi
Bey0ndB1nary has quit []
pipcet[m] has left #asahi [#asahi]
jbowen has joined #asahi
bps2 has quit [Ping timeout: 480 seconds]
jbowen has quit [Ping timeout: 480 seconds]
kenjigashu has joined #asahi
kenjigashu has quit [Remote host closed the connection]
jbowen has joined #asahi
___nick___ has joined #asahi
___nick___ has quit []
___nick___ has joined #asahi
user982492 has joined #asahi
quentin[m] has joined #asahi
kenjigashu has joined #asahi
kenjigashu has quit [Remote host closed the connection]
kenjigashu has joined #asahi
kenjigashu has quit []
mika_ has joined #asahi
mika_ has quit [Remote host closed the connection]
jacoxon has joined #asahi
aleasto has quit [Remote host closed the connection]
jbowen has quit [Ping timeout: 480 seconds]
___nick___ has quit [Ping timeout: 480 seconds]
kenjigashu has joined #asahi
kenjigashu has quit [Remote host closed the connection]
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jacoxon has quit []
bps2 has joined #asahi
kenjigashu has joined #asahi
bps2 has quit [Ping timeout: 480 seconds]
bps2 has joined #asahi
bps2 has quit [Ping timeout: 480 seconds]
kenjigashu has quit []
bps2 has joined #asahi
user982492 has joined #asahi
<phire>
"<marcan> oh wow, the antialiased edges are done in hardware" I'm curious if that's done in the LCD controller, or if it's a physical property of the panel itself.