notHorseface has quit [Remote host closed the connection]
vanveldt has quit [Ping timeout: 480 seconds]
notHorseface has joined #aarch64-laptops
monkeybusiness has joined #aarch64-laptops
dc7800_ has quit []
dc7800 has joined #aarch64-laptops
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]
crabbedhaloablut has quit []
crabbedhaloablut has joined #aarch64-laptops
dc7800_ has quit [Read error: Connection reset by peer]
dc7800 has joined #aarch64-laptops
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]
dc7800 has joined #aarch64-laptops
dc7800_ has quit [Ping timeout: 480 seconds]
dc7800 has quit [Read error: Connection reset by peer]
dc7800 has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]
dc7800 has joined #aarch64-laptops
<penguin42[m]>
right, nice shiny 7.2.0 base on here
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Ping timeout: 480 seconds]
pbrobinson has joined #aarch64-laptops
dc7800 has joined #aarch64-laptops
dc7800_ has quit [Remote host closed the connection]
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #aarch64-laptops
dc7800 has joined #aarch64-laptops
dc7800_ has quit [Read error: Connection reset by peer]
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]
dc7800 has joined #aarch64-laptops
dc7800_ has quit [Read error: Connection reset by peer]
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]
bandini has joined #aarch64-laptops
dc7800_ has quit [Read error: Connection reset by peer]
dc7800 has joined #aarch64-laptops
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #aarch64-laptops
enyalios_ has quit [Remote host closed the connection]
enyalios has joined #aarch64-laptops
dc7800 has joined #aarch64-laptops
dc7800_ has quit [Read error: Connection reset by peer]
<lynxy>
does anybody know if ControlPortOverNL80211=false is still required for iwd on the qualcomm wifi chips in the x1e devices?
<lynxy>
i remember about a year back that connection was very unstable without this option set
<lynxy>
also- valpackett: what on earth are you running to achieve 3w at idle?? i'm running a clean install of arch with the drzee repo for aarch64 devices, the correct dtb loaded and all dell firmware found without issue, and i'm hitting 12w at idle (load avg 0.26)??
<anthony25>
ASPM policy in powersupersave, you need the patches to correctly shutdown the usb controller when not in used (if I remember correctly), also the regulators for the webcam registered help a bit
<anthony25>
But 12W is really high, without all of this on my slim 7x I was at 6w idle
<anthony25>
And no you dont need that in iwd, at least not on the slim 7x
<anthony25>
Realistically on the slim 7x i'm more between 4 and 5w when idling, I can reach like 3.6W with what I wrote before, the psr patch and a content mostly dark on the OLED screen, while being really idle idle
<anthony25>
And no keyboard backlight, some laptops use quite a lot of power with it on
<lynxy>
what's the best way to control the aspm policy on the snapdragon devices? i imagine that many of the power management tools aren't quite compatible with newer architectures
<sven>
Table F-10 of the "USB Type-C Cable and Connector Specification R2.5" defines bit 16 of that VDO as 0 = TBT3 Adapter and 1 = TBT2 Legacy Adapter
<sven>
i've also found some references to a USB Type-C ECN Thunderbolt 3 Compatibility Updates but don't have access to that. the other consumers of that bit in the tree i can just change but that bit there looks weird so i'd like to confirm if it's intentionally claiming tbt2 legacy
<JensGlathe[m]>
DisplayLink is the virtual graphics interface, right? I have one of those here, too
<clover[m]>
Yeah my work gave me one of those docks with a m1 MacBook. I think that was the only way to drive two external screens
<JensGlathe[m]>
ah. Yes, also my work... and I could drive a 5k display with it if I were a mac user
Telvana has joined #aarch64-laptops
dc7800 has joined #aarch64-laptops
dc7800_ has quit [Read error: Connection reset by peer]
<valpackett>
anthony25: lynxy: the iwd/ath12k issue was fixed yea, no more conf knob required if everything is up to date
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]
dc7800 has joined #aarch64-laptops
dc7800_ has quit [Read error: Connection reset by peer]
<misyl>
oh god display link, what a horrible thing
<JensGlathe[m]>
if it does the job, it does the job
<Mis012[m]>
it does a job
<Mis012[m]>
with pcie tunneling could actually put a sane display engine in there I guess
<Mis012[m]>
but with usb... idk if you can abuse DMA enough
<lynxy>
valpackett: good to hear! thanks!
<robclark>
I'm with misyl about display link.. the only good thing about it is it's not my problem ;-)
<steev>
yet
<clover[m]>
it's a nifty option for people that want one port to drive two displays. hot plug works, and suspend resume works.
<JensGlathe[m]>
Mini-X has EL2 and sound now, btw
<misyl>
robclark: I have actively worked to make it not my problem
<misyl>
clover[m]: Making display-link work has a huge amount of costs, and at least in Gamescope, the trade-off wasn't work it for us as it would mean we have to do GPU composition 100% of the time
<clover[m]>
makes sense, probably not a good option for gaming
jhovold has quit [Ping timeout: 480 seconds]
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]
<valpackett>
compositor wise, there shouldn't really be displaylink specific work, it's the same split node situation as many embedded socs with totally separate display engines
Telvana is now known as Rob
Rob is now known as Guest15855
krei-se- has quit []
<valpackett>
(idk why i said embedded, high performance socs too heh)
Guest15855 has left #aarch64-laptops [WeeChat 4.10.0]
<robclark>
arm does license afbc so that $vendor can add support to scanout stuff mali renders without another step to blit to linear
<robclark>
so not exactly the same
krei-se has joined #aarch64-laptops
<valpackett>
oh right gbm/kms is kinda not very helpful there, somehow i thought it helped with the negotiation but.. not really lol
<robclark>
there is fourcc+modifier negotiation... but displaylink isn't going to support UBWC, for ex
<valpackett>
selecting a format common for all nodes is just "generally correct api usage" imo
<HdkR>
Obviously Displaylink just needs to support all the vendor's compressed framebuffer formats, then it'll be good! </s>
<robclark>
:-P
<misyl>
valpackett: not really, usually the case is those split display engines can at least handle the compressed format provided by the gpu. :P
<misyl>
forcing everyone's swapchain to LINEAR is bad
<misyl>
in SteamOS we rely super heavily on using the display hardware for 3D LUTs and other color and non-color transformations to avoid composition
<misyl>
DisplayLink just doesn't provide anything there, so we are forced to composite basically always
<valpackett>
"usually" is the problem, the API is more flexible and nodes can be arbitrary (displaylink is just the popular example but you can render on a dGPU and display on an iGPU, etc.)
<misyl>
those iGPUs usually support the same compressed formats or some subset
<valpackett>
everyone shouldn't be forced to linear, the compositor is supposed to query what's supported and only use linear if nothing better has been negotiated
<misyl>
that's what i am saying -- with displaylink you get linear or nothin
dc7800_ has quit [Ping timeout: 480 seconds]
<valpackett>
well.. linear is better than nothing :D
dc7800 has joined #aarch64-laptops
<HdkR>
Some people might prefer nothing in that situation :)
<misyl>
in that situation it's usually better to composite
<misyl>
some apps do crazy compute work on their swapchain buffers that benefits from compressed image stores
<misyl>
but i am definitely not the average non-gamer or the average compositor
Rob has joined #aarch64-laptops
<valpackett>
obviously :) still i guess most people would prefer a working fallback (and a "hey your stupid dongle is slow" warning?) than stuff not working, even in the steam case
<valpackett>
actually i think regular DEs would also do well to include such warnings in display settings..
<valpackett>
because someone could get a displaylink dongle without specifically looking for one
<clover[m]>
hl.dsp.exec_cmd("notify-send 'hey your stupid dongle is slow'")
dc7800_ has joined #aarch64-laptops
dc7800- has joined #aarch64-laptops
dc7800_ has quit [Read error: Connection reset by peer]
dc7800 has quit [Ping timeout: 480 seconds]
<clover[m]>
added to my dotfiles lol
dc7800- has quit [Read error: Connection reset by peer]
dc7800 has joined #aarch64-laptops
<misyl>
i dont think someone has made a non-stupid dongle yet ;P
enyalios_ has joined #aarch64-laptops
enyalios has quit [Ping timeout: 480 seconds]
dc7800 has quit [Ping timeout: 480 seconds]
dc7800 has joined #aarch64-laptops
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]