robclark 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
<steev> konradybcio: do you happen to know why https://lore.kernel.org/all/20231230-topic-8180_more_fixes-v1-8-93b5c107ed43@linaro.org/ is unhappy in 6.6.8? it throws a parsing error on line 2945 which corresponds with that patch
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
<steev> derp, my brain short circuited when i saw that and i somehow dismissed it as 6.1.7
<steev> but, it occurs there too, hmm, i'll have to dig deeper tomorrow
<steev> because we're not including qcom,icc
<steev> yet
<steev> its in next already, okay
jglathe has joined #aarch64-laptops
<steev> jenneron[m]: also, just tested, headphones do indeed have output on the flex5g, but you have to crank the volume all the way to get to very quiet
<jenneron[m]> steev: do you mean it is too loud?
<steev> quite the opposite
<jenneron[m]> hm
<steev> at 100% volume i can "barely" hear it
<jenneron[m]> interesting, doesn't happen for me
<jenneron[m]> i listen music on 40%
<jenneron[m]> do you have pipewire or pulseaudio?
<jenneron[m]> actually it is 60-70%..
<jenneron[m]> still more quiet than it was on windows
<steev> pipewire
<jenneron[m]> can you try pulseaudio?
<steev> not without breaking my desktop :(
<jenneron[m]> pipewire didn't work for me at all, i got dummy outputs
<jenneron[m]> steev: why?
jglathe has quit [Remote host closed the connection]
<steev> gnome-core depends on pipewire audio in debian
<jenneron[m]> you don't need to remove it
<steev> you do in debian
<jenneron[m]> no..
<steev> pulseaudio won't co-exist with pipewire due to their dependencies, so if you install the pulseaudio package, gnome-core, pipewire and pipewire-audio are removed
<jenneron[m]> i have both pulseaudio and pipewire installed
<jenneron[m]> on debian sid
<steev> pipewire-audio is a depends, not a recommended
<steev> they may have it fixed in sid, but not in testing?
<steev> or do you not have gnome-core installed?
<jenneron[m]> uh, i don't have gnome-core installed. i use gnome though
<jenneron[m]> yeah installing gnome-core would remove pulseaudio
<steev> it's not *required* if you install all the other stuff either manually, or some other way
<steev> but that's how i pull in the dependencies
<steev> ah, yeah, i was thinking maybe that (i do that on the c630)
<jenneron[m]> to be honest i don't understand why it fixes stuff
<jenneron[m]> is pipewire always trying to set your sound card to 24 bit mode? even when you play only 16 bit files?
<jenneron[m]> it is probably not as bad as setting "wrong" sample rate though
<steev> fwiw, i'm doing a dd if=/dev/sda5 of=/dev/null and not having issues
<steev> with the 2 patchsets i mentioned to 6.7-rc7 - about to test the gnome-disks
<jenneron[m]> yeah try gnome-disks
<jenneron[m]> i use these options
<jenneron[m]> steev: can you open a merge request to my 6.7-rc7 branch?
<steev> i think i have a linux tree on gitlab i can push to, so should be able to
<jenneron[m]> looks good as long as it doesn't fail for you
<jenneron[m]> it failed for me on this branch
<steev> 64% complete
<jenneron[m]> it is possible that konradybcio fixed it unintentionally :P
<jenneron[m]> i'm going to try it
<steev> as soon as the fork finishes, i'll push
<jenneron[m]> i still don't understand what's wrong with touchpad
jglathe has joined #aarch64-laptops
<steev> mine is "mostly fine" ? sometimes it sticks, but if i right click then it goes back to being able to tap to touch, or do you mean something else?
<jenneron[m]> yeah, sometimes it sticks
<jenneron[m]> i use my laptop 8+ hours a day, it's annoying as fuck
<steev> i do too, just... not the flex
<jenneron[m]> yea x13s is much better, i'm not sure it's worth upgrading for me though
<steev> sent
<steev> nah, it's not
<jenneron[m]> maybe i will skip x13s and buy a laptop on the next SoC
<steev> yeah, get x13t :P
<steev> or x13s gen2 x1e00g100
<steev> hm, and i need to dig out my patch for my panel too, it seems
<steev> i swore i'd sent that upstream already but i guess not
<Jasper[m]> <jenneron[m]> "maybe i will skip x13s and buy a..." <- You should
<Jasper[m]> I had some weird issues with my x13s over CCC, Wifi didn't work very well as expected and the keyboard missed input on plymouth which was interesting
<craftyguy> Jasper[m]: regarding wifi, did you try disabling wifi power management?
<craftyguy> my biggest complaint with the x13s is that it's really flaky with usb-c docks (known issues I guess...)
<Jasper[m]> craftyguy: I haven't explicitly checked and/or tried no. What should I check out to see if it fixes things?
<craftyguy> just something like "iw wlan0 set power_save off", then see if it's more reliable
<craftyguy> I have an AP that, for some reason I haven't figured out yet... it's super unreliable when connected to it unless I disable PM. it's usually fine with other APs (wifi6 or otherwise)
<Jasper[m]> Outwardly (in NetworkManager) it just has very bad range, but I think it just picks nonsensical access points based on theoretical speed (wifi 6 on 5GHz instead of wifi 4 on 2.4GHz) instead of actual signal range
<craftyguy> are you using iwd or wpa_supplicant?
<craftyguy> iwd is supposed to be smarter about that stuff, I think...
<Jasper[m]> I think Fedora uses wpa_supplicant
<Jasper[m]> craftyguy: I think I asked before if it's a kernel driver thing or userspace, but got no answer hahahaha
<Jasper[m]> Oh well, when I get back to messing around with it I'll try it out
<jenneron[m]> <Jasper[m]> "You should" <- why?
<Jasper[m]> jenneron[m]: Performance difference is going to be big and it should fix some (practical) issues this model has.
<Jasper[m]> Like the amount and kind of ports
<jenneron[m]> ports is not an important factor for me
<craftyguy> are we going to get hypervisor support on Linux? :P
<jenneron[m]> performance.. probably if it's enough to play something otherwise eh sc8180x is fine too
<craftyguy> (with the new thing, I mean)
<Jasper[m]> jenneron[m]: With somewhat flakey usb (it'll improve in the upcoming months obviously) and some adapters not working properly, I'd love to have a single usb A or something hahahah
<jenneron[m]> i see
<Jasper[m]> craftyguy: Gunyah? Yeah that's shipping as far as I know
<jenneron[m]> both of my type c "docks" work fine on my device except display output
<Jasper[m]> jenneron[m]: I mean everything is relative, but the new chip is also relatively a LOT better than sc8280xp from what they've shown
<jenneron[m]> yeah
<jenneron[m]> but i'm wondering about GPU
<jenneron[m]> when i tried to play something on windows the bottleneck was GPU
<jenneron[m]> like i had 30% CPU load in portal 2 and 90% GPU load having 60 fps with vsync
<Jasper[m]> jenneron[m]: it has usb 4
<Jasper[m]> The drivers will come, maybe something internal to the laptop too
<Jasper[m]> + of course the new adreno will improve a bit too
<Jasper[m]> s/+/\+/
<jenneron[m]> mesa is actually very good on freedreno
<jenneron[m]> OpenGL 4.6 and Vulkan 1.3
<Jasper[m]> With drivers I mean, arm64 drivers for nvidia and amd
<Jasper[m]> nvidia already works, amd is slowly getting there
<jenneron[m]> i doubt new laptops on qcom will have a discrete GPU
<craftyguy> I want to stick with the x13s for as long as possible, I'm hopeful that Linux support will continue to improve and my experience tells me that starting over with a new platform/SOC is always a bit rocky
<Jasper[m]> I guess it helps that support is already mostly there for the qrd's
<craftyguy> and it actually seems to outperform (or at least "feel a bit faster than" lol) the laptop it replaced (intel i7-10710U)
<Jasper[m]> Jasper[m]: Don't think that was the case for the sc8280xp
<jenneron[m]> craftyguy: meanwhile x13s (8cx gen 3) is better supported than flex 5g (first 8cx)
<Jasper[m]> craftyguy: Oh yeah, it is the reason why I switched. Got a good deal on it too
<craftyguy> yeah obviously it's not a rule :P
<Jasper[m]> Jasper[m]: (Although yeah, it marketdly improved with Lenovo throwing some money at supporting the x13s somewhat officially)
<craftyguy> ok maybe I'm still in a "honeymoon" phase. I don't have a lot of experience with aarch64 laptops, this one is worlds better than my last attempt to use an aarch64 laptop (pinebook pro)
<jenneron[m]> craftyguy: rk3399 is meh and eMMC is meh..
<Jasper[m]> i/o does a LOT
<craftyguy> I agree (I used an nvme with my pbp, but that exposed a bunch of new issues lol...)
<Jasper[m]> Also helps that those x1 and a78 cores are just really fast with a better power budget
asdf has joined #aarch64-laptops
asdf has quit []
<craftyguy> Jasper[m]: does gunyah actually work on Linux though? I found a project on github that says "it uses AArch64 EL2 in VHE mode by default", and I thought EL2 wasn't an option on the sc8280xp?
svarbanov_ has joined #aarch64-laptops
svarbanov__ has quit [Read error: Connection reset by peer]
<Jasper[m]> <craftyguy> "Jasper: does gunyah actually..." <- Assumed you were talking about the new chip. sc8280xp will likely need a different approach in the long run
<travmurav[m]> craftyguy: exelite will (probably) have gunyah "forced on" on everyone by default, and qcom seems to slowly work on upstreaming the linux side for it too, so can think you're forced to run under hyper-v equivalent but you can at least use the vm management api
f_ is now known as f_estive
<jglathe> my branch contains the current gunyah patch series. can't do a lot with it, except load the modules - on sc8280xp.
<agl> Have a good New Year 2024!!!
<jglathe> IMO x13s support is kinda outstanding. working WWAN would be cool. USB-C monitor support works. Is there an official install image? I thought there would be.
<Jasper[m]> jglathe: Fedora Rawhide is nearly perfect
<Jasper[m]> Save for the outstanding patches in (for example) jhovold and steev's trees I think you only really need to put the dtb on the esp and add the kernel cmdline options
<Jasper[m]> Oh and the alsa-ucm-conf patches are not in yet obviously
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #aarch64-laptops
<HdkR> as an end user, x13s is definitely one of the better ARM experiences with Linux
<agl> HdkR: I use original Debian and EndeavourOS on the x13s. Both with steev's kernel. All works well.
<HdkR> Yea, since most everything works it is a pretty good time
jhovold has joined #aarch64-laptops
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #aarch64-laptops
<jhovold> jglathe, craftyguy: you can't set the bluetooth device address from udev directly due to some systemd security setting
<jhovold> hans came up with a systemd service hack that can be used to work around it here:
<jhovold> ideally somone should just implement support for this i bluez as suggested in the link
<jhovold> jglathe: wwan works and people like bamse use it all the time (my machine does have a modem), you may need a recent modem manager and you need to do the fcc unlock dance manually first, though
<jhovold> s/does have/doesn't have/
<Jasper[m]> I wish it was more financially viable to have a data only sim here.
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #aarch64-laptops
<Bioxvirizm-x13s[m]> <agl> "HdkR: I use original Debian..." <- Sound + microphone? Integrated?
sensesense has joined #aarch64-laptops
<sensesense> HI
<sensesense> here is LENOVO chat?
<jglathe> @jhovold then using crontab @reboot is the way. Works nicely.
<Jasper[m]> sensesense: It's for Linux development on all aarch64 related laptops
<sensesense> oh thx
<sensesense> i want ask why erveryone love aarch64 not arm64 or x86x64
<jglathe> aarch64 == arm64
<sensesense> oh this is my first one heard sound
sensesense has quit [Remote host closed the connection]
sensesense has joined #aarch64-laptops
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #aarch64-laptops
sensesense has quit [Remote host closed the connection]
<agl> Bioxvirizm-x13s[m]: Sound does (a bit quiet), but I haven't tried the microphones yet. WLAN and LAN (over an ethernet adapter) works also!
svarbanov_ has quit [Read error: Connection reset by peer]
<agl> Bioxvirizm-x13s[m]: For USB-Theathering over my Smartphone (Internet) there was it necessary to switch on a kernel module over Menuconfig bevore compiling steev's kernel
svarbanov_ has joined #aarch64-laptops
<agl> Bioxvirizm-x13s[m]: I don't know at this moment which kernel module that is.
<Bioxvirizm-x13s[m]> <agl> "Bioxvirizm-x13s: Sound does (a..." <- Very frustrating with a non-working microphone and broken sound. Not possible to use as the only working device in my user experience.
<jhovold> Bioxvirizm-x13s[m]: you should have somewhat working microphone (distorted) and working speakers and headphone as long as you have the latest ucm conf fixes
<jhovold> but you probably have to package those yourself for whatever distro you're using
<jhovold> until upstream does a release, hopefully soon...
<Jasper[m]> jhovold: Is it loud enough for you? I have the configs copied over from git and both the speakers and 3.5mm jack are very soft for me
<jhovold> Jasper[m]: yes, i'd say so at least for I use the speakers for (don't use headphones but would blow my ear drums at max volume)
<jhovold> i ended up with pulseaudio reducing the digital gain setting for some reason at one point, and then it was too quiet
<jglathe> It is not very loud (mantic), but works okay. Mic not tested.
<Jasper[m]> jhovold: Interesting, I have the default setup on fedora (pipewire) + those alsa configs and the 3.5mm jack is only somewhat hearable at 100% vol
<Jasper[m]> Same for speakers
<Jasper[m]> Copying over the configs did change the 3.5mm jack from blowing my eardrums out to that lower volume
<Bioxvirizm-x13s[m]> jhovold: you must have somewhat working microphone (distorted) - it's hard to call it a working device.
<jhovold> Bioxvirizm-x13s[m]: yeah, I agree, the microphone is probably mostly useless, only did some basic tests long ago and that distortion should still be there afaik
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #aarch64-laptops
<jhovold> sounded like you had trouble with speakers and headphones too, but those work here
<jhovold> Jasper[m]: make sure you have cleared out any old alsa state, which could have left the digital gain settings too low
<Jasper[m]> jhovold: Directly after applying the config? I've rebooted many times since, didn't really make a difference sadly.
<jhovold> could try try setting them manually to 0 dB too, and make sure pipewire doesn't do anything funky
<jhovold> rebooting isn't enough, you need to stop the alsa-state service, remove the alsa state, and then reboot...
<Jasper[m]> Okay I'll check it out when I have the time. Thanks!
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #aarch64-laptops
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #aarch64-laptops
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #aarch64-laptops
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #aarch64-laptops
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #aarch64-laptops
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #aarch64-laptops
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #aarch64-laptops
<neobrain> Speaking of audio, was audio-over-hdmi/dp something that should be working yet?
<neobrain> oh, oof, and looks like audio-over-3.5mm adds strong buzzing to the sound here
<jglathe> apparrently... no idea. Over USB-C alt mode it doesn't or I didn't switch the output. Will test when USB-C display is accessible
<neobrain> ah yeah, I think "usb-c alt mode" is the one I meant to refer to. It's an external monitor connected via hdmi to a USB-C dock plugged into the X13s :)
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #aarch64-laptops
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #aarch64-laptops
<jhovold> neobrain: no, srinik got audio over dp to work, but it's left disabled due to some missing bits related to how the outputs are registered and reported to user space
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #aarch64-laptops
<travmurav[m]> jhovold: the -22 crowbar fun when the cable is not connected?
<jhovold> (e.g. it would only show up if the monitor was connected at boot or similar)
<jhovold> right, something like that
<travmurav[m]> right, that thing
<travmurav[m]> seems like PA (didn't check pw) insists on configuring the port even when jack is unconnected and, annoyingly, refuses the whole ucm profile if it failed, right
<travmurav[m]> can still (if inconveniently) use it, if the DP is a dedicated profile and one restarts PA after connecting the display to re-run ucm rules
<neobrain> jhovold: ah I see, thanks!
<jhovold> heh, yeah, not very user friendly as is then
<jhovold> neobrain: have you tried a different pair of headphones? perhaps something is off with the plug detection?
<neobrain> ok interesting, I found two things:
<neobrain> 1) it worked when plugging in my earphones, but (spoiler) I only tested them with 5% volume
<neobrain> 2) I plugged the speakers back in. Turns out audio buzzing is only there when the software-side volume is at 30%. If I limit the volume to 20% sounds perfectly fine as long as volume is limited to 20% it sounds perfectly fine, even if I pull the physical volume knob all the way up
<neobrain> ("at 30%" = at 30% or higher)
<neobrain> I wonder if this is the ucm files acting up again or something. I didn't set up any "protection" from my package manager partially overwriting them
<neobrain> Upon listening more closely, there are *some* artifacts even on 20%. On that level, it actually sounds very similar to the artifacts I noticed in that one hiphop song the other day on the built-in speakers.
<jhovold> neobrain: haven't tested line-out myself, and not sure how it's supposed to work, perhaps you need to set a lower gain manually for that
<neobrain> Is gain like the mapping from software-adjusted volume to physical signal strength? Would comparing the physical volume produced by the x13s to some other device be useful to deduce the correct gain value then?
<jhovold> yeah, something like that, or just lower the gain on the x13s until it sounds good on the external speakers
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #aarch64-laptops
<neobrain> alright, will look into that later then
jglathe has quit [Remote host closed the connection]
jglathe has joined #aarch64-laptops
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #aarch64-laptops
jglathe_ has joined #aarch64-laptops
jglathe__ has joined #aarch64-laptops
svarbanov_ has quit [Remote host closed the connection]
svarbanov_ has joined #aarch64-laptops
<jglathe__> argh.Plugging in the USB-C display killed the desktop session. Afterwards joined screens (okay), but sound stays on internal speaker. No additional sound device.
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #aarch64-laptops
svarbanov_ has quit [Read error: Connection reset by peer]
jglathe has quit [Ping timeout: 480 seconds]
svarbanov_ has joined #aarch64-laptops
jglathe__ has quit []
jglathe_ has quit [Ping timeout: 480 seconds]
jglathe has joined #aarch64-laptops
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #aarch64-laptops
jglathe has quit [Ping timeout: 480 seconds]
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #aarch64-laptops
jglathe has joined #aarch64-laptops
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #aarch64-laptops
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #aarch64-laptops
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #aarch64-laptops
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #aarch64-laptops
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #aarch64-laptops
jglathe has quit [Quit: Leaving]
jglathe has joined #aarch64-laptops
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #aarch64-laptops
<_[m]1> <jenneron[m]> "maybe i will skip x13s and buy a..." <- I thought the same but will it be equal enough as to seeing a faster kind of stable Linux distro(s)?
<_[m]1> I think, inversely, i will hold back from buying next gen because x13s will be stable af by then maybe wait a year or a gen? unless x13s never gets finished because everyone is on the next iteration, let's hope a lot of the work is similar?
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #aarch64-laptops
<jglathe> @_[m]1 Hmm I bought an x13s with several excuses (one being curiosity) and must say it was a lucky strike. Seeing the amount of work that has gone into it, it might take a while for next gen to become as operational or better than the x13s.
<jglathe> the new hardware isn't really available yet. Enough to tweak on the x13s, still, but it is very usable IMO. And the devices come into the "affordable" price range, occasionally.
jglathe has quit [Quit: Leaving]
jglathe has joined #aarch64-laptops
<steev> jglathe: do you have the fixed mutter?
svarbanov_ has quit [Read error: Connection reset by peer]
svarbanov_ has joined #aarch64-laptops
<craftyguy> Jasper[m]I was referring to sc8280xp actually :(
<robclark> basic support for x1e80100 is already in v6.8 so I guess linux support for the next gen thing should come up quicker..
<jglathe> @steev no
svarbanov_ has quit [Read error: Connection reset by peer]
<Jasper[m]> <craftyguy> "Jasper[m]I was referring to sc82..." <- Okay, well it needs a lot of work
<jglathe> @steev thanks. Just built 6.7-rc7 with volterra patches on top
<Jasper[m]> It's not impossible, but since there's barely any info on it public, it'll need research
jglathe has quit [Remote host closed the connection]
jglathe has joined #aarch64-laptops
Ablu has quit [Read error: Connection reset by peer]
Ablu has joined #aarch64-laptops
<jenneron[m]> <_[m]1> "I think, inversely, i will..." <- well, i already have flex/yoga 5g
<jenneron[m]> i'm just pissed off with touchpad issue
jglathe has quit [Ping timeout: 480 seconds]
<jenneron[m]> steev: btw do you notice the touchpad issue?
<jenneron[m]> it seems to me that it happens much less than before my patch
<jenneron[m]> i'm wondering if you could confirm this feeling
<steev> i need to use it more but definitely hasn't stuck on me as often as it used to
<steev> touchscreen works here too (though i'll probably end up disabling that as i don't like people touching my screen ;) )
<jenneron[m]> this is basically what i did
<jenneron[m]> it makes interrupt report faster
<jenneron[m]> i'm not sure if it is possible to make it even faster with this patch
<jenneron[m]> because it seems to be an improvement, but it's not there yet, the problem still happens sometimes
<jenneron[m]> <steev> "touchscreen works here too (..." <- yeah i got it to work as well, but using device-tree bindings which i shouldn't use
<steev> have you considered high? it looks like high was used on the c630
<steev> though we also override the default pinctrl, so not sure
<jenneron[m]> AFAIU edge falling reports when interrupt starts changing
<jenneron[m]> while high/low reports when it is in the specified state
<jenneron[m]> so edge falling should always be faster
<travmurav[m]> but not always correct
<travmurav[m]> as in, level interrupt is ususally used when multiple events may hit and you have to read and respond to all of them to it to drop
<travmurav[m]> if you only catch the edge, you will (forever) miss other events
<jenneron[m]> idk, ACPI tables set it to low
<travmurav[m]> idk if hid-i2c spec is like that
<jenneron[m]> but most (all) touchscreens in mainline kernel are edge falling
<jenneron[m]> touchpad is a similar to touchscreen thing
<jenneron[m]> * most (all?) touchscreens
<steev> what i'm most excited about is that it doesn't stutter when using network anymore (on 6.7-rc7)
<jenneron[m]> yeah i included the patch
<steev> my sensors don't seem to be reporting properly; something is funky because bottom is reporting no data for... everything
<jenneron[m]> what sensors do you mean?
<steev> https://github.com/clementtsang/bottom i may be misspeaking, but basically, this app is entirely empty
<steev> oh
<travmurav[m]> jenneron: hid-i2c spec (duh they distribute it as docx) says:
<steev> nevermind, i know what it is
<travmurav[m]> > DEVICE is responsible to assert the interrupt line (level trigger interrupt required) when it has data.
<steev> it's the ath10k thermal sensor still not reporting properly
<steev> it just takes a long time to time out
<jenneron[m]> travmurav: then how do we make interrupt faster...? or why else these problems are happening
<steev> and ath10k_snoc when using it starts spamming about failed to synchronize thermal read
<travmurav[m]> not sure, but I'd say the issue is somewhere else if the latency is introduced. i.e. if the interconnect that is used by geni (and wifi you say?) is incorrectly configured
<jenneron[m]> yeah possible
<travmurav[m]> but I'd say setting it to edge /may/ lock up touchpad randomly
<travmurav[m]> at least as I read the spec
<jenneron[m]> wifi works fine though
<jenneron[m]> i get 500 mbit download speed, really good
<travmurav[m]> iirc you said touchpad starts to misbehave worse when something else is used?
<jenneron[m]> travmurav: that was a separate problem
<jenneron[m]> it was fixed
<travmurav[m]> mhm
<travmurav[m]> well, I guess all I can say is that edge interrupt for i2c-hid is not correct per spec
<jenneron[m]> touchpad gets stuck if you spam click. this is the current problem
<jenneron[m]> with edge falling interrupt it is much harder to catch, doens't happen that much
<jenneron[m]> travmurav[m]: yeah, so none of my patches are going to upstream, heh
jglathe has joined #aarch64-laptops
<steev> :(
svarbanov has joined #aarch64-laptops
svarbanov has quit [Remote host closed the connection]
svarbanov has joined #aarch64-laptops
svarbanov has quit [Read error: Connection reset by peer]
svarbanov has joined #aarch64-laptops
<jglathe> @steev interesting: On Volterra the WCN6855 code generates qca/hpnv21g.bin like before. Different SoC IDs and controller versions.
<steev> jglathe: not surprising that it would generate that one if it's a different id and controller; that seems like it's a g variant (the x13s is not)
<jglathe> @Jasper[m] Any idea how to get the calibration data from the Volterra WiFi Windows driver in a usable format?
<Jasper[m]> <travmurav[m]> "iirc you said touchpad starts to..." <- I have a similar problem with x13s
<Jasper[m]> Was pixelflutting over wifi and mouse wasn't having it (trackpoint worked fine)
<Jasper[m]> jglathe: Haven't looked into it yet.
<Jasper[m]> There are some thing I can still try and I haven't asked Kalle for help yet
<jglathe> Need to look it up, but I did a bin compare of the driver directories between x13s and volterra, and only one file was different ^
<steev> i haven't seen that here on my x13s at all, and i'd say i do a decent amount of network traffic on it
<steev> git repos, building kali packages, kernels, building the arm images
svarbanov has quit [Remote host closed the connection]
svarbanov has joined #aarch64-laptops
svarbanov has quit [Remote host closed the connection]
svarbanov has joined #aarch64-laptops
svarbanov has quit [Read error: Connection reset by peer]
svarbanov has joined #aarch64-laptops
svarbanov has quit [Read error: Connection reset by peer]
svarbanov has joined #aarch64-laptops
svarbanov has quit [Read error: Connection reset by peer]
svarbanov has joined #aarch64-laptops
<jglathe> Happy new Year everybody!
svarbanov has quit [Read error: Connection reset by peer]
svarbanov has joined #aarch64-laptops
svarbanov has quit [Read error: Connection reset by peer]
svarbanov has joined #aarch64-laptops
svarbanov has quit [Remote host closed the connection]
svarbanov has joined #aarch64-laptops