00:04 <hexdump0815> travmurav[m]: jenneron[m]: i found some time to look at the samsung galaxy book go again and i managed to get the touchpad working

00:05 <hexdump0815> https://github.com/hexdump0815/linux-mainline-qcom-kernel/commit/692bb8ff835dc7ec4786eda5673c0e68ec9df628

00:05 <hexdump0815> sadly i'm still strugling with the keyboard - it is basically working with this dts entry: https://github.com/hexdump0815/linux-mainline-qcom-kernel/blob/main/misc.qc7/misc/sc7180-samsung-galaxy-book-go.draft#L186-L201

00:07 <hexdump0815> but i have to either press some key early at boot or i'll get flooded with "i2c_hid_of 6-0005: i2c_hid_get_input: incomplete report (11/33026)"

00:08 <hexdump0815> also the irq set in that dts is definitely not the proper one as many different irq values will work in a similar broken way too

00:08 <hexdump0815> this is the corresponding part from acpi: https://pastebin.com/raw/iuxqB1Y7

00:09 <hexdump0815> i already tried many different values for the interrupt, but so far did not find anything working properly

00:12 <hexdump0815> travmurav[m]: jenneron[m]: do you maybe have any idea what might be the proper value here? - i already tried 12-62, 320 (=0x140), 385 (=0x181) but none of them worked

00:15 <hexdump0815> what i notice is that the interrupt for ECKB in acpi is marked SharedAndWake and there is a separate device for I2C7 while for instance for the flex 5g case it is marked ExclusiveAndWake without an extra device for the corresponding i2c

01:29 <steev> jenneron[m]: i need to reboot a few more times, but i *think* the wcn3998 needs the .capabilities line in hci_qca.c `.capabilities = QCA_CAP_WIDEBAND_SPEECH | QCA_CAP_VALID_LE_STATES,`

02:29 <INtermedai> HI EVERYONE

02:30 <INtermedai> Aarch64 is support Xen Kernel?

03:54 <HdkR> Found out that the latest Cortex has a `IMP_CPUPWRCTLR_EL1` register for determining how long it takes a WFE/WFI instruction to enter its power retention state. I wonder what the latest Snapdragons say about that.

03:59 <HdkR> I guess probably 0 to state that it is disabled

05:30 <travmurav[m]> <hexdump0815> "but i have to either press..." <- does this stop after you press the key?

05:31 <travmurav[m]> but from what you say I'd guess this gpio is always low so it /always/ triggers the interrupt, basically polling the keyboard. And if the keyboard was not reporting any event, it would spam that I guess...

05:32 <travmurav[m]> hexdump0815: I'd still suggest trying to monitor gpios from userspace and try seeing what gpio changes state after you press a key

05:33 <travmurav[m]> after I read the spec, what I think would happen is that the gpio should be high initially, then if you press any key, it will be low until reboot.

05:33 <travmurav[m]> so can probably get debug/gpios -> press a key -> get another output, find what went high->low

07:30 <hexdump0815> travmurav[m]: if i press a key very early on in boot (i.e. when grub has finished) then i do not get the log spam, otherwise i get it and i think pressing a key later does not help anymore - the keyboard is working in both scenarios

07:32 <hexdump0815> sometimes after a while of no keyboard use the keyboard does not work anymore, but comes back then i use it again after a while and it looks like all keystrokes i did then are coming at once then, so looks like nothing really gets lost in this case

07:35 <travmurav[m]> well that does sound like a wrong interrupt - if the kb controller queues the events for each keystroke but linux doesn't read them, then decides to read everything at some point...

07:37 <hexdump0815> i just double checked: i do not have to enter a key early on - it looks like the log spam also stops if i enter it later, which should make your idea possible to monitor the gpios and check which changes on the first key press

08:22 <jhovold> Jasper[m]: good to hear you got the volume level issue sorted, have never seen that soundwire issue before, though

08:25 <jhovold> exeat: interesting to hear you've made some progress on the firefox/pipewire issue, does clamping the quantum range also help with the youtube timing issue?

11:45 <steev> jenneron[m]: i think one of the bluetooth regulators isn't "correct"; i can get the system to trip up pretty easily by restarting bluetooth (or trying to start it twice) and iirc, we had something similar on the x13s

11:54 <steev> jhovold: seems like it here, though i'm just watching watch the world burn by falling in reverse. first in firefox 121.0-2, but realizing i'm not spoofing my user agent on there and only getting 720p, before switching to firefox-esr 115.6.0esr-1 where i am, and watching it at 2160p) and no issues. additionally the "scratchy noise" i complained about with the startup sound is not "scratchy" after setting the quantum)

12:55 <jhovold> steev: the x13s bluetooth regulator issue was due to you forgetting to add WCN6855 to a conditional when enabling support in the driver:

12:55 <jhovold> https://lore.kernel.org/lkml/Y%2FXMbhIgF8veIIdl@hovoldconsulting.com/

12:55 <jhovold> don't have much context here, but perhaps it applies here too

12:55 <jhovold> jenneron[m]: ^

12:57 <jhovold> steev: thanks for confirming, it seems like most of the audio issues are indeed down to some bug or compatibility issue with firefox/pipewire

12:58 <jhovold> Bioxvirizm-x13s[m]: I just tried the internal microphones and the distortion issue I heard almost a year ago is not there anymore, so everything indeed seems to work

12:59 <jhovold> it's a bit surprising, given that srinik seemed to confirm the issue just a few weeks ago, I guess we must have talking about different issues, and maybe he too is having trouble with pipewire

13:00 <jhovold> I can't say whether that is due to a bug in firefox, pipewire, or some compatibility issue with the driver, but given that everything works with pulseaudio I'm inclined to consider it a firefox/pipewire bug for now

13:09 <Jasper[m]> <jhovold> "I can't say whether that is..." <- swap out firefox with chromium and the issue is gone. The issue likely sits inbetween

13:10 <Jasper[m]> <jhovold> "Jasper: good to hear you got the..." <- Also to come back to this, I still need to figure out the jack xD

13:16 <jhovold> Jasper[m]: the jack?

13:18 <Jasper[m]> jhovold: 3.5mm jack, not JACK.

13:18 <Jasper[m]> It's still overamplified and extremely distorted sadly.

13:19 <jhovold> and just turning down the gain doesn't work?

13:19 <jhovold> are you connecting it somewhere which expects line levels?

13:24 <Jasper[m]> jhovold: using alsamixer?

13:24 <Jasper[m]> jhovold: Just my IEM's

13:26 <jhovold> yeah, if you use alsa directly, I use pavucontrol here and would just lower the "Speaker playback" gain

13:27 <jhovold> guess the IEMs have their own amplification and would expect line levels

13:28 <jhovold> neobrain reported the other day that he had to turn down the gain below 30%, should probably go even lower and adjust volume on the external speaker (or IEMs)

13:31 <jhovold> correction: I meant to say "Headphone playback" above

13:34 <Jasper[m]> <jhovold> "guess the IEMs have their own..." <- They're just regular earbuds, so they shouldn't

13:34 <Jasper[m]> <jhovold> "yeah, if you use alsa directly..." <- I use pipewire too, I will check if there's such a setting. Otherwise I'll try to turn down the gain using alsamixer

13:35 <jhovold> Jasper[m]: wouldn't recomment trying to go behind pipewire's back like that, it will probably not have any effect (or be restored as soon as pipewire tries to change the volume)

13:36 <jhovold> fwiw, i have my headphone gain set to 25% too, would be way to loud with the crappy headphones I use for testing otherwise

13:37 <Jasper[m]> Alright

13:39 <jhovold> that said, perhaps the default or max gain setting can/should be tweaked

13:39 <jhovold> srinik: ^

13:43 <neobrain> I've also observed (both on internal speakers and on speakers connected to the 3.5mm jack) some weird dynamic regulation of audio volume. It seems that if you keep playing certain songs for >20s, the audio starts being played back differently (for lack of better words to describe the effect). Pretty noticable when the song's second chorus kicks in though.

13:44 <neobrain> I thought it would be overheat protection for the speakers at first, but that'd only make sense for the internal ones

13:49 <jhovold> neobrain: interesting, and you're sure it's not just pipewire acting up again (will be my default reply to any audio issues from now on ;) )?

13:51 <neobrain> I've switched to pulseaudio due to the PW+FF issue, but I should try and see if it reproduces in VLC

13:56 <neobrain> Not sure what song I noticed it on sadly, so will have to experiment a bit (aka turn on my regular audio playlist and go do something else for a couple of hours :p)

14:11 <neobrain> Based on quick testing, it seems like I need to shut up about issues until I've solidly reproduced them a second time 🙈

14:14 <jhovold> :)

14:17 <neobrain> ok here we go, disclaimer it's weird music again though: https://youtu.be/97rqvPgdzBk?t=67

14:18 <neobrain> The segment from 1:05 to around 1:35 has very variable volume for some reason, compared to when I play back the song on the same speakers but via my macbook

15:12 <jhovold> For completeness, here's an updated wip branch for the X13s:

15:12 <jhovold> - https://github.com/jhovold/linux/tree/wip/sc8280xp-v6.7-rc8

15:12 <jhovold> I've also updated the known issues list (e.g. audio and bluetooth):

15:12 <jhovold> - https://github.com/jhovold/linux/wiki/X13s#known-issues

15:21 <jglathe_> I noticed something odd on x13s with 6.7-rc7: on waking up after a longer time (lid was open) WLAN won't come up again. Experienced it twice now.

15:24 <jglathe_> the log is full of this: ath11k_pci 0006:01:00.0: HTC Rx: insufficient length, got 412, expected 1472

15:24 <jglathe_> deep in the night

15:27 <konradybcio> had something like this, removing the wifi device and rescanning the pci bus makes it work again

15:27 <konradybcio> of course, rather suboptimal

15:37 <exeat> jhovold: I'd never noticed the firefox a/v timing issue, but then I almost never use it for media. The "scratchy audio" problem doesn't seem to be specific to firefox, however.

15:37 <exeat> For example it's reproducible with mpv playing a sine wave, especially after seeking (this might be a clue):

15:37 <exeat> mpv --ao=pipewire --pipewire-buffer=64 48KHz-stereo.wav <-- alsa_output quantum==2048, clicks

15:37 <exeat> sox -r 48000 -n -b 16 -c 2 48KHz-stereo.wav synth 120 sin 1000 vol -30dB

15:37 <exeat> pw-metadata -n settings 0 clock.max-quantum 0

15:37 <exeat> mpv --ao=pipewire --pipewire-buffer=32 48KHz-stereo.wav <-- alsa_output quantum==1024, no clicks

15:37 <exeat> With clock.max_quantum set to 1024, both buffer sizes play with no clicks.

15:37 <exeat> (Use pw-top to observe the quantum values and ensure that no other client is forcing a lower quantum)

15:37 <exeat> The above work normally (with no quantum clamping etc) on snd_hda_intel, as does firefox.

15:41 <jhovold> exeat: thanks for the details, i don't use pipewire here, but this sounds it will be very useful for anyone that wants to track this down

15:41 <jhovold> and perhaps I should just say Pipewire playback issues in the wiki

15:43 <jhovold> let's ping srinik as well in case he thinks this might indicate a driver side issue

15:57 <jhovold> jglathe_: so this wasn't on resume but rather after you waking up? :)

15:57 <jhovold> i've been able to provoke the ath11k fw into something like that too, but not during normal use, i think

16:07 <jhovold> neobrain: hehe, i tried listening to that too, and can't really be unheard, unfortuntely :)

16:07 <jhovold> last one was better!

16:09 <jhovold> but if you're trying to evalutate this using your external speaker that expect line-levels, i guess whatever you're hearing could be the result of the external system doing something with the stronger signal

16:10 <jhovold> you'd need to reproduce issues like this with the internal speakers so we have the same base line

16:15 <neobrain> hmm back to the drawing board it is then

16:18 <jhovold> neobrain: but as an experiment, you could try lowering the gain on the x13s further and see if the issue (e.g. due to clipping) goes away

16:19 <neobrain> You don't happen to know off the top of your head how I lower gain on a pulseaudio setup, do you? :)

16:20 <jhovold> use pavucontrol and lower the "Headphone playback" gain setting under "Output devices"

16:23 <neobrain> oh, well here's one interesting thing: the pavucontrol slider says "Silence" on the leftmost setting, "100% (0 dB)" further on the right, but there's also a "Base" level around 20%. The slider controls the same volume that KDE plasma's volume slider controlled, so that would explain why volumes above 20% caused issues before. Not sure why it let me drag past that "Base" level to begin with then,

16:23 <neobrain> though?

16:29 <neobrain> As for the other issue (variable volume), apparently that's gone if I put volume at this base level. It only shows back up if I turn down volume to 10% (on the external speaker)

16:58 <Jasper[m]> <jhovold> "Jasper: wouldn't recomment..." <- Alsamixer doesn't work anyways it seems. Will have to do more googling to edit pipewire's settings in that regard though. Couldn't find anything at a first glance.

20:14 <harvests[m]> I have xmonad setup finally on the x13s!

20:51 <exeat> xmonadcomputers

21:45 <steev> it shouldn't have taken that long to build :P

21:55 <clover[m]> arch updates:... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/BUTlgoTSoviJRdGRXWGcyDDq>)

22:26 <clover[m]> https://archive.mesa3d.org/ is down i guess?

22:38 <steev> maybe

22:41 <robclark> there was some mention on #freedesktop about some server being down.. idk if related or not but sounds likely

23:20 <adamcstephens> hi 👋 I’ve got an x13s working well on steev’s 6.6.6 branch, but all of the 6.7 rc’s I’ve tried (both steev and jhovold branches) will turn the display off shortly after boot. any suggestions on what I could try to troubleshoot this? I can get to the machine over the network, so it is fully booting

23:32 <steev> probably missing a module being in the initramfs

23:34 <steev> check jhovold's commit for his defconfig in my branch

23:34 <steev> it mentions all the modules you should throw into the initramfs

23:48 <adamcstephens> awesome, i'll do so. thanks

23:56 <harvests[m]> has anyone used https://wiki.debian.org/InstallingDebianOn/Thinkpad/X13s recently? Having some trouble after editing the install params to disable pointer auth to boot into the installer

23:57 <harvests[m]> After replacing quiet with arm64.nopauth I'll hit CTRL-x to boot into the launcher but I just get a black screen then boot into the internal drive

23:59 <steev> i believe that's ema's work