/dev/backlight/backlight0: No such file or directory

Hello, I am normally a Linux user, but I have an old Acer Aspire One which is an i386 and I found among the few OS that still supports it FreeBSD so I gave it a go.
I was able to make a dual boot FreeBSD/Windows XP.
I am currently running FeeBSD 13.5 with IceWM. Basically everything runs fine aside the brightness regulation which I really want to fix to save battery (and my eyes). Also the Fn keys do not work but I don't care I want to change brightness via command line.

This is the output of hw-probe: https://bsd-hardware.info/?probe=39030d3f23

I have installed the drm-kms and loaded the intel drivers, and I have read on the forum to try to load also the acpi_driver which I did but did not work.

My /boot/loader.conf:
Code:
acpi_asus_load="YES"
hw.i915kms.enable_dpcd_backlight=1
acpi_video_load="YES"
ubtbcmfw_load="YES"

and my /etc/rc.conf:
Code:
clear_tmp_enable="YES"
hostname="stefano-freebsd"
keymap="it.kbd"
wlans_ath0="wlan0"
ifconfig_wlan0="WPA DHCP"
sshd_enable="YES"
moused_enable="YES"
ntpdate_enable="YES"
ntpd_enable="YES"
powerd_enable="YES"
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="AUTO"
kld_list="i915kms cuse acpi_video"
lightdm_enable="NO"
ifconfig_re0="DHCP"
dbus_enable="YES"
slim_enable="YES"
webcamd_enable="YES"
webcamd_0_flags="-d ugen3.2"
wpa_gui_enable="YES"

However if I use backlight I get the following error:
Code:
backlight: cannot open /dev/backlight/backlight0: No such file or directory
(and it is true it does not exists at all the folder backlight).

This is the output of xrandr --verbose
Code:
Screen 0: minimum 1024 x 768, current 1024 x 768, maximum 1024 x 768
default connected 1024x768+0+0 (0x3ff) normal (normal) 0mm x 0mm
        Identifier: 0x3fe
        Timestamp:  120041
        Subpixel:   horizontal rgb
        Gamma:      1.0:1.0:1.0
        Brightness: 0.0
        Clones:  
        CRTC:       0
        CRTCs:      0
        Transform:  1.000000 0.000000 0.000000
                    0.000000 1.000000 0.000000
                    0.000000 0.000000 1.000000
                   filter:
        non-desktop: 0
                supported: 0, 1
  1024x768 (0x3ff)  0.000MHz *current
        h: width  1024 start    0 end    0 total 1024 skew    0 clock   0.00KHz
        v: height  768 start    0 end    0 total  768           clock   0.00Hz
As you can see the brightness is stuck to zero.

Of note on winXP I have no problem in changing the brightness with the Fn+left/right arrows key, so the hw is capable of it and it is working fine.

So I have a few questions:
  • why is backlight0 missing?
  • When is it supposed to be created?
  • During installation or at boot?
  • And why is it not created?
  • Is it an unsupported HW problem? A driver problem? A config problem?
 
WARNING 1: Seeing that you have received no additional responses in more than 72 hours, with nothing but good intentions in my heart, especially helping you, I outsourced your case to a non-subject expert-in-training and below the horizontal line is what it had to say.

WARNING 2: Use it all only as an inspiration or starting investigative point and check everything using official sources. That it sounds certain doesn't mean it is; these non-subjects are trained to first and foremost sound certain.

WARNING 3: Read in full before doing anything. Then, decide what you want to do.

Note: If you end up solving your problem, please write a post explaining what fixed it, so it gets documented for the community.



Backlight control on FreeBSD 13.5/i386 (Acer Aspire One)

HAZARD: /dev/backlight is created only when a kernel driver registers a backlight; incorrect assumptions may waste time troubleshooting the wrong layer.
Why /dev/backlight/backlight0 is missing

  • backlight(8) works only when some kernel driver registers a backlight via backlight(9)(). If no registration occurs, /dev/backlight/backlight0 does not exist and backlight fails with “No such file or directory.” backlight(8)() backlight(9)()
  • /dev/backlight/* is created by devfs at boot/module attach time when the driver registers the device. It is not created “during installation.” backlight(9)()

HAZARD: Changing kernel modules can break graphics startup and may require single-user recovery.
Step 1 — Verify whether Intel KMS/DRM is actually attached

Code:
# kldstat | egrep 'i915kms|drm'
# ls -ld /dev/dri /dev/backlight
# dmesg | egrep -i 'drm|i915|kms|backlight|acpi_video'
What success looks like
  • /dev/dri exists (KMS/DRM is alive).
  • /dev/backlight exists (a backlight was registered).

Verify what Xorg is using
Code:
$ grep -E '(modesetting|intel|vesa|scfb|fbdev|drm|dri)' /var/log/Xorg.0.log
  • If Xorg is on vesa/ scfb/ fbdev rather than modesetting, hardware backlight integration is often unavailable through the DRM path. (Confirm in the log, not by inference.)

HAZARD: Installing the wrong DRM kmod package for the FreeBSD release can prevent i915kms from attaching.
Step 2 — Confirm the correct DRM kmod package for FreeBSD 13.5


Verify installed packages
Code:
# pkg info | egrep '^drm-|^gpu-firmware|^libdrm'

Install/repair
Code:
# pkg install drm-510-kmod

Ensure boot-time module load
Code:
# sysrc kld_list="i915kms cuse acpi_video"

HAZARD: Loading acpi_video too early can prevent it from attaching properly; do not force-load it in loader.conf.
Step 3 — Fix acpi_video(4) load ordering


/boot/loader.conf — remove early loads (and remove ASUS-only module)
Code:
# acpi_asus_load="YES"      # ASUS-only; remove on Acer
# acpi_video_load="YES"     # do not load here

Optional note
  • hw.i915kms.enable_dpcd_backlight=1 is mainly relevant to eDP/DPCD backlight paths; many older netbooks use LVDS. Keep only if proven necessary on this exact hardware.

Verify after reboot
Code:
# dmesg | grep -i acpi_video
# sysctl -a | grep '^hw.acpi.video'

HAZARD: Writing unsupported values to sysctls can leave brightness unchanged; always use the provided levels/presets.
Step 4 — Use ACPI Video brightness sysctls (often the only working method)


List available knobs
Code:
# sysctl -a | grep '^hw.acpi.video'

Set brightness using supported levels
Code:
# sysctl hw.acpi.video.lcd0.levels
# sysctl hw.acpi.video.lcd0.brightness=50

Optional presets
Code:
# sysctl hw.acpi.video.lcd0.economy=40
# sysctl hw.acpi.video.lcd0.fullpower=80

Persist at boot (per acpi_video(4)())
Code:
# /etc/sysctl.conf
hw.acpi.video.lcd0.economy=40
hw.acpi.video.lcd0.fullpower=80
hw.acpi.video.lcd0.brightness=50

HAZARD: Do not rely on xrandr “Brightness” for battery savings; it is typically a software multiplier and may not reduce backlight power.
Step 5 — If /dev/backlight/* exists, use backlight(8)

Code:
# backlight -i
# backlight 70
  • backlight(8) defaults to /dev/backlight/backlight0 unless -f is used. backlight(8)()

HAZARD: Hardware support limitations may make /dev/backlight impossible on this platform; avoid endless tuning when the GPU generation is outside the intended DRM/KMS support envelope.
Hardware support reality check

  • Many Aspire One i386 models use very old Intel integrated graphics. Newer DRM/KMS stacks are primarily aimed at newer Intel generations; older chipsets can fall back to non-KMS paths, commonly preventing backlight registration via /dev/backlight/*. graphics/drm-54-kmod
  • If hw.acpi.video.* sysctls do not appear even when acpi_video(4)() is loaded after DRM, the firmware likely is not exposing ACPI Video brightness control to the OS. acpi_video(4)()

Direct answers
  • Why is backlight0 missing? No driver registered a backlight with backlight(9)(), so devfs never created /dev/backlight/backlight0. backlight(9)()
  • When is it supposed to be created? During boot/module attach, when a driver registers a backlight (not during installation). backlight(9)()
  • Why is it not created? Typically Intel KMS/DRM did not attach (Xorg fallback), or the platform uses a brightness path not wired into backlight(9)() for this hardware/stack.
  • Unsupported HW vs driver vs config? Often mixed: acpi_video(4)() load order matters; older Intel generations can limit DRM/KMS/backlight registration; ACPI sysctl control depends on firmware support. acpi_video(4)()
 
Back
Top