This matches the pattern in /etc/acpi/events/videobtn. That pattern is correct; and the action specified for it is also correct, and the behavior you're describing appears to also be the correct behavior when a video mode switch request is received.
So I don't think this is a bug in any of the userspace packages involved in processing this event. Instead, I would argue it's a bug in the vendor ACPI implementation, which should not generate this event.
I'm reassigning this bug to the Linux kernel package; the kernel team may wish to consider filtering out the event at the kernel level to compensate for the strange behavior of the ACPI implementation.
So, this acpi event is the one at issue:
video VID 00000080 00000000
This matches the pattern in /etc/acpi/ events/ videobtn. That pattern is correct; and the action specified for it is also correct, and the behavior you're describing appears to also be the correct behavior when a video mode switch request is received.
So I don't think this is a bug in any of the userspace packages involved in processing this event. Instead, I would argue it's a bug in the vendor ACPI implementation, which should not generate this event.
I'm reassigning this bug to the Linux kernel package; the kernel team may wish to consider filtering out the event at the kernel level to compensate for the strange behavior of the ACPI implementation.