Re: Possible bug in acpi_video(4)
On 29/05/2020 14:39, MrPhyber wrote: > Nevermind, after some thinkering I managed to get it to work on > drm-fbsd12.0-kmod. Now the hardware brightness controls work! > I am really grateful, thank you. I wonder when this patch will > be pushed upstream. In fact, the piece of change that updates amdgpu_atif_handler() is already in Linux. But the LKPI ACPI glue seems to need a bit more polish (or a proper design). -- Andriy Gapon ___ freebsd-acpi@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Possible bug in acpi_video(4)
> > 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 ___ freebsd-acpi@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Possible bug in acpi_video(4)
On 28/05/2020 13:02, MrPhyber wrote: > > 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 -- Andriy Gapon ___ freebsd-acpi@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
