| + bkeys (~Thunderbi@173.16.175.75) | 00:49 | |
| BoostisBetter | meh, it'll get eventually, they are already supporting a slightly older RK SoC | 00:50 |
|---|---|---|
| BoostisBetter | meh, it'll get there eventually, they are already supporting a slightly older RK SoC | 00:50 |
| - mtm (QUIT: Ping timeout: 252 seconds) (~textual@47.202.75.129) | 01:03 | |
| - bkeys (QUIT: Ping timeout: 276 seconds) (~Thunderbi@173.16.175.75) | 01:05 | |
| + bkeys (~Thunderbi@173.16.175.75) | 01:06 | |
| + mtm (~textual@47.202.75.129) | 01:06 | |
| - MyNetAz (QUIT: Remote host closed the connection) (~MyNetAz@user/MyNetAz) | 01:21 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@173.16.175.75) | 01:23 | |
| + bkeys (~Thunderbi@173.16.175.75) | 01:23 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@173.16.175.75) | 01:34 | |
| + bkeys (~Thunderbi@173.16.175.75) | 01:34 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@173.16.175.75) | 01:44 | |
| + bkeys (~Thunderbi@173.16.175.75) | 01:44 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@173.16.175.75) | 01:55 | |
| + bkeys (~Thunderbi@173.16.175.75) | 01:55 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@173.16.175.75) | 02:05 | |
| + bkeys (~Thunderbi@173.16.175.75) | 02:05 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@173.16.175.75) | 02:16 | |
| + bkeys (~Thunderbi@173.16.175.75) | 02:16 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@173.16.175.75) | 02:26 | |
| + bkeys (~Thunderbi@173.16.175.75) | 02:27 | |
| - mjw (QUIT: Ping timeout: 252 seconds) (~mjw@gnu.wildebeest.org) | 02:32 | |
| - midfavila (QUIT: Quit: leaving) (midfavila@sdf.org) | 02:33 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@173.16.175.75) | 02:37 | |
| + bkeys (~Thunderbi@173.16.175.75) | 02:37 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@173.16.175.75) | 02:47 | |
| + bkeys (~Thunderbi@173.16.175.75) | 02:48 | |
| - cobra (QUIT: Quit: ZNC 1.8.2 - https://znc.in) (~cobra@user/Cobra) | 02:53 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@173.16.175.75) | 02:58 | |
| + bkeys (~Thunderbi@173.16.175.75) | 02:58 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@173.16.175.75) | 03:08 | |
| + bkeys (~Thunderbi@173.16.175.75) | 03:09 | |
| - nsc (QUIT: Ping timeout: 252 seconds) (~nicolas@65-97-142-46.pool.kielnet.net) | 03:12 | |
| + nsc (~nicolas@i5C74DC72.versanet.de) | 03:14 | |
| + cobra (~cobra@user/Cobra) | 03:14 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@173.16.175.75) | 03:19 | |
| + bkeys (~Thunderbi@173.16.175.75) | 03:19 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@173.16.175.75) | 03:30 | |
| + bkeys (~Thunderbi@173.16.175.75) | 03:30 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@173.16.175.75) | 03:40 | |
| + bkeys (~Thunderbi@173.16.175.75) | 03:40 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@173.16.175.75) | 03:51 | |
| + bkeys (~Thunderbi@173.16.175.75) | 03:51 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@173.16.175.75) | 04:01 | |
| + bkeys (~Thunderbi@173.16.175.75) | 04:02 | |
| - aloo_shu (QUIT: Ping timeout: 272 seconds) (~aloo_shu@85.51.17.167) | 04:05 | |
| + aloo_shu (~aloo_shu@90.166.99.7) | 04:07 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@173.16.175.75) | 04:12 | |
| + bkeys (~Thunderbi@173.16.175.75) | 04:12 | |
| - paperManu (QUIT: Ping timeout: 246 seconds) (~paperManu@107.159.243.8) | 04:15 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@173.16.175.75) | 04:22 | |
| + bkeys (~Thunderbi@173.16.175.75) | 04:23 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@173.16.175.75) | 04:33 | |
| + bkeys (~Thunderbi@173.16.175.75) | 04:33 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@173.16.175.75) | 04:43 | |
| + bkeys (~Thunderbi@173.16.175.75) | 04:44 | |
| - aloo_shu (QUIT: Ping timeout: 272 seconds) (~aloo_shu@90.166.99.7) | 04:49 | |
| + aloo_shu (~aloo_shu@90.166.193.196) | 04:51 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@173.16.175.75) | 04:54 | |
| + bkeys (~Thunderbi@173.16.175.75) | 04:54 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@173.16.175.75) | 05:04 | |
| + bkeys (~Thunderbi@173.16.175.75) | 05:05 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@173.16.175.75) | 05:15 | |
| + bkeys (~Thunderbi@173.16.175.75) | 05:15 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@173.16.175.75) | 05:21 | |
| + bkeys (~Thunderbi@173.16.175.75) | 05:21 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@173.16.175.75) | 05:26 | |
| + bkeys (~Thunderbi@173.16.175.75) | 05:26 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@173.16.175.75) | 05:32 | |
| + bkeys (~Thunderbi@173.16.175.75) | 05:32 | |
| - bkeys (QUIT: Client Quit) (~Thunderbi@173.16.175.75) | 05:37 | |
| + bkeys (~Thunderbi@173.16.175.75) | 05:37 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@173.16.175.75) | 05:42 | |
| + bkeys (~Thunderbi@173.16.175.75) | 05:42 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@173.16.175.75) | 05:48 | |
| + bkeys (~Thunderbi@173.16.175.75) | 05:48 | |
| - bkeys (QUIT: Remote host closed the connection) (~Thunderbi@173.16.175.75) | 05:48 | |
| + jacobk (~quassel@47-186-65-73.dlls.tx.frontiernet.net) | 06:54 | |
| + jacobk_ (~quassel@47-186-65-73.dlls.tx.frontiernet.net) | 07:23 | |
| - jacobk (QUIT: Ping timeout: 260 seconds) (~quassel@47-186-65-73.dlls.tx.frontiernet.net) | 07:23 | |
| + glu_ (~glu@user/glu) | 08:27 | |
| josch | nice, kernel 6.6 can still suspend on imx8mq | 09:07 |
| - glu_ (QUIT: Ping timeout: 248 seconds) (~glu@user/glu) | 09:28 | |
| + glu_ (~glu@user/glu) | 09:28 | |
| josch | Zaba: it seems that "make olddefconfig" was exactly what i wanted, thank you! | 09:49 |
| josch | i now also understand what went wrong the other times. I first have to copy over a good default config (i can create that using snapshot.d.o) to .config, then run "make olddefconfig" to set any new symbols to their defaults and then "make localmodconfig" to disable all modules that i don't need for faster build times | 09:51 |
| josch | and for future-me: these are the docs: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/admin-guide/README.rst | 09:52 |
| + gustav28 (~gustav@c-78-82-52-90.bbcust.telenor.se) | 10:02 | |
| - jacobk_ (QUIT: Ping timeout: 248 seconds) (~quassel@47-186-65-73.dlls.tx.frontiernet.net) | 10:04 | |
| + jacobk (~quassel@47-186-65-73.dlls.tx.frontiernet.net) | 10:04 | |
| BoostisBetter | minute: now that I know about the reset button on the keyboard controller, my system is NOT crashing, as I can just restore the keyboard. SO if you need logs or anything to help triage the keyboard issue, I would be happy to privede anything you need. | 10:08 |
| BoostisBetter | minute: this morning the keyboard had disconnected again and could only be brought back with a controller reset. | 10:09 |
| + pinsl (c01623b131@2a03:6000:1812:100::121d) | 10:25 | |
| BoostisBetter | minute: and now it is crashing during use. The first time I pushed the reset button, the keyboard rgb lighting went haywire, and the keyboard was responding sporadically, then another reset saw more of the same, it wasn't until the 4th reset that the keyoard cleared all the way out and began working again. | 10:32 |
| - piroko (QUIT: Ping timeout: 245 seconds) (~piroko@104.225.216.16) | 11:38 | |
| - bpye (QUIT: Quit: Ping timeout (120 seconds)) (~bpye@user/bpye) | 12:05 | |
| + bpye (~bpye@user/bpye) | 12:05 | |
| + chomwitt (~alex@2a02:587:7a09:1500:42b0:76ff:fe46:a5fd) | 12:13 | |
| ch | does the pocket-hid try talking to sysctl even if the oled is otherwise blank? | 12:15 |
| ch | just saw a blank oled with a T | 12:15 |
| BoostisBetter | ch: yes I have been seeing that a bit as well. | 12:18 |
| BoostisBetter | But the T has been improved with minute's latest keyboard branch | 12:19 |
| - Ar|stote|is (QUIT: Ping timeout: 252 seconds) (~linx@149.210.3.168) | 12:47 | |
| + Ar|stote|is (~linx@149.210.0.92) | 12:52 | |
| amospalla | minute: I upgraded my pocket sysctl firmware from the artifacts.zip/job 7276 (a day ago "Merge branch 'sysctl-no-extras' into 'main'"), now the battery reported to the OS is not correct, neither `acpi` or my sway bar (i3status-rs) do show it reliably. This is what `while sleep 1; do acpi; done` shows: https://paste.debian.net/1342399/ . | 12:52 |
| amospalla | I am running Debian/Stable. | 12:53 |
| amospalla | I also noticed it reports much lower amps than the sysctl firmware as of the one from August you posted on the forums. Just as a comment. | 12:56 |
| ch | can you check dmesg please? | 12:56 |
| ch | because that looks like comms failure between host kernel and sysctl | 12:56 |
| + mjw (~mjw@gnu.wildebeest.org) | 12:56 | |
| - mtm (QUIT: Ping timeout: 244 seconds) (~textual@47.202.75.129) | 13:03 | |
| amospalla | ch: true, its shows from time to time lines like the last four on this dmesg https://paste.debian.net/1342401/ | 13:05 |
| + mtm (~textual@47.202.75.129) | 13:05 | |
| ch | but that doesnt match the jumps in the while loop? | 13:05 |
| amospalla | more here https://paste.debian.net/1342402/ | 13:05 |
| ch | (dmesg -T gives you human timestamps) | 13:06 |
| amospalla | I understand, let me do a better paste. | 13:06 |
| + shdw (~shdw@static.218.156.216.95.clients.your-server.de) | 13:30 | |
| amospalla | ch: https://paste.debian.net/1342405/ | 13:31 |
| ch | yeah so probably that | 13:32 |
| BoostisBetter | ch: any idea what the problem is? | 13:51 |
| ch | not really, the SPI interface is just not super stable as is | 13:51 |
| ch | i've been wondering if keyboard and linux interfere with each other | 13:52 |
| BoostisBetter | ok, I know there will be a solution eventually but I am glad I am not the only one experiencing these things. | 13:52 |
| ch | well it seems a lot worse for you | 13:53 |
| BoostisBetter | I am actually thinking about drilling a hole in my keyboard top cover so I can just hit the keyboard reset button without having to remove it | 13:53 |
| ch | i see the occasional timeout but its not breaking anything | 13:53 |
| BoostisBetter | ch: Are you using anything from amospalla? rmt tools or anything? | 13:58 |
| ch | no | 13:58 |
| + paperManu (~paperManu@107.159.243.8) | 13:59 | |
| ch | biggest like on the rp2040 imo: the C SDK is really well thought out | 14:12 |
| ch | biggest dislike: nobody seems to be using the C SDK | 14:12 |
| minute | ch: keyboard talks over uart, so on hw level they should not disturb. | 14:18 |
| minute | ch: but maybe interrupt driven uart could be a culprit | 14:18 |
| ch | right. well at some point all the things should be interrupt driven, maybe that would also help | 14:18 |
| minute | i.e. interrupt in the middle of spi | 14:19 |
| minute | yeah, depending on priorities | 14:19 |
| minute | this is going into small operating system design | 14:19 |
| minute | territory | 14:19 |
| ch | btw i couldnt find a HID class for batteries or an existing driver in linux.git, but havent spent more than 5 min yet | 14:19 |
| ch | heh yes | 14:19 |
| ch | step 1: rewrite in rust *runs* | 14:20 |
| minute | one could also look at zephyr and such | 14:20 |
| ch | yeah or check what the chromebook ec does | 14:21 |
| ch | iirc that has some rtos | 14:21 |
| minute | https://docs.zephyrproject.org/latest/boards/raspberrypi/rpi_pico/doc/index.html | 14:21 |
| ch | ah yes, that uses zephyr | 14:21 |
| minute | and https://zmk.dev/ | 14:21 |
| ch | zmk is qmk on zephyr? | 14:22 |
| ch | right | 14:22 |
| ch | standalone keyboard might be a good experimentation platform for that | 14:23 |
| minute | yeah | 14:23 |
| ch | well before i start a new expedition i want to get the usb stuff done | 14:25 |
| minute | for sure | 14:34 |
| minute | i'm in the train(s) back to berlin from my dad's funeral. work will resume on monday. | 14:48 |
| - aloo_shu (QUIT: Ping timeout: 265 seconds) (~aloo_shu@90.166.193.196) | 14:50 | |
| ch | take your time | 14:51 |
| + aloo_shu (~aloo_shu@90.166.99.62) | 14:52 | |
| BoostisBetter | minute: I am so sorry to hear! Thank you for all of your efforts and seriously take all the time you need! | 14:53 |
| ch | https://github.com/fwupd/fwupd/pull/8270 | 15:08 |
| ch | jfyi | 15:08 |
| + bkeys (~Thunderbi@173.16.175.75) | 15:14 | |
| - aloo_shu (QUIT: Ping timeout: 272 seconds) (~aloo_shu@90.166.99.62) | 15:19 | |
| + aloo_shu (~aloo_shu@85.51.18.188) | 15:22 | |
| - bkeys (QUIT: Ping timeout: 252 seconds) (~Thunderbi@173.16.175.75) | 15:52 | |
| minute | pushed some first watchdog test code from the train | 16:15 |
| minute | funnily, it gets triggered when using the "power on" command from the oled menu | 16:16 |
| ch | :o | 16:16 |
| minute | probably because the fade in animation takes longer than 100 ms | 16:16 |
| minute | so it might be more prudent to set the watchdog interval to 1000ms or so | 16:16 |
| ch | probably good idea. if it does hang/crash one can wait a bit, and then its also more obvious its happening | 16:17 |
| ch | (otoh i guess the leds will go out anyway) | 16:17 |
| minute | i did it so that it sets the LEDs to full red and shows a message on oled... just for testing now | 16:18 |
| ch | ah nice | 16:18 |
| minute | but we'll have to be lucky so that the hang triggers the watchdog reset at all... | 16:18 |
| ch | mh? | 16:18 |
| minute | for example, it could also be a hard crash or memory (code) corruption | 16:19 |
| ch | and the wd doesnt trigger on that? | 16:19 |
| ch | (if its memory corruption i hope that will also break the main loop) | 16:19 |
| minute | not if the WD code/handler is itself corrupted | 16:19 |
| minute | i'm not sure atm if the SPI flash is re-read on such a reset | 16:20 |
| ch | uhuh. i had hoped thats all in hardware | 16:20 |
| minute | now reading https://vanhunteradams.com/Pico/Bootloader/Boot_sequence.html | 16:22 |
| ch | datasheet is not super clear about it, but i think it implies hw does it and then a normal reset runs | 16:27 |
| minute | it reads like "normally" code is executed directly from flash?! | 16:35 |
| - jacobk (QUIT: Ping timeout: 248 seconds) (~quassel@47-186-65-73.dlls.tx.frontiernet.net) | 16:37 | |
| minute | > Is the Pico able to run code in RAM? | 16:37 |
| minute | > Yes, it's a simple flag in the Cmake file. | 16:37 |
| minute | > cmake -DPICO_COPY_TO_RAM=1 | 16:38 |
| minute | also > void __not_in_flash_func(some_function_name) | 16:38 |
| minute | ok so executing directly from flash is of course a hang source | 16:39 |
| minute | if there's some big disturbance in the force (EMI) it would just stumble i guess... | 16:39 |
| minute | as the flash is not internal in contrast to i.e. attiny, atmega32u4 | 16:39 |
| minute | we have 264kB SRAM which is not bad though | 16:40 |
| minute | our current uf2 is 109kB | 16:41 |
| - glu_ (QUIT: Read error: Connection reset by peer) (~glu@user/glu) | 17:11 | |
| + glu_ (~glu@user/glu) | 17:11 | |
| ch | toram might need a good test, i think there might be interesting cornercases | 17:15 |
| amospalla | Could it help if I flash all the sysctl firmware from gitlab jobs since job 5694 to latest until I find the one where battery is not reported correctly? | 17:40 |
| amospalla | (not exactly all, but doing a binary search) | 17:41 |
| ch | yeah | 17:43 |
| amospalla | ok | 17:43 |
| ch | before you do that, maybe try the usbpd branch | 17:44 |
| ch | and see if it has the same issue | 17:44 |
| amospalla | Is there any known artifact containing a borked firmware? | 17:44 |
| amospalla | do you mean usb-preempt? I don't see any usbpd branch on "MNT Pocket Reform" repository | 17:46 |
| ch | https://source.mnt.re/zeha/pocket-reform/-/commits/zeha-usbpd | 17:46 |
| ch | usb-preempt does nothing to the sysctl | 17:46 |
| amospalla | mmh, my pocket now doesn't have a usb device with id 2e8a:000a and can't update | 17:52 |
| ch | yes, you need to use reform-mcu-tool | 17:52 |
| ch | (or fwupd) | 17:52 |
| amospalla | That means, since certain firmware version it changed the upgrade process? | 17:53 |
| - glu_ (QUIT: Read error: Connection reset by peer) (~glu@user/glu) | 17:54 | |
| + glu_ (~glu@user/glu) | 17:54 | |
| amospalla | Yes, that must be. reform-mcu-tool list didn't show anything before I updated, now it does. | 17:54 |
| ch | yeah that changed | 17:54 |
| amospalla | How do I upgrade using reform-mcu-tool ? | 17:54 |
| amospalla | it has three commands, none sounds like a firmware upgrade. | 17:55 |
| ch | reform-mcu-tool bootsel pocket-sysctl-1.0 and then continue with picotool as usual | 17:55 |
| amospalla | ohh I see, thank you | 17:55 |
| ch | wel, picotool load | 17:55 |
| ch | should write this down somewhere, but not sure where | 17:57 |
| - spew (QUIT: Remote host closed the connection) (~spew@135.233.119.40) | 18:10 | |
| + spew (~spew@135.233.119.40) | 18:10 | |
| amospalla | ch: I still don't find the usb device 2e8a:000a, does this say something to you https://paste.debian.net/1342425/ ? | 18:15 |
| ch | ok the update script is expecting a running sysctl, not one already in the bootrom | 18:16 |
| ch | just go picotool load -f sysctl.uf2 && picotool reset -f | 18:16 |
| amospalla | ok | 18:16 |
| ch | (make sure you have the right device and file, you can crossflash hid/keyboard and sysctl if you are not careful) | 18:17 |
| amospalla | I'm sure I'm loading the sysctl file, but I don't know what I'm doing with picotool, what device it is accessing. | 18:17 |
| - chomwitt (QUIT: Ping timeout: 248 seconds) (~alex@2a02:587:7a09:1500:42b0:76ff:fe46:a5fd) | 18:18 | |
| amospalla | I mean, I ran reform-mcu-tool bootsel, but I'm don't really know what's going on behind that. | 18:18 |
| minute | amospalla: try without -f first | 18:18 |
| minute | -f means force | 18:19 |
| amospalla | The keyboard firmware is the stock one, if that helps. | 18:19 |
| ch | i could never tell what -f really does in picotool | 18:19 |
| amospalla | Go ahead with picotool load sysctl.uf2? | 18:20 |
| ch | yeah from your paste it looks fine | 18:20 |
| amospalla | ok: Loading into Flash: [==============================] 100% | 18:20 |
| amospalla | now it should be `picotool reboot -f` ? This is what the script does next. | 18:22 |
| amospalla | The script also states that flashing this would power off the system, and because of that does the dance of "echo u > sysrq-triger, etc", but my system has not rebooted. | 18:23 |
| ch | only happens if you upgrade from too old sysctl firmware | 18:24 |
| amospalla | Oh, well, yeah, maybe because I have still not ran `picotool reboot -f` | 18:24 |
| ch | but yes, after picotool reboot, if it happens :) | 18:24 |
| amospalla | But the firmware is already flashed right? | 18:24 |
| ch | but not running until you run picotool reboot | 18:25 |
| amospalla | I'll poweroff and switch off/on the physical button. | 18:26 |
| amospalla | Oh I see now the famous "T". | 18:27 |
| amospalla | ch: I don't see any message on dmesg with your firmware. Acpi shows much less "Not charging, 70%" or "Discharging, 70%, discharging at zero rate - will never fully discharge." | 18:35 |
| amospalla | Oh, here it is, one message appeared on dmesg. | 18:36 |
| amospalla | Anyway, I don't want to mess anything, I'll go back to August firmware, and go forward with real data, because I feel I'm saying things without any baseline, or even false things. | 18:38 |
| - glu_ (QUIT: Ping timeout: 248 seconds) (~glu@user/glu) | 19:00 | |
| + glu_ (~glu@user/glu) | 19:04 | |
| - amospalla (QUIT: Quit: WeeChat 4.4.4) (~jordi@user/amospalla) | 19:27 | |
| + amospalla (~jordi@user/amospalla) | 19:28 | |
| grimmware | hey, does anyone have a recommendation for viewing webp files without using a web browser that is of a similar level of lightweight as the MNT sway desktop? | 20:29 |
| spew | I use mpv for all things av | 20:30 |
| grimmware | yeah I tried that and it shat the bed :/ | 20:31 |
| spew | it even has built-in support for youtube or http via curl and yt-dlp | 20:31 |
| spew | what file? | 20:31 |
| ch | vlc | 20:32 |
| ch | ? | 20:32 |
| minute | grimmware: make sure that you don't have a .config/mpv.conf from the olden times with hw accel auto | 20:32 |
| minute | buuut webp is a picture right | 20:33 |
| grimmware | no it's an animation | 20:33 |
| minute | ah | 20:33 |
| minute | nomacs would be another candidate | 20:34 |
| grimmware | minute: is mpv not expected to play an animated webp? | 20:35 |
| minute | grimmware: i never tried, i thought it was mainly for movies | 20:35 |
| grimmware | spew: `mpv https://grimmwa.re/files/thatonemask.webp` | 20:36 |
| antti | mpv should play webp. sometimes I even open png files by mistake rather than using imv :P | 21:12 |
| grimmware | antti: can you try opening the above and see if it works? | 21:55 |
| grimmware | it's an image that I found years ago (possibly over a decade) ago on tumblr which has been etched in my brain ever since and I managed to find it again | 21:56 |
| antti | hmm it didn't work. mpv couldn't open it. even after I download it. I open it with imv without issues | 22:06 |
| antti | it is weird that it can be open with ffpeg either.that is really odd | 22:11 |
| - gustav28 (QUIT: Quit: Quit) (~gustav@c-78-82-52-90.bbcust.telenor.se) | 22:15 | |
| grimmware | okay so it's not just me then | 22:23 |
| grimmware | honestly mostly I wanted to know whether it was just this file or not | 22:23 |
| - bpye (QUIT: Ping timeout: 248 seconds) (~bpye@user/bpye) | 22:35 | |
| antti | there is something wrong with it. | 22:35 |
| antti | the only way that I found to play it is by convert it | 22:36 |
| antti | magick convert thatonemask.webp thatonemask.gif | 22:36 |
| antti | mpv thatonemask.gif works for me | 22:37 |
| + jacobk (~quassel@47-186-65-73.dlls.tx.frontiernet.net) | 22:39 | |
| + ephase (~ephase@2a01:e0a:2a:5300:8af3:6216:8fce:7058) | 22:57 | |
| + bpye (~bpye@user/bpye) | 23:05 | |
| - jacobk (QUIT: Ping timeout: 276 seconds) (~quassel@47-186-65-73.dlls.tx.frontiernet.net) | 23:31 | |
| + jacobk (~quassel@47-186-65-73.dlls.tx.frontiernet.net) | 23:32 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
