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

checkpoint · 2025-12-25T22:31:30+0000

Hello guys.

I've recently installed FreeBSD 14.3/i386 on old MacBook and discovered that there are no drm-kmod drivers available any more. An attempt to build from sources reports unsupported version of FreeBSD. Is it temporary or permanent ? I understand that i386 is doomed and noone is willing to work on supporting it. But any hope to get at least i915kms.ko for 14.3-RELASE/i386 ? This was heck of a popular video adapter on cheap old hardware.

T-Aoki · 2025-12-25T22:54:19+0000

FYI: Picked related arch / version restrictions from ports Makefiles.
drm-510-kmod:

ONLY_FOR_ARCHS= aarch64 amd64 i386 powerpc64 powerpc64le
ONLY_FOR_ARCHS_REASON= the new KMS components are only supported on amd64, i386, aarch64, and powerpc64

.if ${OPSYS} == FreeBSD && ${OSVERSION} >= 1401501
IGNORE= not supported on FreeBSD 14.2 and higher
.endif

drm-515-kmod:

ONLY_FOR_ARCHS= amd64 powerpc64 powerpc64le
ONLY_FOR_ARCHS_REASON= the new KMS components are only supported on amd64 and powerpc64

.if ${OPSYS} == FreeBSD && ${OSVERSION} >= 1600000
IGNORE= not supported on FreeBSD 16.0 and higher
.endif

drm-61-kmod:

ONLY_FOR_ARCHS= amd64 powerpc64 powerpc64le
ONLY_FOR_ARCHS_REASON= the new KMS components are only supported on amd64 and powerpc64

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

drm-66-kmod:

ONLY_FOR_ARCHS= amd64
ONLY_FOR_ARCHS_REASON= the new KMS components are only supported on amd64

.if ${OPSYS} == FreeBSD && !( ${OSVERSION} >= 1500031 )
IGNORE= not supported on older than 1500031, no kernel support
.endif

drm-latest-kmod:

ONLY_FOR_ARCHS= amd64
ONLY_FOR_ARCHS_REASON= the new KMS components are only supported on amd64

.if ${OPSYS} == FreeBSD && !( ${OSVERSION} >= 1500058 )
IGNORE= not supported on older than 1500058, no kernel support
.endif

checkpoint · 2025-12-25T23:02:27+0000

Yes, that's what I discovered. drm-510-kmod is supported on 14.1, but not on 14.2. What's so different between these two releases ? Can drm-510-kmod support be extended to 14.3 ?

T-Aoki · 2025-12-25T23:18:01+0000

checkpoint said:
Yes, that's what I discovered. drm-510-kmod is supported on 14.1, but not on 14.2. What's so different between these two releases ? Can drm-510-kmod support be extended to 14.3 ?

Ask about it to Linux guys. Not to FreeBSD guys.

These are ported from Linux, and strongly (mandatorily) tied to LinuxKPI on base.
Even on same series of Linux kernel versions (5.10.*, 5.15.*, 6.1.*, ...), its KBI / KPI easily changes (means, "moving goals") and once DRM / KMS drivers start depending on modified newer version, LinuxKPI on base need to chase it, but only for not-yet-released *-RELEASEs (as it breaks KPI / KBI).

Not sure symbol versioning works fine on Linux(KPI) world, but even if it's possible, as far as I know, graphics team on FreeBSD is tooooooooooooooooooooooo small to maintain every versions.

And you'll see a bunch of Linux distros start dropping i386 (aka x86 without _64).

T-Aoki · 2025-12-25T23:28:19+0000

Another thing to mention.

nvidia, too, already dropped supporting i386.
The last legacy branches of drivers supporting i386 was pre-470, and all of them are EoL'ed at the end of 2022.
See my HEADSUP posted to freebsd-ports ML for detail.

The only way to use GPUs on i386 would be to stick on X11 (not Wayland!) if the GPU you have is supported by anything in x11-drivers category with names xf86-video-*. Or use x11-drivers/xf86-video-vesa (for legacy BIOS boots) or x11-drivers/xf86-video-scfb (for UEFI boots).

checkpoint · 2025-12-25T23:30:12+0000

Well, that's understood. But drm-510 has not been changed for years. It seems, the only reason its support was not added to FreeBSD 14.2/i386 and higher is because of changes in FreeBSD kernel itself (LinuxKPI framework) which made it incompatible. Anyways, thanks for answering.

The only way to use GPUs on i386 would be to stick on X11 (not Wayland!) if the GPU you have is supported by anything in x11-drivers category with names xf86-video-*. Or use x11-drivers/xf86-video-vesa (for legacy BIOS boots) or x11-drivers/xf86-video-scfb (for UEFI boots).

To hell with Wayland, I want good old X11.

Yes, Xorg's VESA driver works, but way tooooo slow. I also tried legacy xf86-video-intel, but it does not work (depends on i915kms.ko ?).

POSIX.1 · 2025-12-25T23:44:55+0000

checkpoint said:
i915kms.ko

Try to copy that file from a previous RELEASE kernel.txz. Works here.

Index of /old-releases/i386/

shkhln · 2025-12-25T23:52:28+0000

Most Intel MacBooks are capable of running FreeBSD AMD64.

Phishfry · 2025-12-25T23:53:02+0000

Problem with that is i915drm was pulled out of base and sent to ports. No longer in RELEASE.

checkpoint · 2025-12-26T00:02:02+0000

See my HEADSUP posted to freebsd-ports ML for detail.

Can you please explain why do we drop support for anabdoned drivers even if tarballs are buildable ?

*upstream tarballs are still available and buildable,

Why not to host them locally ?

*no CVEs stating "wouldn't be fixed" cannot be found for them,

Even if critical CVEs are found, we still can support/build them with some warning or use of ALLOW_NOT_SAFE macro.

*and these are the last versions that supports i386.

There are tons of i386 hardware worth supporting. If everyone (Linux) drops i386, FreeBSD will be the last man standing (maybe NetBSD also).

checkpoint · 2025-12-26T00:05:34+0000

shkhln said:
Most Intel MacBooks are capable of running FreeBSD AMD64.

Yes, but there's a bug in vidcosole (amd64 only) which makes it impossible to use. My resent report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291935

checkpoint · 2025-12-26T00:11:03+0000

Phishfry said:
Problem with that is i915drm was pulled out of base and sent to ports. No longer in RELEASE.

Pretty smart solution. Now kernel team can run lightning fast, but all the rest will lag waiting till drivers (kmod) catch up. /s

Phishfry · 2025-12-26T00:18:40+0000

But the problem is i915kms was pulled from base OS for version 13.0-RELEASE. Sent to ports.

So you would have to be using the 12-BRANCH for that trick to work.

FreshPorts -- graphics/drm-legacy-kmod: Legacy DRM modules for the linuxkpi-based KMS components

Legacy DRM driver that used to be in FreeBSD base before the removal in FreeBSD 13. For newer Intel and AMD hardware, please use graphics/drm-kmod which will pick an appropriate driver for your system. This version is mostly current with Linux 3.8 in terms of hardware support. WWW...

www.freshports.org

Would i915kms compiled for 12 and copied over work on 13 or 14 ? That is my question. I doubt it.

checkpoint · 2025-12-26T02:01:49+0000

Well, I have solved the problem, in a more radical way. I just compiled drm-kmod 5.10 drivers from source right on target machine. It just builds! The i95kms.ko driver works fine, my kids can now watch Yoube on this old MacBook (that was the intention).

Here are the instructions:

 

git clone https://github.com/freebsd/drm-kmod.git

cd drm-kmod

git checkout 5.10-lts

make

sudo make install

Or cource add i915ksm.ko to kld_list in your /etc/rc.conf. After reboot Xorg detects the driver automagically.

 

rz@sunny:~ % dmesg | head -20

---<<BOOT>>---

Copyright (c) 1992-2023 The FreeBSD Project.

Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994

        The Regents of the University of California. All rights reserved.

FreeBSD is a registered trademark of The FreeBSD Foundation.

FreeBSD 14.3-RELEASE-p5 GENERIC i386

FreeBSD clang version 19.1.7 (https://github.com/llvm/llvm-project.git llvmorg-19.1.7-0-gcd708029e0b2)

WARNING: 32-bit kernels are deprecated and may be removed in FreeBSD 15.0.

VT(vga): resolution 640x480

CPU: Intel(R) Core(TM)2 CPU         T7400  @ 2.16GHz (2161.36-MHz 686-class CPU)

  Origin="GenuineIntel"  Id=0x6f6  Family=0x6  Model=0xf  Stepping=6

  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>

  Features2=0xe3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM>

  AMD Features=0x20100000<NX,LM>

  AMD Features2=0x1<LAHF>

  VT-x: HLT,PAUSE

  TSC: P-state invariant, performance statistics

real memory  = 2684354560 (2560 MB)

avail memory = 2580418560 (2460 MB)

Event timer "LAPIC" quality 100



rz@sunny:~ % uname -a

FreeBSD sunny 14.3-RELEASE-p5 FreeBSD 14.3-RELEASE-p5 GENERIC i386



rz@sunny:~ % dmesg | grep i915

[drm] Initialized i915 1.6.0 20200917 for drmn0 on minor 0



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 (0xffffffff)

    Device: llvmpipe (LLVM 19.1.7, 128 bits) (0xffffffff)

    Version: 24.1.7

    Accelerated: no

    Video memory: 68096MB

    Unified memory: yes

    Preferred profile: core (0x1)

    Max core profile version: 4.5

    Max compat profile version: 4.5

    Max GLES1 profile version: 1.1

    Max GLES[23] profile version: 3.2

Memory info (GL_ATI_meminfo):

    VBO free memory - total: 528693 MB, largest block: 528693 MB

    VBO free aux. memory - total: 512 MB, largest block: 512 MB

    Texture free memory - total: 528693 MB, largest block: 528693 MB

    Texture free aux. memory - total: 4294772974 MB, largest block: 4294772974 MB

    Renderbuffer free memory - total: 528693 MB, largest block: 528693 MB

    Renderbuffer free aux. memory - total: 4294772974 MB, largest block: 4294772974 MB

Memory info (GL_NVX_gpu_memory_info):

    Dedicated video memory: 528705 MB

    Total available memory: 334657 MB

    Currently available dedicated video memory: 528693 MB

OpenGL vendor string: Mesa

OpenGL renderer string: llvmpipe (LLVM 19.1.7, 128 bits)

OpenGL core profile version string: 4.5 (Core Profile) Mesa 24.1.7

OpenGL core profile shading language version string: 4.50

OpenGL core profile context flags: (none)

OpenGL core profile profile mask: core profile



OpenGL version string: 4.5 (Compatibility Profile) Mesa 24.1.7

OpenGL shading language version string: 4.50

OpenGL context flags: (none)

OpenGL profile mask: compatibility profile



OpenGL ES profile version string: OpenGL ES 3.2 Mesa 24.1.7

OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20





rz@sunny:~ % glmark2

** GLX does not support GLX_EXT_swap_control or GLX_MESA_swap_control!

** Failed to set swap interval. Results may be bounded above by refresh rate.

=======================================================

    glmark2 2023.01

=======================================================

    OpenGL Information

    GL_VENDOR:      Mesa

    GL_RENDERER:    llvmpipe (LLVM 19.1.7, 128 bits)

    GL_VERSION:     4.5 (Compatibility Profile) 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

=======================================================

** GLX does not support GLX_EXT_swap_control or GLX_MESA_swap_control!

** Failed to set swap interval. Results may be bounded above by refresh rate.

[build] use-vbo=false: FPS: 46 FrameTime: 21.870 ms

=======================================================

                                  glmark2 Score: 45 

=======================================================

checkpoint · 2025-12-26T02:10:34+0000

And attaching Xorg.0.log for the history. Xorg running on MacBook2,1 under FreeBSD 14.3-RELEASE/i386 using i915kms.ko driver.

Now, back to my original question. Can we have this drm-kmod supported officcialy in all 14.x/i386 releases ?

Phishfry · 2025-12-26T03:00:31+0000

checkpoint said:
GL_RENDERER: llvmpipe (LLVM 19.1.7, 128 bits)

You realize why your score stinks right ?

That is software rendering. Not hardware accelerated i915kms aka MODESETTING.

Phishfry · 2025-12-26T03:02:32+0000

You can load the scfb driver and glmark2 shows exactly the same output and scoring.
LLVM pipe

My handy guide:
xf86-video-intel=llvmpipe
scfb=llvmpipe

Phishfry · 2025-12-26T03:07:17+0000

I really suggest not loading i915kms automatically. Manually load it until you know it's good.

You will see a resolution change and console messages which can be indispensable.
kldload i915kms

Phishfry · 2025-12-26T03:14:34+0000

This is what the modesetting driver shows up as:

Code:

=======================================================
    glmark2 2023.01
=======================================================
    OpenGL Information
    GL_VENDOR:      Intel
    GL_RENDERER:    Mesa Intel(R) UHD Graphics 630 (CFL GT2)
    GL_VERSION:     4.6 (Compatibility Profile) Mesa 24.1.7
    Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=24 stencil=0 samples=0
    Surface Size:   800x600 windowed
=======================================================

Phishfry · 2025-12-26T03:17:16+0000

Oh crap you are on T7400 Core2duo? I thought N270 was pushing it.
You are not going to get it to work with something that old. You need => SandyBridge for drm2 driver.

Phishfry · 2025-12-26T03:25:09+0000

I am not trying to bust your stones but the Xorg log shows it too.

27.037] (II) intel(0): Allocated new frame buffer 1280x800 stride 8192, tiled
[ 27.041] (II) UXA(0): Driver registered support for the following operations:

The Intel UXA driver is not the modesetting driver. i915 KernelModeSetting
It's a differnt driver.

rcbsdpge · 2025-12-26T05:38:25+0000

Better gpu engineering than nvidia. Maybe we can build these drivers out for the long term

By this I mean targeting all gpu drivers old and cutting edge

Dare I say a graphics processing engine

T-Aoki · 2025-12-26T11:42:08+0000

checkpoint said:
Can you please explain why do we drop support for anabdoned drivers even if tarballs are buildable ?

You're mis-understanding here.
As described in the HEADSUP, it is because why EoL'ed 3xx series of drivers are still available as FreeBSD ports, unless unlikely-to-be-fixed CVEs are announced.

checkpoint said:
Why not to host them locally ?

Because these are PROPRIETARY DRIVER.

checkpoint said:
Even if critical CVEs are found, we still can support/build them with some warning or use of ALLOW_NOT_SAFE macro.

No!
It's a clear reason to drop it. At least, disallowing to provide as pkg should be stopped (in the latter specific case, I'll add non-default option to allow the affected one to build). EVERYONE ATTEMPT TO USE VULNERABLE SOFTWARE SHALL 100% UNDERSTAND WHAT'S THEY ARE TRYING TO DO.

checkpoint said:
If everyone (Linux) drops i386, FreeBSD will be the last man standing (maybe NetBSD also).

NetBSD would be.
See this huge thread on freebsd-arch ML.

At first, i386 was planned to be removed on Sep. 2027. Beforehand, stop providing installation images for all 32bit archs was planned, but with quite strong objections in the discussion, armv7 alone remained to be provided.

The reason for dropping is, as far as I know, the lack of developers maintaining 32bit archs and problems on availability of reliable, reasonabully priced and newly manufactured computers / spare parts.

Without both of them, the codes would be hard to maintain, even for allowing builds on continuously upgraded toolchains.

Once upstream of toolchains (currently, LLVM) drops support for specific archs and no alternatives are available, FreeBSD project alone cannot continue supporting the archs.

On the other hand, PowerPC64 big endian (BE) gets a developer and computers for testing (actually POWER, not PowerPC), thus, going to remain unlike other BE archs reading another thread on freebsd-arch ML.
This kind of things are usually discussed in this ML (apart from GPU-related things).

rcbsdpge · 2025-12-26T12:15:00+0000

Are these codebases archived by chance. They just had the big news about Unix v4. I think Dice posted about it fairly recently

I imagine someone later down the line can bring something back from legacy FreeBSD.

The i915kms driver has been heavily battle-tested on my old machine. And very much capable. With ECC I might add

I see this as opportunity to harden base system which is awesome

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

Attachments