josch | minute: is this your source of qcacld2 firmware? https://github.com/boundarydevices/qca-firmware | 00:29 |
---|---|---|
josch | bdwlan30.bin and otp30.bin are the same as the one MNT ships but qwlan30.bin differs for some reason... | 00:30 |
josch | i'm so smart -- apparently i already did all the work 3 months ago and completely forgot that i did it: https://salsa.debian.org/debian/ezurio-qca-firmware | 00:42 |
josch | [insert i-have-no-memory-of-this-place meme] | 00:43 |
minute | :0 | 00:43 |
josch | minute: yup, you answered my questions of today back in march: https://mntre.com/reform-irc-logs/2024-03-27.log.html#t13:13:08 | 00:45 |
josch | [PATCH v16 0/8] Initial support Cadence MHDP8501(HDMI/DP) for i.MX8MQ | 01:26 |
josch | minute: the saga continues with v16: https://lore.kernel.org/lkml/cfc1c9a2a2cc6280efd353702f43ef958ff90d5b.1719903904.git.Sandor.yu@nxp.com/T/ | 01:26 |
- _E (QUIT: Quit: hi) (~e@bsd.moe) | 02:53 | |
+ reform22921 (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 02:57 | |
* reform22921 -> mtm-pocket | 02:58 | |
- nsc (QUIT: Ping timeout: 264 seconds) (~nicolas@104-97-142-46.pool.kielnet.net) | 03:08 | |
+ nsc (~nicolas@4-99-142-46.pool.kielnet.net) | 03:10 | |
mtm-pocket | josch: got bluetooth working on boot with my changes to reform-hw-setup. My account on source.mnt.re hasn't been approved yet, let me know it you just want the patch | 03:19 |
jfred | hoping my pocket will ship soon. it's a purple hyper though and sounds like they were the last ones out haha | 03:26 |
mtm-pocket | jfred: I have the purple non-hyper, very impressive piece of kit. The screen quality was beyond what I was expecting | 03:27 |
- colinsane (QUIT: Quit: bye) (~colinunin@97-113-64-230.tukw.qwest.net) | 03:33 | |
+ colinsane (~colinunin@97-113-64-230.tukw.qwest.net) | 03:38 | |
jfred | that purple is a very pretty color | 03:46 |
jfred | need to try and get the custom top panel I was working on put together, I bet it'd look cool with a white cover too | 03:48 |
- mtm-pocket (QUIT: Remote host closed the connection) (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 04:19 | |
- vagrantc (QUIT: Ping timeout: 246 seconds) (~vagrant@2600:3c01:e000:21:7:77:0:50) | 04:27 | |
- cobra (QUIT: Ping timeout: 256 seconds) (~cobra@user/Cobra) | 04:36 | |
- bkeys (QUIT: Remote host closed the connection) (~Thunderbi@45.134.140.153) | 05:22 | |
- murphnj (QUIT: Quit: Leaving) (~murph@user/murphnj) | 05:40 | |
- akira (QUIT: Read error: Connection reset by peer) (~akira@2a01:599:a2b:694a:816d:9d4b:fe4:a6f7) | 06:20 | |
+ akira (~akira@ip2504e6e1.dynamic.kabel-deutschland.de) | 06:20 | |
josch | mtm: patch by mail works fine! josch@debian.org | 06:35 |
+ rvense (~niklas@152.115.193.19) | 07:13 | |
- rvense (QUIT: Changing host) (~niklas@152.115.193.19) | 07:13 | |
+ rvense (~niklas@user/rvense) | 07:13 | |
+ robin_ (~robin@user/terpri) | 07:45 | |
- robin (QUIT: Ping timeout: 264 seconds) (~robin@user/terpri) | 07:48 | |
josch | amospalla: thank you for your input! the firmware package has now been uploaded to Debian unstable (non-free-firmware) and is waiting for review by ftp-master: https://ftp-master.debian.org/new/ezurio-qca-firmware_0.0~git20230404.bad01ca-1.html | 08:22 |
josch | minute: setting loglevel=3 was mainly to not make the kernel/systemd print stuff over tuigreet? There seems to be a fix that can be applied to greetd: https://github.com/apognu/tuigreet/issues/68#issuecomment-2001807691 | 08:52 |
josch | i didn't hear about TTYReset = true; TTYVHangup = true; TTYVTDisallocate = true; in systemd services before | 08:53 |
- rvense (QUIT: Ping timeout: 255 seconds) (~niklas@user/rvense) | 09:03 | |
+ vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:50) | 09:05 | |
- vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:7:77:0:50) | 09:12 | |
+ rvense (~niklas@user/rvense) | 09:20 | |
- rvense (QUIT: Ping timeout: 272 seconds) (~niklas@user/rvense) | 09:55 | |
+ gustav28 (~gustav@c-2f35524e.019-141-67626730.bbcust.telenor.se) | 10:02 | |
minute | josch: interestinng, me neither i think | 10:10 |
amospalla | josch: great! thank you for your work, it is a lot of work what you're doing. | 12:10 |
- akira (QUIT: Ping timeout: 255 seconds) (~akira@ip2504e6e1.dynamic.kabel-deutschland.de) | 12:13 | |
+ akira (~akira@2a01:599:a30:72b9:dda5:8865:cd9:15d7) | 12:14 | |
minute | josch: the reviewer of the hdmi patch doesn't seem to be happy about it yet :D | 12:15 |
josch | yup, i read that :) | 12:15 |
josch | we'll be going for v17 :) | 12:15 |
minute | oof oof :D | 12:15 |
minute | extremely unrelated, but i just looked at the lattepanda mu again... it's cool that they have kicad example files and everything | 12:15 |
minute | i wonder if people would be interested in a spin of reform next that supports that module | 12:16 |
minute | i mean, spin of next motherboard | 12:16 |
minute | the motherboard is much less complex now so adapting to different module form factors is feasible for the first time | 12:16 |
minute | the mu is also extremely cheap at $139 | 12:17 |
minute | well, later i guess :D | 12:20 |
josch | oh it's an intel n100 board | 12:21 |
minute | yeah | 12:21 |
josch | up to 35W TDP doesn't sound that nice though, no? :D | 12:22 |
minute | no :D | 12:22 |
minute | but it's not clear what "up to" really means | 12:22 |
minute | i.e. in what cases does it draw that much | 12:23 |
josch | yeah, probably throttles automatically when it becomes too hot | 12:23 |
minute | normally the processor is rated 6W TDP | 12:23 |
minute | so i don't get what that 35W figure is about | 12:23 |
minute | according to reports, the n100 seems to be very jumpy in terms of power draw... eats a lot when at 100% and 2.9ghz | 12:25 |
minute | well well. i guess i'm just anxious what to do post-rk3588, like next year :D | 12:26 |
minute | because snapdragon x elite is so much faster in benchmarks | 12:27 |
josch | isn't post-rk3588 the time of reform-next? you want it to be even faster? | 12:29 |
minute | reform-next starts with rk3588 yeah | 12:31 |
minute | then there's qcs6490 as a slightly faster, but less ram (8GB) option | 12:32 |
minute | but after that... no idea yet | 12:33 |
josch | maybe an intel option is not that bad for people who rely on proprietary x86 applications | 12:34 |
josch | there seems to be quite some hype about riscv but no idea whether that's just hype or whether enough people would really put money down for it just because it's riscv | 12:34 |
josch | i'd expect "flat reform" i.e. reform next to become a very attractive option for many | 12:35 |
minute | i think riscv is mostly still a tech hype at this point. but one could look at dc-roma to see how many people invested in that | 12:35 |
josch | vagrantc has one and is tooting about their adventures with it :) | 12:37 |
minute | oh! i need to check that :D | 12:39 |
+ rvense (~niklas@152.115.193.19) | 12:40 | |
- rvense (QUIT: Changing host) (~niklas@152.115.193.19) | 12:40 | |
+ rvense (~niklas@user/rvense) | 12:40 | |
chartreuse | It'd be very limiting, but a low cost/complexity fpga board could be neat to see what people make with it, or a combination of fpga and a simpler micro like a RP2040 | 13:06 |
chartreuse | https://github.com/rscott2049/DECstation2040 | 13:06 |
chartreuse | Kinda an inspiration there of what can be possible in such a setup. | 13:07 |
chartreuse | How many RP2040's can fit on a CPU card :P | 13:07 |
chartreuse | Though I think a setup like that would probably more benefit from a more minimal laptop chasis without some of the complexity of the reform | 13:08 |
minute | chartreuse: yep, fpga is also very interesting. the kintex-7 board was more like an overpriced POC but would be interesting to make something cost-effective | 13:11 |
chartreuse | I think that's just my mind saying I should revisit one of my earlier goals of making one of my retro homebrew computers into a laptop | 13:11 |
minute | :D | 13:11 |
minute | well, you're not alone... i also would like a zero-latency c64/amiga thing :D | 13:12 |
chartreuse | Even FPGAs in the ~10k logic elements can be setup to do some quite impressive things. | 13:12 |
chartreuse | Hardest part of a laptop is going to likely be driving the 1080p screen effectively, just due to the sheer data and bandwidth. | 13:13 |
minute | i did that on spartan 6 and zynq 7020 so far | 13:14 |
minute | in doubt you can always pixel-double in the scanout engine :D | 13:14 |
minute | ah sorry and did it on kintex-7 obviously... with external DP encoder chip | 13:14 |
minute | but on that one i just used the existing framebuffer impl from litex | 13:15 |
minute | i haven't really used anything outside of xilinx though... only once played with some tiny lattice thing in the fomu | 13:15 |
chartreuse | Maybe with an external RGBHV to DP chip then something could be done with smaller fpgas like a couple ICE40's to have an FPGA board with an open toolchain itself | 13:16 |
chartreuse | Or other fpgas with an open source toolchain | 13:16 |
chartreuse | Though of course don't want to make it so complex that it pushes the price up again. | 13:17 |
minute | yes, it wouldn't be a problem with ecp5 or maybe even possible with ice40 and some pixel doubling... it mostly also depends on sdram/hyperram bandwidth | 13:17 |
minute | there's also some newer ones like the gowin stuff but have no experience with them whatsoever | 13:18 |
chartreuse | I guess an idea there could be a dual fpga approach, so that one could essentially be dedicated as a display driver, and the other would be more open to experimentation in CPU design and such | 13:19 |
chartreuse | With each having a separate ram chip possible, or having the ram coordinated through the display one | 13:19 |
chartreuse | Though a single ECP5 likely has it, and is only in the ~$100 ballpark | 13:20 |
chartreuse | Just my brain speculating, I'm not even sure what an ideal setup would be | 13:21 |
minute | unrelatedly, it looks like we'll be getting vulkan for G52 even... previously it was said to be "not worth it" IIRC https://gitlab.freedesktop.org/marysaka/mesa/-/commit/b06661aaf333967497b201b50edd64612ed8955c | 13:23 |
- rvense (QUIT: Ping timeout: 255 seconds) (~niklas@user/rvense) | 13:27 | |
minute | https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29639 | 13:29 |
minute | in any case, i have to say reform with rk3588 is a very comfy computer. can't wait to ship those modules | 13:34 |
chartreuse | The extra performance and plenty of ram seem like it'd make the reform much more comfortable when having to deal with heavy web apps | 13:41 |
chartreuse | Web apps are really the only thing I feel that makes the reform (imx8mq) feel slow | 13:42 |
- akira (QUIT: Read error: Connection reset by peer) (~akira@2a01:599:a30:72b9:dda5:8865:cd9:15d7) | 13:42 | |
+ akira (~akira@ip2504e6e1.dynamic.kabel-deutschland.de) | 13:43 | |
minute | chartreuse: yeah, i have (regrettably) switched to chromium on my rk3588 reform and there's almost no noticeable difference in everyday web performance between it and my i9 desktop | 13:50 |
josch | minute: i don't know how feasible it would be to go into a completely different direction than improving the performance: is there an easy SoM option with very minimal power draw which will get us more than 5 hours of battery life? | 14:54 |
josch | i remember that some people find 5 hours atrocious... | 14:54 |
minute | josch: those people are not the target group :D | 14:54 |
josch | fair enough! :D | 14:55 |
minute | josch: i mean, those people would find a processor that is so low power atrocious as well | 14:55 |
josch | ah good point | 14:55 |
josch | i find myself reminded of people dissing the range of electric cars even though their avarage commute distance is at around 10-20 km per day... | 14:56 |
josch | it just has to have a range of 600+ km for the one time in the year when you'd need that :) | 14:56 |
minute | :D | 14:58 |
mtm | minute: minor wish for upcoming board designs: adding a few ground "eyes" to clip test equipment to. Trying to debug the Pocket keyboard it was difficult to get my scope probe ground connected | 15:38 |
minute | mtm: good point | 15:41 |
mtm | josch: patch sent | 15:53 |
+ jagtalon (~jagtalon@pool-100-34-179-37.phlapa.fios.verizon.net) | 15:57 | |
- colinsane (QUIT: Quit: bye) (~colinunin@97-113-64-230.tukw.qwest.net) | 16:11 | |
+ colinsane (~colinunin@97-113-64-230.tukw.qwest.net) | 16:15 | |
+ rvense (~niklas@user/rvense) | 16:58 | |
- jagtalon (QUIT: Remote host closed the connection) (~jagtalon@pool-100-34-179-37.phlapa.fios.verizon.net) | 17:14 | |
- rvense (QUIT: Ping timeout: 272 seconds) (~niklas@user/rvense) | 17:36 | |
+ rvense (~niklas@user/rvense) | 18:19 | |
josch | mtm: thank you! It now lives here: https://source.mnt.re/reform/reform-tools/-/merge_requests/75 | 18:57 |
- rvense (QUIT: Ping timeout: 252 seconds) (~niklas@user/rvense) | 19:27 | |
minute | josch: mtm: this feels slightly strange, what if i want to block bluetooth on purpose? where is this preference stored? | 19:34 |
josch | good point | 19:35 |
+ reform1187 (~matt@184-23-21-40.fiber.dynamic.sonic.net) | 19:45 | |
* reform1187 -> photomattmills | 19:45 | |
jfred | minute: Looking forward to those modules shipping too! | 19:56 |
jfred | And, since I'm starting to have Reform modules piling up a bit... when the Reform Next goes up for sale, do you think ordering it without a CPU module will be an option? | 19:57 |
ch | josch, mtm: the kernel default should be unblocked by default, assuming rfkill.default_state=0 is not on the cmdline | 20:10 |
josch | ch: yes, but the current hack does not respect this | 20:12 |
ch | i guess what i'm saying is: if unblock does something, then userspace messed up before | 20:12 |
- photomattmills (QUIT: Quit: Leaving) (~matt@184-23-21-40.fiber.dynamic.sonic.net) | 20:13 | |
josch | ch: userspace? this seems to be a kernel regression | 20:13 |
ch | well. rfkill should be able to tell you the state before running unblock | 20:17 |
ch | if its not blocked before, then that will be interesting | 20:17 |
josch | yes, we do not know why this happens and are looking for a workaround until somebody finds out | 20:18 |
mtm | before the patch 'rfkill' showed bluetooth being soft-blocked; that was not the case with the previous kernel | 20:20 |
- akira (QUIT: Ping timeout: 252 seconds) (~akira@ip2504e6e1.dynamic.kabel-deutschland.de) | 20:21 | |
- sevan (QUIT: Changing host) (~sevan@2001:470:1f1d:1d6:5a55:caff:fe24:ed4) | 20:23 | |
+ sevan (~sevan@user/venture37) | 20:23 | |
+ akira (~akira@37.4.230.225) | 20:30 | |
- gustav28 (QUIT: Quit: Quit) (~gustav@c-2f35524e.019-141-67626730.bbcust.telenor.se) | 20:36 | |
+ gustav28 (~gustav@c-2f35524e.019-141-67626730.bbcust.telenor.se) | 20:40 | |
mtm | can someone with a Pocket still running linux 6.7.12 show the results from 'cat /var/lib/systemd/rfkill/*bluetooth'. On 6.9.7 it shows 0, which will soft block bluetooth on boot. It's supposed to track your desired state to restore it on the next boot but mine seems to be stuck on 0 even if I unblock bluetooth | 20:57 |
ch | cant say the rfkill definition in linux/imx8mp-mnt-reform2.dts makes any sense to me. the referenced pin seems not connected | 20:58 |
- colinsane (QUIT: Quit: bye) (~colinunin@97-113-64-230.tukw.qwest.net) | 21:10 | |
+ colinsane (~colinunin@97-113-64-230.tukw.qwest.net) | 21:14 | |
ch | (scratch that) | 21:42 |
violet | mtm: 6.7.12 here. have not system updated my pocket yet since getting it. `cat /var/lib/systemd/rfkill/*bluetooth` returns `0` | 21:45 |
violet | does the pocket have a similar battery drain thing as the full size reform used to when its not in use? | 21:47 |
- gustav28 (QUIT: Quit: Quit) (~gustav@c-2f35524e.019-141-67626730.bbcust.telenor.se) | 22:15 | |
mtm | violet: thanks! | 22:31 |
mtm | not sure on the battery drain; the batteries are a different chemistry though. It's hard for me to compare because I have suspend working on my Reform, not so much on the Pocket | 22:34 |
violet | i had my thing powered off and when i turned it back on it said it was at 1% | 23:48 |
ch | https://community.mnt.re/t/reprogramming-the-pocket-keyboard/2109 | 23:50 |
ch | seems related | 23:50 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!