Bug 109821 - Surface Pro 4 camera is not supported by kernel.
Summary: Surface Pro 4 camera is not supported by kernel.
Status: RESOLVED WILL_NOT_FIX
Alias: None
Product: v4l-dvb
Classification: Unclassified
Component: v4l-other (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: v4l-other
URL:
Keywords:
: 110151 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-12-22 19:05 UTC by Weng Xuetian
Modified: 2019-01-04 17:09 UTC (History)
14 users (show)

See Also:
Kernel Version: 4.3.3
Tree: Mainline
Regression: No


Attachments

Description Weng Xuetian 2015-12-22 19:05:50 UTC
Despite of the existing patch (e.g. https://github.com/tiggerite/mint-17.3-for-surface-pro-3/blob/master/patches-4.3/surface-cam.patch), it seems some surface pro 4 model (E.g. my i7 16G) uses a different webcam solution.

From windows, there are three camera listed with "Camera" in their driver name.
They are Microsoft Camera Front, Microsoft Camera Rear and Microsoft IR Camera Front.

The properties dialogs show that they are OV5693, OV7251 and OV8865, seems they are i2c device instead of usb device.
Comment 1 kxra 2015-12-26 21:55:14 UTC
I believe that the Microsoft Surface Book is also affected by this same issue. Should the title of this bug change or should a new one be filed?
Comment 2 Andy Shevchenko 2016-02-01 10:46:13 UTC
*** Bug 110151 has been marked as a duplicate of this bug. ***
Comment 4 Andy Shevchenko 2017-04-01 16:11:00 UTC
Just in case, AtomISP driver is now in drivers/staging/atomisp folder in mainline. The quality of code is far from ideal, but someone can try it (and fix :-)).
Comment 5 RussianNeuroMancer 2017-04-02 03:33:19 UTC
Andy, where one can find/extract firmware files for AtomISP if there is no Android build for device? (Like in my case with DEXP Ursus 10XW.)
Comment 6 Andy Shevchenko 2017-04-02 09:48:07 UTC
I have no idea. I would suggest to try find an Android build for most closest device.
Comment 7 Bastien Nocera 2017-04-03 09:19:57 UTC
(In reply to Andy Shevchenko from comment #4)
> Just in case, AtomISP driver is now in drivers/staging/atomisp folder in
> mainline. The quality of code is far from ideal, but someone can try it (and
> fix :-)).

In mainline? Can't see it here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/media

Did you mean in master for the media tree?
Comment 9 RussianNeuroMancer 2017-04-03 13:24:05 UTC
Andy, is Intel going to provide necessary firmware files for linux-firmware?

Do you have information about Intel AVStream 2500 driver by any chance? I have affected hardware (Dell 9250) and I not sure if I need to register separate bugreport about that, or this one is enough.
Comment 10 Andy Shevchenko 2017-04-03 13:49:05 UTC
I have no idea. I'm not related to the team which has been working on this.
Comment 11 Robert Mast 2018-07-27 17:56:10 UTC
Those Intel-firmware files for Linux, would they be the same as for the ASUS T100?

https://github.com/jfwells/linux-asus-t100ta/tree/master/webcam/firmware

JFWells once made some similar camera's work on the ISP on the ASUS T100.
Comment 12 Robert Mast 2018-07-27 18:41:05 UTC
I also find some of these similar camera's mentioned in the source for the ASUS Zenfone:
https://github.com/ZenfoneArea/android_kernel_asus_zenfone5/blob/master/linux/modules/camera/drivers/media/i2c/Kconfig
"It currently only works with the atomisp driver."
Comment 13 Mauro Carvalho Chehab 2018-07-28 04:33:08 UTC
The atomisp driver was removed from the Kernel. It was on a really very bad shape, and we don't even have reports that it actually works with the latest upstream version of it.

Unfortunately, no developer had time to work with (and/or hardware availability).

So, we ended by removing it until some developer with atomisp-based hardware and enough time to fix the driver would popup.
Comment 14 RussianNeuroMancer 2018-07-28 07:14:03 UTC
> no developer had time to work with (and/or hardware availability)

Was there anyone who wanted to work on this but could not due to lack of hardware? I could help with that by providing hardware for development.
Comment 15 Andy Shevchenko 2018-07-28 12:56:31 UTC
(In reply to RussianNeuroMancer from comment #14)
> > no developer had time to work with (and/or hardware availability)
> 
> Was there anyone who wanted to work on this but could not due to lack of
> hardware? I could help with that by providing hardware for development.

The main problem is to extract exact version of firmware and C code for certain hardware.

There are two approaches (at least?):
- take *working* source base with known firmware file and step-by-step move it to the state where it can be taken to the drivers/staging (GitHub project?)
- analyze *working* solution with known firmware and understand what must be fixed in the driver that used to be in the kernel and move step-by-step it.

For BayTrail platforms Android for Asus T100TA would be, perhaps, a good start. For CherryTrail / Braswell I have no idea.
Comment 16 Mauro Carvalho Chehab 2018-07-28 14:07:48 UTC
(In reply to Andy Shevchenko from comment #15)
> (In reply to RussianNeuroMancer from comment #14)
> > > no developer had time to work with (and/or hardware availability)
> > 
> > Was there anyone who wanted to work on this but could not due to lack of
> > hardware? I could help with that by providing hardware for development.
> 
> The main problem is to extract exact version of firmware and C code for
> certain hardware.
> 
That's just a small part of the issue. The main problem is that the atomisp driver has too many troubles:
 - lots of layers internally abstracting stuff;
 - The sensor drivers don't use the v4l-subdev kernel API;
 - It doesn't properly use the V4L2 framework;
 - Depending on the version of atomisp, one has to change the source code to enable the right support;
 - The same code is copied over and over on several parts;
 - it is uneedless *big*.

In other words, a developer that would work with it would need to reserve a considerable amount of time in order for it to lose weight and be able to be merged upstream outside staging. This is a major rework and will require someone to take it as a full time job (or a full time hobby).

Unfortunately, the developer that originally posted it was reassigned and won't be able to do that.

So, at least while no such developer arrives, it makes no sense to restore it at staging.
Comment 17 Andy Shevchenko 2019-01-04 16:41:12 UTC
Based on Mauro's and mine comments close this as impossible to fix.
Comment 18 Mauro Carvalho Chehab 2019-01-04 17:09:03 UTC
(In reply to Andy Shevchenko from comment #17)
> Based on Mauro's and mine comments close this as impossible to fix.

Yeah, it makes sense to close this BZ. 

Yet, I wouldn't say that this is impossible. It is doable. Yet, it would require someone with a lot of time to dedicate on such project. Currently, we don't know anyone willing to do that, as mainstream media developers are busy doing something else.

If someone starts having time and interest on doing that, we can consider reverting the patch that removed the driver from staging, and keep applying the needed fixup patches for it to work with real hardware, while keeping the driver at staging. 

I suspect, however, that it may require a large time frame in order to cleanup the atomISP driver mess in order to move it out of staging.

Note You need to log in before you can comment on or make changes to this bug.