| Boostisbetter | no pun intended right? | 00:08 |
|---|---|---|
| Boostisbetter | hahaha | 00:08 |
| Boostisbetter | ANyway still dreaming about the Pocket Reform | 00:08 |
| - bgs (QUIT: Remote host closed the connection) (~bgs@212-85-160-171.dynamic.telemach.net) | 00:11 | |
| - ajr (QUIT: Quit: WeeChat 3.7) (~ajr@user/ajr) | 00:34 | |
| minute | very cool https://fathy.fr/carbonyl | 00:37 |
| - mtm (QUIT: Ping timeout: 252 seconds) (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 01:04 | |
| chartreuse | INB4 pico reform that's compute stick sized | 01:37 |
| violet | josch: depends on both in my experience. rock64 for example can easily handle 30fps h264 decode both in software _or_ in hardware, but playback is only smooth from tty where mpv can decode direct to a video display layer, cutting out a lot of memory copies from the equation | 02:46 |
| violet | well, i guess i wouldnt say that its "easy" in software for the rock64 actually. but the point being that the hardware decode can handle a lot more than either the memory bandwidth or gpu compositing can handle under wayland (not sure which is the bottleneck) | 02:47 |
| violet | cause under X/wayland it can only do the version that copies the frames back from the hardware decoder to userspace ram before then sending them back to the GPU to render it | 02:49 |
| violet | this isn't like, a limitation that _needs_ to exist, but it exists because nobody's written tho code to plumb together the bits that let the fast path work | 02:50 |
| violet | but some chips like the one in the pinebookpro can basically just brute-force this by just having enough headroom that it still works out alright | 02:51 |
| violet | anyways if the hardware decoding on the imx8m* is based on v4l2-requests the way it is on rock64, you can definitely use ffmpeg with it, but you need to use a patched ffmpeg because I think that still hasn't been merged upstream unfortunately | 02:53 |
| + sevan (~sevan@user/venture37) | 02:53 | |
| violet | rafostar[m]: if you do actually have software that can do playback without coping through system ram like you say, do you know if its using the same mechanisms as mpv's `drm` (not `drm-copy`) decode scheme? if so, then i suspect the patched ffmpeg im referring to would also work | 02:56 |
| violet | i guess all the more reason for me to order one and find out for myself | 02:58 |
| - vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:7:77:0:20) | 03:03 | |
| violet | are there any SBCs that have the imx8mplus i could get maybe sooner than I'd get a reform? | 03:05 |
| violet | i kinda want to wait for the pocket anyway, going back and forth on that | 03:05 |
| - Guest6226 (QUIT: Ping timeout: 260 seconds) (~nicolas@128-49-142-46.pool.kielnet.net) | 03:08 | |
| + mtm (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 03:10 | |
| + nsc (~nicolas@168-49-142-46.pool.kielnet.net) | 03:10 | |
| * nsc -> Guest8046 | 03:11 | |
| + vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:40) | 04:13 | |
| - vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:7:77:0:40) | 05:10 | |
| - jjbliss (QUIT: Ping timeout: 265 seconds) (~jjbliss@1464766-static.elnsmiaa.metronetinc.net) | 07:14 | |
| + jjbliss (~jjbliss@1464766-static.elnsmiaa.metronetinc.net) | 07:18 | |
| rafostar[m] | <violet> "rafostar: if you do actually..." <- Not DRM because we have a whole GTK4 GUI on top of it. Internally we get DMABuf pointer from decoder, use a MESA extension to turn it into GL texture. Pass texture ID to GTK4 so it will show it on clock. It was tested with v4l2, vaapi and nvdec that GStreamer supports and worked well. One limitation is that it needs Wayland to do so, but I am not gonna focus on X11 these days. | 08:27 |
| - jnerula_ (QUIT: Ping timeout: 265 seconds) (~jnerula@li1009-93.members.linode.com) | 08:37 | |
| violet | yeah i looked into it a little more, it looks like `mpv` also has this experimentally with `wayland-dmabuf` video output now | 09:45 |
| violet | only on weston/sway though for now but luckily i use sway | 09:45 |
| violet | that is recent i think | 09:45 |
| * Guest8046 -> nsc | 10:23 | |
| rafostar[m] | <violet> "yeah i looked into it a little..." <- Use whatever you like obviously. I personally prefer GStreamer over ffmpeg/MPV backend. It gives me much more freedom then ffmpeg does. | 10:41 |
| - eschaton (QUIT: Quit: ZNC 1.8.x-git-34-0db5c235 - https://znc.in) (eschaton@2600:3c01::f03c:91ff:fefd:5d92) | 10:48 | |
| + eschaton (eschaton@2600:3c01::f03c:91ff:fefd:5d92) | 10:48 | |
| - eschaton (QUIT: Remote host closed the connection) (eschaton@2600:3c01::f03c:91ff:fefd:5d92) | 11:36 | |
| + eschaton (~eschaton@li541-49.members.linode.com) | 11:36 | |
| - GNUmoon (QUIT: Read error: Connection reset by peer) (~GNUmoon@gateway/tor-sasl/gnumoon) | 12:33 | |
| + GNUmoon (~GNUmoon@gateway/tor-sasl/gnumoon) | 12:33 | |
| - GNUmoon (QUIT: Ping timeout: 255 seconds) (~GNUmoon@gateway/tor-sasl/gnumoon) | 12:51 | |
| + GNUmoon (~GNUmoon@gateway/tor-sasl/gnumoon) | 12:57 | |
| - mtm (QUIT: Ping timeout: 260 seconds) (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 13:02 | |
| - GNUmoon (QUIT: Ping timeout: 255 seconds) (~GNUmoon@gateway/tor-sasl/gnumoon) | 13:24 | |
| + GNUmoon (~GNUmoon@gateway/tor-sasl/gnumoon) | 13:26 | |
| josch | flowy: doesn't matter because the build failed anyways. The error log looks like the ffmpeg patch was not updated to work on recent systems. | 13:34 |
| josch | violet: do you have experience with the ffmpeg v4l2-requests patch stack? It worked fine for ffmpeg 4 but the patches didn't apply anymore with ffmpeg 5. A few months ago the patch stack got rebased onto ffmpeg 5 and i managed to build and run the thing but I got red-tinged output with mpv. Now I tried rebuilding it again and it fails because it cannot find some functions (ioctl and close, so probably | 13:39 |
| josch | some #include is missing). Does the ffmpeg v4l2-requests patch stack work for you on your rock64 with ffmpeg 5? | 13:39 |
| - S0rin (QUIT: Read error: Connection reset by peer) (~S0rin@user/s0rin) | 14:39 | |
| + S0rin (~S0rin@user/s0rin) | 14:40 | |
| minute | here's a fun thing: suspend/wake half works | 14:55 |
| minute | if i suspend and wake, i come to a black screen, but the backlight is on | 14:55 |
| minute | so if i do super+enter and enter pkill sway, the console springs to life | 14:55 |
| minute | suspending in console and then after wake typing sway also works | 14:56 |
| minute | so it's just something about the display not reinitializing correctly | 14:56 |
| minute | (this is with dcss, will try with lcdif) | 14:56 |
| minute | (still on 6.0.0 though) | 14:57 |
| minute | same problem with lcdif | 15:02 |
| minute | i wonder if gpu related... going from console to sway doesn't actually bring the display to life after wake, only exiting sway to console | 15:02 |
| + mtm (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 15:08 | |
| minute | upgrading to 6.1 now. | 15:10 |
| minute | still the same issue. i wonder if it's related to the nwl-dsi driver, as the behavior is the same for lcdif and dcss. | 15:14 |
| minute | one could experiment with putting sysfs or handlers in these drivers and try to nudge them from userspace after wakeup | 15:19 |
| josch | minute: you are talking about imx8mq? | 15:21 |
| minute | josch: ytes. | 15:21 |
| minute | yes | 15:21 |
| josch | oh i thought suspend/wake already worked and my system was just borked somehow? | 15:22 |
| minute | no, i think it regressed | 15:22 |
| minute | strangely, switching to another console with ctrl+alt+f2 and back also doesn't make the display work again... but pkill sway does | 15:26 |
| minute | i wonder what would happen if i were to switch resolution | 15:26 |
| minute | or scale, that is | 15:26 |
| minute | found a workaround | 15:34 |
| minute | blindly typing the following works: swaymsg output eDP-1 disable; swaymsg output eDP-1 enable | 15:34 |
| minute | little test: bindsym $mod+x exec 'swaymsg output eDP-1 disable; swaymsg output eDP-1 enable' | 15:36 |
| minute | works! | 15:37 |
| minute | so now the question, how to send a message to sway in the suspend script | 15:37 |
| minute | here's an ugly hack: | 15:53 |
| minute | sway_display_restart() { | 15:53 |
| minute | export SWAYSOCK=$(echo /run/user/1000/sway-ipc*.sock) | 15:53 |
| minute | swaymsg output eDP-1 disable | 15:53 |
| minute | swaymsg output eDP-1 enable | 15:53 |
| minute | } | 15:53 |
| minute | btw, somehow i didn't notice before that cpu frequency scaling is happening. in htop under f2->display options you can enable display of the frequency for the cpu cores | 16:05 |
| minute | it toggles between 1000mhz and 1500mhz for me depending on what i do | 16:05 |
| sigrid | maybe sway doesn't get some kind of event then? | 16:07 |
| minute | sigrid: the same problem is also in the linux console, without sway | 16:08 |
| - buckket (QUIT: Read error: Connection reset by peer) (~buckket@pdp8.buckket.org) | 16:09 | |
| minute | the display re-enabling just nudges something in the kernel display stack | 16:09 |
| sigrid | interesting | 16:09 |
| minute | don't have the energy/tools right now to investigate what exactly that is in the kernel | 16:10 |
| + buckket (~buckket@pdp8.buckket.org) | 16:14 | |
| - cwebber (QUIT: Remote host closed the connection) (~user@user/cwebber) | 19:57 | |
| josch | I lack the skill to fix this properly in the kernel but since the script cannot know the user running sway, maybe this can replace the 1000 in sway_display_restart: | 21:26 |
| josch | $(pgrep sway | xargs -I'{}' ps -p '{}' --format uid= | sort -u) | 21:26 |
| josch | this will find all sway processes and print their user ids (hopefully only one after running through sort -u) | 21:26 |
| + vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:40) | 21:47 | |
| + jnerula (~jnerula@li1009-93.members.linode.com) | 22:26 | |
| bluerise | AH FOR FUCKS SAKE | 22:49 |
| bluerise | minute: I found out why my PCIe wasn't working anymore... | 22:49 |
| ex-parrot | Card fell out? | 22:50 |
| josch | breadcrumbs found their way from the keyboard to the bottom of the unit? (don't ask) | 22:51 |
| minute | bluerise: what was it | 22:51 |
| bluerise | someone at u-boot replaced the power domain driver that calls into ATF with a 'we twiddle the bits ourselves' one | 22:52 |
| bluerise | I ruled out the power domain stuff because I thought no one would ever touch that again | 22:52 |
| bluerise | turns out I was wrong | 22:52 |
| bluerise | u-boot=> pci | 22:54 |
| bluerise | BusDevFun VendorId DeviceId Device Class Sub-Class | 22:54 |
| bluerise | _____________________________________________________________ | 22:54 |
| bluerise | 00.00.00 0x16c3 0xabcd Bridge device 0x04 | 22:54 |
| bluerise | 01.00.00 0x1987 0x5012 Mass storage controller 0x08 | 22:54 |
| bluerise | better | 22:54 |
| josch | bluerise: are you working on making upstream u-boot work on the reform? | 22:57 |
| bluerise | yes, already sent v6 of my basic support patch | 22:57 |
| josch | wow this is awesome, thank you for working on that!! :D | 22:58 |
| minute | bluerise: wow! | 22:59 |
| bluerise | ok, booted with NVMe on current U-Boot master | 23:00 |
| bluerise | now I can try and add the lcdif stuff | 23:00 |
| bluerise | ... or debug the power domain thing first, I reverted the change locally for now.. sigh | 23:00 |
| minute | meanwhile i am debugging etnaviv | 23:01 |
| minute | i think glVertexAttribPointer is broken and causes mmu faults | 23:01 |
| bluerise | found the bug, yay, can send another diff to u-boot :D | 23:06 |
| minute | awesome | 23:07 |
| josch | bluerise: this still requires the memory training binary blob, right? | 23:07 |
| bluerise | yep | 23:08 |
| josch | works for me -- Debian now has a new archive section exclusively for firmware that is loaded up on some chip but isn't part of the OS otherwise. If reform support is in upstream u-boot then Debian can build u-boot for the reform and ship the memory training blob as addon package in the non-free-firmware section. | 23:10 |
| josch | vagrantc: ^ | 23:10 |
| bluerise | ok, PCIe fixed and the PCIe driver is a little nicer now as well | 23:15 |
| bluerise | now... lcdif... | 23:15 |
| vagrantc | josch: last i looked, the licensing on those training blobs still wasn't permissive enough to allow redistribution ... but maybe i am misremembering | 23:22 |
| minute | hmm i hope i haven't found a serious problem, it looks like glVertexAttribPointer() with invalid pointers might be able to scribble into memory | 23:23 |
| vagrantc | josch: but yeah, i have been wondering a bit about the ramifications for debian's policy changes regarding firmware as they relate to u-boot or similar | 23:24 |
| minute | it can def. ruin other programs' textures and cause weird dmesg messages... building the latest mesa git to see if the problem is still there | 23:24 |
| josch | vagrantc: hrm... maybe... i guess minute knows the answer. But even if the license doesn't allow redistributions, we can ship the training blob in reform-tools because apparently minute is allowed to redistribute it. :) | 23:48 |
| minute | ;) | 23:49 |
| minute | https://gitlab.freedesktop.org/mesa/mesa/-/issues/8180 | 23:49 |
| josch | oh wow that must've been really "funny" to track down | 23:51 |
| minute | yeah it took a few hours | 23:52 |
| minute | i have kind of a migraine today and was "bored" | 23:52 |
| minute | but i learned more about using apitrace and qapitrace | 23:52 |
| minute | one can capture a programs opengl calls and then selectively replay them and inspect state at any point | 23:52 |
| minute | and also toggle the calls on and off | 23:52 |
| minute | that way you can boil it down to the offending calls | 23:52 |
| josch | uff.. hope you feel better soon! i cannot concentrate on anything when having a migraine XD | 23:58 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!