Re: OptiPlex 7400 AIO HDMI-IN button requires WMI startup method

[Teodora <teolyub@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5418 bytes --]

Hi Armin,

Thanks for your response. Attached is the requested acpidump.

Regarding the other methods on the same WMI interface: 
DellOSDService.exe appears to invoke 
AcpiOSD_WMBC_method::PegaOemNotificationStartUp. The companion 
MediaButtons.exe also has WMI execution paths for 
PegaOemNotificationBrightnessUP and PegaOemNotificationBrightnessDown. 
I did not find call paths for PegaOemNotificationStop, 
PegaOemNotificationRSVD1, or PegaOemNotificationRSVD2, however.

There is also a separate AcpiOSD_WMBB_method interface used by 
DellOSDService.exe for a method named PegaOemReturnUBFR, but that 
appears to be a different WMI interface.

I can boot back into Windows and retrieve the WmiMethodId qualifiers 
for all of the WMBC methods if that would be useful, but I have not 
done that yet.

Thanks

On Sat, Oct 24 2026 at 20:52:25 +02:00:00, Armin Wolf <W_Armin@gmx.de> 
wrote:
> Am 24.10.26 um 15:48 schrieb Teodora:
>> Hi,
>> 
>> I have a Dell OptiPlex 7400 All-in-One machine and have been 
>> \x7finvestigating why its physical HDMI-In/source button works under 
>> Windows \x7fbut not under Linux. I wanted to flag a potential solution, 
>> though I am \x7fnot a kernel developer but was hoping that perhaps this 
>> could help the \x7fcommunity.
>> 
>> So, my system details are:
>> 
>> - Dell OptiPlex 7400 All-in-One
>> - Fedora 44
>> - Kernel: 7.2.11-200.fc44.x86_64
>> - dell-wmi-aio is present and loaded
>> 
>> While investigating the Dell Windows OSD software, I found that the 
>> \x7fbutton generates a WMI event through Acpi_OSD_event, GUID: 
>> \x7f02314822-307C-4F66-BF0E-48AEAEB26CC8. The GDat payload generated 
>> when \x7fpressing the source button begins 02 00 00 00 F2 DD which 
>> corresponds to \x7fevent/scancode 0xDDF2.
>> 
>> More importantly, Dell's OSD service invokes another WMI method 
>> during \x7fstartup:
>> 
>>      Class: AcpiOSD_WMBC_method
>>      GUID: 2D703EE8-36AC-4F88-BDB5-7556CE6B2946
>> 
>>      Method: PegaOemNotificationStartUp
>>      WmiMethodId: 1
>>      Description: "Invoked by AP when system up."
>> 
>> Linux exposes this WMI interface on the machine, with instance_count 
>> = \x7f1. I wrote a minimal test WMI driver which binds only to this 
>> GUID and \x7finvokes: wmidev_invoke_procedure(wdev, 0, 1, &input); 
>> using an empty \x7finput buffer.
>> 
>> The result is reproducible: After a normal Linux boot, the 
>> HDMI/source \x7fbutton does not switch the display. Then loading the 
>> test driver invokes \x7fWMI method 1 and the firmware reports success. 
>> Immediately after, the \x7fphysical source button works correctly and 
>> switches the panel to HDMI- \x7fIn. The test module can then be 
>> unloaded and the physical button \x7fcontinues to work.
>> 
>> After rebooting, the problem returns until method 1 is invoked 
>> again. \x7fThis suggests that PegaOemNotificationStartUp is a one-shot 
>> firmware \x7finitialization which Dell's Windows software performs at 
>> startup but \x7fLinux currently does not.
> 
> Interesting, can you share the output of acpidump?
> 
>> 
>> Below I am sharing the small module I use as a workaround; this is 
>> \x7floaded once on boot.
>> 
>> // SPDX-License-Identifier: GPL-2.0
>> 
>> #include <linux/module.h>
>> #include <linux/kernel.h>
>> #include <linux/wmi.h>
>> 
>> #define DELL_OSD_WMI_GUID "2D703EE8-36AC-4F88-BDB5-7556CE6B2946"
>> #define DELL_OSD_STARTUP_METHOD 1
>> 
>> static int dell_osd_probe(struct wmi_device *wdev, const void 
>> *context)
>> {
>>   struct wmi_buffer input = {
>>    .length = 0,
>>    .data = NULL,
>>   };
>> 
>>   u8 instances;
>>   int ret;
>> 
>>   (void)context;
>> 
>>   instances = wmidev_instance_count(wdev);
>> 
>>   dev_info(&wdev->dev,
>>     "Dell OSD test: WMI device found, instance count = %u\n",
>>     instances);
>> 
>>   if (instances < 1) {
>>    dev_err(&wdev->dev,
>>     "Dell OSD test: no WMI instance 0 available\n");
>>    return -ENODEV;
>>   }
>> 
>>   dev_info(&wdev->dev,
>>     "Dell OSD test: calling PegaOemNotificationStartUp, method ID 
>> 1\n");
>> 
>>   ret = wmidev_invoke_procedure(
>>    wdev,
>>    0,
>>    DELL_OSD_STARTUP_METHOD,
>>    &input
>>   );
>> 
>>   if (ret < 0) {
>>    dev_err(&wdev->dev,
>>     "Dell OSD test: startup method failed: %d\n",
>>     ret);
>>    return ret;
>>   }
>> 
>>   dev_info(&wdev->dev,
>>     "Dell OSD test: startup method returned success\n");
>> 
>>   return 0;
>> }
>> 
>> static const struct wmi_device_id dell_osd_id_table[] = {
>>   {
>>    .guid_string = DELL_OSD_WMI_GUID,
>>   },
>>   { }
>> };
>> 
>> MODULE_DEVICE_TABLE(wmi, dell_osd_id_table);
>> 
>> static struct wmi_driver dell_osd_driver = {
>>   .driver = {
>>    .name = "dell-osd-wmi-test",
>>   },
>>   .id_table = dell_osd_id_table,
>>   .probe = dell_osd_probe,
>>   .no_singleton = true,
>> };
>> 
>> module_wmi_driver(dell_osd_driver);
>> 
>> MODULE_AUTHOR("Dell OptiPlex 7400 AIO experimental test");
>> MODULE_DESCRIPTION("Experimental Dell OSD WMI startup-method test");
>> MODULE_LICENSE("GPL");
>> 
>> I hope this would be useful as not having this function has been 
>> such a \x7fbugbear for me over the years, especially on a business 
>> machine.
>> 
>> Thanks,
>> Teodora
> 
> Nice work, i will try to check if other devices expose the same 
> firmware interface. If yes then we can for sure have a small driver 
> initializing this during probe.
> 
> Does the OEM software invoke any other methods on this WMI device?
> 
> Thanks,
> Armin Wolf
> 


[-- Attachment #2: acpidump.txt.gz --]
[-- Type: application/gzip, Size: 631623 bytes --]