Bug 109821
| Summary: | Surface Pro 4 camera is not supported by kernel. | ||
|---|---|---|---|
| Product: | v4l-dvb | Reporter: | Weng Xuetian (wengxt) |
| Component: | v4l-other | Assignee: | v4l-other (v4l-dvb_v4l-other) |
| Status: | RESOLVED WILL_NOT_FIX | ||
| Severity: | normal | CC: | andy.shevchenko, bugzilla, greg, kxra, mchehab, nikodll, nrndda, rn.mast, russianneuromancer, sergei.a.trusov, sinxwal, stephenjust, xunil, yuzvir |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 4.3.3 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
|
Description
Weng Xuetian
2015-12-22 19:05:50 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? *** Bug 110151 has been marked as a duplicate of this bug. *** 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 :-)). 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.) I have no idea. I would suggest to try find an Android build for most closest device. (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? 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. I have no idea. I'm not related to the team which has been working on this. 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. 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." 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. > 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.
(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. (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. Based on Mauro's and mine comments close this as impossible to fix. (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. |