-
Notifications
You must be signed in to change notification settings - Fork 243
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
Surface Pro 4 / 2017 and Books: Cameras are not working #145
Comments
@L4SCHI I haven't finished the patches for the camera on the Surface Pro 4 and newer yet. I'll work on it after finishing the i2c driver for acpi. |
Thank you for all your work. I installed latest version (4.17.3) but, webcam doesn't work. Is it fixed? |
@pysongh No, not yet. |
Sorry to be a bother, but the description says that it has partial support, it's just 'disabled for now'. How may one go about re-enabling it, so as to attempt to help fix it? |
Are there any news on this? This would be greatly appreciated! |
I found this today. I'm compiling the kernel from sources as I'm on Fedora 28 and I'll report back if this works to bring the cameras online: Seems to be a relatively simple patch, adding the vendor IDs to the driver. |
Seems to be more than matching IDs :) @jakeday has already these identifiers on his camera patch file. I found some links that may help Jake to get this up and running: |
@jakeday, hey there, love the work you're doing! @denzilferreira, any idea how to use the files? |
After getting the battery-reading work, let's do the next step for the cameras :). The last post from @denzilferreira looks interesting, but i'am not able to program in c. Someone else? |
@htrampe I might have a look at that, now that I think I've got the ethernet on the dock working. WIFI is also still a major issue I haven't looked at, but IIRC Jake said he's disabled power-save in the driver which could fix that, so I guess I'll look at the cameras next. |
ov5693 and atomisp (, which is needed for ov5693 for now) modules once existed in staging tree until 4.17, removed in 4.18 due to a lack of progress.
Just for your information. |
Yeah, unfortunately it won't be that easy. I've had a look at this over the past couple days and I still don't quite understand things as good as I'd like to get started. Here's a rough overview: OV5693 is a camera sensor with an I2C interface. This is in fact the actual camera sensor, but it doesn't directly provide the images. The I2C interface is for stuff like setting the exposure etc., the actual images are provided via a MIPI CSI-2 (Camera Serial Interface) connection handled by a PCI device (with ID Then there are the Also there's the matter of the ISP (Image Signal Processor). This is also a PCI device ( There's a bit about all of that here (Section 3.4), but not really much to go on. As to drivers: There's currently some work upstream for the ISP device, it's currently in staging for 4.21. I'm not yet sure if we actually need that, or if we can get the images directly from the CSI-2 interface. The CSI-2 interface has an upstream driver, but I'm not sure if that's working properly or supports everything. I've enabled it in the kernel options but nothing changes with respect to video devices under Then there's the OV5693 driver, or rather the one that was in staging. This depends on the atomisp subsystem and won't work with anything else without modification. The atomisp is a different signal processor for some older Intel Atom platform, but we might be able to use that as a template, AFAIK this also uses some CSI-2 PCI interface. The catch is: This has apparently been removed because the atomisp subsystem was a bit of a mess and Intel didn't care enough to fix it. So with quite a bit of luck we only need to wait some time and adapt the controller driver for OV5693 to work without the atomisp subsystem. |
Also the CIS-2 interface and ISP combined are sometimes also referred to as IPU (Image Processing Unit), which doesn't really further understanding when it comes to what handles what. Here's a somewhat similar device setup, which can help us figure this out. |
I'm also interested in camera support - and props to @qzed for the research you've done. You're saying it "won't be that simple", since this is OSS I suspect someone will tackle it at some point (someone with kernel experience so not me :)), what are the odds you'd put on availability say 3 to 6 months for now? Basically I'd like to know if there's hope or just to forget about it, seeing it's also not seen as vital to many people. It's just a bit frustrating to know it's there and good but unavailable... |
@andreivolt Sorry it took me so long to answer, unfortunately I'm a bit busy at the moment. I hope that the big parts will be supported by Intel (i.e. IPU and CIS2-interface, as mentioned there seems to be some development at the moment), and I think we should then be able to fill in the missing parts. I'd really like to have working cameras myself, but I can't give you any credible estimate. I just still know too little about that, but I'll have a look at it again once I've got a bit more time to spare. I think if the support on the Intel side is there, it could be possible that we have camera support in 6 months, but don't hold me to that. |
@qzed no problem and thank you for that estimate, it seems you've got a skeleton of a solution, it seems improbable that it won't happen at some point, which is great news after reading elsewhere it's not likely to ever happen Thanks again for all your work here! |
Would donations in some way make this bump through faster? |
For me: No. Sorry. I'm currently focusing on a proper dGPU power-on/power-off switch (as for me this is the faster-to-fix and more pressing issue right now) and some SB1/SP4 stuff on the side. At the moment I can't even tell you with full confidence what's missing and what's already implemented. I'll probably try to have another look at it after the dGPU stuff is done, but if someone else wants to take this on, be my guest. |
I haven't looked at it in-detail yet, but there is now some documentation for the ipu3 driver currently being worked on by Intel: https://www.kernel.org/doc/html/latest/media/v4l-drivers/ipu3.html. Looks very promising so far. Also here's some discussion about the ipu3 camera subsystem: https://www.mail-archive.com/linux-media@vger.kernel.org/msg133794.html. |
Hi all, I'm using the acpi and camera patches from 4.18.16-1 on a 4.18.14 kernel Thanks for this project |
The actual i2c devices can be found under The problem at the moment is that the drivers that were in staging are (as far as I remember) dependent on the atomisp platform, and that there is some work required in getting the ipu3 driver (the one actually responsible for receiving and processing the image) and the drivers for the sensor controllers to play together (see mailing list links above). The camera stuff depends on multiple devices and drivers to work together, so the issue is a bit more complex than just a single missing driver. Unfortunately, I haven't had much time lately, so I haven't managed to look into it as much as I wanted. |
Hi @qzed in my case the ov5693 driver does not start as #145 (comment) pasted. It only displays
There's no further probing of the i2c drivers like above, just driver starting and that's it |
@floion Quoting from the module description, "It currently only works with the atomisp driver.". Atomisp is a ISP (Image Signal Processor) for the Intel Atom platform. This driver as included here wont work without modifications on the Surface devices (never has), doesn't really matter where it fails, it will fail simply due to the different hardware. Maybe @kitakar5525 had some other atomisp related stuff enabled that allowed the driver to probe, maybe it's a model-specific thing that allowed it to load, or maybe there have been some other related changes upstream since then. Even if that driver would work, the binding to the ipu3 driver is missing. |
The OV5693 driver included in the camera.patch won't even compile because it includes v4l2-chip-ident.h which is an old header only present in kernel 3.x series.
in
and the kernel oops'es. To be noted, I also applied 690403a Without applying the above, the atomisp-ov5693 driver would complain that it can't get INT33BE:00_CamClk, INT33BE:00_ClkSrc, INT33BE:00_I2CAddr: https://github.com/torvalds/linux/blob/v4.17/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c#L721 So some progress here |
@floion I'm not sure what you're trying to achieve here. If you want to adapt the ov5693 driver for the Surface/general use, I'd suggest you have a look at the other ov5xxx drivers, for example the one for ov5695. The problem you're running into right now is that the atomisp-ov5693 is designed for an Intel Atom SOC based platform (and only for that, stuff like atom-based netbooks and tablets). AFAIK Jake has been trying to work around that (which is why the patches change the error). In my opinion, though, the right way forward is to implement the ov5693 driver independent of the platform (similar to all the other media-i2c/ov drivers). I really don't think trying to modify the platform driver to work on a completely different platform is a good idea (and also not likely to be easy or work at all) and I highly doubt that such modifications will ever be accepted upstream. As I've already mentioned, to ultimately get the cameras working, we need proper (read platform-independent) drivers (similar to the ones already upstream) for the sensor controllers (ov5693, ov8865, ov7251) and a bridge to the ipu3 driver. |
It seems that, at least, ov7251 is already upstream. I built the module with this config:
However, not probed at all. No logs in dmesg even if I load the module manually (not loaded by default) by |
I found a bug report of the ov7251 on Kernel.org Bugzilla. |
Dumping some more notes, I currently do not own a Surface device, but I'm vetting it for potential purchase. I found libcamera based on this bug report, it seems to have the required userspace code to have ipu3 working on 5.0. libcamera FOSDEM slides |
Does anyone know why the upstream driver ov7251 does not probe the device at all as mentioned before? $ sudo cam -l
[21:13:08.805213608] INFO Camera camera_manager.cpp:94 libcamera v0.0.0+960-744fabcb
Available cameras: What's the difference between I modified the matching to use acpi_device_id instead: diff
diff --git a/drivers/media/i2c/ov7251.c b/drivers/media/i2c/ov7251.c
index 0c10203f8..1ec27bf87 100644
--- a/drivers/media/i2c/ov7251.c
+++ b/drivers/media/i2c/ov7251.c
@@ -1481,15 +1481,18 @@ static int ov7251_remove(struct i2c_client *client)
return 0;
}
-static const struct of_device_id ov7251_of_match[] = {
- { .compatible = "ovti,ov7251" },
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id ov7251_acpi_ids[] = {
+ {"INT347E"},
{ /* sentinel */ }
};
-MODULE_DEVICE_TABLE(of, ov7251_of_match);
+
+MODULE_DEVICE_TABLE(acpi, ov7251_acpi_ids);
+#endif
static struct i2c_driver ov7251_i2c_driver = {
.driver = {
- .of_match_table = ov7251_of_match,
+ .acpi_match_table = ACPI_PTR(ov7251_acpi_ids),
.name = "ov7251",
},
.probe_new = ov7251_probe, but cannot initialize the device: kern :err : [76976.135409] ov7251 i2c-INT347E:00: endpoint node not found
kern :warn : [76976.137010] ov7251: probe of i2c-INT347E:00 failed with error -22 Maybe not intended to be used with ipu3? |
I am just checking into this discussion - just acquired a SP4 and loving all that works under Ubuntu. However has there been any progress on the front-facing camera? My son will need it for his Zoom sessions if we go full virtual and I may just have to buy a separate webcam. |
This repo is unmaintained, please follow linux-surface/linux-surface#91 for current discussion and progress. There was some promising developments recently but no driver is available yet. |
How can I get my volume control to work? I can't use my buttons for volume |
What device are you using, I'm on a surface pro 6 using the linux-surface/linux-surface kernel and it's working perfectly for me |
On the Surface Book I've noticed a change since the first versions of kernel-5.9.xx-surface during the loading process (a.i. wasn't there with the 5.3.18). The light near the camera flashes once (see pic). Is it due to the "intel_backlight.service" command during the loading process? False hope that a solution is approaching? |
Wrong repository, if you're running 5.1+ There's been a lot of work done on camera drivers: linux-surface/linux-surface#91 5.10 has initial support for certain camera models, but further work is needed to get a picture with proper white balance: linux-surface/linux-surface#96 (comment) |
@jakeday Hey, thanks for your work. Is the camera support for Surface Book 3 down the roadmap anytime soon? |
Surface cameras are supported/documented by the linux-surface project at https://github.com/linux-surface/linux-surface/wiki/Camera-Support SB3 is documented as using the IPU4. This can not currently be supported without extensive kernel driver development, requiring either direct support from Intel or ... a lot of funding / developer time. |
Thanks @kbingham , yeah makes sense. |
Hey!
Thank you very much for your work.
I've installed the kernel version 4.15.17-surface-linux-surface on Ubuntu 17.10. I am using the MS Surface Pro 4 with 8GB RAM and 256 GB Storage. All devices work very fine. Just the camera is not working.
Is it possible to solve this with patch?
Can anybody help me?
Thank you
The text was updated successfully, but these errors were encountered: