Ok, so people have found that standard USB cameras don't work on these units. The only known working camera is actually a fully self-contained recording device, that really only uses the USB wire for power and a few pointless controls.
https://www.carjoying.com/car-acces...-for-joying-new-android-system-head-unit.html
Really, if you're going to make the camera self contained, then what the heck is the point of bothering with the hookup with the head unit to begin with? Makes no sense.
Now the reason they did this is quite obvious... in their OLDER head units, they used the complete piece of trash ROCKCHIP 3188 SoC. I'm referring, of course, to MTC units. Those units would be *completely crippled* if you tried to record video on them, since they had neither video encoder nor even video decoder hardware blocks, which means that the video processing would be done entirely on the CPU! So they sold a camera that would mask this problem by recording the video itself!
The Intel SoC's have a video CODEC, so obviously the right way to do this now is to actually record the video on the head unit, using standard file formats.
I initially theorized that they had crippled either the kernel or the camera HAL.
So last night I watched the kernel log while plugging a PROPER USB camera in, and found something very interesting;
1) The kernel detected the camera, and properly associated it with the UVC video driver!
2) It was assigned a devfs entry of /dev/video5 --- 5? FIVE?
That's interesting. Why 5? Because there are already entries of /dev/video0 through /dev/video4.
Wonder what those extra inputs correspond to? Typically, when you plug in a device like a camera, the devfs entry is created dynamically. Yes, in this case, it was! But it was created at 5 (the 6th video device). Very likely, the HAL is hardcoded to use specific inputs from 0-4. I'm not aware of any Android mechanism for manually selecting the device. So blank screen on "DVR"? Because its trying to pull video from a video device that has no video INPUT.
It is certainly worth some investigation. I wonder what those inputs correspond to. Don't suppose that they could actually have video feeds from things like BACKUP camera and VIDEO IN, that feed Android, could they? Note that some video devices can create multiple devfs entries that correspond to different modes of operation, which could explain why there are so many.
It is also possible that the FYT5009 SoM has video input option that may not even be hooked up. Depends on how the MCU board is wired up.
I also note that in the configuration options for backup camera, there is an option for it to use a USB camera.
EDIT:
Checked into the camera HAL, it has hardcoded values for /dev/video0 through /dev/video3. What this means, is that there is currently no way in hell that Android can access /dev/video5, which is where an external USB camera is attached.
THIS IS SOMETHING WE CAN WORK WITH!!!!
AOSP USB Camera HAL:
https://android.googlesource.com/platform/hardware/libhardware/+/master/modules/usbcamera
Found something more...
There is an executable at /sbin/camcap
What it is, is a butchered build of ffmpeg
Which, of course, is licensed as GPL/LGPL.
So... intentionally and knowingly violating GPL, else why would they be hiding the identity of the program!
https://www.carjoying.com/car-acces...-for-joying-new-android-system-head-unit.html
Really, if you're going to make the camera self contained, then what the heck is the point of bothering with the hookup with the head unit to begin with? Makes no sense.
Now the reason they did this is quite obvious... in their OLDER head units, they used the complete piece of trash ROCKCHIP 3188 SoC. I'm referring, of course, to MTC units. Those units would be *completely crippled* if you tried to record video on them, since they had neither video encoder nor even video decoder hardware blocks, which means that the video processing would be done entirely on the CPU! So they sold a camera that would mask this problem by recording the video itself!
The Intel SoC's have a video CODEC, so obviously the right way to do this now is to actually record the video on the head unit, using standard file formats.
I initially theorized that they had crippled either the kernel or the camera HAL.
So last night I watched the kernel log while plugging a PROPER USB camera in, and found something very interesting;
1) The kernel detected the camera, and properly associated it with the UVC video driver!
2) It was assigned a devfs entry of /dev/video5 --- 5? FIVE?
That's interesting. Why 5? Because there are already entries of /dev/video0 through /dev/video4.
Wonder what those extra inputs correspond to? Typically, when you plug in a device like a camera, the devfs entry is created dynamically. Yes, in this case, it was! But it was created at 5 (the 6th video device). Very likely, the HAL is hardcoded to use specific inputs from 0-4. I'm not aware of any Android mechanism for manually selecting the device. So blank screen on "DVR"? Because its trying to pull video from a video device that has no video INPUT.
It is certainly worth some investigation. I wonder what those inputs correspond to. Don't suppose that they could actually have video feeds from things like BACKUP camera and VIDEO IN, that feed Android, could they? Note that some video devices can create multiple devfs entries that correspond to different modes of operation, which could explain why there are so many.
It is also possible that the FYT5009 SoM has video input option that may not even be hooked up. Depends on how the MCU board is wired up.
I also note that in the configuration options for backup camera, there is an option for it to use a USB camera.
EDIT:
Checked into the camera HAL, it has hardcoded values for /dev/video0 through /dev/video3. What this means, is that there is currently no way in hell that Android can access /dev/video5, which is where an external USB camera is attached.
THIS IS SOMETHING WE CAN WORK WITH!!!!
AOSP USB Camera HAL:
https://android.googlesource.com/platform/hardware/libhardware/+/master/modules/usbcamera
Found something more...
There is an executable at /sbin/camcap
What it is, is a butchered build of ffmpeg
Which, of course, is licensed as GPL/LGPL.
So... intentionally and knowingly violating GPL, else why would they be hiding the identity of the program!
Last edited:
