00:08 <AlexMarty[m]> that would be good

00:26 <steev> indeed

01:37 <steev> i wanna see just how far off i was

03:00 <steev> bamse: speaking of wifi... have we heard anything from kalle? i know there's a bug https://bugzilla.kernel.org/show_bug.cgi?id=216036 but seems like absolutely no traction on it at all

03:03 <bamse> steev: he's been on vacation, i did ping him yesterday...

03:03 <steev> ahhh

03:26 <steev> qzed: you drop the ucsi glink stuff for 5.19?

03:26 <steev> oh, nevermind, you apply them earlier :)

03:29 <steev> wait no, i'm an idiot, i was looking at mine

03:33 <qzed> I think I didn't see any difference with those on the SPX (I don't think that uses glink)

03:34 <steev> yeah, i'm trying to merge all 3 of the lenovo devices into one, and wanted to make sure i'm using the latest of the stuff you have, and was just noticing you didn't have it :)

03:36 <qzed> AFAICT the UCSI stuff is quite a bit different on the SPX because charging goes through the EC and not the Qualcomm firmware stuff, so the UCSI events are provided by the EC

03:46 <steev> makes sense

05:10 <steev> hm

05:10 <steev> somehow i broked it

05:11 <steev> [ 33.546253] panel-simple-dp-aux aux-aea0000.displayport-controller: Couldn't identify panel via EDID

05:11 <steev> no deferred devices, so i must have screwed up a patch

05:31 <steev> hm

05:53 <steev> okay i fully expect this to break, but if it doesn't, great

05:54 <steev> also, the rcu stalls have to be a config option i have, because i saw them on the thinkpad too when i moved to the "distro_defconfig"

21:07 <leezu> It turns out that the screen flipping issue on lazor is due to flipped readings from iio-sensor-proxy / sensor mounted in "non-standard" way. According to iio-sensor-proxy this can be fixed by setting ACCEL_MOUNT_MATRIX udev property or, for device tree based devices via the mount-matrix property. But for the aarch64 qcom devices, I only see a few msm8916 devices use

21:07 <leezu> mount-matrix in dts. Is that something that should be adopted for the lazor dts? https://www.kernel.org/doc/Documentation/devicetree/bindings/iio/mount-matrix.txt

21:11 <amstan> leezu: macc24_ was looking at this a while ago

21:11 <amstan> the tldr is that every chromebook should have that matrix the same way, it's not just a lazor problem

21:15 <amstan> https://github.com/systemd/systemd/blob/main/hwdb.d/60-sensor.hwdb#L406

21:15 <amstan> someone should stop adding those one by one for every chromebook and just match all of them in one rule

21:17 <leezu> Would one rule work for all? I see that Lazor has two sensors, iio:device1 and iio:device2. I'm not yet sure which one (or both) are used for determining the rotation and if both are equally flipped. Do you know that?

21:18 <amstan> there should be a way to tell which one's the lid and which is the base

21:19 <amstan> you could tell by moving the lid and seeing which one moves more

21:19 <amstan> but i'm sure there's metadata for it too

21:19 <amstan> one rule should work for all, as that's our standard for whatever chromeos userspace uses too

21:19 <amstan> i suspect nocturne (the only one different) in that list is wrong

21:22 <amstan> btw, should also match: https://source.android.com/devices/sensors/sensor-types

21:22 <amstan> there was a w3c page about this too, cannot find it right now

21:23 <amstan> https://w3c.github.io/deviceorientation/

21:23 <amstan> those should match the lid accelerometers, forgot how the base ones worked

21:24 <amstan> maybe they match the lid if the laptop is wide open at 180deg

21:28 <leezu> So you suggest something like: sensor:modalias:platform:cros-ec-accel:dmi:*:*:*

21:28 <leezu> ACCEL_MOUNT_MATRIX=-1, 0, 0; 0, -1, 0; 0, 0, -1

21:32 <leezu> I tried adding that rule to /etc/udev/hwdb.d/61-sensor-local.hwdb and rebooted. The sensor is still inverted

21:33 <leezu> (Probably the syntax is wrong)

21:36 <leezu> Ok, so looking at in_accel_z_raw, the device1 sensor is the one in the lid and the device3 the one in the base

21:51 <macc24_> amstan: i've been procrastinating looking at that

21:52 <macc24_> got a tiny bit sidetracked and now i'm making custom builds of steamos 3

21:59 <leezu> macc24_: Do you know why above cros-ec-accel rule does not work?

21:59 <macc24_> leezu: do you have dmi ids on your arm chromebook

22:00 <leezu> No, how can I find them? It seems CONFIG_DMIID is not for aarch64

22:00 <macc24_> then why did you put `:dmi:*:*:*`

22:00 <macc24_> it'll match any device's dmi strings

22:01 <amstan> Yeah, this is x86 syntax leaking in. I wouldn't be surprised if a bunch of users place in this area just assumes it

22:01 <leezu> I also tried: sensor:modalias:platform:cros-ec-accel

22:01 <leezu> ACCEL_MOUNT_MATRIX=-1, 0, 0; 0, -1, 0; 0, 0, -1

22:01 <macc24_> leezu: just put https://github.com/Maccraft123/Cadmium/blob/master/board/krane/accel-matrix.hwdb into /etc/udev/hwdb.d and run udevadm hwdb -u

22:01 <macc24_> and reboot

22:02 <macc24_> or udevadm trigger and restart iio-sensor-proxy

22:03 <leezu> That matches. But now my default state is left-up :D

22:04 <macc24_> oh yeah just make it -1, 0, 0; 0, -1, 0; 0, 0, -1

22:05 <leezu> Yes, that works

22:05 <leezu> Thank you

22:07 <leezu> amstan: So sensor:modalias:platform:* matches but sensor:modalias:platform:cros-ec-accel doesn't despite the sensor's modalias is platform:cros-ec-accel. That sounds like a bug, but do you have a guess where?

22:14 <amstan> nope, sorry

22:14 <amstan> sboyd might know, he touched some related area to that for fingerprint recently

23:07 <harvestz[m]> Is Peter Robinson in here? Looks like they got the x13s to support it for Fedora!

23:52 <steev> doesn't look like it in the irc list, iirc he goes by pbrobinson