ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630)
leezu has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
mayco has quit [Remote host closed the connection]
jhovold has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
rpirea has quit []
derzahl has quit []
systwi has quit []
Lucanis0 has quit []
mjeanson has quit []
bryanodonoghue has quit []
echanude has quit []
schaeffer has quit []
pzc has quit []
arnd has quit []
pjones has quit []
exit70 has quit []
ldts__ has quit []
olv has quit []
rfs613 has quit []
broonie has quit []
dianders has quit []
ardb has quit []
_alice has quit []
jhugo___ has quit []
robher has quit []
eric_engestrom has quit []
dgilmore has quit []
pundir has quit []
steev has quit []
ndec has quit []
lool has quit []
CosmicPenguin has quit []
bamse has quit []
bryanodonoghue has joined #aarch64-laptops
schaeffer has joined #aarch64-laptops
eric_engestrom has joined #aarch64-laptops
rfs613 has joined #aarch64-laptops
systwi has joined #aarch64-laptops
broonie has joined #aarch64-laptops
dianders has joined #aarch64-laptops
_alice has joined #aarch64-laptops
ardb has joined #aarch64-laptops
robher has joined #aarch64-laptops
jhugo___ has joined #aarch64-laptops
pundir has joined #aarch64-laptops
dgilmore has joined #aarch64-laptops
ndec has joined #aarch64-laptops
CosmicPenguin has joined #aarch64-laptops
lool has joined #aarch64-laptops
mjeanson has joined #aarch64-laptops
derzahl has joined #aarch64-laptops
pzc has joined #aarch64-laptops
arnd has joined #aarch64-laptops
echanude has joined #aarch64-laptops
pjones has joined #aarch64-laptops
exit70 has joined #aarch64-laptops
olv has joined #aarch64-laptops
steev has joined #aarch64-laptops
ldts__ has joined #aarch64-laptops
Lucanis0 has joined #aarch64-laptops
bamse has joined #aarch64-laptops
bamse is now known as Guest9757
iivanov has quit [Quit: - Chat comfortably. Anywhere.]
iivanov has joined #aarch64-laptops
<javierm> leezu:, the fix is heading towards v6.2.y apparently
godvino has joined #aarch64-laptops
phire has quit [Ping timeout: 480 seconds]
phire has joined #aarch64-laptops
<rfs613> okay, i have installed the newer board-2.bin from the git repo, along with the other files in same directory. But doest
<rfs613> *doesn't seem to load:
<rfs613> [ 3.284427] ath11k_pci 0006:01:00.0: failed to fetch board data for bus=pci,vendor=17cb,device=1103,subsystem-vendor=17cb,subsystem-device=0108,qmi-chip-id=2,qmi-board-id=140 from ath11k/WCN6855/hw2.1/board-2.bin
baozich has joined #aarch64-laptops
<rfs613> fe76aa59c6ff5470d724eb10b3bdeaa2 /lib/firmware/ath11k/WCN6855/hw2.1/board-2.bin
godvino has quit [Quit: WeeChat 3.6]
baozich has quit [Ping timeout: 480 seconds]
<steev> steev@wintermute:~$ md5sum /lib/firmware/ath11k/WCN6855/hw2.0/board-2.bin
<steev> 22e2c914f374c3832a7ca6836c3b3f83 /lib/firmware/ath11k/WCN6855/hw2.0/board-2.bin (hw2.1 is a symlink to 2.0 in my install)
phire has quit [Ping timeout: 480 seconds]
<rfs613> yep i have the same hw2.1 -> 2.0 symlink
phire has joined #aarch64-laptops
<steev> steev@wintermute:~/git/x13s-alarm/x13s-firmware$ md5sum board-2.bin
<steev> 22e2c914f374c3832a7ca6836c3b3f83 board-2.bin
<steev> steev@wintermute:~/git/ath11k-firmware/WCN6855/hw2.0$ md5sum board-2.bin
<steev> 22e2c914f374c3832a7ca6836c3b3f83 board-2.bin
<steev> seems like yours didn't get written to it
<rfs613> i cloned linux-firmware from your earlier link, that's where i got fe76aa59c6ff5470d724eb10b3bdeaa2 board-2.bin
<steev> linux-firmware would be upstream, and doesn't have it yet afaik
<rfs613> right, let me find the right repo then...
<ndec> juergh: so back to my grub / dtb thing.. how does grub load the dtb? I am not seeing anything in the grub config related to dtb.
<steev> rfs613: si, or ironrobin's x13s-alarm one which has just the important to us firmwares in it (that aren't in linux-firmware)
<juergh> @ndec there's some flash-kernel voodoo that copies the dtb to the EFI partitions and grub.cfg has devicetree /boot/dtb-6.2.0-1003-laptop
<juergh> ndec ^^
<juergh> IIRC grub adds the devicetree line automatically if there's a matching dtb in /boot
<juergh> err no. flash-kernel copies to /boot, not the EFI partition.
<rfs613> steev: i got the same hash as you now, and the 'failed to fetch board data' message is gone.
<rfs613> but wifi still not coming up, there are other firmwares I guess I am missing
<steev> rfs613: the others should already be in the folder, but you need the amss.bin and m3.bin files too
<steev> ls /lib/firmware/ath11k/WCN6855/hw2.0
<steev> amss.bin board-2.bin m3.bin Notice.txt regdb.bin
Guest9757 is now known as bamse
<rfs613> steev: cool that was it, wifi is working again, thanks!
<ndec> juergh: i am not seeing the devicetree command in my grub config..
<rfs613> i still see a bunch of complaints about missing a666_sqe.fw, and also one about qcom/sc8280xp/SC8280XP-LENOVO-X13S-tplg.bin
<rfs613> sorry, small typo, a660_sqe.fw
<rfs613> seems that one is both in firmware-qcom-soc and also firmware-lenovo packages
<rfs613> probably neither is recent enough ;-)
laine has joined #aarch64-laptops
<juergh> ndec: hrm. do you have dtbs in /boot? like /boot/dtb-6.2.0-1003-laptop?
<ndec> yes, it's there.
<ndec> it's a link to some real dtb in /boot/dtbs
<ndec> hmm. i mounted my ubuntu partition (booting a local debian install). i can see which has it, but grub.cfg does not.
<juergh> hmm. I wonder if something went wrong during initial grub-update and grub.cfg wasn't replaced with
<ndec> the only diff between the 2 files are the devicetree commands in each section..
<ndec> note that i didn't have a 'normal' setup, since I have 3 or 4 install in different partitions. i also had 3 different entries in the EFI bootmgr.
<ndec> after running the installer it removed all my efi bootmgr entries (even windows!)
<juergh> ugg
<juergh> we try to be like MS, one OS to rule them all...
<ndec> juergh: so, what should I do, try to reinstall? or fix up the grub config in chroot?
<steev> seems like cp'ing the .new to .cfg should fix it up
<juergh> yeah, give that a try first
<steev> note: you can always manually edit the grub boot command to point to the correct devicetree file if needed
<steev> that's how i test the different kernels, i keep the working dtb installed and just manually add devicetree /usr/lib/linux-image-$kverimtesting/qcom/sc8280xp-lenovo-thinkpad-x13s.dtb when i go to boot test
svarbanov has joined #aarch64-laptops
<calebccff> steev: i've kiiinda ignored audio on the c630, i usually use bluetooth... I'm running Arch on mine with pipewire and audio has never worked. I am certain that the UCM configs in upstream for the c630 don't behave with pw
<steev> they used to
svarbanov_ has quit [Remote host closed the connection]
<steev> then someone added 50 billion more multimediaX entries and now it doesn't
<calebccff> we do have some pretty nice UCM confs for the phones, we had to work around some weirdness with how pulseaudio treats UCM confs too... Probably rewriting the c630 confs based on these would help?
<calebccff> lol nothing coppes with the shear volume of mixer controls on these codecs, it's ridiculous
<calebccff> copes*
<steev> yeah....
derzahl has quit [Ping timeout: 480 seconds]
<steev> the phone one looks similar to how the thinkpad does it now, so it could just be that c630 needs updating
<calebccff> it probably does...
<steev> i was excited to see the patches from srini for popping and then.... just silence
<calebccff> steev: apparently the ConflictingDevices directive isn't handled properly by pa/pw:
<calebccff> at some point it would be nice to have some good generic ucm confs for the sdm845 / wcd934x stuff, we could easily standardise it
<steev> si! that would be nice
derzahl has joined #aarch64-laptops
<ndec> juergh: that didn't work quite well.. so i am reinstalling it again now.
<ndec> juergh: ok, now it works, and the installer ran very quickly this time..
<xnox> ndec: juergh: installer doesn't remove any entries. It tries to append ubuntu one, and reorder.
<xnox> that seems to trigger purge of all entries
<ndec> i definitely lost entries :)
<xnox> and then one needs to boot to windows-boot-mgr from grub-menu selecting windows.... and then as if by magic, (some) entries come back (for example native windows one)
<xnox> and re-adding entries after that seems to persist
<xnox> i don't know how or why, and sort of tempted to run the efi test suite on it
<ndec> yes, the windows one reappeared, after booting once into windows
<ndec> graphics uses llvmpipe after the installer is done. is that expected?
<xnox> ndec: installer image was not respun with new kernel & mesa; but apt update; apt fullupgrade; and reboot should bring you accelerated stack
<xnox> (and increment our PPA download counts ;-) )
<ndec> ok, i am doing that now.
<xnox> ndec: the variables "bug" is mentioned in the quick-start guide of the ppa, but it is very weird.
<xnox> ndec: note that gives accelerated stack for like epiphany browser from .deb with like webgl aqvarium. I'm working on making an x13s specific gnome snap, to bring that to the firefox snap as well.
<ndec> where is that quick start guide?
<xnox> ah, but i don't mention efi variables explicitly, as that's the steps to recover bitlocker too
<ndec> right, the one I knew, but I didn't see anything about the variables issues. but no big deal.
<xnox> updated the bitlocker recovery to call out it will restore efi boot menu entries
<juergh> xnox maybe we should make a real meas (lunar version + patches) rather that TOT that's currently in the PPA.
<juergh> s/meas/mesa/
<juergh> and then shove it into lunar proper
<ndec> juergh: xnox : after the dist upgrade, mesa uses freedreno. and reboot worked :)
* juergh wipes his forehead
<ndec> heh
<ndec> since the a690 patches have been merged in mesa/master, i think it would indeed be nice to backport them in lunar.
<xnox> juergh: how destabilising would that be to raspi? because as far as i know we possibly currenty have mesa+patches to get accel on raspi in lunar, no?
<xnox> cause mesa:arm64 is used at least on raspi these days.
<ndec> it's completely orthogonal i believe
<juergh> There are currently no raspi patches in mesa AFAIK.
<ndec> it's 2 or 3 patches which only impact the freedreno driver.
<xnox> nice, yeah, i'm all for integrating x13s patches into stock ubuntu, makes everything easier.
<juergh> yeah, I'll take a crack at it.
<ndec> i think the alsa-ucm-conf patches are another candidate then
<ndec> but we should make sure we have the most recent versions
<xnox> juergh: totaly falls under SRU HWE exception
<juergh> ndec yes. but I haven't gotten audio to work yet. still on my list.
godvino has joined #aarch64-laptops
godvino has quit [Quit: WeeChat 3.6]
<steev> ndec:
<steev> the patch is on top, but you'll need to bump your changelog
<steev> the only patch i haven't added from srini is the one that sets default volumes
svarbanov has quit [Ping timeout: 480 seconds]
<xnox> horay, got 60 fps in firefox webgl aquarium, will ask desktop team to enable my forked snap, and publish it to the store, to then enable firefox gl
<steev> \o/
aguslr has joined #aarch64-laptops
aguslr has quit [Remote host closed the connection]
<_`[m]1> oh my so ubuntu shouleld boot? I installed it but then it got stuck in boot
<_`[m]1> I thought it was borked and I've been seeing up arch since lol
<clover[m]> 6.3.0-rc5-4-x13s+ booting steev, anything new with this one?
<steev> yeah... it has a hack i'm working on for the bluetooth to point to the b8c file directly, it won't be accepted upstream for a good long while as tim still hasn't sent v3
<steev> although mani just sent v4 of the pci suspend/resume stuff, so i probably need to pull that in
<steev> other than the hack though, i think it's just the same stuff as rc4, but if new revisions of patch sets came in, they were bumped
<steev> things will be slowing down, most likely, as we get closer and closer to stuff being in mainline; i think we're only around 38 patches on top of -next currently
<steev> but we still need to figure out why the touch screen doesn't bind properly, so users don't need to use the udev rule, need orientation switching...
<steev> audio can sometimes still randomly stop working, i see that most often by logging out and back in
<steev> oh, actually yeah, this has the patches that seem to still be being argued about on the mailing list from abelvesa for letting us punt pd_ignore_unused
ema has quit [Quit: leaving]
ema has joined #aarch64-laptops
godvino has joined #aarch64-laptops
svarbanov has joined #aarch64-laptops
hightower2 has joined #aarch64-laptops
godvino has quit [Ping timeout: 480 seconds]
<clover[m]> Do I need any different BT files?
<javierm> steev: what's the touchscreen driver out of interest and what udev rule do you need ?
<steev> clover[m]: no, same files should be fine; just instead of defaulting to .bin or the 8c symlink, it should use the b8c file
<steev> the .8c symlinked file can go away
<steev> javierm: uhhhh... i2c-hid? i think, or multitouch - the udev rule is clover[m]'s thing -
<steev> i'm actually fine with it being "not bound" by default because i don't use it as a touchscreen anyway, but i know some people do.
<javierm> steev: interesting. This is with DTB or ACPI ?
<steev> dtb
<steev> i honestly don't think i've ever done an acpi booted linux on the thinkpad
mohamexiety has joined #aarch64-laptops
<javierm> steev: what a mystery :) And the others "hid-over-i2c" devices bind correctly? I see that there a few (i.e: a keyboard)
<steev> yessir, it's only the touch screen
<javierm> steev: what's the latest version of the DTS ?
<steev> heck no, either linux-6.2.y or the 6.3.0-rc5
<steev> v6.3-rc5
<steev> i haven't used next in a bit, i need to, but it's the same there. there haven't been any changes to the touchscreen bits in quite a while, i don't think
<javierm> steev: yeah, looking at that now but can't see anything evident. So strange
<steev> :)
<steev> maybe we need an input-enable in the pins?
<steev> the only thing i can really compare to is the c630, and it has input-enable, but it also has the pin definitions as "active" instead of default?
<javierm> steev: but then why it would work when bound using the sysfs interface?
<javierm> that's the part that confuses me
<steev> no idea, but as soon as we do that echo we get
<steev> [78541.468174] input: hid-over-i2c 04F3:2FE6 as /devices/platform/soc@0/9c0000.geniqup/990000.i2c/i2c-4/4-0010/0018:04F3:2FE6.0003/input/input12
<steev> [78541.468749] input: hid-over-i2c 04F3:2FE6 UNKNOWN as /devices/platform/soc@0/9c0000.geniqup/990000.i2c/i2c-4/4-0010/0018:04F3:2FE6.0003/input/input13
<steev> [78541.469213] input: hid-over-i2c 04F3:2FE6 UNKNOWN as /devices/platform/soc@0/9c0000.geniqup/990000.i2c/i2c-4/4-0010/0018:04F3:2FE6.0003/input/input14
<steev> [78541.469343] hid-multitouch 0018:04F3:2FE6.0003: input,hidraw2: I2C HID v1.00 Device [hid-over-i2c 04F3:2FE6] on 4-0010
<steev> [78541.470017] i2c_hid_of 4-0010: i2c_hid_get_input: IRQ triggered but there's no data
<javierm> steev: and anything interesting in the kernel log when booted but without doing that bind from user-space ?
<steev> [ 1.097275] geni_se_qup 9c0000.geniqup: Adding to iommu group 1 is the only thing remotely related
<steev> there's no mention of the i2c device at all until the bind
<javierm> steev: and you have that driver as a module or built-in ?
<javierm> I wonder if could be again an issue of probe deferral
<steev> looks like its built in
<steev> CONFIG_I2C_HID_OF=y
<steev> it has been like this for as long as we've had the device trees
<javierm> steev: I'm so curious to know what's going on here :)
<steev> if i even remotely knew how to debug this crap, i'd do so
<steev> pretty sure clover[m] was the one who even discovered the bind bit
<javierm> steev: I believe the first step is figuring out whether i2c_hid_of_probe() is even called for that device, it should because should match with compatible = "hid-over-i2c"
<javierm> then determine when if returns early, either in that function or i2c_hid_core_probe()
<javierm> my guess is that either is failing due a missing resource and returning with -EPROBE_DEFER (although then I don't know why the kernel doesn't try to re-probe it)
<javierm> or it silently fails, for example if i2c_hid_core_power_up() returns an error
<steev> clover[m]: ^^ there's your homework assignment :P
<javierm> hmm, that was a bad example because i2c_hid_of_power_up() can only fail if regulator_bulk_enable() fails and a warning is printed there
<javierm> but you get the idea :)
<steev> i say we make clover[m] do it because he is the weirdo that likes touch screens :P
<javierm> steev: hehe, I also prefer the trackpoint on thinkpads
<steev> i do too, but thats' because sometimes i have to wear a wrist brace that absolutely insists on rubbing against the touchpad
janrinze has joined #aarch64-laptops
<javierm> steev: going to sleep. If you find the issue please share, just for curiosity
<steev> :) no worries, i'm not blaming anyone or anything like that, was just mentioning things i could think of off the top of my head that we still need to figure out :)
<javierm> steev: super interesting bug tbh :)