DELL 7285 webcam (IPU3-CIO2) not working

Thanks for suggestion. It is g in my timezone etting late, so I will try libcamera IRC tomorrow. For the time being I will keep the problem as unsolved, so I could post possible updates.
To solve necessity of working cameras and videoconferencing I will probably reinstall W10.

Update:
I at least wanted to find out what cameras are actually installed in the laptop. I could not find it anywhere, not even in the service manual. I had success extracting .EXE file provided by DELL as camera driver installer. There seems to be:

  • Some RealTek IR camera
  • ov8858 (OmniVision)
  • ov9234
  • ov9734

Apart from other files there are “pipeCfg.bin” file, I am not sure how to open these, but I suspect there could be some information on how the correct pipe for image processing (that should be hardware specific) should look.

Certainly. You could dump the ACPI tables to get more information.

Update:
During IRC discussion I was informed about most recent advances in solving similar problem on MS Surface devices. (The already mentioned thread: https://github.com/linux-surface/linux-surface/issues/91 ). The only problem is that there is currently no driver for my sensors, so probably the only way is to write the drivers myself. This will probably take a lot of time since I am not familiar with writing drivers (as well as I am not really a programmer) and these sensors are not well documented ones. Any info on ov9234 and ov9734 (such as datasheets) is welcome.

Which sensor is it, both? Did you dump the ACPI tables?

Thank you. I first misunderstood the information on ACPI and thought that to get useful information out of it I would need the hardware to work first. So that would mean I would have to reinstall W10 first. (Which is what I still did not do since I do not want to ruin my - except for cameras - perfectly functional Manjaro installation. I have that USB recovery “disk” that would have to wipe whole disk.)

Now I have read through some information on ACPI. I have binary dumped them and decompiled them via iasl. Now I am still struggling to understand what do data in .dsl files mean.

You could look for the camera devices. I guess they’re called CAM0, CAM1 or something similar.

Thanks for suggestion. But I could not find anything like CAM, IPU, I2C. Although I did not have time to read everything. There are 33 .dsl files in total and I did not find anything in dsdt.dsl

Can you post the contents of dsdt.dsl? Or, alternatively, search for “OVTI” and the sensor model number. For example “OVTI2680”; that’ll probably find them.

The file is quite big (~44,5k lines) nor hastebin nor pastebin did not like it. Here is the part following mention of OVTI: dsdt.dsl - Pastebin.com

You can use curl --upload-file FILENAME https://aptget.xyz

Is that for the 7285? Same cameras as the Surface Go 2. Here’s one of the definition of the cameras:

    Device (CAM1)
    {
        Name (_ADR, Zero)  // _ADR: Address
        Name (_HID, "INT3474")  // _HID: Hardware ID
        Name (_CID, "INT3474")  // _CID: Compatible ID
        Name (_DDN, "OV2740-CRDG2")  // _DDN: DOS Device Name
        Name (_UID, "0")  // _UID: Unique ID
        Name (_DEP, Package (0x01)  // _DEP: Dependencies
        {
            ^^I2C2.PMIC
        })
        Name (_PLD, Package (0x01)  // _PLD: Physical Location of Device
        {
            ToPLD (
                PLD_Revision           = 0x2,
                PLD_IgnoreColor        = 0x1,
                PLD_Red                = 0x0,
                PLD_Green              = 0x0,
                PLD_Blue               = 0x0,
                PLD_Width              = 0x0,
                PLD_Height             = 0x0,
                PLD_UserVisible        = 0x1,
                PLD_Dock               = 0x0,
                PLD_Lid                = 0x0,
                PLD_Panel              = "FRONT",
                PLD_VerticalPosition   = "CENTER",
                PLD_HorizontalPosition = "RIGHT",
                PLD_Shape              = "VERTICALRECTANGLE",
                PLD_GroupOrientation   = 0x0,
                PLD_GroupToken         = 0x0,
                PLD_GroupPosition      = 0x0,
                PLD_Bay                = 0x0,
                PLD_Ejectable          = 0x1,
                PLD_EjectRequired      = 0x1,
                PLD_CabinetNumber      = 0x0,
                PLD_CardCageNumber     = 0x0,
                PLD_Reference          = 0x0,
                PLD_Rotation           = 0x0,
                PLD_Order              = 0x0,
                PLD_VerticalOffset     = 0xFFFF,
                PLD_HorizontalOffset   = 0xFFFF)

        })
        Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
        {
            Name (SBUF, ResourceTemplate ()
            {
                I2cSerialBusV2 (0x0036, ControllerInitiated, 0x00061A80,
                    AddressingMode7Bit, "\\_SB.PCI0.I2C4",
                    0x00, ResourceConsumer, , Exclusive,
                    )
            })
            Return (SBUF) /* \_SB_.PCI0.I2C4.CAM1._CRS.SBUF */
        }

        Method (_STA, 0, NotSerialized)  // _STA: Status
        {
            If ((SCSS == One))
            {
                Return (0x0F)
            }
            Else
            {
                Return (Zero)
            }
        }

        Method (SSDB, 0, NotSerialized)
        {
            Name (PAR, Buffer (0x6C)
            {
                /* 0000 */  0x00, 0x50, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  // .P......
                /* 0008 */  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  // ........
                /* 0010 */  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  // ........
                /* 0018 */  0x00, 0x00, 0x00, 0x00, 0x01, 0x02, 0x00, 0x00,  // ........
                /* 0020 */  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  // ........
                /* 0028 */  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  // ........
                /* 0030 */  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  // ........
                /* 0038 */  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  // ........
                /* 0040 */  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  // ........
                /* 0048 */  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  // ........
                /* 0050 */  0x09, 0x00, 0x02, 0x01, 0x00, 0x01, 0x00, 0xF8,  // ........
                /* 0058 */  0x24, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  // $.......
                /* 0060 */  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  // ........
                /* 0068 */  0x00, 0x00, 0x00, 0x00                           // ....
            })
            Return (PAR) /* \_SB_.PCI0.I2C4.CAM1.SSDB.PAR_ */
        }

        Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
        {
            If ((Arg0 == ToUUID ("822ace8f-2814-4174-a56b-5f029fe079ee")))
            {
                Return ("4SF259T2")
            }

            If ((Arg0 == ToUUID ("26257549-9271-4ca4-bb43-c4899d5a4881")))
            {
                If ((Arg2 == One))
                {
                    Return (One)
                }

                If ((Arg2 == 0x02))
                {
                    Return (0x04003600)
                }
            }

            Return (Buffer (One)
            {
                 0x00                                             // .
            })
        }
    }
}

Most of that looks like it should work with the stuff on the surface-linux thread, and there’s even a driver for ov2740 that might work. The additional problem we’re hitting with these is the _STA method in that ACPI definition doesn’t evaluate true, so the cameras never show up as i2c devices for whatever reason.

tl;dr still more work to do to get those operational unfortunately.

You can always recompile it. :slight_smile: Anyways, I guess you checked it already, but doesn’t the value of SCSS depend on OSI?

Thanks. Now I found out that I misspelled CAM when searching for it. I do not understand how is it possible that there is ov2740 mentioned. The windows driver contains .bin files with names:

    OV8858_BCBM84V01-200_SKY_pipeCfg.bin
    OV8858_BCMS84V2_SKY_pipeCfg.bin
    OV8858_CBAD822_SKY_pipeCfg.bin
    OV8858_CJAE840_SKY_pipeCfg.bin
    OV8858_CJAE845_SKY_pipeCfg.bin
    OV8858_CJAG829_SKY_pipeCfg.bin
    OV8858_FO80AF468H_SKY_pipeCfg.bin
    OV8858_GEGR1601270_SKY_pipeCfg.bin
    OV8858_GEGR1601271_SKY_pipeCfg.bin
    OV8858_VNVPD_CN6D9_SKY_pipeCfg.bin
    OV8858_4BA862T2_SKY_pipeCfg.bin
    OV8858_5BA802T2_SKY_pipeCfg.bin
    OV8858_5BA812T2_SKY_pipeCfg.bin
    OV8858_5BA821T2_SKY_pipeCfg.bin
    OV8858_6BA803T2_SKY_pipeCfg.bin
    OV8858_6BA807T2_SKY_pipeCfg.bin
    OV8858_6BA808T2_SKY_pipeCfg.bin
    OV9234_IPU3_PV28T_SKY_pipeCfg.bin
    OV9234_5SF010T1_SKY_pipeCfg.bin
    OV9234_6BF120T2_SKY_pipeCfg.bin
    OV9734_IPU3_YJFXG_SKY_pipeCfg.bin
    OV9734_S1VM02_SKY_pipeCfg.bin

This is only clue I had until now.

By the way, do you know the format of those bin files?

file identifies all of them as Hitachi SH big-endian COFF object file, not stripped, 0 section, symbol offset=0x1000000 . I could not find more about how to extract/deconstruct them.

objdump and nm could not identify file.

Hmmm… and what does strings say about it?

Already tried it.
Here is the output (Where I have added heading with filenames):
http://aptget.xyz/5R5g6/strings.txt

Sorry it took me so long to give an update on what is going on. Unfortunately I am an undergraduate student, so I don’t have enough to properly work on this problem. :frowning_face:
I tried to analyse the content of windows driver. This is where I got:

I don’t know if you checked the linux-surface repository, but there have been some progress. I think you are more likely to get more there since it’s a similar problem.

I guess that requires knowing that driver integrates into the Windows driver model, and how cameras are handled on a driver level, to know what to look for.

If file has nothing to say about them, then I guess analyzing the code that reads them is more or less the only option. Except of course if you discover that it’s a thin layer around a “standard” file format.

1 Like