| - nsc (QUIT: Ping timeout: 252 seconds) (~nicolas@117-98-142-46.pool.kielnet.net) | 00:26 | |
| + nsc (~nicolas@i5C74DFEF.versanet.de) | 00:28 | |
| - chomwitt (QUIT: Ping timeout: 252 seconds) (~chomwitt@2a02:587:7a12:1b00:1ac0:4dff:fedb:a3f1) | 00:34 | |
| - cobra (QUIT: Ping timeout: 252 seconds) (~cobra@user/Cobra) | 02:15 | |
| - bkeys (QUIT: Remote host closed the connection) (~Thunderbi@173.16.175.75) | 02:27 | |
| + aloo_shu (~aloo_shu@90.166.98.89) | 02:29 | |
| - 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 | |
| + cobra (~cobra@user/Cobra) | 05:09 | |
| - aloo_shu (QUIT: Ping timeout: 252 seconds) (~aloo_shu@90.166.98.89) | 05:24 | |
| + aloo_shu (~aloo_shu@90.166.98.89) | 05:31 | |
| - robin (QUIT: Read error: Connection reset by peer) (~robin@user/terpri) | 06:19 | |
| + robin (~robin@user/terpri) | 07:14 | |
| + LainExperiments (~LainExper@2804:880:1312:2d00:980e:a6e9:388c:88a0) | 08:07 | |
| - robin (QUIT: Ping timeout: 252 seconds) (~robin@user/terpri) | 08:12 | |
| digitalrane | did anyone ever publish any images for alpine on original reform? | 08:26 |
|---|---|---|
| + gustav28 (~gustav@c-78-82-52-4.bbcust.telenor.se) | 10:02 | |
| - jacobk (QUIT: Ping timeout: 276 seconds) (~quassel@47-186-105-237.dlls.tx.frontiernet.net) | 10:04 | |
| + jacobk (~quassel@47-186-105-237.dlls.tx.frontiernet.net) | 10:05 | |
| + robin (~robin@user/terpri) | 10:22 | |
| - erle (QUIT: Ping timeout: 265 seconds) (~erle@user/erle) | 10:24 | |
| + erle (~erle@user/erle) | 11:32 | |
| - LainExperiments (QUIT: Changing host) (~LainExper@2804:880:1312:2d00:980e:a6e9:388c:88a0) | 12:19 | |
| + LainExperiments (~LainExper@user/LainExperiments) | 12:19 | |
| - iank (QUIT: Quit: ZNC 1.8.2+deb2+deb11u1 - https://znc.in) (~iank@fsf/staff/iank) | 12:30 | |
| + iank (~iank@fsf/staff/iank) | 12:30 | |
| - iank (QUIT: Quit: ZNC 1.8.2+deb2+deb11u1 - https://znc.in) (~iank@fsf/staff/iank) | 13:25 | |
| + iank (~iank@fsf/staff/iank) | 13:27 | |
| + bkeys (~Thunderbi@173.16.175.75) | 14:04 | |
| - LainExperiments (QUIT: Quit: Client closed) (~LainExper@user/LainExperiments) | 15:00 | |
| + bkeys1 (~Thunderbi@45.134.140.153) | 15:09 | |
| - bkeys (QUIT: Ping timeout: 252 seconds) (~Thunderbi@173.16.175.75) | 15:11 | |
| * bkeys1 -> bkeys | 15:11 | |
| + chomwitt (~chomwitt@2a02:587:7a12:1b00:1ac0:4dff:fedb:a3f1) | 15:14 | |
| - bkeys (QUIT: Remote host closed the connection) (~Thunderbi@45.134.140.153) | 15:22 | |
| - erle (QUIT: Killed (NickServ (GHOST command used by erle__))) (~erle@user/erle) | 16:33 | |
| + erle__ (~erle@user/erle) | 16:33 | |
| * erle__ -> erle | 16:35 | |
| - chomwitt (QUIT: Ping timeout: 272 seconds) (~chomwitt@2a02:587:7a12:1b00:1ac0:4dff:fedb:a3f1) | 17:29 | |
| + chomwitt (~chomwitt@2a02:587:7a12:1b00:1ac0:4dff:fedb:a3f1) | 18:43 | |
| hramrach | josch: https://source.mnt.re/reform/reform-tools/-/merge_requests/97/diffs | 19:15 |
| - erle (QUIT: Remote host closed the connection) (~erle@user/erle) | 19:29 | |
| + erle (~erle@user/erle) | 19:36 | |
| Twodisbetter | looks like using dpms for the display on the Pocket has freezing errors as well when the screen needs to be turned back on. Doesn't happen too often but enough to be annoying. | 19:49 |
| + mjw (~mjw@gnu.wildebeest.org) | 20:09 | |
| Twodisbetter | also who was messing with the charging software? Was that ch? I'm wondering if it is feasible to allow 5v sources to charge. | 20:13 |
| Twodisbetter | unless the charging mechansm is only able to handle pd sources then I guess it wont matter | 20:15 |
| hramrach | freezing of what? | 20:30 |
| hramrach | You are using wayfire, right? That should track dpms by itself, unlike sway. | 20:31 |
| hramrach | The problem with sway for me is is that if something turns off the screen and does not turn it back on the screen remains off in sway but works fine in console or if sway is restarted. | 20:32 |
| + LainExperiments (~LainExper@user/LainExperiments) | 20:38 | |
| Twodisbetter | do you mean that if you restart sway from the console that the screen will come back to life? | 20:44 |
| Twodisbetter | I really wish there was some kind of workaround to get the display back up. As it is, I just have to powerdown and then the drive needs to be repaired when booting again | 20:47 |
| Twodisbetter | not ideal at all | 20:47 |
| Twodisbetter | it seems like the only safe way to use the pocket is power it on, use it with no screen off time, no suspend, and turn it off when done. The Pocket could really be everything to me if it had some reliable low power states. | 20:48 |
| ch | Twodisbetter: 5v sources will work, but its not gonna be a fast charge | 20:51 |
| ch | Twodisbetter: feel free to try the usbpd branch | 20:51 |
| ^alex | oh hey we ought to sync up to some of these changes, we've been otherwise swamped with day-job stuff | 20:56 |
| hramrach | You can try to bind screen on to a key, log in remotely over ssh to investigate what part of the system is still operational, etc. | 20:56 |
| hramrach | To me it looks like there is nothing ever frozen, only sometimes I set up something wrong in sway, and it merely shows a blank screen | 20:57 |
| ch | ^alex: same here really :) | 20:57 |
| hramrach | which is very unfriendly, sure, but that's how these beta quality compositors go | 20:57 |
| hramrach | It seems that for some people something does really lock up but I cannot reproduce that | 20:58 |
| ^alex | ch, our day job is managing a very large email installation | 20:58 |
| hramrach | right, and I cannot reporduce the system randomly powering off for a while, looks like updating the sysctl firmware with the pd fixes really does make charging reliable at least with my charger | 21:03 |
| - LainExperiments (QUIT: Quit: Client closed) (~LainExper@user/LainExperiments) | 21:16 | |
| josch | hramrach: and i've had another "display does not come back on by itself" problem today on a311d with your config. But it's possible to login remotely to fix it, so it's not a hard freeze as they used to happen far in the past. | 21:29 |
| josch | hramrach: the problems i have with your MR 97 are with the maintainer script code depending on /proc/device-tree/model and /proc/cmdline. This will do different things depending on the u-boot version of the person running this. | 21:30 |
| josch | why is this important? imagine somebody is running this in a chroot or somebody is creating system images | 21:30 |
| josch | this maintainer script will also be executed on the initial system creation which can be done even on x86 systems and still should do the right thing | 21:31 |
| hramrach | josch: on an initial system it will not run, it will only run on upgrade | 21:35 |
| hramrach | This is to paper over the fact that we do not upgrade u-boot | 21:35 |
| josch | hramrach: i'd also like to only use maintainer scripts to do the things that are necessary as a last ressort -- ideally, other mechanisms than maintainer scripts should be used | 21:36 |
| josch | hramrach: ah you are right i see this now | 21:36 |
| josch | hrm.... | 21:36 |
| hramrach | Somebody rightfully complained that the reform-tools font size hack hardcodes thefont making it impossible to configure. This replaces the hack with onne-time change of console-setup configuration, for new images the kernel argument passed from u-boot should replace it | 21:38 |
| hramrach | which is not the case so far for some reason, maybe the u-boot needs to be released or something? | 21:41 |
| hramrach | Overall I would say it's replacing a gross hack with slightly less gross hack slightly improving the console font handling | 21:42 |
| josch | i agree with that | 21:46 |
| josch | maybe we can ask minute again on their position for upgrading u-boot on imx8mp? | 21:46 |
| josch | because if a u-boot upgrade is made possible/easier, then the maintscript solution is also not needed | 21:47 |
| hramrach | I don't think we are anywhere near suggesting automated u-boot upgrades meaning that the script is still needed on systems where people did not get out of their way to upgrade u-boot | 21:48 |
| hramrach | And bot forn problem and u-boot upgrade problem affect all three SoCs that are compatible with Pocket so far | 21:49 |
| hramrach | *font | 21:49 |
| - jacobk (QUIT: Ping timeout: 248 seconds) (~quassel@47-186-105-237.dlls.tx.frontiernet.net) | 22:03 | |
| + jacobk (~quassel@47-186-105-237.dlls.tx.frontiernet.net) | 22:05 | |
| - gustav28 (QUIT: Quit: Quit) (~gustav@c-78-82-52-4.bbcust.telenor.se) | 22:15 | |
| minute | josch: hramrach: if only known good uboots from our CI are installed (hashed), then i have no problem with upgrading them in general | 22:36 |
| josch | minute: the hash is enforced by reform-flash-uboot -- that component also checks $EMMC_BOOT to find out whether flashing u-boot to emmc should be allowed or not | 23:06 |
| minute | josch: then it's fine | 23:07 |
| josch | minute: in the past you said that upgrading u-boot should only be done by expert users, i.e. those who know how to run dd manually or those who know how to hack their way around the reform-flash-uboot safeties | 23:07 |
| josch | so your position on this changed? | 23:07 |
| josch | just making sure | 23:07 |
| minute | josch: yes | 23:07 |
| josch | okay | 23:07 |
| minute | josch: in any case it is still manual, right? you have to execute the command | 23:07 |
| josch | yes | 23:07 |
| josch | and reform-check will tell you if your u-boot is different than the one advertised via its hash | 23:07 |
| minute | it is fine then. we could also add a warning for imx8mp, that recovery is only possible by opening up the device and placing jumper cables | 23:08 |
| josch | minute: a similar argument would hold for a311d, no? | 23:09 |
| minute | josch: correct | 23:09 |
| josch | okay, if you think there should be a warning, i can add one into reform-flash-uboot | 23:10 |
| josch | though i wonder then if an upgrade should be suggested by reform-check? | 23:10 |
| josch | like, it's unintuitve why one tool would recommend a change and the other would caution against it | 23:10 |
| minute | josch: it doesn't need to be recommended at this point. i think at this point one can introduce interested users to the possibility of the update via a community post | 23:21 |
| josch | minute: then maybe the EMMC_BOOT variable should become tri-state: true/false/warn? If it's "warn" then it will *not* be recommended by reform-check but it will not be disallowed by reform-flash-uboot? | 23:23 |
| minute | josch: that sounds good! | 23:23 |
| josch | okay, then lets do it like that | 23:23 |
| josch | hramrach: i appreciate that even with making it easier for people to flash more recent u-boot your MR still remains useful | 23:23 |
| josch | hramrach: i must also admit that i'm much more likely to apply solutions i don't like for problems that i'm personally affacted by | 23:24 |
| josch | hramrach: since i don't have a pocket, how about you agree on a good way forward with ch and if both of you are for it, then i press the MR button unless i see grave problems (which i do not) | 23:25 |
| minute | Twodisbetter: i think dpms on the pocket display won't save much power vs brightness 0 | 23:27 |
| josch | minute: what is your current swayidle command in your sway config? | 23:30 |
| josch | minute: there is also an open issue by hramrach where we talk about switching to dmps off and i've been running that config for over a month and about once a week i run into the situation where the display fails to come back and i need to log in via ssh to fix it up | 23:31 |
| josch | (but i'm the only one who tried this on classic reform with a311d, so this might be a problem of my configuration) | 23:31 |
| minute | josch: i don't use swayidle | 23:31 |
| minute | i just leave everything on... or turn the device off. or right now, when "docked" with my dell u2724de, i just have brightness 0 on the internal pocket display | 23:32 |
| josch | uh interesting :) | 23:32 |
| minute | with rk3588, the pocket boots in max 10 seconds or so | 23:32 |
| minute | so it's unnecessary for me to have low power states | 23:32 |
| josch | interesting... i currently have 11 workspaces full of stuff :D | 23:32 |
| minute | ah well ok | 23:33 |
| minute | so yeah, it would be def. useful to have for example hibernation working on rk3588 | 23:34 |
| josch | of all soms so far, rk3588 probably has the highest chances for $somebody to do that work. I feel it is very popular in the arm irc channels and mailing lists i'm on... | 23:35 |
| minute | yes, totally | 23:44 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!