On Monday 20 September 2021 12:34:09 Daniel Dadap wrote:
> My apologies. I wasn't aware that WMAA was an autogenerated method name; I
> thought it was the name of the ACPI method and that the 603E9613... WMI GUID
> happened to wrap it. Given your explanation, I agree that the current name
> is inappropriate.
>
>
> > > So what would be a better name wmi-nvidia-backlight.ko I guess ?
> > > (and update the rest to match ?)
> > It looks like that no vendor driver starts with "wmi-" prefix. "-wmi"
> > string is used as a suffix. So for consistency it would be better to
> > choose "nvidia-backlight-wmi.ko".
> >
> > But it would be a nice to know if this wmi "API" is nvidia specific or
> > not. Because it is possible that there is vendor C who this "API"
> > invented, is licensing it and nvidia was just first who started using
> > this "API" + send patch to kernel. Embedded Controller, including its
> > programming is done by laptop vendor, it is fully in laptop vendor
> > control and I do not think that nvidia sells laptops. So there is a high
> > chance that we will see laptops without any nvidia component (with e.g.
> > amd or intel graphics card) and with this "API" :)
>
>
> I will have to check about the origin of the "API" to be certain. My
> understanding is that this WMI backlight control scheme is part of NVIDIA
> design recommendations to notebook OEMs, with multiple OEMs potentially
> implementing it (I'm aware of at least two off the top of my head which
> already have systems in the wild). Specifically, this is meant to address an
> issue in hybrid systems with switchable graphics, by placing control of the
> backlight level with the EC rather than having to coordinate it between the
> different GPUs which might happen to be connected to the panel at any given
> time. It seems appropriate to me to include "nvidia" in the driver name for
> now; it could be renamed if it turns out non-NVIDIA designs use it as well.
> I don't have any specific information on whether or not that would be the
> case.
Ok! So lets stick with nvidia name for now.
> > Some information may be available in bmf / acpidump code. Also there can
> > be information if this GUID is just for backlight or if it can provide
> > also some other functionality.
> >
> > So for now lets stick with nvidia and I guess later driver can be
> > renamed (if we find out that this "API" is used also on non-nvidia based
> > laptops).
>
>
> Okay, I'll send a follow-up patch to do the renaming once I get a little
> more clarification from someone who knows more about where the interface
> came from.
>
>
> >
> > > > Anyway, could you provide BMF code for this wmi acpi functionality? In
> > > > BMF could be encoded more informations, including real, meaning human
> > > > readable name of this function. Not only internal (autogenerated) AA
> > > > identifier. BMF can be extracted from dumps created by 'acpidump' tool
> > > > or with new kernels directly from files 'find /sys/ -name bmof'.
>
>
> I've attached the output of your bmf2mof tool. Seems it's named
> "WmiBrightnessNotify", which isn't especially helpful.
I see... no (interesting) additional details.
Just one check, has bmf2mof showed some warning on stderr? I see
"instance" in class definition and bmf2mof does not support decompiling
MOF instances yet, it shows warning.
> [WMI, Dynamic, Provider("WmiProv"), Locale("MS\\0x409"), Description("WMI Function"), guid("{603e9613-ef25-4338-a3d0-c46177516db7}")]
> class WmiBrightnessNotify {
> [key, read] String InstanceName;
> [read] Boolean Active;
>
> [WmiMethodId(1), Implemented, read, write, Description("Get/Set EC brightness level status")] void NotifyBrightnessLevel([in] uint32 inArg, [in] uint32 Level, [out] uint32 Result);
> [WmiMethodId(2), Implemented, read, write, Description("Get/Set Display Brightness Source")] void NotifyBrightnessSource([in] uint32 inArg0, [in] uint32 inArg1, [out] uint32 Result);
> };
