<jannau>
it probably should be integrated back into hid-magicmouse but that needs refactoring first. the report id clashes with MAGIC_TRACKPAD2_USB but both use a different format for the touch contacts
<jannau>
assuming we can get rid of applespi it will probably result in a negative line count change while supporting more hardware
yuyichao has quit [Ping timeout: 480 seconds]
skipwich has joined #asahi-dev
Dcow_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
leah has joined #asahi-dev
PhilippvK has joined #asahi-dev
phiologe has quit [Ping timeout: 480 seconds]
yuyichao has joined #asahi-dev
<marcan>
maz: there is a way to control the affinity per-cluster to some extent, and there is a grouping system which may allow CPUs to opt-in to only specific priority levels (unclear)
<marcan>
I'm quite certain there is no explicit, per-IRQ, specific-CPU affinity setting
<marcan>
as in literally there aren't enough implemented irqconfig bits to make that happen
<marcan>
jannau: does it work? I was just adding a "no multitouch" comment, but I can skip that :p
<notyou[m]>
alyssa: 333
<jannau>
marcan: as far as evtest is concerned yes, I haven't done tests beyond that
<marcan>
cool :)
<marcan>
also re RTC, ehh, I'm not terribly interested in listing everything they have some driver for; I'm only throwing up WiFi because people keep bugging me about it :p
<marcan>
I think we've run out of drivers to even consider saving from them anyway, what's left is either a complete mess or kettenis already worked it out better ;)
<marcan>
jannau: the report IDs aren't supposed to be unique anyway; note how magicmouse_emit_touch ends up looking up the PID
<jannau>
marcan: magicmouse_raw_event uses the Report IDs to identify the data format though. nothing a little refactoring can't fix
<jannau>
but looking at hte end result of hid-appleft.c it should clearly live in hid-magicmouse
<jannau>
I did not start that way
pg12 has joined #asahi-dev
<marcan>
:)
pg12_ has quit [Ping timeout: 480 seconds]
<marcan>
drivers/hid/spi-hid/spi-hid-apple.c:828:27: error: ‘spi_hid_apple_shutdown’ undeclared here (not in a function); did you mean ‘spi_hid_apple_match’?
<marcan>
jannau: you have a minor build glitch with !CONFIG_PM_SLEEP
<marcan>
jannau: something's glitchy about the touchpad; clicking and dragging with one finger does not work (two fingers does), and two-finger scroll is kind of weird
<marcan>
so it seems there are still some bugs lying around :)
<marcan>
it's like the two-finger scroll takes a second to activate
<marcan>
or doesn't otherwise work reliably
<marcan>
caps lock LED also doesn't work, perhaps an issue with output reports?
<marcan>
evtest looks reasonable though, not sure why it's glitchy
<j`ey>
looks like LED support just hasnt been added yet, SPIHID_SET_LEDS is there but unused
<jannau>
output reports are not yet implemented, hid-apple doesn't seem to use them with the current keyboard id though
<jannau>
I'm not surprised that !CONFIG_PM_SLEEP is broken
<marcan>
mtview shows good data from the event device, maybe xorg is somehow confused by something?
<marcan>
it's weird
<marcan>
I didn't see anything weird in evtest either
<jannau>
two finger scrolling seems to work better when the two fingers are further apart
<marcan>
ah heh
<marcan>
[ 691.453] (EE) event1 - MacBook Force Touch trackpad: kernel bug: Touch jump detected and discarded.
<marcan>
so it sounds like there may be some glitchiness left somewhere
<marcan>
oh god this is so broken
<marcan>
jannau: so setting the correct pressure range now results in libinput defaulting to a touch pressure threshold *higher* than the palm detection threshold
<marcan>
therefore, no touches work, ever
<_jannau_>
bcm5974 reports tocuch_major as pressure and maps it into u8
<marcan>
pressure palm detection is stupid anyway; pressure has to be a misnomer here, intended for touchpad-based "pressure" detection which is more like area-based
<marcan>
this touchpad reports *real* pressure as pressure
<marcan>
as in you can press it down with something plastic and it still counts, it's force-based
<marcan>
that doesn't make any sense to use for palm detection
<marcan>
like I get ~600 solidly resting my palm on the touchpad, but I can easily get more than that pressing hard down with my finger
<_jannau_>
sounds like it doesn't make sense to report the pressure as pressure at the moment
<_jannau_>
libuinput has AttrPressureRange=N:M, AttrPalmPressureThreshold=O, AttrThumbPressureThreshold=P quirks but those won't help if we report pressure instead of touch area like bcm5974
aleasto has joined #asahi-dev
<mjg59>
Please do not assume that any of the attributes reported in bcm5974 are necessarily accurate
<mjg59>
Some of that was me drunk on my sofa 13 years ago
<mjg59>
Most of this is what seemed right given what people understood of the tech at the time
<marcan>
AttrPalmPressureThreshold=10000
<marcan>
AttrPressureRange=1:0
<marcan>
_jannau_: that works
<marcan>
_jannau_: pushed the latest fixup to touchpad/wip if you want to squash it in
<marcan>
just playing with the input properties
<_jannau_>
mjg59: the hardware documentation part looks mostly accurate as far as I've looked at it
<_jannau_>
problems seems to be mostly to translate it into something libinput understands
<marcan>
the correct solution is to translate it into something that meets the input specification
<marcan>
if libinput is doing insane things like setting a touch threshold higher than a palm threshold with a 0~6000 pressure range, that's a libinput bug
<marcan>
which I'm going to report right now, in fact
<marcan>
ahhh
<marcan>
found the trick
<marcan>
/* On traditional touchpads, the pressure value equals contact
<marcan>
* size. On PressurePads, pressure is a real physical axis for the
<marcan>
* force down. So we disable it here because we don't do anything
<marcan>
* with it anyway and using it for touch size messes things up.
<marcan>
*
<marcan>
* The kernel/udev set the resolution to non-zero on those devices
<marcan>
* to indicate that the value is in a known axis space.
<marcan>
so we need a resolution.
<marcan>
... I guess I need to measure this now, don't I
<marcan>
I'm going to say it's in grams
<marcan>
given a quick test with a 355 ml can of Monster yielding values in the 370 range on top of my finger
<j`ey>
scientific :D
<marcan>
_jannau_: force pushed the fixup again; works fine without any libinput quirks now
<_jannau_>
does it report right/middle button clicks? I haven't managed to check if the the hardware reports them directly in the mouse button report
<marcan>
we don't want those anyway
<marcan>
those are for physical buttons only, unless we want to treat it as a touchpad and disable all the software logic for those
<marcan>
but we probably don't
<marcan>
libinput actually complains if you have those capability bits on for a clickpad
<marcan>
(which is what this physically is)
<marcan>
well, a pressurepad-clickpad I guess?
<_jannau_>
libinput didn't activate clickfingers by default, only with the AppleTouchpad quirk
<marcan>
by default it does it by finger position
<marcan>
bottom right area = right click
<marcan>
so yes, we do need ModelAppleTouchpad=1 to change the behavior to apple style
<marcan>
but at least that's a style thing, it's not broken without it, just not the behavior macOS has
<marcan>
if anyone wants to check before I spam it :)
<marcan>
whoops, missed a thing, updating
Dcow_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<ChaosPrincess>
would be cool to have that table on gsheets or whatever to track progress in real time as opposed to once per progress report
<sven>
not sure i'd call "a bunch of magic MMIO pokes" understood for USB3 :D
<sven>
ohh... and you forgot about the most important thing ever: the watchdog for reboot support :-P
<TellowKrinkle[m]>
> Apple really don’t cut corners when it comes to making their hardware friendly to software developers :-).
<TellowKrinkle[m]>
Shouldn't that be "doesn't"?
<TellowKrinkle[m]>
Shouldn't that be "doesn't"?
<chadmed>
referring to a company in the collective is valid english
<psykose>
correct both ways
<TellowKrinkle[m]>
chadmed: Oh interesting
<Jamie[m]1>
Dark blue ("Work in progress, available for testing in the linux-asahi branch") having a kernel version (for Device Tree on T600x) is a little confusing
<Jamie[m]1>
in that there is no mention in the colour description of upstreaming
<Jamie[m]1>
though (unless it's a mistake?) it's not hard to infer what is meant
<marcan>
it's a weird case because the review is pretty trivial, so *if* the AIC and DART stuff get merged in time it'll make it, otherwise not
<Jamie[m]1>
I expect "Worth it?" in the JPEG Decode row to be taken as a challenge :P
<marcan>
heh :)
<marcan>
tweeted :p
<marcan>
sven: added watchdog
<sven>
lol :D
<marcan>
and well, really, PHYs are just magic pokes no matter how you slice it
<_jannau_>
I'd say not. There are not many uses cases where jpeg encode/decode perfomance/power use are relevant on a computer.
<_jannau_>
the jpeg block almost certainly supports both encode and decode btw
<marcan>
I was wondering about that
<marcan>
renamed
<Jamie[m]1>
compatible="jpeg,s5l8920x"
<Jamie[m]1>
that's iPhone 3GS haha
<marcan>
yup
<marcan>
sven: just sent you a quick fix for some fail in the pmgr build that the test robot caught, if you can review it before I fire off the next pull to arnd :)
<sven>
hm... does that need a fixes tag if it's not in mainline yet?
<marcan>
ah, yes
<marcan>
I'll add that
<kettenis>
so we're going with apple,asc-mailbox-v4 for the generic compatible for the mailboxes?
<marcan>
yeah, let's do that
<marcan>
I'll send out a new series shortly, once I'm done with the pulls
<sven>
works for me
<marcan>
hmm
<marcan>
arnd: I have a merge conflict with something that went into 5.16-rc5, are you okay if I base the 5.17 DT pull on that? It's not urgent, so that patch can also wait if that's easier.
conradev has quit [Quit: -]
conradev has joined #asahi-dev
<j`ey>
marcan: jannau asahi/asahi works well on mb air too
<marcan>
:)
<j`ey>
don't have a setup to try the trackpad yet
StupidYui has joined #asahi-dev
<marcan>
arnd: I guess I'd have to do something like merge 5.16-rc5 on top of my previous DT branch, then rebase off of that and fix the conflict, then send you the pull with that merge commit as base?
<j`ey>
unrelentingtech: hah the last sentence is what marcan said just a few hours ago :D
<unrelentingtech>
yeah the "you have to set a resolution" thing isn't very.. discoverable
<marcan>
yeah...
<j`ey>
sven: did you say that the watchdog should automatically be picked up by the 'reboot' command?
<sven>
yes
<j`ey>
wait.. ignore that, i think I forgot to build the driver lol
<sven>
lol
<sven>
i had to use reboot -f inside my initramfs though but just reboot worked when i booted into a sane userland
<sven>
(iirc)
<j`ey>
sven: ah thanks, reboot -f was it
<kettenis>
_jannau_: what keyboard layout are you using?
<arnd>
marcan: torvalds and I are both used to sorting out merge conflicts. If the new patches you have work without the earlier bugfix, I'd prefer to keep the git history clean and do the conflict resolution on my end
<arnd>
marcan: which mainline patch is causing the conflict?
al3xtjames0 has joined #asahi-dev
al3xtjames has quit [Read error: Connection reset by peer]
al3xtjames0 is now known as al3xtjames
<jannau>
kettenis: none so I'ld guess ascii. using USB_DEVICE_ID_APPLE_MAGIC_KEYBOARD_2021 with hid-apple. That has an incorrect Fn key mapping
<jannau>
someone has to translate kblang-calibration from the ADT into a DT property
* povik
just learned from progress report the headphones jack works on other t8103 macs
<jannau>
I can do that along with finishing the linux drivers
<povik>
nice
<jannau>
kettenis: have you already written dt-bindings for the hid transport?
<kettenis>
jannau: no, the keyboard layout/language thing is one reason
<kettenis>
the other question is whether we need to add somephysical parameters for the touchpad in the device tree
<kettenis>
apple keyboard layouts are a bit weird
<kettenis>
there are basically three variants: ANSI, ISO and Japanese
<kettenis>
and then there are language variants of ANSI and ISO
<kettenis>
my Dutch ISO keyboard is to close to the Internation English ISO variant to make a distinction
<kettenis>
but I'm wondering whether German (QWERTZ) or French (AZERTY) work correctly without userland configuration
<kettenis>
also, where did you get the device IDs from? Did you just invent one?
<jannau>
I invented or reused USB device ids
<jannau>
we probably want at least a different device id for the macbook pro 13"
<jannau>
I was thinking of just apple's target-type as device id
<jannau>
we probably want the IDs in the DT though
Dcow has quit [Read error: Connection reset by peer]
Dcow_ has joined #asahi-dev
<jannau>
touchpad dimensions are would be useful to set the resolution of X and Y
<marcan>
arnd: the PCIe PERST change (5b970dfcfee9)
<marcan>
I then removed the max-link-speed lines right below
<marcan>
povik: confession: I didn't actually test it, I just assumed it did given it's the same codec; I planned to but then I got distracted with touchpad stuff :)
<marcan>
need to put a rootfs on a USB stick or something to make this easier
<arnd>
marcan: ok, so no functional dependency, just a trivial conflict affecting context, don't worry about that then
<marcan>
arnd: got it
<arnd>
marcan: and if you did need this as a dependency, you still wouldn't need to merge in -rc6, but just merge the fixes branch that contains this commit into your DT branch, that way you'd avoid backmerging all of the mainline changes from other people
<marcan>
true
<marcan>
makes sense, yeah
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-dev
Dcow has joined #asahi-dev
<maz>
marcan: the CPU PMU will not make it into 5.17, the branch is already closed.
<povik>
marcan: i have small (15M) rootfs.cpio.gz with alsa tools, it's been built by buildroot, i can send it to you if you want
<marcan>
arnd: pulls sent, hope I didn't screw up the wrapping this time :-) (I just turned it off in thunderbird after forcing it to hard wrap the cover message part only)
<arnd>
marcan: ok, I see it. There are no extra linewraps, but I still see the odd extra spaces at the start of each line that has one or more spaces at the beginning.. Not a problem since the commit message comes from the tag anyway, but I wonder what causes this
kyoto has joined #asahi-dev
<marcan>
hm, it wasn't like that in the editor, let me look at the message...
<marcan>
indeed, huh
<marcan>
oh, perhaps it *was* like that in the editor? hmm
<marcan>
and apparently in the raw email. huh.
<arnd>
it's the same thing that happened last time, I would blame thunderbird
<marcan>
yeah, I think it's thunderbird
kyoto has quit [Remote host closed the connection]
<marcan>
every time I edit as new -> send it adds one extra space to everything...
<marcan>
sigh
<marcan>
I should probably just use git send-email or something instead
<arnd>
Documentation/process/email-clients.rst has a few things on Thunderbird, not sure any of those help
<maz>
marcan: I came to that conclusion after a number of failed attempts at making TB work. eventually, I abandoned TB altogether, but git-send-email stayed...
<marcan>
arnd: ah! looks like that flowed thing fixed it :)
<marcan>
maz: I definitely don't trust TB for patches; kind of hoped it'd be good enough for pulls...
<marcan>
looks like I *might* be able to make it work this way, as long as I remember to rewrap the cover text and then click the disable linewrap button
<marcan>
arnd: PMGR pull sent, hope this one is OK! :)
<arnd>
marcan: the whitespace looks fine now, going through today's pull requests now
tardyp_ has joined #asahi-dev
nkaretnikov has quit [Ping timeout: 480 seconds]
nkaretnikov_ is now known as nkaretnikov
nathanchance has quit [Ping timeout: 480 seconds]
gruetze_ has joined #asahi-dev
tbodt_ has joined #asahi-dev
tbodt has quit [Ping timeout: 480 seconds]
rcombs has quit [Ping timeout: 480 seconds]
Lightsword has quit [Ping timeout: 480 seconds]
jabashque has quit [Ping timeout: 480 seconds]
koorogi1 has joined #asahi-dev
tardyp has quit [Ping timeout: 480 seconds]
tardyp_ is now known as tardyp
sjg1 has quit [Ping timeout: 480 seconds]
sjg1_ is now known as sjg1
philpax has quit [Ping timeout: 480 seconds]
_jannau_ has quit [Ping timeout: 480 seconds]
yuyichao has quit [Ping timeout: 480 seconds]
koorogi has quit [Ping timeout: 480 seconds]
gruetzkopf has quit [Ping timeout: 480 seconds]
_jannau_ has joined #asahi-dev
<marcan>
jannau: ah, I see you got some kernel test robot goodies :)
<marcan>
some of that may be useful, some of it may not; always good to look at
<marcan>
(it automatically goes off on every branch in our asahi/linux.git repo)
<j`ey>
I also got: drivers/hid/spi-hid/spi-hid-apple.c:56:17: warning: variable 'spi_hid_apple_status_ok' is not needed and will not be emitted [-Wunneeded-internal-declaration]
rcombs has joined #asahi-dev
yuyichao has joined #asahi-dev
yuyichao_ has joined #asahi-dev
yuyichao has quit [Ping timeout: 480 seconds]
yuyichao_ has quit [Quit: Konversation terminated!]
yuyichao_ has joined #asahi-dev
Dcow has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
yuyichao has joined #asahi-dev
nathanchance_ has quit []
nathanchance_ has joined #asahi-dev
nathanchance_ has quit []
nathanchance has joined #asahi-dev
<marcan>
alright, I think that's all the urgent-ish kernel stuff taken care of... I should follow up on spi and aic2 tomorrow and then maybe I'll have time for wifi :)
yuyichao_ has quit [Ping timeout: 480 seconds]
<kettenis>
marcan: heh, I can probably write something up for the next report...
<marcan>
that would be cool, I feel like you don't get enough credit :)
<marcan>
(mostly my fault for not following anything outside the kernel properly...)
somkls^ has quit [Remote host closed the connection]
Dcow has joined #asahi-dev
kgarrington has joined #asahi-dev
kgarrington has quit [Remote host closed the connection]
<povik>
haha, kernel test robot found the admac driver
<povik>
and is not exactly happy
riker77 has quit [Quit: Quitting IRC - gone for good...]
<sven>
it almost never is :D
riker77 has joined #asahi-dev
riker77 has quit []
<jn>
grumpy-as-a-service
kgarrington has joined #asahi-dev
kgarrington has quit [Remote host closed the connection]
kgarrington has joined #asahi-dev
kgarrington has quit [Remote host closed the connection]
<dottedmag>
Wouldn't it be nice if it also sent e-mails like "I have found some new code, checked it and it's perfect"?
kgarrington has joined #asahi-dev
kgarrington has quit [Remote host closed the connection]
riker77 has joined #asahi-dev
Dcow has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Dcow has joined #asahi-dev
Dcow has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<alyssa>
jn: Bad acronym :p
<jn>
indeed (i didn't notice)
yamii has joined #asahi-dev
Dcow has joined #asahi-dev
Dcow has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Dcow has joined #asahi-dev
Dcow has quit []
somkls^ has joined #asahi-dev
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi-dev
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi-dev
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi-dev
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi-dev
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi-dev
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi-dev
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi-dev
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi-dev
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi-dev
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi-dev
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi-dev
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi-dev
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi-dev
c10l8 has quit [Remote host closed the connection]
c10l8 has joined #asahi-dev
c10l8 has quit [Remote host closed the connection]
Dcow has joined #asahi-dev
Dcow has quit []
Dcow has joined #asahi-dev
Dcow has quit []
<FireFox317>
do we already have an idea how the backlight of the lcd is controlled on these m1 machines? Keyboard backlight seems to be PWM, but im not sure about the lcd backlight
<FireFox317>
Maybe it is SMC actually?
<j`ey>
pipcet had it working, I think it also has some DCP components