Undefined reference to intel_ipts_connect in ipts_gfx

[GrayHatter]

ld: drivers/misc/ipts/ipts-gfx.o: in function `ipts_open_gpu':
ipts-gfx.c:(.text+0x9e): undefined reference to `intel_ipts_connect'
ld: drivers/misc/ipts/ipts-gfx.o: in function `ipts_close_gpu':
ipts-gfx.c:(.text+0x11d): undefined reference to `intel_ipts_disconnect'
make[1]: *** [/home/grayhatter/code/aports/main/linux-vanilla/src/linux-5.3/Makefile:1069: vmlinux] Error 1
make: *** [/home/grayhatter/code/aports/main/linux-vanilla/src/linux-5.3/Makefile:179: sub-make] Error 2

any thoughts/suggestions?

[StollD]

What is your defconfig?

These symbols are an API for IPTS inside of the i915 graphics driver, and them missing sounds like you are building IPTS right into the kernel core (CONFIG_INTEL_IPTS=y) while building i915 as a module (CONFIG_DRM_I915=m). If you want to build one into the kernel core, the other one has to be built into it as well.

[GrayHatter]

That's what I suspected, but make menuconfig wouldn't allow me to specify both as y.

[StollD]

You could try to edit the generated .config file manually. But is there any reason why you want both built-in? If they are builtin, you also need have the companion driver for firmware loading built-in (CONFIG_INTEL_IPTS_SURFACE=y) and embed the firmware files themselves.

[GrayHatter]

Only because y seemed easier than m. I'm recompiling now after editing the .config. If y to both doesn't work than I'll try m.

If neither works I'll report back, otherwise hopefully in 2h I'll be able to close this.

Thanks for your help!

[kitakar5525]

For example, to build i915 as a built-in driver on Arch Linux:

DRM_I915 depends on HAS_IOMEM [=y] && DRM [=m] && X86 [=y] && PCI [=y]
DRM depends on HAS_IOMEM [=y] && (AGP [=m] || AGP [=m]=n) && !EMULATED_CMPXCHG && HAS_DMA [=y]

So, AGP and DRM also need to be built-in (y).

Then, DMC/GuC/HuC firmware need to be specified in CONFIG_EXTRA_FIRMWARE
(if not, loading the firmware will fail early at boot process, maybe because filesystem is not mounted yet).
(There seems to be no need to embed IPTS firmware anymore thanks to the companion driver)

[GrayHatter]

@StollD thanks mate, you were correct. I got it compiling.

Neither the battery info nor the touch screen actually works yet, but at least the IPTS shows up in libinput now (without any events from it)

Any help you can offer would be great, but I don't wanna add too much noise to this repo.

[GrayHatter]

@kitakar5525 I'm building for alpine linux instead of arch... so things are a little more complicated for me.

Anyone happen to have a config with the firmware embedded into the kernel so I can try that? I've never needed to embed firmware into the kernel before so I have no idea what I'm doing.

[kitakar5525]

I'm building for alpine linux instead of arch... so things are a little more complicated for me.

I see. Anyway, building IPTS as a module sounds a better idea in order to reload the module because IPTS is not stable yet.

---

It seems that we need to add the DRM_I915 as a dependency to INTEL_IPTS.
https://github.com/qzed/linux-surface-kernel/blob/37287a3ecd01861432991d4acad0167173cacbde/drivers/misc/ipts/Kconfig#L1-L4
to like this?

depends on X86 && PCI && HID && DRM_I915

[qzed]

@kitakar5525 you're correct, we should add it as dependency. Re-opening this issue until that is resolved.

[qzed]

@GrayHatter

Neither the battery info nor the touch screen actually works yet, but at least the IPTS shows up in libinput now (without any events from it)

For touch: Do you have the firmware installed (if you have IPTS built as module)?

For battery etc: That depends on SURFACE_ACPI_SAN and thus SURFACE_ACPI_SSH (which depends on a bunch of additional stuff) and SURFACE_ACPI. I've seen you've already found my configs for Arch and Debian, I think you should be able to use those as starting point (I agree that there's room for improvement in managing the configs, I'll probably revisit this in the future). Usually make menuconfig is a pretty good tool to find out if the dependencies are all satisfied (the option just won't show up if they aren't, in which case you'll have to look at the Kconfig files).

[GrayHatter]

Yeah, I pulled your arch config and it worked out of the box for Alpine. Touch, battery, everything but the webcams.

I'm sure I was doing something stupid but make menuconfig had a lot of "bugs" I changed the setting on [something] from module to installed to off, then when I tried to turn it back on, I couldn't install it as a module anymore. So clearly I had a broken config as my starting point.

[qzed]

Yeah, sounds like the config had some options enabled with dependencies that weren't enabled. Ideally, we'd have some list of options that are required for the Surface devices and a tool that enables all of them and their dependencies. The merge_config.sh script could be a base for that, but that doesn't enable dependencies, just prints warnings (which I guess would work too). Also it directly depends on the kernel source, so its a bit difficult to put that into an extra repo.

@StollD and @phunyguy have done some work like this (see e.g. https://github.com/StollD/fedora-linux-surface/blob/19de73504480781f1616d12a58599a7dd0583fa9/config.surface)