- mjw (QUIT: Ping timeout: 252 seconds) (~mjw@gnu.wildebeest.org) | 00:36 | |
- mtm- (QUIT: Ping timeout: 272 seconds) (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 01:03 | |
mhoye | So, possiblydumb question, but should there be any obstacles to my getting kde running on this machine? | 01:59 |
---|---|---|
+ mtm (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 03:08 | |
- vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:7:77:0:50) | 05:19 | |
- cobra_ (QUIT: Ping timeout: 268 seconds) (~cobra@user/Cobra) | 06:07 | |
+ cobra (~cobra@user/Cobra) | 06:26 | |
josch | mhoye: on which machine? on the reform? | 07:08 |
+ chomwitt (~chomwitt@2a02:587:7a11:6600:1ac0:4dff:fedb:a3f1) | 07:34 | |
+ mjw (~mjw@gnu.wildebeest.org) | 09:04 | |
- klardotsh (QUIT: Ping timeout: 264 seconds) (~klardotsh@c-67-170-115-80.hsd1.wa.comcast.net) | 10:08 | |
hramrach | mhoye: Technically KDE should work if you have one of the faster SoCs, I would not expect much of IMX8 in this case. However, there are no reports of success or failure runnig it I know of so you would be a pioneer there. | 10:12 |
- chomwitt (QUIT: Ping timeout: 256 seconds) (~chomwitt@2a02:587:7a11:6600:1ac0:4dff:fedb:a3f1) | 10:22 | |
josch | i've run kde plasma successfully for a few weeks 2 years ago on the imx8mq | 10:31 |
josch | the performance was absolutely fine for me | 10:32 |
- Nixkernal (QUIT: Read error: Connection reset by peer) (~quassel@2a02:1210:1613:e600:6423:5a57:65aa:24f) | 10:37 | |
+ Nixkernal (~quassel@2a02:1210:1613:e600:1808:d1a5:ef99:c7b8) | 10:37 | |
- Nixkernal (QUIT: Client Quit) (~quassel@2a02:1210:1613:e600:1808:d1a5:ef99:c7b8) | 10:37 | |
- mjw (QUIT: Ping timeout: 256 seconds) (~mjw@gnu.wildebeest.org) | 10:44 | |
+ Nixkernal (~quassel@2a02:1210:1613:e600:94d3:6f05:5978:3b44) | 11:02 | |
+ mjw (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 11:03 | |
minute | the debugging reports on https://www.powerpc-notebook.org/en/ are eerily similar to our ls1028a stuff because of the qoriq stuff, rcw and everything | 12:20 |
- colinsane (QUIT: Read error: Connection reset by peer) (~colinunin@97-113-159-4.tukw.qwest.net) | 13:01 | |
+ colinsane (~colinunin@97-113-159-4.tukw.qwest.net) | 13:02 | |
- mtm (QUIT: Ping timeout: 255 seconds) (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 13:04 | |
hramrach | yes, that's why the RiscV is not particularly promising - the SoC manufacturers tend to make SoCs of different architecture by reusing existing design, and only replacing the CPU core, keeping all the problematic perpipherals that make the ARM SoCs hell. | 13:16 |
jn | at least on ARM you could rely on having somewhat predictable CPU cores (because ARM makes reference implementations, like the Cortex line, and architecture licenses are expensive) - on RISC-V you don't only get SoC hell, you also get CPU hell where every vendor implements a random set of instruction set extensions (speaking with slight hyperbole) | 13:30 |
- romi (QUIT: Write error: Connection reset by peer) (bd30729973@user/romi) | 13:34 | |
- tretinha (QUIT: Write error: Connection reset by peer) (3a571d9f43@2a03:6000:1812:100::1151) | 13:34 | |
- Zaba (QUIT: Remote host closed the connection) (80b9b4b35e@2a03:6000:1812:100::116) | 13:34 | |
- henesy (QUIT: Read error: Connection reset by peer) (d7619ffbc2@2a03:6000:1812:100::143) | 13:34 | |
- noam (QUIT: Remote host closed the connection) (81879d1ffa@2a03:6000:1812:100::dfc) | 13:34 | |
- cmahns (QUIT: Remote host closed the connection) (8fe824803c@2a03:6000:1812:100::10cd) | 13:34 | |
+ noam (81879d1ffa@2a03:6000:1812:100::dfc) | 13:34 | |
+ cmahns (8fe824803c@2a03:6000:1812:100::10cd) | 13:35 | |
+ henesy (d7619ffbc2@2a03:6000:1812:100::143) | 13:35 | |
+ tretinha (3a571d9f43@2a03:6000:1812:100::1151) | 13:35 | |
+ romi (bd30729973@user/romi) | 13:35 | |
+ Zaba (80b9b4b35e@2a03:6000:1812:100::116) | 13:35 | |
josch | 13:56 | |
+ mark_ (~mjw@gnu.wildebeest.org) | 14:15 | |
+ mtm (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 15:10 | |
josch | 14:47:59 up 5:27, 0 user, load average: 0.43, 0.26, 0.20 | 15:20 |
josch | so... | 15:20 |
josch | i bought a new set of eight eremit batteries and tested the runtime of my a311d reform with it in the following way | 15:20 |
josch | 1. i charged it all up to 100% and disabled upower switching off my reform on critical battery levels | 15:20 |
josch | 2. then i shut it down, removed the power cable and booted it up again | 15:21 |
+ chomwitt (~chomwitt@2a02:587:7a11:6600:1ac0:4dff:fedb:a3f1) | 15:21 | |
josch | 3. i started a "while sleep 1m; do ..." loop which sent the output of "uptime" to a remote machine every minute | 15:21 |
josch | i disabled my display switching off, so the display was at full brightness the whole time | 15:22 |
josch | and then i just used my reform normall, writing some python, looking things up in firefox, checking my mail, do some things on remote machines over ssh, that kind of stuff | 15:22 |
josch | the line above is the last uptime output before my reform died due to empty battery cells | 15:23 |
josch | so a311d reform with normal usage can last about 5.5 hours | 15:23 |
mjw | nice | 15:23 |
josch | what i find a bit upsetting is, that in the recent reviews by jeff geerling or thom holwerda, their a311d reform only lasted less than 4 hours. | 15:25 |
josch | i think this is because the lpc is by default configured to show 0% way too early | 15:26 |
josch | and then some part of the DE or upower switch off the machine way too early and the lpc can never learn what the actual 0% of the installed batteries is | 15:26 |
mjw | old boards seemed to drain the batteries beyond the point they could get recharged, so being conservative here seems somewhat reasonable | 15:27 |
josch | mjw: but new reforms, those that were sent out for review, have the protected battery boards installed | 15:28 |
mjw | ah, yeah | 15:29 |
josch | minute: would it make sense to change the default in the lpc? if reviewers saw 5.5 hours of runtime would probably not be described as "Battery life has been only so-so" or "It’s definitely not class-leading or anything" | 15:29 |
mjw | ACTION is about to get the new protected battery boards :) | 15:29 |
Zaba | the difference between 4 and 5.5 hours doesn't seem like much in an overall assessment | 15:41 |
josch | it's a 37.5% runtime improvement -- i'd call that very significant | 15:43 |
- pandora (QUIT: Quit: Connection closed for inactivity) (uid585533@id-585533.ilkley.irccloud.com) | 15:44 | |
josch | Zaba: the 4 hours i mentioned above are from the review of thom holwerda who talked about 3-4 hours. In the review by jeff geerling, the runtime was described as 2.5 hours and "You can probably get a bit more if you use it conservatively." -- i don't think that the reader expect a more than double battery runtime compared to the mentioned 2.5 hours | 15:48 |
Zaba | well yeah, 5.5 up from 2.5 is a big jump | 15:49 |
- bleb (QUIT: Ping timeout: 264 seconds) (~cm@user/bleb) | 15:53 | |
+ bleb (~cm@user/bleb) | 15:58 | |
+ bleb_ (~cm@user/bleb) | 15:58 | |
- jacobk (QUIT: Ping timeout: 268 seconds) (~quassel@64.189.201.150) | 16:22 | |
+ jacobk (~quassel@64.189.201.150) | 16:29 | |
- chomwitt (QUIT: Quit: WeeChat 3.8) (~chomwitt@2a02:587:7a11:6600:1ac0:4dff:fedb:a3f1) | 16:42 | |
- Nixkernal (QUIT: Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) (~quassel@2a02:1210:1613:e600:94d3:6f05:5978:3b44) | 17:21 | |
+ kop316 (m-6f6zq6@static.138.159.90.157.clients.your-server.de) | 17:21 | |
+ Nixkernal (~quassel@2a02:1210:1613:e600:e064:d3b8:33d1:5081) | 17:23 | |
+ vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:20) | 17:31 | |
- f_ (QUIT: Read error: Connection reset by peer) (~AUGESOUND@fases/developer/funderscore) | 18:33 | |
+ klardotsh (~klardotsh@c-67-170-115-80.hsd1.wa.comcast.net) | 18:34 | |
+ f_ (~AUGESOUND@fases/developer/funderscore) | 18:50 | |
sigrid | do people call reform "brutalist" because of its sharp angles? | 18:57 |
+ chomwitt (~chomwitt@2a02:587:7a11:6600:1ac0:4dff:fedb:a3f1) | 18:59 | |
+ ndufresne1 (~ndufresne@apple.collaboradmins.com) | 19:10 | |
minute | heh, console with sixel support https://github.com/uobikiemukot/yaft | 19:11 |
+ f__ (~AUGESOUND@fases/developer/funderscore) | 19:11 | |
+ hl_ (~hl@user/hl) | 19:11 | |
+ aard_ (~bwachter@217.11.60.132) | 19:11 | |
- qbit (QUIT: Ping timeout: 260 seconds) (~qbit@mail.suah.dev) | 19:12 | |
- chartreuse (QUIT: Ping timeout: 264 seconds) (~chartreus@S0106908d78501d1d.cg.shawcable.net) | 19:12 | |
- anzu (QUIT: Ping timeout: 264 seconds) (~anzu@melkki.cs.helsinki.fi) | 19:12 | |
- hl (QUIT: Ping timeout: 264 seconds) (~hl@user/hl) | 19:12 | |
- nocko (QUIT: Ping timeout: 264 seconds) (~nock@user/nocko) | 19:12 | |
- Aard (QUIT: Ping timeout: 264 seconds) (~bwachter@edna-edison.lart.info) | 19:12 | |
minute | josch: yeah i even got 5 hours from rk3588 | 19:12 |
+ chartreu1e (~chartreus@S0106908d78501d1d.cg.shawcable.net) | 19:12 | |
minute | sigrid: i think so | 19:12 |
- f_ (QUIT: Ping timeout: 260 seconds) (~AUGESOUND@fases/developer/funderscore) | 19:12 | |
- jacobk (QUIT: Ping timeout: 260 seconds) (~quassel@64.189.201.150) | 19:12 | |
- ndufresne (QUIT: Ping timeout: 260 seconds) (~ndufresne@apple.collaboradmins.com) | 19:12 | |
* ndufresne1 -> ndufresne | 19:12 | |
+ jacobk (~quassel@64.189.201.150) | 19:13 | |
+ qbit (~qbit@mail.suah.dev) | 19:13 | |
+ nocko (~nock@user/nocko) | 19:13 | |
* f__ -> f_ | 19:14 | |
- GNUmoon (QUIT: Remote host closed the connection) (~GNUmoon@gateway/tor-sasl/gnumoon) | 19:25 | |
josch | minute: yeah, 5 hours are a really nice runtime i think. At that point one starts getting the feeling that one can just leave the laptop somewhere and forget about it for a bit without having to worry that it will accidentally run out of battery power. | 19:25 |
josch | minute: i opened an issue here to not forget about this: https://source.mnt.re/reform/reform/-/issues/18 | 19:26 |
+ anzu (~anzu@melkki.cs.helsinki.fi) | 19:26 | |
minute | josch: thx | 19:26 |
minute | josch: i am currently looking into tuigreet again. at least i got it to build now | 19:26 |
josch | minute: i found the youtube video that jeff geerling used to benchmark the capacity with firefox playing it on fullscreen. Now that I have brand new cells, do you think it would be make sense if i repeated that benchmark and posted my results publicly? | 19:27 |
minute | josch: sure! | 19:27 |
josch | or would that be seen as me throwing shade in their direction | 19:28 |
minute | josch: no, it's cool... it's just another POV | 19:28 |
josch | okay :) | 19:28 |
- jacobk (QUIT: Ping timeout: 268 seconds) (~quassel@64.189.201.150) | 19:30 | |
minute | lmao > setfont: ERROR psffontop.c:179 read_fontfile: Font is too big | 19:35 |
minute | i tried: setfont /usr/share/consolefonts/spleen-32x64.psfu.gz | 19:35 |
hramrach | just get kmscon or mlterm if you want that | 19:45 |
hramrach | the fbcon is severely limited, and with the monolithic kernel approach every single line of code added is an attack surface increase so there is strong resistance to adding major features there | 19:46 |
minute | hramrach: makes sense | 19:47 |
minute | in any case, i have decided to go with tuigreet, it works nicely now | 19:47 |
hramrach | "The setfont command reads a font from the file font.new and loads it into the EGA/VGA character generator" ... | 19:48 |
minute | i just have to get rid of kernel messages on its tty | 19:48 |
minute | greetd uses tty7 already, i thought the messages only go to tty1 | 19:48 |
minute | i.e. i am getting wifi spam printed over the login form | 19:49 |
hramrach | using a different terminal might get rid of those messages as a sideeffect as well | 19:52 |
hramrach | there used to be a problem starting a graphical session from kmscon, interestingly. That's quite curious ginven you can start X from X. Well, it used to work, maybe not anymore with the session/seat nonsense today. | 19:59 |
minute | yeah, i don't wanna introduce tooooo many nonstandard things by default though | 20:12 |
- sbp (QUIT: Changing host) (~sbp@tea.infomesh.net) | 20:17 | |
+ sbp (~sbp@apache/doge/sbp) | 20:17 | |
minute | ok, loglevel of 4 (instead of 7) gets rid of the spam | 20:22 |
minute | ok, will try to fix the issues with this MR https://source.mnt.re/reform/reform-debian-packages/-/merge_requests/25 | 20:29 |
- mjw (QUIT: Killed (lithium.libera.chat (Nickname regained by services))) (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 20:37 | |
* mark_ -> mjw | 20:37 | |
+ Guest3510 (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 20:37 | |
minute | tuigreet aarch64 build https://source.mnt.re/reform/reform-tuigreet/-/jobs/3565/artifacts/browse/tuigreet/target/aarch64-unknown-linux-gnu/release/ | 21:31 |
+ jacobk (~quassel@utdpat242017.utdallas.edu) | 21:55 | |
josch | minute: do you think you are happy enough with tuigreet such that i can start spending time on packaging it? | 22:10 |
josch | can MR !24 in reform-debian-package bbe closed? | 22:13 |
minute | josch: yes, happy enough with it | 22:14 |
minute | josch: yes, !24 can be closed :3 | 22:14 |
minute | josch: the only thing i don't like about tuigreet is the window title "Authenticate into ${HOSTNAME}", it sounds a bit strange | 22:15 |
josch | maybe upstream can be convinced to make that configurable? | 22:16 |
minute | i would like to change this to "Login to ${HOSTNAME}" | 22:16 |
minute | yeah, currently it comes from a file contrib/locales/en-US/tuigreet.ftl | 22:16 |
minute | which is included in the binary | 22:16 |
minute | so during my build process i can just change that line | 22:16 |
josch | hrm... that doesn't sound like it should be configurable at run-time | 22:21 |
josch | i find it a bit odd that files like these are just embedded into the binary instead of being sourced from /usr/share or from /etc or from $XDG_CONFIG_HOME or some such | 22:27 |
minute | woah why the hell can't i rebase the rk3588-reform2 branch | 22:30 |
minute | it's always changing?! | 22:30 |
minute | are you working on rebasing it at the same time maybe? | 22:30 |
minute | so i did a rebase but then hint: Updates were rejected because the tip of your current branch is behind | 22:31 |
minute | ah | 22:31 |
minute | git pull --rebase did the trick | 22:31 |
minute | but the ui still says > Merge blocked: the source branch must be rebased onto the target branch. | 22:31 |
josch | huh, i'll have a look | 22:32 |
minute | ah because my local main was behind i guess | 22:32 |
minute | i will rebase again | 22:32 |
josch | seems other people also observe the problem of kernel log messages overwriting things: https://github.com/apognu/tuigreet/issues/68 | 22:34 |
minute | josch: yeah i already solved this | 22:35 |
minute | by changing the default log level :D | 22:36 |
minute | (to warning+) | 22:36 |
minute | hmm i always fail to rebase this | 22:38 |
josch | minute: somehow there are commits of mine in the middle of your patch stack (according to the web ui) | 22:40 |
minute | ah i had to force push after rebase | 22:42 |
minute | lol the history looks like a huge mess | 22:43 |
minute | i guess i'll have to completely redo this branch | 22:46 |
minute | but not today, too tired already | 22:46 |
josch | minute: i also noticed that some of your patches are against 6.6 and others are against 6.7 | 22:48 |
minute | josch: yeah | 22:48 |
minute | josch: i wanted to add the pocket-a311d patches to 6.7. as well | 22:49 |
josch | minute: i suggest you work on patches for 6.7+ and let me do the work for 6.6 because the latter is not relevant for you as the MNT repos only do unstable | 22:49 |
minute | josch: ok | 22:49 |
josch | minute: your patch stack should not include the "linux: rebase patches on 6.7.1" commit as that one is already in main | 22:51 |
josch | maybe i find some time to clean this up a bit tonight but if so, i'll do that in another branch, no worries :) | 22:52 |
- Gooberpatrol_66 (QUIT: Ping timeout: 260 seconds) (~Gooberpat@user/gooberpatrol66) | 23:14 | |
minute | josch: ok cool ^^ | 23:17 |
- chomwitt (QUIT: Quit: WeeChat 3.8) (~chomwitt@2a02:587:7a11:6600:1ac0:4dff:fedb:a3f1) | 23:36 | |
+ Gooberpatrol_66 (~Gooberpat@user/gooberpatrol66) | 23:51 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!