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

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

[Teodora]

Hi,

I have a Dell OptiPlex 7400 All-in-One machine and have been 
investigating why its physical HDMI-In/source button works under 
Windows but not under Linux. I wanted to flag a potential solution, 
though I am not a kernel developer but was hoping that perhaps this 
could help the community.

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 
button generates a WMI event through Acpi_OSD_event, GUID: 
02314822-307C-4F66-BF0E-48AEAEB26CC8. The GDat payload generated when 
pressing the source button begins 02 00 00 00 F2 DD which corresponds 
to event/scancode 0xDDF2.

More importantly, Dell's OSD service invokes another WMI method during 
startup:

    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 = 
1. I wrote a minimal test WMI driver which binds only to this GUID and 
invokes: wmidev_invoke_procedure(wdev, 0, 1, &input); using an empty 
input buffer.

The result is reproducible: After a normal Linux boot, the HDMI/source 
button does not switch the display. Then loading the test driver 
invokes WMI method 1 and the firmware reports success. Immediately 
after, the physical source button works correctly and switches the 
panel to HDMI-In. The test module can then be unloaded and the physical 
button continues to work.

After rebooting, the problem returns until method 1 is invoked again. 
This suggests that PegaOemNotificationStartUp is a one-shot firmware 
initialization which Dell's Windows software performs at startup but 
Linux currently does not.

Below I am sharing the small module I use as a workaround; this is 
loaded 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 
bugbear for me over the years, especially on a business machine.

Thanks,
Teodora

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

[Armin Wolf]

Am 24.10.26 um 15:48 schrieb Teodora:
> Hi,
> 
> I have a Dell OptiPlex 7400 All-in-One machine and have been 
> investigating why its physical HDMI-In/source button works under Windows 
> but not under Linux. I wanted to flag a potential solution, though I am 
> not a kernel developer but was hoping that perhaps this could help the 
> community.
> 
> 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 
> button generates a WMI event through Acpi_OSD_event, GUID: 
> 02314822-307C-4F66-BF0E-48AEAEB26CC8. The GDat payload generated when 
> pressing the source button begins 02 00 00 00 F2 DD which corresponds to 
> event/scancode 0xDDF2.
> 
> More importantly, Dell's OSD service invokes another WMI method during 
> startup:
> 
>      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 = 
> 1. I wrote a minimal test WMI driver which binds only to this GUID and 
> invokes: wmidev_invoke_procedure(wdev, 0, 1, &input); using an empty 
> input buffer.
> 
> The result is reproducible: After a normal Linux boot, the HDMI/source 
> button does not switch the display. Then loading the test driver invokes 
> WMI method 1 and the firmware reports success. Immediately after, the 
> physical source button works correctly and switches the panel to HDMI- 
> In. The test module can then be unloaded and the physical button 
> continues to work.
> 
> After rebooting, the problem returns until method 1 is invoked again. 
> This suggests that PegaOemNotificationStartUp is a one-shot firmware 
> initialization which Dell's Windows software performs at startup but 
> Linux 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 
> loaded 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 
> bugbear 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

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

[Teodora]

[-- 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 --]

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

[Armin Wolf]

Am 24.10.26 um 21:09 schrieb Teodora:
> 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

Thanks, but i do not think that this will be necessary, the ACPI tables 
should already contain the necessary data. I will check tomorrow and 
report back if i need any additional data from you.

Armin Wolf

> 
> 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
>>
> 

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

[Armin Wolf]

Am 24.10.26 um 21:14 schrieb Armin Wolf:
> Am 24.10.26 um 21:09 schrieb Teodora:
>> 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
> 
> Thanks, but i do not think that this will be necessary, the ACPI tables 
> should already contain the necessary data. I will check tomorrow and 
> report back if i need any additional data from you.
> 
> Armin Wolf

I have written a experimental kernel patch based on your custom kernel 
module, check the attached zip file. Can you check if building and 
loading this kernel module correctly enables notifications? Please also 
check that unloading said module produces no warnings in dmesg.

Thanks,
Armin Wolf

>>
>> 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
>>>
>>
> 
> 

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

[Armin Wolf]

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

Am 27.10.26 um 18:12 schrieb Armin Wolf:
> Am 24.10.26 um 21:14 schrieb Armin Wolf:
>> Am 24.10.26 um 21:09 schrieb Teodora:
>>> 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
>>
>> Thanks, but i do not think that this will be necessary, the ACPI 
>> tables should already contain the necessary data. I will check 
>> tomorrow and report back if i need any additional data from you.
>>
>> Armin Wolf
> 
> I have written a experimental kernel patch based on your custom kernel 
> module, check the attached zip file. Can you check if building and 
> loading this kernel module correctly enables notifications? Please also 
> check that unloading said module produces no warnings in dmesg.
> 
> Thanks,
> Armin Wolf

Forgot to attach the zip file, sorry.

> 
>>>
>>> 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: dell-wmi-pega.zip --]
[-- Type: application/zip, Size: 1665 bytes --]

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

[teolyub]

Got it, thanks! I am away at the moment but will test it on the weekend and get back to you as soon as I can.


> On 27 Oct 2026, at 18:04, Armin Wolf <W_Armin@gmx.de> wrote:
> 
> Am 27.10.26 um 18:12 schrieb Armin Wolf:
>>> Am 24.10.26 um 21:14 schrieb Armin Wolf:
>>> Am 24.10.26 um 21:09 schrieb Teodora:
>>>> 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
>>> 
>>> Thanks, but i do not think that this will be necessary, the ACPI tables should already contain the necessary data. I will check tomorrow and report back if i need any additional data from you.
>>> 
>>> Armin Wolf
>> I have written a experimental kernel patch based on your custom kernel module, check the attached zip file. Can you check if building and loading this kernel module correctly enables notifications? Please also check that unloading said module produces no warnings in dmesg.
>> Thanks,
>> Armin Wolf
> 
> Forgot to attach the zip file, sorry.
> 
>>>> 
>>>> 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
>>>>> 
>>>> 
>>> 
>>> 
> <dell-wmi-pega.zip>