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 joined #aarch64-laptops
<robclark>
I guess it only "failed" if your expectations where unrealistic
<robclark>
and beyond that, it is a question best asked in a few years.. since I don't think ecosystems that aren't entirely controlled by one company (ie. apple) change overnight
<robclark>
meanwhile, I'm still pretty happy w/ may 7x
chrisl has quit [Ping timeout: 480 seconds]
davidinux has quit [Ping timeout: 480 seconds]
JesusGod-Pope666-Info has quit []
Darkijah has joined #aarch64-laptops
Darkijah has quit []
<steev>
when i was at genesi and we had that 800mhz single core mx51... we had a number of complaints that were asking us why the $150 machine couldn't compete with their $3000 laptop
JesusGod-Pope666 has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
JesusGod-Pope666 has quit []
chrisl has quit [Ping timeout: 480 seconds]
valpackett has joined #aarch64-laptops
<valpackett>
hihi everyone, just got a dell latitude 7455, dumped the acpi, working on the dt
<valpackett>
is there a knowledge base of like stuff to know for x1e porting? e.g. how stuff looks in the dsdt? not finding stuff like usb_mp / usb-a retimers in any dumped dsdt
<valpackett>
uugghh, the snps eusb2 driver was un-qualcommed recently in linux-next but the arm64 defconfig still has CONFIG_PHY_QCOM_SNPS_EUSB2 instead of the new non-QCOM version
<JensGlathe[m]>
which still has some issues, I removed this one from my tree because of it.
<valpackett>
wdym by removed, reverted the un-qualcomming patch series?
<JensGlathe[m]>
rebased it out, yes. But it was my tree.
<valpackett>
i was just trying to use postmarket's prebuilt linux-next but due to the missing defconfig change it was just straight up missing that driver now xD
<kuruczgy[m]>
With this I can build a working ISO for the slim7x, I don't see why it wouldn't fork for the x13s.
<kuruczgy[m]>
(Of course you need the other stuff like the initrd modules and kernel params too.)
<JensGlathe[m]>
valpackett leading to instant reboot in my case. I had it integrated, worked for me, but not T14s
tobhe[m] has quit [Quit: Bridge terminating on SIGTERM]
Eighth_Doctor has quit []
Jasper[m] has quit [Quit: Bridge terminating on SIGTERM]
travmurav[m] has quit [Quit: Bridge terminating on SIGTERM]
noisycoil[m] has quit [Quit: Bridge terminating on SIGTERM]
z3ntu|m has quit [Quit: Bridge terminating on SIGTERM]
KieranBingham[m] has quit [Quit: Bridge terminating on SIGTERM]
JensGlathe[m] has quit [Quit: Bridge terminating on SIGTERM]
stefan-schmidt has quit [Quit: Bridge terminating on SIGTERM]
teadaniel[m] has quit [Quit: Bridge terminating on SIGTERM]
smoorgborg[m] has quit [Quit: Bridge terminating on SIGTERM]
bumble[m] has quit [Quit: Bridge terminating on SIGTERM]
Pengyu[m] has quit [Quit: Bridge terminating on SIGTERM]
alexVinarskis[m] has quit [Quit: Bridge terminating on SIGTERM]
anonymix007[m] has quit [Quit: Bridge terminating on SIGTERM]
macc24 has quit []
JosDehaes[m] has quit [Quit: Bridge terminating on SIGTERM]
konradybcio has quit [Quit: Bridge terminating on SIGTERM]
Radical[m] has quit [Quit: Bridge terminating on SIGTERM]
brand[m] has quit []
clover[m] has quit [Quit: Bridge terminating on SIGTERM]
arj[m] has quit [Quit: Bridge terminating on SIGTERM]
dcavalca has quit [Quit: Bridge terminating on SIGTERM]
sobek[m] has quit [Quit: Bridge terminating on SIGTERM]
neobrain[m] has quit [Read error: Connection reset by peer]
mosamadeeb[m] has quit [Read error: Connection reset by peer]
angeloverlain[m] has quit [Remote host closed the connection]
freekurt[m] has quit [Read error: Connection reset by peer]
WarrenArden[m] has quit [Write error: connection closed]
ahoneybun[m] has quit [Remote host closed the connection]
MarcusE1W[m] has quit [Read error: Connection reset by peer]
sadness88267[m] has quit [Write error: connection closed]
erebion_muc[m] has quit [Write error: connection closed]
qzed has quit [Remote host closed the connection]
philtech[m] has quit [Remote host closed the connection]
farchord has quit [Read error: Connection reset by peer]
Nicholas[m] has quit [Read error: Connection reset by peer]
XMPPBridgeerebioneu[m] has quit [Read error: Connection reset by peer]
LiangQi[m] has quit [Read error: Connection reset by peer]
apple-corps[m] has quit [Write error: connection closed]
believeme234[m] has quit [Read error: Connection reset by peer]
Kobold[m] has quit [Write error: connection closed]
amstan has quit [Write error: connection closed]
roy[m] has quit [Read error: Connection reset by peer]
steveej[m] has quit [Read error: Connection reset by peer]
nirik has quit [Write error: connection closed]
Treibholz[m] has quit [Write error: connection closed]
Dantheman825[m] has quit [Write error: connection closed]
ppd[m] has quit [Write error: connection closed]
Ian[m] has quit [Read error: Connection reset by peer]
kuruczgy[m] has quit [Remote host closed the connection]
qwer12qwer[m] has quit [Read error: Connection reset by peer]
kibiz0r[m] has quit [Read error: Connection reset by peer]
hellfire7734club[m] has quit [Remote host closed the connection]
mynery[m] has quit [Remote host closed the connection]
GuidoMariaSerraFenaroli[m] has quit [Remote host closed the connection]
\[m] has quit [Write error: connection closed]
ednouu034[m] has quit [Remote host closed the connection]
june[m] has quit [Remote host closed the connection]
albsen[m] has quit [Read error: Connection reset by peer]
JeromedeBretagne[m] has quit [Read error: Connection reset by peer]
Tammieyem[m] has quit [Read error: Connection reset by peer]
DeepGaurav[m] has quit [Remote host closed the connection]
GurneyBuchanan[m] has quit [Read error: Connection reset by peer]
VctorGonzalo[m] has quit [Remote host closed the connection]
hfg477[m] has quit [Remote host closed the connection]
joel[m]12 has quit [Remote host closed the connection]
michaelmnemonic[m] has quit [Read error: Connection reset by peer]
jhovold has joined #aarch64-laptops
ravikant_ has joined #aarch64-laptops
jglathe_volterra has quit [Remote host closed the connection]
jglathe_volterra has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
travmurav_ has joined #aarch64-laptops
<travmurav_>
great, apparently the matrix bridge has died
<travmurav_>
just wrote a few messages that didn't get bridged, will duplicate:
<travmurav_>
Gurney Buchanan: as already mentioned, for sd-boot+dtbloader you just place dtbloaderaa64.efi into /EFI/systemd/drivers/dtbloaderaa64.efi, that's what we do for generic images for postmarketOS. then sd-boot will load the driver (unconditionally) and dtbloader will bail out gracefully if it cant' detect the device (so if it runs under u-boot uefi on rpi, it won't touch the already loaded dtb) - this should work fine for installer images so no u
<travmurav_>
so i.e. if your goal is to target EBBR (either working acpi or working DT provided by frimware -- rpi and other u-boot things) + WoA (broken acpi + DT provided in installer image) then with sd-boot placing dtbloader into the installer/live image and letting sd-boot load it should work "out of the box" for the user, that's currently the main usecase I target for dtbloader
<travmurav_>
If you start to dig deeper then there are more interesting problems and limitations of course: for example for uefi-secure-boot case it's not safe to load unverified dtb, dtbloader only provides minimal protection at this time as there was no interest yet, UKI with dtb embedded in the image verifies them properly. (however I personally think that there will be more and more need for board-specific detection logic and I don't agree that putting
<travmurav_>
and every bootlaoder separately is a nice way to go about it, especially if you consider value-add like vendor specific mac address detection dtbloader can provide)
chrisl has quit [Ping timeout: 480 seconds]
<travmurav_>
Then there is a problem of syncing dtb with the kernel version. Thoretically dtb should be both-ways-compatible so using latest dtb should generally work fine, but this is not ideal for rapidly developed platforms. UKI also wins here by embedding dtbs into the boot image. bl-spec has no provisions here for now, ideally we'd extend BLS with new "devicetree-dir" command like u-boot already has, make it "IMPLEMENTATION DEFINED" in the BLS, and le
<travmurav_>
read a efivar. Then user could either commit a efivar "DtbFile="qcom/x1e-blah.dtb" into nvram or let something like u-boot or dtbloader to save it as volatile, then sd-boot can find i.e. /boot/kernel-v99-dtbs/qcom/blah.dtb based on it and, if needed, call into u-boot/dtbloader via dt_fixup_protocol to get value-add (like it already does for the case when devicetree is specified explicitly in the config)
<travmurav_>
and then if you want to provide option for virtualizaiton with El2 via slbounce, the headache multiplies twofold :^)
chrisl has joined #aarch64-laptops
travmurav[m] has joined #aarch64-laptops
_xav_ has joined #aarch64-laptops
_xav_ has quit []
travmurav_ has left #aarch64-laptops [#aarch64-laptops]
hwpplayer1 has quit [Remote host closed the connection]
<jhovold>
- ath12k fw in linux-firmware-20250508 is broken (revert to previous version)
zdykstra has joined #aarch64-laptops
Tammieyem[m] has joined #aarch64-laptops
<Tammieyem[m]>
<jhovold> "https://lore.kernel.org/ath12k/8..."; <- perhaps you mentioned this before, but the email mentions that the fw should be updated. can that just be performed by installing the latest lenovo fw update?
<anthony25>
it is not a bios update or anything, it is the firmware located in /lib/firmware/ath12k
<anthony25>
it gets updated through your distributions with the linux-firmware package
Jasper[m] has joined #aarch64-laptops
<Jasper[m]>
Ohhhh they updated the wcn6855 boardfile aswell
<JensGlathe[m]>
Interesting
davidinux has joined #aarch64-laptops
hwpplayer1 has quit [Remote host closed the connection]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<GurneyBuchanan[m]>
travmurav: thanks for the thorough write-up!
<GurneyBuchanan[m]>
One question from the folks over in Fedora ARM - can we store the dtb-s in somewhere other than ESP? We are almost at the 30MB limit!
<travmurav[m]>
Currently dtbloader searches only on its own volume (so esp), if interop with a bootloader were to be implemented, the bootloader could look up anywhere (but not sure if BLS defines how)
<travmurav[m]>
But also 30MiB sounds quite small
<Eighth_Doctor>
That's the limit from the format spec
<travmurav[m]>
Hm let me ask a different question then I guess... which aa64 device you target must be installed using optical media disc? >:)
chrisl has joined #aarch64-laptops
ravikant_ has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
<GurneyBuchanan[m]>
_slaps USB external Bluray drive_ all of them!
<GurneyBuchanan[m]>
Joking aside - is the 30MB limit only present on disk images and not live ISOs?
ravikant_ has joined #aarch64-laptops
<maz>
phy_qcom_snps_eusb2 giving an ugly splat at boot time with lockdep enabled. rings any bell?
<bamse>
steev: what did{,n't} i do?
<bamse>
maz: yes, linaro folks have an open jira ticket on fixing the recursive phy usage...
<bamse>
maz: the retimer/redriver downstream of the phy is also modelled as a phy...and the phy framework doesn't account for that
<maz>
bamse: right. hopefully that's benign.
chrisl has joined #aarch64-laptops
<jhovold>
maz: yeah, it should be benign, but it prevents people from spotting locking issues with lockdep so really should have been fixed by now
<jhovold>
it was reported over a year ago, but the issue is even
ungeskriptet has quit [Remote host closed the connection]
kalebris_ has joined #aarch64-laptops
kalebris has quit [Ping timeout: 480 seconds]
kalebris_ is now known as kalebris
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
ravikant__ has joined #aarch64-laptops
ravikant_ has quit [Ping timeout: 480 seconds]
BrainWart has quit [Read error: Network is unreachable]
BrainWart has joined #aarch64-laptops
changwoo_ has quit [Read error: Network is unreachable]
changwoo_ has joined #aarch64-laptops
dianders has quit [Remote host closed the connection]
pundir has quit [Remote host closed the connection]
jbowen has quit [Remote host closed the connection]
pundir has joined #aarch64-laptops
jbowen has joined #aarch64-laptops
dianders has joined #aarch64-laptops
gwolf has quit [Remote host closed the connection]
chrisl has joined #aarch64-laptops
<steev>
bamse: dell x1e, i thought i remembered you submitting one of them
logan2611 has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<bamse>
steev: xps13 and i think alexander(?) beat me to it
gwolf has joined #aarch64-laptops
<valpackett>
is cpufreq a big impact on idle thermals & battery drain?
<steev>
if you're running the cpu at full speed all the time, yes
<janrinze>
On the Lenovo thinkpad x13s I can install Ubuntu but debian fails to boot after installing. There is unfortunately not much to go on since the screen goes black and then after a bit it reboots..
<steev>
did you follow the wiki?
<steev>
if it's screen going black and then rebooting though, it's likely you're not loading the correct dtb
ravikant__ has quit [Ping timeout: 480 seconds]
<steev>
which kernel version as well? I’ve noticed with Debian’s 6.14, I think there is an serror when the crypto tests run
<steev>
I workaround that by passing modprobe.blacklist=qcrypto
<janrinze>
I followed the wiki but I had Ubuntu installed before. So the grub question never happened. I think I might need to remove the old grub first?
<janrinze>
Let's try the modprobe.blacklist=qcrypto first ..
<janrinze>
I think it's the missing dtb
<steev>
if you aren't using an encrypted rootfs
<steev>
you can pass the dtb in via grub, just edit the entry you want to boot and add at the bottom - devicetree /usr/lib/linux-image-6.x.x-arm64/qcom/sc8280xp-lenovo-thinkpad-x13s.dtb
<janrinze>
no encrypted rootfs
<steev>
the linux-image... is whatever version of the kernel you have installed
<janrinze>
I used the latest debian-testing-arm64-netinst.iso. I'll check using Ubuntu from a USB drive. Then I can also modify the grub cfg
<steev>
cheat sheet: the version number is in there already :)
<steev>
the kernel and initrd use the version number in their names
<janrinze>
yes, but i can't see much from win11 :-D
<steev>
oh, when you say fails to boot, you mean its not even getting to grub?
<steev>
if you are getting to grub, you can just hit `e` to edit the entry to test
<janrinze>
grub runs, boots the kernel and a few lines are printed.. black screen .. reboot
<steev>
yeah, you should be able to hit e there to edit the entry and add the devicetree line
<janrinze>
Yup that could work too.
<steev>
that's what i was suggesting
<steev>
also check what the kernel command line is set to
<janrinze>
Okay I got booting linux, loading ramdisk .. now a bluish dark screen..
<janrinze>
and no response, cannot switch to a console either.
chrisl has joined #aarch64-laptops
<steev>
well, we have some progress :D
<steev>
you can hold the power button down for ~10-20 seconds to power it off
<janrinze>
that indeed. Yup reboot with powercycle
<valpackett>
huh actually one difference with the latitude 7455 vs inspiron 7441 is that the battery on 7455 just works
<steev>
janrinze: can you show the kernel command line you have set?
chrisl has quit [Ping timeout: 480 seconds]
<janrinze>
can't see the kernel commandline, I installed everything on a NVME partition. I think it's better to try on a USB disk first. That will allow me to access everything from the linux machine that I use for this chat.
<craftyguy>
cat /proc/cmdline
<steev>
they aren't getting far enough for that :)
<craftyguy>
ahh, sorry
<janrinze>
:-D
<steev>
i was thinking a picture, but if you can boot it from a usb and mount and grub config should have the info
ellyq has joined #aarch64-laptops
<anthony25>
you can edit the grub entry config by pressing "e"
ellyq has quit []
<anthony25>
and you should be able to see the all cmdline
<janrinze>
The Ubuntu kernel does DP-alt too :-D That's a plus. linux/boot/vmlinuz-6.12.27-arm64 root=UUID=d1ed8f95-9c72-437e-b28f-a45e16edd8fa ro arm64.nopauth quiet
<janrinze>
Had to fix ssh on the Ubuntu install first..
<janrinze>
The initrd is there too on the Debian grub, just did not copy that line.
<anthony25>
you can copy Ubuntu's dtb and use it to boot debian
<janrinze>
can try.
<janrinze>
Also it looks like the Ubuntu kernel is newer. I might just move the kernel and its modules over to Debian..
<anthony25>
this and I don't know if Ubuntu applies some patches for the x13s
Treibholz[m] has joined #aarch64-laptops
<Treibholz[m]>
just copy sc8280xp-lenovo-thinkpad-x13s.dtb to /boot/efi
<Treibholz[m]>
NO!
<Treibholz[m]>
the ubuntu-kernel does not work on debian and vice versa (at least not OOTB)
<janrinze>
Treibholz[m]: Well.. transplanting kernels does require a bit more than just copying the kernel image.
<anthony25>
well at least if you copy the kernel image, initrd and modules, you'll see if it reboots or not, or fail later
<janrinze>
Treibholz[m]: done it before on other platforms..
<anthony25>
but yes, try the dtb first, it's easy to swap
<Treibholz[m]>
janrinze: yes... Ubuntu uses different compression for modules (and firmware). so your "initrd system" and "real system" will not be compatible.
<janrinze>
No, initrd is not compatible. So I need to create an extra initrd.
<janrinze>
Treibholz[m]: That copy of the dtb is already in that partition as described in the guide.
<steev>
you would want to add the clk_ignore_unused and pd_ignore_unused to the debian one
<Treibholz[m]>
yes, but don't add the crashkernel stuff.
<janrinze>
So.. copying a bit of stuff around and now I have Debian 13 running..
<janrinze>
This is a bit irreproducible. =-O
<Treibholz[m]>
\o/
<Treibholz[m]>
janrinze: to make my life easier, I just manually installed ubuntu-x13s-settings and ubuntu-x13s-settings-nogrub on my debian here.
<steev>
probably need to update the debian wiki to add those options to the kernel command line when using the installer (and they should carry over to the installed system iirc)
<steev>
janrinze: you should have clk_ignore_unused and pd_ignore_unused at the end too
<janrinze>
Probably moving the dtb to /boot helped.
<steev>
copying the correct dtb to the efi partition does help too, but that gets overridden by the devicetree line
<janrinze>
Now, let's get a newer kernel working. It's clear that 6.14 has far more features than 6.12
<Treibholz[m]>
janrinze: two days ago, I was exactly at that point.
<steev>
the x13s support in the kernel hasn't changed a ton
<janrinze>
Treibholz[m]: I had a 'franken-debian-ubuntu' on a USB disk and it did not feel right. so I wanted to do a full Debian install from scratch on the NVME.
<Treibholz[m]>
janrinze: actually, i have not found anything.
<steev>
we are still waiting on qcom/lenovo to submit the venus firmware
<steev>
found anything what
<steev>
there are improvements to the drivers (but aren't bug fixes so not backported to stable kernels), and that always helps
<Treibholz[m]>
steev: on my ubuntu venus-dec was quite unstable, AND needed more battery... :-(
<steev>
yeah, there are definitely still some bugs with it :D
<steev>
the debian kernel does not have the venus patches applied
<janrinze>
I'm neither gaming nor using it for youtube and such :-D
<janrinze>
Timing buffered disk reads: 7944 MB in 3.00 seconds = 2647.46 MB/sec .. Not bad!
<Treibholz[m]>
janrinze: was that bad on your ubuntu aswell? Because disk-io was horrible slow here.
chrisl has joined #aarch64-laptops
<janrinze>
Treibholz[m]: Timing buffered disk reads: 416 MB in 3.00 seconds = 138.52 MB/sec for the USB disk
chrisl has quit [Ping timeout: 480 seconds]
<janrinze>
Treibholz[m]: Timing buffered disk reads: 7562 MB in 3.00 seconds = 2520.57 MB/sec for the NVME disk under the franken-debian-ubuntu.. So not bad either. But the rootfs is the USB disk.
<janrinze>
steev: At least it boots consistently! that's a plus.
<steev>
janrinze: my x13s is my daily driver, and while i'm not on debian, i'm on kali which is debian testing with extra steps
<janrinze>
steev: looking at the performance and the way it handles itself, I can understand completely!
<steev>
could the battery life be better? yes. is it acceptable for my needs? also yes
<janrinze>
What's your average battery-life ?
<Treibholz[m]>
here it's about 1h per 10%
<steev>
i can't really answer that as i don't pay close enough attention
<steev>
it also depends on which kernel i'm running :D
<Treibholz[m]>
would be nice, if suspend worked properly... maybe I'll try suspend-to-disk, if I can live with it...
<steev>
what do you mean if it worked properly?
<Treibholz[m]>
steev: it's not "really" suspended.
<steev>
it doesn't get into the lowest power states that it could, but it should suspend
<janrinze>
Treibholz[m]: so with your average usage you get almost 10 hours, that's pretty okay, i guess..
<steev>
if i'm just working on docs and such, then yeah, i get about 10-12 hours, but if i'm building kali images, its lower because of compressing large files
<Treibholz[m]>
janrinze: for some reason my device has an "undocumented feature". As long as an OS is running (Linux or Windows), it only charges to ~80%.
<steev>
interesting
<steev>
latest bios?
<janrinze>
Sounds good to me. I know it does easily run out of power when left in 'suspend' in my backpack overnight..
<valpackett>
Treibholz[m]: hm, that should be controllable in windows somewhere?
<Treibholz[m]>
which is somehow cool, as there is no "manual" way of limiting the charge.
<valpackett>
on my x86 laptop i have /sys/class/power_supply/BAT*/charge_control_*_threshold
<Treibholz[m]>
valpackett: Then I'm too stupid to find that setting.
<janrinze>
Treibholz[m]: I actually prefer that the firmware takes care of the battery and therefore allow Lenovo to optimize how the battery is charged etc..
<steev>
we do not have that on qualcomm
<Treibholz[m]>
valpackett: yes... some x86 thinkpads have that.
<steev>
maybe we would if we had ec, but idk
<Treibholz[m]>
janrinze: how can you allow/disallow that?
<Treibholz[m]>
steev: last time I check: yes. latest bios.
<janrinze>
Treibholz[m]: no idea. I guess firmware is 'black magic' ;-)
* Treibholz[m]
hates magic of all colors...
<steev>
i know my math skills... i'll let someone else do the maths
<Treibholz[m]>
magic is just technology, nobody understands.
<valpackett>
meanwhile the one thing i couldn't get to work so far on the dell 7455 is the touchscreen ><
<Treibholz[m]>
so, now I'll try suspend-to-disk, walk the dogs and then check if it resumes properly :-)
<valpackett>
it's getting NACK on the i2c bus and i2cdetect shows weird output (not all dashes but looots of blank space)
<valpackett>
the pin config should be identical to xps according to DSDT but it's not working
<janrinze>
steev: I saw that the NVME is tucked away under some cooling plates. Do you know if anyone has been able to replace the disk with something bigger?
<janrinze>
I replaced the SSD of my chromebook and that now has 1TB. That made a big difference.
<steev>
janrinze: i have 2TB in mine
chrisl has joined #aarch64-laptops
<JensGlathe[m]>
<valpackett> "the pin config should be..." <- The DSDT also specifies the i2c bus... is it alone on i2c8?
<steev>
and in the T14s
<Jasper[m]>
@janrinze x13s? SN770M works perfectly
<steev>
with adapter*
<Jasper[m]>
You do need an adapter to extend from 2230 to 2242 though but they are cheap
<steev>
that is exactly what i am using here
<JensGlathe[m]>
If it is i2c8, you need to enable qupv3_1 too
<janrinze>
Jasper[m]: Thanks!
chrisl has quit [Ping timeout: 480 seconds]
<janrinze>
And.. this x13s is 70.5 x the speed of my old Acorn Risc PC (SA110) :-D
misyl_ has quit [Remote host closed the connection]
jglathe_angrybox has quit [Remote host closed the connection]
maz has quit [Read error: Connection reset by peer]
maz has joined #aarch64-laptops
maz is now known as Guest16424
<valpackett>
JensGlathe[m]: qupv3_[012] have been enabled all along, copied from other Dells
<Treibholz[m]>
<Treibholz[m]> "so, now I'll try suspend-to-disk..." <- nope. resume from hibernate was not successful - frozen system. - AND it took longer than a normal boot + start all applications again would take.
jglathe_angrybox has joined #aarch64-laptops
<janrinze>
MESA is not hardware accelerated.. That's different. Any suggestions on that?
<hogliux>
kuruczgy[m]: Thanks to your nix camera branch, I've got a (fairly greenish) camera working. But I can't get it to flip the orientation. In your issue you mention "rotation = <180>;" but that does do the trick.
<hogliux>
kuruczgy[m]: Anything I'm missing
<hogliux>
does do the trick=does *not* do the trick
<hogliux>
?
hogliux has quit [Quit: Leaving]
ravikant_ has joined #aarch64-laptops
hogliux has joined #aarch64-laptops
ravikant_ has quit []
<Treibholz[m]>
I don't understand, why my camera works fine in qcam, but flickers like hell in firefox...
jglathe_volterra has quit [Remote host closed the connection]
<janrinze>
steev: you might have a point there, initramfs when rootfs is not mounted yet.
<steev>
robclark: does the zap fw not get attempted every time like the sqe?
<janrinze>
steev: also make sure that the script is executable.
<steev>
si
<janrinze>
also grub.cfg can 'forget' the devicetree line. (found out when it stopped booting after an update.)
chrisl has joined #aarch64-laptops
<alexVinarskis[m]>
janrinze: ubuntu auto adds the dtb line, so probably another hook you can borrow
<robclark>
steev: things get into a weird state if you have sqe/gmu in initrd but not zap.. I've not had a chance to look at that yet, but my recommendation is to have none of the fw in initrd
<steev>
robclark: oh interesting
* robclark
recently sent a patch to remove all the MODULE_FIRMWARE()s from the driver so dracut/etc doesn't try to copy fw into initrd
<steev>
alexVinarskis[m]: its a patch afaik
<steev>
robclark: i did see that patch
chrisl has quit [Ping timeout: 480 seconds]
<janrinze>
Whooohooo! \o/ glmark2 is now 20x faster!
<janrinze>
steev: thanks!
<robclark>
\o/
jhovold has quit [Ping timeout: 480 seconds]
<valpackett>
JensGlathe[m]: lmao, yes, the 0 is patched into a 0x10 in a separate piece of aml (same on the xps)
<valpackett>
janrinze: dtbloader exists, you can forget about devicetree lines in boot loaders :p
hwpplayer1 has quit [Remote host closed the connection]