ex-parrot | and so I can make it properly For Me | 00:00 |
---|---|---|
sigrid | being able to fix burned traces | 00:00 |
ex-parrot | yeah or recompile the trackball firmware | 00:00 |
ex-parrot | or whatever I like | 00:00 |
pkill9 | would definitely like one | 00:02 |
vagrantc | mostly i just test u-boot and barebox and such on my mnt/reform :) | 00:03 |
bibliocar | it's nice to program on. I'm actually learning how to use tmux correctly. | 00:05 |
bibliocar | to explain why my mnt is special in that regard: | 00:06 |
ex-parrot | I also haven't bothered to install a graphical environment since setting up LFS and I like that | 00:07 |
bibliocar | I still need to get around to doing the ball bearing thing for my trackball... mine is actually very bad, like actually binds and i have to wiggle it back and forth. I have it 3d printed, just need to sand it. | 00:08 |
bibliocar | but, back to the point: it's because I feel the laptop is something I can invest time in and become familiar with. The little disrespectful things that other laptops do really detract from that mood. | 00:09 |
- ruff (QUIT: Ping timeout: 240 seconds) (~ruff@ip-78-45-99-112.net.upcbroadband.cz) | 00:11 | |
ex-parrot | ^^^ | 00:13 |
pkill9 | i think i will watch the entire two hours 15 mins of this at some point heh https://www.youtube.com/watch?v=DKzDzDmst2Q | 00:23 |
pkill9 | i hate how there are a million different laptops with slight differences | 00:24 |
pkill9 | for each difference there is a whole new laptop model | 00:25 |
vagrantc | bluerise: hrm. same result building from https://github.com/bluerise/u-boot/tree/mntre | 00:47 |
vagrantc | what changed between v2022.01-rc3+v3 patches to .... v2022.01+v4 patches ... | 00:48 |
- mtm (QUIT: Ping timeout: 240 seconds) (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 01:02 | |
bluerise | vagrantc:weird, because I was running with that | 01:07 |
- chomwitt (QUIT: Ping timeout: 245 seconds) (~chomwitt@2a02:587:dc11:fb00:12c3:7bff:fe6d:d374) | 01:09 | |
vagrantc | bluerise: i'm using the lpddr, hdmi and bl31 firmwares from https://source.mnt.re/reform/reform-boundary-uboot | 01:12 |
vagrantc | maybe that's somehow a difference? | 01:13 |
bluerise | https://blueri.se/flash.bin -- does that do? | 01:15 |
bluerise | Oh right, if it hangs after SPL it can be bl31 firmware | 01:15 |
bluerise | because it's SPL -> ATF -> U-Boot | 01:15 |
bluerise | https://blueri.se/bl31.bin | 01:15 |
- adjtm (QUIT: Remote host closed the connection) (~adjtm@2a0c:5a80:3a17:7800:d1f9:3a6a:2c35:84e) | 01:24 | |
+ adjtm (~adjtm@2a0c:5a80:3a17:7800:d1f9:3a6a:2c35:84e) | 01:25 | |
- Christoph_ (QUIT: Remote host closed the connection) (~Christoph@p54bf6219.dip0.t-ipconnect.de) | 02:45 | |
vagrantc | bluerise: your flash.bin works ... will try building with your bl31.bin | 02:45 |
- pkill9 (PART: https://quassel-irc.org - Chat comfortably. Anywhere.) (~quassel@104.238.170.104) | 02:46 | |
vagrantc | bluerise: even with your bl31.bin, my local build fails in the same way ... | 03:00 |
vagrantc | ACTION tries with older toolchains | 03:00 |
+ mtm (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 03:09 | |
- Guest9189 (QUIT: Ping timeout: 240 seconds) (~nicolas@i5C74425A.versanet.de) | 03:15 | |
+ nsc (~nicolas@i5C7440FD.versanet.de) | 03:16 | |
* nsc -> Guest294 | 03:17 | |
vagrantc | no luck with older toolchains either... | 03:23 |
vagrantc | ACTION sighs | 03:23 |
vagrantc | now i wonder how my successful build was ... built. :/ | 03:24 |
- vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:21:21:0:100b) | 03:27 | |
Boostisbetter | doctorhoo: after setting the console as you suggested, I have not had a single resume from standby failure over the last few days. We are looking at about 30 resumes. | 04:17 |
Boostisbetter | I think that might really have been the final bit of the puzzle making resuming stable. | 04:17 |
Boostisbetter | Very happy with that. | 04:17 |
Boostisbetter | I get about 10 hours of mixed usage out of the batteries. | 04:18 |
+ vagrantc (~vagrant@2600:3c01:e000:21:21:21:0:100e) | 04:38 | |
- sts-q (QUIT: Ping timeout: 240 seconds) (~sts-q@91.200.108.171) | 04:56 | |
+ sts-q (~sts-q@212.53.219.138) | 05:09 | |
- vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:21:21:0:100e) | 05:26 | |
- erlehmann (QUIT: Ping timeout: 256 seconds) (~erle@ip5f5bd566.dynamic.kabel-deutschland.de) | 06:04 | |
+ erlehmann (~erle@ip5f5bd566.dynamic.kabel-deutschland.de) | 06:48 | |
+ ruff (~ruff@ip-78-45-99-112.net.upcbroadband.cz) | 06:57 | |
+ chomwitt (~chomwitt@ppp-94-67-201-202.home.otenet.gr) | 07:29 | |
josch | besides ruff, who else is working with the mnt reform kernel patches? | 09:00 |
- bkeys (QUIT: Ping timeout: 256 seconds) (~Thunderbi@66.115.189.236) | 09:05 | |
+ bkeys (~Thunderbi@66.115.189.236) | 09:11 | |
+ MajorBiscuit (~MajorBisc@86-88-79-148.fixed.kpn.net) | 09:21 | |
+ Major_Biscuit (~MajorBisc@c-001-009-026.client.tudelft.eduvpn.nl) | 09:22 | |
ruff | josch: what do you mean - working? I'm currently rebasing on yet another purism's update, also I found I made some typos during commit which caused git patch to reject the patches (even though they applied via patch -p1) | 09:24 |
ruff | whitespace typos, git diff was highlighting extra space in red so i decided to remove it, and checked only with patch --dry-run (but not with git patch --check) after removal | 09:25 |
josch | as mentioned i'm also currently rebasing patches and everything boots but the display doesn't come on... debugging now... | 09:25 |
- MajorBiscuit (QUIT: Ping timeout: 250 seconds) (~MajorBisc@86-88-79-148.fixed.kpn.net) | 09:26 | |
ruff | hm, are you using my repo or still trying with your own version> | 09:26 |
ruff | I'm currently trying to modularize as much as possible in the kernel since I getting OOM on my gitlab-runner while linking vmlnux | 09:27 |
ruff | and because I'm enabling modules anyway so no reason to keep optional mods static | 09:28 |
josch | yes, i'm also building with modules | 09:29 |
josch | but instead of using pureos/byzantium I rebased on top of torvalds/linux | 09:30 |
josch | i'll try out pureos/byzantium now and see what happens :) | 09:30 |
ruff | thay have more than half of the patches already in-tree | 09:31 |
ruff | there're only 5 left and the biggest (mnt5000, hdmi) i'm pretty sure is optional now as only thing it does is enabling hdmi cec. | 09:33 |
ruff | I mean after I stripped it off the in-tree chnuks only cec is left | 09:33 |
josch | ruff: indeed, I'm currently running into the "error: corrupt patch at line" messages when using your patches | 09:50 |
- Major_Biscuit (QUIT: Ping timeout: 250 seconds) (~MajorBisc@c-001-009-026.client.tudelft.eduvpn.nl) | 09:52 | |
+ MajorBiscuit (~MajorBisc@c-001-009-026.client.tudelft.eduvpn.nl) | 09:53 | |
ruff | josch: i'll submit corrections together with latest rebase today. Since I didn't pin the commit/tag I'll need to do it periodically (untill all patches are gone :P) | 09:55 |
josch | that's motivation to get everything merged more quickly ;) | 09:59 |
ruff | pushed corrected and rebased patches | 10:19 |
josch | ruff: you already confirmed the resulting kernel to work? | 10:24 |
ruff | nope, building now | 10:30 |
ruff | but it's patch removal (i.e. it's already there) not adding, and according to commit log I don't expect any major changes comparing with kernel I'm running now | 10:32 |
ruff | on a second thought - I realized the patches with fuzz were skipped by git patch, so my current kernel is built without at least a 3 patches (which had fuzz and which are fixed now). So will see if those extra patches are breaking anything :) | 10:37 |
- arminweigl (QUIT: Ping timeout: 256 seconds) (~arminweig@sourcehut/user/arminweigl) | 10:44 | |
+ arminweigl (~arminweig@sourcehut/user/arminweigl) | 10:46 | |
josch | ruff: I saw you dropped caam-revert-swiotlb-origaddr.patch but if I look at https://source.puri.sm/Librem5/linux-next/-/blob/pureos/byzantium/kernel/dma/swiotlb.c then that patch is still needed -- or are you on a different branch than pureos/byzantium | 10:46 |
+ arminweigl_ (~arminweig@sourcehut/user/arminweigl) | 10:50 | |
ruff | ok i need to re-check that one, I just know for sure my current kernel does not have it (it had a huge fuzz so no chance it got applied) | 10:50 |
- arminweigl (QUIT: Ping timeout: 256 seconds) (~arminweig@sourcehut/user/arminweigl) | 10:50 | |
* arminweigl_ -> arminweigl | 10:50 | |
ruff | no wait, it is there | 10:54 |
ruff | it's just worked out differently, offset is calculated and then applied | 10:54 |
ruff | tlb_offset = tlb_addr & (IO_TLB_SIZE - 1); | 10:55 |
ruff | orig_addr += tlb_offset; | 10:55 |
ruff | https://source.puri.sm/Librem5/linux-next/-/commit/5f89468e2f060031cd89fd4287298e0eaf246bf6 | 11:05 |
ruff | Another benefit of acrylic bottom cover - you can see all the breadcrumbs which fell through the keyboard. So you know when it's time to clean! | 11:22 |
Boostisbetter | ruff, indeed! | 11:25 |
Boostisbetter | does anyone know how many charge cycles the 18650 cells have in the reform? Like what they are rated for? | 11:26 |
- bibliocar (QUIT: Quit: Leaving) (~EricShmar@195.82.99.14) | 11:30 | |
ruff | Cycle Characteristic 2500 times | 11:31 |
ruff | 100% DOD, the residual capacity is no | 11:31 |
ruff | less than 80% of rated capacity at 0.5C | 11:31 |
ruff | Chargeļ¼0.5C Discharge rate. | 11:31 |
ruff | although it's GeB datasheet, not enerpower (with same chemistry and capacity) | 11:36 |
ruff | https://enerpower.de/wp/wp-content/uploads/2019/07/Technical-Specifications-HTCFR18650-1800mAh-3.2V-EN.pdf | 11:40 |
ruff | Here you have 3000 times (80% DOD) so enerpower declares to be better | 11:41 |
+ mjw (~mjw_@2001:1c06:2488:1400:9e5c:8eff:fe8f:a440) | 12:11 | |
ruff | ehm... actually no, geb looks better on the paper, 2500 cycles for 100% dod vs enerpower only 1500 cycles for 100% dod | 12:16 |
Boostisbetter | good to know. One other thing I was wondering about is why the mainboard says that the 8 batteries should supply 28.8V but the batteries are rated at 3.2V each. Is that just the upper limit of what the power rail can handle? | 12:33 |
- mtm (QUIT: Ping timeout: 256 seconds) (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 13:03 | |
- erlehmann (QUIT: Ping timeout: 256 seconds) (~erle@ip5f5bd566.dynamic.kabel-deutschland.de) | 13:14 | |
+ erlehmann (~erle@ip5f5bd566.dynamic.kabel-deutschland.de) | 13:16 | |
+ Christoph_ (~Christoph@p54bf6063.dip0.t-ipconnect.de) | 13:20 | |
ruff | Boostisbetter: it states - "All 8 cells are connected in series. When fully charged at 3.6V, the total voltage of the cells can add up to 28.8V" | 13:28 |
ruff | Boostisbetter: as per specs the cell would never supply 3.6, instead 3.6 is charging voltage | 13:31 |
ruff | Boostisbetter: so it's like - while connected to the mains (charging or fully charged) the input voltage will be 28.8 | 13:32 |
- MajorBiscuit (QUIT: Ping timeout: 250 seconds) (~MajorBisc@c-001-009-026.client.tudelft.eduvpn.nl) | 13:33 | |
ruff | Boostisbetter: but yea in current form the statement is a bit misleading (one may think the batteries are damaged and not supplying full design voltage of 3.6) | 13:34 |
ruff | Boostisbetter: unless at the time of writing the plan was to use Li-Po cells | 13:35 |
+ MajorBiscuit (~MajorBisc@2a02:a461:129d:1:193d:75d8:745d:e91e) | 13:40 | |
+ Major_Biscuit (~MajorBisc@c-001-009-026.client.tudelft.eduvpn.nl) | 13:41 | |
- erlehmann (QUIT: Quit: Just say no, then the virus can not enter your body without your consent.) (~erle@ip5f5bd566.dynamic.kabel-deutschland.de) | 13:45 | |
- MajorBiscuit (QUIT: Ping timeout: 252 seconds) (~MajorBisc@2a02:a461:129d:1:193d:75d8:745d:e91e) | 13:45 | |
+ erlehmann (~erle@ip5f5bd566.dynamic.kabel-deutschland.de) | 13:45 | |
- erlehmann (QUIT: Ping timeout: 240 seconds) (~erle@ip5f5bd566.dynamic.kabel-deutschland.de) | 14:17 | |
- chomwitt (QUIT: Ping timeout: 256 seconds) (~chomwitt@ppp-94-67-201-202.home.otenet.gr) | 14:23 | |
+ chomwitt (~chomwitt@2a02:587:dc11:fb00:12c3:7bff:fe6d:d374) | 14:26 | |
+ erlehmann (~erle@ip5f5bd566.dynamic.kabel-deutschland.de) | 14:35 | |
+ mtm (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 15:09 | |
- erlehmann (QUIT: Ping timeout: 250 seconds) (~erle@ip5f5bd566.dynamic.kabel-deutschland.de) | 15:22 | |
Boostisbetter | ruff, honestly I don't care, it doesn't bother me in the slightest. The system works excellent as a whole, and I love this thing. | 15:25 |
+ erlehmann (~erle@ip5f5bd566.dynamic.kabel-deutschland.de) | 15:35 | |
+ reform32361 (~domi@2a02:120b:c3de:c090:6f0:21ff:fe91:626) | 16:06 | |
- reform32361 (QUIT: Client Quit) (~domi@2a02:120b:c3de:c090:6f0:21ff:fe91:626) | 16:07 | |
- erlehmann (QUIT: Ping timeout: 256 seconds) (~erle@ip5f5bd566.dynamic.kabel-deutschland.de) | 16:21 | |
+ erlehmann (~erle@ip5f5bd566.dynamic.kabel-deutschland.de) | 16:32 | |
- erlehmann (QUIT: Ping timeout: 240 seconds) (~erle@ip5f5bd566.dynamic.kabel-deutschland.de) | 16:44 | |
- Major_Biscuit (QUIT: Ping timeout: 250 seconds) (~MajorBisc@c-001-009-026.client.tudelft.eduvpn.nl) | 16:54 | |
+ erlehmann (~erle@ip5f5bd566.dynamic.kabel-deutschland.de) | 17:03 | |
- erlehmann (QUIT: Quit: Just say no, then the virus can not enter your body without your consent.) (~erle@ip5f5bd566.dynamic.kabel-deutschland.de) | 17:09 | |
+ erlehmann (~erle@ip5f5bd566.dynamic.kabel-deutschland.de) | 17:09 | |
- erlehmann (QUIT: Quit: Just say no, then the virus can not enter your body without your consent.) (~erle@ip5f5bd566.dynamic.kabel-deutschland.de) | 17:23 | |
+ MajorBiscuit (~MajorBisc@c-001-009-026.client.tudelft.eduvpn.nl) | 17:49 | |
- bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.115.189.236) | 17:51 | |
+ bkeys (~Thunderbi@66.115.189.236) | 17:51 | |
- bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@66.115.189.236) | 17:54 | |
+ bkeys (~Thunderbi@66.115.189.236) | 18:10 | |
- mjw (QUIT: Quit: Leaving) (~mjw_@2001:1c06:2488:1400:9e5c:8eff:fe8f:a440) | 18:21 | |
- MajorBiscuit (QUIT: Ping timeout: 250 seconds) (~MajorBisc@c-001-009-026.client.tudelft.eduvpn.nl) | 19:27 | |
+ vagrantc (~vagrant@2600:3c01:e000:21:21:21:0:100e) | 19:39 | |
ruff | argh, ok I'm close to the point to connect my turris mox as a gitlab runner with native armv8 cpu. It just cannot do docker i think on default kernel | 20:02 |
swivel | try nspawn? | 20:03 |
swivel | assuming you have systemd | 20:03 |
ruff | inside lxc I do but kernel does not support all caps on cgroups | 20:03 |
ruff | I'd put one of the pi laying around but they are pi1 or pi2, armv6 or 7 and too low on memory, linking kernel needs at least a spare gig of ram | 20:07 |
swivel | no swap? | 20:08 |
ruff | On pi's storage subsys (sd over usb) it will take ages to swap gig :) | 20:16 |
mntmn | hmmmm i'm sorry for that, i thought i had put everything for docker in there | 20:17 |
ruff | mntmn: not it's not your runner, I didn't have access to runners so I created group and connected my own group shared runner. But it's running on x86 vps and adding qemu-arm64 will be too much for it | 20:19 |
ruff | so now want to create arm64-native runner | 20:20 |
sigrid | you don't want to cross-compile? | 20:22 |
ruff | I do cross-compile. But building image requires running debootstrap which requires arm64 execution (not compilation( | 20:24 |
kfx | sounds like a job for sr.ht! | 20:25 |
mntmn | ah oh | 20:25 |
mntmn | ruff: sorry i thought it was about docker on mnt reform | 20:25 |
mntmn | ruff: btw i believe the new stuff by josch can cross-build everything | 20:26 |
sigrid | I wonder if qemu-user on x86 vps could be faster at this than native aarch64 | 20:26 |
mntmn | FYI https://source.mnt.re/reform/reform-system-image/-/merge_requests | 20:26 |
mntmn | sigrid: unlikely, except if you have a slow aarch64 box | 20:26 |
mntmn | at least qemu-user on my i9 9900 is not "super" fast | 20:27 |
mntmn | (chrooting into arm i mean) | 20:27 |
ruff | sigrid: could be, but this vps runs on FDE volume, so it's a headache to reboot it (need controlpanel) | 20:27 |
josch | mntmn: the packages are all cross compiled but creating an arm64 image requires to run its maintainer scripts which in turn requires some form of emulation if you're not on arm64 already | 20:27 |
josch | that is until we implement DPKG_ROOT support in all involved packages but some maintainers are... difficult... | 20:28 |
ruff | mox runs dualcore armada cpu | 20:29 |
mntmn | josch: ah, got it | 20:29 |
josch | ruff: for the kernel you built with the rebased patches -- does the display come on properly? I only manage to get the backlight on but the display stays black. | 20:31 |
- mtm (QUIT: Ping timeout: 256 seconds) (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 20:33 | |
mntmn | josch: are you able to see dmesg from that boot with no display? | 20:33 |
ruff | josch: just finished rebuild with latest commit so will be rebooting with finish with a runner | 20:33 |
mntmn | josch: via serial/ssh/hdmi? | 20:33 |
+ mtm (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 20:33 | |
josch | mntmn: yes, I can even log in via serial | 20:33 |
mntmn | josch: can you pastebin me the complete dmesg? then i can identify what's wrong, maybe | 20:34 |
josch | mntmn: http://paste.debian.net/1227018/ | 20:34 |
mntmn | that was quick | 20:34 |
josch | i had that prepared ;) | 20:35 |
mntmn | hmm > [ 4.636814] nwl-dsi 30a00000.mipi-dsi: [drm:nwl_dsi_host_attach] lanes=4, format=0x0 flags=0x1 | 20:35 |
mntmn | > [ 4.970795] imx-dcss 32e00000.display-controller: [drm] fb0: imx-dcssdrmfb frame buffer device | 20:35 |
ruff | ok gitlab-runner does not exist in alram repos, so that was also quick | 20:35 |
mntmn | even /dev/fb0 is there yeah? | 20:36 |
mntmn | that's either a new bug or it's the vblank inversion mess | 20:36 |
josch | crw-rw---- 1 root video 29, 0 Jan 13 20:23 /dev/fb0 | 20:36 |
mntmn | does this patch still apply? https://source.mnt.re/reform/reform-system-image/-/blob/main/reform2-imx8mq/template-kernel/patches/0001-nwl-dsi-fixup-mode-only-for-LCDIF-input-not-DCSS.patch | 20:37 |
mntmn | i mean, is it included in your kernel? | 20:37 |
mntmn | because if that's not there, that can make the display blank | 20:37 |
josch | I had the same problem with 5.15.5 so to try and minimize the diff I rebased on top of the next closest release after 5.1 for which you wrote the patch | 20:37 |
josch | no it doesn't I had to fix it, here is my diff: | 20:38 |
mntmn | josch: ah, what happens when you do reform-display-config dual and reboot? do you get something on display then? | 20:38 |
mntmn | (in other words, when using the -hdmi themed dtb) | 20:38 |
josch | ah nevermind, I misremembered and yes, I have this patch applied: http://paste.debian.net/1227022/ | 20:40 |
josch | I didn't try hdmi yet, let me try that next | 20:41 |
mntmn | josch: i mean, the hdmi dtb is interesting because it will connect LCDIF to the internal display instead of DCSS | 20:41 |
mntmn | josch: so it's possible that the internal display will work thewn | 20:41 |
mntmn | then | 20:42 |
- ruff (QUIT: Quit: rebooting) (~ruff@ip-78-45-99-112.net.upcbroadband.cz) | 20:44 | |
+ Boosterfive (~Boosterfi@p5dedf5a5.dip0.t-ipconnect.de) | 20:49 | |
Boosterfive | greetings everyone. Instead of writing you from the MNT Reform I am writing you from the HP 200 LX. Crazy world huh? Anyway I hope you'll pardon this bit of nerdom. | 20:50 |
Boostisbetter | Seriously cool how I can use a device released in 1993 with a 186 processor and running MS-DOS 5.0 to chat on IRC. Anyway, who knows, maybe in 20 years, we'll find it awesome we are doing the same thing with the Reform? | 20:51 |
mntmn | heh! what kind of tcp-ip stack does that have? | 20:55 |
Boosterfive | it is using the slip protocol | 20:56 |
Boosterfive | mtcp | 20:57 |
Boosterfive | it is possible because of a serial to wifi adapter. orginally it only emulated a hayes modem. But recently he figured out how to get it working with a TCP/IP stack that worked on DOS. In conjunction with a http proxy I can use Microweb | 20:59 |
Boosterfive | to "browse" the internet as well. but I think one of the biggest draws is that you can host and connect to a ftp server. That just makes moving files more convenient than using compact flash. | 21:00 |
Boosterfive | anyway enough off topic stuff. thanks for the interest!! | 21:00 |
- Boosterfive (QUIT: Quit: Boosterfive) (~Boosterfi@p5dedf5a5.dip0.t-ipconnect.de) | 21:01 | |
+ ruff (~ruff@ip-78-45-99-112.net.upcbroadband.cz) | 21:13 | |
- ruff (QUIT: Remote host closed the connection) (~ruff@ip-78-45-99-112.net.upcbroadband.cz) | 21:33 | |
flowy | in case anyone is curious, i had some success with acclerated media playback recently. i tried around a dozen h264-encoded files of various framerate/bitrate. using either mpv (built from source against custom ffmpeg), and clapper (installed from flathub), i was able to play everything accelerated, including high bitrate stuff like blu ray remuxes, and 1080p60fps youtube rips. confirmed acceleration was | 21:45 |
flowy | working by monitoring /proc/interrupts and seeing the codec counter go up. | 21:45 |
flowy | the combination of players was required though, because each of them had showstopper bugs with different files- thankfully their problem sets have been mutually exclusive so far. | 21:46 |
flowy | so both stacks are still a bit buggy, it's just nice to have two of them. | 21:47 |
Boostisbetter | flowy, that is awesome! | 21:47 |
flowy | it's nice for me since watching stuff on my laptop is sort of an essential function, especially when i'm travelling. so i reall wanted this to work well enough for everything i can throw at it | 21:47 |
josch | flowy: if the Debian provided binaries don't work you can send me your patches. I'm preparing a repository of patched Debian packages for https://mntre.com/reform-debian/sid/ | 21:48 |
Boostisbetter | that was what i was just about to ask. I'd like to get the goodness on my own machine. | 21:48 |
flowy | though of course reform is perfectly capable of CPU-decoding most stuff, i guess it's a bit less energy efficient, and some stuff actually does require acceleration, like 1080p60fps | 21:48 |
flowy | mpv can not do the latter, btw. clapper does, though. | 21:49 |
flowy | josch: sure thing, and i'm really excited to see the fruits of your labour. i'd also offer to test anything | 21:50 |
josch | flowy: you can reach me via josch@debian.org -- i'll also test myself once I have my display running again ;) | 21:50 |
flowy | it's really impressive how clapper installed through flathub requires no effort at all to get accel running. it just works. | 21:51 |
flowy | i'm on sysimage-v2 w/ a slightly newer kernel but built with the reform system build scripts | 21:52 |
flowy | the recipe to get ffmpeg and mpv working feels a bit sad since it depends on a branch of ffmpeg that has been around for over a year and periodically gets rebased. i don't know what the status is there, in terms of getting that v4l2-request stuff merged | 21:53 |
flowy | but the gstreamer stack, at least in the flathub repos, seems to support that v4l2-request stuff already. | 21:54 |
+ bibliocar (~EricShmar@195.82.99.14) | 21:54 | |
+ doctorhoo (~hanno@194-18-252-127-no2005.tbcn.telia.com) | 21:56 | |
sigrid | flowy: what's the name of the ffmpeg branch? | 21:57 |
+ ruff (~ruff@ip-78-45-99-112.net.upcbroadband.cz) | 21:58 | |
flowy | it's the v4l2-request branch from https://github.com/martinetd/FFmpeg. i believe this work is being done by this person: https://github.com/Kwiboo/FFmpeg. not totally sure | 22:00 |
flowy | i followed the instructions left by mntmn: https://community.mnt.re/t/notes-on-building-ffmpeg-and-mpv-to-use-the-hardware-h-264-decoder/305 | 22:00 |
flowy | except i skipped the ugly hacks, hoping that the newer debian wouldn't require them. and maybe i was right, because it's working. | 22:01 |
flowy | so all i did was build the custom ffmpeg branch and checked out the most recent mpv sources | 22:02 |
kfx | what test files are you using? | 22:02 |
flowy | not big buck bunney? :p | 22:03 |
flowy | blu ray remuxes, youtube stuff dl'd with yt-dlp, various bluray/dvd transcodes with x264 | 22:04 |
flowy | some stuff randomly drops frames and can't sync in mpv. it's accelerated, but something is wrong. it's not a lack of horsepower, because the pattern is sort of random. but then those files have all played back perfectly with clapper, which has different bugs that mpv does not have | 22:05 |
ruff | what is the logic level on ser1? I have 1.8V serial and 5V serial, not sure if I have 3.3 | 22:06 |
josch | mntmn: so with the hdmi.dts not even the backlight comes on but I the reform outputs to hdmi and I can log in from there using the internal keyboard | 22:06 |
josch | ruff: 3.3 V | 22:06 |
ruff | josch: thx, any idea if it is 5v tolerant? | 22:07 |
josch | no, no idea | 22:07 |
- doctorhoo (QUIT: Ping timeout: 256 seconds) (~hanno@194-18-252-127-no2005.tbcn.telia.com) | 22:12 | |
ruff | ok, will leave it to another day. But in general it works: Linux reform 5.15.14+ #2 SMP PREEMPT Thu Jan 13 19:59:43 CET 2022 aarch64 GNU/Linux | 22:17 |
ruff | But - while loading modules perhaps some module causes either crash or lockup, or whatever. Just screen goes blank and nothing. Network is not coming up. But if I move mods folder, it boots ok. then I move it back and do modprobe for wifi - wifi comes up (that's how I'm currently working) | 22:19 |
- bibliocar (QUIT: Ping timeout: 256 seconds) (~EricShmar@195.82.99.14) | 22:38 | |
+ Boosterfive (~Boosterfi@p5dedf5a5.dip0.t-ipconnect.de) | 22:57 | |
- Boosterfive (QUIT: Client Quit) (~Boosterfi@p5dedf5a5.dip0.t-ipconnect.de) | 22:58 | |
- ruff (QUIT: Ping timeout: 256 seconds) (~ruff@ip-78-45-99-112.net.upcbroadband.cz) | 23:25 | |
+ mjw (~mark@gnu.wildebeest.org) | 23:33 | |
- mjw (QUIT: Client Quit) (~mark@gnu.wildebeest.org) | 23:34 | |
- mtm (QUIT: Ping timeout: 250 seconds) (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 23:37 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!