ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Chrome OS Trogdor Devices - Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630 - Lenovo ThinkPad X13s - and various other snapdragon laptops) - https://oftc.irclog.whitequark.org/aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<anthony25>
alexVinarskis[m]: I confirm that your patches work on the slim 7x
<anthony25>
testing on 4K@120Hz right now
<anthony25>
it's a 4K@240Hz screen, and all the 3 usb ports of the laptop work at 4K@120Hz (expected without DSC)
<anthony25>
this screen is a bit picky over usb-c with devices that don't support 4K@240Hz, but on this laptop, one usb port seems to train better than the other and immediatly works
<anthony25>
for the 2 other ports, I need to power down the screen and power on again, and then it works
<anthony25>
Windows has the same problem, and it might be related to the screen (I had the same problem with an older intel laptop, the new one supports 4K@240Hz and has no more issue)
<anthony25>
thanks a lot!
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
eirikkar has quit [Quit: Ping timeout (120 seconds)]
eirikkar has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
tobhe has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
tobhe_ has quit [Ping timeout: 480 seconds]
<steev>
spawacz: glad another person confirmed it works :D
chrisl has joined #aarch64-laptops
<JensGlathe[m]>
HP X14 waking normally from sleep again, type-c ports are there.
chrisl has quit [Ping timeout: 480 seconds]
eluks has quit [Remote host closed the connection]
eluks has joined #aarch64-laptops
<JensGlathe[m]>
It has gotten new UEFI firmware (f.31) which is a mighty jump from the last one (f.13?) - and apparently there are no PS883x retimers left 🤔🤨
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<valpackett>
huh, seeking is busted in iris h264 with gstreamer
<valpackett>
qcom-iris aa00000.video-codec: session error received 0x1000006: unknown ; qcom-iris aa00000.video-codec: session error received 0x4000004: invalid operation for current state
jhovold has joined #aarch64-laptops
davidinux has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
ravikant_ has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<alexVinarskis[m]>
anthony25: thanks for testing and feedback, happy it works as expected!
SpieringsAE has joined #aarch64-laptops
<alexVinarskis[m]>
There is a debug output (if you picked debug pacth too or run Jens's kernel), is it pin assignment 4 or 6 when you connect 4lane DP? Could you please additionally confirm that 1. USB3.0 still works, in both orientations, 2. You are able to suspend and resume just as before, without extra screen related dmesg errors (leaving TypeC plugged in)
<alexVinarskis[m]>
anthony25: regarding one screen working and another needing repower: did you try swapping Type-C cables between working/non-working monitors? Or just using another Type-C cable?
chrisl has joined #aarch64-laptops
<steveej[m]>
jhovold for the known issues on your wiki, is there a corresponding list of bug reports? i'd like to estimate if or when some of them get resolved. i'm eagerly waiting for the moment to start recommending these fanless aarch64 laptops to linux beginners :-)
chrisl has quit [Ping timeout: 480 seconds]
<jhovold>
steveej[m]: short answer no, some issues like the wifi ring-buffer corruption was originally reported to upstream but I ended up fixing that one myself, similar for the recent ucm breakage
<jhovold>
but most are tracked "internally" at linaro, even if I try to also send out a report on the mailing list where appropriate
<jhovold>
for example, the camera null deref at boot, or the broken phy repeater implementation that breaks lockdep
erebion_[m] has joined #aarch64-laptops
jglathe_angrybox has joined #aarch64-laptops
<erebion>
Has anyone here had a look at the new ARM Thinkcentre yet? Does it run Linux? Can't find much on it. I know this chat is mostly about laptops, but don't know a better one for the question.
<valpackett>
erebion: is it on sale anywhere even? i've just heard somewhere (here??) very recently that they had just opened preorders
<jannau>
german lenovo site allows configuring and claims shipment within 6-9 days
chrisl has joined #aarch64-laptops
<JensGlathe[m]>
I can configure one, mine would be €750. But no device tree yet, for sure no GPU acceleration yet, and out of excuses to buy more tech
<valpackett>
is it the first product coming out with an "X Minus" (X1-26-100) chip?
<JensGlathe[m]>
No. There are more already, but the x126100 is Purwa. So it will be supported as much as Purwa is supported already.
erebion_[m] has left #aarch64-laptops [User left]
<JensGlathe[m]>
alexVinarskis's A14 has an x126100 iirc
erebion_[m] has joined #aarch64-laptops
<alexVinarskis[m]>
Correct.
erebion_[m] has left #aarch64-laptops [User left]
erebion_[m] has joined #aarch64-laptops
erebion_[m] has left #aarch64-laptops [User left]
erebion_[m] has joined #aarch64-laptops
erebion_[m] has left #aarch64-laptops [User left]
erebion_[m] has joined #aarch64-laptops
kalebris has quit [Remote host closed the connection]
kalebris has joined #aarch64-laptops
erebion_[m] has left #aarch64-laptops [User left]
erebion_[m] has joined #aarch64-laptops
kalebris has quit [Remote host closed the connection]
erebion_[m] has left #aarch64-laptops [User left]
erebion_[m] has joined #aarch64-laptops
kalebris has joined #aarch64-laptops
erebion_[m] has left #aarch64-laptops [User left]
chrisl has quit [Ping timeout: 480 seconds]
kalebris has quit [Remote host closed the connection]
kalebris has joined #aarch64-laptops
erebion_[m] has joined #aarch64-laptops
erebion_[m] has left #aarch64-laptops [User left]
<anthony25>
I'll try with another cable
chrisl has joined #aarch64-laptops
<anthony25>
I suspect it's more due to the switch between my PC output (Displayport, 4K@240Hz) and the USB-C output, and that switching from 4K@240Hz to USB-C is picky if the device doesn't support the same refresh rate (in this case, doesn't support DSC)
<anthony25>
I'll try with my TV as well, it does 4K@144Hz
<anthony25>
but again, Windows has the same problem on my desktop monitor
chrisl has quit [Ping timeout: 480 seconds]
erebion_[m] has joined #aarch64-laptops
erebion_[m] has left #aarch64-laptops [User left]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
erebion_[m] has joined #aarch64-laptops
erebion_[m] has left #aarch64-laptops [User left]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<whiskey9>
Hey I noticed that Alex's dts related to wifi/bt for the 9345 didn't seem to get accepted and pulled into linux-next - does anyone know what's up with that?
ravikant_ has quit [Ping timeout: 480 seconds]
ravikant_ has joined #aarch64-laptops
jglathe_angrybox has quit [Remote host closed the connection]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
I got 4 lanes dp altmode on the x13s
<JensGlathe[m]>
usb0 only, though, but both orientations 🤨
<Treibholz[m]>
Hmm, I'm only getting 4K@30hz with my X13s...
<Treibholz[m]>
but still on 6.12.x
<JensGlathe[m]>
based on alexVinarskis patchset, extended to sc8280xp and the x13 dts
<JensGlathe[m]>
I mean its experimental, but will push 6.15.0-jg-1 with it, this is fun
<JensGlathe[m]>
would love to get usb1 functional, too, though
deathmist1 has joined #aarch64-laptops
deathmist has quit [Ping timeout: 480 seconds]
jglathe_angrybox has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
davidinux has quit [Ping timeout: 480 seconds]
SpieringsAE has quit [Quit: SpieringsAE]
<jhovold>
lenovo just sent a merge request for the venus fw for the x13s:
<jhovold>
that literally took two years, but better late than never :)
<Jasper[m]>
NICE holy crap
<Jasper[m]>
Is it finally time for the driver to be merged then? Did codec compat improve in the meantime?
<jhovold>
yeah, hopefully we can get the venus support in more or less in it's current state
<jhovold>
no, idea what condition the driver itself is in (well we did get some reports about crashes when transcoding iirc)
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
deathmist1 is now known as deathmist
<dgilmore>
Nice to have tho have an idea on whats changede firmware there and updates, but would be better t
kalebris_ has joined #aarch64-laptops
kalebris has quit [Ping timeout: 480 seconds]
kalebris_ is now known as kalebris
chrisl has joined #aarch64-laptops
alexVinarskis has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
alexVinarskis has quit []
ravikant_ has quit []
<Treibholz[m]>
oh, the files seem to be newer, than the ones on my windows-partition!
<dgilmore>
finally got the modem on my x13s to register when roaming in France. Only took all day
<Treibholz[m]>
dgilmore: had no problems in Luxembourg last weekend (nor in Belguim during FOSDEM). But I still can't persuade it, to use 5g...
<dgilmore>
I can not remeber if I had issues at FOSDEM, but previously I could not get it wirking in Spain, Germany, and Czech Republic at all
chrisl has joined #aarch64-laptops
<dgilmore>
currently connected via UMTS, but I am also quite Rural
<Treibholz[m]>
There is no UMTS anymore in Germany...
<dgilmore>
5G worked in th UK
<dgilmore>
the
<Treibholz[m]>
I can only debug the 5G part abroad, because my provider wants 5€ more for 5G (with the same speed as 4G - which I still refuse to pay) - but when roaming I get 5G (on my phone AND in windows)
<dgilmore>
I will see how it works in Australia next week
<dgilmore>
roaming is not the most frequent thing I can do. but I do get 5G everywhere
<Treibholz[m]>
dgilmore: Australia or Austria? (one of them might be very expensive when roaming...)
<dgilmore>
Australia
<dgilmore>
I am US based and get free global roaming
<Treibholz[m]>
Jens Glathe: Packages for Ubuntu, right?
<JensGlathe[m]>
Yes
<JensGlathe[m]>
And source tree
<Treibholz[m]>
hmm... maybe on the weekend, I'll find some to setup a clean kernel-build-setup, to build proper debian-kernels - It's been ages, since I did that the last time...
<Treibholz[m]>
* find some time to setup
<valpackett>
jhovold: at least with gstreamer as a client, with iris on x1e i'm seeing one (big) problem exactly: seeking in the video breaks it
<steev>
valpackett: we get that with venus on sc8280xp as well, i believe there is a linaro bug to track it
<steev>
mpv, iirc, does not have that issue
<kuruczgy[m]>
In case it wasn't only non-obvious to me, to get the camera working in firefox you have to enable `media.webrtc.camera.allow-pipewire` which is disabled by default...
<kuruczgy[m]>
With this, my camera on the slim7x works with firefox, it's even the right way up.
<valpackett>
steev: yea firefox doesn't either
<kuruczgy[m]>
Though it's a bit weirdly cropped. Also a bit green tinted as usual.
<valpackett>
on the dell for me the tint resolves itself quickly, the auto color balance even with no camera calibration files seems to be working well
<valpackett>
auto exposure tends to overexpose a bit tho and the worst part is the flickering
<Treibholz[m]>
here the camera works in snapshot and qcam fine - but in firefox it's very flickery (if the wall behind me is not dark!)
<valpackett>
i get the flickering in snapshot
<Treibholz[m]>
consistency \o/
<Treibholz[m]>
is it possible, to extract the calibration-files from windows?
<agl>
steev: Did you patched Kernel 6.15.0 and have you not pushed it on your Web site?
<agl>
for the x13s
<agl>
steev: On yout Web-Site at github.comist still 6.14.6.
<steev>
i have but i saw some clk issues so i haven't yet pushed it til i figure out if it's a patch from me, johan, or just part of 6.15
<steev>
i did push 6.14.8 just now though, which pulls in krzk's patch for adding the capacity entry for battery
<kuruczgy[m]>
Indeed I now also get the camera flicker in firefox :(
<agl>
steev: Ok .. I will compile and install it .. I will wait until 6.15 is out by you.
<Treibholz[m]>
kuruczgy: you need a dark wall...
<steev>
whoops, it's not krzk, sorry, i misread the name
<kuruczgy[m]>
I guess all these (green tint, flicker) are libcamera issues?
<kbingham>
kuruczgy[m], yes :-(
<Treibholz[m]>
kuruczgy: another possible workaround could be OBS with v4l2loopback-dkms
<Treibholz[m]>
I get no flicker in OBS, but libcamera-support is experimental and unstable.
<kbingham>
if anyone can find any calibration files for their camera in windows- I'd be very interested to see if we can get any usable calibration data out of them.
<kuruczgy[m]>
Hm... well that's definitely strange if it's alright in OBS but bad in firefox
<Treibholz[m]>
maybe firefox puts it in a 30hz mode which doesn't work....
<steev>
kbingham: they're just json files right?
<kbingham>
valpackett, That's not the flicker that's occuring. ... the SoftISP currently has a bug which causes the AGC to flicker. The solution IMO is to move the AGC implementation to use the libipa AGC implementation that's shared with the rest of libcamera rather than duplicating it with one that has a bug.
<valpackett>
oop
<kbingham>
steev, No idea! - in libcamera we use json/yaml files - but I haven't seen any windows calibration files.
<kuruczgy[m]>
kbingham: What would these calibration files be calibrating exactly?
<steev>
kbingham: ah, i thought the qsh_camera_$chipset.json files were calibration but i don't think they are now that i looked
<kbingham>
kuruczgy[m], They will contain things like the lens shading tables, and colour correction matrix (matrices?) data that configures the colour for known illuminants of light temperature, and ... well posssibly lots of other useful information to make a camear turn into somethign more useful.
<kbingham>
We have our own tuning tools that can generate this calibration informaiotn too - but that would require getting 'every device model' in a tuning box.
<steev>
i had hoped that it would be in the qcsensorsconfigXXXXXXX directory, but i don't think it is
<steev>
maybe its in dpp too?
<kuruczgy[m]>
kbingham: So from what I understand, libcamera is getting raw sensor data that's just a scalar value for each pixel, and turning that into RGB values has quite a few free parameters? I guess most of these are specific to the camera model, and should not vary much across devices? (So we don't have to have every user grab their own calibration data, once per sensor model is fine.)
<kbingham>
kuruczgy[m], correct - once per sensor model (device) is fine.
<kbingham>
I.e. We need 'one' Lenovo-X13s tuning data.
<kbingham>
(Some products do go for per individual device tuning, but we don't need that for a webcam)
<kuruczgy[m]>
kbingham: Here is the list of my files from windows that match ov02c10, if any of them sound interesting let me know and I can look deeper
<kbingham>
There are many stages to getting from a RAW sensor to 'good' RGB pixels. The main ones are the lens shading artifacts (handled by lens shading tables/data) then the sensor CCM to account for sensitivity differences. Then on top of that AWB does colour correction that is 'light source' dependent ... then there is gamma correction ... and black level correction but those two are easy to handle.
<kbingham>
kuruczgy[m], anything in ./Windows/System32/DriverStore/FileRepository/qccamfrontsensor_extension8380.inf_arm64_7a41e39ba4c057a9 and ./Windows/System32/DriverStore/FileRepository/qcsensorsconfigcrd8380.inf_arm64_4ad380f2610787f6 certainly look intesting.
<kuruczgy[m]>
kbingham: ^ here they are if you want to poke around
KieranBingham[m] has joined #aarch64-laptops
<KieranBingham[m]>
thansk
<KieranBingham[m]>
* thanks
hogliux has joined #aarch64-laptops
<hogliux>
kurzugy[m]: To fix the cropping issue (really bad in zoom for example), I first open this site on one tab: https://de.webcamtests.com/
<hogliux>
kurzugy[m]: For some reason after a few seconds the cropping issue resolves itself on that site. Then, I open Zoom on a second tab and keep the first one open.
<hogliux>
kurzugy[m]: Once zoom is streaming the camera feed you can close the first one again. For some reason that works around the cropping issue for me.
hogliux has quit [Quit: Leaving]
<Treibholz[m]>
aehm... it seems Firefox 139 fixed the flickering-problem...
<Treibholz[m]>
no... it's just too dark now...
<Treibholz[m]>
I'll try again tomorrow morning at the same light conditions.
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
hogliux has joined #aarch64-laptops
<hogliux>
I don't seem to have the flickering problem - neither in firefox nor in gnome-snapshot
hogliux has quit [Quit: Leaving]
<nirik>
I don't seem to see the camera here ( using the 6.15.0-jg-0 tree ). I did build the ec option in...does it need to be a module for some reason? I do see: "Error: Driver 'yoga-slim7x-ec' is already registered, aborting..." in dmesg...
<valpackett>
clients like firefox cannot fix the flickering problem, it's a *bug* in *libcamera's SoftISP* as kbingham said above
<valpackett>
nirik: not sure why EC would matter. do you have the config option for the camera sensor itself enabled?
<kuruczgy[m]>
hogliux: if I had to guess it depends on if your lighting has a 50/60Hz flicker or not.
<valpackett>
myry
<valpackett>
oop
<kuruczgy[m]>
Yes, I just tested and it does. With my light bulbs it flickers. With my studio light it does not.
<nirik>
I... think so, but perhaps not. Whats the option...
<valpackett>
kuruczgy[m]: not really, i've had the flicker in broad daylight, outside on a balcony
<kuruczgy[m]>
Hm... actually it might just be brightness dependent
<kuruczgy[m]>
yes
<valpackett>
yeah
<valpackett>
nirik: depends on your machine, OV02E10 for me
<nirik>
ok, will dig around. I should be able to see it in lsusb tho right? or is it not a usb cam? OF: reserved mem: 0x000000008e100000..0x000000008e8fffff (8192 KiB) nomap non-reusable camera@8e100000 is the only mention of cam in dmesg.
<valpackett>
btw, also make sure to enable UDMABUF
<valpackett>
SoftISP hard requires udmabuf at this point
<JensGlathe[m]>
Noticed that keeping on par with dts propagation is quite an issue.
<nirik>
ah, yes, that one. I tried to just cherry pick some things from it, but ran into... yeah, dts changes... ;(
chrisl has joined #aarch64-laptops
<konradybcio>
alexVinarskis: so there's been some unlucky timing.. i took another look at Neil's 4 lane dp patches as well
<konradybcio>
do your machines also have the issue where DP_ONLY->USB3_ONLY switch doesn't work immediately? seems like romulus doesn't like that on either
chrisl has quit [Ping timeout: 480 seconds]
<konradybcio>
to be clearer, going from 4 lane dp to 4 lane usb3 requires me to plug in the usb stick twice
<konradybcio>
the phy is programmed identically, but it seems like another layer doesn't react
<alexVinarskis[m]>
Ah wasn't aware of Neil's patches... Do you have a link?
<Jasper[m]>
konradybcio: idk if this matters, but I've had similar issues with non-4 lane dp on sc8280xp
<Jasper[m]>
Including the "one usb c port is broken" thing @[Jens Glathe] described
<Jasper[m]>
Generally fixed by a reboot
<konradybcio>
usb1 seems to sometimes get stuck in HS mode for me
<konradybcio>
not always
<konradybcio>
also generally fixed by a reboot
<Jasper[m]>
I've noticed that coldboot while charging breaks stuff for me
<konradybcio>
oh yeah i noticed charger plays a role too.. haven't ""truthtabled"" it out yet
<JensGlathe[m]>
I was planning to booby-trap all mux drivers with enter/exit debug messages to see what goes on
<alexVinarskis[m]>
Ahhh, beat me to it... Though his version is a bit more involved
<alexVinarskis[m]>
I had issue that going away from DP only to any other state would result in weird things as it would attempt to prepare/unprepare pipe_clk, which would fail. Fixing that i can go between x4 DP to USB+DP just fine. Didn't test x4 USB as wasn't aware its supported.
<konradybcio>
well by 4ln usb i meant the phy side config.. not really sure about the stick's capabilities
<konradybcio>
but what Jasper mentioned seems to be a bigger issue which I'm more likely to believe too
<Jasper[m]>
(for reference I run Fedora's default kernel which should in theory be mostly unpatched, hardwarewise, I believe)
<Jasper[m]>
I think this started right after some major patchset got merged w.r.t. roleswitching, but I don't remember what it was exactly
<alexVinarskis[m]>
We were testing with Glathe my changeset on top of linux-next from last Friday, and it seems ps883x worked very well, but whatever used sbu-mux was a bit more weird. I was under impression that switch/retimer must propagate mux state upstream (like ps883x does for both mux state, orientation), but sbu-mux driver doesn't, so actually im not sure why that one works at the moment..
<alexVinarskis[m]>
konradybcio: with Niel's series, when you have DP ONLY, can it suspend and resume? If no, maybe its related to issue i described.
<alexVinarskis[m]>
Ill try Neil series tomorrow, will report if it works on DP ONLY to USB ONLY here or not. Damn i really should read the lists better 😔
<kuruczgy[m]>
Is there some easy way to list all the connected DP monitor modes? (In particular stuff like bit depth, compression, etc.)
<kuruczgy[m]>
When I have multiple monitors connected and one with a high refresh rate I can see that the bit depth is shit, but it would be nice to have something more precise than just eyeballing it, when testing the 4 lane patches.
<kuruczgy[m]>
swaymsg -t get_outputs only lists resolution and refresh rate
<kuruczgy[m]>
Also, is there any difference in features between the series by alexVinarskis and Neil? Or are they independent implementations of basically the same thing?
<steev>
wlrandr maybe?
<JensGlathe[m]>
Neil's series appears to be a year old. Alex's implementation is a separate stab at it afaik
<steev>
wlr-randr*
<kuruczgy[m]>
steev: Nope, it also only lists resolution and refresh rate
<kuruczgy[m]>
steev: How should I parameterize `edid-decode`?
<kuruczgy[m]>
I was under the impression that EDID only gives you static information about a monitor, and not dynamic stuff like the current bit depth or DSC compression
<alexVinarskis[m]>
konradycio: just confirmed on Zenbook ith PS8833, switching from 4 lanes DP to USB3+DP (need to recompile with Neils changes to get USB only) works from first try. Unplug monitor, plug USB stick, it just works.
<konradybcio>
perhaps romu is weird
<JensGlathe[m]>
"perhaps"
<alexVinarskis[m]>
Well, or its because of USB3 only mode...
<konradybcio>
ah you said combo
<konradybcio>
it didn't work for me with your patches either though
<konradybcio>
as in, i did need to replug the type-c thumb drive
<alexVinarskis[m]>
Yes, i need to rebuild to Neils version to gain USB only. Will report back once I do.
jhovold has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
Caterpillar has quit [Read error: Connection reset by peer]