+ bkeys (~Thunderbi@199.226-24.cm.ptn.tftn.dynamic.friendlycity.net) | 00:07 | |
+ bkeys1 (~Thunderbi@199.226-24.cm.ptn.tftn.dynamic.friendlycity.net) | 00:10 | |
- bkeys (QUIT: Ping timeout: 276 seconds) (~Thunderbi@199.226-24.cm.ptn.tftn.dynamic.friendlycity.net) | 00:12 | |
* bkeys1 -> bkeys | 00:12 | |
cinap_lenrek | i wonder | 00:12 |
---|---|---|
cinap_lenrek | i'd be nice to have a serial port connector somehow | 00:13 |
cinap_lenrek | for the mnt reform | 00:13 |
cinap_lenrek | right now, i have a dupond connector hooked up and the back is open | 00:13 |
cinap_lenrek | i'm a desaster when it comes to mechanics | 00:13 |
- bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@199.226-24.cm.ptn.tftn.dynamic.friendlycity.net) | 00:14 | |
+ bkeys (~Thunderbi@199.226-24.cm.ptn.tftn.dynamic.friendlycity.net) | 00:14 | |
cinap_lenrek | i'm just thinking if theres a good compromize thats better than having the serial cable wires dangeling thru the bottom plate | 00:14 |
kfx | cinap_lenrek: I drilled a hole in my side plate | 00:17 |
kfx | and fed the cable through that | 00:17 |
kfx | when I don't have the cable in I just shove a rubber grommet in the hole | 00:17 |
cinap_lenrek | hahahaha | 00:18 |
cinap_lenrek | perfect | 00:18 |
cinap_lenrek | maybe i can fiddle the cables thru the supports of the display | 00:18 |
cinap_lenrek | but then i'd need some kind of planar connector | 00:18 |
cinap_lenrek | maybe such a thing exists | 00:18 |
cinap_lenrek | but yeah | 00:19 |
cinap_lenrek | could also drill a hole or dremel a window | 00:19 |
kfx | side plates are cheap, I have like three sets | 00:19 |
cinap_lenrek | hold on | 00:20 |
cinap_lenrek | the sideplace is a discrete part | 00:20 |
kfx | yes | 00:20 |
cinap_lenrek | dude | 00:20 |
kfx | originally when I wanted the serial cable on for a while I'd just remove the side plate entirely | 00:20 |
cinap_lenrek | what where i thinking | 00:20 |
cinap_lenrek | i can just 3d print one | 00:21 |
kfx | also true? I lack that technology | 00:21 |
cinap_lenrek | perfect | 00:22 |
cinap_lenrek | thanks | 00:22 |
cinap_lenrek | maybe it even already exists | 00:23 |
cinap_lenrek | kfx: lemme look into it | 00:24 |
- bkeys (QUIT: Ping timeout: 240 seconds) (~Thunderbi@199.226-24.cm.ptn.tftn.dynamic.friendlycity.net) | 00:25 | |
kfx | the side plates are svg files | 00:28 |
kfx | I have mine laser-cut by some shop | 00:28 |
cinap_lenrek | yeah | 00:29 |
cinap_lenrek | i found them | 00:29 |
kfx | looks like lukas added step files since I last looked | 00:29 |
+ bkeys (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 00:36 | |
cinap_lenrek | ok | 00:36 |
cinap_lenrek | this is perfect | 00:36 |
- bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 00:38 | |
+ bkeys (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 00:38 | |
- bkeys (QUIT: Ping timeout: 248 seconds) (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 00:45 | |
cinap_lenrek | haha | 00:46 |
cinap_lenrek | i was looking for connector options for the 3v3 uart | 00:46 |
cinap_lenrek | it seems people use the coaxial headphone jack? | 00:47 |
kfx | pinebook pro does that | 00:49 |
kfx | it's super annoying because you have to disassemble the laptop to flip the switch to get headphone audio back | 00:49 |
cinap_lenrek | HAHAHAHA | 00:49 |
- mjw (QUIT: Quit: Leaving) (~mark@gnu.wildebeest.org) | 00:58 | |
- Ar|stote|is (QUIT: Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) (~linx@149-210-28-104.mobile.nym.cosmote.net) | 01:00 | |
+ Ar|stote|is (~linx@149-210-28-104.mobile.nym.cosmote.net) | 01:00 | |
+ bkeys (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 01:01 | |
- Christoph_ (QUIT: Remote host closed the connection) (~Christoph@p4fe7356a.dip0.t-ipconnect.de) | 01:08 | |
- S0rin (QUIT: Ping timeout: 248 seconds) (~S0rin@user/s0rin) | 01:24 | |
+ erle_reform (~erle_refo@86-82-248-88.fixed.kpn.net) | 01:24 | |
+ S0rin (~S0rin@user/s0rin) | 01:29 | |
+ erle_reform41 (~erle_refo@86-82-248-88.fixed.kpn.net) | 01:31 | |
- erle_reform (QUIT: Ping timeout: 252 seconds) (~erle_refo@86-82-248-88.fixed.kpn.net) | 01:33 | |
+ erle_reform (~erle_refo@86-82-248-88.fixed.kpn.net) | 01:36 | |
- erle_reform41 (QUIT: Ping timeout: 252 seconds) (~erle_refo@86-82-248-88.fixed.kpn.net) | 01:39 | |
- erle_reform (QUIT: Ping timeout: 252 seconds) (~erle_refo@86-82-248-88.fixed.kpn.net) | 01:47 | |
+ mtm (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 02:16 | |
- bkeys (QUIT: Ping timeout: 246 seconds) (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 04:33 | |
- sigrid (QUIT: *.net *.split) (~sigrid@ftrv.se) | 06:21 | |
- ezequielg (QUIT: *.net *.split) (sid363064@id-363064.uxbridge.irccloud.com) | 06:21 | |
- skalk (QUIT: *.net *.split) (~skalk@vond.sysret.de) | 06:21 | |
+ sigrid (~sigrid@ftrv.se) | 06:22 | |
+ skalk (~skalk@vond.sysret.de) | 06:22 | |
+ ezequielg (sid363064@id-363064.uxbridge.irccloud.com) | 06:22 | |
- verx (QUIT: *.net *.split) (~verx@matrix.16bit.dev) | 06:27 | |
- flowy (QUIT: *.net *.split) (~flowy@2a01:4f8:c0c:1a8f::1) | 06:27 | |
- hl (QUIT: *.net *.split) (~hl@user/hl) | 06:27 | |
+ flowy (~flowy@2a01:4f8:c0c:1a8f::1) | 06:27 | |
+ verx (~verx@matrix.16bit.dev) | 06:27 | |
+ hl (~hl@user/hl) | 06:27 | |
- yuu_ (QUIT: *.net *.split) (sid267332@id-267332.ilkley.irccloud.com) | 06:30 | |
- lexik (QUIT: *.net *.split) (~lexik@171.25.222.230) | 06:30 | |
- sbates (QUIT: *.net *.split) (sid451432@id-451432.ilkley.irccloud.com) | 06:30 | |
+ yuu_ (sid267332@id-267332.ilkley.irccloud.com) | 06:30 | |
+ sbates (sid451432@id-451432.ilkley.irccloud.com) | 06:30 | |
+ lexik (~lexik@171.25.222.230) | 06:30 | |
+ Kooda2 (~kooda@natsu.upyum.com) | 06:52 | |
- scops (QUIT: Ping timeout: 272 seconds) (~scopstchn@2001:470:69fc:105::8da) | 06:53 | |
- Kooda (QUIT: Ping timeout: 272 seconds) (~kooda@natsu.upyum.com) | 06:53 | |
+ scops (~scopstchn@2001:470:69fc:105::8da) | 07:06 | |
ex-parrot | evening | 08:28 |
ex-parrot | there was a new trackball firmware? | 08:28 |
+ MajorBiscuit (~MajorBisc@wlan-145-94-167-213.wlan.tudelft.nl) | 08:32 | |
- MajorBiscuit (QUIT: Ping timeout: 268 seconds) (~MajorBisc@wlan-145-94-167-213.wlan.tudelft.nl) | 08:51 | |
- GNUmoon (QUIT: *.net *.split) (~GNUmoon@gateway/tor-sasl/gnumoon) | 09:07 | |
- mlarkin (QUIT: Ping timeout: 260 seconds) (~mlarkin@047-048-086-214.biz.spectrum.com) | 09:15 | |
+ mlarkin (~mlarkin@047-048-086-214.biz.spectrum.com) | 09:15 | |
+ MajorBiscuit (~MajorBisc@wlan-145-94-167-213.wlan.tudelft.nl) | 09:29 | |
- MajorBiscuit (QUIT: Ping timeout: 246 seconds) (~MajorBisc@wlan-145-94-167-213.wlan.tudelft.nl) | 09:50 | |
+ mjw (~mark@gnu.wildebeest.org) | 09:58 | |
+ MajorBiscuit (~MajorBisc@wlan-145-94-167-213.wlan.tudelft.nl) | 10:20 | |
- MajorBiscuit (QUIT: Ping timeout: 268 seconds) (~MajorBisc@wlan-145-94-167-213.wlan.tudelft.nl) | 10:41 | |
+ MajorBiscuit (~MajorBisc@wlan-145-94-167-213.wlan.tudelft.nl) | 10:46 | |
- MajorBiscuit (QUIT: Ping timeout: 248 seconds) (~MajorBisc@wlan-145-94-167-213.wlan.tudelft.nl) | 10:51 | |
+ MajorBiscuit (~MajorBisc@wlan-145-94-167-213.wlan.tudelft.nl) | 11:05 | |
- MajorBiscuit (QUIT: Ping timeout: 264 seconds) (~MajorBisc@wlan-145-94-167-213.wlan.tudelft.nl) | 11:11 | |
+ MajorBiscuit (~MajorBisc@wlan-145-94-167-213.wlan.tudelft.nl) | 11:22 | |
- MajorBiscuit (QUIT: Ping timeout: 248 seconds) (~MajorBisc@wlan-145-94-167-213.wlan.tudelft.nl) | 11:35 | |
+ MajorBiscuit (~MajorBisc@wlan-145-94-167-213.wlan.tudelft.nl) | 11:45 | |
- MajorBiscuit (QUIT: Ping timeout: 248 seconds) (~MajorBisc@wlan-145-94-167-213.wlan.tudelft.nl) | 11:51 | |
+ MajorBiscuit (~MajorBisc@wlan-145-94-167-213.wlan.tudelft.nl) | 12:11 | |
- MajorBiscuit (QUIT: Ping timeout: 264 seconds) (~MajorBisc@wlan-145-94-167-213.wlan.tudelft.nl) | 12:33 | |
vkoskiv | The trackball fw was last touched 3 months ago | 12:41 |
josch | vkoskiv: did you have a chance to look at blender? otherwise i think it'd be better to disable building blender until it gets fixed because i'll be away on holidays for 10 days starting this thursday | 12:54 |
vkoskiv | josch: Only briefly, investigating more today after work. | 13:02 |
vkoskiv | Brief look indicated it might be a small patch to fix it, but I didn't try it yet. | 13:03 |
+ mark (~mjw_@2001:1c06:2488:1400:9e5c:8eff:fe8f:a440) | 13:21 | |
- mjw (QUIT: Killed (NickServ (GHOST command used by mark!~mjw_@2001:1c06:2488:1400:9e5c:8eff:fe8f:a440))) (~mark@gnu.wildebeest.org) | 13:23 | |
* mark -> mjw | 13:23 | |
+ mark__ (~mark@gnu.wildebeest.org) | 13:24 | |
+ MajorBiscuit (~MajorBisc@wlan-145-94-167-213.wlan.tudelft.nl) | 13:33 | |
+ Christoph_ (~Christoph@p54bf604a.dip0.t-ipconnect.de) | 13:33 | |
flowy | anyone interested in signal on linux/aarch64, this person http://elagost.com/flatpak/ is maintaining a flatpak that is now being built by gitlab CI. runs well for me | 13:49 |
- mtm (QUIT: Ping timeout: 256 seconds) (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 14:04 | |
+ bkeys (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 14:13 | |
vkoskiv | I just remembered that binfmts exist. | 14:30 |
vkoskiv | I'll try to set up transparent running of x86 binaries, most notably Ripcord on my reform. | 14:31 |
vkoskiv | I wonder how safe dpkg --add-architecture is. I'm assuming it won't mess up any existing packages. | 14:31 |
josch | vkoskiv: correct, `dpkg --add-architecture` does nothing else than enable the architecture so that you can download and install packages from that arch with apt afterwards | 14:34 |
josch | you can only call dpkg --remove-architecture after having removed all packages from that foreign architecture first | 14:34 |
vkoskiv | Cool. As far as I know I need an x86 libc at least to run dynamically linked binaries | 14:35 |
vkoskiv | With qemu. | 14:35 |
josch | yes, but that will get installed automatically when you install a foreign arch binary | 14:36 |
josch | the dependency system is taking care of pulling it in | 14:36 |
vkoskiv | In this case it's a proprietary software that I just downloaded as an AppImage off the web manually. | 14:36 |
josch | oh :D | 14:37 |
vkoskiv | Hasn't been ported to aarch64 yet, sadly. A lovely, lightweight discord/slack client | 14:37 |
josch | vkoskiv: yes, then you need to run "sudo apt install libc6:arm64" manually first | 14:37 |
josch | errr... "sudo apt install libc6:amd64" | 14:37 |
vkoskiv | Yeah, amd64 is more helpful :D | 14:38 |
- bkeys (QUIT: Ping timeout: 248 seconds) (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 14:40 | |
vkoskiv | I noticed /dev/kvm is there. Does the i.MX8MQ support any hw virtualization? | 14:42 |
sigrid | no | 14:42 |
sigrid | ripcord works with box64 | 14:43 |
vkoskiv | Unfamiliar with that | 14:43 |
sigrid | i couldn't make it run on debian specifically (because everything there seems to be old? idc anyway) but on void it's fine | 14:44 |
sigrid | https://github.com/ptitSeb/box64 | 14:44 |
+ bkeys (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 14:44 | |
sigrid | ripcord's author told me he might do an aarch64 build someday but so far box64 is the way on the reform, it seems | 14:46 |
vkoskiv | Yeah I asked about that too | 14:47 |
josch | if people want to use box64 on the reform, maybe i should package it for debian? Would anybody like to use such a package? | 14:51 |
vkoskiv | I set it all up with qemu, but it's still throwing an exec format error. | 14:52 |
vkoskiv | I see the binfmt thing is enabled. | 14:52 |
josch | vkoskiv: can you paste the output of /proc/sys/fs/binfmt_misc/qemu-x86_64 | 14:54 |
vkoskiv | enabled | 14:54 |
vkoskiv | interpreter /usr/libexec/qemu-binfmt/x86_64-binfmt-P | 14:54 |
vkoskiv | flags: POC | 14:54 |
vkoskiv | offset 0 | 14:54 |
vkoskiv | magic 7f454c4602010100000000000000000002003e00 | 14:54 |
josch | looks good | 14:54 |
vkoskiv | mask fffffffffffefefcfffffffffffffffffeffffff | 14:54 |
josch | did you reboot after installing qemu-user? | 14:54 |
vkoskiv | Running the interpreter directly works | 14:55 |
vkoskiv | Nope! | 14:55 |
josch | vkoskiv: you might need to reboot. This is a bug introduced a few weeks ago: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012163 | 14:55 |
vkoskiv | Fair, I'll do that. I just tend to be averse to rebooting to fix issues :D | 14:56 |
josch | the problem is that systemd-binfmt does not provide a way to register a new binfmt besides a reboot | 14:56 |
josch | yeah, same here | 14:56 |
josch | this change to systemd-binfmt broke my stuff | 14:56 |
minute | josch: box64 package would be amazing to have, yes. | 14:58 |
josch | minute: oh hi! :) While you are here: i just tried running the reform-system-image pipeline on the gitlab.com CI and they have binfmt_misc support but it works for all arches except arm64 due to this bug: https://gitlab.com/gitlab-org/gitlab/-/issues/339567 :( | 14:59 |
- bkeys (QUIT: Ping timeout: 264 seconds) (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 15:00 | |
vkoskiv | I'm starting to think this qemu+binfmt approach might be a bit silly :D | 15:00 |
vkoskiv | Currently installing amd64 libgl | 15:00 |
minute | josch: perhaps that's the reason why i went for building on bare metal | 15:01 |
minute | vkoskiv: don't do it, use box64 | 15:01 |
minute | vkoskiv: qemu emulation is too slow | 15:01 |
minute | waste of time | 15:01 |
vkoskiv | Cool, will do. | 15:01 |
josch | vkoskiv: i'll build you a box64 debian package and you fix blender -- deal? :) | 15:02 |
minute | i like the sound of that | 15:02 |
vkoskiv | WARNING: The following essential packages will be removed. | 15:04 |
vkoskiv | This should NOT be done unless you know exactly what you are doing! | 15:04 |
vkoskiv | libgcc-s1:amd64 gcc-12-base:amd64 (due to libgcc-s1:amd64) libc6:amd64 (due to libgcc-s1:amd64) | 15:04 |
vkoskiv | Sounds like a deal! | 15:04 |
vkoskiv | I'm assuming I can ignore that warning | 15:04 |
vkoskiv | Just yoinking all these amd64 packages I installed. | 15:04 |
vkoskiv | I'm assuming it just has a list of important enough packages that it warns about | 15:05 |
josch | vkoskiv: those packages are essential but since they are also foreign architecture you can safely remove them | 15:05 |
vkoskiv | Actually it won't even let me remove them. | 15:05 |
vkoskiv | Not permitted, it says. | 15:05 |
vkoskiv | Let me find the correct flag... | 15:06 |
vkoskiv | --allow-remove-essential >:D | 15:06 |
josch | yes, the reason is because we had the "linus tech tips" desaster: https://youtu.be/0506yDSgU7M | 15:06 |
vkoskiv | I remember that one. Was that actually added because of that? | 15:07 |
vkoskiv | Or did he google what I googled and add that flag | 15:07 |
josch | no, it was added because after that linus tech tips video, we got a big shit storm | 15:08 |
josch | like: why would apt permit you doing something that breaks your system? | 15:08 |
josch | well... it says that you have to type "Yes, I know what I'm doing!" to continue and linus typed that... it even shows this point in the video... | 15:09 |
josch | but apparently even that is too dangerous to be allowed... | 15:09 |
vkoskiv | I highly recommend adding these to ~/.config/mpv/mpv.conf: https://gist.github.com/vkoskiv/4eb945642873ed4f4a32b00dfb2e2bbf | 15:10 |
vkoskiv | Then you can easily do mpv --profile=720p <url> | 15:10 |
vkoskiv | I didn't get this laptop for media consumption, as I'm trying to decrease that, but this thing does play youtube well with mpv. | 15:11 |
josch | I have the same in my own mpv.conf but as part of my defaults | 15:12 |
vkoskiv | I consider the slightly added inconvenience of having to copy the link to open it in mpv a feature :D | 15:12 |
vkoskiv | About 90% of the stuff I would otherwise end up watching on youtube is stuff I really don't need to watch. | 15:12 |
josch | i even do that on my intel laptop because mpv requires way less cpu power to play videos than youtube | 15:12 |
josch | minute: do you think we should put such a default into the reform-tools etc/skel file for mpv? Currently, lots of youtube videos are available in 4k which is not possible on the reform even with mpv. | 15:13 |
vkoskiv | I did try to get hw decoding working on my nvidia + arch x86 desktop system, but I never got anywhere | 15:17 |
vkoskiv | Specifically with firefox. | 15:17 |
vkoskiv | Followed all the arch guides to a t, still nothing :D | 15:17 |
minute | josch: sounds good yes | 15:17 |
vkoskiv | Without the profiles, it does seem to default to 4k, which isn't ideal | 15:17 |
vkoskiv | Would make more sense to default to 1080p | 15:18 |
vkoskiv | Did I understand correctly that the OS not being aware of battery level is a software issue, right? | 15:18 |
vkoskiv | I remember reading something about a driver that would then receive uart messages from the lpc to keep the system aware of the battery level | 15:18 |
minute | vkoskiv: there's a MR for SPI kernel driver for lpc battery status | 15:19 |
minute | in my mailbox | 15:19 |
vkoskiv | The one from today? | 15:19 |
minute | yeah | 15:19 |
vkoskiv | Very cool! I just happened to spot it like a minute after it was sent :D | 15:19 |
vkoskiv | I love how this thing keeps getting better as the patches roll in | 15:19 |
minute | yes | 15:20 |
josch | vkoskiv: thanks, i think this was a good idea to have as a default https://source.mnt.re/reform/reform-tools/-/merge_requests/17 | 15:21 |
minute | merged | 15:22 |
josch | wow, quick service! :D | 15:23 |
- MajorBiscuit (QUIT: Quit: WeeChat 3.5) (~MajorBisc@wlan-145-94-167-213.wlan.tudelft.nl) | 15:28 | |
+ MajorBiscuit (~MajorBisc@wlan-145-94-167-213.wlan.tudelft.nl) | 15:28 | |
vkoskiv | Cool! | 15:31 |
vkoskiv | I still haven't investigated why the wake command on my lpc doesn't work. I guess I need a uart connection to debug that? | 15:38 |
vkoskiv | I have a uart serial adapter, I just need to fashion a cable. | 15:39 |
minute | yep | 15:45 |
minute | also make sure no_console_suspend is in your kernel options (should be) | 15:45 |
vkoskiv | Seems to me like the issue is on the firmware side. I'm running latest on both kbd and lpc. | 15:46 |
vkoskiv | The symptom is that I invoke the wake command, it starts waking the lpc and then doesn't get a response right away | 15:47 |
vkoskiv | Would having box64 + binfmt set up out of the box on sysv3 make sense? Or would that violate the principle of least surprise? | 15:50 |
vkoskiv | Still compiling it, the README sure did make box64 seem quite nice! | 15:50 |
Boostisbetter | I got Box64 working but haven't had a much luck with box32. I'm still trying to get steam working on the Reform | 15:52 |
minute | Boostisbetter: steam is complex mix of box32+box64. i don't have a recipe for it | 15:52 |
Boostisbetter | minute: yep, and I have no problem not being able to run. It one day though. | 15:53 |
vkoskiv | Interesting. One of the motherboard screws managed to work itself loose and just fell onto the acrylic below :D | 15:56 |
vkoskiv | So far I haven't experienced any other screws coming loose. | 15:57 |
minute | vkoskiv: eek | 16:02 |
minute | vkoskiv: probably vibrations from shipping :| | 16:02 |
vkoskiv | It's a screw I put in. | 16:02 |
minute | oh. | 16:02 |
vkoskiv | And one I haven't touched since I assembled this thing rapidly in excitement | 16:02 |
minute | you can use locktite 242 perhaps | 16:02 |
vkoskiv | Yep, I should get some | 16:03 |
vkoskiv | box64 doesn't emulate libstdc++.so.6 for some reason | 16:05 |
vkoskiv | Online for others it seems to be emulated, but for me it throws an error. | 16:06 |
+ qbit (~qbit@h.suah.dev) | 16:11 | |
+ bkeys (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 16:36 | |
bkeys | josch: Did you ever come up with any theories on my uboot issues? | 16:48 |
bkeys | I wonder if I can write a new uboot to the emmc from uboot itself | 16:48 |
bkeys | Or even better, a whole OS image | 16:48 |
- bkeys (QUIT: Ping timeout: 246 seconds) (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 17:17 | |
+ bkeys (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 17:35 | |
josch | bkeys: nocko recently had a problem that looked similar to me and boiled down to this fix: https://source.mnt.re/reform/reform-tools/-/merge_requests/16 | 17:50 |
josch | bkeys: but we are not generating an image with that yet because blender is (again) broken but vkoskiv is working on it | 17:50 |
josch | bkeys: otherwise, sadly nothing changed from what I said four days ago: https://mntre.com/reform-irc-logs/2022-06-16.log.html#t23:21:11 | 17:50 |
josch | :( | 17:50 |
minute | josch: maybe we can remove blender temporarily | 17:54 |
josch | minute: i proposed that but vkoskiv said they would provide a fix after work today | 17:55 |
minute | ok | 17:55 |
minute | if that doesn't happen we should turn blender off | 17:55 |
josch | agreed | 17:56 |
- bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 17:57 | |
+ bkeys (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 17:57 | |
josch | bkeys: you went offline -- did you get my last messages to you? | 17:59 |
bkeys | Yes | 17:59 |
bkeys | This pinebook hibernates after 5 minutes of me not using it, it's really annoying | 17:59 |
bkeys | So nothing changed, but you seem to have a fix? | 18:00 |
bkeys | Which is it? | 18:00 |
josch | bkeys: no, i meant that there is an issue that looked similar and we have a fix for that | 18:00 |
josch | bkeys: i added a link to the fix | 18:00 |
bkeys | That is good to hear | 18:00 |
bkeys | I am talking with a co worker and he has been looking at the schematics, I dunno if he is confident/willing to try to repair it out of his house | 18:01 |
bkeys | But if he did my guess is that it would be moreso a personal favor to me, rather than something he'd be willing to do for the greater community | 18:01 |
bkeys | The other repair shop I emailed hasn't responded, they said the foreman was on vacation. I am gonna email them again because that was almost a week and a half ago | 18:01 |
bkeys | josch: So my understanding is we don't have an image with this fix? But after vkoskiv fixes blender we should have one soon after? | 18:06 |
josch | vkoskiv: I'm done with the box64 packaging: https://salsa.debian.org/debian/box64/ | 18:06 |
josch | vkoskiv: now it's your turn with blender :) | 18:06 |
josch | bkeys: either vkoskiv fixes blender or we disable blender build and then produce a new image with the fix that solves the problem discovered by nocko, yes | 18:07 |
bkeys | Just curious, what exactly was the problem? | 18:07 |
bkeys | It'd be really cool if I get EFI working on there | 18:08 |
josch | bkeys: the reform-flash-rescue script was downloading the image from the sysimage-v3 branch and not from the main branch even after the sysimage-v3 branch was merged into main -- see the link I posted above | 18:08 |
bkeys | Alright | 18:08 |
bkeys | So this image my guess is will contain the fix as well as the distroboot changes? | 18:08 |
josch | not the distroboot changes yet, no | 18:08 |
josch | but you can always write your own u-boot to your sd-card | 18:09 |
bkeys | Yep, as long as I have a working OS again | 18:09 |
bkeys | If I had an encrypted Fedora install on there that would be awesome | 18:10 |
josch | bkeys: i definitely want to see efi boot working on that as well | 18:10 |
josch | with the distroboot changes it *should* work out of the box and if it doesn't it *should* just be some config setting away | 18:11 |
bkeys | Yeah that is my theory, just my OS situation has been blocking me | 18:11 |
josch | if it doesn't work out of the box, i also want to look into the u-boot efi thing but i first need to have my serial line working again :D | 18:11 |
bkeys | It would just be a matter of having an EFI partition on the emmc | 18:11 |
josch | or sd-card, or usb-stick, yes | 18:12 |
bkeys | So are you guys still assembling more reforms? Or has the queue of people waiting for theirs calmed down at all? | 18:14 |
sknebel | right now they are redesigning parts to use components that can be bought | 18:16 |
sknebel | and actually be delivered in reasonable time after buying them I guess :D | 18:16 |
bkeys | I mean I am gonna be on a project at work soon that basically does that but uses microcontrollers that are in stock | 18:17 |
bkeys | Although I would think it would be not that useful, cause you redo all this work to use available components and what if those components go out of stock? | 18:17 |
+ mtm (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 18:18 | |
minute | we are moving to rp2040 | 18:30 |
minute | also, nobody can predict the future | 18:30 |
- bkeys (QUIT: Ping timeout: 268 seconds) (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 18:39 | |
+ bkeys (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 18:56 | |
- mjw (QUIT: Quit: Leaving) (~mjw_@2001:1c06:2488:1400:9e5c:8eff:fe8f:a440) | 19:05 | |
- MajorBiscuit (QUIT: Ping timeout: 268 seconds) (~MajorBisc@wlan-145-94-167-213.wlan.tudelft.nl) | 19:19 | |
* mark__ -> mjw | 19:54 | |
vkoskiv | josch: I *think* what might have happened was that libtbb-dev was bumped, but openvdb was not | 20:07 |
vkoskiv | That header was removed in version 2021.1 | 20:07 |
vkoskiv | I'd try bumping openvdb or downgrading libtbb to an older version. I don't think I have a suitable build environment to try this out | 20:08 |
+ bkeys1 (~Thunderbi@253.236-24.gp.ptn.tftn.static.friendlycity.net) | 20:26 | |
- bkeys (QUIT: Ping timeout: 240 seconds) (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 20:29 | |
* bkeys1 -> bkeys | 20:29 | |
bkeys | minute: So with the repair place here, they just sent me an email saying to send in my Reform for evaluation. I'm gonna probably mail it off sometime this week and hopefully the fact that the schematics and stuff are available will help them out | 20:52 |
minute | bkeys: oh that's exciting, keep me udpated | 20:54 |
minute | updated even | 20:54 |
+ bkeys1 (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 20:57 | |
bkeys1 | Before I send it in though I would be interested in getting an image with vkoskiv's fix that way I can confirm that I can boot an OS on there | 20:57 |
minute | bkeys1: you could also try booting plan9, might be quicker/easier | 20:58 |
bkeys1 | Well right now I cannot boot anything | 20:58 |
minute | ah | 20:59 |
bkeys1 | I am okay with debian atm but I cannot get a system image to boot at all, josch has been working with me on it | 20:59 |
bkeys1 | Earlier we were discussing how there is a fix for it but we are waiting on vkoskiv's patch for Blender | 20:59 |
minute | yeah i meant, with plan9/9front you could make sure this is not just a linux issue | 20:59 |
minute | ah, sorry, misunderstanding on my part | 21:00 |
minute | i thought your reform doesn't appear to boot | 21:00 |
bkeys1 | Well my end goal is to get a uboot with josch's distroboot put on there but no matter what I do I don't get a uboot with distroboot on there | 21:00 |
bkeys1 | According to serial connection it boots, even lights up a screen but the system image doesn't find the rootfs | 21:00 |
bkeys1 | I even tried it with different SD cards | 21:01 |
josch | vkoskiv: I think I can confirm the results of your analysis -- if anybody wants the longer story, I can list it but I think for now we should just not compile blender | 21:01 |
- bkeys (QUIT: Ping timeout: 264 seconds) (~Thunderbi@253.236-24.gp.ptn.tftn.static.friendlycity.net) | 21:01 | |
* bkeys1 -> bkeys | 21:01 | |
minute | bkeys1: ah, the board level repair was about some battery cell measuring/charging circuit, right? | 21:01 |
bkeys | Yes these are two unconnected issues | 21:01 |
minute | sorry, got it | 21:01 |
bkeys | No problem, hopefully these people will be able to repair it cause that could take a load off of you | 21:02 |
bkeys | I'd think since they claim to have so much experience fixing industrial PCBs that they would have a lot of exposure to I.MX8 | 21:02 |
bkeys | Even so this is a simple carrier board issue and shouldn't have anything to do with the SoM | 21:03 |
- bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 21:03 | |
+ bkeys (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 21:04 | |
vkoskiv | I kind of want to build a proper electronics workbench. | 21:04 |
vkoskiv | I have a bunch of scattered tools around, but no dedicated spot | 21:04 |
vkoskiv | Soldering irons, bench power supply, some parts. | 21:04 |
vkoskiv | I want a (cheap) oscilloscope and a dedicated thing to keep all this stuff in. | 21:04 |
bkeys | I can solder bigger things but once we are talking small components like this I am not much help | 21:04 |
minute | vkoskiv: always a good idea ^^ | 21:04 |
vkoskiv | Some kind of rack that I could move aside when not in use. | 21:05 |
vkoskiv | I have a spare table in my office that I usually do vintage computerings on | 21:05 |
vkoskiv | I just don't know what kinds of parts I should buy to stock up | 21:05 |
vkoskiv | I want wires, connectors, passives and other random bits | 21:05 |
vkoskiv | Just today I wanted to crimp a suitable connector to my uart adapter cable, but I dont have that connector anywhere. | 21:06 |
minute | cinap_lenrek: i tried to boot your latest 9front image, and it gives me a Plan 9 Console with working keyboard+mouse pointer, butttt i'm not sure how to start my session/rio | 21:12 |
minute | it givces me a table of /dev/sdM0 stuff and then prompts: bootargs is (tcp, tls, il, local!device)[local!/dev/sdM0/fs] | 21:12 |
josch | the blender situation is a mess and cannot be fixed in blender but has to be fixed in openvdb by adding onetbb support (tbb got renamed to onetbb) full story here: https://source.mnt.re/reform/reform-debian-packages/-/commit/5b91cfca713eeee94b35226570b989a4d9f0db76 | 21:14 |
josch | minute: that commit disables building blender -- i'll ping you once the repository got updated and then you can trigger the reform-system-image pipeline again | 21:15 |
minute | josch: alright, thanks for all your work on this. so we're gonna turn off blender for now | 21:15 |
- bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 21:16 | |
minute | cinap_lenrek: if i do local!/dev/sdM0/fs, it gives me > hjfs: fs is /dev/sdM0/fs and then > mount: mount/root: no such user | 21:16 |
+ bkeys (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 21:16 | |
josch | once the openvdb situation is fixed blender might still fail to build because the openvdb version will change from 7.1 to 9.0 including several API changes -- but we'll fix that once it happens. Anyways, this will take a while longer... | 21:16 |
minute | cinap_lenrek: oh, after reset, typing local!/dev/sdM0/fs worked! | 21:20 |
- bkeys (QUIT: Ping timeout: 240 seconds) (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 21:22 | |
+ MajorBiscuit (~MajorBisc@86-88-79-148.fixed.kpn.net) | 21:38 | |
minute | ah, figured out how to go online | 21:44 |
- MajorBiscuit (QUIT: Ping timeout: 240 seconds) (~MajorBisc@86-88-79-148.fixed.kpn.net) | 21:46 | |
- qbit (QUIT: Ping timeout: 264 seconds) (~qbit@h.suah.dev) | 21:46 | |
+ MajorBiscuit (~MajorBisc@2a02-a461-129d-1-193d-75d8-745d-e91e.fixed6.kpn.net) | 21:48 | |
+ bkeys (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 21:49 | |
+ qbit (~qbit@h.suah.dev) | 21:53 | |
minute | hey, our website is pretty ok in mothra... just i should probably upload smaller versions of the images | 21:54 |
- bkeys (QUIT: Ping timeout: 246 seconds) (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 21:55 | |
sigrid | I wonder how well (or not well) will it play youtube videos | 21:55 |
minute | sigrid: can mothra do that? :D | 21:57 |
minute | i can browse our shop and look at the pictures in hires | 21:58 |
minute | i have to say the processor is really ok for software based graphics | 21:58 |
minute | it's fun | 21:58 |
sigrid | mothra can't, but treason+nvi can | 21:58 |
sigrid | http://wiki.9front.org/youtube | 21:59 |
- MajorBiscuit (QUIT: Ping timeout: 244 seconds) (~MajorBisc@2a02-a461-129d-1-193d-75d8-745d-e91e.fixed6.kpn.net) | 22:02 | |
minute | sigrid: :0 | 22:05 |
+ bkeys (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 22:13 | |
josch | minute: https://mntre.com/reform-debian-repo/ just updated -- can you re-run reform-system-image pipeline? thanks! | 22:15 |
minute | josch: running by merge! :3 | 22:17 |
- bkeys (QUIT: Ping timeout: 240 seconds) (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 22:17 | |
josch | minute: I think I can also confirm that kernel 5.18 now reliably breaks suspend: https://community.mnt.re/t/standby-suspend-to-ram-mnt-reform/538/66 | 22:21 |
minute | sigrid: omg there's `vt` and `ssh` | 22:21 |
minute | josch: ugh | 22:21 |
sigrid | there's also native live streaming to peertube and twitch | 22:25 |
minute | sigrid: if i type `9fs sources`, where are those file magically mounted from? | 22:29 |
minute | is that a public 9pfs server? | 22:29 |
sigrid | yeah, it is | 22:32 |
sigrid | see /bin/9fs | 22:33 |
+ _9minute (~mntmn@softboy.mntmn.com) | 22:34 | |
_9minute | i'm here via irssi/ssh/vt/9front lol | 22:35 |
minute | sigrid: ohh i see, thanks | 22:35 |
vkoskiv | Looking at the etnaviv source. If only I knew kernel/driver development better! | 22:43 |
vkoskiv | I'd love to see gles 3.x support. | 22:44 |
_9minute | vkoskiv: no kernel development needed for that, just mesa/gallium | 22:46 |
vkoskiv | Or that. But the driver is in the kernel, no? Or is the needed work in some userspace component? | 22:48 |
+ bkeys (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 22:52 | |
bkeys | I thought blender required OpenGL 3.3 nowadays? | 22:57 |
bkeys | How does it manage to run on the Reform? | 22:57 |
josch | bkeys: it doesn't | 22:58 |
_9minute | bkeys: we (mostly josch) tried to keep 2.79 alive on top of debian | 22:58 |
bkeys | So what is the talk of blender about? | 22:58 |
bkeys | I see | 22:58 |
josch | bkeys: unfortunately, making old blender build with modern libraries currently requires a 1896 line diff and becomes increasingly hard the more stuff changes -- right now it fails to build because of openvdb | 22:59 |
bkeys | I see, my plans for Blender (since I do enjoy doing game development in my free time) was to just do it on a different machine | 23:00 |
bkeys | Although I did get Godot 4 Alpha building on the Reform's system image before I wrecked my install | 23:00 |
minute | i've also used the godot available in debian, worked well | 23:01 |
vkoskiv | I could run Blender on my desktop with x forwarding | 23:01 |
vkoskiv | In fact, let me try that now. | 23:01 |
bkeys | I had some LX2160a workstation boards but both of them failed on me and are on their way to Israel for repair | 23:02 |
bkeys | It'll be nice to have both arm laptop and desktop again (hopefully both with Fedora on EFI) | 23:02 |
vkoskiv | It's too slow. I can see frame updates draw from top to bottom every second or two | 23:02 |
bkeys | Although the lx2160a boards have edk2 on them | 23:02 |
vkoskiv | Let me try this with ethernet hooked up | 23:02 |
bkeys | I am waiting for Godot 4 to come out before I do any new Godot development, but in the meantime I mess with this project | 23:03 |
bkeys | https://gitgud.io/bkeys/black-shades-redemption | 23:03 |
bkeys | It's some old game from 2007 I resurrected and modernized a lot of the internals. I am working on implementing online play now | 23:04 |
bkeys | It runs on the Reform, it uses OpenGL 2.0 I think | 23:04 |
vkoskiv | With ethernet it's better, but still about 1fps | 23:04 |
vkoskiv | I briefly looked into what features blender needs from opengl 3.x | 23:05 |
sigrid | you can force mesa into llvm pipe rendering and run latest blender on the reform. it is, however, going to be slow af | 23:05 |
vkoskiv | Seems like they bumped the requirement for a reason | 23:05 |
bkeys | Probably the best approach would be if we had a new SoM we might get vulkan support | 23:06 |
bkeys | I believe the raspberry pi has vulkan support | 23:07 |
minute | vkoskiv: you'll probably have more success with a desktop streaming application | 23:07 |
vkoskiv | sigrid: re: pipe rendering: See? I knew all this opengl stuff was just unnecessary bloat! :D | 23:08 |
vkoskiv | Blender isn't necessary for me on the go. I've been working on a renderer myself for a few years, and that one works perfectly fine on reform | 23:09 |
vkoskiv | I haven't gotten around to integrating it with blender yet | 23:09 |
vkoskiv | So the UI is: "edit this json file and run the thing" | 23:09 |
josch | sounds like openscad | 23:09 |
- Ar|stote|is (QUIT: Ping timeout: 248 seconds) (~linx@149-210-28-104.mobile.nym.cosmote.net) | 23:10 | |
vkoskiv | I actually like the bespoke json scene description scheme I came up with. Later I found out it's quite similar to what pixar is using in some places. | 23:10 |
vkoskiv | And since my renderer has network clustering support, I can offload all compute away from my reform and get speedy renders. | 23:11 |
- _9minute (QUIT: Quit: leaving) (~mntmn@softboy.mntmn.com) | 23:11 | |
+ Ar|stote|is (~linx@149-210-4-100.mobile.nym.cosmote.net) | 23:14 | |
- bkeys (QUIT: Ping timeout: 246 seconds) (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 23:21 | |
+ MajorBiscuit (~MajorBisc@86-88-79-148.fixed.kpn.net) | 23:24 | |
vkoskiv | minute: Did you get those smooth trackball buttons fabricated somewhere or is that after an acetone vapor bath? | 23:32 |
- MajorBiscuit (QUIT: Ping timeout: 276 seconds) (~MajorBisc@86-88-79-148.fixed.kpn.net) | 23:34 | |
- mjw (QUIT: Quit: Leaving) (~mark@gnu.wildebeest.org) | 23:38 | |
josch | is hibernate on the reform not working for similar reasons as suspend? | 23:42 |
josch | even after enabling a swap partition that is large enough, the reform only sometimes successfully comes back from hibernation (similar to suspend also only works sometimes) | 23:43 |
vkoskiv | How do you suspend and resume, by the way? systemctl suspend? | 23:43 |
josch | correct | 23:43 |
josch | and resume via circle, space | 23:43 |
vkoskiv | Yeah, I need to debug that on my system | 23:44 |
vkoskiv | It never worked, even after upgrading/reflashing fw for everything | 23:44 |
minute | vkoskiv: fabricated as industrial SLA via hubs | 23:58 |
josch | minute: https://source.mnt.re/reform/reform-system-image/-/merge_requests/52 | 23:59 |
josch | i'll not be around to see if it succeeds though -- heading to bed now. gn8! | 23:59 |
minute | josch: interesting, i've never had hibernate work! if it doesn't work only sometimes, then that's the same flakiness like with the regular suspend/wake, yeah. | 23:59 |
minute | josch: good night! | 23:59 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!