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)
<steev>
yeah... because usually the developer is running some stable version of ubuntu which doesn't have "up to date" packages
<amstan>
if that, it's probably windows or mac through
<steev>
that too
<steev>
okay, time to figure out what half this stuff in the code review means
svarbanov has quit [Remote host closed the connection]
svarbanov has joined #aarch64-laptops
<steev>
jhovold: to expand on my email - when setting gpio121, i end up with this splat, and then bluetooth just keeps crashing - https://paste.debian.net/1273553/ - it could just be some of my changes in the driver (i haven't done those just yet), but for now, the only way i have working bluetooth is with cts's pin set to 122 for now
<jhovold>
steev: that's because you're triggering a separate regression in 6.3-rc1 due to the serial driver gaining DMA support.
<steev>
jhovold: it has happened since before 6.3
<jhovold>
I posted a number of fixes for the fallout from the DMA support the other day, and will include in my 6.3-rc1 branch in a bit
<steev>
hm, i thought i had those...
<jhovold>
that splat definitely did not happen with 6.2, which lacked dma support. Perhaps you saw it with linux-next, though
<steev>
apparently i backed those out
<steev>
i think youare correct...
<steev>
and i didn't test 6.2 with the correct pin
<steev>
re-applied your serials, let me re-test again
<steev>
jhovold: oh wow, yeah that was it, okay. additionally, i'm able to connect my airpods now, which i wasn't able to before. still need to make the driver changes but that's a tomorrow thing after work, if i can get the rpi testing done... which is hit or miss considering how slow they are
<steev>
jhovold: qca2066 and wcn6855 are the same chip, fwiw
<steev>
just... different teams, i guess
<jhovold>
ok, so that other series was adding support for qca2066, i didn't look that closely at it, just noticed the firmware naming issue you mentioned
<jhovold>
thought it was needed on top to load the patch files or something
<jhovold>
ok, so that one is definitely incomplete for wcn6855
<jhovold>
e.g. no power handling
<steev>
i *thought* he was gonna incorporate my changes, but that didn't happen, which is why v5 of mine sat for so long - but i'll do a v6 with your requested changes as well (which has the power handling correct, and is what i have pushed)
<calebccff>
UFS doesn't seem to be too happy on c630 with 6.3-rc1, anyone beat me to the punch here? https://p.calebs.dev/00b47a@raw
<calebccff>
hmm.. af00000.clock-controllerplatform: wait for supplier /soc@0/phy@88e9000/dp-phy@88ea200
<jhovold>
calebccff: i think i saw something about a clock devlink regression, saravanna has posted a patch
<calebccff>
jhovold: ah nice, thanks!
<calebccff>
i've also realised that the qmp combo phy is compiled as a module in my kernel and isn't in the ramdisk,, so that probably doesn't help either heh
<jhovold>
heh, yeah, that seems more likely to be the cause here :)
srinik has quit [Killed (NickServ (Too many failed password attempts.))]
srinik has joined #aarch64-laptops
<jhovold>
steev and anyone else using my wip branches: I've just pushed a new branch based on 6.3-rc1 here:
<jhovold>
Changes since the previous 6.2 branch include:
<jhovold>
- new
<jhovold>
- bluetooth support
<jhovold>
- audio jack detection (requires updated ucm2)
<jhovold>
- pcie basic system suspend support
<jhovold>
- serial console hang fix
<jhovold>
- serial dma support fixes
<jhovold>
- drm bind error handling fixes
<jhovold>
- drm info leak fix
<jhovold>
- cpumask fixes
<jhovold>
- scm bogus irq error fix
<jhovold>
- updated
<jhovold>
- audio dts fixes (v1)
<jhovold>
- uefi sec app (v3)
<jhovold>
- gpu runtime pm fixes (v2)
<jhovold>
- dropped
<jhovold>
- drm hotplug workaround as early dp events no longer crash the driver
<jhovold>
- new known issues
<jhovold>
- usb/dp device link errors
<jhovold>
- cache hierarchy warnings
ema has joined #aarch64-laptops
_xav_ has joined #aarch64-laptops
xroumegue has quit [Ping timeout: 480 seconds]
init_x13s has joined #aarch64-laptops
<clover[m]>
Nice
<steev>
\o/
<init_x13s>
anyone has problem with their keyboard being seeingly unresponsive? im curiously missing a lot of letters, which does not happend on other keyboards.
<init_x13s>
keyboard feel slugish in fact
<init_x13s>
typing assist is off
init_x13s has quit [Remote host closed the connection]
<clover[m]>
yeah, we think x13s drops key-presses on occasion
<steev>
maybe y'all just type too fast
<steev>
jhovold: stupid question, since i'm taking uart17 out, and we'll probably leave it disabled... should i also just call uart2 serial0 instead of serial1?
<steev>
it's an alias we create so... that should be fine i think?
<bamse>
hmm, why do we have uart17 enabled on the x13s?
<steev>
because i threw it in there :D
<bamse>
ahh, because you put it there :)
<steev>
johan told me to take it out
<steev>
i dunno, maybe someone like caleb will get a thinkpad in the future and throw together a uart like he did with the c630, just future proofing really
<steev>
so, i'm hoping to have v6 of it this weekend addressing johan's comments
<bamse>
right, i don't know if there's a debug connector...if so it would likely have uart pins as well
<clover[m]>
is a serial console possible with x13s?
<steev>
i was being sarcastic... i dunno why i threw it in there.
<steev>
completeness
<bamse>
seems like if you don't have an alias the uart won't probe
<bamse>
ahh, with msm_serial you can omit alias...bus you need to do it for all instances then
<steev>
right but i mean, the alias is simply our side, not the hardware side, and it shouldn't matter - besides, uart17 seems like it would be after uart2 anyway
<bamse>
steev: i was about to suggest that you removed the bt serial alias as well...because as you say...it doesn't matter
<steev>
i can do that as well :)
<bamse>
but reading the code indicates that it won't work
<steev>
but it should? since removing uart17 as well would mean no serial aliases?
<bamse>
you need an alias for the bt-uart...if you want it to probe
<steev>
ah
<steev>
okay
<bamse>
and i don't understand why it has to be like that...
<steev>
sometimes, it is what it is
<bamse>
soundsl like a challenge
<bamse>
hmm, if you have a console it must be serial0
<steev>
that seems odd that it's required
<bamse>
yeah...and it means that ttyMSM0 is your console, regardless of which uartN that is attached to
<bamse>
and if you want your console on some other uart...you have to rebuilt the devicetree and update the uart's compatible and the aliases
<steev>
i don't think that's msm specific though, i seem to recall some weirdness with the pi4 and bluetooth and serial consoles
<bamse>
meh, feels like you tricked me into this rabbit hole
<steev>
the only rabbit hole i want anyone in, is kalle getting us the working firmware :D
<bamse>
but i think this means that you should use the serial1 alias...
<bamse>
the purpose of the aliases is to maintain static numbering, and if someone want console they have to use serial0
<steev>
yeah, i'll leave it as is... maybe add a comment in the commit message that serial0 should be saved for serial console
<jhovold>
bamse, steev: like you noticed the qcom serial driver is special and expects an alias, that should probably be fixed
<jhovold>
we're using serdev for the bluetooth uart so it not even exposed to userspace
<jhovold>
init: heh, we're just reducing some clock rates so far, but it's the basis for improving things further
<init>
for now I was just shutting it down
<init>
any improvement is welcome
<clover[m]>
<steev> "the only rabbit hole i want..." <- is that the 5 ghz wifi?
<steev>
i would assume all of the wifis would work, yeah
<clover[m]>
nice to know someone is looking at it
<steev>
i think the ath11k patches that kalle asked for review on are related to our need for firmware, but not entirely sure, and i'm not good enough to review them (and no firmware to test them)
<steev>
or at least, i couldn't get it to recognize any of our files as the firmware, maybe it was something i needed to throw together, like the sdm845 where you can combine the bdwlan.* files or some such
<steev>
jhovold: i don't quite understand your comment about splitting the rts-tx-pins - none of the other boards seem to do that?
<steev>
(keep in mind that i'm an idiot and may need a bit more guidance than some - but your feedback is absolutely phenomenal, i'm learning a ton)
<steev>
init: you could use a sledgehammer and enable pcie_supersaver or something like that
<qzed>
oh, it looks like multiport support is getting in shape... maybe I can finally replace my hack with that
<steev>
i can't :(
<steev>
patch 2 seems malformed for some reason, or maybe my net just doesn't want me to apply it
<qzed>
does it break?
<qzed>
ah
<steev>
Applying: usb: dwc3: core: Access XHCI address space temporarily to read port info
<steev>
error: corrupt patch at line 83
<jhovold>
steev: at least sc7180 do split them, which makes sense since we may need different bias settings (e.g. during suspend)
<steev>
oh!
<steev>
i was looking at 7280 and sdm660
<steev>
ah, yeah, i had looked at that previously, i just wasn't entirely sure how to split them before, so left them as is (mostly because when i did before i was still running into the serial regression) - will address that as well :)
<steev>
since i'm not near my notes that i took when someone who had schematics gave me the pins - can you confirm: rts = 122, tx 123, rx = 124?
<ajhalaney[m]>
yes im excited to see multiport... i have poked that on and off for like a year now on various platforms but the original patch series from QC got posted and I dropped it. Excited to see it moving again.
<ajhalaney[m]>
also steev the idea of better wifi on x13s gets me giddy as i await an upload to finish now :P
<steev>
si, very much looking forward to it. i'd like to not sound like a demon over bluetooth when trying to talk to people on discord
<ajhalaney[m]>
maybe then I could stop booting a separate laptop for meetings :)
<steev>
still no webcam, but i'm okay with that, as a "privacy minded individual" ;)
<ajhalaney[m]>
yeah my understanding with ISP stuff upstream in general, and Qualcomm's stance on all that, is that's a dream that won't be realized
<qzed>
never say never :) we got IPU3 Surface devices working almost completely now, but that's in parts thanks to Intel graciously providing the IPU driver for that... still, the rest is quite a bit of amazing work by the libcamera folks
<jhovold>
steev: yes, the rest of the pinconfig is correct
<steev>
hm
<ajhalaney[m]>
/me googles IPU3 and hopes for a better camera future :P
svarbanov has quit [Ping timeout: 480 seconds]
svarbanov has joined #aarch64-laptops
<clover[m]>
Bluetooth Trackpoint keyboard coming in today :)
<rfs613>
clover[m]: let me know how it compares to the laptop keyboard...
<clover[m]>
Wilco
<rfs613>
oh, not the lenovo one?
<clover[m]>
Its lenovo yeah
<rfs613>
they were practically giving it away last time I ordered a machine from them... i thought about getting it.. but decided i didn't really need yet another device ;-)
<clover[m]>
I really like my thinkpad keyboard so decided to pull the trigger on one I can use while its docked
<HdkR>
External keyboard is also how I'm getting around the absolutely terrible key drops and ghosting
<steev>
i gotta say, 6.3 is shaping up to be quite nice, 6.4 even better
<steev>
i wish i could blow off work and work on the bluetooth driver
<clover[m]>
call in sick
<HdkR>
Quit your job and just work on X13s fulltime :P
<clover[m]>
yeah!
<clover[m]>
you have my moral and spiritual support
<steev>
i would but i don't have hdkr monies :(
<init>
don't worry we'll find you a bridge to live under with sweet coffee shop wifi running under it.
<HdkR>
Is that an admission of wanting to work on X13s kernel stuff steev? :P
<steev>
wanting doesn't give me the actual skillset :(
<steev>
i have to google half the stuff in code reviews...
<rfs613>
HdkR: which machine are you seeing key drops on?
<HdkR>
rfs613: X13s
<HdkR>
The ghosting is the biggest issue, combining of keys will cause other keys to get dropped
<HdkR>
Or that's just a user satisfied with new hardware :P
<init>
well, yeah, in fact, i don't miss keys in windows
<init>
just under linux
<init>
so it's not hardware related
<rfs613>
his saga starts many months ago... after lots of messing about, Lenovo finally replaced his machine
<init>
at least for me
<HdkR>
I can't retest under Windows since I blew the install away
<rfs613>
ah, if its only in linux, then yeah, likely differnt issue
<rfs613>
do yours have the 5G modem?
<init>
HdkR: you can re-download the vanilla windows image for your specific machine serial on lenovo's website.
<HdkR>
init: Under Windows do you get ghosting? eg holding `a`, then holding shift to get `A` repeating, letting go of shift and seeing `a` not repeat?
<init>
i went back to it when we were still on 6.0 and it wasn't usable.
<init>
never tried the ghosting thing
<HdkR>
It would be a good test to see if that issue is a Linux thing
<rfs613>
i just tested mine for ghosting... hold 'a' then press shift... it stops repeatign the 'a'. Then start again with shift-A repeating, let go of shift, it switches to repeating 'a' after a short pause.
<HdkR>
See, that doesn't work under Linux for me
<rfs613>
so mine is not symmetric
<clover[m]>
both tests work for my machnie
<clover[m]>
on linux
<HdkR>
er, maybe I should have specified left shift?
<HdkR>
Just to ensure consistency there
<HdkR>
(Although both have issues here)
<rfs613>
i just tried with right shift, same non-symmetric behaviour here...
<clover[m]>
tried with both shifts, working fine here on linux
<clover[m]>
HdkR did you try i on all of your dev's laptops?
<HdkR>
I didn't since I'll be sending those out to people
<clover[m]>
might be an easy way to see if its a hardware issue
<clover[m]>
do the test, then just use the fancy new ubuntu installer to reinstall :P
<rfs613>
under linux, mine behaves symatrically... whenever i press or release SHIFT, the repeating stops
<init>
I might ask, what is the expected correct behavior
* rfs613
shrugs
<clover[m]>
repeating never stops
<HdkR>
Yea, correct behaviour is the repeating doesn't stop
<HdkR>
xev will show a key-release for `a` once shift is released is the real issue
<HdkR>
Well, key release for both shift AND `a` when only shift was released
<init>
intriguing, i have a raspberry pi connected and if I press shift, it stops repeating also.
<init>
but this one's never missing a single keypress
<clover[m]>
i used vim to do my tests
<rfs613>
i just tried pressing and hold a, then add b, then add c, etc.
<rfs613>
in that scenario addign 'd' doesn't show anything for me
<rfs613>
but oddly, if I start with b, c, d, then adding 'e' works.
<rfs613>
eg 3 vs 4-key rollover.
<HdkR>
Well, they one probably hits real ghosting from key rollover fail
<rfs613>
i guess it has to do with how the keyboard matrix is setup
<HdkR>
One other person already tested for me and they have the same failure on theirs and it wasn't an early unit
<clover[m]>
software companies are so stingy with arm64 releases. both on windows and linux
<HdkR>
They bought their's like two weeks ago? So relatively new
pbsds has joined #aarch64-laptops
pbsds3 has quit [Ping timeout: 480 seconds]
pbsds is now known as pbsds3
hexdump0815 has quit [Quit: WeeChat 1.9.1]
hexdump0815 has joined #aarch64-laptops
<clover[m]>
Leo Shen: were you ever able to migrate from synapse to conduit for a matrix homeserver?
<szclsya[m]>
nah
<szclsya[m]>
tried conduit in 2021. decided to save some brain cell afterwards
svarbanov has quit [Ping timeout: 480 seconds]
<clover[m]>
steev: do you recommend lenovo-x13s-v6.3.0-rc1
<steev>
sure why not
<steev>
i might push later though
<clover[m]>
any config changes i need or should i just select default stuff
<steev>
i *think* the laptop_defconfig has all the changes needed in it
<steev>
but off the top of my head, there aren't any important changes
svarbanov has joined #aarch64-laptops
<clover[m]>
boots, everything seems to work too
<clover[m]>
Is this the one with the suspend goodness?
<HdkR>
steev: Did you fix the one missing sc8280xp config option being disabled that I saw from laptop_defconfig?
<steev>
the lcars or whatever?
<HdkR>
yea
<steev>
good question
<HdkR>
Only missing option that I saw that was sc8280xp specific anyway
<steev>
CONFIG_SC_LPASSCSR_8280XP=y
<steev>
looks like its in there
<HdkR>
coolio
<steev>
am putting all my stuff on top of johan's latest though, and once i finish the bluetooth changes he requested, as well as going over the ones that were requested of tim's bits that i integrated, will push to be sure