03:05 <tstachecki> reposting: [07:40] <Core2323> Hi all. I recently picked up some Microsoft Surface 7 laptops and have been bringing them up with various patches and fixes. The touchpad is behind hid-over-spi and I'm having issues bringing up the QSPI

03:06 <tstachecki> invalid proto: 9 suggests the geni controller has issues, is there qspi support anywhere upstream from Qualcomm?

09:16 <albsen[m]> kuruczgy: thank you for asking this questions, I've been running grub with `cutmem 0x8800000000 0x8fffffffff` but without `mem=31G` kernel param and the system kept crashing, added your param and so far it hasn't crashed.

10:05 <\[m]> robclark I ve reread the mails - I couldn't understand from them that the gpu issues were somehow fixed but I'm out of my league 🙂

10:05 <\[m]> ah yes the fuses thing, didn't quite catch the essence

10:06 <\[m]> https://lore.kernel.org/all/75c17309-3072-4321-ab15-69d60190f2f7@kernel.org/ I'll repost for those interested to reread too 🙂

10:39 <Stardust> Hi! I don't know where else to ask it, but I have noticed that two SanDisk SD cards have last sector filled with random-looking data

10:39 <Stardust> Can you tell if it's indicating it's fake, or it's real and what this data means?

11:04 <Stardust> It could be encrypted license key for an util from their site or something perhaps

14:10 <kuruczgy[m]> albsen: I have seen that param from roy @_oftc_roy:matrix.org, not sure where they got it from. (But also it does make sense that we want to use some kernel param like that, because when booting with sd-boot there is no cutmem equivalent. Question is then, is cutmem needed at all?)

14:31 <albsen[m]> kuruczgy: its needed when running grub. but maybe, `mem=31G` is more encompassing. at the moment I'm using both and the machine hasn't crashed for many hours. longer than I ever was able to use it before. at the moment I'm just happy I can finally use this laptop, when I feel like experimenting again I'll remove the cutmem entry from grub and check if it works as well.

14:50 <\[m]> https://fedoraproject.org/spins/cosmic nice

17:38 <robclark> JensGlathe[m]: fwiw, a co-worker just got a 7x.. I tried it with windows (with the same monitor that did not work with right-side port).. it works fine with windows. (He hasn't put linux on it yet so can't rule out a hw issue with my specific laptop.. but it seems like the right side port is supposed to work)

17:39 <JensGlathe[m]> That's the second report, the other one was on Linux

17:42 <robclark> maybe there is something different about how it is wired up, due to ribbon cable? Or maybe some kind of phy tuning/cal issue?

17:46 <JensGlathe[m]> phy/tuning. LTTPR is getting better, try with 6.15-rc3-jg-1. The [reports](https://bugs.launchpad.net/ubuntu-concept/+bug/2084191/comments/232) used this one.

17:48 <alexVinarskis[m]> It worked on the right port for me when i tested it last week. Both cold and hot plug, as long as I would start from rhs. Was running on ubuntu's kernel wirh [@jglathe:matrix.org](https://matrix.to/#/@jglathe:matrix.org) 's dtb iirc, so LTTPR link training per segment patches included.

17:48 <robclark> I should mention, I do have msm-next for v6.15 on top of v6.14, so I should have any dp changes

17:49 <SpieringsAE> weeee just got my fairphone 5, gonna try the new android experience before I'm gonna try running Linux on it

17:49 <robclark> but yeah, I'll move to v6.15 soonish. I'm just in middle of working on a largish patchset so don't want to rebase just at the moment

17:50 <SpieringsAE> I've tried to rebase this display driver for the jh7110, didn't get it working again yet

17:51 <SpieringsAE> some wacky changes happened in the drm subsystem happened that really affected that specific driver it seems

17:51 <SpieringsAE> I really need to get to work on that driver, maybe a little project for this weekend

17:51 <alexVinarskis[m]> [@_oftc_robclark:matrix.org](https://matrix.to/#/@_oftc_robclark:matrix.org) could you try with this series? https://lore.kernel.org/all/20250417021349.148911-1-alex.vinarskis@gmail.com/

17:51 <alexVinarskis[m]> v2 of same series is part of Ubuntu's concept kernel, so maybe explains why it worked for me.

17:54 <robclark> alexVinarskis[m]: that looks relevant.. I'll give it a try soon

18:05 <JensGlathe[m]> just applied

18:12 <robclark> so I guess it seems likely for the right port to have an extra LTTPR on the i/o board after the ribbon cable

18:14 <JensGlathe[m]> sounds like it

18:14 <JensGlathe[m]> would be useful (but expensive) design

20:57 <JensGlathe[m]> 6.15.0-rc3-jg-2 is up on [googledrive](https://drive.google.com/drive/folders/1Lps5o3FXroAJFDiKj18vutJbC1uld49s?usp=sharing) and [github](https://github.com/jglathe/linux_ms_dev_kit/tree/jg/ubuntu-qcom-x1e-6.15.0-rc3-jg-2)

20:57 <JensGlathe[m]> changes: Added alexVinarskis LTTPR patchset

20:59 <JensGlathe[m]> as always, based on jhovold 's tree

21:00 <JensGlathe[m]> dp altmode definitely works better, had a case today where one of the type-c ports on the devkit didn't train after removing the NIC. Now it works as it should, again

21:07 <robclark> JensGlathe[m]: can confirm... with alexVinarskis[m] series all three usb-c ports are working (in either orientation)

21:15 <alexVinarskis[m]> Nice to hear, thanks for testing. I guess indeed they have yet another lttpr there...

21:17 <alexVinarskis[m]> Do they also work for you if you plug all three sequentially? When i tested, any last connector to be plugged in would be detected with valid resolution, but no image, stream just won't start. Might be a Wayland specific issue though.

21:45 <robclark> alexVinarskis[m]: no ordering issues that I could find.. g-s wayland, fwiw.. could be something was fixed, maybe rebasing on msm-next would fix that for you as well