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 [resistance.oftc.net weber.oftc.net]
systwi has quit [resistance.oftc.net weber.oftc.net]
Lucanis0 has quit [resistance.oftc.net weber.oftc.net]
mjeanson has quit [resistance.oftc.net weber.oftc.net]
bryanodonoghue has quit [resistance.oftc.net weber.oftc.net]
echanude has quit [resistance.oftc.net weber.oftc.net]
schaeffer has quit [resistance.oftc.net weber.oftc.net]
pzc has quit [resistance.oftc.net weber.oftc.net]
arnd has quit [resistance.oftc.net weber.oftc.net]
pjones has quit [resistance.oftc.net weber.oftc.net]
exit70 has quit [resistance.oftc.net weber.oftc.net]
ldts__ has quit [resistance.oftc.net weber.oftc.net]
olv has quit [resistance.oftc.net weber.oftc.net]
rfs613 has quit [resistance.oftc.net weber.oftc.net]
broonie has quit [resistance.oftc.net weber.oftc.net]
dianders has quit [resistance.oftc.net weber.oftc.net]
ardb has quit [resistance.oftc.net weber.oftc.net]
_alice has quit [resistance.oftc.net weber.oftc.net]
jhugo___ has quit [resistance.oftc.net weber.oftc.net]
robher has quit [resistance.oftc.net weber.oftc.net]
eric_engestrom has quit [resistance.oftc.net weber.oftc.net]
dgilmore has quit [resistance.oftc.net weber.oftc.net]
pundir has quit [resistance.oftc.net weber.oftc.net]
steev has quit [resistance.oftc.net weber.oftc.net]
ndec has quit [resistance.oftc.net weber.oftc.net]
lool has quit [resistance.oftc.net weber.oftc.net]
CosmicPenguin has quit [resistance.oftc.net weber.oftc.net]
bamse has quit [resistance.oftc.net weber.oftc.net]
<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
<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 grub.cfg.new 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 grub.cfg.new.
<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>
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>
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.
<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.
<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>
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
<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.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 :)