2026-01-11.log

joschminute: and of course i hope that everything goes smoothly with your surgey and that you may have a speedy recovery! *fingerscrossed*00:12
- spew (QUIT: Quit: nyaa~) (~spew@user/spew)01:25
- vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:7:77:0:50)01:54
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)02:15
+ kensanata (~alex@user/kensanata)02:15
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)02:21
+ kensanata (~alex@user/kensanata)02:22
- mjw (QUIT: Ping timeout: 264 seconds) (~mjw@gnu.wildebeest.org)02:23
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)02:28
+ kensanata (~alex@user/kensanata)02:28
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)02:34
+ kensanata (~alex@user/kensanata)02:35
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)02:41
+ kensanata (~alex@user/kensanata)02:41
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)02:47
+ kensanata (~alex@user/kensanata)02:48
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)02:54
+ kensanata (~alex@user/kensanata)02:54
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)03:00
+ kensanata (~alex@user/kensanata)03:01
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)03:07
+ kensanata (~alex@user/kensanata)03:07
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)03:13
+ kensanata (~alex@user/kensanata)03:14
- paperManu_ (QUIT: Ping timeout: 246 seconds) (~paperManu@146.71.9.156)03:18
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)03:20
+ kensanata (~alex@user/kensanata)03:20
- paperManu (QUIT: Ping timeout: 244 seconds) (~paperManu@146.71.9.156)03:21
- schalken (QUIT: Ping timeout: 246 seconds) (~schalken@117-118-178-69.gci.net)03:26
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)03:26
+ kensanata (~alex@user/kensanata)03:27
+ schalken (~schalken@117-118-178-69.gci.net)03:27
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)03:33
+ kensanata (~alex@user/kensanata)03:33
- nsc (QUIT: Ping timeout: 240 seconds) (~nicolas@i5C74DF85.versanet.de)03:39
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)03:40
+ kensanata (~alex@user/kensanata)03:40
+ nsc (~nicolas@i5C74DC92.versanet.de)03:41
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)03:46
+ kensanata (~alex@user/kensanata)03:46
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)03:53
+ kensanata (~alex@user/kensanata)03:53
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)03:59
+ kensanata (~alex@user/kensanata)03:59
- 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
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)04:06
+ kensanata (~alex@user/kensanata)04:06
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)04:12
+ kensanata (~alex@user/kensanata)04:12
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)04:19
+ kensanata (~alex@user/kensanata)04:19
- chomwitt (QUIT: Ping timeout: 244 seconds) (~chomwitt@2a02:85f:9a42:1100:1ac0:4dff:fedb:a3f1)04:49
+ siviq (~siviq@user/siviq)05:13
- siviq (QUIT: Client Quit) (~siviq@user/siviq)05:17
- switchy (QUIT: Remote host closed the connection) (~switchy@mechboards/switchy)05:24
- Ar|stote|is (QUIT: Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) (~linx@149.210.3.83)05:29
+ Ar|stote|is (~linx@149.210.3.83)05:38
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)06:00
+ kensanata (~alex@user/kensanata)06:00
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)06:06
+ kensanata (~alex@user/kensanata)06:07
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)06:13
+ kensanata (~alex@user/kensanata)06:13
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)06:19
+ kensanata (~alex@user/kensanata)06:20
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)06:26
+ kensanata (~alex@user/kensanata)06:26
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)06:32
+ kensanata (~alex@user/kensanata)06:33
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)06:39
+ kensanata (~alex@user/kensanata)06:39
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)06:45
+ kensanata (~alex@user/kensanata)06:46
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)06:52
+ kensanata (~alex@user/kensanata)06:52
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)06:58
+ kensanata (~alex@user/kensanata)06:59
+ pomel0 (~pomel0@user/pomel0)07:02
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)07:05
+ kensanata (~alex@user/kensanata)07:05
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)07:11
+ kensanata (~alex@user/kensanata)07:12
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)07:18
+ kensanata (~alex@user/kensanata)07:18
- jogu (QUIT: Remote host closed the connection) (~jogu@user/jogu)07:51
+ jogu (~jogu@user/jogu)07:51
- jogu (QUIT: Remote host closed the connection) (~jogu@user/jogu)07:52
+ jogu (~jogu@user/jogu)07:53
+ potash1 (~potash@user/foghorn)08:00
- qbit (QUIT: Remote host closed the connection) (~qbit@user/qbit)08:39
- voltaire28 (QUIT: Ping timeout: 264 seconds) (~jlafon@28.162.2.93.rev.sfr.net)08:47
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)08:55
+ kensanata (~alex@user/kensanata)08:55
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)09:01
+ kensanata (~alex@user/kensanata)09:01
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)09:08
+ kensanata (~alex@user/kensanata)09:08
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)09:14
+ kensanata (~alex@user/kensanata)09:14
- bkeys (QUIT: Ping timeout: 244 seconds) (~Thunderbi@98.19.128.69)09:19
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)09:21
+ kensanata (~alex@user/kensanata)09:21
rwa_hhmmm...seems like screen flickering on low backlight settings is back on MNT Reform 2 with RCORE-DSI RK3588 after the update to Trixie 13.3 yesterday including new backports kernel 6.17.1309:21
rwa_minute: all the best, that the surgery goes well and you can recover quickly09:23
joschrwa_: i just moved my trixie installation to rk3588-dsi classic reform -- are you saying that the backlight flickering on very low brightness was not there with older kernel versions?09:23
rwa_after the dtb change a few months ago i didn't observe screen flickering anymore with Trixie and backports kernel...i'm not sure if my eyes are betraying me, i saw slight flickering a few minutes ago, it doesn't seem to be so obvious like back then09:25
rwa_now it seems to be gone09:25
rwa_i'd say i keep an eye on this, maybe i should have a coffee first09:26
joschi definitely see different degrees of flickering at very low brightness here09:26
joschi remember that there were adjustments to the dtb but i rather have flickering very low brightness than not having the ability to turn down the brightness this much -- it's really useful if the baby next to you wants to sleep :D09:27
rwa_ok, maybe it's not just me then :)09:27
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)09:27
+ kensanata (~alex@user/kensanata)09:27
joschthe lowest brightness where i still can see something is 13 and it has quite some flickering09:28
rwa_yeah, iirc it was about the pwm value for the display...i can not tune the display down so much as before the change, backlight will turn of when you go below 15 or something09:29
rwa_https://source.mnt.re/bugs/bugs/-/issues/4009:30
joschoh funny, that page says that i should've known about this :D09:32
rwa_lol, i don't expect anyone to remember things that happened 4 months ago - i just remember of the top of my head that we had an issue files back then09:34
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)09:34
+ kensanata (~alex@user/kensanata)09:34
joschhaha yes. This is why i must force myself to always write extremely verbose git commit messages. Not for others but for me 4 months in the future who will have forgotten everything. :D09:35
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)09:40
+ kensanata (~alex@user/kensanata)09:40
rwa_feel you :D09:44
rwa_afk for a while, the weather is to nice to stay inside ;)09:45
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)09:47
+ kensanata (~alex@user/kensanata)09:47
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)09:53
+ kensanata (~alex@user/kensanata)09:53
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)10:00
+ kensanata (~alex@user/kensanata)10:00
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)10:06
+ kensanata (~alex@user/kensanata)10:06
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)10:13
+ kensanata (~alex@user/kensanata)10:13
minuterwa_: thank u!10:17
minutei'm at the airport gate, flight to frankfurt is a bit delayed, so lets see if i can make those uboot tags10:17
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)10:20
+ kensanata (~alex@user/kensanata)10:20
minutejosch: imx8mplus, a311d and rk3588 uboots tagged!10:22
minutejosch: FYI this has been lingering as well, set to auto merge https://source.mnt.re/reform/reform-debian-packages/-/merge_requests/15410:29
minutejosch: originally the kernel build had worked, but it just failed because of some build-patched stuff10:29
- jogu (QUIT: Remote host closed the connection) (~jogu@user/jogu)10:33
minuteah, linux build fails now10:38
+ switchy (~switchy@mechboards/switchy)10:41
+ voltaire28 (~jlafon@28.162.2.93.rev.sfr.net)10:47
+ jogu (~jogu@user/jogu)10:56
joschminute: wooah mega thank oyu!11:47
joschminute: what abount reform-boundary-uboot?11:47
- voltaire28 (QUIT: Ping timeout: 264 seconds) (~jlafon@28.162.2.93.rev.sfr.net)11:49
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)11:56
+ kensanata (~alex@user/kensanata)11:57
+ shdw (~shdw@static.218.156.216.95.clients.your-server.de)11:59
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)12:03
+ kensanata (~alex@user/kensanata)12:03
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata)12:09
+ kensanata (~alex@user/kensanata)12:10
joschi'm also on my way to frankfurt but unfortunately train internet is so bad that i cannot load a single gitlab page XDOB12:18
joschOBOB12:18
+ AnimaInvicta (~AnimaInvi@88-120-179-216.subs.proxad.net)12:19
+ mjw (~mjw@gnu.wildebeest.org)12:37
joschOB12:41
joschorry something is wrong with mosh it seems12:42
joschminute: about reform-debian-packages failing: it fails because 6.18 got uploaded to unstable but that moves the dtbs to a different location and requires a new upload of reform-tools and that upload is blocked by the tagging of u-boot because the next reform-tools version assumes that the u-boot blobs are a multiple of 512 bytes.12:49
joschi could of course revert that change or cherry-pick the compatibility patch for 6.18 and backport that to the version in unstable but i thought that maybe creating the tag is much less work than reverting or cherry-picking commits. But if you are out for a bit now, maybe that's what I should be doing?12:50
joschoh no wait, apparently i have sufficient privileges to push to the master branch of reform-boundary-uboot13:00
joschminute: i hope i have not overstepped any boundaries by just having created a signed tag 2026-01-11 in reform-boundary-uboot13:00
joschtechnically it should not create problems as the only effective change compared to the last tag is the 512 alignment commit13:01
joschoh... no pun intended (bundary)13:02
chseems like a good thing to me13:02
joschch: oh hello13:02
joschdo you happen to know the proper way to identify which /dev/hidraw* device is the keyboard?13:03
chi thought that gets symlinked, ie udev should know?13:03
chalso doesnt reform-power-daemon "know"?13:04
chcant check at the moment13:04
joschch: yes, it uses /dev/input/by-id/usb-MNT_Pocket_Reform_Input_*hidraw13:05
joschbut that doesn't exist for classic reform with keyboard v413:05
chright and there is no similar thing?13:05
joschthe symlinks i have in /dev/input/by-id/ point to ../event*13:05
joschi was unable to find a simlar thing13:06
chhm13:06
joschwhat mechanism creates the hidraw symlink for the pocket reform keyboard?13:06
chshould finally order a keyboardv413:06
chi imagine udev does?13:06
chthere are no udev rules in reform-tools right?13:07
joschch: same offer to you that i already extended to elb: i have a board (without switches) here which i could mail you easily13:07
joschreform-tools has udev rules but only for imx8mq suspend wakeup13:08
chcam you check udevadm info (or whatever its called) for differing sttributes between pocket and standalone kbd?13:13
joschhere is a diff between pocket reform output and classic reform keyboard v4 output: https://paste.debian.net/hidden/5ffff63513:24
chhmm, kinda boring13:27
chjosch: so you only have the *-event-* symlinks in /dev/input/by-id?13:32
joschyes13:32
chi think /usr/lib/udev/rules.d/60-persistent-hidraw.rules is supposed to do it13:34
chmaybe you need to inspect the parent devices for differences, if any doesnt have ID_BUS or so13:36
joschhrm.. strange i don't have a file like that on Trixie and apt-file doesn't find anything matching persistent-hidraw.rules13:36
chudev: /usr/lib/udev/rules.d/60-persistent-hidraw.rules13:36
joschmy OS is too old it seems :)13:37
chwell that might be the problem then?13:37
chis your pocket on forky?13:37
joschindeed -- i shall check at home13:37
chi guess you can just copy the file into /etc13:37
joschno, everything on trixie except with kernel from forky13:37
chand see if that makes it work13:37
joschyup13:38
+ paperManu (~paperManu@146.71.9.156)13:41
+ bkeys (~Thunderbi@h69.128.19.98.dynamic.ip.windstream.net)13:46
joschokay, i think this is ready now but unfortunately the train is arriving so i'll finish it only tonight: https://source.mnt.re/reform/reform-tools/-/merge_requests/15614:14
joschlets also build some system images for testing this...14:14
joschda heck is going on here??? https://mister-muffin.de/p/ByeA.txt14:28
gordon1josch: do you have UART attached?14:32
joschnope14:32
josch(rk3588-dsi classic reform)14:32
gordon1i had this issue once, when usb uart chip for some reason started to generate those sysrq-like requests when usb wasn't attached14:32
joschoh wait, "serial attached" means something different for motherboard 3.014:33
gordon1i really want to know what UART condition kernel interprets like sysrq14:33
joschi had a usb pd charger attached but booted now without it14:34
gordon1josch: sort of, yes, i solved this issue by disconnecting the uart on dip-switches14:34
gordon1but since then i switched them back on and the issue didn't reappear14:34
joschoh interesting, good idea14:34
gordon1so shrug14:34
gordon1is you'll find any info about what uart condition treated as sysrq, please throw this info at me14:35
gordon1oh wait, i think i know how i "solved" the issue14:36
gordon1josch: do you have multiple console= params in your /proc/cmdline?14:37
joschro no_console_suspend cryptomgr.notests console=ttyS2,1500000 clk_ignore_unused cma=256M swiotlb=65535 console=tty114:37
gordon1i think i had both console=tty1 and console=ttyS2,150000014:37
gordon1and i removed the latter14:38
gordon1yeah14:38
joschokay, but i *want* to be able to connect via serial from time to time14:38
joschso i don't want to remove console=ttyS2,150000014:38
gordon1yeah i know, i'm just saying that the issue is probably still there even in my setup14:38
josch:(14:39
gordon1i just found a way to ignore it :)14:39
gordon1i have two u-boot menu items - one with console=tty1 and another with console=ttyS2, and when i attach serial i pick the latter one14:39
gordon1but it would be nice to find the culprit14:40
joschbrb bus14:40
+ chomwitt (~chomwitt@2a02:85f:9a0a:f200:1ac0:4dff:fedb:a3f1)14:40
amospallaI don' really know what a BREAK is, so I'm speaking blindly, but from  from https://docs.kernel.org/admin-guide/sysrq.html#how-do-i-use-the-magic-sysrq-key, it says "On the serial console (PC style standard serial ports only): You send a BREAK, then within 5 seconds a command key. Sending BREAK twice is interpreted as a normal BREAK."14:48
amospallaCan something being sending a "BREAK"?14:48
amospallaon the serial console, I mean. Maybe the serial port sending noise?14:51
gordon1right, so probably when UART is not connected - chip just releases lines and they float maybe? and then it just detect 0 for prolonged time and interprets it as BREAK14:52
gordon1i need to check that chip14:52
- bkeys (QUIT: Remote host closed the connection) (~Thunderbi@h69.128.19.98.dynamic.ip.windstream.net)14:55
+ bkeys (~Thunderbi@98.19.128.69)14:56
gordon1datasheet does not say what happens in self-powered configuration when usb is not connected15:02
gordon1it also mentions some "configuration utility", maybe there is something there15:02
gordon1alternatively just weak pullup on RX should do the job15:04
+ siviq (~siviq@user/siviq)15:05
- bkeys (QUIT: Remote host closed the connection) (~Thunderbi@98.19.128.69)15:13
+ bkeys (~Thunderbi@134.22.115.162)15:55
+ spew (~spew@user/spew)16:48
kcxtjosch: sorry for the late reply, could you clarify what the partition type you pasted is? I would personally suggest following the UAPI spec (including using the ESP type for the boot partition and setting the legacy bootable bit), that should cover all our bases and not cause any issues.16:55
joschkcxt: i fear i do not know more than you about the partition type used by debian-installer. I mainly wanted to find out how "wrong" it is.16:56
kcxtafaik u-boot doesnt actually care about the partition type and will try to boot from anything which has a filesystem it can read, the EFI subsystem at least creates automatic boot entries for every partition with a readable filesystem16:57
kcxtok i'll try and look up that GUID :D16:57
joschoh for *every* partition, thank you i thought it was important to have everything on the first partition16:59
kcxtjosch: the GUID you sent is described on the UAPI spec as "Generic Linux Data Partition", it predates the discoverable partition spec. I assume that the d-i uses it for any partitions you create that don't have a specific use17:02
- pomel0 (QUIT: Ping timeout: 240 seconds) (~pomel0@user/pomel0)17:02
+ pomel0 (~pomel0@user/pomel0)17:03
kcxtjosch: so it would make sense that setting the bootable bit causes it to use the ESP type GUID instead17:03
kcxtwhat does d-i use for the root partition? Ideally it would be the aarch64 root partition type or the generic root partition type17:04
kcxtbut yah in general GPT is a lot more sane across the board, assuming a recent u-boot things should all just work with EFI or extlinux with bootflow17:05
joschkcxt: i tested the automatic installation which creates three partitions with the latter containing luks+lvm17:05
joschall three partitions have the guid i sent17:05
joschyes, i saw the guid in the spec but it said it was somehow legacy so i interpreted it as "don't use"17:06
kcxtfwiw the uapi spec is meant to be an idealised best-practise, so a lot of stuff it describes as legacy is stuff that is still widely used XD17:07
kcxtthat said, the DPS in particular is one worth following17:08
kcxtit's definitely a bug if d-i doesn't use the ESP type for the boot partition, particularly if we plan to switch to EFI eventually, having the GPT already in place will save a lot of pain17:09
joschkcxt: got it, thank you!17:09
+ spew_ (~spew@user/spew)17:28
- spew (QUIT: Ping timeout: 252 seconds) (~spew@user/spew)17:29
- siviq (QUIT: Quit: Client closed) (~siviq@user/siviq)17:58
- pomel0 (QUIT: Ping timeout: 255 seconds) (~pomel0@user/pomel0)18:31
+ pomel0 (~pomel0@user/pomel0)18:31
- pomel0 (QUIT: Remote host closed the connection) (~pomel0@user/pomel0)18:32
+ pomel0 (~pomel0@user/pomel0)18:32
+ voltaire28 (~jlafon@28.162.2.93.rev.sfr.net)18:38
* spew_ -> spew19:08
+ paperManu_ (~paperManu@146.71.9.156)19:19
- chomwitt (QUIT: Ping timeout: 246 seconds) (~chomwitt@2a02:85f:9a0a:f200:1ac0:4dff:fedb:a3f1)19:29
- voltaire28 (QUIT: Ping timeout: 264 seconds) (~jlafon@28.162.2.93.rev.sfr.net)19:34
+ siviq (~siviq@user/siviq)19:56
+ chomwitt (~chomwitt@2a02:85f:9a0a:f200:1ac0:4dff:fedb:a3f1)20:34
- spew (QUIT: Quit: nyaa~) (~spew@user/spew)20:58
- pomel0 (QUIT: Ping timeout: 260 seconds) (~pomel0@user/pomel0)21:09
+ pomel0 (~pomel0@user/pomel0)21:12
- enwu (QUIT: Read error: Connection reset by peer) (~enwu@user/enwu)21:20
+ enwu (~enwu@user/enwu)21:20
minutejosch: that's fine @ boundary-uboot, had forgotten about that one!21:32
joschokay, i'm glad :)21:34
+ voltaire28 (~jlafon@28.162.2.93.rev.sfr.net)22:21
- cow321 (QUIT: Ping timeout: 244 seconds) (~deflated8@user/meow/deflated8837)22:24
elba serial break is a spacing condition held for longer than a character time (how much longer varies; I don't remember what it is for rs-232)22:32
elbEvery serial character is sent by sending a start bit (space), then the data for the character, and then a stop bit (mark; sometimes more than one).  This means that any time the line goes to space, you _know_ that at the end of the character you should return to mark, even if the character is all zeroes (space)22:34
elbnormally a receiving serial line pulls its receive pin to either balance (0V) or space (+V), and that's one way that a port can detect that someone has connected; the sending line will pull to mark for idle22:35
elbTTL serial is _often_ reverse-polarity (which is normal logic polarity), so mark is +V and space is 0V (RS-232 uses +/- and 0 is an ill-defined state), and the receiver should have a pull-down to space22:36
elbanyway, so to send a break, you just pull to zero for a ms or whatever22:36
elbmost serial terminal programs have a keystroke for that22:36
^alexa cereal break is when you drop your breakfast in your kitchen22:52
- Gooberpatrol66 (QUIT: Quit: Konversation terminated!) (~Gooberpat@user/gooberpatrol66)23:07
+ Gooberpatrol66 (~Gooberpat@user/gooberpatrol66)23:14

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!