#linux-media 2021-07-15,Thu

hey, for whatever reason, I'm getting an "Unable to parse link: Operation not permitted (1)" error when trying to run a `media-ctl -d /dev/media0 -l ...` command. I'm running the command as root, and /dev/media0 exists. Does anyone have any suspicions about what might be wrong, or can I enable debug prints somehow?
Nothing is printed to dmesg even though I wrote 0x1f to all the dev_debug files I could find in /sys/class/video4linux
--print-dot prints https://p.mort.coffee/WbI

[10:09]

***

camus has joined #linux-media
camus1 has quit IRC (Remote host closed the connection)

[10:14]

.......... (idle for 49mn)

hverkuil has quit IRC (Quit: ZNC 1.8.2+deb2+b1 - https://znc.in)

[11:03]

hverkuil has joined #linux-media
hverkuil has quit IRC ()

[11:12]

hverkuil has joined #linux-media
NiksDev2 has quit IRC (Remote host closed the connection)
NiksDev2 has joined #linux-media

[11:18]

svarbanov has quit IRC (Ping timeout: 480 seconds)

[11:24]

svarbanov has joined #linux-media

[11:38]

svarbanov has quit IRC (Ping timeout: 480 seconds)

[11:48]

svarbanov has joined #linux-media

[11:56]

..... (idle for 24mn)

svarbanov has quit IRC (Ping timeout: 480 seconds)
BrianG61UK has quit IRC (Read error: Connection reset by peer)

[12:20]

svarbanov has joined #linux-media

[12:28]

........ (idle for 39mn)

kbingham

hverkuil, Hi!, I'd like to properly test that vb2 fix you sent, and I recall you said there was a control in vivid to potenitally recreate the issue - I can't find that reference though, was I dreaming?

[13:07]

hverkuil

kbingham: what vb2 fix? I've been working on other things and this fell out of my brain-cache...

[13:08]

kbingham

hverkuil, Ah, the title of the patch is "vb2 fix" ;-)
It was to do with a qbuf failing
or more precisely ...

[13:09]

hverkuil

ah yes.

[13:09]

kbingham

If the stream fails to start, it doesn't return a buffer that it should have I think.

[13:09]

hverkuil

Um, the commit log in that patch says how to do it :-)
v4l2-ctl -c inject_vidioc_streamon_error=1

[13:10]

kbingham

hverkuil, ...
...
Great. I knew I'd read it - and then I looked everywhere except right in front of me ...
Well at least I wasn't dreaming ;-) thanks!

[13:10]

hverkuil

You're welcome!
Note that the same issue can happen with the Request API, and I don't really know how to solve that. It's on my TODO list to figure this out, but it's a pretty low prio.

[13:10]

mort_

this particular command fails and I don't understand why: media-ctl -d /dev/media0 -l '"msm_csiphy1":1 -> "msm_csid1":0[1]'

https://p.mort.coffee/Cr8.svg

I'm able to connect csid1 to ispif1, ispif1 to vfe0_pix, and vfe0_pix to vfe0_video3
but not csiphy1 to csid1

[13:20]

pinchartl

the graph looks very wrong
the 6 yellow blocks at the top should be green
they're subevs, they should have pads

[13:21]

mort_

they have pads according to the topolgoy
topology*

[13:22]

pinchartl

what's the output of media-ctl -d /dev/media0 -p

[13:22]

mort_

https://p.mort.coffee/DLw

[13:22]

pinchartl

indeed. I wonder why the graphical representation is incorrect

[13:23]

mort_

I'm working on upgrading from linux 4.9 to linux 5.7, it looked about the same in 4.9 and everything worked
I can put 4.9 on it and give you a graph from that if you want

[13:24]

pinchartl

does adding -v give you any extra information when you set the link with -l ?

[13:24]

mort_

oh wow, I tried running the csiphy1->csid1 link again and the kernel got unhappy: https://p.mort.coffee/DLQ
now media-ctl hangs
I'll reboot..
video4linux likes to crash and hang linux in non-recoverable ways ime
https://p.mort.coffee/KQb
pinchartl

[13:26]

pinchartl

I'd blame the msm camera drivers :-)
are you using a qcom bsp kernel ?

[13:30]

mort_

what sort of "permission system" is in use in the media controller API? I'm running this all as root

[13:31]

pinchartl

it's likely the driver returning that

[13:31]

mort_

I'm running this kernel: https://github.com/varigit/DART-SD410-kernel/tree/release/kernel-20.07
it's for the variscite DART-SD410 SoC with a qualcomm snapdragon 410
wouldn't surprise me if variscite's kernel is based on qualcomm's kernel

[13:31]

pinchartl

all my condolences, and good luck

[13:32]

mort_

are qualcomm kernels especially bad?

[13:32]

pinchartl

yes
all bsp kernels are bad
qcom is likely not the worst
but probably not very far

[13:32]

mort_

well, would've been nice if linux itself supported any hardware

[13:33]

pinchartl

it would be nice if qcom submitted drivers to mainline

[13:34]

mort_

it would

[13:34]

pinchartl

Linaro has done a fairly good job in that area
(and to be fair, qcom is helping there)
have you tried running mainline on that board ?

[13:34]

mort_

no
I could give it a shot, but it's not gonna work is it

[13:34]

pinchartl

there are camera drivers in the mainline kernel for that SoC
they're limited in the features they support though
you can capture raw data from the sensor, the ISP isn't supported
so it depends what you want to do

[13:34]

mort_

to debug this driver in this qcom kernel I probably enable debugging from the driver somehow right
for the driver for the csiphy1 specifcially

[13:36]

pinchartl

no idea, I haven't touched that kernel, I don't know what monsters lie beneath the surface :-)
essentially, with a qcom kernel, we can't help at all
you need to get support from qcom, or one of the service companies that support the qcom kernel
what kind of sensor are you using ?

[13:36]

mort_

ov5645

[13:38]

pinchartl

that's a yuv sensor, right ?

[13:38]

mort_

yeah
we usually configure it to give us nv12 frames

[13:38]

pinchartl

if I were you, I'd give mainline a try
but I'm not you :-)

[13:39]

mort_

I'll try it out
building torvalds/linux@v5.7 now

[13:40]

pinchartl

v5.7 is ancient

[13:42]

mort_

yeah ik
it's the newest variscite kernel so it's what I've been using

[13:42]

pinchartl

if you try mainline, you can as well try v5.13

[13:42]

mort_

would fuck up some kernel patches
I suppose I could get rid of those just to test
I'll try 5.10, LTS is nice
it's probably not gonna work though, devicetree stuff seems to change a lot

[13:42]

pinchartl

you can complain to variscite

[13:48]

***

camus1 has joined #linux-media
camus has quit IRC (Remote host closed the connection)

[13:57]

.... (idle for 17mn)

mort_

ugh
https://github.com/torvalds/linux/blob/v5.7/arch/arm64/boot/dts/qcom/msm8916.dtsi#L1623
this label doesn't exist in 5.10
I'll stick with 5.7, Linux changes way too much to be possible to upgrade just for a test
tbh I don't get the point of devicetree if all the dtsi files you have to rely on change this frequently and this drastically

[14:14]

..... (idle for 24mn)

pinchartl: well, with the upstream kernel, there's no /dev/media0 nor any /dev/video* devices

[14:41]

pinchartl

you won't like my answer, so I'll refrain from giving it

[14:44]

kbingham

hverkuil, "Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com>" for the "vb2 fix" patch - "
hverkuil, noted in https://bugs.libcamera.org/show_bug.cgi?id=61, your patch using the stream on error injection on vivid no longer shows the "Dequeued an unexpected buffer" error message.

[14:44]

mort_

eh, you can say it. It's probably gonna be something about "you should've used a soc with better mainline support" or "you should've used mainline from the beginning and worked through these kinds of issues in mainline instead of in the fork" or something, and I don't disagree

[14:45]

***

camus has joined #linux-media

[14:47]

pinchartl

mort_: I won't repeat the long discussion from #armlinux here, thanks

[14:48]

mort_

alright

[14:48]

***

camus1 has quit IRC (Ping timeout: 480 seconds)

[14:51]

.... (idle for 17mn)

hverkuil

kbingham: OK, I'll clean up the patch and post it so it can be merged for the next kernel.
Thanks for testing!

[15:08]

kbingham

hverkuil, Thanks for fixing, I saw a bug, logged it and before I knew it Laurent had talked to you and got a fix ;-)

[15:09]

mort_

it would've been useful to have a way to enable all dynamic kernel debugging except for the kind of things which spams continuously

[15:10]

................. (idle for 1h24mn)

***

GBenji has quit IRC (Quit: Leaving.)
BrianG61UK has joined #linux-media

[16:34]

......... (idle for 41mn)

gouchi has joined #linux-media

[17:18]

.... (idle for 15mn)

NiksDev2 has quit IRC (Remote host closed the connection)
NiksDev has joined #linux-media

[17:33]

NiksDev has quit IRC (Remote host closed the connection)
NiksDev has joined #linux-media

[17:41]

.... (idle for 19mn)

NiksDev has quit IRC (Remote host closed the connection)
NiksDev has joined #linux-media

[18:00]

....... (idle for 32mn)

NiksDev has quit IRC (Remote host closed the connection)
NiksDev has joined #linux-media

[18:33]

........... (idle for 50mn)

camus1 has joined #linux-media
camus has quit IRC (Ping timeout: 480 seconds)

[19:23]

....... (idle for 32mn)

NiksDev has quit IRC (Remote host closed the connection)
NiksDev has joined #linux-media

[19:59]

.... (idle for 17mn)

svarbanov has quit IRC (Ping timeout: 480 seconds)

[20:16]

...... (idle for 27mn)

camus has joined #linux-media

[20:43]

camus1 has quit IRC (Ping timeout: 480 seconds)

[20:48]

...... (idle for 27mn)

gouchi has quit IRC (Remote host closed the connection)

[21:15]

.... (idle for 18mn)

jm_h__ has joined #linux-media

[21:33]

jm_h has quit IRC (Ping timeout: 480 seconds)

[21:40]

lucaceresoli has quit IRC (Quit: Leaving)

[21:46]

........ (idle for 37mn)

jm_h__ has quit IRC (Remote host closed the connection)

[22:23]

camus has quit IRC (Remote host closed the connection)
camus has joined #linux-media

[22:28]

djrscally

jmondi: I checked how that sensor behaves running the cams in Windows; it actually has a lower HTS than output width there too
Weird!

[22:28]

***

NiksDev has quit IRC (Ping timeout: 480 seconds)

[22:41]

.......... (idle for 47mn)

djrscally has quit IRC (Ping timeout: 480 seconds)

[23:28]

↑back Search ←Prev date Next date→ Show only urls

(Click on time to select a line by its url)