-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bunch of fixes to make the tool work on rockchip platforms #16
base: master
Are you sure you want to change the base?
Conversation
Not all KMS drivers have a zpos property attached to their plane. Let's make this prop optional so that v4l2-request-test can work on those platforms. Signed-off-by: Boris Brezillon <[email protected]>
Latest version of the stateless H264 patch series renamed V4L2_PIX_FMT_H264_SLICE into V4L2_PIX_FMT_H264_SLICE_RAW. Let's reflect that in v4l2-request-test. Signed-off-by: Boris Brezillon <[email protected]>
Having a #ifdef DRM_FORMAT_MOD_ALLWINNER_TILED does not guarantee that V4L2_PIX_FMT_SUNXI_TILED_NV12 exists in the videodev2.h header. Let's make this dependency explicit to avoid compilation errors. Signed-off-by: Boris Brezillon <[email protected]>
…tive connector->encoder_id is only set to a valid encoder ID if the connector is active, otherwise it's set to 0. In that case, we can pick any encoder that can connect to this connector, so let's pick the first one. Signed-off-by: Boris Brezillon <[email protected]>
Drivers that are MPLANE capable can also support non-M formats, and requests for non-M formats should take the _mplane path (which is unintuitive). Let the v4l2 glue decide when it's appropriate to use _MPLANE types instead of specifying it in the supported formats table. Signed-off-by: Boris Brezillon <[email protected]>
I'm trying to use this patch to validate an rk3399 board. We're using 5.10.17 and the rkvdec/hantro drivers with panfrost. I get the following error: $ ./v4l2-request-test -D panfrost /root Preset: Media device driver: rkvdec I looked at the panfrost driver but don't see the atomic ioctl implemented. Am I looking in the right place? Should this work or am I even testing this correctly? Or is there another, lower-level way to validate rkvdec/hantro HW decoding without having to use the whole libva/ffmpeg stack? As an additional bit of information, I tried this using "rockchip" as the driver name. $ ./v4l2-request-test -D rockchip /root Preset: Media device driver: rkvdec And some additional data points: Video Devices: /dev/video1 /dev/video2 /dev/video0 LIBVA_DRIVER_NAME=v4l2_request vainfo --display drm --device /dev/video1 LIBVA_DRIVER_NAME=v4l2_request vainfo --display drm --device /dev/video2 LIBVA_DRIVER_NAME=v4l2_request vainfo --display drm --device /dev/video0 |
No description provided.