> -----Original Message----- > From: Mauro Carvalho Chehab [mailto:mchehab+samsung@xxxxxxxxxx] > Sent: Thursday, June 21, 2018 1:50 PM > To: Limonciello, Mario > Cc: pavel@xxxxxx; nicolas@xxxxxxxxxxxx; linux-media@xxxxxxxxxxxxxxx; > sakari.ailus@xxxxxxxxxxxxxxx; niklas.soderlund@xxxxxxxxxxxx; > jerry.w.hu@xxxxxxxxx > Subject: Re: Software-only image processing for Intel "complex" cameras > > Em Thu, 21 Jun 2018 13:41:37 +0000 > <Mario.Limonciello@xxxxxxxx> escreveu: > > > > -----Original Message----- > > > From: Pavel Machek [mailto:pavel@xxxxxx] > > > Sent: Wednesday, June 20, 2018 4:12 PM > > > To: Nicolas Dufresne > > > Cc: linux-media@xxxxxxxxxxxxxxx; sakari.ailus@xxxxxxxxxxxxxxx; > > > niklas.soderlund@xxxxxxxxxxxx; jerry.w.hu@xxxxxxxxx; Limonciello, Mario > > > Subject: Re: Software-only image processing for Intel "complex" cameras > > > > > > Hi! > > > > > > > > On Nokia N900, I have similar problems as Intel IPU3 hardware. > > > > > > > > > > Meeting notes say that pure software implementation is not fast > > > > > enough, but that it may be useful for debugging. It would be also > > > > > useful for me on N900, and probably useful for processing "raw" > > > > > images > > > > > from digital cameras. > > > > > > > > > > There is sensor part, and memory-to-memory part, right? What is > > > > > the format of data from the sensor part? What operations would be > > > > > expensive on the CPU? If we did everthing on the CPU, what would be > > > > > maximum resolution where we could still manage it in real time? > > > > > > > > The IPU3 sensor produce a vendor specific form of bayer. If we manage > > > > to implement support for this format, it would likely be done in > > > > software. I don't think anyone can answer your other questions has no > > > > one have ever implemented this, hence measure performance. > > > > > > I believe Intel has some estimates. > > > > > > What is the maximum resolution of camera in the current Dell systems? > > > > > > > 5M camera sensor HW spec: > > 2592x1944 > > > > 8M camera sensor HW spec: > > 3264x2448 > > Looking at the ipu3 driver, I'm wandering how the library would identify > the system components. The way VIDIOC_QUERYCAP is currently implemented > doesn't help at all: > > static int cio2_v4l2_querycap(struct file *file, void *fh, > struct v4l2_capability *cap) > { > struct cio2_device *cio2 = video_drvdata(file); > > strlcpy(cap->driver, CIO2_NAME, sizeof(cap->driver)); > strlcpy(cap->card, CIO2_DEVICE_NAME, sizeof(cap->card)); > snprintf(cap->bus_info, sizeof(cap->bus_info), > "PCI:%s", pci_name(cio2->pci_dev)); > > return 0; > } > > In order to allow the library to know more about the hardware, it > would likely need to expose some model number to userspace. Ok, userspace > could always call dmidecode, but that requires root privileges. We > really don't want media apps to require root. > > So, perhaps caps->cap (or a MC caps equivalent call) should, instead be filled > with values obtained from the BIOS DMI tables with some logic based on > enum dmi_field: > > enum dmi_field { > DMI_NONE, > DMI_BIOS_VENDOR, > DMI_BIOS_VERSION, > DMI_BIOS_DATE, > DMI_SYS_VENDOR, > DMI_PRODUCT_NAME, > DMI_PRODUCT_VERSION, > DMI_PRODUCT_SERIAL, > DMI_PRODUCT_UUID, > DMI_PRODUCT_FAMILY, > DMI_BOARD_VENDOR, > DMI_BOARD_NAME, > DMI_BOARD_VERSION, > DMI_BOARD_SERIAL, > DMI_BOARD_ASSET_TAG, > DMI_CHASSIS_VENDOR, > DMI_CHASSIS_TYPE, > DMI_CHASSIS_VERSION, > DMI_CHASSIS_SERIAL, > DMI_CHASSIS_ASSET_TAG, > DMI_STRING_MAX, > }; > > e. g. something like: > > board_vendor = dmi_get_system_info(DMI_BOARD_VENDOR); > board_name = dmi_get_system_info(DMI_BOARD_NAME); > board_version = dmi_get_system_info(DMI_BOARD_NAME); > product_name = dmi_get_system_info(DMI_PRODUCT_NAME); > product_version = dmi_get_system_info(DMI_PRODUCT_VERSION); > > sprintf(dev->cap, "%s:%s:%s:%s", board_vendor, board_name, > board_version, product_name, product_version); > > (the real code should check if the values are filled, as not all BIOS vendors use the > same DMI fields) > > With that, the library can auto-adjust without needing to run anything as > root. > Well actually most of those fields you're interested in are already exposed to userspace through sysfs /sys/class/dmi/id/ Can't the library just pull them from there? The one field that isn't exposed is actually the one I think you should key off of though: Product SKU number. So I would propose as part of this change that should start to get exposed to userspace too. The reasoning is I'm a little concerned in taking an approach that goes off of marketing model number specifically because it's creating an assumption that all systems with that model number have the exact same components. It's possible for two systems to have the same model number but to second source for example. This might not affect complex cameras, but I just want to make sure it's taken into consideration. At least going off of Product SKU will better narrow it down.
