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]>
as far as it's known and a fix is on the way I'm happy
<clover[m]>
steev what terminal emulator do you use?
<steev>
okay the battery is there
<steev>
i use alacritty myself
<steev>
gnome terminal works fine here too though
<clover[m]>
i must be missing some relevant power package maybe
<steev>
upowerd running?
<steev>
i woulda thought gnome would start it
<clover[m]>
ooo service not found
<steev>
service should be upower
<steev>
upowerd is the executable
<leezu>
hexdump0815: I've returned the Galaxy Book Go. Mainly as Lazor come with dts thanks to CrOS but I also found it has a better build quality and is cheaper. The only downside is 64GB emmc vs the 128GB ufs.
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
derzahl has quit [Remote host closed the connection]
<clover[m]>
yeah even with the service still shows 0% batter steev
<steev>
And you have the firmware files in /lib/firmware/qcom/LENOVO/21BX/ ?
<steev>
Can you pastebin your dmesg output?
richfree has joined #aarch64-laptops
<clover[m]>
alacritty is weird on this, it doesnt refresh the last thing you typed until you type the next thing lol
<bamse>
steev: and it's not actually showing the battery of the stylus if you have one of those closeby?
<steev>
bamse: i don't have a stylus at all (that i'm aware of)
<mahmoudajawad[m]>
I see. I was assuming manjaro for a second and wanted to confirm. Great news, as I'm monitoring the development of Linux for x13s. I'm hoping to get one if basic functions become available for it.
<steev>
mahmoudajawad[m]: i'm using debian stable on mine, and it's my daily driver
<steev>
i basically yanked out the other stuff, put the mailing stuff in, and removed all the stuff that was applied and then reverted later
chuckz has left #aarch64-laptops [Leaving]
<steev>
so i'm assuming ci is gonna mail me a few times yelling :P
<mahmoudajawad[m]>
steev: beside gpu, what doesn't work for you?
<steev>
audio, gpu
<steev>
wifi is a hack, but we're at the mercy of qualcomm there
<mahmoudajawad[m]>
I see. I was under assumption regular distros still don't go beyond boot screen on x13s. I was wrong. Maybe I should consider getting one already.
<bamse>
bt
<steev>
oh right, no bluetooth
<steev>
bluetooth, audio, gpu, but gpu and audio are close, with audio being closest
<mahmoudajawad[m]>
I see.
<mahmoudajawad[m]>
The device has sound jack, right? I can live without bt then.
<bamse>
steev: audio is up and running, so that's a matter of getting it upstream
flowriser has quit [Quit: Konversation terminated!]
hexdump0815 has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
Lucanis has quit [Ping timeout: 480 seconds]
<hexdump01>
jenneron[m]: travmurav[m]: i tried the mentioned values for the i2c kbd but nothing changes - i'm slowly coming to the conclusion that without some docs, schematics or sources it might be quite hard to move forward with the galaxy book go if one is not an re expert like the asahi experts :)
hexdump01 has quit [Quit: WeeChat 1.9.1]
hexdump0815 has joined #aarch64-laptops
<travmurav[m]>
hexdump01: I think acpi has i2c lines off by 1 according to the device addresses in acpi vs sc7180.dtsi
<travmurav[m]>
but mine had completely different line in dsdt compared to the reality
<travmurav[m]>
so worst case you could make 12 keyboard nodes and see which one probes :P
<travmurav[m]>
but yes, without schematics the task is significantly harder IMO
<hexdump0815>
travmurav[m]: i tried i2c7 and i2c6
<travmurav[m]>
theoretically the dsdt, w10 driver files and preferably high resolution photos of the mainboard would be enough to advance pretty far
<hexdump0815>
jenneron[m]: where did you have those reg and irq values from which you suggested to me?
<travmurav[m]>
(with the latter serving as a reference of what components exist)
<travmurav[m]>
hexdump0815: I think acpi spec defines how the function is called and what are the arguments, returns
<clover[m]>
<mahmoudajawad[m]> "I see. I was assuming manjaro..." <- I'm considering adding x13s as a community device to manjaro arm. Their community repository has a lot of useful stuff.
Lucanis has joined #aarch64-laptops
<clover[m]>
ok kitty is working much better than alacritty on gnome so far
<clover[m]>
./battery:26:in `to_i': NaN (FloatDomainError)
<clover[m]>
from ./battery:26:in `<main>'
<clover[m]>
from the ruby script
<steev>
it's pointing at ENERGY_NOW and ENERGY_FULL in yours?
<steev>
it's gonna be annoying if yours points at CHARGE_NOW and CHARGE_FULL unlike... everyone else that gets 0's out of them
<clover[m]>
meetings, i will have to check later
<steev>
or give me the output of grep '' /sys/class/power_supply/qcom-battmgr-bat/uevent
<clover[m]>
POWER_SUPPLY_NAME=qcom-battmgr-bat
<clover[m]>
POWER_SUPPLY_TYPE=Battery
<bamse>
is the adsp running and is pd-mapper in place?
<clover[m]>
how can i tell sir
<bamse>
what do you get if you run "qrtr-lookup" any reported services on Node 5?
pierro78 has joined #aarch64-laptops
<clover[m]>
um, what
<bamse>
the tool qrtr-lookup will list "qmi" services in the system...node address 5 is the entity that runs the battery firmware, so a quick check to see if the remoteproc is up is to run that and check for any services registered from that node
<HdkR>
clover[m]: Maybe, I don't use touchscreens so I wouldn't care either way :)
<jenneron[m]>
thanks, panel over drm works now
<jenneron[m]>
one more thing, flex 5g has no-hpd binding, how do i know whether i need it or not?
<clover[m]>
Leo does yours work?
<jenneron[m]>
bamse: ^
<szclsya[m]>
clover[m]: nope
<bamse>
jenneron[m]: it should reflect if the hpd signal is connected or not in your device
<bamse>
jenneron[m]: presumably though no-hpd should just work
<jenneron[m]>
it works without no-hpd
<bamse>
it might be that there's no difference in the qualcomm dp driver at the moment...
<jenneron[m]>
panel-edp.c uses some additional delays for hdp on this panel, though i use "wrong" compatible which refers to another panel with same timings for now
<bamse>
using the generic edp-panel compatible gives you the benefit that you only need to care about the timing of the power sequence...not the video timing
<jenneron[m]>
does it parse timings from edid?
hexdump01 has joined #aarch64-laptops
<qzed>
the video timings, yes
<qzed>
the power sequence timings aren't part of edid
<leezu>
robclark: Do you know if CrOS verifies/uses the hw video encoder on lazor? It turns out that ffmpeg hw accelerated encoding works on the qcom rb5, but hangs on lazor. So I wonder if the issue may not be with ffmpeg. On lazor, triggering the encoding process increases the venus /proc/interrupts by 16, then ffmpeg hangs, and upon hard exiting after Ctrl+C, venus interrupts
<leezu>
increase by another 8.
<robclark>
we defn use both hw vid enc and dec..
<robclark>
but I don't have something handy atm with combo of upstream kernel and CrOS userspace
<robclark>
(but chromeos-5.15 kernel should be pretty close to upstream and video was working there)
Lucanis has quit [Ping timeout: 480 seconds]
Penguinpee has quit [Quit: Leaving]
Penguinpee has joined #aarch64-laptops
pierro78 has quit [Remote host closed the connection]
<harvestz[m]>
is anyone using an external monitor with the x13s? I haven't kept up with all of the updates recently
Penguinpee has quit [Quit: Leaving]
<steev>
harvestz[m]: yes, though if you're using gnome, you need to patch mutter and rebuild it