ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Chrome OS Trogdor Devices - Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630 - Lenovo ThinkPad X13s - and various other snapdragon laptops) - https://oftc.irclog.whitequark.org/aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
echanude has quit [Ping timeout: 480 seconds]
<dgilmore>
Is there a doc somewhere on what bootargs are needed for the t14s?
_whitelogger_ has quit [Remote host closed the connection]
nothorseface has quit []
_whitelogger_ has joined #aarch64-laptops
Caterpillar has quit [Quit: Konversation terminated!]
nothorseface has joined #aarch64-laptops
_whitelogger_ has quit [Remote host closed the connection]
nothorseface has quit []
_whitelogger_ has joined #aarch64-laptops
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #aarch64-laptops
<robclark>
dgilmore: potentially dtb=...whatever.. if you are loading dtb that way.. plus `clk_ignore_unused pd_ignore_unused`
<robclark>
I guess at some point the _ignore_unused stuff should go away
<dgilmore>
robclark: I have grub loading the dtb, and passing in "clk_ignore_unused pd_ignore_unused arm64.nopauth efi=noruntime rd.driver.blacklist=qcom_q6v5_pas rd.driver.blacklist=msm"
chrisl has joined #aarch64-laptops
<dgilmore>
the screen turns off and then the system resets
<robclark>
the nopauth and noruntime stuff should not be needed on x1 stuff, fwiw.. but they shouldn't be causing reset
<dgilmore>
maybe I need to get some firmware from windows?
<robclark>
there is defn some fw from windows needed.. although I don't _think_ it should cause reset
<robclark>
maybe start w/ jhovold's kernel
<robclark>
iirc there were some sharp edges with 64G devices (but I think that was in grub) and t14s oled panel (needs a hack)
<robclark>
I believe cwabbott is running fedora on t14s (but with his own kernel)
<dgilmore>
I have a 64G device
<robclark>
iirc there was some grub hack needed.. but I think that was for a reset before even the kernel started
<dgilmore>
I built a custom disk image, with a grub I built and a kernel built by Kevin Fenzi that is rawhides kernel with jhovold's patches on top
<dgilmore>
grub has the hack needed
<robclark>
oled panel?
<dgilmore>
nope, I did get the touch screen
chrisl has quit [Ping timeout: 480 seconds]
<robclark>
does init=/sbin/sh work (ie. keep the screen on and not reset)?
<dgilmore>
it does not
<dgilmore>
not blacklisting msm gets the screen on a smidge longer, but it still shuts off and the system resets
<robclark>
pretty sure you'll need msm to keep the display on, or at least I haven't tried without.. but I don't think that explains the reset.. does it get far enough to write anything into journal?
<dgilmore>
need to use a different computer to check, the volume group name conflicts with my laptop
<robclark>
I guess the other thing to note, if you are booting off of usb-c I think there is still some potential for lols when something (maybe adsp?) loads and usb getting reset.. I don't really remember the details, I've been booting off of nvme for quite a while now
<robclark>
jhovold might be more familiar with the current state
<dgilmore>
I am using usb-c
<dgilmore>
I need to sit down and make lorax copy the dtb files into the livecd and installer isos
<dgilmore>
going to rebuild the image without lvm
_whitelogger_ has quit [Remote host closed the connection]
chrisl has joined #aarch64-laptops
_whitelogger_ has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<dgilmore>
no journal saved. I did record a video of booting, last thing on the screen was the usb drive being mounted
echanude has joined #aarch64-laptops
<cwabbott>
dgilmore: I am running fedora with the kernel from jhovold, I haven't tried 6.12 yet though
<cwabbott>
I had the one with the oled screen where you have to revert the commit enabling external dp because it breaks the built-in screen for unknown reasons
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #aarch64-laptops
<dgilmore>
That may be next step.
<dgilmore>
6.12 was very unhappy on my ampere desktop this week
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #aarch64-laptops
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #aarch64-laptops
tobhe_ has joined #aarch64-laptops
tobhe has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
Segfault[m] has joined #aarch64-laptops
<Segfault[m]>
did the x13s-specific wifi/bt firmware ever get upstreamed?
chrisl has quit [Ping timeout: 480 seconds]
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
_whitelogger_ has quit [Remote host closed the connection]
<craftyguy>
Yeah that fw has been in linux-firmware for a while now
<craftyguy>
except maybe not some specific bt fw that I use to fix some range issue. i guess that hasn't been sent yet
_whitelogger_ has joined #aarch64-laptops
_whitelogger_ has quit [Remote host closed the connection]
<bamse>
wifi yes for a while, bt arrived earlier this week
_whitelogger_ has joined #aarch64-laptops
<Segfault[m]>
oh bluetooth is in now? good timing lol
alfredo has joined #aarch64-laptops
hexdump0815 has joined #aarch64-laptops
<steev>
yeah, the windows fw was submitted to l-f recently, hopefully will be in the november release, and qcom submitted a patch that lets us use it
<steev>
for bluetooth*
hexdump01 has quit [Ping timeout: 480 seconds]
<bamse>
finally figured out which strings to pull to get that done
<Segfault[m]>
heh i'm just glad qcom haven't completely forgotten the x13s now that x1e is out
<bamse>
Segfault[m]: i'm still relying on x13s for daily driving, so we won't forget it just yet
<bamse>
although i'm hoping we can finally make some progress on the suspend issues
<bamse>
and now that we have working bt, i really would like mac address support ;)
<travmurav[m]>
probably enough to make DEBUG=1 and "load dtbloader.efi" in efi shell to see it print the macs it found
<travmurav[m]>
that is, assuming the correct dtb is somewhere on the same partition
<travmurav[m]>
for devices with emmc/ufs this would lookup DPP using gpt label but for spi flash I don't know how to find it proeprly so I just loop through all and find which starts with the magic value
<travmurav[m]>
sadly I don't have any spi devices to test myself
<bamse>
ohh, very cool!
<bamse>
i was hoping though that we could figure out how the protocol works to read out the data, so that we can put that in the kernel...and that it is feasible to put in the kernel...
<bamse>
travmurav[m]: so the DPP isn't encrypted or anything when it resides in UFS?
<travmurav[m]>
I guess the funny problem is that, afaiu, for spi it would go through tz but for emmc/ufs the os needs to access it
<travmurav[m]>
yes, it's just plain binary
<bamse>
i always assumed it went through tz in both cases
<travmurav[m]>
well it probably is and then tz calls back to the os to indirectly access the storage backend, that'd be my guess at least
<travmurav[m]>
so i.e. on linux we don't have a way to allow qsee to access ufs/emmc/rpmb and I guess unless it has cached the data, it won't work?
<bamse>
correct
<bamse>
there's an effort to figure out how to upstream the smc-invoke tee interface, which should allow us to create a userspace thingie to provide that access...
<travmurav[m]>
oh that's very cool to hear
<bamse>
but i don't have a timeline for that, or a good sense if there's a plan for the second part of that plan
<Segfault[m]>
<bamse> "although i'm hoping we can..." <- does anyone know what's causing the high power draw yet?
<bamse>
Segfault[m]: yes...
<travmurav[m]>
bamse: but also about dpp, there is something called "DppDxe" in uefi capsule and the DPP thing contains windows activation key acpi table so I assume uefi uses that driver to read dpp, tho I didn't bother trying to decompile it, as staring at the dpp binary itself and guessing what offsets do what seemed to be enough
<travmurav[m]>
bamse: perhaps you/someone at quic who has access to firmware sources could look how it works and see if my guess for data structures was right/wrong
<Segfault[m]>
oh interesting
<travmurav[m]>
or if there is perhaps some protocol installed that makes it trivial
<bamse>
Segfault[m]: if you remove those issues and change that icc vote as necessary, we're consuming considerable less power
<Segfault[m]>
i guess it figures that it'd be a pcie issue, seeing as other qcom devices without pcie don't seem to have the same high power draw
<bamse>
travmurav[m]: the answer i was looking for is not in dppdxe
<travmurav[m]>
sad
<travmurav[m]>
actually I guess if you say it goes via tz, it might not even contain the data structures...
<bamse>
well, i know we can't access spi-nor from linux...beyond that i don't know
<travmurav[m]>
right
<travmurav[m]>
bamse: well I guess short term workaround of passing it via dt might be good enough, tho I guess windows does access those files /somehow/
<travmurav[m]>
sad upower deleted the "old" charging history data so I don't have a nice graph of the device discharging after I last charged it on 6th and left in suspend 'til today
<bamse>
ohh and speaking of x13s; now that v6.12 is coming up, don't miss that "pacman -S linux-aarch64" is now functional...if you run arch, btw
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #aarch64-laptops
_whitelogger_ has quit [Remote host closed the connection]
alfredo has quit [Quit: alfredo]
_whitelogger_ has joined #aarch64-laptops
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #aarch64-laptops
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #aarch64-laptops
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #aarch64-laptops
<Segfault[m]>
<bamse> "Segfault: if you remove those..." <- do you know off hand what those issues are? like is it something specific to certain devices or is it just a general issue with how qcom pcie suspend is handled at the moment?
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #aarch64-laptops
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #aarch64-laptops
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #aarch64-laptops
kuruczgy[m] has joined #aarch64-laptops
<kuruczgy[m]>
I am also interested in the status of suspend power draw on the x1e. Is it the same issue as on the x13s, or are there further problems that need to be solved?
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #aarch64-laptops
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #aarch64-laptops
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #aarch64-laptops
SpieringsAE has joined #aarch64-laptops
<SpieringsAE>
So I sent this patch (input subsystem), a week ago, but there is no response yet, is that normal and am I just too impatient or may it have fallen through the cracks
<SpieringsAE>
I did a tiny oopsie in it so I kind of want to make a v2, but I don't want to annoy the maintainer
<travmurav[m]>
week is too short probably but if you have something to fix, better fix it right away and send a v2
<travmurav[m]>
as in, week is not "too long" to not get a reply
<SpieringsAE>
okay thanks, then I'll just send a v2 without the reply
<SpieringsAE>
is Dmitry Barishkov also in this irc?
<SpieringsAE>
don't quite have a map of mailing list to irc name in my mind yet
<travmurav[m]>
yes, lumag
<SpieringsAE>
neat lumag: do you mind me sending in a patch that adds my asus to the list in qcom_scm.c? This would cause a conflict with your current patch that generalizes this file
<SpieringsAE>
I saw that patch series ran into a bit of a showstopper for now, so I don't know how long it will be till that happens
jhovold has joined #aarch64-laptops
<JensGlathe[m]>
SpieringsAE: right, vivobook is not in there. You could send a patch though, since vivobook is upstream
<JensGlathe[m]>
interestingly, in qcom.yaml it is there
<SpieringsAE>
I don't mean to cause issues, I don't even know if I should be worrying about this
<JensGlathe[m]>
I guess this won't be an issue. This is a good refactoring, makes things easier. Maintainers will take care of eventual conflicts as long as its not upstream
<SpieringsAE>
oki
SpieringsAE has quit [Remote host closed the connection]
SpieringsAE has joined #aarch64-laptops
<SpieringsAE>
tobhe_: I was informed that there were some updates to the asus dtb on the ubuntu concept, is there anyone planning on upstreaming those? One of those is the lid switch which I also found out, don't want to steal anyones thunder by sending that in before them
tobhe_ is now known as tobhe
<tobhe>
SpieringsAE: I think I only have one bt patch that I copied over from another dt
<tobhe>
anyway, no need to worry about stealing anything. I am happy to see things making it to the list and I'll eventually drop the patches for what's in mainline
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #aarch64-laptops
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #aarch64-laptops
SpieringsAE has quit [Quit: SpieringsAE]
SpieringsAE has joined #aarch64-laptops
<SpieringsAE>
about that bluetooth, it doesn't seem to be working for me, but I don't know why https://pastebin.com/KHGLSaQ9
<SpieringsAE>
everything (bluetooth related) looks good to me
nothorseface has joined #aarch64-laptops
<tobhe>
hm someone on the bug tracker said they got it working
<SpieringsAE>
well, I must be doing something wrong then it seems to find all of the right firmware, maybe a missing kernel config?
<SpieringsAE>
this is the only weird thing I see: [ 4.892126] Bluetooth: hci0: Frame reassembly failed (-84)
<SpieringsAE>
but that happens before the firmware is even downloaded, maybe I need to run some command to set up the mac addres, I've seen some stuff about mac addresses not being available
<SpieringsAE>
some hciconfig thing
<tobhe>
i don't remember enabling any specific config option
<tobhe>
mac address could be
<tobhe>
does btmgmt info show anything interesting?
<SpieringsAE>
yeah btmgmt does show something now, but blueman isn't working
<SpieringsAE>
Maybe I made the wrong observation
<SpieringsAE>
I maybe stupid
<SpieringsAE>
yep I'm an idiot, bluetooth.service wasn't running, I thought that would have been enabled automatically but nope
<SpieringsAE>
yep bluetooth audio working neat
nothorseface has quit []
<tobhe>
yay :)
_whitelogger_ has quit [Remote host closed the connection]
<SpieringsAE>
rtc support did not get merged yet right?
<kuruczgy[m]>
bamse: Well, I commented out the `icc_set_bw` call in `qcom_pcie_suspend_noirq` that you linked, and I see no adverse effects after resume (nvme keeps working).
<kuruczgy[m]>
I guess I should test if this improves power draw.
<SpieringsAE>
wait what, JensGlathe[m]: That just made me realize that I don't have a backlight thing in my dtb, but I can still control the backlight, does the edp-panel driver automatically assume some kind of backlight?
<SpieringsAE>
how does that work
<HdkR>
What sort of crypto things?
<JensGlathe[m]>
I was only having a short look - there is some crypto unit which was in the dtsi that was not in my tree.
<SpieringsAE>
seems that this thing has a backlight driver that is controlled through the dp aux bus, didn't know that was a thing
<JensGlathe[m]>
and it works on the vivobook, but not on Thinkpad, not on HP
<SpieringsAE>
neat
<JensGlathe[m]>
I mean, good to know
<SpieringsAE>
there is a big ol core dump in dmesg in the edp-panel driver but eh, seems to work
<JensGlathe[m]>
that is for unknown panel (thanks #aarch64-laptops, you learn a lot here!). There is also a line with "unknown panel: <some string>". I added the string to panel-edp.c after some research and it solved the splat.
<HdkR>
I would still love an async compression unit that can do zram compression without utilizing any CPU resources :D
<SpieringsAE>
ah okay I'll look into that
<SpieringsAE>
this bit jeah? [ 1.744259] panel-simple-dp-aux aux-aea0000.displayport-controller: Unknown panel SDC 0x41b1, using conservative timings
<JensGlathe[m]>
yep
<JensGlathe[m]>
SDC is vendor, 0x41b1 is some ID
<JensGlathe[m]>
there is a big table in panel-edp.c
<SpieringsAE>
yeah, I think I figured out SDC is samsung if im not mistaken
<JensGlathe[m]>
Mine is BOE 0x0c93 or something
<JensGlathe[m]>
fetched the EDID via windows, will decode later
<SpieringsAE>
yeah I did that too
<SpieringsAE>
you can also do it linux just fine
<JensGlathe[m]>
only if the i2c bus is known
<SpieringsAE>
ah okay
_whitelogger_ has quit [Remote host closed the connection]
<tobhe>
JensGlathe[m]: thx for the brightness link. will add that to our tree
_whitelogger_ has joined #aarch64-laptops
<SpieringsAE>
I'm not sure if I should add to panel-edp.c or try the samsung,atna33xc20 driver
<SpieringsAE>
because this thing has the ATNA56AC03-0
<SpieringsAE>
I think I should try the latter thing
jhovold has quit [Quit: WeeChat 4.4.2]
<JensGlathe[m]>
yes
<JensGlathe[m]>
if this is in the dtb as it should the edp-panel splat goes away, too
<JensGlathe[m]>
finally have the EDID of my display
<JensGlathe[m]>
no timings. Hmm
<SpieringsAE>
that is strange indeed
SpieringsAE has quit [Remote host closed the connection]
_whitelogger_ has quit [Remote host closed the connection]
<JensGlathe[m]>
But it woks, that's something
SpieringsAE has joined #aarch64-laptops
<SpieringsAE>
mine seems to work too
<SpieringsAE>
one thing I am skeptical about is the enable pin, I just copied this one from the other dtbs, but I don't know for sure if it is the correct one
_whitelogger_ has joined #aarch64-laptops
yang has joined #aarch64-laptops
nothorseface has quit []
<SpieringsAE>
isn't there a script that checks dts compared to docs? I wan't to check if I updated the yaml correctly, but I cannot for the life of my find it, something like dt-check or something
<travmurav[m]>
There is both dt bindings check and dtbs check
<travmurav[m]>
make CHECK_DTBS=y qcom/blah.dtb to check dtb against all docs
<travmurav[m]>
make dt_binding_check DT_SCHEMA_FILES=blah
<travmurav[m]>
For checking the yaml itself
<SpieringsAE>
dt_binding_check gives me a bunch of python errors
<SpieringsAE>
ah okay that second one might be usefull
<travmurav[m]>
I think you need some specific version of jsonschema
<SpieringsAE>
oof, well I've got whatever version arch has lol
<JensGlathe[m]>
I got dtschema to run with venv
<SpieringsAE>
that is a good idea
<SpieringsAE>
the CHECK_DTBS one gives me 'nothing to be done for x' I tried deleting the built dtb but didn't help unfortunately
<robclark>
AFAIU the samsung oled panels need to use a different panel driver because non-standard power on/off sequence (but t14s might be an exception for some reason.. but unclear if panel is powering off and back on correctly).. but if we do need different dtb, I'm not sure how to handle that vs devices with IPS panel (which do use panel-edp)
<robclark>
at least the 7x and other things that use SDC panels have needed to use the atna driver
<SpieringsAE>
mine seems to be fine with either
<SpieringsAE>
the asus vivobook that is
<travmurav[m]>
SpieringsAE: how did you invoke it exactly?
<SpieringsAE>
like this: make CHECK_DTBS=y arch/arm64/boot/dts/qcom/x1e80100-asus-vivobook-s15.dts
<travmurav[m]>
dtb not dts
<SpieringsAE>
also tried with dtb
<robclark>
SpieringsAE: I think they are "fine" in that bootloader leaves the panel on and it (possibly?) never gets disabled
<travmurav[m]>
And not full path but start from qcom
<SpieringsAE>
then I get no rule to make target
<travmurav[m]>
Canonical name
<SpieringsAE>
huh, I expected it to at least have to know the architecture
<travmurav[m]>
Well you set ARCH
<SpieringsAE>
but yeah more python errors, so I guess I'm going to set up a venv like jens
<SpieringsAE>
ah
<travmurav[m]>
Which is guess is already arm64 on native target? XD
<SpieringsAE>
robclark: it did turn off and back on when I closed the lid
<SpieringsAE>
but I think it may have just set the brightness to 0
<robclark>
but panel.. or just backlight?
<SpieringsAE>
as there was no panel enable pin defined
<robclark>
ahh, right.. yeah so panel itself is probably still powered
<SpieringsAE>
that is a good question, that I am no longer able to answer
<SpieringsAE>
well I could set back the old dtb I guess
<robclark>
I guess it would make a difference on the power draw when suspended (at least if all the other power issues were resolved)
<SpieringsAE>
yep lol, I really would like that rtc support to get in
<SpieringsAE>
waiting for ntpd to kick in gets old pretty fast
<SpieringsAE>
similar issue with the systems at my work lol, at least those keep the time when you `reboot`
<SpieringsAE>
but this thing doesn't sadly
<robclark>
heheh, I cherry-picked flto's rtc patches (and cloned the changes from t14s dts in 7x dts) and it seems to work
<SpieringsAE>
should probably try that out too
<JensGlathe[m]>
I had to change ntp settings to ntp pool to make it work
<SpieringsAE>
well ntp works, it just, takes a little time for itself
_whitelogger_ has quit [Remote host closed the connection]
nothorseface has joined #aarch64-laptops
_whitelogger_ has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
_whitelogger_ has quit [Remote host closed the connection]
brisket has joined #aarch64-laptops
<deathmist>
JensGlathe[m]: seems grub (or any other bootloader) keyboard not working has to do with using the boot selection menu on the HP anyway, spamming ESC on bootup, selection F9 for boot menu and then picking your linux entry should break the keyboard in it compared to letting it boot with grub etc as default
<tobhe>
brisket: press f12 at boot, check if there are multiple ubuntu entries
<tobhe>
if yes, try both
_whitelogger_ has joined #aarch64-laptops
<brisket>
there is just one ubuntu entry
<brisket>
do i need to instasll x1e78100-lenovo-thinkpad-t14s.dts ?
<tobhe>
you shouldn't need to
<brisket>
it obviously starts to boot the kernel
<tobhe>
grub randomly crashes sometimes, we haven't found out why so far
<brisket>
then flashes back to the grub screen
<brisket>
and is locked up
<tobhe>
ok that sounds like the grub issues we have seen before
<JensGlathe[m]>
deathmist: grub from nvme works fine, to my surprise (had sd-boot configured already)
<kuruczgy[m]>
bamse: Nope, still seeing the same 3.5%/hour power draw. So either shutting off pcie does not make a difference, or removing that line of code does nothing because something else still has an icc vote keeping it enabled.
<brisket>
@tobhe anyway to confirm?
<tobhe>
not really. in my experience it usually goes away after rebooting a few times, maybe reboot into windows via f12 and then back into ubuntu
<tobhe>
I wish I knew what is causing those
<brisket>
i can boot into windows from grub
<brisket>
fwiw
<deathmist>
JensGlathe[m]: it does, unless you use the ESC + F9 boot menu to select it, then keyboard stops working. I'm assuming that somehow disables hardware compared to letting it boot from default entry
<kuruczgy[m]>
robclark: uh you got rtc working on the slim 7x? which patches are these, could you link them please?
SpieringsAE has quit [Remote host closed the connection]
<tobhe>
maybe see if there are fw updates you can install in windows
<brisket>
yep i did firmware updates before installing this morning
<JensGlathe[m]>
on X14 the new UEFI BIOS didn't change a thing re keyboard
<tobhe>
you said usb still works, maybe boot from usb and check if the entries look ok in efibootmgr
<brisket>
https://ibb.co/XxMKbDT is as far as boot gets before it jumps back to a locked up grub, this instance i was trying to boot into recovery mode
nothorseface has joined #aarch64-laptops
chrisl has quit [Remote host closed the connection]
chrisl has joined #aarch64-laptops
_whitelogger_ has quit [Remote host closed the connection]
<deathmist>
ugh I'm now nearing X1E ISO creation of my own and it seems everyone depends on various downstream grub patches to make it select the right DTB somehow automatically without manually messing with the entry/other configuration
_whitelogger_ has joined #aarch64-laptops
<deathmist>
I wouldn't be opposed to better solutions targeting either systemd-boot/limine either if someone knows what those might be. somehow this all seems worse than aboot on androids where you can add multiple dtbs to one boot.img and it'll pick the right one based on qcom,msm-id/qcom,board-id lol
<steev>
unfortunately, from my understanding, upstream grub developers declined the ubuntu patches, so we all have to do whatever is best for each distro
<deathmist>
thankfully my distro is likely ditching grub for live images later
<deathmist>
macc24: thanks will look into it
_whitelogger_ has quit [Remote host closed the connection]
nothorseface has quit []
<tobhe>
brisket: re. pastebin has expired
_whitelogger_ has joined #aarch64-laptops
<JensGlathe[m]>
hmm brightness control seems to work on the HP X14, but the scale seems to be off. It is now stuck in a range where the backlight stay switched off 🤨
<JensGlathe[m]>
It comes back when the brightness gets dimmed due to inactivity, immediatily switches off when moving the mouse
<JensGlathe[m]>
okay, brightnessctl to the rescue, maximum value is 3850
<JensGlathe[m]>
with 3851 you're dead
<JensGlathe[m]>
I mean, dark
<JensGlathe[m]>
So, this works with abelvesa 's patch 👯♀️
<tobhe>
steev: not sure sure if they were actually declined or just ignored
<steev>
tobhe: fair, still waiting on a response to travmurav[m]'s patch he submitted recently
<steev>
by recently... a month or so?
<tobhe>
I think that one did actually get a response
<JensGlathe[m]>
I imagine a dev massaging his temples after reading the patches
<deathmist>
JensGlathe[m]: I wouldn't mind trying if you have a dts diff :D
<deathmist>
very nice to get brightness control though
<deathmist>
did you try bluetooth with the windows firmware yet? I've yet to extract the pieces but maybe I just will since I do want my headphones to function properly
<JensGlathe[m]>
yes this works great
<deathmist>
I can even drop my wifi signal to 1 bar in kde by just standing between the router and laptop lol
<deathmist>
JensGlathe[m]: you mean the bt fw switch worked great? I'll prob try it soon as well. have you seen the wifi signal be similarly weak like I mentioned?
<JensGlathe[m]>
no, honestly, not. It is good most of the time
<kuruczgy[m]>
Can confirm, RTC working on yoga slim 7x.
<JensGlathe[m]>
The bt range and quality improves dramatically with the right firmware.
<JensGlathe[m]>
Wifi was pretty great already (usually getting 20..30 MB/s effective transer rates, link speed 500-866MBit/s)
<JensGlathe[m]>
No it was there
<JensGlathe[m]>
deathmist: I suggest you leave the brightness control alone (because reasons), maximum setting via brighnessctl is 3850, idle state should be 1155 - i changed these with dconf. The control is... interesting
_whitelogger_ has quit [Remote host closed the connection]