02:43 <steev> well that was... surprisingly painless

02:53 <steev> argh. I need to go into bios… they did this same keyboard on the x1c line, I have no idea who thought it was a great idea to swap the fn and ctrl keys

03:22 <leezu> dianders: thanks. Good to know Power-Refresh also reboots EC. The EC has been working fine ever since the reboot via Cr50 update, so it must have been a weird edge-case that got it into the bad state

03:23 <leezu> The wifi issue on the second lazor turned out to be an issue with the AP. The netmask was misconfigured and only allowed 16 devices to obtain IP addresses, causing the lazor to voluntarily disconnect after giving up on receiving an address. Ie. the "chan info: invalid frequency 0 (idx 41 out of bounds)" error in the kernel log is harmless

03:36 <leezu> Does anyone know about Freedreno WebGL support in Firefox? WebGL works mostly fine with Chrome, but Firefox fails with "Exhausted GL driver options. (FEATURE_FAILURE_WEBGL_EXHAUSTED_DRIVERS)" in about:support even if webgl.force-enabled is enabled in about:config. (This breaks zoom.us video conferencing.) For Chrome, a few tests fail at

03:36 <leezu> https://www.khronos.org/registry/webgl/sdk/tests/webgl-conformance-tests.html but that may be expected (?)

03:37 <steev> leezu: <qzed> last step in https://gitlab.com/postmarketOS/pmaports/-/issues/494#note_307360685 - re idx 41 out of bounds

03:57 <leezu> steev: Thank you. I'll try that

04:07 <leezu> Regarding WebGL, Chrome WebGL also breaks (becomes unavailable / disabled) when running with --ozone-platform=wayland. But Firefox WebGL is broken on both x11 and wayland.

04:09 <steev> i couldn't tell you the first thing about GL, unfortunately

04:09 <steev> you might try asking in #freedreno

04:47 <Dylanger> Firefox UX is terrible on aarch64 chromebooks from my experience

04:49 <steev> is it specific to the chromebooks? seems fine everywhere else

04:54 <Dylanger> Not sure, I assumed because the amount of users running on aarch64 would be very, very small, I'm running Ungoogled Chromium on my Duet 5 currently

05:04 <steev> i mean what's terrible about it - i've not had any issues here

05:04 <steev> otoh, i use esr, mostly because don't want it randomly updating on me

05:04 <Dylanger> Oh, everything

05:05 <Dylanger> It's the worst browsing experience

05:05 <steev> because...

05:05 <robclark> I'd generally expect webgl to work, I'd kinda get a lot of bugs about it on CrOS things otherwise.. but on linux chrom(ium) has different deny-lists for gl.. and I guess similar situation for ffox.. and the whole "omg there are gpus that don't have pci-id's" on arm things doesn't help.. so there might be some config things you need to do to override deny-lists

05:05 <Dylanger> Compared to Chromium, again I assume this is just because Google have put a bunch of man hours into aarch64

05:06 <steev> again, you're just saying "it's bad" - i'm asking HOW it's bad, not if it is or isn't

05:06 <Dylanger> Oh, like 2 fps, terrible when scrolling

05:06 <Dylanger> Forghettaboutit trying to watch a video

05:07 <travmurav[m]> Hm, it seems like my eDP panel fails with "Unexpected max rate (0x0); assuming 5.4 GHz" -> "Link training failed, link is off (-5)" if the panel power was cut, forcing it's regulator "fixes" the thing

05:08 <steev> robclark: i'm not sure the fix for non-visible planes is correct - my c630 won't wake the display up now - the backlight comes on, but nothing comes on screen

05:09 <steev> i lied, it just came back, after the 4th attempt :(

05:10 <robclark> iirc on my fedora setup, I had to figure out some chromeium and ffox overrides for gl/webgl.. but I'm not sure I can remember at this point what those steps are (but I guess the interwebs would remember)

05:10 <robclark> steev: that shouldn't really break anything with visible planes ;-)

05:10 <robclark> the fix was all about making things actually invisible when they are supposed to be ;-)

05:11 <robclark> (ie. cursor that moves off screen and that sorta thing)

05:11 <steev> robclark: heh, I figured, just was weird that it wouldn’t wake the display from suspend

05:12 <steev> dylanger: playing video here just fine https://usercontent.irccloud-cdn.com/file/ws8aSJj2/67894989451__BA17A8C3-D7A6-4776-B8A6-B8470436FEA9.mp4

05:12 <robclark> I won't rule out that I missed some case where we should disable something for non-visible plane (but I don't think you should be hitting that.. and so far it has fixed a whole lot of igt edge cases)

05:13 <steev> i'm not sure, i'll have to try to ssh in next time and see what it thinks should be happening

05:15 <steev> part of why i bugged srinik so much back in the day was because my audio wasn't working right and that meant i couldn't watch youtube videos, or more importantly, our PWK course videos

05:16 <HdkR> Speaking of watching videos. Only V4L2 video decode support on Snapdragon SoCs? Nothing wired in to VAAPI to take advantage of more "traditional" video decode pipelines from mainly x86 setups?

05:18 <travmurav[m]> Also speaking of watching videos. Can I expect the venus blobs from the linux-firmware to "just work" on WoA or I must load whatever is signed for the device? Seem to have a bit of trouble with this (well with all remoteprocs so far)

05:19 <steev> travmurav[m]: that's a good question... i *believe* i'm using the upstream firmware for venus on my c630, but i can't remember

05:21 <robclark> HdkR: just v4l2... but in theory ffmpeg and gst have support.. and chrom(ium) but in that case it is all behind "I'm building for CrOS" build flags probably

05:21 <steev> https://chromium-review.googlesource.com/c/chromium/src/+/3380427/5

05:22 <robclark> venus fw is signed afaiu.. but not sure if all the WoA things use the same signing or not.. CrOS things just kinda ignore the signing on venus fw afaiu (since it doesn't really matter from CrOS security model)

05:23 <steev> well... that's not good since there's no way to differentiate them

05:24 <robclark> in theory the firmware-path in dt is the way to do it.. I don't remember if venus supports that yet

05:24 <travmurav[m]> So far it seemed like my WoA blobs are signed by qualcomm but copying "qcvss7180.mbn" (with v for video I assume) instead of what was there just gave me a new error: "failed to reset venus core" with -110 timeout

05:25 <steev> travmurav[m]: do you have an mdt file as well?

05:25 <travmurav[m]> only found mbn, let me re-check the C drive

05:26 <steev> robclark: it definitely doesn't support it yet, all the firmware sits in qcom/venus-X.X

05:27 <steev> travmurav[m]: there's either just one mbn or an mdt and bXX files

05:27 <steev> and i believe you can use pil-splitter to split the mbn

05:27 <travmurav[m]> I think what I did is to copy the mbn over the mdt and hope the TZ would figure it out as iirc it can read both packed and bXX

05:27 <travmurav[m]> I think so far the tendency was to squash non-squashed blobs :D

05:27 <steev> travmurav[m]: hm, i do believe that should work

05:28 <robclark> steev: sadness.. oh, are they still also requiring split fw.. there needs to be some loud complaining about that ;-)

05:28 <steev> i'm not sure if it's *required*

05:28 <steev> but e.g.

05:28 <steev> https://packages.debian.org/unstable/firmware-qcom-soc seems to include both mbn and split?!

05:29 <travmurav[m]> steev: a search for the "*.mbn" and "*.mdt":... (full message at https://matrix.org/_matrix/media/r0/download/matrix.org/XBIMoCZRlSuWaUXplxWDXhtn)

05:30 <steev> hm

05:30 <steev> let me

05:30 <travmurav[m]> so I think they're all squashed, there was only some bluetooth stuff with .bX I think, and that's some other fun afaiu

05:31 <steev> i just have the qcvss850.mbn in there, along with the split ones

05:31 <steev> in venus-5.2 that is, i'm assuming the 7180 is 5.4?

05:31 <HdkR> robclark: My concern is mostly libraries that never compiled in V4L2 support, so we need some sort of VAAPI->V4L2 translation layer :/

05:31 <travmurav[m]> steev: yes, 5.4 iirc

05:33 <robclark> HdkR: vaapi->v4l2, esp for stateful vl42 decoders isn't a good idea.. it is putting a lower level abstraction on top of a higher level abstraction.. the better option si that things don't use vaapi directly, sadly

05:34 <robclark> ie, implementing a vk->gl trnaslation layer isn't a good idea.. same thing..

05:36 <HdkR> robclark: Better than software decoding still

05:37 <travmurav[m]> ah, just decided to check and the linux-firmware venus is test key signed, so definitely need the device firmware

05:37 <HdkR> Ideally venus can just gain support for vaapi and I don't have to think about this headache :)

05:38 <robclark> HdkR: questionable .. tbh these things should be able to do at least 1080p sw decode w/ competent sw codec

05:38 <robclark> travmurav[m]: yeah, l-f stuff is defn test-key signed

05:38 <steev> travmurav[m]: you can try splitting it - python2 pil-splitter.py qcvss7180.mbn venus and then copy the venus.* files into /lib/firmware/qcom/venus-5.4

05:38 <steev> https://github.com/remittor/qcom-mbn-tools/blob/master/pil-splitter.py

05:39 <robclark> HdkR: again.. it is layering a low level api on top of something that does more things in hw.. it isn't a sane way to do things and is just asking for endless supply of bugs ;-)

05:40 <robclark> if it was a sane thing to do, CrOS would have already done it for you ;-)

05:40 <HdkR> I deal in the insane arts

05:41 <HdkR> For now I have a note to do some benchmarking since this is going to be an...interesting problem space

05:41 <robclark> well, there is "insane == hard to do" and "insane == dumb to do" ;-)

05:41 <robclark> vaapi on v4l2 statedful decoder is latter

05:41 <steev> not gonna lie, even without the gpu, i'm surprised at how good the thinkpad is

05:43 <HdkR> robclark: So you're saying that Venus firmware is signed but ignored? ;)

05:44 <steev> on cros

05:44 <robclark> ^^ that

05:44 <HdkR> I could get a cros device for mangling

05:44 <HdkR> If it comes to that

05:44 <steev> yeah but then you'd have to use cros, and no one needs that negativity

05:45 <HdkR> It's a powerful energy

05:45 <steev> i actually don't mind cros at all

05:45 <robclark> for WoA just copy the fw from windows.. and apparently sned patch to bring venus driver into the modern age

05:45 <steev> somewhere around here, i have uhhhh... like, cros 26 or cros 29 for the efikamx

05:46 <robclark> pretty straightforward to run linux on cros things.. upstream kernel support is good, only thing is different boot arch

05:46 <steev> robclark: oh that reminds me... someone started working on getting it running a modern kernel....

05:47 <steev> i used to get so mad at shawnguo nacking all our patches

05:47 <robclark> I've been running modern kernel on qc cros things since long before first qc cros thing shipped

05:48 <steev> robclark: ah i mean on the efikamx :P the i.mx51 thing

05:48 <robclark> ahh

05:48 <steev> we were so excited when freedreno first got announced

05:49 <steev> we absolutely *hated* dealing with bugs in the graphics drivers and having to wait for things to go through amd/ati and qcom

05:50 <robclark> afaiu cphealy got pretty far w/ freedreno on imx5 things.. it would be nice to have some a2xx things in CI but right now that is a bit of a test coverage gap

05:50 <steev> if rtp makes a lot of progress, i have 8 efikamx in my drawer

05:51 <Dylanger> <robclark> "vaapi on v4l2 statedful decoder..." <- Can confirm v4l2 uses Venus perfectly on the Duet 5 (Cadmium), video playback is damn smooth

05:51 <Dylanger> <steev> "Dylanger: playing video here..." <- No idea why I can't hit that with mine

05:53 <robclark> for some reason people expect youtube to "just work" on chromebooks :-P

05:54 <robclark> (I sit next to a few folks who work on video side of these things so I hear all the horror stories ;-))

05:56 <travmurav[m]> well, after patching the splitter to work on py3 and replacing the bobs I got the same "failed to reset" result

06:05 <Dylanger> <robclark> "for some reason people expect..." <- lol fair enough, I think I ended using ytdl pipped into mpv with the v4l2 flag

06:05 <Dylanger> To it it working just right

06:05 <Dylanger> s/it/get/

06:34 <minecrell> travmurav[m]: split vs squashed firmware should be irrelevant for TZ, since it only changes how Linux loads the firmware segments

17:39 <steev> robclark: since you may be a bit more familiar with pwcli... any idea why it's doing this? https://paste.debian.net/1246612/ i'm applying a patch and once it says it's applied... it says a different one?

17:41 <robclark> I don't use pwcli at all.. I use git-pw

17:41 <steev> ah

17:47 <steev> jhovold: since i think you're working on thinkpad support - something i see here - panel-simple-dp-aux aux-aea0000.displayport-controller: Unknown panel IVO 0x854b, using conservative timings

22:25 <bamse> steev: everyone gets their own panel :)

22:26 <bamse> makes me happy that dianders was pushing for panel-edp and asking the panel for its properties

22:28 <dianders> steev / bamse: Yeah, the conservative timings will probably work OK, but if you have the panel datasheet you can do better and then avoid the warning. :-) ...and adding the proper timings is now a tiny patch instead of needing to add dts bindings plus copy/paste from an EDID decode...

22:29 <bamse> exactly

22:29 <steev> dianders: i was trying to find my email where you had given me the instructions for grabbing the edid from the panel itself over i2c, but... thunderbird's search sucks

22:29 <steev> that said... it's working great, no complaints even with that message :)

22:30 <bamse> steev: you don't need that, to get rid of the message you need to patch edp_panels in drivers/gpu/drm/panel/panel-edp.c, to specify some timing parameters and the name of the panel

22:30 <dianders> steev: the EDID won't contain the timings you need, which is why you've got to manually add them...

22:30 <bamse> and the name you can find in the edid dump in /sys

22:30 <steev> yeah... that uhh, isn't really complete

22:31 <bamse> and as dianders says, if you have datasheet you can specify timings...for the cases where we don't have the sheet, i guess we can specify some concervative numbers and comment that it's done without datasheet

22:31 <bamse> but that's the hpd and power timings, not the clock timings...those comes from the panel

22:32 <dianders> bamse: yeah, I'd be OK w/ that as long as it was documented that they were non-official. For the most part almost all the panels have very similar timings...

22:32 <steev> https://paste.debian.net/1246632/

22:32 <dianders> steev: the timings needed are actually things from the eDP power on timing diagram.

22:33 <steev> i definitely don't have that

22:33 <dianders> steev: See the ASCII art in Documentation/devicetree/bindings/display/panel/panel-edp.yaml

22:33 <dianders> ...and then the kernel doc for `struct panel_delay` correlates to those...

22:35 <steev> ah, okay

22:36 <steev> either way... this system is... ridiculously nice

22:37 <steev> and even without gpu, works great

22:37 <dianders> steev: It's quite likely that on most panels you'd be fine with hpd_absent=200, unprepare=500, and enable=80. In most cases you don't actually need hpd_absent if everyone has HPD hooked up, but can be nice to specify it anyway...

22:38 <dianders> That's all documented in the comment right next to the error message where it yells about conservative timings. ;-)

22:38 <steev> bold of you to assume i read