Intel Alder Lake P DRM Graphics Issues

[MicrosoftWindowsFan]

Hello all,

This is my first time posting here, so sorry if I'm not doing this right. I've installed FreeBSD 14.0-RELEASE on an Asus Viviobook S laptop with an Intel i7-12700H CPU (uses an Alder Lake-P iGPU). So far I've run into some major issues getting the iGPU to work.

Specifically, I just cannot get my GPU to work with DRM (i915kms). I've tried multiple versions, from the standard "drm-kmod" package as well as 510 and 515. In the case of 510, DRM does not even latch onto the GPU, and "dmesg | grep drm" returns nothing.. In the case of drm-kmod and version 515, the system locks up at "Loading kernel modules" during the multi-user boot process, with no trace of a crash or logs of any kind. Of course without a working graphics driver, X doesn't work.

In addition, repeat kernel panics have occurred, specifically since installing DRM. It's always a page fault. I've attached two images of two different kernel panics that have occurred.

So far, I have tried the following, which have produced the following results:
Changing kld_list='i915kms' to kld_list='/boot/modules/i915kms'
Same result, a lock up at "Loading kernel modules". From what I can tell, 'i915kms' just points to '/boot/modules/i915kms' anyways, since there's no i915kms modules in the /boot/kernel folder.

Removing all the Alder Lake specific firmware from the /boot/modules directory
In this case, the system will boot with 515 and drm-kmod, however DRM of course complains about the missing firmware, but still seems to initialize the GPU. However, X refuses to work in this case, with the error "failed to create screen resources". Looking at the xorg.0.log file, it seems the error leading to this is the DRM driver complaining that the "size of buffer object does not match constraints". I spent a lot, lot of time trying to get X to work with this, because DRM seemed to be mostly working, however no matter how I configured it I just could not get it to start.

Manually starting i915kms after boot using kldload
The second I do this, the console displays "Loading kernel module" and locks up as it does during boot.

I've probed around in dmesg logs for a while as well, and can't really find anything out of the ordinary during the firmware removal boots, apart from some DRM firmware missing errors. I've done a lot of research into other people who have this issue, and it seems like issues with newer Intel chipsets, especially the iGPU, are not uncommon. I've specifically noted multiple other users experiencing similar problems with DRM and Alder Lake iGPUs from the past 6 months or so. Is DRM just simply not working currently for Alder Lake iGPUs? Alder Lake is 2 years old now, so I'm guessing that's not the case at this point, and there's something I'm doing wrong or forgetting here.

 

[SirDice]

from the standard "drm-kmod" package as well as 510 and 515

There seems to be some misconception here, graphics/drm-kmod isn't a "standard" package, it's a so-called meta-port. It doesn't install anything by itself, it merely depends on other ports/packages for convenience. On 13.x graphics/drm-kmod installs graphics/drm-510-kmod. On 14.x it installs graphics/drm-515-kmod. And on -CURRENT it installs graphics/drm-61-kmod.

The different versions of DRM code require different versions of FreeBSD because they rely on certain kernel features.

Is DRM just simply not working currently for Alder Lake iGPUs?

Honestly not entirely sure if it's supported by 5.15. You might need DRM 6.1, which is only available on -CURRENT at the moment.

Edit: Looking at graphics/drm-61-kmod, it looks like you can now use it on a recent 14-STABLE.

.if ${OPSYS} == FreeBSD && !( ${OSVERSION} >= 1500008 || ( ${OSVERSION} >= 1400508 && ${OSVERSION} < 1500000 ))
IGNORE=		not supported on older than 14-STABLE 1400508, no kernel support
.endif

 

[sko]

the linux 5.15 drm driver lacks some parts to support alder lake (despite alder + raptor lake being listed as supported in their release notes). I have the same problem here on a thinkpad T16 /w i7-1255U.

Just use the scfb driver for now.

 

[MicrosoftWindowsFan]

There seems to be some misconception here, graphics/drm-kmod isn't a "standard" package, it's a so-called meta-port. It doesn't install anything by itself, it merely depends on other ports/packages for convenience

Makes sense. I’m somewhat of a newbie, and honestly have always been a bit confused by how packages and ports work. Just trying to understand this, so in the case of a meta-port, if I were to have a machine with one version of a port/package installed via a meta-port, then change my FreeBSD version such that the meta-port points to a different version of the actual port/package, would that be reflected when I run pkg upgrade?

Edit: Looking at graphics/drm-61-kmod, it looks like you can now use it on a recent 14-STABLE.

In that case, it looks like I’ll be attempting an upgrade to 14-STABLE, because I really don’t want to use another driver. I’ve never performed a from source update before, so I’ll read up on that and we’ll see how that goes.

the linux 5.15 drm driver lacks some parts to support alder lake (despite alder + raptor lake being listed as supported in their release notes)

Well that’s annoying. I read that it was supported, which was why I was assuming I was somehow configuring the driver wrong.

Just use the scfb driver for now.

I want to avoid that if at all possible, I’ve heard it would probably be very slow in this case. What’s your experience with it?

 

[SirDice]

then change my FreeBSD version such that the meta-port points to a different version of the actual port/package, would that be reflected when I run pkg upgrade?

Yes. If you were on 13.2 for example, it would have installed graphics/drm-510-kmod. If you do a major version upgrade to 14.0, then a pkg upgrade would magically upgrade it to graphics/drm-515-kmod because the dependency changes based on the FreeBSD version.

There's some clever selection happening in the port:

.  if ${OSVERSION} >= 1302000 && ${OSVERSION} < 1400097
RUN_DEPENDS+=	${KMODDIR}/drm.ko:graphics/drm-510-kmod
_DRM_ARCHS=	aarch64 amd64 i386 powerpc64 powerpc64le
.  elif ${OSVERSION} >= 1400097 && (${ARCH} == i386 || ${ARCH} == aarch64)
RUN_DEPENDS+=	${KMODDIR}/drm.ko:graphics/drm-510-kmod
_DRM_ARCHS=	aarch64 i386
.  elif ${OSVERSION} >= 1400097 && ${OSVERSION} < 1500008
RUN_DEPENDS+=	${KMODDIR}/drm.ko:graphics/drm-515-kmod
_DRM_ARCHS=	amd64 powerpc64 powerpc64le
.  elif ${OSVERSION} >= 1500008
RUN_DEPENDS+=	${KMODDIR}/drm.ko:graphics/drm-61-kmod
_DRM_ARCHS=	amd64 powerpc64 powerpc64le
.  else
_DRM_ARCHS=
.  endif

(doesn't look like it's been updated to include 6.1 on a recent 14-STABLE, but I assume that will be added some time soon)

In that case, it looks like I’ll be attempting an upgrade to 14-STABLE, because I really don’t want to use another driver. I’ve never performed a from source update before, so I’ll read up on that and we’ll see how that goes.

I've been running a -STABLE version for at least 25 years now. Started off with 3-STABLE way back. Updating from source and building world is surprisingly easy to do, it just takes time. I find it kind of mesmerizing watching compiler output scroll by.

 

[MicrosoftWindowsFan]

(doesn't look like it's been updated to include 6.1 on a recent 14-STABLE, but I assume that will be added some time soon)

Ah. Well in that case I still should be able to just manually install drm-61-kmod, right?

I've been running a -STABLE version for at least 25 years now. Started off with 3-STABLE way back. Updating from source and building world is surprisingly easy to do, it just takes time. I find it kind of mesmerizing watching compiler output scroll by.

Yeah, I'm currently in the middle of the process, and it is going very smoothly so far, albeit sure takes a while (that's to be expected of course). I've always had a bit of an irrational fear of compiling and installing my own programs from source, but the more I'm required to do that, and the more I've been toying around with compiling my own programs from source, it's not bad at all, just something that always seemed foreign since I never had to, and often couldn't do it when all I used was Windows.

 

[MicrosoftWindowsFan]

I've since updated my system to 14-STABLE, and installed graphics/drm-61-kmod from the ports collection. Now, with i915kms enabled in /etc/rc.conf, and all the Alder Lake firmware present in /boot/modules, the system no longer hangs, and boots fully. However, I still cannot get X to work, and it is seemingly running into the same problem as it did before with drm-515-kmod(w/out firmware).

Specifically, whenever X attempts to start, including on boot, it briefly "flashes" to a screen with a blank cursor in the top right corner, then exists back to console. I've attached my Xorg.1.log file, which seems to complain about screen buffer objects, and then gives up. At this point I'm pretty lost. DRM seems to work apart from complaining about missing power management firmware, so I just honestly don't know why X is doing this. I've attached the output of dmesg | grep drm as well, just in case.


EDIT: After toying around a bit more, I remembered I had installed the package xf-86-video-intel, which I completely forgot about, and figured it possibly could be conflicting with DRM. Sure enough, after removing it and rebooting, SDDM came right up. However, the second I entered my password, it froze completely, so back to troubleshooting.

 

[MicrosoftWindowsFan]

Alright, so I finally got X, SDDM, and KDE working by removing a weird video driver config from my /boot/loader.conf. Only other major issue is my trackpad doesn't work. No response at all. This is true in the console and in X. The weird thing is that the trackpad is recognized by the hms, hmt, iichid, and hconf drivers as an i2c trackpad according to dmesg, and it seemingly gets configured. Oddly, it is however absent from /dev. I've made sure that iichid, iic, and usbhid are all loaded, and I've also enabled both Synaptics and Elantech trackpad support in /boot/loader.conf. I've also ensured I have libinput and the corresponding X driver installed.
libinput list-devices shows a "System mouse" device that has an empty "N/A" configuration down the board. When I automatically generate an X config file, it lists "/dev/sysmouse" as the system mouse.

From what I can tell, the trackpad is recognized by the system, but simply doesn't work. Notably,
i2c -s lists nothing, unless I specifically specify the iic bus using the -f option to be "/dev/iic9", at which pont it displays a bunch of hex numbers. When I specify the iic bus to be "/dev/iic15", it simply prints "15". Interestingly enough, iichid lists the trackpad as an "I2C HID device" "on iicbus15", implying that the trackpad is on bus 15. However, it seems that the system iic bus defaults to iic0, and I can't figure out how to change that from my "research" (Google) on the matter.

At this point, I'm basically lost. Either I'm missing some kind of driver, my drivers are configured wrong, or my trackpad just simply doesn't work with FreeBSD.

 

[Vladimir Kondratyev]

Try to install graphics/gpu-firmware-intel-kmod. Your dmesg output shows that 915_adlp_dmc_ver2_16_bin.ko is s not installed

 

[MicrosoftWindowsFan]

Try to install graphics/gpu-firmware-intel-kmod. Your dmesg output shows that 915_adlp_dmc_ver2_16_bin.ko is s not installed

I've installed that package before, but I reinstalled it just in case (most likely got messed up when I was purposefully moving firmware around to get DRM to work). Either way, DRM is currently functional now! X is now working, and I can use SDDM to log into KDE. The only remaining big issue is my trackpad problem, which I have yet to solve after further troubleshooting.

 

[MicrosoftWindowsFan]

Well, I've exhausted basically all the troubleshooting steps I can. I simply cannot get the system to work with my touchpad. Every driver involved seems to recognize it and initialize it into the I2C bus, but I just can't seem to get it to work.

EDIT: I used hw-probe, and these are the results. It seems that the trackpad isn't detected by hw-probe whatsoever. I have, however, seemingly been able to receive raw data from my trackpad using the i2c command. Specifically, according to my dmesg, the trackpad is located at address 0x15 on iicbus15. Accordingly, I used the following command:
i2c -a 0x15 -f /dev/iic15 -v and am getting a hex value that changes based on where I place my finger on the trackpad. So, from this, it is clear that my trackpad is able to send readable data to the i2c subsystem in FreeBSD, and I this suggests iichid is able to interface with the trackpad.

EDIT 2: I have gotten evdev and libinput to recognize my trackpad by setting all the HID drivers relevant to my trackpad to load in /boot/loader.conf, which allows them to load earlier in the boot, which was enough for libinput to create an event in dev/input for my trackpad. Sure enough, using evtest, I am able to get readable data from my trackpad. However, moused and X still do not recognize the mouse, which suggests my next problem lies in my evdev configuration.

 

[MicrosoftWindowsFan]

I seemingly can't get libinput to work due to it apparently missing the python module "libevdev", which I have installed, so I have no idea why it claims it is missing. My trackpad is listed in the libinput record menu, but not in the active devices, and X does not recognize a driver that works with my trackpad. At this point I'm left to suggest my trackpad is just incompatible with libinput, and I'm unsure of any alternative methods to get it working on X. Pretty close to giving up at this point, I've got no other leads to solutions, and am unaware of any other drivers I've tried that have gotten this close to working. Probably just gonna ignore this specific installation for a while until I'm no longer burned out over driver issues.

 

[Vladimir Kondratyev]

It seems that you have been hit by a bug in HID parser. Try this patch: