| josch | minute: also, another note about the Origin field of the MNT Debian repo: | 00:00 |
|---|---|---|
| josch | when we add that field, users who run "apt update" will get this message: | 00:00 |
| josch | Error: Repository 'https://mntre.com/reform-debian-repo reform InRelease' changed its 'Origin' value from '' to 'mntre.com' | 00:00 |
| josch | Notice: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details. | 00:00 |
| josch | Do you want to accept these changes and continue updating from this repository? [y/N] | 00:00 |
| josch | This is a mechanism to prevent accidentally swapping out repositories. | 00:00 |
| josch | I'll write a forum post about that, so that hopefully fewer people get confused. | 00:01 |
| josch | minute: but this is also why it's not so important *which* value to choose for the field but that we never change it later :D | 00:01 |
| + colinsane (~colinunin@97-113-91-78.tukw.qwest.net) | 00:05 | |
| + colinsane1 (~colinunin@97-113-91-78.tukw.qwest.net) | 00:07 | |
| - colinsane (QUIT: Ping timeout: 272 seconds) (~colinunin@97-113-91-78.tukw.qwest.net) | 00:12 | |
| - colinsane1 (QUIT: Ping timeout: 272 seconds) (~colinunin@97-113-91-78.tukw.qwest.net) | 00:13 | |
| + colinsane (~colinunin@97-126-5-189.tukw.qwest.net) | 00:14 | |
| - colinsane (QUIT: Remote host closed the connection) (~colinunin@97-126-5-189.tukw.qwest.net) | 00:14 | |
| josch | should my Pocket Reform keep the time without its internal batteries attached? Isn't there a RTC with a button cell battery to keep the time? | 00:25 |
| josch | when i switch on my pocket it's back at April 7 2025 19:39 | 00:25 |
| + colinsane (~colinunin@97-126-5-198.tukw.qwest.net) | 00:27 | |
| - colinsane (QUIT: Client Quit) (~colinunin@97-126-5-198.tukw.qwest.net) | 00:27 | |
| - mjw (QUIT: Ping timeout: 252 seconds) (~mjw@gnu.wildebeest.org) | 00:31 | |
| josch | hrm... i don't see an rtc battery on the pocket motherboard | 00:43 |
| - Ar|stote|is (QUIT: Read error: Connection reset by peer) (~linx@149.210.24.240) | 00:56 | |
| + Ar|stote|is (~linx@149.210.24.117) | 01:05 | |
| - svp (QUIT: Remote host closed the connection) (~svp@host-79-7-240-189.business.telecomitalia.it) | 01:26 | |
| + svp (~svp@host-79-7-240-189.business.telecomitalia.it) | 01:27 | |
| jfred | Finally starting to try out Guix System on my rk3588 Reform. I run it on any machine I can and I've been missing it here, haha. Gotta wait for all the custom patched packages to build though, and I'm very glad for the 32 GB of RAM right now | 01:53 |
| jfred | I'm also impressed at how usable the system remains while building all that (and while building libfive at the same time because I wanted to try it again on the rk3588) | 01:55 |
| jfred | Ah. Right. This is what I got when I tried launching libfive studio: "OpenGL context is too old (got 3.1, need 3.2)" | 01:58 |
| jfred | wonder if that mesa override env var might get it partly working | 01:59 |
| - GNUmoon (QUIT: Remote host closed the connection) (~GNUmoon@gateway/tor-sasl/gnumoon) | 02:11 | |
| + GNUmoon (~GNUmoon@gateway/tor-sasl/gnumoon) | 02:12 | |
| + colinsane (~colinunin@97-126-5-198.tukw.qwest.net) | 02:58 | |
| - colinsane (QUIT: Ping timeout: 268 seconds) (~colinunin@97-126-5-198.tukw.qwest.net) | 03:03 | |
| + colinsane (~colinunin@97-113-65-55.tukw.qwest.net) | 03:10 | |
| - colinsane (QUIT: Quit: bye) (~colinunin@97-113-65-55.tukw.qwest.net) | 03:16 | |
| + colinsane (~colinunin@97-113-65-55.tukw.qwest.net) | 03:31 | |
| - nsc (QUIT: Ping timeout: 252 seconds) (~nicolas@109-96-142-46.pool.kielnet.net) | 03:34 | |
| - colinsane (QUIT: Ping timeout: 252 seconds) (~colinunin@97-113-65-55.tukw.qwest.net) | 03:36 | |
| + nsc (~nicolas@139-98-142-46.pool.kielnet.net) | 03:36 | |
| + colinsane (~colinunin@97-113-89-85.tukw.qwest.net) | 03:39 | |
| - paperManu (QUIT: Ping timeout: 265 seconds) (~paperManu@107.159.213.145) | 03:49 | |
| - op_4 (QUIT: Remote host closed the connection) (~tslil@user/op-4/x-9116473) | 04:05 | |
| + op_4 (~tslil@user/op-4/x-9116473) | 04:05 | |
| - arminweigl (QUIT: Ping timeout: 265 seconds) (~arminweig@sourcehut/user/arminweigl) | 05:10 | |
| + arminweigl (~arminweig@sourcehut/user/arminweigl) | 05:58 | |
| + chomwitt (~chomwitt@2a02:85f:9a00:8300:1ac0:4dff:fedb:a3f1) | 06:42 | |
| - aloo_shu (QUIT: Ping timeout: 248 seconds) (~aloo_shu@85.51.17.10) | 06:53 | |
| + aloo_shu (~aloo_shu@85.51.17.10) | 07:23 | |
| + gustav28 (~gustav@c-78-82-53-72.bbcust.telenor.se) | 10:02 | |
| - colinsane (QUIT: Quit: bye) (~colinunin@97-113-89-85.tukw.qwest.net) | 10:08 | |
| + colinsane (~colinunin@97-113-89-85.tukw.qwest.net) | 10:13 | |
| - colinsane (QUIT: Read error: Connection reset by peer) (~colinunin@97-113-89-85.tukw.qwest.net) | 10:24 | |
| - gustav28 (QUIT: Ping timeout: 252 seconds) (~gustav@c-78-82-53-72.bbcust.telenor.se) | 11:10 | |
| - chomwitt (QUIT: Ping timeout: 276 seconds) (~chomwitt@2a02:85f:9a00:8300:1ac0:4dff:fedb:a3f1) | 11:16 | |
| grimmware | josch, minute: Just tested https://source.mnt.re/reform/reform-debian-packages/-/merge_requests/105 and it fixes the issue with the screen not reactivating | 11:36 |
| grimmware | (rk3588 pocket, screen v1) | 11:36 |
| + mjw (~mjw@gnu.wildebeest.org) | 12:32 | |
| - iank (QUIT: Quit: ZNC 1.8.2+deb2+deb11u1 - https://znc.in) (~iank@fsf/staff/iank) | 12:46 | |
| - manis (QUIT: Quit: Gateway shutdown) (01a66df340@185.72.67.185) | 12:46 | |
| + iank (~iank@fsf/staff/iank) | 12:46 | |
| + manis (01a66df340@185.72.67.185) | 12:55 | |
| + chomwitt (~chomwitt@2a02:85f:9a00:8300:1ac0:4dff:fedb:a3f1) | 13:04 | |
| - chomwitt (QUIT: Ping timeout: 248 seconds) (~chomwitt@2a02:85f:9a00:8300:1ac0:4dff:fedb:a3f1) | 13:09 | |
| - elb (QUIT: Remote host closed the connection) (~elb@2600:4041:6671:1300:fb99:ad29:c9b7:14f5) | 13:13 | |
| + elb (~elb@2600:4041:6671:1300:e8f6:ebea:a95c:736) | 13:13 | |
| - iank (QUIT: Quit: ZNC 1.8.2+deb2+deb11u1 - https://znc.in) (~iank@fsf/staff/iank) | 13:25 | |
| + iank (~iank@fsf/staff/iank) | 13:29 | |
| minute | grimmware: could i ask you to test this kernel as well? https://source.mnt.re/reform/reform-debian-packages/-/merge_requests/108 | 13:38 |
| grimmware | minute: I can give it a go this evening, I need to head out shortly and I need my pocket in a usable state :) | 13:41 |
| grimmware | minute: if you get 5 minutes to spare, could you have a glance at https://source.mnt.re/grimmware/pocket-reform/-/commit/cd0e3013014d5aa7a9d9d4fb97e520ef3cb651fe and let me know if the approach (i2c proxying) looks sane to you? I'm not entirely sure what the interface for this is going to look like on the kernel module side yet | 13:46 |
| grimmware | it builds but I haven't tried flashing it yet, I need to prototype a way to interact with it first | 13:48 |
| + paperManu (~paperManu@107.159.213.145) | 13:59 | |
| minute | PSA we'll move source.mnt.re to a new server soon, there will be some downtime | 14:15 |
| minute | (bigger server) | 14:15 |
| minute | grimmware: > if((spi_arg1 << 7) != 0) | 14:20 |
| minute | grimmware: what are you trying to do here? test 1 bit? | 14:20 |
| grimmware | Yeah | 14:20 |
| grimmware | The 8th bit of the address is the r/w | 14:21 |
| minute | grimmware: i think you want to shift in the other direction then. but instead you can just test for the bit with : spi_arg1 & (0b10000000) | 14:22 |
| minute | grimmware: or spi_arg & (1<<7) | 14:22 |
| grimmware | Ah nice that’s the pattern I was half remembering :) | 14:23 |
| grimmware | Thanks! | 14:23 |
| minute | grimmware: but... isn't the first bit the r/w bit on i2c and the address gets shifted up by one? | 14:24 |
| minute | i.e. (7bitaddr << 1 | r_w_bit) | 14:24 |
| grimmware | I’ll look at that next, this is exactly the bit I wanted someone to double-check for me | 14:25 |
| minute | grimmware: also there are different conventions about if you pass the 8 bit r-address or the 7 bit address | 14:26 |
| grimmware | So I need to check whether I should mask the rw but out or not when I pass to the read or write functions? | 14:29 |
| minute | grimmware: normally not. normally it's expected that you don't have to do any extra work on the address when dealing with an i2c address. | 14:30 |
| minute | grimmware: so i would just pass in what you get | 14:30 |
| minute | grimmware: ok, sorry, i'm a bit more concentrated now. i guess the problem is the API design. you're trying to extract a subcommand from a bit there. i would just do 2 separate commands (read + write) | 14:31 |
| minute | grimmware: don't fiddle with any bits etc. just do a 'i' and a 'I' (upper case) for read/write for example | 14:31 |
| minute | grimmware: and then just pass on what you got | 14:32 |
| grimmware | Oh that’s a really nice idea | 14:32 |
| grimmware | Cool I’ll do that instead then I don’t need to do any bit fiddling at all | 14:32 |
| minute | grimmware: yess, and that also maps to established i2c apis | 14:32 |
| grimmware | Gotcha | 14:32 |
| minute | grimmware: one thing you might need is a parameter for stop / nostop | 14:33 |
| minute | grimmware: the > bool nostop | 14:33 |
| grimmware | I think I might see if I can get away with not bothering initially so I can get a PoC with the accelerometers I’ve got and then loop back round to add the bits for the generic case | 14:34 |
| minute | grimmware: another idea could be you use something like "i" for all i2c commands and the next second byte is for flags. so you can have an r/w bit and a nostop bit there, and maybe more bits later. | 14:35 |
| josch | minute: can you give me an ack or nack on the origin field? I now added one to reform.debian.net and having the field set allows to distinguish repositories with apt patterns (that's the big motivation). | 14:36 |
| minute | btw on the reform next/rk3588/rp2350a i have lots of SPI issues | 14:36 |
| minute | josch: ah. what's the new origin now? mntre.com ? | 14:36 |
| josch | minute: and i guess it's normal that a pocket reform without attached battery does not keep the time between being unplugged? | 14:36 |
| josch | minute: it's empty | 14:36 |
| josch | no | 14:36 |
| josch | it's not set | 14:36 |
| josch | so not "not empty" it doesn't exist :) | 14:36 |
| minute | josch: that's the old origin, but the new one? | 14:37 |
| josch | minute: the new one is up to you to decide | 14:37 |
| minute | josch: ok, i thought about this a bit and the most correct one would be MNT Research, but that's somehow clunky for certain usecases or...? | 14:37 |
| minute | josch: can you give me an example of a command where i would need to type in the origin? | 14:38 |
| grimmware | Bbiab | 14:38 |
| josch | minute: i think "MNT Research" is fine. Maybe you find the space and the casing awkward but for debian backports the origin is "Debian Backports" | 14:38 |
| josch | minute: use case is to list all packages that you have installed from the MNT repository. You could do that like this: | 14:38 |
| minute | josch: pocket reform doesn't have a coin cell so yeah, without batteries the rtc loses the time. | 14:38 |
| josch | apt list '?narrow(?installed, ?origin(MNT Research))' | 14:39 |
| josch | minute: thank you | 14:39 |
| minute | josch: ok lets do MNT Research | 14:39 |
| josch | thank you! | 14:39 |
| josch | https://source.mnt.re/reform/reform-debian-packages/-/merge_requests/111 | 14:43 |
| josch | will test, then merge and write a forum post about what this means | 14:43 |
| grimmware | I can figure out how this i2c filesystem interface would work in a like, plan 9 webfs style paradigm but I’m not sure what the more unixy equivalent would be. | 15:08 |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@h211.16.186.173.dynamic.ip.windstream.net) | 15:16 | |
| + bkeys (~Thunderbi@h211.16.186.173.dynamic.ip.windstream.net) | 15:23 | |
| - bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@h211.16.186.173.dynamic.ip.windstream.net) | 15:23 | |
| + bkeys (~Thunderbi@h211.16.186.173.dynamic.ip.windstream.net) | 15:24 | |
| - bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@h211.16.186.173.dynamic.ip.windstream.net) | 15:24 | |
| + bkeys (~Thunderbi@h211.16.186.173.dynamic.ip.windstream.net) | 15:26 | |
| - bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@h211.16.186.173.dynamic.ip.windstream.net) | 15:26 | |
| minute | grimmware: as you don't want to buffer things and handle concurrent connections, i guess one needs exclusive access to an "i2c" file | 15:31 |
| minute | grimmware: actually i think you need to buffer the last response. i would say, if you write to the sysfs file, you issue an i2c command. if you read from the file, you get the last buffered response | 15:33 |
| minute | grimmware: you could add another file like i2c-debug for any debugging/error output you might need, and just make that contain a string or so | 15:33 |
| minute | grimmware: but lets say i write to the i2c file to issue a read command. if something goes wrong this can already return an error code for the file write | 15:35 |
| minute | grimmware: if no error is returned i can assume the transaction went ok, and i can then read the result by reading from the same i2c file | 15:35 |
| minute | grimmware: another option would be to emulate the interface of i2c-dev | 15:37 |
| minute | grimmware: that's much more complicated though | 15:37 |
| minute | grimmware: i guess the most sophisticated approach would be to register an actual i2c bus :D | 15:38 |
| minute | int i2c_add_adapter (struct i2c_adapter * adapter); | 15:40 |
| minute | grimmware: maybe i2c_add_adapter is not that bad. the main thing is a struct i2c_algorithm. this just needs an implementation of int(* master_xfer )(struct i2c_adapter *adap, struct i2c_msg *msgs, int num) | 15:42 |
| minute | grimmware: and an i2c_msg is just addr / flags / len / buf | 15:42 |
| minute | grimmware: so if you implement master_xfer() you loop through the i2c_msgs and convert them into your spi calls. | 15:44 |
| minute | grimmware: i think then a new i2c bus would appear in /dev and could be used by the standard stuff in i2c-tools | 15:45 |
| grimmware | I think I’ll probably go for your initial suggestion for the PoC. | 15:56 |
| minute | grimmware: ok :D | 15:56 |
| grimmware | minute: what do you think is the feasibility of adding i2c breakout from the SoM on future carrier boards? | 15:57 |
| minute | grimmware: very feasible. reform motherboard 3.0 already has one ^^ | 15:58 |
| grimmware | :O | 15:58 |
| minute | haha i just froze my machine with a python script writing too quickly to /dev/uinput | 16:02 |
| grimmware | minute: would be really great to get one on the next rcore carrier if it's possible because that would make it available for pocket and next | 16:06 |
| grimmware | I think using a separate addr file would be a nice way to make reuse simple and also for the very naive implementation would mean we can just set the convention that you need to flock the addr file until you're done with your transaction | 16:20 |
| grimmware | if we were to use separate read and write files that would mean that a read of the write file could expose the bytes written in the last write, then we don't actually have to buffer the response because the read should be atomic? | 16:24 |
| grimmware | assuming I'm not misremembering how this works | 16:25 |
| vkoskiv | An interesting quirk I haven't had the mental bandwidth to debug is that every time I boot, '/usr/bin/fluidsynth -is /usr/share/sounds/sf3/default-GM.sf3' is stuck in some loop consuming 100% CPU. | 16:36 |
| vkoskiv | It just keeps doing that until I kill it. No idea what it is or what it's trying to do :D | 16:36 |
| vkoskiv | perf top symbols for it are soc_dapm_mux_update_power, and snd_soc_dapm_put_enum_double, both in snd_soc_core. | 16:38 |
| + chomwitt (~chomwitt@2a02:85f:9a00:8300:1ac0:4dff:fedb:a3f1) | 16:42 | |
| vkoskiv | I'll just delete fluidsynth, no idea why it's even installed to begin with. | 16:44 |
| minute | vkoskiv: midi synth loading a huge soundfont? | 16:52 |
| minute | i thought that my trackball and esp trackpad scrolling impl was buggy, but it's actually gnome/mutter, this was pretty hard to track down https://mastodon.social/@mntmn/114569000515879965 | 16:53 |
| grimmware | hmm maybe the i2c_add_adapter is the easiest way to not have to come up with an interface | 17:11 |
| josch | minute: wow i do *not* envy you for having to track down these kind of problems all over the stack o0 | 17:20 |
| minute | josch: yeah. there's more... | 17:28 |
| minute | grimmware: i think so :D | 17:28 |
| minute | josch: one of the biggest issues in gnome is that the cursor on rk3588 doesn't use a hardware overlay, and rendering of gnome-shells own elements is done via single-threaded javascript sometimes. so those elements can make the pointer stop for a moment | 17:29 |
| minute | most noticeable when you click on the date/time dropdown with the notifications/calendar | 17:30 |
| josch | ooh i didn't notice this yet in gnome -- i have to pay attention next time | 17:30 |
| minute | to fix that we would have to patch the vop2 driver i think | 17:30 |
| josch | i'm still trying to get a nice reproducer for the imx8mq display-distortion+freeze in single display mode... very hard to repro... | 17:31 |
| minute | josch: did anyone else ever report this issue? | 17:56 |
| josch | minute: yes, we had users who complained about their imx8mq reform being unresponsive after they left it on over night which is exactly how i encountered this issue first | 17:58 |
| minute | josch: ah ok. | 17:58 |
| josch | minute: you suspect it might be a problem specific to my module? | 17:58 |
| minute | josch: not sure if i got all your updates about the issue, does it happen on both dcss and lcdif setups (single + dual) or only with single (dcss)? | 17:59 |
| josch | only with single | 17:59 |
| josch | i left dual on for a long time to make sure but it kept not crashing for 2 weeks uptime | 17:59 |
| josch | so i *guess* it's only on single and not dual | 17:59 |
| josch | (but of course since i have not found a reliable reproducer yet, maybe i was just unlucky?) | 17:59 |
| minute | josch: maybe related https://community.nxp.com/t5/i-MX-Processors/imx8mq-Facing-kernel-hang-dcss-driver-issue-with-Industrial/m-p/1907200 | 18:01 |
| minute | josch: could be DDR access patterns of DCSS | 18:01 |
| minute | josch: likely silicon bug i would say from my experience with NXP products :D | 18:02 |
| minute | on imx8mplus there's no more dcss, only lcdifs.. maybe for a reason | 18:03 |
| josch | heh :D | 18:17 |
| - svp (QUIT: Remote host closed the connection) (~svp@host-79-7-240-189.business.telecomitalia.it) | 18:50 | |
| + svp (~svp@host-79-7-240-189.business.telecomitalia.it) | 18:51 | |
| + gustav28 (~gustav@c-78-82-53-72.bbcust.telenor.se) | 19:25 | |
| + colinsane (~colinunin@97-113-85-70.tukw.qwest.net) | 19:55 | |
| + bkeys (~Thunderbi@134.22.115.162) | 20:06 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@134.22.115.162) | 20:13 | |
| - qbit (QUIT: Remote host closed the connection) (~qbit@user/qbit) | 20:30 | |
| grimmware | I'm not gonna get round to testing that kernel build today but I'll do it tomorrow | 21:56 |
| - gustav28 (QUIT: Quit: Quit) (~gustav@c-78-82-53-72.bbcust.telenor.se) | 22:15 | |
| - chomwitt (QUIT: Ping timeout: 276 seconds) (~chomwitt@2a02:85f:9a00:8300:1ac0:4dff:fedb:a3f1) | 23:29 | |
| minute | grimmware: awesome, looking fwd | 23:57 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!