Will we have drm-kmod driver (i915kms.ko) for 14.3-RELEASE/i386 ?

Is that the problem or something else?
Probably something else. These seem to be two components to i915kms.
A console framebuffer driver and the xorg component
This allows you to have separate console resolutions and xorg resolutions.

scfb and xf86-video-intel both can only use the same resolution in xorg and console framebuffer.
So if you use gop set (from the loader prompt) the same resolution is used in xorg as with the console.

All of that depends on the machine running in UEFI mode.
 
Pause at Beastie Screen and press #3 for loader prompt.

Mess around with gop. Just type gop will give you the options.
gop list/set/something

gop list shows available resolutions.
It seems to be tied to available "Monitor" resolutions. For example gop list might show different settings on different monitors.
Board might support 1920x1080 but monitor does not. So you will not see that resolution.

You should be able to find out if you are running LegacyBIOS or UEFI mode BIOS settings with gop.
This shell command will also show you:
sysctl machdep.bootmethod
 
I want to note that for x11 finding out what driver is I use there is graphics/drm_info in addition to benchmarks/glmark2 for output.

Some provided clues with base port:
xrandr --listproviders

name:modesetting

FreeBSD did not gain UEFI for 32 Bit platforms until recently. So it was a lifeline for FreeBSD-15 to support i386.
Isn't the T7400 Mini-Mac IA32 UEFI?
 
At loader prompt:
OK gop list
unknown command

# sysctl machdep.bootmethod
machdep.bootmethod: BIOS
relevant dmsg lines:
# dmesg | grep -i 'cpu|drm'
CPU: Intel(R) Pentium(R) M processor 1.50GHz (1496.31-MHz 686-class CPU)
cpu0: <ACPI CPU> on acpi0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
cpufreq0: <CPU frequency control> on cpu0
drmn0: <drmn> on vgapci0
vgapci0: child drmn0 requested pci_enable_io
vgapci0: child drmn0 requested pci_enable_io
[drm] Unable to create a private tmpfs mount, hugepage support will be disabled(-19).
[drm] Got stolen memory base 0x0, size 0x0
lkpi_iic0: <LinuxKPI I2C> on drmn0
lkpi_iic1: <LinuxKPI I2C> on drmn0
lkpi_iic2: <LinuxKPI I2C> on drmn0
lkpi_iic3: <LinuxKPI I2C> on drmn0
lkpi_iic4: <LinuxKPI I2C> on drmn0
lkpi_iic5: <LinuxKPI I2C> on drmn0
drmn0: [drm] Initialized overlay support.
[drm] Initialized i915 1.6.0 20200917 for drmn0 on minor 0
name=drmn0 flags=0x0 stride=4096 bpp=32
 
gop list shows available resolutions.
gop is UEFI specific, non-existent in legacy BIOS.
Use mode instead for legacy BIOS.
But not sure VESA graphics modes inherits it properly or not.

Note that on legacy BIOS emulation of UEFI using CSM, "basically" gop would work (some UEFI firmwares could forcibly disable it, though).
 
Right that is showing BIOS bootmeth.
So that might be whats going on. The UEFI framebuffer part is failing because it is LegacyBIOS and it is expecting UEFI.
But i915kms is working in Xorg.
What is surprising is that I thought a port like i915kms would be linked to a version ABI. Not interchangeable just by compiling.
I need drm-510-kmod to keep baytrail alive with Xorg so I might see if I can get it going.
 
You realize why your score stinks right ?

That is software rendering. Not hardware accelerated i915kms aka MODESETTING.
You are right. I realized that I forgot to add myself to 'video' group. After doing so here's what I get:

rz@sunny:~ % glxinfo -B
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Mesa Project (0x8086)
Device: i915 (chipset: 945GM) (0x27a2)
Version: 24.1.7
Accelerated: yes
Video memory: 192MB
Unified memory: yes
Preferred profile: compat (0x2)
Max core profile version: 0.0
Max compat profile version: 2.1
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 2.0
OpenGL vendor string: Mesa Project
OpenGL renderer string: i915 (chipset: 945GM)
OpenGL version string: 2.1 Mesa 24.1.7
OpenGL shading language version string: 1.20

OpenGL ES profile version string: OpenGL ES 2.0 Mesa 24.1.7
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16

rz@sunny:~ % glmark2 --fullscreen
=======================================================
glmark2 2023.01
=======================================================
OpenGL Information
GL_VENDOR: Mesa Project
GL_RENDERER: i915 (chipset: 945GM)
GL_VERSION: 2.1 Mesa 24.1.7
Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=24 stencil=0 samples=0
Surface Size: 1280x800 fullscreen
=======================================================
[build] use-vbo=false:'-avx512er' is not a recognized feature for this target (ignoring feature)
FPS: 57 FrameTime: 17.733 ms
=======================================================
glmark2 Score: 56
=======================================================

The score is higher than with pure software rendering, but not that much. Yet I noticed that some GL games (DreamChess) are much more responsive.

I did some further investigation and here's what I've found (could be some obvious things, but not for me):

1. If you have xf86-video-intel driver installed (intel_drv.ko), like I do, it pulls up i915kms.ko automagically soon as Xorg starts, so you do not need to add it to kld_list.

2. Without i915kms.ko only VESA (Int 10h) driver works on this setup, scfb is not working! VESA driver provides 1024x768 max resolution, while with i915kms.ko I have 1280x800 now.

3. With VESA driver I have "glmark2 Score: 17". So, Installing i915kms.ko improvided things a lot, even with software renderer!

4. Xorg can bind to i915kms.ko directly without intel_drv.ko (just uninstall xf86-video-intel, or rename intel_drv.ko) and that is recommended configuration on some Linux forums. But when I tested it, I faced a number of artifacts: missing hardware mouse cursor, some fonts are not rendered. So, I switched back to intel_drv.ko.

5. With i915kms.ko installed video subsystem suspends and resumes correctly. Without it I always have blank black screen on resume.

I'm pretty much satisfied with the result. Once and again FreeBSD did not let me down. This old MacBook works fine, even Youtube is rendered more or less... The only thing left to do is to change dead battery.
 
This looked like a great solution for my old netbook with Atom N270 with 945GSE iGPU. Unfortunately, I couldn't get it to compile. Does anyone understand these errors?
I am not sure if it is relevant but this is after an upgrade from 13.5 to 14.4 broke the i915 video driver on my device.
Code:
make
===> dmabuf (all)
Warning: Object directory not changed from original /usr/home/simon/drm-kmod/dmabuf
===> linuxkpi (all)
Warning: Object directory not changed from original /usr/home/simon/drm-kmod/linuxkpi
===> ttm (all)
Warning: Object directory not changed from original /usr/home/simon/drm-kmod/ttm
===> drm (all)
Warning: Object directory not changed from original /usr/home/simon/drm-kmod/drm
cc  -O2 -pipe -DLINUXKPI_VERSION=50000 '-DKBUILD_MODNAME="drm"' '-DLINUXKPI_PARAM_PREFIX=drm_' -DDRM_SYSCTL_PARAM_PREFIX=_dri -DCONFIG_DRM_AMDGPU_CIK -DCONFIG_DRM_AMDGPU_SI -DCONFIG_DRM_AMD_DC -DCONFIG_DRM_AMD_DC_SI -DCONFIG_DRM_I915_FORCE_PROBE='"*"' -DCONFIG_DRM_I915_CAPTURE_ERROR -DCONFIG_DRM_I915_USERFAULT_AUTOSUSPEND=250 -DCONFIG_DRM_I915_STOP_TIMEOUT=100 -DCONFIG_DRM_I915_PREEMPT_TIMEOUT=640 -DCONFIG_DRM_I915_HEARTBEAT_INTERVAL=2500 -DCONFIG_DRM_I915_TIMESLICE_DURATION=1 -DCONFIG_DRM_I915_MAX_REQUEST_BUSYWAIT=8000 -DCONFIG_DRM_I915_FENCE_TIMEOUT=10000 -DCONFIG_DRM_MIPI_DSI -DCONFIG_DRM_PANEL_ORIENTATION_QUIRKS -DCONFIG_DRM_FBDEV_EMULATION -DCONFIG_DRM_FBDEV_OVERALLOC=100 -DCONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG -DCONFIG_BACKLIGHT_CLASS_DEVICE -DCONFIG_DMI -DCONFIG_FB -DCONFIG_MTRR -DCONFIG_PCI -DCONFIG_PM -DCONFIG_SMP -DCONFIG_ACPI -DCONFIG_ACPI_SLEEP -DCONFIG_X86 -DCONFIG_X86_PAT -DCONFIG_AGP  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc  -I/usr/home/simon/drm-kmod/linuxkpi/gplv2/include -I/usr/home/simon/drm-kmod/linuxkpi/bsd/include -I/usr/src/sys/compat/linuxkpi/common/include -I/usr/home/simon/drm-kmod/linuxkpi/dummy/include -I/usr/home/simon/drm-kmod/drivers/gpu/drm -I/usr/home/simon/drm-kmod/include -I/usr/home/simon/drm-kmod/include/drm -I/usr/home/simon/drm-kmod/include/uapi -I/usr/home/simon/drm-kmod/drivers/gpu -include /usr/home/simon/drm-kmod/drm/opt_global.h -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -fno-common  -fPIC -ffile-prefix-map=/usr/src/sys=/usr/src/sys -ffile-prefix-map=/usr/home/simon/drm-kmod/drm=/usr/obj/usr/src/i386.i386/sys/modules/drm -fdebug-prefix-map=./machine=/usr/src/sys/i386/include -fdebug-prefix-map=./x86=/usr/src/sys/x86/include     -MD  -MF.depend.drm_pci.o -MTdrm_pci.o -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -Wno-pointer-sign -Wno-format -Wno-format-zero-length   -mno-aes -mno-avx  -std=gnu99 -c /usr/home/simon/drm-kmod/drivers/gpu/drm/drm_pci.c -o drm_pci.o
/usr/home/simon/drm-kmod/drivers/gpu/drm/drm_pci.c:188:35: error: too few arguments provided to function-like macro invocation
  188 |                                         pci_get_slot(dev->dev->bsddev),
      |                                                                      ^
/usr/src/sys/compat/linuxkpi/common/include/linux/pci.h:1329:9: note: macro 'pci_get_slot' defined here
 1329 | #define pci_get_slot(_pbus, _devfn)                             \
      |         ^
/usr/home/simon/drm-kmod/drivers/gpu/drm/drm_pci.c:256:43: error: too few arguments provided to function-like macro invocation
  256 |         info->dev = pci_get_slot(dev->dev->bsddev);
      |                                                  ^
/usr/src/sys/compat/linuxkpi/common/include/linux/pci.h:1329:9: note: macro 'pci_get_slot' defined here
 1329 | #define pci_get_slot(_pbus, _devfn)                             \
      |         ^
/usr/home/simon/drm-kmod/drivers/gpu/drm/drm_pci.c:256:12: error: incompatible pointer to integer conversion assigning to 'uint8_t' (aka 'unsigned char') from 'uint8_t (device_t)' (aka 'unsigned char (struct _device *)') [-Wint-conversion]
  256 |         info->dev = pci_get_slot(dev->dev->bsddev);
      |                   ^ ~~~~~~~~~~~~
3 errors generated.
*** Error code 1

Stop.
make[1]: stopped making "all" in /usr/home/simon/drm-kmod/drm
*** Error code 1

Stop.
make: stopped making "all" in /usr/home/simon/drm-kmod
 
Line 256 in /usr/home/simon/drm-kmod/drivers/gpu/drm/drm_pci.c the function call expects two arguments but gets only one from the code. A macro by the same name is defined earlier with two arguments so that is what is expected.

Please describe in detail what you are trying to do, and how you got to this point starting at the beginning with the source code acquisition.

I have not tried this in person, and I am not going to try it either. This is just a guess on how it could be done.

Compiling into the kernel if the source is in the tree
1. Using a FreeBSD 14.4 machine, acquire the source code for FreeBSD 14.4 kernel.
2. Compile an i386 14.4-RELEASE kernel on that machine to prove that the compilation completes successfully.
3. Acquire the source code for the FreeBSD 13.5 kernel.
4. Move the DRM KMOD source code and Linux firmware source code in the 14.4 tree to outside the 14.4 tree.
5. Copy the source code for the DRM 5.10 KMOD and Linux firmware from the 13.5 tree to the 14.4 tree
6. Edit the Makefile to refer to DRM 5.10
7. Recompile the 14.4 kernel, with the DRM 5.10 KMOD amd Linux firmware from 13.5

Another way of acquiring the DRM 5.10 code would be using the github repo branch 5.10-lts

The FreeBSD github repo for Linux firmware only has one branch, but it looks like it has old versions in it.

Building a package
On a Poudriere build machine running FreeBSD 14.4, configure it to build i386 packages in 14.4 and 13.5 jails.
Build drm-510-kmod on Poudriere for 13.5, this gets the code on your Poudriere host.
Check/Edit the makefile for drm510-kmod to make sure it doesn't have any restrictions for i386
Then run Poudriere to build drm-510-kmod for 14.4

Compile from port
RTFM
 
Line 256 in /usr/home/simon/drm-kmod/drivers/gpu/drm/drm_pci.c the function call expects two arguments but gets only one from the code. A macro by the same name is defined earlier with two arguments so that is what is expected.

Please describe in detail what you are trying to do, and how you got to this point starting at the beginning with the source code acquisition.

I have not tried this in person, and I am not going to try it either. This is just a guess on how it could be done.

Compiling into the kernel if the source is in the tree
1. Using a FreeBSD 14.4 machine, acquire the source code for FreeBSD 14.4 kernel.
2. Compile an i386 14.4-RELEASE kernel on that machine to prove that the compilation completes successfully.
3. Acquire the source code for the FreeBSD 13.5 kernel.
4. Move the DRM KMOD source code and Linux firmware source code in the 14.4 tree to outside the 14.4 tree.
5. Copy the source code for the DRM 5.10 KMOD and Linux firmware from the 13.5 tree to the 14.4 tree
6. Edit the Makefile to refer to DRM 5.10
7. Recompile the 14.4 kernel, with the DRM 5.10 KMOD amd Linux firmware from 13.5

Another way of acquiring the DRM 5.10 code would be using the github repo branch 5.10-lts

The FreeBSD github repo for Linux firmware only has one branch, but it looks like it has old versions in it.

Building a package
On a Poudriere build machine running FreeBSD 14.4, configure it to build i386 packages in 14.4 and 13.5 jails.
Build drm-510-kmod on Poudriere for 13.5, this gets the code on your Poudriere host.
Check/Edit the makefile for drm510-kmod to make sure it doesn't have any restrictions for i386
Then run Poudriere to build drm-510-kmod for 14.4

Compile from port
RTFM
Thank you for the helpful reply. I was looking for a solution to my display problem on an Advent 4211b netbook where I upgraded from 13.5 to 14., following warning messages that 13.5 was about to go out of support. I used the freebsd-update fetch and install method as recommended in the documentation but as you have guessed, I didn't RTFM and have messed things up a bit. From another thread, it looks like the i915 driver is no longer available on 32bit as a package but I found a post here that had a method to compile it from source. I followed this method but the compilation process failed for me with the errors detailed in my first post. Thank you for taking the time to read through this and explain it to me.
 
Back
Top