| + synnfynn (~synnfynn@user/synnfynn) | 01:11 | |
| - synnfynn (QUIT: Quit: comms terminated..) (~synnfynn@user/synnfynn) | 01:25 | |
| - mjw (QUIT: Ping timeout: 250 seconds) (~mjw@195.23.216.83) | 02:04 | |
| - paperManu (QUIT: Ping timeout: 264 seconds) (~paperManu@64.58.44.160) | 03:30 | |
| - GNUmoon2 (QUIT: Remote host closed the connection) (~GNUmoon@gateway/tor-sasl/gnumoon) | 06:54 | |
| + GNUmoon2 (~GNUmoon@gateway/tor-sasl/gnumoon) | 06:55 | |
| - RandyK (QUIT: Remote host closed the connection) (~RandyK@user/randyk) | 07:57 | |
| + RandyK (~RandyK@user/randyk) | 07:57 | |
| - robin_ (QUIT: Ping timeout: 260 seconds) (~robin@user/terpri) | 08:51 | |
| + mjw (~mjw@195.23.216.83) | 08:51 | |
| + robin (~robin@user/terpri) | 08:57 | |
| - mjw (QUIT: Ping timeout: 264 seconds) (~mjw@195.23.216.83) | 09:16 | |
| + gustav2 (~gustav@c-78-82-55-162.bbcust.telenor.se) | 10:02 | |
| + mjw (~mjw@89.205.182.162) | 10:31 | |
| - mjw (QUIT: Ping timeout: 245 seconds) (~mjw@89.205.182.162) | 11:03 | |
| + mjw (~mjw@89.205.182.162) | 11:31 | |
| - mjw (QUIT: Ping timeout: 264 seconds) (~mjw@89.205.182.162) | 12:03 | |
| + mjw (~mjw@89.205.182.162) | 12:05 | |
| - mjw (QUIT: Remote host closed the connection) (~mjw@89.205.182.162) | 12:32 | |
| + mjw (~mjw@89.205.182.162) | 12:33 | |
| minute | hmm, on my next, "dim screen" is turned off in "power saving" in gnome settings, but it still dims the screen... wtf | 13:09 |
|---|---|---|
| minute | this might be power saver mode, but for some reason the widget to switch power saving / "balanced" is missing in this one's gnome control panel | 13:10 |
| minute | aha, power-profiles-daemon was not installed | 13:12 |
| minute | this system is from july 15 | 13:13 |
| minute | apparently one can also try "tuned", testing that | 13:17 |
| + paperManu (~paperManu@64.58.44.160) | 13:22 | |
| minute | josch: if we shipped "tuned" & co instead of power-profiles-daemon (not sure which of the other profiles are needed), we get 3 power profiles in gnome instead of 2, "performance" comes back which is very nice to have. | 13:31 |
| - svp (QUIT: Quit: Gateway shutdown) (~svp@2002:4f07:f0bd:0:69b1:b463:d245:e861) | 13:35 | |
| - mjw (QUIT: Ping timeout: 240 seconds) (~mjw@89.205.182.162) | 13:38 | |
| + svp (~svp@2002:4f07:f0bd:0:69b1:b463:d245:e861) | 13:40 | |
| + synnfynn (~synnfynn@user/synnfynn) | 14:19 | |
| ch | https://www.lumafield.com/article/finding-hidden-risks-in-the-battery-supply-chain | 14:45 |
| ch | (via fedi) | 14:45 |
| josch | minute: you just tell me or commit into reform-debian-packages:reform-tools/debian/control directly --- you know more about gnome than i :) | 14:45 |
| + mjw (~mjw@89.205.182.162) | 14:51 | |
| ch | minute: do you need me to / can i do something to make the pocket-hid fw appear in lvfs? | 15:15 |
| + paperManu_ (~paperManu@64.58.44.160) | 15:31 | |
| - mjw (QUIT: Remote host closed the connection) (~mjw@89.205.182.162) | 15:34 | |
| + mjw (~mjw@89.205.182.162) | 15:35 | |
| minute | josch: ok, will do! | 15:38 |
| minute | ch: query | 15:38 |
| minute | i just had a pocket-typical system reset on reform next! after 2h45 uptime | 15:57 |
| minute | first i thought it was a brownout, but no, system runs fine after that reboot, even under load test | 15:57 |
| minute | coincidentally i had a log task running that logs uptime and the content of lpc "cells" file every 10 seconds, and the last entry has 0 0 0 0 for the second pack of cells | 15:57 |
| minute | this means system controller got stuck there, didn't respond to SPI anymore and then got reset by watchdog (which has 10 sec timeout) | 15:58 |
| minute | (ok, now i got the real poweroff because some cells reached 2.5v) | 16:02 |
| ch | i still need to stick timeouts on all i2c ops in the pocket sysctl | 16:03 |
| minute | yes, you or me :D | 16:09 |
| - paperManu_ (QUIT: Ping timeout: 240 seconds) (~paperManu@64.58.44.160) | 16:32 | |
| chorc | minute: I'm happy to report that I've been running both keyboard fw and sysctl fw from this build for about a week https://source.mnt.re/reform/pocket-reform/-/jobs/13221 and I didn't have any random reboots; also the issue that they system doesn't boot (blank screen) occasionally, requiring power cycle - also gone https://source.mnt.re/reform/pocket-reform/-/jobs/13221 | 16:36 |
| minute | chorc: oh, very nice | 16:37 |
| chorc | in slightly less happy news, my new charging board lasted for two weeks and did magic smoke trick last night | 16:37 |
| chorc | it's funny, because I know my luck and last time I asked plom if I can buy more than one charging board, they said no, so I'll be back in a line for a new one again | 16:38 |
| - mjw (QUIT: Ping timeout: 240 seconds) (~mjw@89.205.182.162) | 16:38 | |
| minute | chorc: argh, i'm very sorry. i can tell you that the line is very short at least. | 16:49 |
| minute | chorc: and the v2 is being finished atm | 16:49 |
| chorc | minute: thank you, good to know! I was thinking I should request a six pack this time :) | 16:50 |
| josch | chorc: ouch :( | 17:34 |
| chorc | josch: yeah, not great, but the summer is over, I can survive on a powerbank and staying near socket :) the bubble is smaller this time, I'm wondering if it indicates something https://ibb.co/DfnKKdvR | 17:43 |
| josch | chorc: you are the first person i hear of who had this happen to them twice | 17:44 |
| chorc | josch: I have a bit of a beta tester luck/karma, don't know how to call it; computers crap out around me all the time, this allowed me to have a successful career in the industry :-) | 17:47 |
| chorc | it's actually the third warranty claim, the first one wasn't charing board related | 17:47 |
| josch | fuuuu XD | 17:47 |
| ch | git users, help! how can i tell git to remember that my local zeha-main branch should be pushed to remote zeha as branch main? | 17:52 |
| josch | git push --set-upstream origin zeha-main:main | 17:59 |
| josch | using --set-upstream, subsequent "git push" will do the right thing, no? | 17:59 |
| ch | josch: https://paste.debian.net/hidden/ede4f587/ :( | 18:01 |
| josch | surely this is possible somehow? :/ | 18:06 |
| ch | thats my big hope :) | 18:06 |
| - plomtest (QUIT: Remote host closed the connection) (~plom@user/plomtest) | 18:21 | |
| + plomtest (~plom@user/plomtest) | 18:21 | |
| - plomtest (QUIT: Remote host closed the connection) (~plom@user/plomtest) | 18:21 | |
| + plomtest (~plom@user/plomtest) | 18:22 | |
| - plomtest (QUIT: Remote host closed the connection) (~plom@user/plomtest) | 18:22 | |
| minute | this works surprisingly well for me on pocket https://messenger.abeto.co/ | 18:45 |
| josch | also smooth fps on a311d :) | 18:54 |
| minute | nice! | 18:59 |
| ch | would be nice if fwupd.org could tell me (without login) if a given firmware is in the catalog already or not | 19:36 |
| minute | ch: yeah, i think the caching / distribution takes a while and i guess you can only check with the cli tools? | 19:42 |
| ch | yeah so the authenticated web thing shows me 'The remote metadata will be rebuilt in 18 minutes. This firmware has not yet been included in the XML catalog.' | 19:42 |
| ch | but a) i cant seem to get that from CI, b) it was not saying that for a build earlier today and it wasnt in the catalog ttbomk | 19:43 |
| minute | ah ;/ | 19:43 |
| ch | but yeah, i guess downloading the catalog and checking would be an option | 19:44 |
| ch | hexdump -C mntre-embargo.jcat.gz | tail -2 | 19:48 |
| ch | 000008e0 00 00 49 48 41 54 45 43 44 4e |..IHATECDN| | 19:48 |
| ch | i'm sure there's an interesting backstory here :D | 19:48 |
| minute | wow :D | 19:48 |
| ch | https://github.com/fwupd/fwupd/issues/6032 o_o | 19:54 |
| ch | The remote metadata will be rebuilt in 56 minutes. This firmware has not yet been included in the XML catalog. | 20:05 |
| ch | not sure how the fw can have missed the first catalog rebuild | 20:05 |
| ch | aha, its in the catalog now | 20:09 |
| ch | so i think thats all quite good now | 20:16 |
| minute | ch: "password" in your MR should be the token, right? | 20:18 |
| ch | yes! | 20:18 |
| ch | the build logs look like pico-sdk now always builds a picotool? | 20:27 |
| josch | ch: see ./tools/Findpicotool.cmake -- it downloads and builds it as an external project | 20:35 |
| minute | https://source.mnt.re/reform/pocket-reform/-/jobs/13356 | 20:35 |
| ch | josch: i dont understand how that gets included | 20:40 |
| ch | oh wow, pico_add_uf2_output needs picotool now? | 20:42 |
| ch | annoying | 20:42 |
| josch | ch: yes, the uf2 stuff was moved from pico-sdk to picotool | 20:43 |
| josch | how do i know? there was a s390x big-endian bug in it... | 20:43 |
| ch | right | 20:43 |
| ch | i guess we could at least try to build it only once | 20:43 |
| ch | would be nice if the version numbers of picotool and the sdk were aligned | 21:23 |
| ch | but the 2.2.0 sdk looks for picotool 2.1.1 | 21:23 |
| minute | interesting panfrost/panvk things are coming https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37462 | 21:33 |
| minute | ch: funky, probably because the pipeline already ran with that tag https://source.mnt.re/reform/pocket-reform/-/jobs/13367#L242 | 21:46 |
| ch | 502? weird | 21:49 |
| ch | maybe lvfs.org was flaky at that moment | 21:49 |
| ch | anyway the 20250927 versions are in lvfs | 21:49 |
| ch | i'll try to submit an update report at 22:05 | 21:49 |
| minute | for me the embargo version numbers are some new kind of integer, like 1113 | 21:58 |
| minute | > Source: https://source.mnt.re/reform/pocket-reform/-/tags/1113 | 21:58 |
| minute | strange? | 21:58 |
| ch | new version is not in the catalog yet | 22:04 |
| ch | 1113 is my test upload, i'll delete those | 22:05 |
| ch | │ └─Pocket Reform Input 1.0 Keyboard Update: | 22:07 |
| ch | │ New version: 20250927 | 22:07 |
| ch | Target pocket-input-1.0 ID 1209:6d06 Serial# DE625492032E7A32 USB bus 3 address 8 Version 20250927 | 22:09 |
| ch | Target pocket-sysctl-1.0 ID 1209:6d07 Serial# DE63544193253234 USB bus 5 address 4 Version 20250927 | 22:09 |
| ch | minute: both have an update report now | 22:11 |
| - gustav2 (QUIT: Quit: Quit) (~gustav@c-78-82-55-162.bbcust.telenor.se) | 22:15 | |
| minute | ah let me check | 22:21 |
| minute | ah yes, cool, i see them now in fwupdmgr get-releases | 22:22 |
| ch | we could also try putting them into testing | 22:24 |
| minute | done that! | 22:29 |
| minute | i've made a todo for monday to implement the "on" state detection for the keyboard after resets | 22:30 |
| ch | is the display init after display sleep still known broken or is it just my machine? | 22:30 |
| minute | it's not 100% broken for me, just flickers like hell for 5 minutes | 22:31 |
| minute | do you mean that? | 22:31 |
| minute | (with disp v1) | 22:31 |
| ch | yeah it flickers a ton and also there's some cursor ghosting | 22:31 |
| minute | yeah. this needs to be fixed soon, it's in my "pain list" | 22:31 |
| ch | and i think it also kinda broke wifi | 22:32 |
| ch | like, it gets packets through, but superslow | 22:32 |
| ch | maybe the flicker is not just visual (: | 22:32 |
| ch | indeed the flicker gets better over time | 22:33 |
| minute | pain list, short form: charger modules blowing up, rk3588 hibernate, random sysctl reset on battery, brownout reset with 30% battery, random keyboard reset (maybe fixed), dysbalanced cells hard to balance, sometimes snow @ disp v1 init, flicker @ disp v1 wakeup, uboot/edk2 graphical, battery runtime can be better, display can get smudged by trackball, missing rubber feet | 22:33 |
| minute | ch: haha omg flicker EMI | 22:34 |
| ch | not unpossible ;) | 22:34 |
| minute | i'm working with a display+glass company to see if we can get a full, bonded cover glass for the display | 22:35 |
| minute | incl. the bezel area | 22:35 |
| minute | (black backprint instead in that area) | 22:35 |
| ch | that sounds very nice | 22:35 |
| minute | i hired someone for charger v2 electronics finishing (to have another pair of eyes) and also for edk2 w/ graphics | 22:36 |
| minute | hibernate i'll probably spend myself some time as soon as i'm out of the worst stuff @ next polishing | 22:36 |
| ch | i think there's also still the issue of not powering on after a power off with not enough delay | 22:37 |
| ch | at least i just ran into it :) | 22:37 |
| minute | ah that's sysctl crashing after poweroff | 22:37 |
| minute | or during poweroff | 22:37 |
| minute | which is very interesting and might be related to the random resets | 22:37 |
| ch | hmpf, thats hard to debug | 22:37 |
| minute | theory: SPI gets confused and can hang | 22:37 |
| minute | well, at least it's reproducible :D | 22:38 |
| minute | we might need to vendor the SPI stuff | 22:38 |
| minute | so we can remove all endless loops | 22:38 |
| ch | bah the access points also seem to hate the pocket in particular | 22:40 |
| minute | oh no | 22:40 |
| minute | which wifi card do you have btw? | 22:40 |
| ch | pocket can ping out to the internet | 22:40 |
| ch | other laptop cant ping pocket | 22:41 |
| ch | the asiarf | 22:41 |
| minute | i guess we should send you the upgrade with intel card at some point :D | 22:42 |
| ch | (: | 22:42 |
| ch | i ordered the upgrade, i guess it will happen some day soon :) | 22:42 |
| minute | oh nice :D | 22:49 |
| minute | i have some new secret version of rcore on the way | 22:49 |
| minute | (with new 8-layer pcb) | 22:49 |
| ch | ohh | 22:49 |
| minute | will come next week | 22:50 |
| minute | so then we can send out more stuff again | 22:50 |
| ch | better signal integrity and stuff? | 22:50 |
| minute | maybe, i wanted to test that in any case | 22:50 |
| minute | because i noticed on next that the SI is different for usb3 port a and b | 22:50 |
| minute | and i wanted to check if i can get more out of it | 22:51 |
| minute | ch: experiment https://source.mnt.re/reform/pocket-reform/-/merge_requests/56/diffs | 22:52 |
| minute | (this lacks error reporting especially) | 22:52 |
| ch | yeah i was looking into it for the fusb | 22:52 |
| minute | i.e. reporting of timeout + bailing out of the current top-level task | 22:53 |
| ch | not sure yet what to do on errors with the usb-pd state machine | 22:53 |
| minute | yeah, needs a state-by-state decision i guess | 22:53 |
| ch | maybe indeed just return; and hope for the best | 22:53 |
| minute | in some cases it should maybe reset the state | 22:54 |
| ch | i just looked into the spi side, and... the sdk has only blocking functions?!? | 22:54 |
| minute | yeah. | 22:54 |
| minute | they rely on the silicon doing the right thing :D | 22:54 |
| ch | not sure the silicon can, if the other side goes bad | 22:54 |
| minute | that's why i think we should vendor | 22:54 |
| minute | and make all those loops breakable... | 22:55 |
| minute | gonna flash my experiment, wish me luck... | 22:55 |
| ch | good luck | 22:55 |
| ch | at least the fusb stuff should work; the state machine might be confused briefly but worst case just replug the charger | 22:55 |
| ch | s/charger/wallbrick/ | 22:55 |
| minute | (actually need to rebuild, i still had 1.5.1 sdk locally argh) | 22:57 |
| ch | ok, spi in the sysctl is probably not that hard given the only thing we need is a write | 22:57 |
| minute | yes | 22:57 |
| Zaba | how can the other side go wrong to affect the spi peripheral? | 22:57 |
| ch | SCL stuck or anything else really | 22:58 |
| minute | yeah if the other side disappears and SCL is stuck in unknown state, but the code is waiting for a clock pulse | 22:59 |
| Zaba | that can happen with i2c, not with spi | 23:00 |
| ch | why not? | 23:00 |
| Zaba | because the clock in spi is not bidirectional, it's always driven by the host, if the peripheral doesn't keep up you just read garbage from it | 23:01 |
| ch | sure, but we're not the host | 23:01 |
| minute | the error case is the host disappearing in the middle of it driving the clock, for example | 23:01 |
| minute | or we say, we want to make 8 transfers on the peripheral side but the host makes only 4 and disappears, it depends on the fw implementation in the peripheral if it gives up after 4 bytes or waits | 23:03 |
| Zaba | ah sorry yeah I didn't realise you were talking about the peripheral side | 23:04 |
| Zaba | is this with an rp2040? | 23:05 |
| minute | Zaba: yes | 23:05 |
| minute | ok, now flashing | 23:05 |
| Zaba | anecdotally, the hard IP blocks in the rp2040 are really horrible, especially the spi/i2c ones, and you can do much better by just using PIO instead | 23:05 |
| Zaba | that's not the way it should be, but that's the way it is | 23:06 |
| minute | oh, you have some links about that? :0 | 23:06 |
| minute | i thought those were just ARM primecells | 23:07 |
| minute | PL022 | 23:07 |
| minute | ok, it survived flashing | 23:08 |
| minute | i'll do a poweroff and see if the hang is still there | 23:08 |
| ch | the comments say PL022 | 23:09 |
| minute | LPC11U24 has the same ip block for spi btw | 23:10 |
| minute | coincidentally | 23:10 |
| minute | ch: hang after poweroff is still there! so not i2c probably :D | 23:11 |
| ch | nice | 23:11 |
| ch | "nice" | 23:11 |
| minute | haha | 23:11 |
| ch | i'm trying my best to make the spi write honor timeouts | 23:11 |
| minute | i've just put a return at the top of handle_spi_commands, lets see if that gives any evidence | 23:13 |
| ch | smart | 23:13 |
| minute | no hang then, but also no poweroff, of course | 23:14 |
| minute | i can manually turn off the power and there is no hang then | 23:14 |
| Zaba | okay so the pico sdk api for SPI seems completely inane for peripheral use | 23:16 |
| minute | :D | 23:16 |
| minute | ch: i notice that my poweroff spi handling stuff was really backwards | 23:17 |
| Zaba | there is no possible way to have a function that 'sends' data back to the host because… like… the host controls the timing of the transfer? | 23:17 |
| ch | minute: mh? | 23:17 |
| minute | Zaba: yeah what the api means is you write stuff into the spi _buffer_ for sending to the host on next xfer | 23:19 |
| minute | ch: ah it's backwards because the way how it should be, that i just tried again, doesn't work | 23:20 |
| minute | anyway, i'll do some gaming now and will revisit on monday | 23:20 |
| ch | enjoy | 23:21 |
| minute | i think it is really spi api related | 23:21 |
| minute | because the som will already power off its clocks after the driver is done sending the command to power off | 23:21 |
| minute | we probably need to reset spi after receiving that command, or in general if timeouts are detected in the code that you're writing now :D | 23:22 |
| minute | i.e. i think the som powering off after sending spi stuff breaks rp2040 spi | 23:22 |
| ch | actually, when we get p1 we just return | 23:23 |
| minute | sorry, not the som, the soc | 23:23 |
| minute | ch: yes. because i already ran into that issue. but something goes wrong afterwards | 23:23 |
| minute | but the next time around i check if som is powered off and return early, because i also had that reasoning last time... and there's still a hang somewhere | 23:25 |
| josch | ACTION is surprised by rk3588 hibernate that high up the pain list | 23:25 |
| ch | it would suck if we do a spurious read of something | 23:25 |
| minute | anyway, need to turn off brain :D | 23:25 |
| minute | josch: yeah, i really want it for the next also | 23:25 |
| josch | i *am* holding my breath :) | 23:25 |
| ch | no luck | 23:28 |
| ch | for anything else i'll need a serial | 23:29 |
| Zaba | minute: it's not just any buffer, it's writing stuff directly into the pl022 fifo. oh yeah that's wacky. | 23:32 |
| minute | Zaba: yeah | 23:36 |
| minute | ch: fyi my rp2040 sysctl go so stuck that there's no more watchdog reset even, after i removed that return :D | 23:37 |
| ch | ugh | 23:37 |
| ch | 'how' | 23:37 |
| minute | the issue is not there on rp2350/next btw, which i just turned off "cleanly" | 23:37 |
| minute | and which uses a fork of the same fw | 23:37 |
| minute | maybe there's some irq stuff piling up... anyway, really gaming now :D | 23:42 |
| ch | even if you comment the return; the write should not happen because its guarded by if(is_som_powered) | 23:43 |
| ch | but yeah | 23:43 |
| josch | minute: have fun and thank you so much for all your work, really! | 23:43 |
| ch | really need to do something about programmable feature flags | 23:46 |
| ch | the git stash dance gets old quickly | 23:47 |
| Zaba | if there is a risk that the host stops reading after a certain number of bytes, the peripheral should probably flush the rx fifo before 'sending' data to the host (i.e., writing more data into the fifo) | 23:47 |
| Zaba | and then once the data is in the fifo, there is no need to wait for anything at all, the host can read it out in its own time | 23:48 |
| + robin_ (~robin@user/terpri) | 23:50 | |
| - robin (QUIT: Read error: Connection reset by peer) (~robin@user/terpri) | 23:51 | |
| Zaba | (the fifo is only 8 items deep, but if you need to send more data you can use the half-full interrupt to refill it, no need to block on anything) | 23:56 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!