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)
rpirea has quit [Quit: rpirea]
rpirea has joined #aarch64-laptops
rpirea has quit [Quit: rpirea]
rpirea has joined #aarch64-laptops
rpirea has quit [Remote host closed the connection]
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
<steev> damn this disappearing seccomp
rpirea has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
rpirea has quit [Quit: rpirea]
rpirea has joined #aarch64-laptops
rpirea has quit [Quit: rpirea]
rpirea has joined #aarch64-laptops
matthias_bgg has joined #aarch64-laptops
iivanov has quit [Quit: - Chat comfortably. Anywhere.]
iivanov has joined #aarch64-laptops
martiert_work has quit [Quit: WeeChat 3.8]
rpirea has quit [Quit: rpirea]
rpirea has joined #aarch64-laptops
<martiert> I think I see why I can't mount my installer disk on booting it now. The kernel logs out: `qcom_pmic_glink pmic-glink: Failed to create device link (0x180) with usb0-sbu-mux`, and the same with usb1-sbu-mux. Is this something people have seen before?
rpirea has quit [Quit: rpirea]
rpirea has joined #aarch64-laptops
iivanov has quit [Quit: - Chat comfortably. Anywhere.]
martin1 has joined #aarch64-laptops
martin1 is now known as martiert_work
rpirea has quit [Quit: rpirea]
rpirea has joined #aarch64-laptops
<jhovold> martiert: those device link errors are a known issue but should not prevent you from using usb
rpirea has quit [Quit: rpirea]
rpirea has joined #aarch64-laptops
rpirea has quit [Quit: Leaving]
rpirea has joined #aarch64-laptops
rpirea has quit []
rpirea has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
<martiert> damn, I was hoping those were the answer :P Guess I'll just have to dig more then
minecrell has quit [Read error: Connection reset by peer]
minecrell has joined #aarch64-laptops
matthias_bgg has quit [Ping timeout: 480 seconds]
matthias_bgg has joined #aarch64-laptops
<juergh> bluerise: I suspect your upgrade pulled in a new linux-firmware from the archive which doesn't have the a690 firmware. I'm in the process of updating the package in the x13s PPA.
<juergh> Ugh. alsa-ucm-conf also upgrades and looses the x13s patches. But I haven't gotten audio to work on Ubuntu yet anyways so not a big loss...
<ndec> juergh: do you still have the 'long delay' in the installer? Do you know what the problem is, and is it something we can help with?
<juergh> ndec: It might be the installer trying to reach the internet and eventually timing out. But I haven't really looked into it.
<ndec> ok, i haven't tried the installer image yet.. i still want to do that at some point. are you planning to build more images?
<juergh> I think so but am unsure about the timing. We're all a bit in a crunch atm with the Lunar release right around the corner.
<ndec> ok!
<steev> juergh: that shouldn't be too long though, upstream accepted the x13s patches
<steev> for alsa-ucm-conf i mean
bryanodonoghue4 is now known as bryanodonoghue
<juergh> steev: ah cool.
<juergh> I still need to figure out why alsa doesn't see any device on ubuntu though
<danielt> juergh: I'd love to hear if you figure out what brings it to life (I'm not seeing in my Debian system either).
<juergh> bluerise: Packages in the PPA are updated and I just upgraded Ubuntu on my x13s and it's still functional.
<steev> juergh: is needed for both mics, but otherwise, audio *should* work, unless there's something missing in the kernel config
<steev> on top of what is in alsa-ucm-conf upstream that is
<steev> and if you're feeling froggish, you could also try the 2 newest commits from which set default volumes
<bluerise> juergh: thanks! I'll run an upgrade and see what happens :)
matthias_bgg has quit [Ping timeout: 480 seconds]
<clover[m]> Steev are you still getting demon voice on mic?
<steev> i haven't tried recently, so maybe?
Lucanis0 has joined #aarch64-laptops
Lucanis has quit [Ping timeout: 480 seconds]
<steev> srinik: on the c630, i'm not getting audio, and we get a bunch of multimediaX -22's;
<steev> this is with today's next
<steev> the branch i'm using is with as my kernel config
<steev> i think it might be related to the patchset that adds all the missing multimedias so maybe it's just some ucm stuff needed?
<bluerise> juergh: worked for me :)
iivanov has quit [Ping timeout: 480 seconds]
hightower2 has quit [Ping timeout: 480 seconds]
<bluerise> there's still no one working on the windows dev kit with device trees, right?
hightower2 has joined #aarch64-laptops
<steev> not yet that i've seen
<bluerise> also hard to work on when the ACPI tables are bad and there's no other info available *shrug*
<steev> you could try asking microsoft politely for the schematics?
mohamexiety has joined #aarch64-laptops
<bluerise> Are they known to share?
<qzed> doubtful, but if you can find some contact and get somewhere, feel free to let me know, would be quite useful for some of the surface stuff as well xD
<bluerise> :D
<bluerise> don't worry, we'll spend a year one a machine to make it work halfway, and then a new version shows up. in perpetuity.
<qzed> yeah... I still believe that it might be easier in the long run to implement PEP support and deal with that ACPI stuff than having to write DTs for every model...
<qzed> but then again that is a ton of work and you'd need all the clock and regulator stuff anyway because their bloody ACPI doesn't do that
<qzed> also is this just qualcomm or does every ARM SoC manufacturer do this?
<bluerise> someone told me the windows drivers ship the actual acpi tables and they have an ACPI parser... so it's essentially ACPI overlays
<qzed> so from what I understand you essentially have some tables in ACPI that tell which devices need which regulators/clocks, then the PEP driver parses that and injects PM methods for the ACPI devices (or more directly in the windows PM API) and handles the PM stuff when anything requests it
<qzed> and besides all that there's still a ton of stuff like hardware addresses hard-coded in some drivers...
<bluerise> I was actually surprised when NXP released edk2 with ACPI to run windows on the i.MX8MQ
<qzed> (e.g. search for G0MD in, which seems to show the resources/states for the GPU, or part of it)
<bluerise> ah yeah
<qzed> I wanted to look into this at some point and maybe try to get some prototype working... but no time at the moment
<qzed> and as I've said, even when that would work, tons of drivers need changes or some hard-coded addresses... which means you'd have to adjust drivers for each SoC generation and probably write half a DT again...
<bluerise> Guess I'm in my ARM midlife crisis now. Sounds like too much work ;)
<bluerise> the MNT Pocket Reform tempts me
<bluerise> I just hope I'll get the CM4 adapter soon so that I can use the RK356x instead of an i.MX8M*
jelly has quit [Remote host closed the connection]