| josch | vagrantc: there is no rush -- since we will be waiting a long time for the patches to get mainlined, a few weeks longer really don't matter :) | 00:23 |
|---|---|---|
| - mjw (QUIT: Quit: Leaving) (~mark@gnu.wildebeest.org) | 00:40 | |
| bkeys1 | I have heard that the wifi card that comes with the Reform isn't very good; is there an mpcie wireless card that you guys do recommend in your reform? | 01:51 |
| vagrantc | josch: good point | 01:59 |
| - mtm (QUIT: Ping timeout: 240 seconds) (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 02:02 | |
| kfx | what does "isn't very good" mean? | 02:42 |
| kfx | it benefits from a stronger antenna but I haven't run into any problems with mine | 02:42 |
| - Christoph_ (QUIT: Remote host closed the connection) (~Christoph@p54bf605a.dip0.t-ipconnect.de) | 02:44 | |
| - sl (QUIT: Quit: leaving) (~sl@104-59-85-219.lightspeed.iplsin.sbcglobal.net) | 03:22 | |
| + mtm (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 04:09 | |
| + reform32121 (~mark@h134-215-219-148.bendor.broadband.dynamic.tds.net) | 04:51 | |
| - reform32121 (QUIT: Client Quit) (~mark@h134-215-219-148.bendor.broadband.dynamic.tds.net) | 04:52 | |
| - vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:7:77:0:20) | 05:08 | |
| + bluerise_ (~bluerise@p5b0acfb5.dip0.t-ipconnect.de) | 06:13 | |
| - mtm (QUIT: Ping timeout: 246 seconds) (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 06:13 | |
| - bluerise (QUIT: Ping timeout: 246 seconds) (~bluerise@user/bluerise) | 06:14 | |
| - GNUmoon (QUIT: Ping timeout: 240 seconds) (~GNUmoon@gateway/tor-sasl/gnumoon) | 07:16 | |
| + chomwitt (~chomwitt@2a02:587:dc1f:5600:c2b2:8e31:c818:61b1) | 07:41 | |
| + GNUmoon (~GNUmoon@gateway/tor-sasl/gnumoon) | 08:00 | |
| + mtm (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 08:19 | |
| + mjw (~mark@gnu.wildebeest.org) | 09:38 | |
| + wielaard (~mjw_@2001:1c06:2488:1400:9e5c:8eff:fe8f:a440) | 11:16 | |
| - mjw (QUIT: Killed (NickServ (GHOST command used by wielaard!~mjw_@2001:1c06:2488:1400:9e5c:8eff:fe8f:a440))) (~mark@gnu.wildebeest.org) | 11:26 | |
| * wielaard -> mjw | 11:26 | |
| + mark_ (~mark@gnu.wildebeest.org) | 11:26 | |
| + erle (~erle@ip5f5af7b3.dynamic.kabel-deutschland.de) | 11:43 | |
| minute | bkeys1: the card is good. you might be interested in external antenna mod | 12:59 |
| + Christoph_ (~Christoph@p4fe73f67.dip0.t-ipconnect.de) | 13:19 | |
| - mtm (QUIT: Ping timeout: 260 seconds) (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 14:03 | |
| - GNUmoon (QUIT: Ping timeout: 240 seconds) (~GNUmoon@gateway/tor-sasl/gnumoon) | 14:49 | |
| - bkeys1 (QUIT: Read error: Connection reset by peer) (~Thunderbi@static-198-54-135-37.cust.tzulo.com) | 14:49 | |
| + bkeys1 (~Thunderbi@static-198-54-135-37.cust.tzulo.com) | 14:57 | |
| vkoskiv | I'm going to travel to where my Reform is located tomorrow. Absolutely cannot wait :D | 15:03 |
| minute | nice | 15:27 |
| minute | i just got prototype trackball controller pcbs based on rp2040 instead of atmega | 15:27 |
| bkeys1 | vkoskiv: Yours didn't show up in the mail yet? | 15:50 |
| bkeys1 | minute: When I shut down my laptop, the OLED screen takes a minute to reboot, is that normal? | 15:51 |
| minute | bkeys1: i can't follow i think. | 16:05 |
| bkeys1 | So I press the circle button and it shows the OLED screen, I select power off and it will shut down my OS | 16:07 |
| bkeys1 | But the OLED screen also seems to turn off, after about 30 seconds it comes back up and everything is fine | 16:08 |
| + mtm (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 16:08 | |
| minute | bkeys1: it's not a good way to shut down. you should use `sudo shutdown now` on the computer | 16:16 |
| minute | bkeys1: because using power off in the OLED menu will hard cut the power and some files might not be committed to disk | 16:17 |
| minute | bkeys1: also, the OLED should _not_ wake up by itself. that's weird | 16:17 |
| bkeys1 | It doesn't wake up, it just doesn't respond to the circle button for about 20-30 seconds then it's back up and behaves just fine | 16:26 |
| + vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:20) | 16:26 | |
| minute | bkeys1: in sleep mode it will not respond unless you hold circle for 1-2 seconds | 16:30 |
| minute | bkeys1: that's a new feature that got introduced after printing the handbook ^^ | 16:31 |
| minute | (deep sleep mode for keyboard + lpc after power off) | 16:31 |
| bkeys1 | Yeah that is probably what it is | 16:31 |
| bkeys1 | I am still talking to the repair people, hopefully I will get an answer and quote today | 16:31 |
| minute | cool | 16:31 |
| - bkeys1 (QUIT: Read error: Connection reset by peer) (~Thunderbi@static-198-54-135-37.cust.tzulo.com) | 16:54 | |
| + bkeys1 (~Thunderbi@static-198-54-135-37.cust.tzulo.com) | 16:57 | |
| bkeys1 | minute: I am not sure why, but KDE on wayland must have some sort of memory leak because it runs great but over time it starts to lag worse and worse | 17:05 |
| bkeys1 | It takes an hour or two to manifest | 17:05 |
| minute | very possible, should be better with newer mesa | 17:06 |
| minute | not sure if you can upgrade libglx-mesa0 (and dependencies)? | 17:06 |
| minute | i also have some interesting GPU MMU faults with my bleeding edge mesa + kde | 17:07 |
| bkeys1 | I am running an upgrade but nothing mesa related was in the list of stuff to be upgraded | 17:07 |
| vagrantc | how many of the patches are only for hdmi support https://source.mnt.re/reform/reform-debian-packages/-/tree/main/linux/patches ... since the hdmi support requires a binary blob | 17:09 |
| minute | vagrantc: if you were to support only the single internal display configuration, the only required patches are 0005 and mnt4002 | 17:13 |
| vagrantc | minute: thanks! | 17:13 |
| vagrantc | that simplifies things a lot | 17:13 |
| josch | minute: how sure are you? I tried building the kernel with all patches except mnt5000-imx8mq-import-HDMI-driver-and-make-DCSS-compatible.patch and the internal display didn't come on. | 17:15 |
| vagrantc | oh. | 17:18 |
| josch | in other bad kernel news: attempting to boot 5.18.2 results in a kernel panic quite late in the boot process | 17:21 |
| josch | I changed our patches according to what sigrid did here https://github.com/ftrvxmtrx/void-packages/commit/52f060dfcc424177809a39d350617344f5d202ba | 17:21 |
| vagrantc | hrm. | 17:21 |
| josch | maybe somebody with a working serial connection can have a look at it | 17:21 |
| josch | i already disabled building 5.18.2 so that not more people accidentally upgrade to it | 17:21 |
| vagrantc | unfortunately, my mnt/reform is still in a box after a minor office move... | 17:22 |
| josch | here is an image containing 5.18.2 that shows the problem: https://mister-muffin.de/reform/reform-rescue-system.img | 17:22 |
| sigrid | josch: what's the panic about? | 17:48 |
| sigrid | did 5.18.1 boot? | 17:48 |
| - bkeys1 (QUIT: Ping timeout: 240 seconds) (~Thunderbi@static-198-54-135-37.cust.tzulo.com) | 17:53 | |
| + bkeys1 (~Thunderbi@static-198-54-135-37.cust.tzulo.com) | 17:59 | |
| josch | sigrid: sorry, I don't have my camera with me, so I cannot take a photo. I didn't try 5.18.1 because that was never released in Debian unstable. | 18:04 |
| sigrid | ok, did 5.18.0 boot then? | 18:05 |
| josch | linux in unstable went from 5.17.11 to 5.18.2 | 18:05 |
| sigrid | ok | 18:06 |
| sigrid | I had a panic on 5.18.0 and it was related to audio | 18:06 |
| sigrid | and it was later during boot | 18:06 |
| sigrid | https://github.com/ftrvxmtrx/void-packages/commit/52f060dfcc424177809a39d350617344f5d202ba#diff-6ce09432a91cc8b36027f04c8dbf4dc85e35171c2d3964680a775759c1b0a1b4 | 18:08 |
| sigrid | this change fixed it. I might have forgotten to make the same change to hdmi dts | 18:08 |
| sigrid | right, hdmi one does not even have that line | 18:10 |
| minute | josch: hmmmmmmm that's strange, maybe there is another DCSS related fix in that patch :0 | 18:39 |
| josch | sigrid: yeah I ignored the change to imx8mq-mnt-reform2-no-hdmi.dts because I couldn't find that line | 18:51 |
| josch | In any case, I would be greatful if somebody else could take over debugging this. It's really bothersome always having to jump through hoops to get serial. Maybe I should write to the board whether somebody who never needs serial would be willing to switch their board with mine... :/ | 18:53 |
| sigrid | could you try booting with the sound disabled? | 18:53 |
| josch | sigrid: just disabling sound in userspace or would you recommend a kernel boot option or blacklisting a certain module? | 18:54 |
| josch | i can certainly try that out later tonight | 18:54 |
| josch | oh indeed | 18:58 |
| josch | snd_soc_fsl_sai | 18:58 |
| josch | https://mister-muffin.de/p/ttJH.jpg | 18:58 |
| josch | cool. after blacklisting snd_soc_fsl_sai I don't get a kernel panic but the screen turns off at the point where i should get the login screen... | 19:07 |
| josch | this really has to be looked at by somebody with serial... | 19:07 |
| sigrid | josch: blacklisting the module | 19:15 |
| sigrid | i wonder if your dt is different, cause for me it all works fine | 19:16 |
| + bkeys2 (~Thunderbi@253.236-24.gp.ptn.tftn.static.friendlycity.net) | 19:22 | |
| - bkeys1 (QUIT: Ping timeout: 244 seconds) (~Thunderbi@static-198-54-135-37.cust.tzulo.com) | 19:23 | |
| - bkeys (QUIT: Ping timeout: 250 seconds) (~Thunderbi@static-198-54-135-37.cust.tzulo.com) | 19:24 | |
| * bkeys2 -> bkeys | 19:24 | |
| - mjw (QUIT: Quit: Leaving) (~mjw_@2001:1c06:2488:1400:9e5c:8eff:fe8f:a440) | 19:35 | |
| + bkeys1 (~Thunderbi@static-198-54-135-37.cust.tzulo.com) | 19:41 | |
| - bkeys (QUIT: Ping timeout: 258 seconds) (~Thunderbi@253.236-24.gp.ptn.tftn.static.friendlycity.net) | 19:43 | |
| * bkeys1 -> bkeys | 19:43 | |
| josch | sigrid: maybe that's it. I think I made a mistake applying your patch and the line "fsl,sai-mclk-direction-output" is still in my version. | 20:01 |
| * mark_ -> mjw | 20:22 | |
| - bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@static-198-54-135-37.cust.tzulo.com) | 20:26 | |
| + bkeys1 (~Thunderbi@static-198-54-135-37.cust.tzulo.com) | 20:26 | |
| + bkeys (~Thunderbi@static-198-54-135-37.cust.tzulo.com) | 20:28 | |
| - bkeys (QUIT: Client Quit) (~Thunderbi@static-198-54-135-37.cust.tzulo.com) | 20:32 | |
| - bkeys1 (QUIT: Remote host closed the connection) (~Thunderbi@static-198-54-135-37.cust.tzulo.com) | 20:32 | |
| + bkeys (~Thunderbi@static-198-54-135-37.cust.tzulo.com) | 20:32 | |
| - bkeys (QUIT: Client Quit) (~Thunderbi@static-198-54-135-37.cust.tzulo.com) | 20:35 | |
| + bkeys (~Thunderbi@static-198-54-135-37.cust.tzulo.com) | 20:35 | |
| - bkeys (QUIT: Ping timeout: 256 seconds) (~Thunderbi@static-198-54-135-37.cust.tzulo.com) | 20:41 | |
| + bkeys (~Thunderbi@static-198-54-135-37.cust.tzulo.com) | 20:42 | |
| + kklimonda_ (sid72883@user/kklimonda) | 20:46 | |
| + jfred_ (sid534649@libera/sponsor/jfred) | 20:46 | |
| + svp_ (sid537750@id-537750.uxbridge.irccloud.com) | 20:46 | |
| + bleb_ (~cm@user/bleb) | 20:49 | |
| + swivel_ (~swivel@shells.gnugeneration.com) | 20:49 | |
| + marlun1 (~marlun@46.101.246.245) | 20:50 | |
| - svp (QUIT: Ping timeout: 248 seconds) (sid537750@id-537750.uxbridge.irccloud.com) | 20:50 | |
| - kklimonda (QUIT: Ping timeout: 248 seconds) (sid72883@user/kklimonda) | 20:50 | |
| - bleb (QUIT: Ping timeout: 248 seconds) (~cm@user/bleb) | 20:50 | |
| - jfred (QUIT: Ping timeout: 248 seconds) (sid534649@libera/sponsor/jfred) | 20:50 | |
| - swivel (QUIT: Ping timeout: 248 seconds) (~swivel@shells.gnugeneration.com) | 20:50 | |
| - marlun (QUIT: Ping timeout: 248 seconds) (~marlun@46.101.246.245) | 20:50 | |
| - _E (QUIT: Ping timeout: 248 seconds) (~e@bsd.moe) | 20:50 | |
| * svp_ -> svp | 20:50 | |
| * kklimonda_ -> kklimonda | 20:50 | |
| * jfred_ -> jfred | 20:50 | |
| * bleb_ -> bleb | 20:51 | |
| + _E (~e@bsd.moe) | 21:01 | |
| josch | sigrid: that was it!! Thank you so much once again! :D | 21:14 |
| josch | turns out you don't even need working serial connection if you have sigrid in the chat to help you out ^^ | 21:15 |
| sigrid | np :) | 21:17 |
| * swivel_ -> swivel | 21:17 | |
| josch | yeah... i should've really read your commit more carefully XD | 21:17 |
| josch | anyways, reform-debian-repo again contains a working kernel | 21:21 |
| vkoskiv | bkeys: Mine did arrive in the mail last week already, but it arrived at my parents' place instead of mine | 21:25 |
| vkoskiv | And I live ~4h away by train. | 21:26 |
| josch | minute: I can now also confirm that kde plasma is really smooth on the reform -- i'll prepare some MR for reform-system-image and reform-tools | 21:49 |
| vkoskiv | <24h until I'll have my hands on my reform. Should I go with the (presumably v2) SD card that comes with the system or right away flash the newest v3 image onto the card? | 21:50 |
| josch | also turns out that the kde-standard meta-package pulls a lot of stuff in but we've already installed quite a bit of it so in the end, the image is just 1 GB larger with kde | 21:50 |
| josch | vkoskiv: start with v3 | 21:51 |
| vkoskiv | Cool, and just the latest image will do? There was a link to some CI artefact at one point. | 21:51 |
| josch | vkoskiv: there is no easy upgrade path from v2 to v3 and I don't think there is a reason to stay with the old versions that you cannot upgrade on v2 | 21:51 |
| minute | josch: ok cool! | 21:51 |
| vkoskiv | Ideally I'd like to format, encrypt and install the system on this NVME drive I'm putting in. | 21:51 |
| josch | vkoskiv: that should all work with v3. Contact me if you run into any problems. | 21:52 |
| vkoskiv | Anything special to know about that process before I start? | 21:52 |
| minute | the best is to start with v3 yep | 21:52 |
| vkoskiv | josch: Thanks! I'll probably spam this channel a bit in my excitement tomorrow night :3 | 21:52 |
| josch | vkoskiv: we understand :) | 21:52 |
| vkoskiv | I also plan to film a proper assembly tutorial once I get back home. Sounds like a fun video project. | 21:53 |
| vkoskiv | I'll just put the thing together myself first. | 21:53 |
| josch | I think one of my lifepo4 cells is damaged. While the others are still at 3.3 V, this one cell quickly looses its voltage and dips below 2.5 V while the others are still at 3.3. Instead of replacing that single cell I thought of just buying 8 new cells from eremit. Would anybody in this channel be interested in the other 7 working cells from my reform? If you pay shipping I'd give them away for free. | 22:17 |
| vkoskiv | Where are you located? | 22:18 |
| josch | Germany | 22:18 |
| vkoskiv | Not far! | 22:18 |
| vkoskiv | Don't you want to keep a few as spares? | 22:18 |
| josch | The eremit cells i want to buy are 2000 mah, I don't think i should mix 2000 mah cells with 1800 mah cells. | 22:19 |
| minute | yup | 22:19 |
| vkoskiv | Good point. Does the LPC support/detect that even? | 22:19 |
| vkoskiv | *could* it even physically deal with that if the code were there? | 22:19 |
| josch | Yes, minute and Boostisbetter are already using the eremit cells and the lpc firmware learns about the new capacity. | 22:20 |
| vkoskiv | But I mean if you mix two different capacities at the same time randomly, could it handle that in theory? | 22:20 |
| josch | I was recently explained that this is why the lpc display initially shows ???% as capacity because it has to learn what "full" means. | 22:20 |
| vkoskiv | It does charge them individually, right? But there might be issues when discharging? | 22:20 |
| vagrantc | you don't want mismatched cells, as it'll put more wear and tear on individual cells | 22:23 |
| minute | vkoskiv: it would just turn off when the first cell is empty | 22:23 |
| minute | vkoskiv: so you basically only get the capacity of the weakest cell | 22:23 |
| vkoskiv | Right, so it would not be a wise thing to do :D | 22:24 |
| vagrantc | they'll also be harder to balance | 22:24 |
| vkoskiv | How does the charging circuit "detect" when a cell is full? Just based purely on the voltage? Current draw? Both? | 22:24 |
| minute | vkoskiv: voltage, and if total charging current goes below a certain value it assumes it can't really charge more | 22:26 |
| minute | it tries to get all cells to >3.3V and <3.5V while squeezing as much charge in there as possible | 22:27 |
| minute | sometimes the loop does not terminate though, i need to improve that still (i.e. it balances for many hours near the top end) | 22:28 |
| minute | vkoskiv: https://source.mnt.re/reform/reform/-/blob/master/reform2-lpc-fw/src/boards/reform2/board_reform2.c#L934 | 22:31 |
| minute | (note that charge current is negative) | 22:31 |
| minute | the -0.3 is probably too tight https://source.mnt.re/reform/reform/-/blob/master/reform2-lpc-fw/src/boards/reform2/board_reform2.c#L190 | 22:32 |
| vkoskiv | How does it measure the cell voltage when it's applying a voltage to the cell? Cut off the charge for a brief moment to do the measurement? | 22:34 |
| minute | currently it measures while charging | 22:38 |
| minute | i could change that though | 22:38 |
| vkoskiv | The cell being charged 'drags' the voltage down, right? | 22:38 |
| vkoskiv | Can you tell I never really studied electronics concepts probably :D | 22:39 |
| vkoskiv | So for SysV3 I just grab the artifacts for the latest job here: https://source.mnt.re/reform/reform-system-image/-/jobs | 22:44 |
| vkoskiv | the latest sysv3 branch job, I mean. | 22:44 |
| josch | vkoskiv: sysimage-v3 was merged into main recently, so you can just use the latest successful job artifacts | 22:45 |
| vkoskiv | Cool. Do y'all maintain a persistent installation or are you always reinstalling the whole thing with the latest artifact? | 22:46 |
| vkoskiv | If a new change is made to the system image, I assume I can't just install that as an update to whatever package | 22:46 |
| josch | vkoskiv: both -- i have an installation i keep upgrading but for testing i flash the most recent artifacts to make sure that my local config doesn't influence anything | 22:46 |
| josch | vkoskiv: that's the advantage of sysimage-v3 over v2: you just use "apt upgrade" to get the latest improvements | 22:47 |
| vkoskiv | And does 'apt upgrade' still mess things up? I heard at some point that was a thing | 22:47 |
| minute | vkoskiv: not down, rather up | 22:47 |
| vkoskiv | Ah, cool. | 22:47 |
| minute | the idea of v3 is that it should hopefully not mess things up when upgrading. but it's still debian unstable | 22:48 |
| vkoskiv | minute: Weird! I'll have to study the system controller code more. I'd love to contribute. | 22:48 |
| josch | vkoskiv: we are still using Debian "unstable" as our base so potentially bad bugs can be in the packages that you upgrade to, but we have apt-listbugs installed so before you upgrade, it will show you any release critical bugs in the package versions you are upgrading to so that you can abort the upgrade before installing stuff that breaks your system | 22:48 |
| minute | vkoskiv: it is a pretty small amount of code. | 22:48 |
| vkoskiv | Am I correct in thinking that if I'm happy with Arch on my daily drive PC, I should be more than happy with debian unstable? | 22:49 |
| vkoskiv | If I understand correctly, Arch's rolling release is "more unstable" than Debian's unstable, right? | 22:49 |
| * bluerise_ -> bluerise | 22:54 | |
| - bluerise (QUIT: Changing host) (~bluerise@p5b0acfb5.dip0.t-ipconnect.de) | 22:54 | |
| + bluerise (~bluerise@user/bluerise) | 22:54 | |
| kfx | vkoskiv: very much so | 22:54 |
| vkoskiv | i.e. debian has rather high standards for what they consider stable and unstable :D | 22:55 |
| vkoskiv | Cool. Well, all of my important work is in version control, so I'm not worried about unstable. | 22:56 |
| josch | maybe, but we still fuck up and then the package that breaks your system will be installable as part of "unstable" during just the few hours that you decide to run "apt upgrade" :( | 22:56 |
| josch | anyways, if you are an experienced arch user, i guess you should be fine with unstable | 22:56 |
| kfx | josch: that's pretty much how arch linux runs their core repositories | 22:56 |
| minute | Kooda: about your USB problem, it might be related to wifi. have you tried disabling wifi? | 23:45 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
