Possible bug in acpi_video(4)

MrPhyber mrphyber at protonmail.com
Fri May 29 10:11:12 UTC 2020


> > I tried the patch you sent, and I have a few questions:
> >
> > 1.  when will this patch be avaiable on 12.1-RELEASE?
>
> In stable/12 soon.
> In 12.1 probably never as the release has been released.
>
> > 2.  now the system does not spit out any more errors like
> >     the one complaining about _BQC missing: in fact it doesn't
> >     give errors at all, but the hardware brightness controls still
> >     won't work. Now hw.acpi.video.lcd0.active = 1 but if I try
> >     to modify hw.acpi.video.lcd0.brightness nothing appens. I
> >     still think that acpi_video doesn't see all video outputs
> >     (I investigated a bit further and on OpenBSD there are
> >     acpivouts on dmesg output, could be an hint). What could
> >     be wrong?
> >
>
> If your system is like mine then ACPI does not directly control the brightness.
> Instead, it posts some events that a video driver (like radeon or amdgpu) is
> supposed to listen to and then the driver should update the brightness.
> (This can also be thought of as the brightness being controlled by the video
> "card" / GPU rather than by a motherboard).
> For my laptop I had to patch amdgpu driver:
> https://github.com/FreeBSDDesktop/kms-drm/pull/241

I downloaded from GitHub drm-fbsd12.1-kmod and compiled adding
your patch, and now the hardware brightness controls work like
a charm! Sadly, suspend/resume broke. I tried using "vanilla"
drm-fbsd12.1-kmod and the error persists, so the problem is
not the patch but the drm itself. The laptop seems to enter
suspend state (blinking LED confirms that) but at resume time
the monitor doesn't turn on, and the system is hung up. Can your
patch be backported to drm-fbsd12.0-kmod where suspend/resume
worked?
-MrPhyber




More information about the freebsd-acpi mailing list