| minute | new pocket sleeve and some new spare parts https://mastodon.social/@mntmn/115448604719840451 | 00:01 |
|---|---|---|
| josch | i think the big news here is the MNT Pocket Reform Headset/Switch Board 2.0 | 00:05 |
| josch | this was part of the upgrade bundle, right? | 00:06 |
| + paperManu (~paperManu@198.58.209.52) | 00:07 | |
| - LainIwakura (QUIT: Quit: Client closed) (~LainIwaku@user/LainIwakura) | 00:16 | |
| - paperManu (QUIT: Ping timeout: 264 seconds) (~paperManu@198.58.209.52) | 00:24 | |
| + pomel0 (~pomel0@user/pomel0) | 00:26 | |
| + paperManu (~paperManu@198.58.209.52) | 00:27 | |
| - leony (QUIT: Quit: leony) (~leony@2a02:8109:f084:a900::e761) | 00:39 | |
| minute | josch: it's not that big, it's just a spare part. except if you happen to have mrcorexxr02, then you can get the wifi expansion cheaper now | 00:43 |
| minute | before, the cheapest option if you had mrcorexxr02 was 100 eur carrier upgrade incl this expansion | 00:44 |
| josch | in the fotos you showed on fedi one can see a purple rev4 rcore board? | 00:44 |
| minute | yeah ;3 | 00:44 |
| minute | that's the newest batch and also what will be shipped to crowd supply | 00:44 |
| josch | minute: could i also send you a friendly ping about my messages from earlier today at around 7:30 berlin time? | 00:45 |
| minute | sure, will check | 00:45 |
| josch | well... not today obviously XD | 00:45 |
| minute | josch: already did :D | 00:48 |
| - paperManu (QUIT: Ping timeout: 246 seconds) (~paperManu@198.58.209.52) | 00:52 | |
| josch | minute: perfect, thank you! | 00:54 |
| + paperManu (~paperManu@node-1w7jra78xlwv3hmhumsr2vo99.ipv6.telus.net) | 00:54 | |
| josch | minute: any idea on how to debug a non-moving mouse cursor with pocket reform keyboard? sensor is visually absolutely clean | 01:00 |
| minute | josch: hmmm seems rare, did you already try keyboard reset (in oled menu)? | 01:01 |
| minute | otherwise i'd say maybe the cable is a bit loose | 01:01 |
| josch | wat | 01:02 |
| josch | reset fixed it | 01:02 |
| josch | o0 | 01:02 |
| minute | ok, so software issue in the keyboard | 01:02 |
| minute | which fw are you on btw? | 01:02 |
| josch | 20251001 | 01:02 |
| minute | seems relatively recent :D | 01:03 |
| minute | not exactly bleeding edge though! :D | 01:03 |
| josch | oh i missed the new release then | 01:03 |
| josch | thank you! | 01:03 |
| elb | huh I just popped dmy rcore off the carrier board and saw the HDMI flat flex cable header under there | 01:04 |
| elb | is that a different HDMI port from the one on the other side of the motherboard, or same? | 01:04 |
| minute | josch: sorry, there was no real release after 20251001 but several new builds ^^ | 01:04 |
| josch | ah that you mean :) | 01:04 |
| minute | elb: different, you found the "free additional HDMI" easter egg | 01:04 |
| elb | nice | 01:04 |
| elb | I'd honestly quite appreciate a full size HDMI port, maybe on the headphone jack side | 01:05 |
| elb | it'd save me a dongle that I use every single day | 01:05 |
| minute | yeah... | 01:05 |
| minute | if i put an oculink, fullsize hdmi and usb-a there, no idea where i would put the intel wifi though ;/ | 01:06 |
| elb | heh yeah | 01:06 |
| elb | it's definitely a tradeoff | 01:06 |
| elb | and I understand (for that reason) why the other size is micro HDMI | 01:06 |
| minute | it's sad that HDMI alt mode never took off | 01:07 |
| minute | now we only get DP alt mode and TVs don't really speak DP | 01:07 |
| minute | otherwise one could've wrapped hdmi nicely in usb-c | 01:07 |
| elb | isn't HDMI except for HDCP a strict subset of DP, though? | 01:08 |
| minute | btw i'm only half joking about oculink. i ordered the minisforum deg-1 today, and some oculink breakouts for m.2, cables, sfx power supply, the goods | 01:08 |
| minute | elb: no, you're thinking of DVI maybe? | 01:08 |
| minute | elb: there's DP++ which means a DP port that can alternatively output HDMI if asked nicely | 01:09 |
| elb | oh yeah maybe | 01:09 |
| minute | (but not input) | 01:09 |
| minute | DVI-D and HDMI are somewhat compatible, i.e. DVI-D doesn't have audio and a few other things | 01:09 |
| minute | ACTION has flashbacks to DVI-I | 01:10 |
| elb | yeah I knew I remembered that some protocol and HDMI were signal-compatible but had only overlapping modes, maybe it was some revision of DVI | 01:11 |
| elb | like you could do one direction with a passive cable, and the other required a converter chip | 01:11 |
| elb | oh that headset/switch 2.0 board for only 19 eur is a deal | 01:12 |
| minute | yeah, i guess my colleague underpriced that one a bit lol | 01:13 |
| elb | uh does it come with the cable | 01:13 |
| minute | normally not yet. but i realize that most people who have rcore R02 will want the cable | 01:14 |
| elb | yeah it's maybe too late to do it right now, but I think you could add another 5-10 eur onto that and nobody (reasonable) could complain | 01:14 |
| minute | i think we'll do that tomorrow, i already wrote to my colleague about this, and to include the cable. and i also made a compatibility table earlier today that didn't make the cut | 01:15 |
| minute | (yet) | 01:16 |
| elb | so I know that m.2 is pitched as a port for wi-fi, but ... it's just a 40 mm PCIe, right? | 01:16 |
| minute | well it's key E | 01:16 |
| minute | 3220 i think? if memory serves | 01:16 |
| elb | ohhhhhh the really little guy | 01:17 |
| elb | hard to see in those photos | 01:17 |
| minute | sorry, 2230 | 01:17 |
| minute | even little-er | 01:17 |
| bremner | isn't 3220 a robert johnson song? | 01:17 |
| minute | and there is pcie and usb 2.0 on it | 01:17 |
| minute | bremner: i don't know :D | 01:18 |
| bremner | https://en.wikipedia.org/wiki/32-20_Blues | 01:18 |
| bremner | uh, glad I could contribute :P | 01:18 |
| elb | I normally love parts that have true parametric sizes | 01:18 |
| elb | but like m.2 can chill out a little | 01:18 |
| minute | haha yes m.2 has a lot of form factors and keys | 01:19 |
| elb | way back in the day, the first m.2 I ever used was in an APU or something | 01:19 |
| elb | I remember being utterly baffled as to whether the SSD I ultimately bought would even go in the hole, much less work when it got there | 01:19 |
| elb | (it did) | 01:19 |
| elb | and there were a lot fewer options in 2017 or whenever that was | 01:20 |
| minute | oh right. | 01:20 |
| - mjw (QUIT: Ping timeout: 256 seconds) (~mjw@gnu.wildebeest.org) | 01:31 | |
| - paperManu (QUIT: Ping timeout: 255 seconds) (~paperManu@node-1w7jra78xlwv3hmhumsr2vo99.ipv6.telus.net) | 01:31 | |
| minute | > Welcome to the OpenBSD/arm64 7.8 installation program. | 02:06 |
| minute | out of curiosity i booted openbsd arm64 img on classic rk3588 reform | 02:07 |
| minute | pcie and usb work, looks like everything is recognized. but of course there are no graphics drivers | 02:12 |
| + paperManu (~paperManu@107.159.15.124) | 02:40 | |
| - paperManu (QUIT: Ping timeout: 255 seconds) (~paperManu@107.159.15.124) | 02:47 | |
| elb | nice, though | 02:48 |
| elb | that means the reform desktop kind of form factor could be a great contender in the set top routing field | 02:49 |
| elb | now that the APU2 is gone there's a hole | 02:49 |
| ^alex | our home network nat router and captive dns cache is a pair of apu2s, pourin' one out | 02:57 |
| ^alex | and yes, they do run openbsd :} | 02:57 |
| - kop316 (QUIT: Remote host closed the connection) (m-6f6zq6@static.138.159.90.157.clients.your-server.de) | 03:06 | |
| + kop316 (m-6f6zq6@static.138.159.90.157.clients.your-server.de) | 03:08 | |
| - kop316 (QUIT: Remote host closed the connection) (m-6f6zq6@static.138.159.90.157.clients.your-server.de) | 03:08 | |
| + kop316 (m-6f6zq6@static.138.159.90.157.clients.your-server.de) | 03:08 | |
| sigrid | [h264 @ 0xaaaac3ea0790] Using V4L2 media driver hantro-vpu (6.17.5) for S264 | 04:34 |
| sigrid | looks like i got ffmpeg8 work with this thing | 04:34 |
| sigrid | on rk3588 | 04:35 |
| sigrid | [hevc @ 0xffff95a8bc40] Using V4L2 media driver rkvdec (6.17.5) for S265 | 04:46 |
| sigrid | guess that's the other video core | 04:46 |
| wytch | minute: Thank you so much with your help with my display woes. I am now happily typing this on my pocket with no external display. I'll email plom to close my ticket, but the new motherboard appears to have done the trick! | 07:13 |
| wytch | it also appears that according to cloudflare, the combination of the new wifi antenna and the back cover have greatly increased my network speeds | 07:18 |
| + chomwitt (~chomwitt@2a02:85f:9a5f:900:1ac0:4dff:fedb:a3f1) | 08:20 | |
| josch | \o/ | 08:40 |
| josch | sigrid: how did you do it? | 08:40 |
| josch | i *really* enjoyed hardware video decoding on imx8mq. It's so neat to compile your kernel on all eight cores and watch 1080p@60 video without frame drops at the same time. :D | 08:41 |
| - chomwitt (QUIT: Ping timeout: 256 seconds) (~chomwitt@2a02:85f:9a5f:900:1ac0:4dff:fedb:a3f1) | 09:15 | |
| + chomwitt (~chomwitt@2a02:85f:9a5f:900:1ac0:4dff:fedb:a3f1) | 10:02 | |
| minute | sigrid: oh nice | 10:36 |
| minute | wytch: glad to hear it! | 10:37 |
| + mjw (~mjw@gnu.wildebeest.org) | 11:29 | |
| + paperManu (~paperManu@107.159.15.124) | 11:53 | |
| sigrid | josch: patched the kernel with https://lore.kernel.org/linux-media/20251023214247.459931-1-detlev.casanova@collabora.com/T/#t (although the previous version of it) and reapplied v4l2request patches on ffmpeg 8 | 12:06 |
| sigrid | had to fix things here and there for it to build, but it wasn't that much work. tested the result with ffplay ... -hwaccel v4l2request -vf hwdownload,format=nv12 | 12:07 |
| sigrid | without the latter it complains about invalid dmabuf layer format being nv12, which I have no idea what to do about | 12:08 |
| sigrid | all the patches are on the last two commits here if anybody wants it: https://git.sr.ht/~ft/aports/ | 12:09 |
| + gustav25 (~gustav@c-92-32-81-177.bbcust.telenor.se) | 13:02 | |
| - RandyK (QUIT: Ping timeout: 272 seconds) (~RandyK@user/randyk) | 13:03 | |
| + RandyK (~RandyK@user/randyk) | 13:03 | |
| - erle (QUIT: Quit: K-lined) (~erle@user/erle) | 13:24 | |
| - chomwitt (QUIT: Ping timeout: 260 seconds) (~chomwitt@2a02:85f:9a5f:900:1ac0:4dff:fedb:a3f1) | 13:31 | |
| - paperManu (QUIT: Ping timeout: 260 seconds) (~paperManu@107.159.15.124) | 13:33 | |
| josch | sigrid: thank you! | 13:38 |
| - mjw (QUIT: Ping timeout: 256 seconds) (~mjw@gnu.wildebeest.org) | 13:39 | |
| josch | minute: should the MNT repository ship ffmpeg with the v4l2request patch-set again? We disabled that in the past because the patches did not allow for a gui overlay in mpv, because of irregular stutters in the h264 output (on imx8mq back then) and because h265 did not work at all | 13:39 |
| * Guest1670 -> mjw | 13:42 | |
| + paperManu (~paperManu@modemcable141.205-200-24.mc.videotron.ca) | 13:51 | |
| + andreas-e (~Andreas@2a02-8434-b6a3-e901-facc-8e87-8e54-890e.rev.sfr.net) | 14:44 | |
| - paperManu (QUIT: Ping timeout: 260 seconds) (~paperManu@modemcable141.205-200-24.mc.videotron.ca) | 14:48 | |
| elb | ugh my digikey order with a new console cable in it is delayed and has been ... somewhere ... for a week now | 14:52 |
| elb | I itch to move from the keyboard to sysctl, but I have trepidation about doing that without a console cable | 14:52 |
| minute | elb: console cable for SoC output? because you can get serial from sysctl just with usb-c to another computer if needed | 15:27 |
| minute | josch: it's fine if we ship the mpv config where hwdec is disabled by default | 15:29 |
| minute | not sure if that's still the case or if it's "auto" | 15:29 |
| elb | yeah I want SoM and sysctl | 15:29 |
| minute | elb: alright | 15:30 |
| elb | like I anticipate getting into "this doesns't boot, why not?" territory | 15:30 |
| elb | so far I have managed to not run into any hiccoughs whatsoever with the keyboard (except for failing to do the dance of putting it into flashing mode and running the uploader in exactly the right timings, once or twice) | 15:31 |
| minute | right | 15:32 |
| elb | I've been thinking about the remote protocol some, and looking at it ... we had discussed the other day a dual-stack kind of idea | 15:33 |
| elb | but I dislike the complexity of having to maintain two protocols | 15:33 |
| elb | so now I've been thinking, what about a sysctl console kind of program, that you run on a host computer and it speaks the framed, now-binary remote protocol, with a few commands and queries and a decoder that pretty-prints the returned data? | 15:34 |
| elb | I see pluses and minuses to that, versus just firing up a terminal | 15:34 |
| + paperManu (~paperManu@64.187.189.252) | 15:34 | |
| amk | sigrid: does the rk3588 kernel work with the pocket? been wanting to get alpine running on mine | 15:34 |
| [tj] | elb: run the sysctl firmware on a pi pico for development | 15:36 |
| sigrid | amk: the dts files for the pocket are there too, I think it should work. I can't test it though since I have no pocket | 15:37 |
| elb | [tj]: an interesting suggestion | 15:37 |
| amk | ah cool, ill see about giving it a try | 15:37 |
| - paperManu (QUIT: Ping timeout: 240 seconds) (~paperManu@64.187.189.252) | 15:42 | |
| + paperManu (~paperManu@142.169.16.151) | 15:44 | |
| minute | elb: yeah, single is better than dual for complexity, sure. regarding the framing, i think we agreed the command side was pretty ok, and that we could focus on restructuring the responses. i think it's fine to change the responses totally in the firmware, so only have the "new stack" there, as keeping backwards compat only in the driver is easier to manage there | 15:47 |
| minute | elb: because we want as little as possible complexity in the FW which is harder to change and failures are less forgiving, than on the linux driver side which is easier and less risky to update, and more resources are available | 15:48 |
| elb | oh I'm talking about the sysctl-to-keyboard remote protocol at this moment | 15:48 |
| elb | so it's firmware-to-firmware | 15:49 |
| minute | elb: oh you're right. it's the same commandset though | 15:49 |
| elb | ok, I haven't gotten that far yet | 15:49 |
| elb | so your suggestion is that we leave commands to the sysctl as plain text, and re-frame the responses as binary-only? | 15:49 |
| minute | elb: the SPI stuff is basically a port of that to a more restrictive transport layer | 15:49 |
| minute | elb: hmm, i don't necessarily see a huge gain in them being binary... that's up for debate | 15:50 |
| minute | elb: a checksum and other framing could also be printable digits :D (unusual, but...) | 15:51 |
| elb | it could, and I thought about that | 15:51 |
| elb | it really depends on what the goal is | 15:51 |
| minute | i see two goals: 1. make the message integrity 100% reliable (recognize transfer errors with certainty, and make sure the syntax is correct before parsing) 2. ideally make it still plaintext compatible (more friendly to debug). but this can be examined more closely vs any tradeoffs i might glance over at the moment | 15:53 |
| minute | and a subgoal of 1. is probably, define a regular response syntax | 15:53 |
| minute | when choosing a syntax, i like to consider what existing tooling it would immediately be compatible to | 15:54 |
| minute | for example, if it was CSV/TSV, or JSON, it could be verbatim logged and graphed | 15:55 |
| minute | if it was custom, one would require extra parsers/adapters | 15:55 |
| elb | I see two specific benefits of going binary; one, a much more robust check (even something like a CRC) becomes easy without having to, say, base64 or something. Two, the numeric fields can stay numeric, which simplifies parsing and means fewer hacks to keep things fixed-width | 15:55 |
| elb | yeah plaintext has real benefits for "let me just dump this through awk and gnuplot" | 15:55 |
| - paperManu (QUIT: Ping timeout: 264 seconds) (~paperManu@142.169.16.151) | 15:56 | |
| elb | but is that something an interface tool could do? | 15:56 |
| minute | elb: i mean plan9 got pretty far with plaintext interfaces ^^ | 15:56 |
| minute | elb: for crc, i was imagining that you would just crc the text string as if it was binary and then append it as a hex string | 15:57 |
| elb | I need to look at all of the messages more closely, I understand your position and I think this is something that I"ll have a better idea about once I see the landscape | 15:57 |
| minute | (utf8 is for me just a specific type of binary) | 15:57 |
| elb | that's true, re: plan 9, but plan 9 was also more in the situation of the drivers you mention above | 15:58 |
| elb | even more so, as it was almost all _userspace_ applications providing those services | 15:58 |
| elb | so they had memory protection and complex allocation interfaces and large standard libraries at their disposal | 15:58 |
| minute | right. are you worried about arbitrary field lengths etc? | 15:59 |
| elb | yeah I was thinking the checksum could be represented in hex or base64 or somethning, yeah | 15:59 |
| elb | arbitrary field lengths and numeric parsing, yes | 15:59 |
| elb | I see that most of the current messages are fixed fields, but there's some questionable (to me) numeric stuff | 16:00 |
| minute | elb: yeah, those are mainly bugs | 16:00 |
| elb | I think I even saw and atoi() (although maybe that was in hidraw) | 16:00 |
| minute | elb: it was supposed to be regular, but i made at least one mistake | 16:00 |
| elb | ok fair | 16:00 |
| minute | in the end, a proven, but a bit more flexible parser would have been better, but it would need to hard limit all lengths and use only fixed preallocated buffers. | 16:01 |
| elb | I should also say that I'm considering these surfaces taht should be hardened | 16:02 |
| elb | which is ... definitely something that requires a careful threat model | 16:02 |
| elb | like obviously if you can just send 0p and shut the thing down you have to be trusted | 16:02 |
| elb | but also I don't want to see arbitrary memory accesses | 16:02 |
| minute | elb: right. | 16:03 |
| elb | unrelated, but did you see my comments about HID reports the other day? | 16:03 |
| - jogu (QUIT: Remote host closed the connection) (~jogu@user/jogu) | 16:03 | |
| minute | elb: 0p + checksum would be better though :D | 16:03 |
| elb | absolutely! | 16:03 |
| minute | elb: ah, i think i missed that about HID | 16:03 |
| elb | I have a slight concern that I'm not sure how to resolve | 16:04 |
| elb | related to suppressing unnecessary HID reports | 16:04 |
| elb | right now, we trigger one HID report on every keyboard poll, which sends a keyboard report immediately | 16:04 |
| elb | and then when we receive confirmation that it was sent, we send the trackball | 16:05 |
| minute | elb: ok, i just thought about it some more. i think arbitrary text and esp. number formatting/parsing adds a lot more overhead than is required for a machine interface, and needing a little tool on a computer to pretty print the responses is actually fine. | 16:05 |
| elb | but we're only notified of that report completing on the _next_ keyboard poll | 16:05 |
| elb | because it comes as a callbnack when we call tud_task() | 16:05 |
| minute | mhm | 16:06 |
| elb | this is absolutely imminently solvable, but it's gonig to be added complexity | 16:06 |
| elb | I can't find any way to get tinyusb to notify us of that truly asynchronously | 16:06 |
| minute | elb: well, for me the current code about report is legacy because we really should first switch to something like in my next branch of keyboard4-fw, because we should send the reports only if any inputs to the reports differ | 16:07 |
| elb | I'm thinking something like a stuttered wakeup -- send a report and set a _very quick_ timer for the next wakeup, if there are chained reports, more like 1 ms or so, where the next wakeup does nthing but clock out the next report | 16:07 |
| elb | yeah that's exactly where I'm going with this | 16:07 |
| elb | ok maybe I need to look at that firmware | 16:07 |
| minute | hang on, i'll send a link | 16:08 |
| elb | if you already have suppression there's no sense in me reinventing that | 16:08 |
| minute | yeah that's what i mean | 16:08 |
| minute | but that version is losing keydown/up events spuriously, so maybe you can figure out why | 16:08 |
| minute | it might point to a deeper issue or maybe i just made a small mistake | 16:09 |
| elb | popping back to binary vs text messages, I should also add that I have an aversion to "text" protocols which are _actually binary_ like NMEA and APRS, because they trick people into thinking that typing them is reasonable, when it's not ;-) | 16:09 |
| minute | elb: https://source.mnt.re/reform/reform/-/blob/next-multitouch/reform2-keyboard4-fw/src/main.c?ref_type=heads#L482 | 16:09 |
| minute | elb: sorry, this is the more interesting part https://source.mnt.re/reform/reform/-/blob/next-multitouch/reform2-keyboard4-fw/src/main.c?ref_type=heads#L517 | 16:10 |
| minute | this version also has consumer reports for media keys btw | 16:10 |
| elb | ok, I pulled that up and I'll plan to look at it before I dig any deeper into the HID reports | 16:11 |
| minute | elb: ok ^^ i kind of thought in the last 10 minutes like "it would be so much easier/cleaner to just pass structs" so yeah. you have my blessing | 16:11 |
| elb | it took me a little bit to figure out what all tusb was doing | 16:11 |
| elb | since, you know, there's absolutely no documentation | 16:11 |
| minute | yeah, that, i read from the sidelines | 16:11 |
| minute | cool that you're digging in there! | 16:11 |
| elb | oh I'm loving this | 16:12 |
| elb | so to close the second thread, I'll look at the sysctl interface with an eye to a very regular and simple but structured protocol for sysctl <-> keyboard and SoM; I wasn't previously aware of the unified protocol talking to the kernel, so I'll think about that, too | 16:13 |
| elb | my instinct is to do something like a TLV chain with very simple framing to include a checksum | 16:14 |
| elb | (or more likely a CRC) | 16:15 |
| elb | I will note out loud that this also requires a method for forcing a re-sync | 16:16 |
| elb | if a message fails to decode, you can get into a situation where you don't know how to interpret the _next_ message | 16:16 |
| elb | now to do my real job :-\ | 16:18 |
| minute | elb: yep, we have these sync problems already in practice, and a "resync" command is missing. | 16:20 |
| minute | elb: ttyl! | 16:20 |
| + jogu (~jogu@user/jogu) | 16:54 | |
| ^alex | if we had infinite time/energy we would consider a Kaledioscope port to the pocket reform keyboard | 17:06 |
| - GNUmoon2 (QUIT: Ping timeout: 272 seconds) (~GNUmoon@gateway/tor-sasl/gnumoon) | 17:21 | |
| + paperManu (~paperManu@142.169.16.151) | 17:33 | |
| + GNUmoon2 (~GNUmoon@gateway/tor-sasl/gnumoon) | 17:33 | |
| - paperManu (QUIT: Ping timeout: 264 seconds) (~paperManu@142.169.16.151) | 17:43 | |
| + FirefoxDeHuk (~FirefoxDe@109.108.69.106) | 18:09 | |
| sigrid | josch: mpv works great as well - https://git.sr.ht/~ft/aports/commit/b4759c670a175d0b8cdb10cecae1c3b7c2f6dc3b | 18:14 |
| elb | minute: I see why this would drop consumer control keys, but not regular keyboard keys (at least not yet); does it drop only multimedia keys? | 18:25 |
| elb | is there a list of priorities or outstanding bugs/concerns somewhere? I'm kind of applying effort on whatever catches my attention, which was great while I was getting a feel for the ecosystem, but now that I'm starting to feel comfortable with how things are put together I'd be happy to start tackling things people actually _care_ about. | 18:28 |
| elb | (I'm also happy to keep doing whatever and just try to make things cleaner/better here and there, but now that I see the divergence in this firmware, I'm wondering if me submitting a million patches to the pocket keyboard firmware is really what y'all want) | 18:29 |
| grimmware | elb: my only ask is whilst you're in there keep an eye out for unnecessary interactions with the sysctl because the likelihood is that to get a lower power consumption from the sysctl (which we sorely need) it's liable to need to wake on an interrupt on a uart pin (or some adjacent bodge) so if the keyboard's querying the sysctl when it doesn't need to that's likely to need cleaning up at some point | 18:32 |
| grimmware | so I guess just generally keep low power states in mind because it would be great if these would stop draining the battery so much when the SoM is off | 18:33 |
| elb | grimmware: power is one of the things I got started here to look at, in fact | 18:34 |
| grimmware | oh nice! | 18:35 |
| elb | the power thing currently on my radar is slowing down HID wakeups | 18:35 |
| grimmware | ah nice | 18:35 |
| grimmware | that sounds like a really good place to start :) | 18:35 |
| elb | I believe he keyboard isn't sending HID reports when the SoM is off/asleep, but it's still _waking up_ and doing a full poll | 18:35 |
| elb | and when the SoM is awake, it's sending one or more HID reports every 5 ms, regardless of need | 18:36 |
| grimmware | oh wow | 18:36 |
| elb | I'd hae to look, but I think it doesn't poke the sysctl uart if it knows the system is powered off, but it isn't good about knowing that | 18:36 |
| elb | in particular if the system powers off for anything except hyper+enter 0, I think it doesn't know | 18:36 |
| elb | (which is definitely a bug, I filed an issue for that) | 18:37 |
| grimmware | what do you think is the answer, keepalive from the sysctl? | 18:37 |
| + paperManu (~paperManu@142.169.16.151) | 18:37 | |
| elb | I haevn't tracked it down yet, I think I know generally why it's happening, but a casual glance at teh code alsoso suggested that it has an attempt to reventthat in palce | 18:38 |
| elb | ugh lag | 18:38 |
| elb | sorry for that junk, I was out-typing my display update | 18:38 |
| elb | I think I know why it's happening, but I think the code is trying to do the right thing, basically | 18:39 |
| elb | it needs more inspection | 18:39 |
| - FirefoxDeHuk (QUIT: Quit: Client closed) (~FirefoxDe@109.108.69.106) | 18:39 | |
| elb | I don't know if keepalives is it; I'd like to see something that is synchronously correct, and it feels doable | 18:39 |
| elb | maybe some pollings on reset/etc. to make sure everythiung is in the same state | 18:39 |
| elb | I'm going to look harder at that when I visit the remote protocol | 18:40 |
| minute | elb: no it drops regular keys | 18:40 |
| minute | elb: ok so in the keyboard space, my biggest priority is fixing that "dropping keys" bug so i can merge that to reform2-keyboard4 main, (and ship the reform next), and reuse that code on pocket to make the USB interface less spammy | 18:42 |
| minute | elb: and we should decide at which point it makes the most sense to merge these two firmwares into one that has a pocket and a classic mode | 18:44 |
| minute | elb: as the pocket's fw has the most polish currently, i think it makes sense to make a branch in the pocket repo and manually carry over features from reform2-keyboard4 until that fw works ok on a reform2-keyboard4 | 18:45 |
| minute | or we could make a new repo reform-firmware that over time replaces all pico-sdk based impls with unified ones (i.e. one unified sysctl codebase and one unified hid/input codebase) | 18:47 |
| minute | if sysctl and hid are in one repo together, it would be not too hard to run integration tests of the protocol between them in CI | 18:47 |
| - chorc (QUIT: Quit: ZNC 1.9.1 - https://znc.in) (~chorc@user/chorc) | 18:48 | |
| + chorc (~chorc@user/chorc) | 18:49 | |
| elb | minute: personally I'd like to see a repo for unified firmware and then just pull that into pocket or next or whatever; how to _get_ there is a little bit of a different question | 18:52 |
| minute | ok | 18:53 |
| elb | right now I'm not setup to do that integration work, though | 18:54 |
| elb | in the sense that the only hardware I can test is the Pocket | 18:55 |
| - paperManu (QUIT: Ping timeout: 260 seconds) (~paperManu@142.169.16.151) | 18:56 | |
| elb | what I _can_ do is try to port some of the HID suppression stuff over to the pocket, but as things stand right now, it would then require back-porting | 18:56 |
| elb | but I think something like a reform-fw repo where you just 'cmake -DPLATFORM=pocket' or -DPLATFORM=next or whatevber would be very nice | 18:58 |
| grimmware | yeah unified firmware would definitely be good. | 18:59 |
| + erle (~erle@user/erle) | 19:00 | |
| elb | also; if it's dropping regular keys, I dont' immediately see why that is, and so I'd probably want to port it over to pocket and play with it a bit to try to figure that out | 19:01 |
| + paperManu (~paperManu@142.169.16.151) | 19:01 | |
| grimmware | > if sysctl and hid are in one repo together, it would be not too hard to run integration tests of the protocol between them in CI | 19:04 |
| grimmware | omg yes | 19:04 |
| grimmware | I would happily help with that, it would do a lot to prevent bugs from finding their way back in. | 19:05 |
| elb | a set of integration tests that could be run with a pair of pi picos would bbe cool for reworking the remote protocol | 19:07 |
| grimmware | [tj] started looking into that some time ago but has been working on other stuff | 19:08 |
| elb | yeah they mentioned testing with a pico earlier is what made me think of it | 19:09 |
| grimmware | If I had a reliable development environment for that stuff I'd be working a lot more actively on it, the i2c-over-spi proxy stuff for one | 19:09 |
| elb | that feels like it wants an emulator | 19:09 |
| elb | isn't the other end of the spi normally the SoM? | 19:09 |
| elb | but again, a pico could handle that | 19:10 |
| elb | a rack of picos and some wires with a usb hub ;-) | 19:10 |
| grimmware | oh no wait yeah sorry I'm brainfarting | 19:10 |
| grimmware | it's tunneling i2c over spi so you can present a kernel interface for the i2c which is actually connected to the sysctl | 19:11 |
| grimmware | because that's the only thing with an exposed qwiic header | 19:11 |
| elb | right now the sysctl talks to the SoM in a streaming text protocol wrapped in I2C transported over SPI? | 19:12 |
| grimmware | oh wait maybe I could try to do this with a pi and a pico... | 19:12 |
| grimmware | no right now the sysctl talks to the SoM over pure SPI | 19:13 |
| elb | ok good that hurts less | 19:13 |
| grimmware | oh no yeah I want to *add* the jank so that i2c can be used without having to maintain your own fork of both the sysctl firmware and the kernel module | 19:14 |
| grimmware | minute, josch: actually on that note, what if the new reform-firmware repo was actually also a debian package which distributes source and firmware binaries for the picos but doesn't actually install them, and we also moved the kernel module to it? That way if you *did* want to maintain your own fork or patchset it would be significantly less painful. | 19:17 |
| grimmware | it would also make the reform family significantly more moddable from the get-go | 19:17 |
| + rwa_ (~rene@2001:9e8:3393:dc00:555e:eb3:b087:a109) | 19:19 | |
| - paperManu (QUIT: Ping timeout: 264 seconds) (~paperManu@142.169.16.151) | 19:19 | |
| - erle (QUIT: Ping timeout: 264 seconds) (~erle@user/erle) | 19:26 | |
| + wielaard (~mjw@gnu.wildebeest.org) | 19:30 | |
| + paperManu (~paperManu@142.169.16.151) | 19:32 | |
| - paperManu (QUIT: Ping timeout: 264 seconds) (~paperManu@142.169.16.151) | 19:38 | |
| - qbit (QUIT: Remote host closed the connection) (~qbit@user/qbit) | 19:40 | |
| + qbit (~qbit@user/qbit) | 19:43 | |
| josch | grimmware: firmware is already distributed via fwupd though | 20:00 |
| josch | already found the first bug: W: unsupported machine: MNT Reform 2 with i.MX8MP Module | 20:01 |
| + paperManu (~paperManu@142.169.16.151) | 20:25 | |
| - paperManu (QUIT: Ping timeout: 244 seconds) (~paperManu@142.169.16.151) | 20:44 | |
| + johl (~johl@ip-185-104-138-117.ptr.icomera.net) | 21:08 | |
| + paperManu (~paperManu@142.169.16.151) | 21:18 | |
| - johl (QUIT: Quit: leaving) (~johl@ip-185-104-138-117.ptr.icomera.net) | 21:21 | |
| - aloo_shu (QUIT: Ping timeout: 252 seconds) (~aloo_shu@85.51.17.185) | 21:34 | |
| elb | well I just found a way to save a _little_ bit of power | 21:42 |
| elb | one of the column driver pins is idling high, which is six GPIO pulldown loads | 21:43 |
| elb | hmmm they're in the 50kohm range, that's pretty high | 21:44 |
| elb | (so not much current) | 21:44 |
| elb | I'll fix it anyway ;-) | 21:44 |
| + LainIwakura (~LainIwaku@user/LainIwakura) | 21:47 | |
| + LainIwakura85 (~LainIwaku@user/LainIwakura) | 21:49 | |
| - LainIwakura (QUIT: Ping timeout: 250 seconds) (~LainIwaku@user/LainIwakura) | 21:54 | |
| - paperManu (QUIT: Ping timeout: 260 seconds) (~paperManu@142.169.16.151) | 21:58 | |
| + leony (~leony@2a02:8109:f084:a900::e761) | 22:03 | |
| - rwa_ (QUIT: Remote host closed the connection) (~rene@2001:9e8:3393:dc00:555e:eb3:b087:a109) | 22:11 | |
| - gustav25 (QUIT: Quit: Quit) (~gustav@c-92-32-81-177.bbcust.telenor.se) | 22:15 | |
| + chomwitt (~chomwitt@2a02:85f:9a5f:900:1ac0:4dff:fedb:a3f1) | 22:17 | |
| - plomtest (QUIT: Remote host closed the connection) (~plom@user/plomtest) | 22:23 | |
| + plomtest (~plom@user/plomtest) | 22:24 | |
| + paperManu (~paperManu@107.159.15.124) | 22:50 | |
| elb | ok the red wire is GND and the black wire is +5 V on the USB cable to the motherboard, that's just evil | 22:51 |
| - andreas-e (QUIT: Quit: Leaving) (~Andreas@2a02-8434-b6a3-e901-facc-8e87-8e54-890e.rev.sfr.net) | 22:55 | |
| - plomtest (QUIT: Remote host closed the connection) (~plom@user/plomtest) | 22:55 | |
| + plomtest (~plom@user/plomtest) | 22:55 | |
| elb | grimmware: I just scoped the pocket keyboard to sysctl interface and it's actually pretty quiet, I don't think it's waking the sysctl frequently | 23:02 |
| elb | tough to be sure because its' freaking hard to get a scope probe onto those pads | 23:02 |
| elb | I neeed to check the boards for a btter place to sniff | 23:03 |
| + aloo_shu (~aloo_shu@85.51.17.185) | 23:06 | |
| - mlarkin (QUIT: Ping timeout: 264 seconds) (~mlarkin@syn-076-081-194-027.biz.spectrum.com) | 23:26 | |
| - plomtest (QUIT: Remote host closed the connection) (~plom@user/plomtest) | 23:26 | |
| + plomtest (~plom@user/plomtest) | 23:26 | |
| - LainIwakura85 (QUIT: Quit: Client closed) (~LainIwaku@user/LainIwakura) | 23:27 | |
| + mlarkin (~mlarkin@syn-076-081-194-027.biz.spectrum.com) | 23:27 | |
| - plomtest (QUIT: Remote host closed the connection) (~plom@user/plomtest) | 23:27 | |
| + plomtest (~plom@user/plomtest) | 23:28 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!