Xorg complains that it cannot find mesa when i915kms is installed using the binary package, but runs just fine when built locally out of ports. Known bad on at least two systems.
This is somehow an unfortunately known issue. The root cause is that currently the 12.x packages are all built on 12.1 because it is the oldest supported version in 12 branch, theoretically, the packages should be working on 12.2 and later, but if a port uses internal KPI/KBIs, then its binary package has certain chance cannot be usable cross minor versions.
The workaround is like what you said, building from ports to let it use the 12.2 interfaces. The solution is still under working.
I can confirm. Using Intel integrated graphics and is not working after the upgrade from 12.1 to 12.2 Release version.
[ 31.518] (EE) open /dev/dri/card0: No such file or directory
I had tested i915kms on one of the 12.2 pre-releases (I forget if beta or RC). I didn't have any issues with it. Mine was compiled (by me) on 12.1 with the latest 12.1 patches.
Will need to try again.
Does X fail to start, or is this a logged error message?
(In reply to Teran McKinney from comment #3)
Yes. X fails to start. I have attached the last Xorg.0.log.
Created attachment 219191 [details]
Xorg.0.log in 12.2 Release with Intel HD 2000 graphics
There is no line where intel driver module is added by me. But, this is what it shows.
As Li-Wen already stated, please build the driver locally from ports.
(In reply to firstname.lastname@example.org from comment #2)
Intel(R) HD Graphics 620 (Kaby Lake GT2)
I got same error.
When building locally make sure you have the 12.2 sources in /usr/src.
It might be an edge case but it caught me :D (I still had the 12.1 sources)
*** Bug 250678 has been marked as a duplicate of this bug. ***
I understand that this problem will potentially occur each time when there is an update from x.y to x.y+1 while packages are still built for x.y (because x.y is not yet EOL).
In my opinion, this issue will bite many users that are not so experienced with FreeBSD and will stand in the way of increasing desktop usage, so maybe we should find a generic solution beyond fixing it for 12.2?
(In reply to stephan from comment #10)
Yes, that would be quite nice, but so far no one has stepped up to work on this.
I recompiled drm-kmod (and the fb12.0 one). kldload i915kms works fine and startx is fine, however anything OpenGL does not work.
dmesg shows some "Hangcheck timer elapsed... GPU hung" errors.
I can run OpenGL stuff inside Xephyr, though, which is what I'd expect.