| vkoskiv | I've been studying the trackpad firmware to try and understand how the 3-finger drag is implemented. I don't quite understand how. | 00:25 |
|---|---|---|
| vkoskiv | I want to implement a short delay, such that one can drag, lift fingers briefly and continue the same drag. | 00:26 |
| vkoskiv | i.e. the same behaviour as a Mac trackpad with 3-finger-drag enabled in accessibility settings. | 00:26 |
| vkoskiv | I feel like that's a very intuitive way for it to work, if the timings are correctly set up. | 00:26 |
| vkoskiv | josch: FYI: apt upgrade is failing. 404-ing on the linux 5.19 pkg, I think. | 00:34 |
| jfred | Oh crap, I just got back to my Reform after leaving it running for a bit and it was powered off and very hot near the barrel plug x.x | 00:46 |
| jfred | I think something failed violently… | 00:47 |
| - ggoes (QUIT: Ping timeout: 264 seconds) (~gregf@fsf/staff/ggoes) | 00:51 | |
| + ggoes (~gregf@fsf/staff/ggoes) | 01:27 | |
| - mtm (QUIT: Ping timeout: 268 seconds) (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 02:03 | |
| - GNUmoon2 (QUIT: Ping timeout: 258 seconds) (~GNUmoon@gateway/tor-sasl/gnumoon) | 02:40 | |
| + GNUmoon2 (~GNUmoon@gateway/tor-sasl/gnumoon) | 02:53 | |
| + reform7965 (~masop@67-43-243-35.fidnet.com) | 03:09 | |
| * reform7965 -> morrig | 03:09 | |
| morrig | i have a question | 03:34 |
| morrig | is the system imager main updated to v3? | 03:34 |
| morrig | man its still not working. Once my git account is approved maybe i will be able to pull an imager version that works for me | 03:50 |
| - morrig (QUIT: Read error: Connection reset by peer) (~masop@67-43-243-35.fidnet.com) | 03:54 | |
| + reform25542 (~masop@67-43-243-35.fidnet.com) | 03:55 | |
| * reform25542 -> morrig | 03:55 | |
| morrig | accidentally popped out the sd card | 03:55 |
| morrig | oops | 03:55 |
| - buckket (QUIT: Read error: Connection reset by peer) (~buckket@pdp8.buckket.org) | 04:05 | |
| + mtm (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 04:08 | |
| - GNUmoon2 (QUIT: Remote host closed the connection) (~GNUmoon@gateway/tor-sasl/gnumoon) | 05:05 | |
| + GNUmoon2 (~GNUmoon@gateway/tor-sasl/gnumoon) | 05:06 | |
| - vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:7:77:0:20) | 05:17 | |
| josch | morrig: yes, the main branch is sysimage-v3 | 05:41 |
| josch | morrig: you do not need an account to clone the git repo | 05:41 |
| josch | morrig: just run: git clone https://source.mnt.re/reform/reform-system-image.git | 05:41 |
| - vkoskiv (QUIT: Ping timeout: 240 seconds) (~vkoskiv@89-166-62-97.bb.dnainternet.fi) | 07:28 | |
| + vkoskiv (~vkoskiv@89-166-62-97.bb.dnainternet.fi) | 07:30 | |
| morrig | getting the same issure | 07:30 |
| morrig | issue | 07:30 |
| morrig | E: Failed to fetch https://mntre.com/reform-debian-repo/pool/main/l/linux/linux-image-5.19.0-reform2-arm64_5.19.6-1%2breform1_arm64.deb 404 Not Found [IP: 91.250.115.15 443] | 07:30 |
| morrig | E: Failed to fetch https://mntre.com/reform-debian-repo/pool/main/l/linux/linux-image-arm64_5.19.6-1%2breform1_arm64.deb 404 Not Found [IP: 91.250.115.15 443] | 07:30 |
| morrig | E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? | 07:30 |
| morrig | is it just internet dropping? | 07:31 |
| josch | morrig: this problem is expected. The new kernel was removed because others reported that installing it will make your system unbootable. | 07:35 |
| josch | Somebody [tm] has to find the time to bisect 5.18 -> 5.19 and figure out what change broke stuff again... :( | 07:36 |
| josch | Another possibility is, that I made a mistake in rebasing the 5.18 patches onto 5.19. | 07:37 |
| - GNUmoon2 (QUIT: Read error: Connection reset by peer) (~GNUmoon@gateway/tor-sasl/gnumoon) | 08:46 | |
| + GNUmoon2 (~GNUmoon@gateway/tor-sasl/gnumoon) | 08:46 | |
| vkoskiv | no worries, I appreciate the steps taken to not make my system unbootable for the time being :D | 08:59 |
| vkoskiv | josch: won't bisecting the kernel and testing it take a really long time? or is there some special trick for that? | 09:00 |
| - morrig (QUIT: Ping timeout: 260 seconds) (~masop@67-43-243-35.fidnet.com) | 09:04 | |
| minute | vkoskiv: it takes a really long time, yep. | 09:18 |
| - jjbliss (QUIT: Remote host closed the connection) (~jjbliss@1464766-static.elnsmiaa.metronetinc.net) | 10:00 | |
| + jjbliss (~jjbliss@1464766-static.elnsmiaa.metronetinc.net) | 10:13 | |
| + morrig (~masop@67-43-243-35.fidnet.com) | 11:25 | |
| - morrig (QUIT: Remote host closed the connection) (~masop@67-43-243-35.fidnet.com) | 11:46 | |
| josch | vkoskiv: it gets faster the closer the commits you are testing become because less stuff needs to be rebuilt. I found that I spent most time on rebasing the patches though because different commits need a different patchset... | 11:53 |
| minute | josch: in reform-debian-packages, is there a trick to only build the linux package for testing/debugging? | 12:04 |
| josch | minute: you want to investigate the current failure? | 12:04 |
| minute | josch: does it make sense? or are you already on it? | 12:05 |
| josch | I usually just run: env --chdir=linux BUILD_ARCH=amd64 HOST_ARCH=arm64 BASESUITE=unstable OURSUITE=reform ./build.sh | 12:05 |
| josch | minute: To debug it, I would not use the Debian package but build from upstream linux git, because a) we want to make sure that the bug is not due to some Debian stuff, b) we want to make sure that the bug is not due to some module loading (thus directly including the imx stuff into the kernel image instead of building modules) c) the build times of the Debian kernel are waaaay to long to be useful for | 12:06 |
| josch | repeated debug builds | 12:06 |
| minute | ah ok | 12:06 |
| josch | minute: I don't know when I will find time to do the bisecting myself this week -- if at all | 12:06 |
| josch | August has been pretty stressful because the KiTa was closed the whole month so I have to catch up with a lot of work from August that I didn't get to finish... :/ | 12:07 |
| minute | oh, i see ;/ sounds stressful indeed | 12:07 |
| josch | children and reform do not really mix (yet) ;) | 12:08 |
| minute | i am most comfortable building a monolithic kernel for bisecting, i hope it will show the same problems like loading modules later | 12:08 |
| josch | i think that reproducing the problem with a monolithic kernel is the way to go. In the worst case, if the monolithic 5.19 doesn't show the same problem, then it must be due to some packaging/module loading issues... | 12:09 |
| minute | ok! | 12:09 |
| + Gooberpatrol_66 (~Gooberpat@user/gooberpatrol66) | 12:35 | |
| + aphistic_ (sid347194@id-347194.ilkley.irccloud.com) | 12:36 | |
| - mjw (QUIT: Killed (NickServ (GHOST command used by wielaard!~mjw_@2001:1c06:2488:1400:9e5c:8eff:fe8f:a440))) (~mark@gnu.wildebeest.org) | 12:37 | |
| * wielaard -> mjw | 12:37 | |
| - ggoes (QUIT: *.net *.split) (~gregf@fsf/staff/ggoes) | 12:44 | |
| - qwer (QUIT: *.net *.split) (~qwer@78-80-108-59.customers.tmcz.cz) | 12:44 | |
| - aphistic (QUIT: *.net *.split) (sid347194@id-347194.ilkley.irccloud.com) | 12:44 | |
| - chartreuse (QUIT: *.net *.split) (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 12:44 | |
| - pinoaffe (QUIT: *.net *.split) (~pinoaffep@2a01:4f9:c010:a00b:1337:1337:11be:10) | 12:44 | |
| - Gooberpatrol66 (QUIT: *.net *.split) (~Gooberpat@user/gooberpatrol66) | 12:44 | |
| * aphistic_ -> aphistic | 12:44 | |
| + buckket (~buckket@pdp8.buckket.org) | 12:49 | |
| + mark__ (~mark@gnu.wildebeest.org) | 12:49 | |
| + ggoes (~gregf@fsf/staff/ggoes) | 12:49 | |
| + qwer (~qwer@78-80-108-59.customers.tmcz.cz) | 12:49 | |
| + chartreuse (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 12:49 | |
| + pinoaffe (~pinoaffep@2a01:4f9:c010:a00b:1337:1337:11be:10) | 12:49 | |
| - buckket (QUIT: Client Quit) (~buckket@pdp8.buckket.org) | 12:52 | |
| + buckket (~buckket@pdp8.buckket.org) | 12:57 | |
| minute | josch: after some prep, building the first kernel now. | 13:02 |
| josch | Uff... much success! | 13:08 |
| josch | I hope you find the culprit quickly. | 13:08 |
| minute | thanks! | 13:09 |
| minute | i'm just doing this on the side while working on imx8mplus adapter | 13:09 |
| josch | The imx8mplus would be another solution to the "have both wifi *and* umts/4g in the reform" problem -- I'm looking forward! :) | 13:11 |
| josch | I'm also wondering whether we'd need a different kernel or not and if yes, how we should name the repositories or packages differently. | 13:11 |
| josch | Same with the LS1028A -- will there be a different repo with a reform-tools version for the LS1028A or should we do runtime checks that then decide which is the right thing to do... | 13:12 |
| minute | i think a unified kernel should be possible | 13:33 |
| minute | just different dtbs | 13:33 |
| minute | josch: what's the correct build command to yield vmlinuz instead of Image? | 13:43 |
| minute | (i guess the kernel is compressed) | 13:43 |
| minute | ah, it's Image.gz, right? | 13:45 |
| - mtm (QUIT: Ping timeout: 248 seconds) (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 14:03 | |
| minute | apparently it is not | 14:20 |
| minute | the current u-boot script doesn't like the format of Image or Image.gz | 14:24 |
| minute | normally bzImage is vmlinuz, right? but on arm64 there doesn't seem to be a make target for bzImage | 14:26 |
| minute | ah, nevermind. Image works as vmlinuz | 14:31 |
| minute | mhm > [ 6.484186] [drm:ti_sn_bridge_attach] *ERROR* Fix bridge driver to make connector optional! | 14:32 |
| minute | the problem is that dcss driver has: | 14:35 |
| minute | ret = drm_bridge_attach(encoder, bridge, NULL, | 14:35 |
| minute | DRM_BRIDGE_ATTACH_NO_CONNECTOR); | 14:35 |
| minute | aha! https://patches.linaro.org/project/linux-arm-msm/patch/20220711073733.312266-3-dmitry.baryshkov@linaro.org/ | 14:56 |
| minute | with this patch, the backlight comes on and fb0 is there, but display stays black | 15:02 |
| minute | i can blindly enter the ssd password | 15:03 |
| minute | and i get login on uart | 15:03 |
| minute | even sway "works" but there's no output on the display, so something wrong with dsi | 15:04 |
| minute | ah, forgot to apply ../patches/0001-nwl-dsi-fixup-mode-only-for-LCDIF-input-not-DCSS.patch | 15:06 |
| minute | getting spurious wifi related oops [ 269.259849] WARNING: CPU: 3 PID: 0 at net/mac80211/rx.c:3993 ieee80211_rx_handlers+0x438/0x2420 | 15:08 |
| minute | (wifi still works though) | 15:08 |
| minute | aaand display is up | 15:11 |
| minute | josch: we probably just have to drop in this patch https://patches.linaro.org/project/linux-arm-msm/patch/20220711073733.312266-3-dmitry.baryshkov@linaro.org/ to make stuff work, at least i'm running 6.0.0-rc4+ now. | 15:12 |
| minute | haven't tested HDMI yet though, but that's secondary | 15:12 |
| minute | i can use 'foliate' now which failed on the old kernel with etnaviv out of space errors | 15:13 |
| minute | wayland chromium works now! | 15:15 |
| minute | (--ozone-platform-hint=auto) | 15:15 |
| minute | (webgl in it is a bit wonky though) | 15:15 |
| minute | 50+ fps in minetest, nice | 15:16 |
| josch | wow | 15:19 |
| josch | minute: okay, I'll instruct reform-debian-packages to build 5.19 with "drm/bridge: ti-sn65dsi86: support DRM_BRIDGE_ATTACH_NO_CONNECTOR" dropped | 15:21 |
| josch | minute: thank you for your super quick solution! :D | 15:21 |
| minute | josch: i just found a v3 of this patch... | 15:21 |
| minute | doesn't seem very different though https://lore.kernel.org/all/20220711092117.360797-1-dmitry.baryshkov@linaro.org/ | 15:22 |
| minute | josch: sorry, just to make sure: the patch needs to be added, not dropped | 15:40 |
| josch | oh and I already was wondering what i'm doing wrong XD | 15:40 |
| minute | we need to include it in linux/patches | 15:41 |
| josch | yup | 15:41 |
| josch | minute: but we need both commits and not only 2/2, right? | 15:47 |
| minute | yeah i just downloaded the "series" | 16:09 |
| + mtm (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 16:09 | |
| josch | yup, it applies cleanly on top of 5.19 (only a little fuzz) | 16:09 |
| + vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:20) | 16:12 | |
| minute | josch: nice | 16:59 |
| josch | fails to build... investigating... | 17:06 |
| minute | not nice | 17:12 |
| josch | probably just some missing headers | 17:25 |
| + dustfinger (~user@d75-159-228-218.abhsia.telus.net) | 18:09 | |
| - mjw (QUIT: Killed (NickServ (GHOST command used by mark__!~mark@gnu.wildebeest.org))) (~mjw_@2001:1c06:2488:1400:9e5c:8eff:fe8f:a440) | 18:14 | |
| * mark__ -> mjw | 18:14 | |
| + wielaard (~mjw_@2001:1c06:2488:1400:9e5c:8eff:fe8f:a440) | 18:15 | |
| josch | minute: it becomes a bit more complicated... 5.19 has ti_sn_bridge_enable but 6.0 has ti_sn_bridge_atomic_enable. The latter has a second argument called old_bridge_state which the former has not, so compilation fails because it cannot find a old_bridge_state variable. | 19:15 |
| minute | josch: could we go directly to 6? | 19:15 |
| minute | otherwise, there was also a patch to convert sn bridge to atomic api | 19:16 |
| josch | minute: theoretically yes, but packaging a new linux upstream version is not for the faint of heart so i'd prefer if the packaging was already done by the Debian linux packaging team | 19:16 |
| josch | minute: do you have the commit for the amotic api handy? | 19:17 |
| sigrid | minute: my fun experiments with screen blank + lcdif ended up with a success - if I do stuff in a very specific order (stopping/resuming) with another bit in a "frame done" interrupt handler, nothing flickers and the screen image doesn't get shifted nor colors go wrong | 19:17 |
| minute | sigrid: nice! can you see any difference in power use? | 19:17 |
| sigrid | it cut down ~ -25mA by this, compared to not doing anything | 19:17 |
| minute | josch: i'll check | 19:17 |
| sigrid | circle+b now shows 0.223A on 9front with screen turned off | 19:19 |
| minute | sigrid: nice | 19:19 |
| minute | josch: probably https://www.spinics.net/lists/dri-devel/msg354571.html | 19:20 |
| minute | trying to find it on lore | 19:21 |
| josch | minute: that patch looks like it does the thing I want | 19:21 |
| minute | https://lore.kernel.org/all/20220703202724.9553-2-sam@ravnborg.org/ | 19:21 |
| josch | thx | 19:23 |
| - vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:7:77:0:20) | 19:46 | |
| - chartreuse (QUIT: Ping timeout: 244 seconds) (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 19:55 | |
| + sts-q (~sts-q@37.228.147.121) | 19:58 | |
| + chartreuse (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 20:07 | |
| minute | josch: do we know why this failed? it's kind of impossible for me to find the actual compilation error in this log https://source.mnt.re/reform/reform-debian-packages/-/jobs/894 | 20:22 |
| josch | minute: the problem is, that linux logs can be hundreds of MB large and gitlab only allows 8 MB | 20:23 |
| josch | so by default, gitlab just stops recording stdout once 8 MB is reached | 20:23 |
| minute | i see | 20:23 |
| josch | to prevent that, I added the filter-output script to the reform-debian-packages repo | 20:23 |
| josch | that script will stop producing output after 4MB and keeps recording output | 20:24 |
| minute | should i try to run the build on my machine then? | 20:24 |
| josch | i'm currently running it on mine | 20:24 |
| minute | ah, cool | 20:24 |
| josch | should be successful or failed in 20 m | 20:24 |
| josch | and since we build in parallel, the error is often not in the last 4 MB of the logs | 20:24 |
| minute | gotcha | 20:24 |
| josch | we could fix this by building with -j1 | 20:25 |
| josch | that would make it much slower but the error would definitely be in the log (at the end of it) | 20:25 |
| minute | well :3 that would slow things down massively yeah | 20:25 |
| josch | actually, let me add a '| tee log |' into the pipeline and then publish that as an artifact | 20:26 |
| josch | oh wait my script already does that | 20:26 |
| josch | but artifacts are only created when the build is successful XD | 20:27 |
| minute | ah ;3 | 20:27 |
| josch | if the build is successful, then the full log is published as output.log | 20:27 |
| minute | right | 20:28 |
| - qwer (QUIT: Ping timeout: 244 seconds) (~qwer@78-80-108-59.customers.tmcz.cz) | 20:39 | |
| josch | the source.mnt.re CI is an order of magnitude faster than my system, so since my local compilation is now past the point where it failed last time, I just pushed my current status | 20:58 |
| josch | if all goes well, then the CI will be done long before my local run is :) | 20:59 |
| minute | :0 | 21:01 |
| - Gooberpatrol_66 (QUIT: Remote host closed the connection) (~Gooberpat@user/gooberpatrol66) | 21:03 | |
| + Gooberpatrol_66 (~Gooberpat@user/gooberpatrol66) | 21:03 | |
| dustfinger | I am curious if anyone has succeeded in running GUIX OS on a reform? | 21:04 |
| dustfinger | If I were to purchase two more reforms today, how long would it be before they arrived in Canada? | 21:05 |
| + Gooberpatrol66 (~Gooberpat@user/gooberpatrol66) | 21:10 | |
| - Gooberpatrol_66 (QUIT: Ping timeout: 244 seconds) (~Gooberpat@user/gooberpatrol66) | 21:11 | |
| + qwer (~qwer@78-80-112-49.customers.tmcz.cz) | 21:20 | |
| josch | dustfinger: I'm not aware of anybody having run guix on the reform yet. These links might be of interest to you: https://lists.gnu.org/archive/html/help-guix/2021-09/msg00027.html https://community.mnt.re/t/guix-and-reform/173 In the past several people in this channel have expressed interest in guix: vagrantc, cwebber, jfred, jackhill... | 21:20 |
| dustfinger | josch: Thank you! | 21:21 |
| josch | dustfinger: I'm not familiar with guix but I can help with anybody who wants to work on this by showing what changes we made in Debian to make it work. | 21:21 |
| dustfinger | josch: I am going to read through the threads and see what issues people ran into in the past. | 21:22 |
| jfred | If anyone manages to get guix running on the reform I would love to run it on mine (once I get it fixed 😞 ) | 21:22 |
| dustfinger | josch: is it simple for you to show me what changes were made to get debian working? Are there maybe some commits you could point me to? | 21:24 |
| josch | dustfinger: the most important part are our patches to the kernel: https://source.mnt.re/reform/reform-debian-packages/-/tree/main/linux/patches | 21:25 |
| dustfinger | Thank you josch, I will take a look. | 21:25 |
| josch | dustfinger: once you have a kernel that boots, think about how to construct a boot.scr or an extlinux.conf. In Debian we have flash-kernel and u-boot-menu to prepare both, respectively. Guix probably has its own machinery to create those files in /boot upon kernel updates. | 21:26 |
| josch | dustfinger: once you have that, there are a few more tweaks which all live in the reform-tools package: https://source.mnt.re/reform/reform-tools | 21:27 |
| josch | dustfinger: most interesting are probably the workarounds to make suspend more reliable | 21:27 |
| dustfinger | Thank you josch! | 21:28 |
| josch | minute: the pipeline passed! | 21:31 |
| josch | Kooda: do you want to try out whether the kernel with the new patches makes your system bootable again? :) | 21:32 |
| josch | Kooda: https://source.mnt.re/reform/reform-debian-packages/-/jobs/895/artifacts/browse/repo/pool/main/l/linux/ | 21:32 |
| - Gooberpatrol66 (QUIT: Ping timeout: 244 seconds) (~Gooberpat@user/gooberpatrol66) | 21:33 | |
| minute | josch: great! | 21:35 |
| josch | ACTION cancels his local build... | 21:35 |
| dustfinger | jfred: what did you do to your reform that it needs fixing? | 21:35 |
| jfred | dustfinger: https://community.mnt.re/t/just-came-back-to-a-seemingly-dead-board/1162 | 21:36 |
| - sts-q (QUIT: Remote host closed the connection) (~sts-q@37.228.147.121) | 21:41 | |
| + sts-q (~sts-q@37.228.147.121) | 21:43 | |
| jfred | minute: On that note, do you happen to know what the fix was for this one or if you ever received the board for inspection? Was frustrating finding a thread for what appears to be the same issue but without a resolution 😅 https://community.mnt.re/t/laptop-unresponsive/749 | 21:45 |
| - qwer (QUIT: Ping timeout: 268 seconds) (~qwer@78-80-112-49.customers.tmcz.cz) | 21:45 | |
| + qwer (~qwer@78-80-112-49.customers.tmcz.cz) | 21:46 | |
| minute | jfred: hmm, i would need to look that up during working hours. it's possible that it's a shot diode D5. | 21:47 |
| minute | jfred: if you have a multimeter you can test if D5 is a short in both directions | 21:48 |
| jfred | ooh, I do have a multimeter, I'll check | 21:48 |
| - sts-q (QUIT: Quit: Mezzano-OS with Pet IRC client.) (~sts-q@37.228.147.121) | 21:48 | |
| jfred | Also sorry, I forget about how far ahead Europe is sometimes 😅 | 21:50 |
| minute | jfred: or if it has a diode tester you can try that too | 21:50 |
| minute | jfred: btw for best results write to support@mntre.com, my colleague will then make sure the request is handled | 21:50 |
| minute | but yeah, i fixed one customer board by desoldering D5 (iirc), one of the schottkys around lt4020 | 21:51 |
| minute | dustfinger: if you write to support@mntre.com we can probably make 2 reforms happen relatively soon. | 21:56 |
| minute | i was going to do some inventory with greta tomorrow | 21:56 |
| dustfinger | minute: Thank you, I will do that. | 22:00 |
| jfred | Multimeter does indeed appear to show a short on D5 (provided it’s not flowing somewhere else on the board since it’s still in-circuit but I assume it wouldn’t be) | 22:00 |
| jfred | Thanks, I’ll email support | 22:01 |
| jfred | Wonder what could have caused that | 22:01 |
| minute | jfred: would you be able to desolder it? | 22:05 |
| minute | jfred: it appears to be a spurious failure of this component (rare so far) | 22:05 |
| jfred | I probably can though I may have better luck with that at my local hackerspace when I can make it in there since they have more tools than I do at home | 22:06 |
| minute | jfred: sounds great! it might save you some time + postage etc | 22:07 |
| minute | jfred: if it turns out not to be the root cause i can of course still take a look | 22:07 |
| minute | josch: thinking how to give the new packages a spin | 22:08 |
| jfred | Out of curiosity, what’s it for? I wouldn’t normally expect desoldering a component without replacing it to work 😆 | 22:08 |
| minute | jfred: it's not really explained in the datasheet https://www.analog.com/media/en/technical-documentation/data-sheets/4020fd.pdf | 22:10 |
| minute | i think it's supposed to take some load off the mosfet(s) | 22:10 |
| jfred | Ahh interesting | 22:13 |
| josch | minute: on a system with the old kernel, wget the kernel packages (one is the meta package and one the real one) and then "sudo apt install ./linux-image-5.19.0-reform2-arm64_5.19.6-1+reform1_arm64.deb ./linux-image-arm64_5.19.6-1+reform1_arm64.deb" | 22:15 |
| minute | ah! that's enough? what about the modules? | 22:15 |
| minute | are they in there? | 22:15 |
| josch | minute: the modules are part of the linux-image-5.19.0-reform2-arm64_5.19.6-1+reform1_arm64.deb | 22:16 |
| minute | thanks! | 22:16 |
| josch | minute: did I read this correctly further up that it's possible to buy a reform from you today? Is this information here outdated: https://shop.mntmn.com/products/mnt-reform | 22:16 |
| minute | josch: it's not outdated, but we might be able to make a few more | 22:17 |
| josch | oh... i should've asked here then... :( | 22:17 |
| minute | josch: why, did you buy at crowd supply? | 22:18 |
| josch | my wife's laptop died two days ago but we didn't buy a reform because of that message and because we needed a replacement now and not in a few months... :/ | 22:18 |
| minute | (we'll mainly send some more to them too) | 22:18 |
| minute | josch: i see! what did you end up buying instead? also, good to know | 22:18 |
| josch | we just got another thinkpad | 22:19 |
| minute | ah :D | 22:19 |
| josch | she says she needs more than two mouse buttons which already makes most laptops out there a non-option | 22:19 |
| josch | and during our holidays in portugal, the reform was our only computer so she got to use it a lot and really liked how sturdy it is built | 22:20 |
| minute | these are good insights for us! | 22:20 |
| josch | i bet you get the "the reform is sturdy" argument a lot :) | 22:21 |
| minute | yeah | 22:22 |
| minute | we're trying to figure out what's most important about the product for people who like it | 22:23 |
| josch | oh and she also liked that it's not manufactured by some cheap labor in asia from some multi-billion $ corp but supports a small local business | 22:23 |
| minute | i did this now for testing: | 22:23 |
| minute | deb [trusted=yes] https://mntre.com/reform-debian-repo-staging reform | 22:23 |
| minute | main | 22:23 |
| josch | looks good | 22:24 |
| minute | lets see what happens... | 22:25 |
| minute | display does not come up | 22:27 |
| josch | drat :( | 22:27 |
| minute | ok, will hook this up to serial tomorrow at work! | 22:28 |
| josch | okay, bed time for me then :) | 22:29 |
| minute | good night! | 22:29 |
| josch | same to you! | 22:29 |
| jfred | Trackball and more than two mouse buttons are a big part of why I like my Reform. Touchpads often aggravate my RSI and the Reform's trackball (post-bearing-upgrade) is more comfortable for me by far | 22:39 |
| jfred | bad keyboards also aggravate it (esp. when I need very specific pressure and location on the keys for them to reliably register as on the laptop I'm using right now) and the Reform's keyboard is wonderful | 22:40 |
| jfred | it's just a *comfy* device to use | 22:40 |
| jfred | also if I ever want to run Plan 9 on it I'll need those extra mouse buttons :P | 22:42 |
| sigrid | Plan 9 is the reason it has those extra mouse buttons, I believe | 22:49 |
| jfred | Ah interesting, I found which diode D5 is on that datasheet (Dd) and it even calls it out as "optional". There's a teeny bit of explanation on p.24/25 but it's been too long since I've done any circuit design :) | 22:59 |
| jfred | suppose I could order and install a replacement schottky diode for it too if this fixes it | 23:04 |
| minute | jfred: ha! | 23:25 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!