| - Christoph_ (QUIT: Remote host closed the connection) (~Christoph@p54bf637d.dip0.t-ipconnect.de) | 00:01 | |
| flowy | alright ordered a purple kb w/ white switches | 00:47 |
|---|---|---|
| flowy | looking forward to trying | 00:47 |
| flowy | also... purple! | 00:47 |
| ex-parrot | mntmn: dumb question but does the LPC have to be "awake" on the new firmware before it can start charging the battery? | 00:52 |
| ex-parrot | it seems that way but I wanted to confirm | 00:52 |
| mntmn | flowy: cool thanks | 00:53 |
| mntmn | ex-parrot: yes | 00:53 |
| mntmn | ex-parrot: lpc enables charging | 00:53 |
| ex-parrot | excellent | 00:55 |
| ex-parrot | I guess there's no easy way to detect that the charger was plugged in and have it fire up the LPC eh | 00:55 |
| ex-parrot | without running another connection to the keyboard perhaps | 00:55 |
| mntmn | lpc should be wake up when wall power is there, normally | 00:57 |
| mntmn | so that's weird then | 00:57 |
| mntmn | lpc wakes up every few seconds and checks for that | 00:58 |
| mntmn | but maybe it doesn't see the expected voltage, or crashed? | 00:58 |
| mntmn | you can try to press the lpc reset button if you have the device open | 00:59 |
| - leonardo (QUIT: Remote host closed the connection) (~leonardo@user/leonardo) | 01:02 | |
| - mtm (QUIT: Ping timeout: 240 seconds) (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 01:03 | |
| + leonardo (~leonardo@user/leonardo) | 01:03 | |
| ex-parrot | hmm ok yeah | 01:04 |
| ex-parrot | I plugged in power, red LED came on, left for a few mins but saw no power draw | 01:04 |
| ex-parrot | so I "woke up" the LPC from the keyboard, and charging started | 01:04 |
| ex-parrot | I'll see if I can reproduce it | 01:04 |
| ex-parrot | I am charging at 20v instead of the included adapter... | 01:05 |
| mntmn | ah that's probably the problem | 01:27 |
| mntmn | check for something like wall power detect voltage in the lpc code | 01:27 |
| - vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:21:21:0:100b) | 01:44 | |
| + vagrantc (~vagrant@2600:3c01:e000:21:21:21:0:100e) | 02:11 | |
| + mtm (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 03:09 | |
| - Guest6698 (QUIT: Ping timeout: 240 seconds) (~nicolas@i5C7440F1.versanet.de) | 03:10 | |
| + nsc (~nicolas@i5C7445E1.versanet.de) | 03:12 | |
| * nsc -> Guest2850 | 03:13 | |
| + bluerise_ (~bluerise@p5b211402.dip0.t-ipconnect.de) | 04:10 | |
| - bluerise (QUIT: Ping timeout: 240 seconds) (~bluerise@user/bluerise) | 04:11 | |
| Asmadeus | suspend/resume, did you see https://community.nxp.com/t5/i-MX-Processors/i-mx8-PCIe-Wi-Fi-Suspend-Resume-Fails/m-p/1219849#M168252 ? it's for iMX8MQ | 05:45 |
| Asmadeus | (hm, sorry for the noise, reading slightly more of it now and it seems to be about the wifi card not coming back up not resume hang) | 05:46 |
| - vagrantc (QUIT: Ping timeout: 240 seconds) (~vagrant@2600:3c01:e000:21:21:21:0:100e) | 06:26 | |
| + MajorBiscuit (~MajorBisc@c-001-007-050.client.tudelft.eduvpn.nl) | 09:17 | |
| - erlehmann (QUIT: Ping timeout: 256 seconds) (~erle@ip5f5bd566.dynamic.kabel-deutschland.de) | 09:35 | |
| + erlehmann (~erle@ip5f5bd566.dynamic.kabel-deutschland.de) | 09:35 | |
| ex-parrot | mntmn: ty will do | 09:48 |
| - MajorBiscuit (QUIT: Ping timeout: 268 seconds) (~MajorBisc@c-001-007-050.client.tudelft.eduvpn.nl) | 09:51 | |
| + MajorBiscuit (~MajorBisc@c-001-007-050.client.tudelft.eduvpn.nl) | 09:52 | |
| + mjw (~mark@gnu.wildebeest.org) | 11:35 | |
| - MajorBiscuit (QUIT: Ping timeout: 240 seconds) (~MajorBisc@c-001-007-050.client.tudelft.eduvpn.nl) | 12:28 | |
| + MajorBiscuit (~MajorBisc@c-001-007-050.client.tudelft.eduvpn.nl) | 12:53 | |
| - jvalleroy (QUIT: Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) (~quassel@user/jvalleroy) | 12:55 | |
| + jvalleroy (~quassel@user/jvalleroy) | 12:56 | |
| + CoderFox (~coderfox@78.152.95.72) | 12:56 | |
| - mtm (QUIT: Ping timeout: 256 seconds) (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 13:03 | |
| - mjw (QUIT: Quit: Leaving) (~mark@gnu.wildebeest.org) | 13:07 | |
| + Christoph_ (~Christoph@p54bf6350.dip0.t-ipconnect.de) | 14:51 | |
| + mtm (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 15:09 | |
| * bluerise_ -> bluerise | 15:21 | |
| - bluerise (QUIT: Changing host) (~bluerise@p5b211402.dip0.t-ipconnect.de) | 15:22 | |
| + bluerise (~bluerise@user/bluerise) | 15:22 | |
| - CoderFox (QUIT: Ping timeout: 256 seconds) (~coderfox@78.152.95.72) | 15:51 | |
| - Christoph_ (QUIT: Remote host closed the connection) (~Christoph@p54bf6350.dip0.t-ipconnect.de) | 16:20 | |
| + frank2 (~frank@2a05:f480:2000:1d0d:5400:3ff:fec6:ae73) | 17:01 | |
| - frank2 (QUIT: Remote host closed the connection) (~frank@2a05:f480:2000:1d0d:5400:3ff:fec6:ae73) | 17:03 | |
| + frank2 (~frank@2a05:f480:2000:1d0d:5400:3ff:fec6:ae73) | 17:04 | |
| - frank2 (QUIT: Client Quit) (~frank@2a05:f480:2000:1d0d:5400:3ff:fec6:ae73) | 17:06 | |
| + frank2 (~frank@juicy.frank2.net) | 17:07 | |
| + CoderFox (~coderfox@78.152.95.72) | 17:30 | |
| - CoderFox (QUIT: Quit: Leaving) (~coderfox@78.152.95.72) | 17:37 | |
| + Christoph_ (~Christoph@p54bf6350.dip0.t-ipconnect.de) | 18:10 | |
| technomancy | looks like letting the batteries take a break outside the reform overnight allowed them to charge up again normally, whew | 18:26 |
| + freakazoid333 (~matt@2603:9000:cf03:86c3:11c4:68db:ad36:c833) | 18:34 | |
| mntmn | technomancy: wow ok? all of them looking normal now? | 19:04 |
| technomancy | yep; we're back to 100% now | 19:06 |
| mntmn | awesome | 19:10 |
| - MajorBiscuit (QUIT: Ping timeout: 240 seconds) (~MajorBisc@c-001-007-050.client.tudelft.eduvpn.nl) | 19:43 | |
| * Guest2850 -> nsc | 19:46 | |
| Boostisbetter | mntmn, I was reading on the forums that you suggested using 3m tape and zip ties to keep the battery cables from moving around. Is this really necessary? I mean they are all shielded, and I have a hard time imagining them getting broken just from moving the Reform around. Am I a fool and I really should secure them? Also should I secure the wifi antenna plate from moving while in transit? | 21:17 |
| mntmn | Boostisbetter: not necessary | 21:19 |
| mntmn | (i personally don't have any such things in my laptop) | 21:19 |
| + vagrantc (~vagrant@2600:3c01:e000:21:21:21:0:100e) | 21:21 | |
| sigrid | I ran reform in dual display mode, but for some reason on laptop's display sway keeps swapping between two virtual workspaces non-stop | 21:33 |
| sigrid | and keeps swapping no matter what I do | 21:33 |
| sigrid | I can't find anything on the internet regarding this | 21:33 |
| sigrid | moving the mouse pointer even one pixel makes it immediately switch | 21:34 |
| sigrid | looks like it's not even a workspace, but just an old image of it | 21:35 |
| sigrid | is that a bug in wayland or something? | 21:35 |
| Boostisbetter | hmmm, sounds like some how your sway install is borked. | 21:37 |
| Boostisbetter | normally I would say try updating, but since we are custom stuff here, I don't think that would be the right recourse. | 21:37 |
| sigrid | :( oh well. that is completely unusable. guess I'll just live with one display for now | 21:41 |
| dj-death | technomancy: interesting, and you charged them on an external charger? | 21:43 |
| + doctorhoo (~hanno@194-18-252-127-no2005.tbcn.telia.com) | 21:51 | |
| doctorhoo | mntmn: In the advanced section of the manual it says "The motherboard connector labeled SER1 ..." -- however, on my mainboard, the connector is labeled "S1" instead of "SER1". Is this a typo or convention? The section calls the UART consistently "SER1". Don't mean to nitpick, just wondering whether you'd appreciate another near-trivial merge request ;) | 21:55 |
| mntmn | that's something that changed on the pcb | 22:01 |
| mntmn | and wasn't fixed in the manual :3 | 22:01 |
| doctorhoo | mntmn: no worries, I got confused for a minute, but the instructions were so clear (even referring to it as connection J18 a couple of sentences later) that it is hardly an obstacle. So far, the instructions were really a joy to use and very helpful! | 22:10 |
| doctorhoo | I have the reform hooked up to another machine right now and try to log the console output from a resume freeze -- no "luck" so far, it works reliably! ;) | 22:12 |
| mntmn | ha :3 | 22:12 |
| doctorhoo | Wondering whether I might have to wait a little longer between attempts -- or whether giving the "no_console_suspend" kernel option has affected the timing somehow. | 22:13 |
| mntmn | oh, no_console_suspend... i remember that being necessary on imx6 | 22:22 |
| mntmn | for suspend/wake to work at all | 22:22 |
| mntmn | or IIRC pcie would crash on imx6 without that | 22:22 |
| doctorhoo | interesting! I have about 12 suspend/resume cycles in the log now. I will continue for a bit, but if nothing goes wrong when I hit the upper twenties, I will repeat the exercise without that option. | 22:35 |
| doctorhoo | but I assume it is only a side-effect of the option? I.e. that it changes timing of the resume? Or is something relying on the console being available? | 22:35 |
| + mjw (~mark@gnu.wildebeest.org) | 22:48 | |
| - mjw (QUIT: Remote host closed the connection) (~mark@gnu.wildebeest.org) | 22:48 | |
| mntmn | doctorhoo: i think with that option, one cpu core will not actually shut down | 23:16 |
| technomancy | dj-death: no, just left them out of the reform overnight and plugged them back into the reform | 23:22 |
| dj-death | technomancy: awesome, thanks, I might be able to save some cells then ;) | 23:42 |
| - Christoph_ (QUIT: Remote host closed the connection) (~Christoph@p54bf6350.dip0.t-ipconnect.de) | 23:42 | |
| doctorhoo | mntmn: that would explain why this seems to work so well: in 30 suspend/resume cycles I did not get a single freeze (with the systemd scripts and the option no_console_suspend set). | 23:50 |
| mntmn | doctorhoo: what's the power consumption when suspending like this? | 23:50 |
| mntmn | (i.e. make sure to run from batteries only and press circle, B when in suspend, note number in lower right corner) | 23:51 |
| doctorhoo | I did manage to freeze up the wayland/sway session though: swaylock would not register any keypresses. Using the serial console, I could log in and kill swaylock which resulted in the graphical UI showing but no keypresses or mouse movement registering. Killing sway brought everything back to life. No idea how to handle something like that more smoothly.. could not see anything immediately suspicious in the logs either. | 23:52 |
| doctorhoo | mntmn: 0.108A, pretty much the same as without that option set | 23:53 |
| mntmn | doctorhoo: hmm interesting problem @ sway | 23:54 |
| mntmn | maybe there could be some sort of watchdog process that also receives keypresses, plus a combo for killing/restarting sway, ctrl-alt-del like | 23:55 |
| mntmn | sounds like no_console_suspend could be a promising workaround candidate | 23:56 |
| doctorhoo | mntmn: right, there was some sysrq combo for killing X I believe | 23:56 |
| doctorhoo | after killing sway, I saw several "Existing due to channel error" messages and a segfault in /usr/bin/reform-compstat.py -- is that due to the brutal exiting or something that might be behind the issue I had? | 23:57 |
| mntmn | normal i think | 23:59 |
| mntmn | because of the killing | 23:59 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!