- nocko (QUIT: Ping timeout: 252 seconds) (~nock@user/nocko) | 00:37 | |
+ nocko (~nock@user/nocko) | 00:38 | |
- mtm (QUIT: Ping timeout: 260 seconds) (~textual@c-71-228-84-213.hsd1.fl.comcast.net) | 02:02 | |
- jfred (QUIT: ) (sid534649@libera/sponsor/jfred) | 02:03 | |
+ mtm (~textual@c-71-228-84-213.hsd1.fl.comcast.net) | 02:05 | |
+ jfred (c9b58a1025@libera/sponsor/jfred) | 02:07 | |
jackhill | josch: thanks! Yeah, I guess I'm cunfused as to what to put in the firmware. This is what I have now: https://git.hcoop.net/jackhill/reform.git/blob/2b0fa817dccc49ea78f8cd12890c1abeeee44ad7:/reform2-keyboard-fw/matrix_3.h#l43 | 02:11 |
---|---|---|
- mjw (QUIT: Ping timeout: 252 seconds) (~mjw@gnu.wildebeest.org) | 02:49 | |
- nsc (QUIT: Ping timeout: 272 seconds) (~nicolas@150-96-142-46.pool.kielnet.net) | 03:42 | |
+ nsc (~nicolas@i5C74DCB8.versanet.de) | 03:43 | |
jackhill | this confusion (or my confusion) seems to be happening on the libinput side of things. An external keyboard sends the same keysim | 03:54 |
^alex | we helped someone with this recently, lemme see | 03:59 |
^alex | in your input config, try setting xkb option `lv3:ralt_alt` | 04:02 |
^alex | this tells xinput to not use a level 3 switch, but instead to send "right alt", aka altgr | 04:03 |
^alex | iirc | 04:03 |
jackhill | ^alex: thanks, but that doesn't seem to do it for me | 04:09 |
jackhill | or maybe what I'm doing in the config file is incorrect. https://paste.debian.net/1324689/ | 04:13 |
jackhill | indeed caps as super doesn't seem to take with external keyboards | 04:14 |
jackhill | ^ah! I think I found it. I had a config.d folder with some stuff in it. I don't think I created that, maybe it came with the system image. | 04:23 |
jackhill | yep, that was it! | 04:25 |
- colinsane (QUIT: Quit: bye) (~colinunin@97-113-150-69.tukw.qwest.net) | 04:40 | |
+ colinsane (~colinunin@97-113-150-69.tukw.qwest.net) | 04:44 | |
^alex | ah | 04:49 |
jackhill | I learned about more xkb options in the process, so my flailing about was still worthwile :) | 04:59 |
jackhill | thanks for your suggestion | 04:59 |
- bkeys (QUIT: Remote host closed the connection) (~Thunderbi@45.134.140.153) | 05:02 | |
^alex | we've done some mildly cursed things with xkb :) | 05:05 |
jackhill | hmmm, now I'd like to remove delete, but https://git.hcoop.net/jackhill/reform.git/commitdiff/d5cd443bcf41ed05fdd32c1c04b56dc2823b0db0 doesn't seem to do it | 05:26 |
- cobra (QUIT: Quit: ZNC 1.8.2 - https://znc.in) (~cobra@user/Cobra) | 05:40 | |
+ cobra (~cobra@user/Cobra) | 05:48 | |
+ mtm_ (~textual@c-71-228-84-213.hsd1.fl.comcast.net) | 10:29 | |
- mtm (QUIT: Ping timeout: 245 seconds) (~textual@c-71-228-84-213.hsd1.fl.comcast.net) | 10:29 | |
+ mjw (~mjw@gnu.wildebeest.org) | 12:22 | |
- Gooberpatrol66 (QUIT: Ping timeout: 248 seconds) (~Gooberpat@user/gooberpatrol66) | 12:28 | |
josch | minute: in May 2020 you added the iosevka font in commit 61824e8a724c15360f3bde839483adf08b18f5e6 -- but the iosevka font currently has 455 variants: https://github.com/be5invis/Iosevka/releases I'm unable to exactly identify the one you used. Do you remember? | 13:06 |
josch | aha, iosevka as i packaged it does not show up as a selectable font in xfce-terminal because it does not show up in "fc-list ':mono'" but only in "fc-list :fixed" | 13:15 |
sevan | is this the same issue that gnome terminal suffers which I suspect is actually due to libfreetype where the listing of fonts is restricted? | 13:19 |
sevan | (Italic variats of fonts no longer show up in the font list, I actually want the italic variant) | 13:20 |
josch | i just can't seem to find a release artifact which works out-of-the-box... :/ | 13:25 |
sevan | "fun!" :) | 13:29 |
sevan | My bodge to side step the issue is to set the font in relevant ~/.config files & then only have the variant of the font installed in ~/.fonts | 13:31 |
violet | yaeh i like terminals that let you specify variants | 13:33 |
violet | i use a bold font in my terminal | 13:33 |
sevan | Putty & Command Prompt impose this restriction I think, I hope it wasn't someone's idea to copy it (no evidence, just aware that I ran into the problem with those utilities) | 13:39 |
sevan | on Windows ^ | 13:40 |
josch | aha! | 13:40 |
josch | iosevka term version 3.0 from May 2020 does show up as a selectable font in xfce termina | 13:41 |
josch | but the current version 31 does not | 13:41 |
josch | "iosevka fixed" does but "iosevka term" does not | 13:41 |
violet | wacky | 13:41 |
josch | minute: should reform-tools switch out "iosevka term" for "iosevka fixed" as the font is also put into /etc/skel/.config/xfce4/terminal/terminalrc and the "term" variant will just be wrong there? | 13:42 |
josch | minute: we could also package both but the font is currently 463 MB large which will blow the size of the system image out of proportion i think | 13:46 |
josch | this is because the iosevka font has 57 variants each around 8 MB in size | 13:47 |
josch | minute: another option would be to throw out iosevka for an already packaged much smaller font, for example fonts-mplus is already in debian and only takes 40.3 MB of disk space instead of nearly half a GB | 13:52 |
josch | and it seems to look very similar: | 13:53 |
josch | https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=973995;filename=Screenshot+from+2023-03-09+01-56-49.png;msg=16 | 13:53 |
josch | https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=973995;filename=Screenshot+from+2023-03-09+01-54-42.png;msg=16 | 13:53 |
sevan | I first ran into it after upgrading Ubuntu & since it wasn't there on my up to date Debian install on Reform, I assumed it was an Ubuntu specific bug. Filed it on the launchpad and some months later it was changed as confirmed. Nothing progress since | 14:00 |
- mjw (QUIT: Remote host closed the connection) (~mjw@gnu.wildebeest.org) | 14:01 | |
+ mjw (~mjw@gnu.wildebeest.org) | 14:01 | |
sevan | s/the launchpad/their launchpad | 14:01 |
sevan | s/Nothing/No | 14:01 |
sevan | IRC needs an edit feature! | 14:02 |
- mtm_ (QUIT: Ping timeout: 265 seconds) (~textual@c-71-228-84-213.hsd1.fl.comcast.net) | 14:04 | |
+ mtm (~textual@c-71-228-84-213.hsd1.fl.comcast.net) | 14:06 | |
[tj] | josch: I had to manually fix a bunch of files to get lualatex to work once due to the sheer insanity of hte size of isoveka | 14:30 |
+ bkeys (~Thunderbi@45.134.140.153) | 14:57 | |
- mjw (QUIT: Killed (iridium.libera.chat (Nickname regained by services))) (~mjw@gnu.wildebeest.org) | 14:58 | |
* Guest6299 -> mjw | 14:58 | |
+ Guest6002 (~mjw@gnu.wildebeest.org) | 14:58 | |
minute | josch: what does iosevka fixed look like? maybe it's good? | 15:06 |
- mjw (QUIT: Ping timeout: 252 seconds) (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 15:13 | |
+ mjw (~mjw@2001:1c06:2488:1400:d37c:619d:fe7c:4eb9) | 15:26 | |
jackhill | I'd like to remove the delete key next to the left shift on keyboard v3, but https://git.hcoop.net/jackhill/reform.git/commitdiff/d5cd443bcf41ed05fdd32c1c04b56dc2823b0db0 doesn't seem to do it. What am I missing? | 15:36 |
minute | jackhill: you need to build as non-US variant | 15:46 |
minute | jackhill: the DEL is inserted in a hacky way into the matrix at startup if it's the US variant | 15:47 |
grimmware | minute: on the topic of keyboard modifications, on the pocket are there any complications around moving any of the keys in the matrix? I'm specifically thinking about whether hyper is a special case or not | 15:50 |
minute | grimmware: yes, you can shoot yourself in the foot by moving HYPER and not moving it in the HYPER matrix :D | 15:52 |
minute | grimmware: so when pressing it it becomes non-hyper | 15:52 |
jackhill | minute: ah, thanks! I'll give it a go. | 15:52 |
minute | grimmware: also, there's a hacky special case for showing the "menu hint" in off mode which relies on the physical default position of hyper. this should be fixed soon | 15:53 |
minute | hmmm no that wasn't it | 15:53 |
minute | ah | 15:53 |
minute | about the backlight. so the backlight control using hyper+trackball is hardcoded to use the bottom left key as a trigger for that | 15:53 |
grimmware | ah just the backlight for the keys | 15:54 |
grimmware | that's fine, that's not a common combo anyway | 15:55 |
grimmware | I'm quite keen to get hyper and super where I can get to them easily with my thumbs, I'm considering hacking in some tap-vs-hold support as well when I have the wherewithall for it. | 15:58 |
grimmware | I'm not going to do any mods though until I have the time and patience for fixing them if they fuck up and I don't think that day is today | 15:58 |
minute | ok i tried EDK2 on the RK3588 Reform and it ~just works~ | 16:06 |
minute | https://mastodon.social/@mntmn/112870152396247846 | 16:07 |
+ lexik (~lexik@93.185.97.218) | 16:15 | |
sigrid | nice! would it work without hdmi-to-dp adapter? | 16:22 |
jackhill | minute: thanks, I got it to my liking! | 16:35 |
minute | sigrid: no. that adapter is crucial for the success i think | 16:42 |
minute | sigrid: is there a generic aarch64 uefi image for 9front? | 16:42 |
minute | i can boot fedora rawhide installer from usb via edk2. it comes up in 1080p, trackball works | 16:43 |
gsora | via usb? this is nuts | 16:43 |
gsora | like, a standard live cd? | 16:43 |
minute | yep | 16:44 |
minute | just downloaded the iso, dded to usb | 16:44 |
minute | edk2 auto boots it | 16:44 |
minute | (or you can select it in boot manager) | 16:44 |
minute | also tried with netbsd | 16:45 |
gsora | i wonder if it's booting with acpi or device tree | 16:45 |
minute | you can select that | 16:45 |
minute | for all non-windows, devicetree is recommended | 16:45 |
gsora | speaking of, you should try windows 11 for arm :^) | 16:46 |
minute | yeah, i'm in the process ^^ | 16:46 |
[tj] | https://download.freebsd.org/snapshots/ISO-IMAGES/15.0/FreeBSD-15.0-CURRENT-arm64-aarch64-20240718-a4469a0d19b6-271237-mini-memstick.img.xz | 16:46 |
minute | ah yes, need to try freebsd of course | 16:47 |
sigrid | minute: nope | 16:47 |
[tj] | it would be cool to know how well it works | 16:47 |
minute | [tj]: i think it has no gpu accel yet so probably sluggish | 16:48 |
gsora | it's funny that we're getting excited about tech that has been in use for 15-20+ years lol | 16:48 |
[tj] | if it can find something storage would attach to I will be impressed | 16:48 |
[tj] | I think you need a clocks driver for anything to come up and a wrapper for the device tree node for usb | 16:49 |
[tj] | but I quite like to be wrong when I'm being pessimistic | 16:49 |
gsora | oooh i wonder if edk2 also contains secure boot etc | 16:54 |
minute | [tj]: freebsd boots until pcie enumeration, i think i need to correct the dtb for that. the dtb is currently for the firefly aio board | 16:55 |
[tj] | cool | 16:56 |
minute | [tj]: here are some photos https://mastodon.social/@mntmn/112870362957725480 | 16:59 |
minute | ahh it's actually using acpi | 16:59 |
minute | trying freebsd with dtb now | 17:02 |
minute | (but still not the fully correct one) | 17:03 |
minute | ah, that's worse :D | 17:03 |
josch | minute: about the fonts and iosevka it might not be a problem of how it looks like but a problem of size. Four years ago when you chose the font, it was 37M small.These days, independent of whether we are talking about Iosevka Term or Fixed, it's 10 times that and more than 400 MB large. Is that not too large for the system image? | 17:03 |
minute | josch: that's bizarre. i wonder if it's not possible to just generate only one variant | 17:04 |
josch | minute: upstream offers over 500 variants, each nearly half a gig in size | 17:05 |
josch | so this is already one out of 500 | 17:05 |
minute | IosevkaTerm-Regular.ttf is 8.9MB | 17:05 |
minute | from this zip file https://github.com/be5invis/Iosevka/releases/download/v31.0.0/PkgTTF-IosevkaTerm-31.0.0.zip | 17:06 |
minute | so something is off | 17:06 |
minute | ahh iosevka fixed is without ligatures | 17:07 |
minute | IosevkaFixed-Regular.ttf is 7.2MB | 17:07 |
josch | minute: but when i package a font for debian, i do not just package a single ttf | 17:07 |
minute | josch: why not? | 17:07 |
minute | ok, all the cuts in the fixed ttf package are 110MB together | 17:08 |
josch | well, by default you package the whole thing -- do you not think that i would immediately receive a bug report asking where all the other variants are in the package? | 17:08 |
minute | yes, that is true. | 17:08 |
minute | ah yeah, uncompressed it's 394 MB | 17:08 |
minute | that's a little bit annoying | 17:08 |
josch | exactly | 17:08 |
minute | ok then i need to select a new font :S | 17:09 |
josch | you don't *need* to | 17:09 |
josch | reform-tools can also be doing different things for the MNT images and the variant that will be in Debian | 17:09 |
josch | i mean, you can ship whatever you want at mnt.re even if it's just a single ttf | 17:10 |
minute | yeah but maybe it's a good idea anyway | 17:10 |
minute | haha mplus originally also has 800 different weights! | 17:10 |
minute | it's a thing now | 17:10 |
grimmware | Trying to make something good in a world that has gone tech maximalist is a fucking nightmare | 17:10 |
sigrid | you can cut some bits out of a font too, if that's something you wanna do | 17:11 |
sigrid | just for the image to be smaller | 17:12 |
josch | sigrid: you can also build the whole thing from source but that downloads half the internet as npm packages... | 17:12 |
minute | i'm trying ibm plex and then i'm seeing on the github > This package uses IBM Telemetry to collect metrics data. By installing this package as a dependency you are agreeing to telemetry collection | 17:12 |
minute | lol | 17:12 |
minute | but how | 17:12 |
sigrid | pyftsubset is nice to get rid of most of font's garbage that isn't used | 17:12 |
minute | yeah iosevka has the downside of being implemented in javascript/nodejs | 17:13 |
gsora | telemetry *on a font*? | 17:13 |
josch | sigrid: but if we go that route, then i'd now maintain an iosevka-minimal and an iosevka-full package. It's possible, but it's not something i've seen before for a font. | 17:13 |
josch | minute: i just read your progress regarding edk2 on rk3588 -- that's really cool! | 17:14 |
sigrid | maybe package a 2x vga.otb then :) | 17:14 |
sigrid | that would look sick | 17:14 |
josch | oh i wouldn't mind throwing iosevka out of the window but minute will have the last word on that :) | 17:15 |
sigrid | 79K Jul 18 2023 /home/ftrvx/.local/share/fonts/u_vga16.otb | 17:16 |
sigrid | has pretty good unicode coverage for a bitmap font | 17:16 |
grimmware | heh, use gnu unifont - excellent unicode coverage, looks like hot garbage | 17:16 |
jackhill | Guix has plex, so it must be possible to turn off the analytics. I haven't looked at the package definition | 17:17 |
minute | maybe it's just counting the github downloads | 17:19 |
minute | plex is already in debianb | 17:19 |
minute | debian | 17:19 |
josch | gosh but iosevka *is* a pretty font. Either that or i really got too used to it. I have trouble finding another one i like... | 17:23 |
gsora | i moved to spline sans mono after yeeeears of iosevka | 17:24 |
minute | i think ibm plex mono:weight=regular could be a good alternative | 17:25 |
^alex | we use Berkeley Mono but that's a licensed product | 17:25 |
minute | i used pragmata back in the day but it's also commercial | 17:25 |
^alex | we kind of miss x11-misc-fixed | 17:25 |
minute | fira code is also OK but plex has a bit nicer computery character | 17:27 |
^alex | also thinking of ways to save power on the RP2040 cores and, i think the stock RPi config keeps the second core held in reset, so we are considering asking the second cores to jump to a `1: wfi; br 1b` loop | 17:27 |
^alex | which ought to let them sleep | 17:27 |
minute | ^alex: ohh | 17:27 |
^alex | havent confirmed this exactly, we were reading code as we were falling asleep | 17:28 |
josch | i guess everything looks weird to me now but ibm plex mono regular seems to have good glyph coverage: https://mister-muffin.de/p/HAaE.png | 17:32 |
minute | josch: yep | 17:32 |
minute | it's weird at first because it runs a bit wider than iosevka | 17:32 |
minute | but the glyphs are pretty well designed | 17:33 |
^alex | hm so, the core1 is told to sleep by the boot rom | 17:37 |
grimmware | nice, first keyboard firmware modifications have been successful | 17:37 |
minute | grimmware: neat | 17:37 |
minute | ^alex: btw are you working on keyboard or sysctl rp2040? sysctl, right? i added some extra msleep in the state machine recently, did you see that? i also have a uamp-scale power measurment toolkit here but didn't set it up yet | 17:38 |
minute | from nordic iirc | 17:38 |
grimmware | I especially enjoyed yoloing a `sleep 10; ./flash.sh` so I could hit hyper+ent,x without having to go upstairs and get my keyboard | 17:38 |
minute | grimmware: haha i do the same | 17:39 |
grimmware | what's the best way to get the keycaps off | 17:39 |
grimmware | ? | 17:40 |
^alex | minute, yeah, we pulled the latest branches of both keyboard and syscon | 17:40 |
josch | grimmware: if you use reform2-keyboard-fw/flash.sh you should get something similar to your sleep with more magic | 17:40 |
minute | grimmware: pull with long fingernails or use tweezers to lever them off | 17:40 |
^alex | this is how we bricked the keyboard, it doesn't like sleep_ms(200) ;) | 17:41 |
^alex | that made it go haywire on the USB | 17:41 |
minute | ^alex: ah because of usb constraints probably | 17:41 |
minute | yeah | 17:41 |
^alex | yeah | 17:41 |
^alex | but also here's the other thing | 17:41 |
^alex | that sleep is a busywait | 17:41 |
minute | really? i chased down the code and it uses the timer normally | 17:42 |
minute | when it's longer than the minimum time | 17:42 |
^alex | huh, we couldn't find that implementation? | 17:42 |
^alex | what we saw depended on `sync_internal_yield_until_before`, which is not defined | 17:43 |
^alex | and uses the RTC | 17:43 |
^alex | not an interval timer | 17:43 |
^alex | s/uses/is designed to use/ | 17:43 |
minute | https://github.com/raspberrypi/pico-sdk/blob/6a7db34ff63345a7badec79ebea3aaef1712f374/src/common/pico_time/time.c#L412 | 17:43 |
minute | https://github.com/raspberrypi/pico-sdk/blob/6a7db34ff63345a7badec79ebea3aaef1712f374/src/common/pico_time/time.c#L382 | 17:44 |
grimmware | minute: next time somebody asks, tell them to do it from the top or the bottom but not the side, came quite close to snapping one of the little mounting posts | 17:44 |
minute | grimmware: oh ok! | 17:44 |
grimmware | my arrow cluster is now hjkl style and my left space key is now backspace :) | 17:45 |
grimmware | has gone where the up arrow was | 17:45 |
grimmware | sorry, / has gone where the up arrow was | 17:45 |
josch | grimmware: i usually take either a thin cable or thread and make two loops out of it. One loop goes over the top half of the keycap and the other loop hooks the bottom. And then i can pull the keycap up vertically without fearing to accidentally snap the stems off. | 17:46 |
minute | ah! | 17:46 |
^alex | minute, oh hm ok. batting 0/10 this morning | 17:46 |
minute | ^alex: so your battery was at 100% and discharges to 0% overnight? | 17:48 |
grimmware | oh wait what that has apparently done some very weird shit to the mouse buttons... | 17:49 |
minute | i charged mine in the morning yesterday and it's now at 41% | 17:49 |
minute | grimmware: maybe you're just now on the latest fw for the first time after i toggled the mouse buttons around | 17:49 |
^alex | it was at 100% last night and went down _by_ 0.1 v overnight, which the meter registered as going down to 80% | 17:50 |
minute | grimmware: they're now: middle left (O) scroll right | 17:50 |
minute | ^alex: ok, that sounds normal | 17:50 |
grimmware | minute: hahah yeah, that'll be it! | 17:50 |
^alex | yeah we're just wondering about ways to get it even further down | 17:51 |
grimmware | okay cool I'll stick with this, should be better for right-hand only scrolling | 17:51 |
^alex | like putting the keyboard to sleep when the system is off, and waking it only when the bottom row or the first column changes state | 17:51 |
minute | grimmware: yep exactly | 17:52 |
- colinsane (QUIT: Quit: bye) (~colinunin@97-113-150-69.tukw.qwest.net) | 18:02 | |
* mjw -> Guest2979 | 18:18 | |
- Guest2979 (QUIT: Killed (osmium.libera.chat (Nickname regained by services))) (~mjw@2001:1c06:2488:1400:d37c:619d:fe7c:4eb9) | 18:18 | |
* Guest6002 -> mjw | 18:18 | |
+ Guest2979 (~mjw@2001:1c06:2488:1400:d37c:619d:fe7c:4eb9) | 18:19 | |
+ colinsane (~colinunin@97-113-150-69.tukw.qwest.net) | 18:23 | |
+ murphnj (~murph@user/murphnj) | 18:33 | |
- murph_nj (QUIT: Ping timeout: 265 seconds) (~murph@ool-457bb02e.dyn.optonline.net) | 18:34 | |
- colinsane (QUIT: Quit: bye) (~colinunin@97-113-150-69.tukw.qwest.net) | 18:35 | |
+ colinsane (~colinunin@97-113-150-69.tukw.qwest.net) | 18:39 | |
grimmware | Is there a more convenience way of interacting directly with the lpc than ripping the appropriate bits from reform2_lpc.c? | 18:43 |
grimmware | I'd like to see the raw responses from the commands so I can try to determine why charge_now is always equal to charge_full | 18:45 |
grimmware | heh, never mind I've just figured out that I can modify the module and insert some more printks :P | 19:19 |
grimmware | Okay, I've found the issue. https://source.mnt.re/reform/pocket-reform/-/blob/main/pocket-reform-sysctl-fw/sysctl.c?ref_type=heads#L1071 sets the current charge to the max charge but even if it were set to `report_capacity_accu_ampsecs` it would *also* be pegged to the max capacity https://source.mnt.re/reform/pocket-reform/-/blob/main/pocket-reform-sysctl-fw/sysctl.c?ref_type=heads#L79 | 20:00 |
grimmware | So like, I think if we get that fixed it'll solve the waybar 100% problem without having to fork waybar | 20:04 |
josch | well, we would definitely not fork waybar in any case :) | 20:06 |
josch | but if this works, then this just fixes waybar on the pocket -- it's broken on the big reform as well | 20:06 |
grimmware | has anyone checked if the charge_now works correctly on the big reform? | 20:15 |
minute | grimmware: thanks for finding that bug! the second line you linked should be fine though. that's just the default state | 20:17 |
grimmware | yeah but it never gets updated! | 20:17 |
minute | grimmware: well yeah that's fine too | 20:18 |
minute | grimmware: this is a leftover from reform code. the current percentage is no longer calculated in the sysctl at all. it comes from the gauge chip now | 20:19 |
minute | probably should be: | 20:21 |
minute | uint16_t cap_accu = (uint16_t) report_capacity_max_ampsecs / (((float) report_capacity_percentage) / 100.0) / 3.6; | 20:21 |
grimmware | ++ | 20:22 |
minute | first / should be a * | 20:24 |
grimmware | I *may* feel brave enough to test that out tomorrow | 20:25 |
minute | i will test it now on my pocket... | 20:25 |
grimmware | heh, nice, I'm not feeling super brave about that stuff cos I'm couch surfing for a while | 20:26 |
grimmware | I'd rather not brick my system controller without at least a desk I can sit at to fix it all | 20:26 |
minute | grimmware: good call! | 20:28 |
minute | upgrading waybar | 20:35 |
minute | it does show the right percentage for me | 20:35 |
minute | yep, it works... upower -i ... shows the right "energy" now | 20:36 |
minute | need to double check the actual design capacity of these cells... | 20:37 |
minute | to get the real capacity one would need to calculate an integral under the discharge curve | 20:39 |
^alex | little a calculus, as a treat | 20:44 |
minute | hehe | 20:52 |
^alex | seems like one of those moments wherein you've accidentally given yourself a "tech company interview question"-type problem :) | 20:53 |
minute | haha i chose to use the "industry standard" method of just multiplying with 3.7 | 20:55 |
^alex | lol | 20:55 |
^alex | anyway we'll test this syscon branch out later tonight once we're done with $DAYJOB | 20:55 |
minute | nice | 20:55 |
^alex | the right-angle adapter came in and so we can unbrick the syscon from our macbook without unscrewing the entire motherboard and praying to Coyote that we don't short anything | 20:57 |
minute | argh | 21:02 |
minute | energy is calculated by something in linux or upower, the driver reports charge, in "µAh" | 21:02 |
minute | the driver wants a value that is multiplied by 1000 | 21:02 |
minute | so it wants mAh | 21:02 |
minute | lol. | 21:02 |
minute | so this can be simplified again | 21:02 |
^alex | unit conversion woes | 21:02 |
minute | mega | 21:04 |
minute | comment https://github.com/torvalds/linux/blob/master/include/linux/power_supply.h#L22 | 21:05 |
^alex | one miliwoe per megasecond | 21:05 |
minute | lol | 21:08 |
minute | ha, u > sysrq-trigger seems to work against fs corruption before flashing | 21:10 |
minute | grimmware: working capacity fix pushed to that branch | 21:14 |
^alex | still thinking about ways to upgrade the syscon without it yanking the power rails out from underneath the device | 21:20 |
^alex | it looks like `picotool reboot` doesn't do a hardware reset, it just loads sp and pc and throws the Halt/Run switch back to Run | 21:22 |
minute | ^alex: there is already some hardware in place for that, but needs some code fixup | 21:27 |
minute | ^alex: power rails are going through a latch chip | 21:27 |
minute | ^alex: that's interesting @ hw reset | 21:27 |
minute | enable signals are changed when gpio_put(PIN_PWREN_LATCH, 1); | 21:28 |
minute | the culprit is // latch the PWR and display pins | 21:29 |
minute | in main() | 21:29 |
minute | so at reboot, it will turn off | 21:29 |
minute | it would probably be best to not touch the latch initially | 21:30 |
grimmware | minute: sorry which branch? | 21:30 |
minute | grimmware: display-panel2 | 21:30 |
+ Gooberpatrol66 (~Gooberpat@user/gooberpatrol66) | 21:30 | |
grimmware | noice | 21:31 |
minute | ^alex: but the next question is, how does sysctl realize that it is still supposed to be in the "on" state after reset | 21:31 |
minute | ^alex: i guess either the keyboard or the system via spi could remind it that it is on. for example, if spi commands are coming in, it definitely must be on. | 21:33 |
^alex | minute, we were thinking about a magic word at some location in memory that doesn't get cleared on reboot, and if it sees that word, then it knows the power is on | 21:52 |
^alex | but maybe making the syscon's first cry be "hey, is the system on" would be more reliable | 21:53 |
minute | ah, interesting idea | 22:03 |
grimmware | "u ok hun?" | 22:04 |
^alex | minute, we stole the "magic word to indicate warm boot" from mainframes | 22:16 |
^alex | our bedtime reading material is bitsavers.org docs :X | 22:17 |
grimmware | Does anyone have a suggestion for a mastodon client that works well on the imx8mp? | 22:17 |
minute | ^alex: nice :3 | 22:17 |
minute | grimmware: tut | 22:17 |
minute | grimmware: https://github.com/RasmusLindroth/tut | 22:18 |
minute | note to self, pff and whomever is interested about pocket keyboard backlight timeout: https://source.mnt.re/reform/pocket-reform/-/merge_requests/1#note_9766 | 22:19 |
Zaba | it would be better to use some register that has a known reset value than a memory location that has a *random* value on a power-on reset | 22:19 |
minute | hehe | 22:19 |
Zaba | a 1 in 2^32 chance your system randomly refuses to boot is hypothetical but *also* it's architecturally janky | 22:21 |
^alex | Zaba, ah but POR is identifiable from the reset-cause register, so the thing we'd have to check is "not POR and word", plus using a 64-bit word, or perhaps a checksum | 22:24 |
Zaba | but the reset cause register won't be cleared if a reset is never triggered | 22:25 |
^alex | and even in the 1/2^32 case, you can resynchronize it by powering it off | 22:25 |
^alex | and get back into a defined state | 22:25 |
Zaba | perhaps it *would* be a good idea to trigger a reset | 22:26 |
^alex | we'll have to do some experimentation with what the rst-cause register appears like on a coldstart vs `picotool reboot` | 22:26 |
^alex | but the consequences of failure here aren't that dire | 22:26 |
^alex | 'cause you can get everyone back on the same page pretty easily | 22:28 |
grimmware | minute: nice thanks, I'll try that for a few days and see how I get on with it | 22:29 |
Zaba | if you could reliably use the reset cause register to detect power-on resets, that would be a good indicator that the rest of the system is also, well, powering on | 22:32 |
^alex | sure, but we would still want to validate that assumption before we go mucking with the power rails | 22:35 |
josch | minute: does the reform2 lpc require a similar fix as in https://source.mnt.re/reform/pocket-reform/-/merge_requests/2/diffs?commit_id=05e6bb3114d2c5fef793bc9951e9555ee5ec02c5#diff-content-c2b06a626cfc44e0fa9c2b4611ccfbf0aa3eedc6 for the pocket reform to fix its capacity reporting with the latest waybar changes? | 22:35 |
^alex | the syscon test points on the main board are so tiny and hidden under the cpu module :( | 22:45 |
^alex | our picoprobe is of no use here | 22:45 |
minute | josch: afaik not | 23:03 |
minute | ^alex: sorry for that, probably you will need to solder some magnet wire | 23:03 |
josch | minute: then i wonder how i was able to find the waybar commit which, if reverted, fixes things on the pocket reform even though i have a big reform :D | 23:04 |
^alex | minute, we saw something that used the 1th core on the pico as a probe to debug the 0th core | 23:07 |
^alex | that one briefly intrigued us | 23:07 |
minute | :D | 23:15 |
minute | josch: hmm so the problem is present on reform as well? i didn't notice yet, so i shall upgrade my waybar | 23:15 |
grimmware | 0.10.4 should be problematic | 23:17 |
josch | yes, exactly | 23:17 |
minute | hmm, the reform2 lpc might exhibit a different, related problem | 23:17 |
minute | right now i get: | 23:18 |
minute | energy: 23.8722 Wh | 23:18 |
minute | energy-full: 46.1052 Wh | 23:18 |
minute | that sounds like the new waybar might show 50% now | 23:18 |
minute | but it's actually 36% | 23:18 |
josch | yes, i had old and new waybar running at the same time and it showed different percentage values | 23:21 |
minute | ok | 23:21 |
+ jacobk (~quassel@2601:380:837f:3520:b5be:3d0:bfde:a44a) | 23:21 | |
minute | josch: then we need a similar fix there | 23:24 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!