<deathmist>
bonfire_: I couldn't at least find traces of libinput on the filesystem as per package files reported by "xbps-query -f libinput" on my Void Linux desktop
<jenneron[m]>
you may also check downstream sources for kukui, it should be <50 patches over mainline, check whether there are any parches for touchpad
<jenneron[m]>
patches*
hexdump01 has joined #linux-cros-arm
hexdump0815 has quit [Ping timeout: 480 seconds]
robclark_ has joined #linux-cros-arm
robclark has quit [resistance.oftc.net larich.oftc.net]
<jenneron[m]>
deathmist: I think "Linux 5.10.158" commit is mainline and everything after are downstream patches?
<jenneron[m]>
oh no, they merge stable updates, yeah
<jenneron[m]>
that's not convenient
<jenneron[m]>
they also may have more patches than i've thought
<jenneron[m]>
deathmist: what touchpad does it use? (check evtest)
<deathmist>
jenneron: evtest on Linux (not CrOS) I'm assuming?
<jenneron[m]>
yes
<deathmist>
jenneron: In my case the touchpad is /dev/input/event9 "Google Inc. Hammer" using https://cateee.net/lkddb/web-lkddb/HID_GOOGLE_HAMMER.html, and interestingly when evtest keeps reporting events the mouse sometimes just stops moving, so I guess I'm blaming libinput after all
<deathmist>
there's also /dev/input/event8 "Google Inc. Hammer" which is the keyboard itself, the touchpad just has it's own event device
<deathmist>
jenneron: idk where it would have something like that, I already checked all dirs/files reported by "xbps-query -f libinput" on my Void Linux desktop and found nothing libinput related on chrome os
<jenneron[m]>
sorry, i don't get it
<jenneron[m]>
void linux on chrome os?
<deathmist>
basically, I found no traces of libinput on chrome os
<jenneron[m]>
i see
<deathmist>
I checked the whole filesystem
<deathmist>
and paths the libinput package on Void Linux contains
<deathmist>
should be fixed by next major wlroots/sway update
<jenneron[m]>
first of all, try v4l2-ctl --all
<jenneron[m]>
if it lists decoder, try to play a h264 video with ffplay -vcodec h264_v4l2m2m file.mp4
robclark_ has quit []
robclark has joined #linux-cros-arm
<deathmist>
jenneron: "Failed to open /dev/video0: No such file or directory" even when running "v4l2-ctl --all" as root after adding the patch
<deathmist>
scp.img firmware loading is failing and "fops_vcodec_open(),165: [MTK_V4L2][ERROR] vpu_load_firmware failed!" is also shown afterwards
<deathmist>
looks like I'll have to get the firmware in place
<deathmist>
there's 12 partitions under mmcblk0, where should I look? guess I'll check chromeos root
<deathmist>
...or not yet :) EXT4-fs (mmcblk0p1): The kernel was not built with CONFIG_QUOTA and CONFIG_QFMT_V2
<deathmist>
welp mmcblk0p1 was useless, weird hierarchy I've never seen before: dev_image encrypted encrypted.block encrypted.key etc home lost+found reboot_vault unencryptedvar_overlay
<deathmist>
"/dev/mmcblk0p3 8687616 17076223 8388608 4G ChromeOS root fs" found my target
<jenneron[m]>
<deathmist> "for fun and got EXT4-fs (..." <- why would we care about chrome os partition layout?
<deathmist>
jenneron: from what I can tell it looks for /lib/firmware/scp.img, so looks like it doesn't have a firmware-name defined in DTS for scp
<jenneron[m]>
you can temporarily make a symlink
<jenneron[m]>
to test it
<jenneron[m]>
we can easily workaround it in packages
<deathmist>
jenneron: I guess we don't care about the layout, can the whole eMMC be wiped and replaced with Linux? I'm still booting from USB stick and I'm very clueless about most things
<deathmist>
ideally I'd even want to replace this crappy stock bl
<deathmist>
on both boots I used the MP4 in https://download4.dvdloc8.com/trailers/divxdigest/serenity_hd_dvd-trailer.zip as the sample, had the "ln -s /lib/firmware/mediatek/mt8183/scp.img /lib/firmware/scp.img" symlink in place, but on boot 1 video didn't play but it seemed to at least do something and showed an audio visualisation, while on boot 2 with h264 decoder it just failed
<deathmist>
I'm still on boot 2 btw if there's further things I could check
<deathmist>
it seems if I reboot I may or may not have video decoder available, and in other cases it'll just have no working audio from what I can tell
<jenneron[m]>
second is definitely better
<jenneron[m]>
maybe it doesnt have v4l2m2m api, but has v4l2-request
<jenneron[m]>
run it when mtk-vcodec-dec is available
<deathmist>
jenneron: it segfaulted
<jenneron[m]>
well.. any other gstreamer-based player should be suitable
<deathmist>
soon after "(parole:14171): GLib-GObject-WARNING **: 19:54:30.327: invalid cast from 'GdkWaylandDisplay' to 'GdkX11Display'"
<deathmist>
I could switch to the X11 Sxmo session from Sway
<jenneron[m]>
i will try to find one which works on my mt8173 (it uses another video decoder, but still)
<deathmist>
jenneron: on dwm sxmo session, had to also install gst-libav but now it's playing, think it's using software decoding however based on CPU usage I see in htop (100% on 2 cores pretty much), should there be some logs?
<deathmist>
I just see some parole related shell scripts being broken with "sewd: unterminated {" and "sh: out of range" in the output during this
<deathmist>
s/sewd/sed/
<deathmist>
I can hear audio too though so I guess that's also good :)
<deathmist>
"v4l2codecs plugin.c:52:register_video_decoder:<v4l2decoder0> Registering mtk-vcodec-dec-proc as H264 Decoder" and right under "v4l2codecs-h264dec gstv4l2codech264dec.c:1532:gst_v4l2_codec_h264_dec_register: Not registering H264 decoder since it produces no supported format", are those related? full log from "rm -rf ~/.cache/gstreamer-1.0; GST_DEBUG=4 parole <mp4 file>":