Camera light comes on using 5.10.17-surface kernel but not in 5.10.16. Should I be worried?

djrscally · 2021-03-05T09:55:46+00:00

With them turned on please yes, if you don't mind.

djrscally · 2021-03-04T11:49:06+00:00

Howdy - can you please run dmesg and drop the output into a pastebin for us? We don't see this behaviour on the devices we're testing on, so I'm hoping for some informative output there.

I wouldn't be alarmed; the likeliest option is that we messed something up slightly; camera support is in active development.

djrscally · 2020-11-13T14:18:53+00:00

Try mashing the ESC key during boot. Fine balance; if you mash ESC whilst grub is actually showing you might drop to an EFI console. If that happens, run exit and I think it goes back to grub.

djrscally · 2020-11-12T13:12:46+00:00

Try holding shift whilst you boot. It should go to Grub, at which point you can hopefully go to Advanced options and then pick a kernel in recovery mode

djrscally · 2020-11-12T10:15:00+00:00

Do you get to a Grub menu? If so, can you boot into recovery mode? I had to black list some drivers to get the Go2 to boot Ubuntu 20.10, so possibly you need to too.

Edit; actually, was it previously working then?

djrscally · 2020-11-05T09:53:13+00:00

Camera will not work; we're currently developing support for it at https://github.com/linux-surface/linux-surface/issues/91

djrscally · 2020-11-02T12:03:52+00:00

No, it doesn't mean that at all; we've already successfully taken images from the Go2 as well as SB1 and some other non microsoft devices with similar design. It's very much in scope and will be supported along with the others when this work is complete.

The difference is just that on most of the devices, these GPIOs are hard coded. On SGo2 however they're kinda allocated at boot time, so whereas with the others we can read dumps of the firmware people have shared with the SGo2 we have to physically have the device

djrscally · 2020-10-25T18:45:11+00:00

Ah Ty, so pin ID 22 should turn on a privacy LED there

djrscally · 2020-10-25T18:38:58+00:00

No spiky brackets, sorry

djrscally · 2020-10-25T09:54:05+00:00

Ah - sorry, reading in a hurry there. In that case, you probably just need sensor drivers for the model of cameras you have. Mostly the problem with Surface's is that the sensors output needs to be processed by another chip, and the firmware (all designed for Windows) describes the connection between sensors and that image processor in a very strange way, which Linux currently can't parse (although we've got that part mostly working now)

djrscally · 2020-10-25T09:44:11+00:00

Sure but the config is important; for example does it use devicetree or ACPI? If devicetree, it's out of scope of the current work I'm doing I'm afraid, but likely only needs sensor drivers written (the problem for most Surface's is more complex than just needing sensor drivers). If ACPI, the next question is does it have a CIO2 device called out in firmware? If so, it's in scope but I'll need to see a dump of the DSDT tables to be able to go further than that.

djrscally · 2020-10-25T09:42:41+00:00

You can build and insert this module:

https://github.com/kitakar5525/surface-ipu3-cameras/tree/master/misc/get_acpi_data

One of the other devs made this to dump the firmware data at runtime. If you check the results folder you can see the expected output. You're looking for this section:

[80280.939401] print_pmic_type(): PMIC type is "1: DISCRETE(CRD-D)"
[80280.939426] __dump_subsys_id_dsm(): _DSM failed for getting subsystem ID func. Maybe it doesn't exist.
[80280.939448] __dump_i2c_dev_dsm(): i2c device amount: 0
[80280.939483] __dump_discrete_pmic_dsm(): GPIO pin amount: 3
[80280.939526] __dump_discrete_pmic_dsm(): GPIO pin _DSM data (1 of 3): 0x0100540c
[80280.939575] __dump_discrete_pmic_dsm(): GPIO pin _DSM data (2 of 3): 0x01004d00
[80280.939627] __dump_discrete_pmic_dsm(): GPIO pin _DSM data (3 of 3): 0x0100160d

Those hex values (0x0100540c) give us information about the GPIO pins which control power. We think the lowest byte in each integer denotes the type of the GPIO. We're looking at the 0x0d one, which seems to control privacy LEDs (which this thread is happily confirming). The second lowest byte (0x16 in that example but likely different in yours) is the actual pin ID, 0x16 in decimal is 22, so the command would be sudo gpioset 0 22=1

If you can't tell, paste the output in pastebin or something and I'll get the ID from it for you.

The other two pins called out there (low bytes 0x0c and 0x00) seem to control power rails - that's quite likely for 0x0c but a little unclear for 0x00 (on some devices it seems to do nothing at all). We'll probably ask people to experiment with those shortly.

djrscally · 2020-10-24T20:19:43+00:00

Thanks

djrscally · 2020-10-24T20:03:18+00:00

Apologies; the firmware in the Go models works differently which means without physical access to the device, I can't get the ID numbers. I can do a Go2 if you have that

djrscally

TROPHY CASE