vagrantc | so if i ordered a few things along with an RK3588 module ... are they going to wait till the RK3588 module is ready to ship? no strong thoughts either way ... | 00:09 |
---|---|---|
vagrantc | (as in, i *did* order a bunch of things with an RK3588 module) | 00:10 |
vagrantc | only to discover later that many of the things i ordered are now available though mouser and whatnot now.... | 00:11 |
- Jonas__ (QUIT: Ping timeout: 244 seconds) (~Jonas@45.134.79.119) | 00:11 | |
jfred | vagrantc: that's how my orders in the past have gone | 00:16 |
vagrantc | would not hurt me one bit to postpone working on that stuff a bit anyways... | 00:18 |
chartreuse | josch: > they are not even using sway at all. Except I do use sway, and the lock ups have occured with the screen blanked using swaylock/swayidle. Though the fault likely is occuring while it's been blank for a long time, not sure it's happening right as it turns off. Though that's really had to check besides just manually running the output * dpms off command | 00:23 |
josch | chartreuse: so you *do* use "output * dpms off" or not? | 00:29 |
chartreuse | Yes, I'm using the default (or at least was default) sway config as a base and have that swayidle line that turns the monitor off | 00:30 |
chartreuse | timeout 600 'swaymsg "output * dpms off"' \ | 00:31 |
- ptrc (QUIT: Remote host closed the connection) (~ptrc@ptrc.gay) | 00:31 | |
+ ptrc (~ptrc@ptrc.gay) | 00:32 | |
josch | chartreuse: "dpms off" hasn't been the default since commit c6659fb0f179b927fd95ec2876b87d5b40683244 | 00:32 |
josch | chartreuse: for my imx8mq, using "dpms off" was the cause for my lock-ups | 00:33 |
josch | replacing it with brightnessctl made the lock-ups completely go away | 00:33 |
chartreuse | Just turning the backlight off with that or does that also do a dpms ? | 00:33 |
josch | chartreuse: https://source.mnt.re/reform/reform-tools/-/blob/main/etc/skel/.config/sway/config?ref_type=heads#L49 | 00:34 |
josch | chartreuse: i cannot tell you what is going on but using brightnessctl instead of "dpms off" made my imx8mq stable. I essential had it on 24/7 because suspend didn't work on my unit. | 00:34 |
chartreuse | Ah okay, I'll give it a try, thought the lockups are so rare it's hard to really see | 00:34 |
chartreuse | Yeah I typically am 24/7 on, suspend works on mine but is missing the wifi after resume (doesn't appear in lspci anymore) | 00:35 |
chartreuse | I believe you can combine the --save option with a new brightness instead of two commands on brightnessctl, since it specifies saving the previous brightness | 00:36 |
chartreuse | Yeah that does work to save a command `brightnessctl -s set 0` saves and sets to 0 | 00:37 |
josch | thank you, adjusted locally | 00:38 |
chartreuse | I'll see if that works for fixing the occasional lockup for me, won't really know for a few days+ | 00:39 |
josch | of course | 00:39 |
noam_ | josch: :O That might be the issue I've seen on my AMD64 system! | 00:46 |
noam_ | tanks! | 00:46 |
josch | noam_: what issue? | 00:47 |
noam_ | Not coming back up after dpms off | 00:47 |
josch | that issue is not reform-specific?? o0 | 00:48 |
noam_ | might not be | 00:48 |
noam_ | I've been having it consistently under Sway for a long while on my Gentoo Ryzen box | 00:48 |
* jackhill -> KM4MBG | 00:48 | |
noam_ | Though... actually, I've had that issue when turning the monitor off/on too :/ | 00:48 |
noam_ | and I think some of those were timed such that there's no way swayidle was runningt | 00:49 |
noam_ | TBH I might have a bad motherboard | 00:49 |
- colinsane (QUIT: Quit: bye) (~colinunin@97-113-150-69.tukw.qwest.net) | 01:00 | |
+ colinsane (~colinunin@97-113-150-69.tukw.qwest.net) | 01:03 | |
- vagrantc (QUIT: Ping timeout: 252 seconds) (~vagrant@2600:3c01:e000:21:7:77:0:50) | 01:28 | |
- mjw (QUIT: Ping timeout: 244 seconds) (~mjw@gnu.wildebeest.org) | 02:00 | |
+ GNUmoon (~GNUmoon@gateway/tor-sasl/gnumoon) | 02:02 | |
- mtm (QUIT: Ping timeout: 272 seconds) (~textual@c-71-228-84-213.hsd1.fl.comcast.net) | 02:03 | |
+ mtm (~textual@c-71-228-84-213.hsd1.fl.comcast.net) | 02:06 | |
* KM4MBG -> jackhill | 02:17 | |
- dodo (QUIT: Server closed connection) (~dodo@user/dodo) | 04:31 | |
+ dodo (~dodo@user/dodo) | 04:31 | |
- bkeys (QUIT: Remote host closed the connection) (~Thunderbi@45.134.140.153) | 04:49 | |
- amospalla (QUIT: Server closed connection) (~jordi@user/amospalla) | 05:35 | |
+ amospalla (~jordi@user/amospalla) | 05:35 | |
- erle (QUIT: Server closed connection) (~erle@user/erle) | 05:36 | |
+ erle (~erle@2a02:8109:da01:6400::1b36) | 05:37 | |
- erle (QUIT: Changing host) (~erle@2a02:8109:da01:6400::1b36) | 05:37 | |
+ erle (~erle@user/erle) | 05:37 | |
- Bertl (QUIT: Server closed connection) (herbert@IRC.13thfloor.at) | 06:37 | |
+ Bertl (herbert@IRC.13thfloor.at) | 06:37 | |
- mtm (QUIT: Ping timeout: 248 seconds) (~textual@c-71-228-84-213.hsd1.fl.comcast.net) | 06:49 | |
+ mtm (~textual@c-71-228-84-213.hsd1.fl.comcast.net) | 06:50 | |
- josch (QUIT: Server closed connection) (~josch@mister-muffin.de) | 08:17 | |
+ josch (~josch@mister-muffin.de) | 08:17 | |
- ex-parrot (QUIT: Quit: _b) (~fincham@user/ex-parrot) | 08:51 | |
+ ex-parrot (~fincham@user/ex-parrot) | 08:51 | |
- GNUmoon (QUIT: Remote host closed the connection) (~GNUmoon@gateway/tor-sasl/gnumoon) | 09:43 | |
minute | noam_: my intel i9 box also was for a while freezing every night when left on at the office... bios/fw updates helped iirc | 10:38 |
minute | violet: yes, exactly, sorry for getting back to you only now | 10:39 |
+ mjw (~mjw@gnu.wildebeest.org) | 12:18 | |
- blast007 (QUIT: Server closed connection) (~blast@user/blast007) | 12:45 | |
+ blast007 (~blast@user/blast007) | 12:45 | |
- whereiseveryone (QUIT: Server closed connection) (206ba86c98@2a03:6000:1812:100::2e4) | 13:22 | |
+ whereiseveryone (206ba86c98@2a03:6000:1812:100::2e4) | 13:22 | |
minute | ok i found the issue @ a311d initramfs display being blank | 13:28 |
minute | echo 1 > /sys/devices/platform/soc/ffd00000.bus/ffd07000.dsi/ffd07000.dsi.0/backlight/ffd07000.dsi.0/bl_power | 13:28 |
minute | i remember this somehow being a problem in the past and some nonsense heuristic in the kernel for deriving the initial value of bl_power, but i remember that had to do with pwm, and we don't have pwm here | 13:29 |
minute | ah, it's probably my fault, looks like i removed backlight_enable() in our patched jdi panel driver | 13:36 |
- mjw (QUIT: Ping timeout: 272 seconds) (~mjw@gnu.wildebeest.org) | 13:38 | |
* Guest9296 -> mjw | 13:42 | |
[tj] | minute: are the crowdsupply shipping estimates set by you or by them? I've always wondered where they actually come from | 13:43 |
chartreuse | Been a bit so just want to say jack detection has been working great for me after replacing the pullup on the jack detect pin with a 220k ohm (120k-150k would work too) | 13:43 |
minute | [tj]: by them | 13:43 |
minute | chartreuse: thanks a lot! i will include that in MB2.6 | 13:44 |
chartreuse | I ordered some SMD ones so I'll replace my bodged on THT one with a proper 0603 one next time I take the motherboard out | 13:44 |
chartreuse | Just needs to be a value of pullup such that the voltage divider with it and the pull down on the headphone line you get less than 0.3 * 3.3v on the pin | 13:46 |
minute | mhm | 13:46 |
- kensanata (QUIT: Server closed connection) (~alex@user/kensanata) | 13:47 | |
+ kensanata (~alex@user/kensanata) | 13:47 | |
chartreuse | I'll write up a forum post later if anyone else wants to do the mod, though it's a shame that the dtb can't really be updated in the main package since it may unreliably flip for people without the mod | 13:47 |
chartreuse | Might just make a version of it like how there's an HDMI and non-HDMI one for the IMX8MQ | 13:47 |
minute | ah, currently the voltage divider is created by 2x 47k? | 13:48 |
minute | so i'm changing R144 to 220k | 13:49 |
chartreuse | Yeah, there's a 47k pullup on the pin, and a 47k pull down when the jack is closed | 13:49 |
minute | got it | 13:49 |
chartreuse | So it *might* work since it's a schmidt trigger input and the capacitor might sink enough to pulse it low, but it's not the best to sit in the middle region | 13:50 |
chartreuse | I think I just went 220k because it was the most common value I had. The minimum would be a bit less than 120k, 120k there gives 0.93v with a 0.99v lower threshold, 150k is 0.79v, and 220k is 0.58v | 13:52 |
chartreuse | And yeah it was R144 on the 2.0 motherboard and sounds like that designator hasn't changed | 13:53 |
chartreuse | I'll also peek into the dtb for the other cpus, I presume they can be made to work as well with the jack detect interrupt going to a gpio | 13:55 |
- mtm (QUIT: Ping timeout: 272 seconds) (~textual@c-71-228-84-213.hsd1.fl.comcast.net) | 14:03 | |
- Sario (QUIT: Quit: Updates) (sario@libera/staff/owl/sario) | 14:03 | |
+ mtm (~textual@c-71-228-84-213.hsd1.fl.comcast.net) | 14:05 | |
+ Sario (sario@libera/staff/owl/sario) | 14:07 | |
- chartreuse (QUIT: Server closed connection) (~chartreus@S0106908d78501d1d.cg.shawcable.net) | 14:33 | |
+ chartreuse (~chartreus@S0106908d78501d1d.cg.shawcable.net) | 14:33 | |
+ GNUmoon (~GNUmoon@gateway/tor-sasl/gnumoon) | 14:33 | |
minute | pocket/a311d emmc uboot is hindered by: "unable to select a mode : -5" when trying mmc dev 1, but it works the 3rd time | 14:36 |
josch | o0 | 14:40 |
josch | i heard flashing u-boot to your a311d emmc could soft-brick your device -- glad to hear it only gets heisen-bricked :) | 14:44 |
- dodo (QUIT: Remote host closed the connection) (~dodo@user/dodo) | 14:46 | |
+ dodo (~dodo@user/dodo) | 14:47 | |
- skipwich (QUIT: Server closed connection) (~skipwich@user/skipwich) | 14:49 | |
+ skipwich (~skipwich@user/skipwich) | 14:53 | |
[tj] | took a month and a new board, the pocket reform images won't boot out of hte box on the olimex som/evb | 14:59 |
minute | [tj]: probably different memory? | 15:01 |
[tj] | oh I didn't try a stock image, but one with the olimex uboot | 15:01 |
[tj] | we think the sd card slot failed on my first board so it might have been that the pocket image u-boot wasn't the issue | 15:02 |
[tj] | the som is only 4GB | 15:02 |
minute | [tj]: dram training parameters are chip specific | 15:08 |
minute | so only if you're very lucky they used the same chip as boundary devices | 15:08 |
[tj] | ah | 15:11 |
[tj] | that makes a lot of sense and is going to make creating imx8mp images a nightmare | 15:11 |
[tj] | I guess impossible | 15:11 |
+ bkeys (~Thunderbi@45.134.140.153) | 15:14 | |
[tj] | I think I remember that the dram training is part of the boot blob along with the secure firmware | 15:17 |
[tj] | but the training is open source and secure firmware isn't | 15:17 |
- ch (QUIT: Server closed connection) (~ch@user/meow/ch) | 15:27 | |
+ ch (~ch@user/meow/ch) | 15:27 | |
- ehenter (QUIT: Server closed connection) (~ehenter@81-175-159-24.bb.dnainternet.fi) | 15:48 | |
minute | [tj]: yes the blob needs to be given parameters about the dram timing and rows/cols/banks etc | 15:48 |
+ ehenter (~ehenter@81-175-159-24.bb.dnainternet.fi) | 15:48 | |
minute | [tj]: board specific code in uboot does that | 15:48 |
[tj] | I thought it was prefixed before the application (u-boot) https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8-Boot-process-and-creating-a-bootable-image/ta-p/1101253 | 16:01 |
[tj] | that is imx8 (no mp), but I didn't find mp specific docs | 16:01 |
minute | imx8 is totally different from imx8m and imx8mp | 16:09 |
minute | it's like a very different chip architecture | 16:09 |
minute | nice, my pocket display fix in initramfs works | 16:16 |
- cwebber (QUIT: Server closed connection) (~Christine@user/cwebber) | 16:19 | |
- murphnj (QUIT: Server closed connection) (~murph@user/murphnj) | 16:20 | |
+ murphnj (~murph@user/murphnj) | 16:20 | |
+ cwebber (~Christine@user/cwebber) | 16:23 | |
[tj] | minute: thanks for the help, I'm getting some support from the FreeBSD foundation to do a port to imx8mp ( and the pocket reform) | 16:38 |
minute | [tj]: oh wow, nice | 16:38 |
[tj] | I don't think I would have landed on there being big architectural differences inside the imx8 family | 16:38 |
minute | [tj]: i think the 8mplus is somewhat related to mini (8mm) and nano (8mn), imx8 is a lot older and distinct, 8m is a predecessor of plus but they changed a lot of stuff there as well, especially everything about power domains | 16:39 |
minute | and display pipelines (but lcdif remains) | 16:40 |
minute | 8x and ulp i know little about | 16:40 |
[tj] | do you have a feeling for how far it is from mq? We already have some mq drivers, it would be nice to be able to special case them rather than rewrite entirely | 16:41 |
[tj] | there is already an mq clock driver which is going to be my first stop once I have a sensible image | 16:41 |
[tj] | I'm booting from a the olimex uboot on an sd card and a freebsd usb installer right now | 16:41 |
minute | [tj]: to get an initial feeling i guess maybe compare imx8mq.dtsi and imx8mp.dtsi in linux | 16:51 |
minute | it's interesting, some peripherals are at the same address, like gpio | 16:51 |
minute | actually a lot of stuff seems to be at the same addresses | 16:52 |
[tj] | great, thank you | 16:55 |
- eery (QUIT: Server closed connection) (~eery@172.97.103.152) | 17:20 | |
+ eery (~eery@172.97.103.152) | 17:20 | |
minute | having some bizarre issues updating uboot on emmc on a311d... the old version just sticks around | 17:59 |
minute | it seems to load uboot from mmcblk1 and not from mmcblk1boot0 | 18:01 |
+ vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:50) | 18:04 | |
minute | swivel: btw there was a glitch in the shop, we actually have basecaps in stock | 18:04 |
minute | swivel: https://shop.mntre.com/products/mnt-logo-basecap | 18:05 |
josch | i think i need to get the base cap too -- the tshirt was great quality, really good fit and the fabric feels great on the skin | 18:17 |
- cobra_ (QUIT: Ping timeout: 258 seconds) (~cobra@user/Cobra) | 18:45 | |
+ cobra (~cobra@user/Cobra) | 18:48 | |
jfred | The caps are also very high quality, love that it's embroidered rather than printed | 19:10 |
- sir-photch (QUIT: Remote host closed the connection) (~m-hy5poy@static.93.70.235.167.clients.your-server.de) | 19:15 | |
+ sir-photch (~m-hy5poy@static.93.70.235.167.clients.your-server.de) | 19:17 | |
+ Jonas__ (~Jonas@45.134.79.119) | 19:26 | |
Jonas__ | Do anyone here knows if the RK3588 could be bought elsewhere and when the adapter board for the pocket is ready one can get one from MNT shop? | 19:35 |
Jonas__ | Or will the two will be undled as it it the case for the Reform (https://shop.mntre.com/products/mnt-reform-rcore-rk3588-processor-module)? | 19:36 |
Jonas__ | (I mean buying the RK3588 SoM now and getting the adapter for the Pocket later when it will be ready) | 19:37 |
+ gustav28 (~gustav@c-1134524e.019-141-67626730.bbcust.telenor.se) | 19:43 | |
noam_ | I need to see if there's a microcenter nearby... | 19:52 |
noam_ | Hoping to mod the speakers today :) | 19:52 |
minute | Jonas__: the rk3588 module/adapter for the pocket will be the same as for the reform | 20:02 |
+ mark_ (~mjw@gnu.wildebeest.org) | 20:15 | |
- mjw (QUIT: Killed (osmium.libera.chat (Nickname regained by services))) (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 20:15 | |
* mark_ -> mjw | 20:15 | |
+ Guest8052 (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 20:15 | |
- hairu (QUIT: Remote host closed the connection) (m-uotkmd@user/hairu) | 20:27 | |
+ hairu (m-uotkmd@user/hairu) | 20:28 | |
swivel | minute: thanks! | 20:36 |
+ Jonas___ (~Jonas@82-65-231-86.subs.proxad.net) | 20:46 | |
- Jonas__ (QUIT: Ping timeout: 258 seconds) (~Jonas@45.134.79.119) | 20:49 | |
bkeys | minute, josch: Are the options in https://source.mnt.re/reform/reform-debian-packages/-/blob/main/linux/config?ref_type=heads all that is needed to get the hardware working? Or is there some other option implicitly enabled? | 21:44 |
minute | bkeys: those are the ones on top of the debian defaults | 21:45 |
bkeys | Do you have the debian defaults handy? Although thinking about it, they are probably not radically different than the Fedora defaults | 21:45 |
bkeys | Especially given the fedora defaults at least boots | 21:45 |
minute | bkeys: what are you currently struggling with, i.e. what is failing? | 21:46 |
bkeys | Hardware isn't failing, I was trying to find out with how Fedora builds things how the kernel configuration is set up because a lot of stuff gets generated; I found out how to get it to generate specific configs now, theoretically I solved the issue but I wanted to make sure I have good configs | 21:46 |
bkeys | I'll try default Fedora options + Reform options and have the Reform options supercede any contradictions | 21:47 |
bkeys | The last couple days have been learning about how the Fedora kernel gets built, nothing really with the Reform stuff. | 21:48 |
bkeys | In the end instead of maintaining a fork of the kernel source, I'll have a python script that acts on a cloned repo of the fedora dist-git which will apply patches and in the end create src.rpms that can be uploaded to copr | 21:49 |
bkeys | Alright, I'll kick off generating the srpm now that it's Fedora defaults with Reform config superceding | 21:55 |
- hairu (QUIT: Remote host closed the connection) (m-uotkmd@user/hairu) | 22:01 | |
+ hairu (m-uotkmd@user/hairu) | 22:04 | |
mtm | minute: new keyboard just arrived, thanks for the prompt delivery! My Pocket is now working as intended | 22:13 |
minute | bkeys: got it | 22:14 |
minute | mtm: yay, great to hear! | 22:14 |
- gustav28 (QUIT: Quit: Quit) (~gustav@c-1134524e.019-141-67626730.bbcust.telenor.se) | 22:15 | |
mtm | I'm enjoying the Pocket so much I might just put the rk3588 in it and move the Pocket SoM to my Reform | 22:17 |
- cow321 (QUIT: Remote host closed the connection) (~deflated8@user/meow/deflated8837) | 22:19 | |
+ cow321 (~deflated8@user/meow/deflated8837) | 22:20 | |
josch | bkeys: you can get the effective kernel config on a Debian system by looking into /boot/config-$(uname -r) so you can effectively extract it from the .deb packages on the MNT mirror like this: | 22:20 |
josch | curl --silent https://mntre.com/reform-debian-repo/pool/main/l/linux/linux-image-6.9.9-mnt-reform-arm64_6.9.9-1%2Breform20240717T114508Z_arm64.deb | dpkg-deb --fsys-tarfile - | tar --to-stdout -x ./boot/config-6.9.9-mnt-reform-arm64 | 22:20 |
mtm | now I just need to hack on the keyboard firmware to make the layout more programmer friendly (the limitations of USB-HID are particularly annoying when you want to assign a character that only exists on a shifted key, say '{' , to a lkey on a layer) | 22:20 |
vkoskiv | Weird, the upower service on my reform is disabled for some reason | 22:21 |
vkoskiv | But waybar still manages to get a time to empty estimate from... somewhere anyway? :D | 22:21 |
vkoskiv | Linux is very confusing. | 22:21 |
josch | mtm: for a programmer friendly layout, i'm using https://en.wikipedia.org/wiki/Neo_(keyboard_layout) | 22:21 |
vkoskiv | My battery monitor thing hooks into dbus for the UPower events, but that whole interface seems to be gone for some reason | 22:22 |
josch | mtm: the '{' key is directly on the home-row under my middle finger | 22:22 |
mtm | josch: how did you set that key on the layer using the reform firmware? I thought it could only handle simple HID constants | 22:24 |
vkoskiv | dbus is supposed to start that service, but I guess it didn't do that for some reason | 22:25 |
josch | mtm: this is not handled by the keyboard firmware but just a regular linux keyboard layout as far as xkeyboard-config is concerned | 22:25 |
mtm | that works in the console as well? | 22:26 |
josch | vkoskiv: waybar does these computations on its own: https://github.com/Alexays/Waybar/blob/HEAD/src/modules/battery.cpp#L546 | 22:28 |
josch | mtm: i'd give you an answer quickly but gitlab is very, very slow | 22:31 |
mtm | heh | 22:31 |
mtm | I've already changed my layout to a modified Colmak. Trying to get the various bracket types onto the home row on the second layer mostly worked. The exception was '{' and '}' which in HID-land only exist on shifted keys (supposedly they also exist unshifted on as 'keypad' codes but those are ignored) | 22:34 |
josch | mtm: okay, whatever it should be part of the xkb-data package, yes | 22:34 |
josch | mtm: so yes, it works transparently on the terminal, in sway in desktops environments etc | 22:34 |
josch | i'm typing my luks passphrase in that layout, for example | 22:35 |
mtm | alright will dig into it | 22:35 |
mtm | just assumed that those things were all X11 related based on the names :) | 22:35 |
josch | mtm: seems i can already select colemak: https://mister-muffin.de/p/4fUW.png | 22:37 |
josch | mtm: the layout are maintained in the package xkeyboard-config but are used by others as well | 22:38 |
josch | mtm: https://forum.colemak.com/topic/2641-submitting-colemakdh-to-xkeyboardconfig/ | 22:38 |
josch | mtm: the data in xkeyboard-config is used by console-setup for example | 22:38 |
mtm | thanks, checking it out now | 22:38 |
josch | that's how i get to type my luks passphrase in the linux console with my layout | 22:39 |
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata) | 22:40 | |
+ kensanata (~alex@user/kensanata) | 22:40 | |
mtm | josch: one last thing before I start hacking on the XKB-related side of things; do these changes only affect the built-in USB keyboard and not any external USB keyboard? Want to make sure I have a way to fix things when I inevitably bork it up | 22:56 |
noam_ | Hypothetical: how safe is it to hotswap the cells? | 22:57 |
noam_ | er | 22:57 |
josch | mtm: they affect any input device, so if i attach a usb keyboard to my reform it will have the same keymap | 22:57 |
noam_ | Terrible question. Lemme try again lol | 22:57 |
noam_ | How safe is it to e.g. disconnect one of the _packs_ by removing the cable? | 22:57 |
josch | mtm: but this is also because in my ~/.config/sway/config.d/input I have: input * { | 22:57 |
josch | mtm: i could replace the * by a specific device to have different keyboard layout for different devices | 22:58 |
vagrantc | noam_: i am going to make a wild guess and say "not at all safe" | 22:58 |
noam_ | My educated suspicion is "proooobbly okay" | 22:59 |
josch | noam_: did it several times, machine survived and kept running *if* plugged into the wall power at the same time | 22:59 |
noam_ | josch: I know someone runs their Reform with just one pack full-time | 22:59 |
vagrantc | they also had to change the firmware to support that, no? | 22:59 |
josch | noam_: yes, that would be dirk eibach | 22:59 |
noam_ | vagrantc: I wasn't aware of that, but plausible | 23:00 |
noam_ | I'm not opposed to modding the firmware though | 23:00 |
josch | noam_: wait, you want to disconnect the battery pack without the reform being plugged in? | 23:00 |
noam_ | no, I want to disconect _one_ battery pack :) | 23:00 |
noam_ | to hotswap it :D | 23:00 |
vagrantc | some people live more dangerously than others | 23:00 |
josch | noam_: sure, but your reform is off while you do that, right? | 23:00 |
noam_ | NO | 23:00 |
noam_ | No* | 23:00 |
josch | you can do that | 23:00 |
noam_ | I'm thinking of replacing the acrylic bottom | 23:01 |
josch | but your reform will turn off :) | 23:01 |
noam_ | Hmmmm. Because of the voltage drop? | 23:01 |
noam_ | ...oh! | 23:01 |
noam_ | because it assumes four dead cells, right | 23:01 |
noam_ | okay, yeah, going to need firmware changes for this | 23:01 |
mtm | ah, so this will render all my external mechanical keyboards a mess. They are configured as Colmak variants in their firmware, so the keycodes won't line up with what the XKB stuff is expecting | 23:01 |
noam_ | I'm thinking of replacing the bottom with basically three pieces | 23:01 |
josch | noam_: dirk also needed hardware changes to make this work | 23:01 |
noam_ | josch: I'm intending some ;) | 23:01 |
noam_ | I want to basically split the protected battery board into two pieces, so that I can swap in a _pack_ | 23:02 |
noam_ | and have it slide out the bottom | 23:02 |
josch | mtm: people usually switch between different keyboard layouts without flashing keyboard firmware ;) | 23:02 |
mtm | heh, yeah but I can plug my keyboard into any machine and have my layout | 23:03 |
josch | mtm: only if the other end always has the same layout configured, no? | 23:04 |
mtm | very handy with my work machines | 23:04 |
josch | if one machine has qwerty configured and the other has qwertz then the scancodes that the custom keyboard sends will not be able to send the same keys on both machines | 23:05 |
mtm | nah, works everywhere: it's just sending the USB-HID codes that I have mapped in the firmware, the other end has no idea where my physical keys are | 23:05 |
vagrantc | that's why you didn't include a camera on the mnt/reform! | 23:06 |
mtm | I mean I haven't tried using them where the computer is expecting qwertz | 23:06 |
mtm | but wouldn't a physical qwertz keyboard send a KEY_Z keycode over USB when the Z key is pressed? | 23:09 |
josch | mtm: you probably never need to deal with your keyboards sending funny letters like ẞ, ü, ö, or ä? ;) | 23:09 |
mtm | I guess that's the difference between scancodes and keycodes | 23:10 |
mtm | very rarely (I used to live in Zürich 20 years ago) | 23:10 |
josch | or é, ẽ, ɇ... | 23:10 |
josch | mtm: if what you type is mostly ascii, i guess your approach works fine | 23:12 |
mtm | but its true that that is so rare that I'm going to remap the AGR key on my Pocket to another shift key | 23:12 |
mtm | the way keyboard input is handled today is a product of the past: the underlying USB HID protocol is actually pretty limiting (some of that because of needing to handle even older standards like PS/2). I'd love a way to just send the raw matrix scans (debounced of course) over the wire and a driver on the OS side deal with it | 23:18 |
mtm | could actually process the matrix scans and then pump the results into the uinput module https://www.kernel.org/doc/html/v4.12/input/uinput.html | 23:20 |
josch | mtm: maybe this is interesting to you: https://community.mnt.re/t/remapping-keyboard-without-firmware-modification-adding-sysrq-key/687 | 23:22 |
+ rah (rah@verain.settrans.net) | 23:26 | |
rah | is there a limit on the current that a particular USB port on the MNT Reform 2 can provide? | 23:26 |
rah | or is there a total limit? | 23:26 |
rah | for all ports? | 23:27 |
noam_ | Yes | 23:27 |
noam_ | I don't know what it is | 23:27 |
noam_ | offhand | 23:27 |
noam_ | but eveery USB port has a limit :) | 23:27 |
noam_ | Normal limit is like 2A IIRC | 23:28 |
noam_ | These maaaay be more, but I wouldn't rely on it without checking | 23:28 |
mtm | josch: that's great info, thanks | 23:29 |
- Jonas___ (QUIT: Ping timeout: 256 seconds) (~Jonas@82-65-231-86.subs.proxad.net) | 23:47 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!