Skip to content
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

Question: how to confirm that the kernel module is patched correctly? #6837

Closed
jurc192 opened this issue Jul 15, 2020 · 3 comments
Closed

Question: how to confirm that the kernel module is patched correctly? #6837

jurc192 opened this issue Jul 15, 2020 · 3 comments
Assignees

Comments

@jurc192
Copy link

jurc192 commented Jul 15, 2020

Required Info
Camera Model D4000
Firmware Version 05.12.06.00
Operating System & Version Linux
Kernel Version (Linux Only) (5.4.0)
Platform PC
SDK Version 2.36.0
Language python
Segment others }

Issue Description

Short question: how can we check that patched kernel module is patched correctly?

I am trying to compare the performance between RSUSB and kernel modules, compiling the realsense SDK from source on Linux. Since officially the 5.4 kernel is not being supported yet, I want to try patching it manually. Is there a simple way to verify that everything is fine, that the kernel module is patched correctly and being used by realsense? Is this all about the uvcvideo driver/module or are there other files/modules that need patching?
Is this related to: "uvcvideo: Unknown video format 36315752-1a66-a242-9065-d01814a8ef8a" error messages?

@jurc192 jurc192 changed the title Question: how to confirm that kernel module is being patched correctly? Question: how to confirm that the kernel module is patched correctly? Jul 15, 2020
@ev-mp
Copy link
Collaborator

ev-mp commented Jul 19, 2020

@jurc192 , there are two things to review - formats and metadata.

  1. For streams formats it is sufficient to monitor dmesg when connecting the camera (as you did).
    For D400 devices the formats patches were upstreamed a while ago, so the unpatched format wornings will be most of low utility. E.g to de-cypher the mentioned 36315752-1a66-a242-9065-d01814a8ef8a:
    ->(extract FourCC) 36315752 ->(hex) 61WR -> (endianness) RW16
    The 'RW16' is a calibration format for one of the sensors. It used in production line but we do not expose it in SDK, so the warning can be safely disregarded.

In case you want to better understand which formats were singled out you can use v4l-utils command (#1137)
v4l2-ctl --list-formats-ext -d /dev/video<0,1,2.....>

Imo the quickest indirect way of verifying the kernel patches is checking the presence of metadata attributes.
For UVC streams check the presence of Exposure/Auto-Exposure values. It is best visualized with realsense-viewer.
For IMU streams you need to verify that both Gyro and Accel have Hardware Timestamp.

image

Specifically for LTS 5.4 - currently it has no DKMS but you can do it with installation script from installation guide

./scripts/patch-realsense-ubuntu-lts.sh

@jurc192
Copy link
Author

jurc192 commented Jul 20, 2020

Thanks!

@seebq
Copy link
Contributor

seebq commented Jan 25, 2021

Sorry to jump on an old thread, but does a command line tool exist on a headless (non X11, no window manager) to check the presence of metadata attributes? ie.e can you see these without using realsense-viewer?

Basically trying to confirm that this unit indeed has the v4l backend with kernel patches, and not the RSUSB, and it does not have realsense-viewer.

I can confirm only the dmesg warning about the 36315752-1a66-a242-9065-d01814a8ef8a video format is showing (no others), but want to make sure 100%.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants