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)
<szclsya[m]>
updated to 1.19 via downloading separated driver from support page, works fine
<AlexMarty[m]>
<steev> "Alex Marty: if you don't mind..." <- I don’t want it drawing power at all if possible
<steev>
AlexMarty[m]: not sure if it draws power still or not, but i believe, if you just edit line's 345 and 354... no wait, wrong kernel - 350 and 359 and change the "okay" to "disabled"; that should disable the nodes and not draw power, but mani_s or bamse or even possibly robclark would know better
<AlexMarty[m]>
Sounds good. I’ll try that at first and use a multi meter to see what the draw is if any
<steev>
i really can't see the touch screen portion taking that much though
<clover[m]>
<szclsya[m]> "updated to 1.19 via downloading..." <- Tried that too. Thanks for testing
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
jhovold has joined #aarch64-laptops
c00k has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
matthias_bgg has joined #aarch64-laptops
srinik has quit [Killed (NickServ (Too many failed password attempts.))]
srinik has joined #aarch64-laptops
matthias_bgg has quit [Quit: Leaving]
matthias_bgg has joined #aarch64-laptops
EdLin has joined #aarch64-laptops
EdLin has quit [Quit: Konversation terminated!]
EdLin has joined #aarch64-laptops
EdLin has quit [Quit: Konversation terminated!]
<jhovold>
steev: I've updated the 20220720 branch with a fix that addresses a race when probing both touchpad variants in parallel that can result in an interrupt storm at boot and non-functional touchpad. https://github.com/jhovold/linux/commits/wip/sc8280xp-20220720
FizzBuzz has joined #aarch64-laptops
<steev>
ooh
jlinton has joined #aarch64-laptops
<steev>
i wonder if that's the thing i get on the flex5g where occasionally on boot it fails to have touchpad
<jhovold>
steev: if you have an alternate touchpad defined in DT then that wouldn't be surprising
<steev>
jhovold: indeed we do on the c630 (never seen there), the flex5g (seen somewhat often actually), and the thinkpad
<maz>
they'd need to share an interrupt for this to happen though.
<steev>
hm
<jhovold>
right, as a second-source touchpad typically would
<FizzBuzz>
Has any work been done for compatibility with the fancy HP folio?
<steev>
not i
<clover[m]>
>I am not experienced in the arm64 world. Is there no perspective on getting the dt fixup protocol into place in your environment?
<clover[m]>
- Poettering
<clover[m]>
~ Poettering
<clover[m]>
* > I am not experienced in the arm64 world. Is there no perspective on getting the dt fixup protocol into place in your environment?
<steev>
what kind of pull does he think a few of us consumers have?
<steev>
but the answer will be no, because even if we got the thinkpad to do so, the flex 5g and the c630 are both EOL already and they won't be doing bios updates for them
<qzed>
steev: I feel that's a common theme with those devices...
<steev>
you aren't wrong
<qzed>
I mean, sure would be great to have firmware that actively supports it, but people please be realistic, those are WoA devices, they've been around for a while... most vendors don't care much about linux and we're unfortunately a pretty small minority
<qzed>
even if we could convince qualcomm to fix it, we'd have years of devices that would need updates from vendors, or we'd need to decide to actively not support them :/
<steev>
or just tell people to stop using software that is end-user hostile
<qzed>
I fear those WoA shenaningans will unfortunately stick around, unless MS puts their thumbs down
<steev>
unfortunately, the contacts i have at MS do not have that kind of pull :(
<qzed>
yeah.. I think changing that would require absolutely massive amounts of pull...
<qzed>
we'll probably need to open that can of worms for ACPI PEPs at some point... if we ever want to stop writing DTs for every new model
<danielt>
I thought the Extensible in EFI means that, technically speaking, something like DtbLoader could implement the DT fixup protocol if one really needed... the problem is more that writing EFI extensions isn't very many programmers idea of fun so the volunteer pool will likely be very small!
<robclark>
Yeah, DtbLoader (or something else) could install the protocol.. but also seems like an eminently reasonable thing for a bootloader to conclude that lack of fixup protocol means there is no fixup to do ;-)
<qzed>
Plus, GRUB does support DTs without that protocol. Which means you can use it without DTBLoader if you want to (e.g. for testing or temporarily when installing).
<steev>
clover[m]: silly question but is windows itself fully up to date? not just the lenovo vantage stuff
<steev>
it *shouldn't* matter
<clover[m]>
yes i check my windows updates daily
<AlexMarty[m]>
I skip grub and use the stubs directly
<janrinze>
before it would be possible to add the dtb in the kernel and firmware as well.. the kernel will always start /sbin/init unless init= is given. Nowadays we see that systemd is being used for just about anything.. I would not be surprised if they added busybox inside systemd.
<steev>
AlexMarty[m]: right, and thats where the issue is, it won't load the dtb because the uefi firmware says it doesn't support dt_fixup
<steev>
broonie: srinik: where can i find the actual error code that's supposed to be printed?
<AlexMarty[m]>
steev: On the x13s? I guess I’m a bit confused because efibootmgr had no problem setting a boot entry with a path to the dtb
<steev>
AlexMarty[m]: i'm not sure, clover was having issues loading the dtb and it would simply spit out "Unsupported"
<clover[m]>
i think the issue is specific to systemd-boot
<AlexMarty[m]>
Well if you want to try stubs I know how to set it up
<clover[m]>
thanks, i wanted to use systemd-boot cause it has nice features for dual-booting, like rebooting into windows with a command
<AlexMarty[m]>
I see. Makes sense. That would be handy
<danielt>
Is anyone able to rebuild sd-boot. I'm reasonly sure that if you just comment out the if() EFI_UNSUPPORTED at the beginning of devicetree_install() then it would work just fine ;-)
<danielt>
state->orig isn't used unless we try to cleanup (which I suspect will only happen if the kernel doesn't boot).
<clover[m]>
nice find
<danielt>
Only if I am right ;-)
<steev>
i'm sure one of the "silly" ARCHers can do it ;)
<robclark>
danielt, clover[m]: ahh, I guess that means you need to use DtbLoader.. which tbh would I suppose have the advantage of standardizing things across different bootloaders
<danielt>
robclark: Yep... if DtbLoader were in the chain then I think things might work too.
matthias_bgg has quit [Quit: Leaving]
<steev>
jhovold: are you just using the defconfig?
FizzBuzz has quit [Ping timeout: 480 seconds]
iivanov has quit [Quit: Leaving...]
neobrain has joined #aarch64-laptops
FizzBuzz has joined #aarch64-laptops
<clover[m]>
replacement x13s ordered, i guess i couldn't get 5G model
<clover[m]>
i also really hope they can refurbish or fix mine and it doesnt become e-waste :\
<HdkR>
I noticed on the X13s that Natural scrolling can't be disabled in the settings panel. Is this from a missing package or something steev?
<steev>
HdkR: the one where scrolling up goes down?
<HdkR>
right
<steev>
definitely works here
<HdkR>
Weird, the toggle in the settings menu changes nothing
<steev>
are you sure you're on the touchpad and not the touch screen
<HdkR>
...
<HdkR>
I was under Mouse, Not Touchpad
<steev>
you should turn it off there too :P
<steev>
no idea who thought "natural" scrolling was natural, but it's absolutely not
<HdkR>
Who the hell would want natural scrolling on a scroll wheel. wtf
<HdkR>
Alright, so GPU is the only thing remaining then :D
<steev>
yeah sorry, i'm busy doing "stuff" so i haven't gotten to looking more than the minor modifications to maximillian's patch (i don't wanna ping him)
<HdkR>
Dang stuff, I understand that
<clover[m]>
<HdkR> "Alright, so GPU is the only..." <- i'd personally like to add bluetooth and USB-C DisplayPort Alternative Mode for multi-monitor setups to the wish list :P
<steev>
neither of you asking for suspend smh
<clover[m]>
oh yeah, that too. i don't want to sound too greedy though
<HdkR>
clover[m]: None of those things matter to me as a immediate need development machine :P
<robclark>
HdkR, bamse: fwiw, educated guess for userspace part for a690 .. not completely sure about the RB_UNKNOWN_8E04_blit bit but if that isn't right we might need somehow to get a cmdstream trace..
<qzed>
yeah, to make sure the edp worked, had some issues with that
<qzed>
or do you already have that running?
<HdkR>
I don't even know what the internal display is using on the X13s but I can see things from it
<qzed>
if you haven't set anything wrt the gpu or panel up, it's probably using simplefb... if you've already defined the panel and hooked it up to the display controller stuff it should be using that
<qzed>
no clue what the status is on the x13
<HdkR>
Guess that makes sense
<szclsya[m]>
yeah, it should be using framebuffer by efi and render everything with Mesa's software renderer
<qzed>
IIRC that patch is essentially for checking that the edp connection between gpu / display controller and panel is good
<qzed>
`/sys/kernel/debug/dri/0` is what you want to look at, I think
<qzed>
so if things work there should be stuff in `/sys/kernel/debug/dri/0/msm_dp-eDP-1` (numbers may be different), the dp_debug thing should then enable the test pattern
<qzed>
ah no wait, wrong entry, dp_debug gives info about the connection / panel
<qzed>
msm_dp_test_active is for the test pattern
<steev>
qzed: oh right, let me pull that in too
<steev>
or well, eventually... once its charged because the battery died while i was out playing with the neighbor's puppy
<HdkR>
Oh cool, pulled that patch and I got a test image
<steev>
i have a few more patches locally i haven't pushed
<steev>
i'd love to push the next stuff jhovold has but for whatever reason i can't get remoteprocs
<steev>
since that's much closer to upstream
<steev>
mostly holding off waiting on either -rc9 or rc going away before pushing them
<steev>
it's not super big though, just the patch jhovold mentioned to deal with possible interrupt storm, and changing your patch for a690 to... try to use the a690 firmware not a660
<steev>
i started poking at the dts but then work stuff
<HdkR>
Dang work stuff always getting in the way
<harvests[m]>
is rc9 / rc going away on Sunday?
<harvests[m]>
just started keeping up with linux kernel developments after grabbing the x13s lol