mchehab: can you merge https://patchwork.linuxtv.org/patch/43495/ asap? It is needed to fix the media_build breakage.
I asked before, but it is still not merged. Just a reminder.
hverkuil: pushed
thanks!
hverkuil: ping
headless: pong
hverkuil: hello. are you going to have more feedback on IMR v7?
(you didn't review the driver itself this time)
or that was because the whole thing was misdesigned? :-)
I reviewed it on August 17.
I didn't have anything else for the driver.
you said you were concentrating on the ioctl (and indeed only commened on the driver doc and UAPI header)
It's that custom ioctl that still needs work, it's just too complicated. My 'brainwave' would (I think) make things a lot easier.
*commented
oh, OK
I *think* I looked at the overall driver as well and didn't find anything else. But to be honest, I am not 100% certain, too long ago :-)
this whole IMR thing is a big PITA for me, it was written/tested by another person
My sympathies. Been there, done that, hated it.
to add to the pain, I only have remote access to the R-Car gen3 boards which the driver initially supports
oh well
At the core the issue here is a data structure issue: how to represent the mesh in a way that makes sense.
your suggestions would make user I/f easier, yes. but I think "deinterlacing" the vertex object in the driver would be more painful
than it's today
oh well. we beed to think more about it...
*need
the current vertex data format is determined by yhe hardware which (AFAIU) is the case of the DRI drivers
hi, I have a problem with me-tv:  Program Map PID not found. what is that?
this driver is akin to those, only the hardware is backwards IIUC: the textures constantly change whil the mesh remain constant
*while
headless: it is the job of the driver to make things easy for the user, not the other way around. I suspect that it will actually help the driver, or at least make it easier to understand the code.