| + paperManu_ (~paperManu@142.169.16.60) | 00:03 | |
| minute | can't wake it up from the real deal yet :D | 00:04 |
|---|---|---|
| - schalken (QUIT: Ping timeout: 256 seconds) (~schalken@117-118-178-69.gci.net) | 00:07 | |
| + schalken (~schalken@117-118-178-69.gci.net) | 00:11 | |
| minute | ah, i found a busybox static binary, that's more comfy | 00:16 |
| - schalken (QUIT: Ping timeout: 265 seconds) (~schalken@117-118-178-69.gci.net) | 00:16 | |
| + schalken (~schalken@117-118-178-69.gci.net) | 00:17 | |
| minute | testing "core" pm_test again, this time crash caused by hdmi | 00:40 |
| minute | ah, this was just a spurious irq... | 00:41 |
| + LainIwakura (~LainIwaku@user/LainIwakura) | 00:43 | |
| - paperManu_ (QUIT: Ping timeout: 265 seconds) (~paperManu@142.169.16.60) | 00:49 | |
| - LainIwakura (QUIT: Ping timeout: 250 seconds) (~LainIwaku@user/LainIwakura) | 00:52 | |
| minute | ok, tried to set up gpio-keys with wake function in dts, and disabled emmc and pcie | 00:56 |
| minute | linux be like: 2.87 seconds to shell | 00:56 |
| minute | ~ # cat /sys/devices/platform/gpio-keys/wakeup/wakeup1/active_count | 00:58 |
| minute | 4 | 00:58 |
| minute | so, i can increase this number using the spacebar on the classic reform keyboard in the oled menu | 00:58 |
| minute | ("wake") | 00:58 |
| minute | strangely, no dice. wakeups just don't do anything after echo mem > state | 00:59 |
| - schalken (QUIT: Ping timeout: 256 seconds) (~schalken@117-118-178-69.gci.net) | 01:00 | |
| minute | i wonder what's the difference between the "core" pm_test and the non-test suspend | 01:00 |
| vagrantc | hrm. after updating my lpc firmware, now i am occasioanlly getting wild battery readings on the OLED display ... ahlf the cells show 0 volts, the other half show 9 volts ... briefly and then goes back to normal charging | 01:00 |
| vagrantc | er, 9.9 volts | 01:00 |
| vagrantc | e.g voltages are all 3.4-3.6 or so | 01:01 |
| + schalken (~schalken@117-118-178-69.gci.net) | 01:01 | |
| minute | vagrantc: ah, interesting that that happens only after lpc fw update and not before | 01:03 |
| minute | vagrantc: how's your keyboard firmware? | 01:03 |
| vagrantc | minute: that is whatever shipped with what i presume is the v3 keyboard (white LEDs only) | 01:04 |
| vagrantc | keyboard layout more conventional than the original... | 01:05 |
| - chomwitt (QUIT: Ping timeout: 252 seconds) (~chomwitt@2a02:85f:9a5f:900:1ac0:4dff:fedb:a3f1) | 01:05 | |
| minute | vagrantc: ah i see | 01:06 |
| vagrantc | it is *possible* I never noticed it before ... but i think not likely, as i have been finding the OLED to be reliable by contrast to the kernel module (that's why i switched) | 01:06 |
| vagrantc | i upgraded the firmware to try and resolve issues with the kernel module for battery status | 01:06 |
| minute | yep | 01:06 |
| - schalken (QUIT: Ping timeout: 256 seconds) (~schalken@117-118-178-69.gci.net) | 01:06 | |
| + schalken (~schalken@117-118-178-69.gci.net) | 01:07 | |
| minute | vagrantc: it's possible that the atmega keyboard code needs some tweaking in the serial code | 01:07 |
| minute | timings or so | 01:07 |
| vagrantc | the ghosting on the OLED is also definitely ne | 01:08 |
| vagrantc | new | 01:08 |
| minute | hmm the oled is driven solely by the keyboard | 01:08 |
| vagrantc | firmware build was from git 3cc6fbb | 01:08 |
| minute | ghosting always happens if you leave some non-changing graphics/text for a long time on the OLED | 01:09 |
| minute | it is cheap to replace though | 01:09 |
| vagrantc | i do frequently leave the battery monitor, but it was the first thing i noticed after updating the firmware ... | 01:10 |
| vagrantc | it was definitely not like that earlier today | 01:10 |
| minute | well you didn't update the keyboard firmware, right? | 01:10 |
| vagrantc | no | 01:10 |
| minute | only the keyboard firmware can affect the oled, nothing else | 01:10 |
| minute | it must be a coincidence | 01:10 |
| + LainIwakura (~LainIwaku@user/LainIwakura) | 01:11 | |
| + LainIwakura43 (~LainIwaku@user/LainIwakura) | 01:11 | |
| vagrantc | it seems to perfectly timed, but ... it is a fairly minor issue | 01:11 |
| minute | ohhh suspend resume works... if s2idle and not deep | 01:14 |
| minute | deep probably needs some TF-A support? | 01:14 |
| minute | for ddr parking | 01:14 |
| ch | sounds likely | 01:14 |
| minute | wakeup interrupts _do_ work | 01:15 |
| - schalken (QUIT: Ping timeout: 246 seconds) (~schalken@117-118-178-69.gci.net) | 01:16 | |
| minute | i wonder why deep is the default? | 01:16 |
| minute | (in /sys/power/mem_sleep) | 01:16 |
| minute | ok, time to turn on some devices in dts again... | 01:17 |
| - LainIwakura (QUIT: Quit: Client closed) (~LainIwaku@user/LainIwakura) | 01:27 | |
| - chorc (QUIT: Quit: ZNC 1.9.1 - https://znc.in) (~chorc@user/chorc) | 01:28 | |
| - enwu1 (QUIT: Quit: Ping timeout (120 seconds)) (~enwu@user/enwu) | 01:29 | |
| + enwu (~enwu@user/enwu) | 01:31 | |
| - LainIwakura43 (QUIT: Ping timeout: 250 seconds) (~LainIwaku@user/LainIwakura) | 01:31 | |
| + chorc (~chorc@user/chorc) | 01:36 | |
| minute | i can enable all the things in dts and it wakes up fine (from s2idle) | 01:37 |
| * jn_ -> jn | 01:38 | |
| - chorc (QUIT: Quit: ZNC 1.9.1 - https://znc.in) (~chorc@user/chorc) | 01:45 | |
| + chorc (~chorc@user/chorc) | 01:46 | |
| minute | i did some more tests. HDMI can greatly delay the wake from suspend | 02:15 |
| minute | up to 30 seconds | 02:15 |
| minute | not sure what's going on in that driver. but if the screen/grabber is disconnected, the wakeup is instant | 02:16 |
| - vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:7:77:0:50) | 02:33 | |
| + schalken (~schalken@117-118-178-69.gci.net) | 02:39 | |
| minute | https://source.mnt.re/reform/reform-debian-packages/-/merge_requests/143/diffs | 02:40 |
| minute | https://source.mnt.re/reform/pocket-reform/-/merge_requests/72/diffs | 02:41 |
| minute | when all these are built, i can check on my pocket + classic if i can just suspend to s2idle or if there are pcie issues | 02:42 |
| Tramtrist | 💓 | 02:46 |
| - paperManu (QUIT: Ping timeout: 244 seconds) (~paperManu@198.58.139.163) | 02:57 | |
| - mjw (QUIT: Ping timeout: 265 seconds) (~mjw@gnu.wildebeest.org) | 03:09 | |
| + bkeys (~Thunderbi@h193.131.19.98.dynamic.ip.windstream.net) | 03:22 | |
| - mlarkin_ (QUIT: Ping timeout: 256 seconds) (~mlarkin@syn-076-081-194-027.biz.spectrum.com) | 03:25 | |
| elb | ok I am pretty sure that pressed_keys should be volatile, but it's not the source of the race that I'm seeing | 03:25 |
| elb | (and it's maybe not a race at all; it may just be plain old bad data) | 03:26 |
| elb | I'll put some thoughts together and file an issue, it's going to be a day or two before I can dig on it, I think | 03:26 |
| minute | elb: looking forward! | 03:29 |
| + pomel0 (~pomel0@user/pomel0) | 03:32 | |
| + mlarkin (~mlarkin@syn-076-081-194-027.biz.spectrum.com) | 03:38 | |
| - mlarkin (QUIT: Client Quit) (~mlarkin@syn-076-081-194-027.biz.spectrum.com) | 03:40 | |
| + mlarkin (~mlarkin@syn-076-081-194-027.biz.spectrum.com) | 03:40 | |
| elb | ok, I filed !7, I hope it makes sense | 03:49 |
| minute | did a quick test at home on my pocket reform, with the debian kernel from that build, wakeup from s2idle doesn't work. that will be interesting to debug | 03:49 |
| minute | but first, some sleep, nighty | 03:49 |
| elb | it's not an urgent bug by any means, and I'll maybe have time to dig on it this weekend | 03:49 |
| elb | amen my friend, it's late for me, it's gotta be way late for you :-) | 03:49 |
| elb | sleep well! | 03:49 |
| elb | #7, sorry, not !7, don't know my gitlab parlance well :-) | 03:50 |
| - pomel0 (QUIT: Ping timeout: 264 seconds) (~pomel0@user/pomel0) | 04:54 | |
| + pomel0 (~pomel0@user/pomel0) | 04:59 | |
| - aelius (QUIT: Ping timeout: 244 seconds) (~aelius@user/aelius) | 05:07 | |
| - colinsane (QUIT: Quit: bye) (~colinunin@97-113-71-58.tukw.qwest.net) | 06:28 | |
| + chomwitt (~chomwitt@2a02:85f:9a5f:900:1ac0:4dff:fedb:a3f1) | 07:10 | |
| + LainIwakura (~LainIwaku@user/LainIwakura) | 07:19 | |
| josch | minute: really awesome to read the backlog this morning -- you rock! | 07:31 |
| - LainIwakura (QUIT: Quit: Client closed) (~LainIwaku@user/LainIwakura) | 07:31 | |
| - casparvitch (QUIT: Remote host closed the connection) (~casparvit@user/casparvitch) | 07:44 | |
| + casparvitch (~casparvit@user/casparvitch) | 07:45 | |
| + colinsane (~colinunin@97-113-71-58.tukw.qwest.net) | 07:45 | |
| - casparvitch (QUIT: Remote host closed the connection) (~casparvit@user/casparvitch) | 07:48 | |
| + casparvitch (~casparvit@user/casparvitch) | 07:48 | |
| + LainIwakura (~LainIwaku@user/LainIwakura) | 07:56 | |
| - LainIwakura (QUIT: Quit: Client closed) (~LainIwaku@user/LainIwakura) | 08:26 | |
| + LainIwakura (~LainIwaku@user/LainIwakura) | 08:44 | |
| - LainIwakura (QUIT: Quit: Client closed) (~LainIwaku@user/LainIwakura) | 08:58 | |
| Tramtrist | agreed | 09:16 |
| + LainIwakura (~LainIwaku@user/LainIwakura) | 09:31 | |
| josch | minute: maybe some more things are working in linux6.17. I integrated your patch cleanup changes into my linux6.17 branch and attempted to perform a similar cleanup for the 6.17 rk3588 patch stack from collabora. I made my patch removal its own commit (sitting on the top) in case you find anything useful for your suspend work in it. Many more patches can likely still be dropped but I didn't want to get | 09:34 |
| josch | overzealous. | 09:34 |
| josch | https://source.mnt.re/reform/reform-debian-packages/-/merge_requests/144 | 09:34 |
| josch | minute: the pipeline fails but since you are building your own kernel anyways, that should not matter to you | 09:36 |
| - LainIwakura (QUIT: Quit: Client closed) (~LainIwaku@user/LainIwakura) | 10:34 | |
| grimmware | it's been a very exciting couple of weeks in this channel :) | 11:19 |
| rick_ | interesting.. i think i don't experince brownouts anymore since i changed the cpu governor like minute wrote in the forums. i had them at least every few ours, but since yesterday evening everything seems to run fine ^ | 11:31 |
| rick_ | i let it run over the weekend, but this seems really promising | 11:32 |
| grimmware | rick_: out of interest which desktop environment are you using? | 11:39 |
| rick_ | sway, also been using it on may old laptop since years. i really love it | 11:43 |
| grimmware | gotcha, I was expecting you were gonna say Gnome because I had a hunch that it was the higher power usage (I think holo_memory's was browning out on the switcher because of high CPU usage) | 11:47 |
| grimmware | I've also been using sway for years, recently switched to Niri and it is my new love in part because it's not too far removed from Sway | 11:48 |
| rick_ | yeah.. i despise gnome cause of that XDD | 11:51 |
| rick_ | a few years ago i had tbh a really old laptop. worked fine with sway, but with gnome.. naah.. one core spiked to 100% when i just moved the mouse cursor XDD | 11:51 |
| rick_ | oh i need to check it out ^^ | 11:51 |
| rick_ | well at first i used i3.. than came sway with wayland | 11:52 |
| grimmware | Yeah same :) | 11:52 |
| rick_ | tbh the biggest change regarding the pocket is going back/used to debian again XDD | 11:53 |
| grimmware | hahah yeah this as well - I was using arch previously | 11:54 |
| rick_ | same XDD well i still have it on my other laptop | 11:54 |
| grimmware | this :) | 11:54 |
| grimmware | I would have switched the pocket over to it as well but I really like the idea of having a roughly representative build so I can contribute to the community :) | 11:54 |
| grimmware | Having spent most of my professional career in debian derived environments makes that a lot easier too | 11:55 |
| rick_ | and i was like "well i use debian on my servers.. why not test it again for desktop usage" XD | 11:55 |
| grimmware | I'm pretty pleased with unstable to be honest, I feel like it's a little more dicey than arch in terms of reliability but for the most part it's like using debian with new software hahah | 11:58 |
| grimmware | I should really do some digging to see if there's a built-in way to only install packages once they're at least N days old (with exemptions for like, kernel) | 11:59 |
| grimmware | I bet unstable on like a 2 week delay is actually pretty stable | 12:00 |
| bremner | that's testing, basically | 12:00 |
| rick_ | yeah.. arch seems to be a litte more stable.. well i only have one problem currently. i updated evolution and now it crashes when i try to load external images in my mails. buuut i think it will be fixed soon | 12:00 |
| grimmware | the main thing I miss from arch is the AUR | 12:05 |
| grimmware | I had a really nice containerized build environment using systemd-nspawn so I could install all the build dependencies in the container so I didn't litter the host system with bullshit from half-hearted experiments | 12:05 |
| rick_ | yeah.. and i felt for one trap. i know not all desktop application supports arm.. and i thought... well i have flatpak.. this should not be arch depened.. well i learned sth new there XDD | 12:14 |
| rick_ | and here i thought flatpkat would fix this XDD | 12:15 |
| + paperManu (~paperManu@198.58.139.163) | 12:18 | |
| bremner | josch: minute: btw I noticed that the "enable PM" patch by Shawn Lin was dropped from the latest collabora patch stack. previous version: https://paste.debian.net/1402470. I haven't had a chance to investigate further, I don't even know if this was intentional | 12:19 |
| + mjw (~mjw@gnu.wildebeest.org) | 12:30 | |
| + LainIwakura (~LainIwaku@user/LainIwakura) | 12:40 | |
| josch | bremner: I'd ask Sebastian Reichel. He answered super quickly to the mails i wrote him in the past. | 12:51 |
| bremner | ok | 12:51 |
| + gustav25 (~gustav@c-78-82-53-228.bbcust.telenor.se) | 13:02 | |
| - mjw (QUIT: Ping timeout: 240 seconds) (~mjw@gnu.wildebeest.org) | 13:11 | |
| elb | here's minute getting up this morning and immediately showing us everything we've been dreaming of in a fifteen second video ;-) | 13:17 |
| minute | bremner: interesting, i also dropped that in my mono kernel but only because it didn't apply cleanly and i wanted to fix that later | 13:19 |
| * Guest6281 -> mjw | 13:19 | |
| minute | elb: haha :D i don't know how much power saving there will be through this in the end on pocket reform though. but it should help a bit | 13:20 |
| + andreas-e (~Andreas@2a02-8434-b6a3-e901-facc-8e87-8e54-890e.rev.sfr.net) | 13:20 | |
| minute | rick_: but so far most things i tried from flathub had arm64 builds! | 13:22 |
| grimmware | it's so frustrating that some people just need to enable an arm64 CI runner in github | 13:22 |
| elb | minute: I mean, even an apparatus that shuts off all the lights and backlights and tells the browser or whatever other godforsaken modern software is running to chill the %!@# out for a bit will make a big difference ;-) | 13:23 |
| grimmware | yeah s2idle would be great in combination with e.g. swayidle | 13:23 |
| bremner | minute: josch: Oh, I think it might be replaced by cf28eebd4269a89814af | 13:24 |
| grimmware | I don't know about anyone else but now that I don't have display flicker and can power the display on and off, and hopefully with the v2 charger board my head-of-queue problem for this to be the machine I want it to be probably becomes sysctl power consumption. | 13:25 |
| bremner | minute: josch: https://paste.debian.net/1402479/ | 13:25 |
| elb | I think a lid switch would be pretty easy on the pocket, too | 13:25 |
| grimmware | minute: with the v2 board is there any idle power consumption with the shipping switch set to off? | 13:26 |
| elb | right corner away from the hinges | 13:26 |
| minute | elb: yeah, that apparatus is def. there | 13:26 |
| elb | the latch magnets are pretty close, one of them might need to come out | 13:26 |
| elb | (assuming hall effect or similar) | 13:26 |
| grimmware | tbf you could probably just glue one into the case elsewhere | 13:27 |
| minute | grimmware: good Q. it should be miniscule but haven't measured yet. a good job for the nordic power profiler kit that sits yet unused on my shelf | 13:27 |
| grimmware | nothing like a bit of kit to make you want to do a job ;) | 13:28 |
| minute | hehehe | 13:28 |
| minute | the display bezel, which is a pcb, could have a mechanical end stop lid switch with i2c gpio on the inside. just sayin' | 13:29 |
| minute | but first i want s2idle for everyone :0 (i hope this isn't thwarted by unsurmountable pcie stuff) | 13:29 |
| minute | bremner: good find, thanks! | 13:30 |
| elb | on the pocket I can tell you that using trackball motion to wake from idle is going to take some firmware changes, though ;-) | 13:32 |
| elb | I've done some playing with that, and you get significant pointer movement if you just close the case and give it a good shake | 13:32 |
| minute | elb: ohh haha | 13:33 |
| minute | elb: so far wake is a special command that the keyboard sends to sysctl, and sysctl passes it on to SoC by wiggling a gpio line that is reserved for this | 13:33 |
| minute | i.e. no usb necessary (but also not sure if usb wake works at all) | 13:34 |
| elb | is it different from 1p? | 13:34 |
| bremner | so false alarm I guess re the PM patch | 13:34 |
| elb | but yeah that solves the trackball problem either way | 13:34 |
| elb | I think I'm headed to looking closely at that sysctl/keyboard remote interface, btw, I think it's the answer to #7 | 13:37 |
| elb | (which is super not urgent, but I've always found that getting deep into a project is well served by starting with poking around the edges) | 13:37 |
| minute | elb: just checked, yeah it's 'w' | 13:37 |
| minute | elb: yeah, appreciate you turning those stones | 13:38 |
| elb | ok so this stuff might also be relevant for gating the USB HID and full keyboard polling | 13:38 |
| elb | when the system is powered off/sleeping/etc | 13:38 |
| minute | elb: some of these things have history that by now feels ancient. this uart sysctl interface was already in reform 1.0 which was like 7 or 8 years ago | 13:38 |
| elb | I might have some opinions about this sysctl interface in general ;-) | 13:39 |
| elb | I love that it's plain text | 13:39 |
| elb | but I itch for a spec and some careful regularity in the syntax | 13:39 |
| minute | elb: right. the keyboard will have to know about the sleep mode to also gate everything | 13:39 |
| minute | elb: right. there is i think regularity in the commands (it's always digit + letter), this was to ensure parsing would never cause headaches. just rhe responses are not regular enough which irks me as well, and they could use some crc or similar | 13:41 |
| elb | yeah exactly, the commands seem solid, but the responses are complicated | 13:41 |
| elb | in particular the battery and power stuff | 13:41 |
| minute | i also want to add crc to the spi interface, which mojyack prototyped once but it needs to be done in a cleaner way. which is now possible since we have api versioning on that part | 13:42 |
| minute | elb: right, i agree | 13:42 |
| elb | on the sysctl serial interface, crc has the disadvantage that it's not uart-bangable | 13:42 |
| elb | wait let me clarify that | 13:43 |
| elb | it's not uart-bangable into my terminal with a keyboard ;-) | 13:43 |
| elb | I don't know if you actually use that, but it sure feels designed to allow it | 13:43 |
| minute | elb: right. i mean we rarely if ever have issues with data integrity of 2 letter commands | 13:43 |
| minute | elb: it is absolutely designed to allow that. | 13:43 |
| elb | fair, re: 2 letter commands :-) | 13:44 |
| elb | but also that could be "fixed" with framing | 13:44 |
| minute | elb: i also have a little on switch/face plate pcb that plugs into a sysctl port, it has an attiny and it was really easy to implement the necessary uart protocol :D | 13:44 |
| minute | elb: right | 13:44 |
| elb | like, send ASCII SOH or STX or something, then the message, then the CRC, then ETX or EOT | 13:45 |
| minute | elb: for the responses you mean? | 13:45 |
| elb | request | 13:45 |
| elb | and if the request is sent that way, the response comes back with framing and CRC | 13:46 |
| minute | ah, a frame marker that also suggests a newer api version | 13:46 |
| elb | yeah | 13:46 |
| minute | sounds good to me | 13:46 |
| elb | but essentially dual-stack | 13:46 |
| minute | right, i like that | 13:47 |
| elb | if you type at the keyboard, and it's a valid message, it accepts and it does what it does | 13:47 |
| elb | but if the keyboard firmware sends a request, it's more robust and has a binary nature | 13:47 |
| elb | these microcontrollers are _super_ under-used, there's plenty of room for dual stack, the cost is code complexity | 13:47 |
| bremner | ACTION rebuilds kernel on pocket, again | 13:59 |
| minute | elb: agreed. with the 2350 there's even more unused oomph | 14:08 |
| minute | one could make a personal computer just out of the keyboard... i mean it's much faster than the desktop computers i had in the 90s | 14:09 |
| elb | absolutely | 14:09 |
| rick_ | > it's so frustrating that some people just need to enable an arm64 CI runner in github | 14:09 |
| elb | I have a project on the back burner here I call the "retro-modern workstation" that's basically a mid-90s Unix workstation on a moderately fast ARM Cortex-M | 14:09 |
| rick_ | yeah looking at you threema desktop... | 14:09 |
| minute | the rp2350a has 520kB SRAM | 14:10 |
| - paperManu (QUIT: Ping timeout: 255 seconds) (~paperManu@198.58.139.163) | 14:10 | |
| minute | and dual core 150MHz | 14:10 |
| minute | more than enough for text web browsing and playing doom :D | 14:10 |
| elb | meanwhile my first Linux box was a 50 MHz 486 ;-) | 14:10 |
| elb | it did have more than 520 kB of RAM, but it was slower RAM than that SRAM, so ... | 14:11 |
| elb | (and the difference between the on-chip flash or an eMMC and a 90s hard disk is difficult to overstate) | 14:11 |
| minute | haha yeah i think my first linux was probably on a 166mhz pentium already (or maybe already amd something?) i also vaguely remember having had a amd k6-iii box with freebsd for a while | 14:12 |
| - LainIwakura (QUIT: Quit: Client closed) (~LainIwaku@user/LainIwakura) | 14:12 | |
| elb | ok well when I'm chasing down this power-off detection situation I'm going to be in the remote interface, I'll think about what a more structured protocol might look like | 14:12 |
| elb | and at the very least get some more detailed documentation in place | 14:12 |
| minute | elb: awesome, looking fwd | 14:12 |
| elb | I really love how tiny these firmwares are | 14:13 |
| bremner | I guess the pocket resume is getting farther with Sebastian's latest patches, but still triggering watchdog / LOCKUP: https://paste.debian.net/1402487/ | 14:13 |
| minute | elb: that's one of the reason why i still can't commit to frameworks like zmk/zephyr etc, because i still think, this stuff is so small, solution still fits in head... | 14:21 |
| minute | (and pico-sdk and tinyusb are already the frameworks here) | 14:21 |
| minute | bremner: can you try with echo s2idle > pm_sleep ? | 14:21 |
| minute | bremner: or you already did? | 14:22 |
| + LainIwakura (~LainIwaku@user/LainIwakura) | 14:23 | |
| bremner | minute: I will try it, one sec. | 14:25 |
| minute | grimmware: could i use ebpf to trace all the PM related calls in the kernel? instead of putting many printks in there i mean | 14:26 |
| bremner | minute: did you mean mem_sleep? I don't have /sys/power/pm_sleep | 14:28 |
| bremner | or some other path? | 14:28 |
| bremner | minute: by eye, the result looks about the same. | 14:35 |
| + paperManu (~paperManu@modemcable141.205-200-24.mc.videotron.ca) | 14:36 | |
| minute | bremner: ah yes mem_sleep | 14:39 |
| minute | bremner: that's weird, because i wasn't able to wake from the default "deep" | 14:39 |
| bremner | I ran (basically) echo s2idle > mem_sleep && echo mem > state | 14:40 |
| minute | bremner: right. could you show the log of that? | 14:41 |
| minute | bremner: and how are you triggering wake? or not at all? | 14:41 |
| minute | bremner: and what if you echo core > pm_test and then echo mem > state? (it should auto wake after 5 seconds) | 14:42 |
| bremner | minute: I ran https://paste.debian.net/1402490/ | 14:43 |
| bremner | it does auto wake, but then hard locks during the resume | 14:43 |
| bremner | dropping the PCI busses is cargo-culted from a hibernation test, I guess I could try without that | 14:44 |
| minute | bremner: yeah can you comment out all pci related stuff? | 14:44 |
| minute | it looks to me as if it is hanging during pci rescan | 14:45 |
| grimmware | minute: yes. I can probably take a look at it this weekend if you can just write down what it is roughly you want to see. Probably give you a working bpftrace example and then enough relevant knowledge to be dangerous. | 14:46 |
| grimmware | I’ve been wanting to sharpen my skills on this for a while | 14:47 |
| bremner | minute: without the PCI stuff it complains about NVME nvme 0004:41:00.0: Unable to change power state from D3hot to D0, device inaccessible | 14:48 |
| grimmware | I’m guessing you’re wanting to trace syscalls and introspect on their invocation and arguments and log out to a file in userland, right? If so the names of some of the syscalls would be handy. | 14:49 |
| bremner | ah, a log. I can grab a log of the version with pci unloading. I'm not sure if core is different than platform here | 14:49 |
| minute | grimmware: log to dmesg / serial also fine | 14:50 |
| minute | grimmware: i don't need syscalls, but all the pm suspend related function calls inside the kernel and their args yes. to see which point it reaches before hanging | 14:51 |
| bremner | PM: Unsupported test mode for suspend to idle, please choose none/freezer/devices/platform. | 14:52 |
| bremner | so I guess platform it is | 14:52 |
| minute | grimmware: i would normally stick printk with function/line macro in every function, but was wondering if there are more elegant ways. | 14:52 |
| minute | bremner: hmm you don't have core? that's weird | 14:53 |
| grimmware | minute: I can give you something I think you’ll be exceptionally pleased with as a future debugging tool. | 14:54 |
| grimmware | minute: can you give me an example of one of the function names you’re interested in? | 14:54 |
| grimmware | I can probably put together an example this afternoon | 14:55 |
| minute | woah there (re deep sleep) https://sc.sigmaris.info/@hughcb/115429185636847860 | 14:55 |
| minute | grimmware: just an example: rockchip_pcie_suspend / rockchip_pcie_resume | 14:57 |
| minute | grimmware: but basically anything *_suspend and *_resume | 14:57 |
| bremner | btw is it expected to traceback when removing the mt76x2u module? https://paste.debian.net/1402494/ ? | 14:58 |
| bremner | I wonder if the kernel is already in bad state before the suspend? | 14:58 |
| minute | bremner: no that's a bug | 14:59 |
| minute | maybe drivers/irqchip/irq-gic-v3-its.c:3639 has a comment | 14:59 |
| bremner | minute: here's a partial log for the platform test https://paste.debian.net/1402496/ ; I have to run now but I can test more later. | 15:03 |
| minute | bremner: many thanks. i'll try to reproduce that | 15:04 |
| - ericsfraga (QUIT: Quit: ERC 5.6.1-git (IRC client for GNU Emacs 31.0.50)) (~user@2a00:23cc:b475:7c01:53b:6ddf:a36e:d38b) | 15:16 | |
| elb | I'd like to write a HACKING document for the keyboard firmware, since I've spent the time to figure some things out; how do people think that should be done? HACKING.rst (the handbook is RST, is that the preferred format for Reform stuff? I love me a little bit of org-mode ...) in pocket-hid? Something else? | 15:40 |
| grimmware | elb: not that I have any decision rights here but I love what you're talking about doing here :) | 15:41 |
| elb | I see that the README for the handbook is markdown, though, maybe markdown is better | 15:45 |
| elb | anyway, format is negotiable, I think the question is the appropriate way to make it available | 15:46 |
| cararemixed | Easy to pandoc it postfacto I guess? I'm very curious to read this. | 15:51 |
| grimmware | ^ yeah I'd crack on and write what it is you want to write :) | 15:56 |
| grimmware | it sounds really helpful | 15:56 |
| minute | elb: HACKING.md sounds great! | 16:22 |
| minute | (rst is fine too, i thnk gitlab can render that as well) | 16:22 |
| grimmware | I have opinions about that particular bikeshed but I'm going to wait until it's built before arguing about what colour it should be painted :) | 16:26 |
| minute | .md is what most people know, so we do everything except the actual handbooks with it | 16:27 |
| minute | haha i didn't know that "worse is better" is also called the "New Jersey approach" in the original essay | 16:29 |
| minute | (https://dreamsongs.com/WIB.html) | 16:29 |
| elb | OK, I'll draft up some high level stuff and drop it in as HACKING.md | 16:37 |
| cwebber | Worse is Better is one of my favorite essays | 16:55 |
| cwebber | shock and surprise :) | 16:55 |
| minute | ;D | 17:06 |
| minute | ok on my test kernel i see > [ 1.711085] pci_bus 0000:01: busn_res: can not insert [bus 01-ff] under [bus 00-0f] (conflicts with (null) [bus 00-0f]) | 17:06 |
| minute | but i don't have that on the pocket with regular kernel | 17:06 |
| minute | > [ 1.730077] pci_bus 0000:00: Some PCI device resources are unassigned, try booting with pci=realloc | 17:07 |
| minute | ah, pocket doesn't have pcie3x4 currently | 17:09 |
| grimmware | oh shit we're not distributing the btf data for the kernel are we? | 17:11 |
| grimmware | lemme see if I can figure out what's required to build and distribute it | 17:12 |
| minute | no idea :0 | 17:12 |
| grimmware | I'll take a look at that later, I'll see if I can get this bpftrace working without, I think it should be fine with just the headers... | 17:13 |
| minute | i wanted to test pcie+suspend with an old samsung 970 evoplus i have here on my desk, and it looks like it needs to much BAR space lol | 17:16 |
| minute | that gives me an excuse to try https://raw.githubusercontent.com/mariobalanica/arm-pcie-gpu-patches/refs/heads/main/linux/6.16/0004-PCI-dwrockchip-Disable-root-port-BARs.patch | 17:16 |
| - LainIwakura (QUIT: Quit: Client closed) (~LainIwaku@user/LainIwakura) | 17:21 | |
| minute | uff, there's a pcie probing race https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/issues/30 | 17:23 |
| + rwa_ (~rene@2001:9e8:3397:df00:9df8:e9ab:69c:821) | 17:24 | |
| minute | this is supposed to be the fix, but i have that in the git log https://lore.kernel.org/linux-pci/20250403093137.1481-1-ilpo.jarvinen@linux.intel.com/ | 17:25 |
| minute | ok, other nvme works, it's just something weird about this samsung | 17:49 |
| minute | bremner: i can do s2idle with nvme no problem on my test kernel | 17:53 |
| minute | (the nvme isn't mounted, but will try that now) | 17:53 |
| lidstah | samsung evo 970? (I have one, the controller can hit 110°C on sustained writes - I do have some Crucial and Kingston nvme drives who barely hit 60°C in the same NUCs (proxmox cluster)) - and Hi all btw ! | 17:53 |
| minute | lidstah: hi! yeah 970evo plus. it might be broken also. | 17:54 |
| lidstah | mine is now shelved, nice paperweight tho | 17:54 |
| lidstah | (sigh) | 17:54 |
| lidstah | can't afford losing a node in my cluster as I use it both for work, for home and for an engineering school I work for part-time | 17:55 |
| minute | bremner: i took my (taifast) out of my personal pocket reform onto the test board, and s2idle suspend/wake works with it | 18:07 |
| minute | (mounted) | 18:07 |
| minute | now lets try the pcie2 host... | 18:07 |
| minute | works there as well | 18:12 |
| minute | bremner: what nvme brand do you have? probably WD? | 18:12 |
| + LainIwakura (~LainIwaku@user/LainIwakura) | 18:25 | |
| - mlarkin (QUIT: Quit: leaving) (~mlarkin@syn-076-081-194-027.biz.spectrum.com) | 18:29 | |
| + mlarkin (~mlarkin@syn-076-081-194-027.biz.spectrum.com) | 18:29 | |
| + vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:50) | 18:38 | |
| gordon2 | okay, so i implemented parametrized classic trackball cup in freecad ( https://source.mnt.re/gordon/sin-trackball-parts ) that allows the change of ball size, sensor offsets and some other parameters and printed a bag of cups with various offsets, 20mm SiN ball works in all the cases no matter how far you offset it down or up and no matter how you move the sensor ±2mm offset from center, with | 18:39 |
| gordon2 | 25mm SiN ball adding 2mm ball offset from baseline makes it track quite well and reliably (but obviously it won't fit in the case), so i ordered some other balls (24mm and 22.225mm dia) to possibly find a sweet spot | 18:39 |
| minute | gordon2: cool! | 18:43 |
| + wielaard (~mjw@gnu.wildebeest.org) | 18:47 | |
| gordon2 | also my hands are sore after screwing hundreds of screws directly into printed holes =/ | 18:50 |
| gordon2 | but as a conclusion, distance between ball and sensor is probably the most defining factor | 18:52 |
| - rwa_ (QUIT: Quit: Leaving) (~rene@2001:9e8:3397:df00:9df8:e9ab:69c:821) | 19:06 | |
| rick_ | Oh so much for the good news.. My charger board went poof on my pocket. Battery was full, so it shouldn't had thaat much load, but its clearly bured throug | 19:10 |
| rick_ | I did remove the batteries for now | 19:10 |
| rick_ | Well the system itsel had some load.. Watched a stream via mpv while it happened | 19:11 |
| minute | rick_: oh well ;/ we'll send you a v2 one of course | 19:12 |
| rick_ | yeah, thanks ^^ i'll alreday created a support ticket yesterday :3 | 19:16 |
| rick_ | and no hurries ^^ | 19:16 |
| bremner | minute: err. /sys/class/block/nvme0n1/device/device/vendor is 0x126f | 20:22 |
| bremner | things like lsblk report the helpful "SSD 1TB" | 20:23 |
| bremner | that seems to refer to Silicon Motion. | 20:24 |
| bremner | which is also what I saw under the back cover | 20:24 |
| + cellmoose (cellmoose@znc.tilde.green) | 20:29 | |
| - LainIwakura (QUIT: Ping timeout: 250 seconds) (~LainIwaku@user/LainIwakura) | 20:31 | |
| cellmoose | hello! i'm a new owner of a pocket reform, and thought it would be fun to check this place out | 20:31 |
| + LainIwakura19 (~LainIwaku@user/LainIwakura) | 20:32 | |
| cellmoose | and I might as well start with a question: I've got the DIY kit. I've assembled everything except the top cover, and when I turn the thing on the LED on the processor module is pink (I've unplugged/plugged in the ribbon cable). I assuming the pink light indicates some issue? | 20:36 |
| + LainIwakura (~LainIwaku@user/LainIwakura) | 20:36 | |
| - LainIwakura19 (QUIT: Ping timeout: 250 seconds) (~LainIwaku@user/LainIwakura) | 20:39 | |
| bremner | oops I ran the battery of my pocket to zero again, because only one usb c port works for charging | 21:00 |
| bremner | cellmoose: it might depend on the module but my rk3588 is green | 21:01 |
| josch | gordon2: awesome work! I'd like to try and replicate one of your designs | 21:15 |
| gordon2 | josch: oh, this one is quite more conventional, with screws and all, just pick the ball size you like and print it | 21:18 |
| gordon2 | tbh i am still not convinced that magnets are way to go, especially with heavier and harder ball | 21:21 |
| gordon2 | if they won't keep it in place for example in my bag if i bump it | 21:21 |
| - pomel0 (QUIT: Ping timeout: 252 seconds) (~pomel0@user/pomel0) | 21:23 | |
| + pomel0 (~pomel0@user/pomel0) | 21:23 | |
| - paperManu (QUIT: Ping timeout: 240 seconds) (~paperManu@modemcable141.205-200-24.mc.videotron.ca) | 21:24 | |
| minute | i just had kmscube running on an amdgpu (polaris10) over mpcie->pcie breakout on rk3588 reform classic | 21:24 |
| minute | cellmoose: the pink LED is fine, it's just the power led of rcore | 21:25 |
| gordon2 | wow that's quite an achievement | 21:26 |
| + paperManu (~paperManu@modemcable141.205-200-24.mc.videotron.ca) | 21:26 | |
| * mjw -> Guest9444 | 21:29 | |
| - Guest9444 (QUIT: Killed (zinc.libera.chat (Nickname regained by services))) (~mjw@2001:1c06:2486:a800:7602:5eff:dc71:a72c) | 21:29 | |
| * wielaard -> mjw | 21:29 | |
| + Guest9444 (~mjw@2001:1c06:2486:a800:7602:5eff:dc71:a72c) | 21:29 | |
| minute | gordon2: well i basically only added these patches https://github.com/mariobalanica/arm-pcie-gpu-patches/tree/main/linux/6.16 | 21:36 |
| minute | (and found a wonky hardware setup that kind of works) | 21:36 |
| cellmoose | minute: good to know. then there are some other issue. When I try to power it on I get a pink LED on the processor, but the display is completely blank. I'll pick up a mini HDMI adapter and see if I can get an image on an external monitor | 22:00 |
| - pomel0 (QUIT: Ping timeout: 256 seconds) (~pomel0@user/pomel0) | 22:09 | |
| + pomel0 (~pomel0@user/pomel0) | 22:09 | |
| - gustav25 (QUIT: Quit: Quit) (~gustav@c-78-82-53-228.bbcust.telenor.se) | 22:15 | |
| minute | cellmoose: maybe one of the display cables not connected correctly? | 22:17 |
| cellmoose | minute: ill have to double check both ends. the connector pads are supposed to be facing down? | 22:23 |
| cellmoose | on the ribbon cabel, i mean | 22:23 |
| - schalken (QUIT: Ping timeout: 256 seconds) (~schalken@117-118-178-69.gci.net) | 22:32 | |
| + schalken (~schalken@117-118-178-69.gci.net) | 22:33 | |
| minute | cellmoose: yes, and there's also the DSI cable connecting RCORE to the motherboard | 22:51 |
| minute | cellmoose: you can also show some photos to check | 22:51 |
| - schalken (QUIT: Ping timeout: 264 seconds) (~schalken@117-118-178-69.gci.net) | 22:58 | |
| + schalken (~schalken@117-118-178-69.gci.net) | 23:01 | |
| - schalken (QUIT: Ping timeout: 244 seconds) (~schalken@117-118-178-69.gci.net) | 23:08 | |
| - paperManu (QUIT: Ping timeout: 244 seconds) (~paperManu@modemcable141.205-200-24.mc.videotron.ca) | 23:08 | |
| + schalken (~schalken@117-118-178-69.gci.net) | 23:10 | |
| - LainIwakura (QUIT: Quit: Client closed) (~LainIwaku@user/LainIwakura) | 23:11 | |
| + LainIwakura (~LainIwaku@user/LainIwakura) | 23:22 | |
| + paperManu (~paperManu@198.58.139.163) | 23:24 | |
| jfred | re: Worse is Better, as someone who lives in New Jersey... sounds about right lol | 23:30 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!