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)
<steev> jhovold: something i just noticed... why does the bluetooth address get set... backwards?
<steev> steev@wintermute:~/kernels/next$ hciconfig -a | grep BD\ Address
<steev> steev@wintermute:~/kernels/next$ sudo btmgmt public-addr F4:A8:0D:30:A3:47
<steev> BD Address: 47:A3:30:0D:A8:F4
amstan has joined #aarch64-laptops
<amstan> steev: big endian little endian?
<amstan> though that's interesting given that it's 6 bytes not 8
<amstan> i wonder where the 00 comes from and goes to
<steev> hm, maybe
<steev> but bluetooth is always 6, no?
hightower2 has quit [Ping timeout: 480 seconds]
<amstan> yeah
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
agl7-x13s has quit [Quit: Leaving]
agl7-x13s has joined #aarch64-laptops
agl7-x13s has quit [Quit: Leaving]
agl7-x13s has joined #aarch64-laptops
<steev> clover[m]: can you grab the qcvss8280.mbn outta windows and throw it into your x13s-firmware repo?
<clover[m]> Yeah
<clover[m]> Tomorrow
hightower2 has joined #aarch64-laptops
hightower2 has quit []
<jhovold> HdkR: that's correct, it's using v4l2 so there is still work to be done in user space...
<jhovold> ajhalaney[m]: we'll try to get camera working in some form even if that too may be a little rough initially, we'll see
<jhovold> steev: yeah, that's very confusing indeed, you need to reverse the address you pass to btmgmt
<HdkR> Reasonable
<jhovold> apparently it expects a little endian address, which is then mostly printed as big endian
<steev> udev is being a pita too
<steev> ACTION=="add", SUBSYSTEM=="bluetooth", ENV{DEVTYPE}=="host", \
<steev> ENV{DEVPATH}=="*/serial[0-9]*/serial[0-9]*/bluetooth/hci[0-9]*", PROGRAM="/usr/bin/btmgmt -i %k public-addr 47:A3:30:0D:A8:F4"
<jhovold> steev: you can't use udev for btmgmt either i'm afraid, not without further hacks anyway...
<steev> weird
<jhovold> it's because the intersting ways the bluetooth subsystem works, it registers the device before it's been initialised
<steev> because if i manually run sudo udevadm test /sys/class/bluetooth/hci0... it runs fine?
<steev> ahhh
<jhovold> you should be able to hack something up using netlink, but someone really should work on fixing bluetoothd for this
<steev> yeah, there's actually a bug upstream about it
<jhovold> so that the daemon can set a previsouly provided address, or a random one until then
<jhovold> steev: heh, i just copied that URL to my clipboard :)
<steev> i guess i can do the systemd unit
<jhovold> Hans has looked into the issue and provided some background there
<jhovold> juergh: this is perhaps something that canonical can help out with (i.e. patching bluetoothd)?
<jhovold> we still hope to be able to set the BD_ADDR from the driver at some point, but until then, and for other platform it would be good something like hans suggested in bluetootd
<steev> yeah, it's actually fine, i just didn't realize couldn't do btmgmt from a udev rule
<jhovold> steev: i too gave that a try before figuring out why it did not work
<steev> ah well, i need to get to bed, actually doing some training tomorrow and should probbly focus on that
<steev> i will poke and prod tomorrow after family dinner
<juergh> jhovold: I'll take a look next week. I'm lacking the context and need to read through the backlog first.
<jhovold> juergh: the issue relates to bluetooth controllers without a valid device address, which the user need to provide before starting the device
<jhovold> it would be good if this could be automated by bluetoothd so that it either configures the device using a previsouly provided address or falls back to a random one
<jhovold> due to how the bluetooth subsystem works, a simple udev rule is not enough, and I assume distros need this to work seemlessly
<jhovold> Hans de Goede from Redhat has provided some details here: https://github.com/bluez/bluez/issues/107
<juergh> That helps, thanks.
iivanov has joined #aarch64-laptops
iivanov has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
Lucanis has joined #aarch64-laptops
Lucanis0 has quit [Ping timeout: 480 seconds]
<agl7-x13s> Know someone where I can define that under /boot not the name "vmlinuz-6.3.1" is used, but "vmlinuz-6.3.1-steev". I once knew this, but no longer know. Have already searched but I can not find it!
<steev> when you build the deb, set LOCALVERSION="-steev"
<agl7-x13s> steev: Oh thank you, I have it found under General in "make menuconfig"!
<steev> that works too :)
<agl7-x13s> steev: Now it shows:
<agl7-x13s> ag@Debian-x13s:/Software/kernel_und_altest_System/steev-kernel$ ll *steev*
<agl7-x13s> -rw-r--r-- 1 ag ag 8249596 5. Mai 18:40 linux-headers-6.3.1-steev_6.3.1-2_arm64.deb
<agl7-x13s> -rw-r--r-- 1 ag ag 9603332 5. Mai 18:40 linux-image-6.3.1-steev_6.3.1-2_arm64.deb
<agl7-x13s> ag@Debian-x13s:/Software/kernel_und_altest_System/steev-kernel$
<steev> yep, that's how it works :)
<agl7-x13s> steev: I have install it with apt and now your kernel is on the top of the grub menu :)
<steev> Woo! Soon enough, that won’t be necessary.
rfs613 has quit [Ping timeout: 480 seconds]
<agl7-x13s> steev: Why?
<steev> Because at some point everything will be in the kernel proper
<agl7-x13s> ok
* jbowen crosses fingers
rfs613 has joined #aarch64-laptops
<steev> i think... i'm gonna try and poke my head into the alsa configs, because yeah... the volume is just too low. i'm currently going through a training on the x13s and i can barely hear the instructor
<agl7-x13s> steev: I don't know if you saw this, in the sound mixer and only there you can increase up to 150%, then it goes so reasonably.
<agl7-x13s> i mean the volume to increase
<steev> si, but i'd like to not have to do that :) it would be nice to have good workable defaults
<agl7-x13s> steev: In Windows 11 the volume is louder, but I still have to set it to full volume so that it has at least room volume.
<steev> yes, we can go louder by default, we just don't
<steev> or whoever wrote the initial stuff didn't have a loud place that they were at ;)
<agl7-x13s> steev: Then the person must have very good ears if the volume is enough for him ;-)
<agl7-x13s> OK, I go now back at home. I'am in the clubhaus. See you later ....
<agl7-x13s> steev: In the last nights I have slept little. I will go to bed early today. Here in Central Europe it is now 9:28 pm. I will go to bed around 10 pm. Good night.
<steev> sleep well
<agl7-x13s> Thanks
agl7-x13s has quit [Quit: Leaving]
agl7-x13s has joined #aarch64-laptops
<agl7-x13s> steev: I have tried the kernel 6.3.1 from kernel.org on the ThinkPad X13s but this kernel doesn't start. Grub loads the files and the dtb file and then ist nothing.
<steev> well yes, all the support isn't there yet
<agl7-x13s> steev: Your kernel starts! (This is running now).
<steev> maybe a vanilla 6.5 will
<agl7-x13s> what's man "vanilla" ?
<agl7-x13s> means
<steev> vanilla = no patches
<steev> actually
<agl7-x13s> ok
<steev> you probably need to add arm64.nopauth and efi=noruntime
<steev> to your cmdline to run vanilla 6.3.1
<agl7-x13s> Is the kernel 6.3.1 from kernel.org the vanilla kernel?
<steev> it's a vanilla one yes
<agl7-x13s> I try the two kernel parameter and then I go to bed ...
agl7-x13s has quit [Quit: Leaving]
agl7-x13s has joined #aarch64-laptops
<agl7-x13s> steev: The vanilla kernel 6.3.1 from kernel.org does no start but ist resetzt after 2 seconds the x13s and then I'am in the UEFI-Bios and it starts new. It's not yet ready. Your kernel runs without any problems.
<agl7-x13s> s/no/now/
<steev> yeah, that's not unexpected at all
<agl7-x13s> OK, Good Night!
agl7-x13s has quit [Quit: Leaving]
exeat has joined #aarch64-laptops
<exeat> I wanted to play with the hw video decoding but my copy of windows fell victim to "nvme format" long ago. Luckily, the firmware can be extracted from a recovery usb drive.
<exeat> % 7z l sources/Reconstruct.WIM | grep qcvss8280.mbn
<exeat>
<exeat> 2022-09-08 15:03:22 ....A 2035748 650854 Windows/System32/qcvss8280.mbn
<exeat> Having tried a few test videos, it seems I get lots of errors. "mpv --hwdec=v4l2m2m-copy" usually segfaults inside libavcodec; "ffplay -vcodec <codec>_v4l2m2m -i ..." usually prints several "capture: driver decode error" messages (with corrupted video or long pauses but no segfaults). This is on x11, on up-to-date debian unstable, with the test videos from https://telecommunication-telemedia-assessment.github.io/AVT-VQDB-UHD-1/. I
<exeat> wonder what I'm doing wrong.
<clover[m]> <steev> "clover: can you grab the qcvss82..." <- do you know where it resides in the windows FS
<clover[m]> oh idk if you guys get matrix replies. steev this is in response to the qcvss8280.mbn request
<konradybcio> C:\Windows\system32
agl7 has quit [Quit: bis denne]
<steev> driverstore\filerepository\qc<something_arm64_<hash>\
<steev> if you have wsl, you can find it in there based on name
laine has quit [Ping timeout: 480 seconds]