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)
laine has joined #aarch64-laptops
laine has quit [Remote host closed the connection]
<HdkR>
Still hoping for vaapi support at some point :)
<quinine>
it will depend on how much totk will take up my time. :D
<steev>
jhovold: it doesn't not work... i just don't fully understand it - if you just put "local-bd-address;" in there, it chooses one completely at random i think? - i might be misremembering and all i had done was local-bd-addres = "XX:XX:XX:XX:XX:XX"; you're supposed to do "local-bd-address = [ XX XX XX XX XX XX ];" which seems odd since it's like the only thing that uses that way
<travmurav[m]>
steev: the property is a byte array and not a string so bytes notation would be correct, not the string with 3x amount of bytes
<steev>
yeah, i just wasn't expecting it :)
<steev>
i also don't wanna push it out to just use my bdaddr, otherwise we're pretty much at the same point as the 00:5A:AD one
<travmurav[m]>
Yeah, but if jhovold says the "linux mode" patches it, I expected it to at least set a stable address from local pool (02:00:xx...)
hightower2 has joined #aarch64-laptops
<steev>
i don't believe it does?
<travmurav[m]>
ah, maybe I misunderstood the thread
<steev>
you can set one via local-bd-address, and it'll generate a random one if you do something like i did (local-bd-address = "bl:ah...";) i can rebuild with just 'local-bd-address;' in there and see what we get, my bios is set to linux mode
<travmurav[m]>
Nah, I was just wondering how far does Lenovo firmware (that are actually cooperative) go in terms of handling Linux things and mac addresses just came to my mind since we provision them in the bootloader on old platforms and I was thinking of doing something similar on my 7c laptop too
<steev>
putting just local-bd-address does not set a random one, you end up with the 5a:ad
<steev>
i just do the btmgmt public-addr in my rc.local
<Bioxvirizm-x13s[m]>
Can you please tell me what depends on the battery consumption in sleep mode? And is there any way to fix it?
<jhovold>
steevm, travmurav[m]: local-bd-address should only be used if we had a boot firmware which could fill in the right address, which we do not
<jhovold>
we'll try to add driver support to retrieve the correct address at some point, but until then it needs to be set by user space
<jhovold>
either manually using btmgmt, or by some home brewed udev/systemd script until bluetootd leans how to handle this properly
<jhovold>
as a local hack, you could set local-bd-address for your own kernel builds, but providing a default one for everyone to use is indeed not better than sticking with the fw default one
<jhovold>
steev: ^
init_x13s has joined #aarch64-laptops
init_x13s has quit [Remote host closed the connection]
init_x13s has joined #aarch64-laptops
<exeat>
BTW, yet another method of setting the public-addr is with a service drop-in (e.g. /etc/systemd/system/bluetooth.service.d/public-addr.conf):
<exeat>
[Service]
<exeat>
ExecStartPre=-/sbin/rfkill block bluetooth
<exeat>
ExecStartPre=-/sbin/rfkill unblock bluetooth
<exeat>
(The rfkill commands should allow changing that address at any time by restarting the service)
init_x13s has quit [Remote host closed the connection]
init_x13s has joined #aarch64-laptops
<init_x13s>
the set public address fix worked to restore BT. I find the execstartpre method to be easier to remember than the udev/systemd service combo. both works.
pundir has joined #aarch64-laptops
init_x13s has quit [Remote host closed the connection]
<Bioxvirizm-x13s[m]>
* use open-lens? https://github.com/MuhammedKalkan/OpenLens does not run on x13s, is there a bug in the underutilized Linux or a bug in the program?