radeon kernel driver not suppressing ACPI_VIDEO_NOTIFY_PROBE events when it should

[Hans de Goede]

Hi All,

I get Cc-ed on all Fedora kernel bugs and this one stood out to me:

https://bugzilla.redhat.com/show_bug.cgi?id=1911763

Since I've done a lot of work on the acpi-video code I thought I should
take a look. I've managed to help the user with a kernel-commandline
option which stops video.ko (the acpi-video kernel module) from emitting
key-press events for ACPI_VIDEO_NOTIFY_PROBE events.

This is on a Dell Vostro laptop with i915/radeon hybrid gfx.

I was thinking about adding a DMI quirk for this, but from the brief time
that I worked on nouveau (and specifically hybrid gfx setups) I know that
these events get fired on hybrid gfx setups when the discrete GPU is
powered down and something happens which requires the discrete GPUs drivers
attention, like an external monitor being plugged into a connector handled
by the dGPU (note that is not the case here).

So I took a quick look at the radeon code and the radeon_atif_handler()
function from drivers/gpu/drm/radeon/radeon_acpi.c. When successful that
returns NOTIFY_BAD which suppresses the key-press.

But in various cases it returns NOTIFY_DONE instead which does not
suppress the key-press event. So I think that the spurious key-press events
which the user is seeing should be avoided by this function returning
NOTIFY_BAD.

Specifically I'm wondering if we should not return
NOTIFY_BAD when count == 0?   I guess this can cause problems if there
are multiple GPUs, but we could check if the acpi-event is for the
pci-device the radeon driver is bound to. This would require changing the
acpi-notify code to also pass the acpi_device pointer as part of the
acpi_bus_event but that should not be a problem.

Anyways I'm hoping you all have some ideas. If necessary I can build
a Fedora test-kernel with some patches for the reporter to test.

Regards,

Hans