User-space access to WMI functions

The alternative would be that WMI is used as the original spec intended - with standardised GUIDs for the functions, rather than each vendor implementing their own that necessitates them all maintaining separate driver stacks in the first place just to do common things - i.e. why does each vendor need a different way to turn on wireless, lights, etc.

It also feels like it somewhat defeats the point of the kernel being an abstraction layer for all this 'basic' stuff anyway (e.g. rfkill, backlight, etc).

As an end-user, I have mixed feelings about this proposal. On one hand, I've come to enjoy generally having a functioning set of drivers "out of the box", be they bundled with the core kernel or firmware blobs bundled by the distro. Notable exceptions to this are needing to manually add a yum repo for nvidia driver and the occasional gymnastics to extract a firmware blob of a windows drivers for something like a broadcom bluetooth interface. The former is a difficult vendor that has largely been worked around by community packaging effort. The later is a crap-tacular experience that is likely beyond the technical abilities or threshold of effort for most end-users. I really want hw vendors to work with the Linux community AND make firmware payloads freely redistributable [by distros]. I definitely *DO NOT* want to have to track down and install a laptop vendor's model-specific state of the art tcl/tk app to control screen brightness, which almost certainly been properly packaged for my distro of choice.

That said, it does seem a bit heavy weight to require a new mainline kernel release to trickle out in order to add support for a couple of custom buttons. I don't have any technical objection to user-space driver frameworks. It is almost certainly in the general Linux communities best interests to encourage hw vendors to contribute support back upstream for their own equipment. If the user-space route is to be embraced, I'd like to see it be a udev/hwdb-like solution that is:

a) a single de facto framework which vendors can contribute configuration data to
b) is treated as "core" system service that is started early and works as part of a minimal/install/rescue environment
c) only results in the bare minimum of Debian forks

> It would, he said, open the flood gates to interesting new developments and "allow vendors to 'own their own destiny' and innovate and support their platforms independently".
I have a lot of unflattering words for this, but I'll constrain myself to just two: “hopelessly naïve”. Or “Windows Systray”.

> allow vendors to 'own their own destiny' and innovate and support their platforms independently...
> ...proved to be surprisingly unappealing

How can that be surprising? This is basic understanding-the-customer stuff. Display brightness control is not an area where users want hardware vendors to be creative or diverse, or isolate their support costs to themselves. Display brightness control is an area where users want hardware to work consistently and predictably as they move their software and data from one ephemeral device to another, and enjoy the greater (or lesser) range of possible brightness values from a more capable (or less expensive) display without having to fight with a new and unfamiliar UI. Vendors would do better to follow each other (or even keep their own designs consistent from one model to the next) than to invent yet another incompatible display brightness control.

Sometimes full WMI support isn't desirable. I've found it quite useful to be able to rip out WMI functions that are supported (like the WiFi kill switch, which on some laptops is positioned exactly where my fingers keep bumping into it every few minutes). It could be easier to do that sort of thing in userspace if there was a sane framework in place, but it would clearly be harder to do that sort of thing if all the WMI functions were controlled by a binary blob.

Notwithstanding the above, the idea isn't entirely terrible. It would be nice to have a userspace rapid prototyping framework, so a medium-skilled user could poke around the function table and discover which function controls the display brightness on a brand new laptop...assuming that there aren't functions in WMI that erase the BIOS or something.

Medium-skilled users used to blindly fire IO writes to ISA registers to figure that sort of thing out on their machines. Now that we have all these discoverable interfaces like ACPI and WMI which can make this sort of probing much easier and safer, but for some reason we've buried them all deeply in the kernel and refuse to allow userspace to get to them.

> The changes required are typically small to the point of being trivial, but they are indeed required, and it seems that some vendors are finding the process of getting those changes into the mainline cumbersome.

If distributions are interested in supporting the hardware the vendor also has the option of just writing a "good enough" kernel patch and dropping it somewhere they can find it. Distributions would be likely to integrate it into their own kernels with a minimum of fuss and presumably one of them would make the effort to get it upstream to lower their own maintenance effort. The vendor just has to be willing to accept that they will have little control over the driver after they let someone else do the integration, but that may actually be a bonus rather than a problem.

> In other words, the idea of moving platform support to a user-space blob — perhaps a proprietary blob at that — proved to be surprisingly unappealing to a number of developers on the list.

There seems to be an assumption that there is no way to discourage user-space binary-only drivers. Is that really the case? Linux makes it very clear that user-space binaries using Linux kernel interfaces are not considered to be GPL-derived works of the kernel. Would the situation change if the Linux developers made clear that user-space drivers which use particular advertised interfaces are not covered by this? Clearly there would always be a few people willing to try to push the boundaries and possibly risk testing it in court, just as there are with kernel drivers, but I suspect that many people would prefer to just go along with it.

Please, God, no.

What's likely to happen if this were done, for the very simple case of backlights, is:
- we'd have very low-quality, probably insecure or just utterly broken glue code provided by vendors, most likely proprietary just in case somebody tries to steal their awful technology
- desktops would start adding hardware specific code in their backlight controlling code
- desktops would realise that they need a solution to hide all that WMI stuff, you'd end up with at least 2 or 3 separate implementations, at the very least one for Android and one for "D-Bus-y" Linux. Infrastructure would need to be recreated, APIs redefined. In the meanwhile, non-WMI backlights and buttons still live happily in the kernel, getting their drivers reviewed.
- somebody gets sick of the user-space library, realising there's no competitive advantage to a bloody backlight driver, starts sending kernel patches to implement the backlight directly in the kernel from the reverse engineered information.

We already have common APIs to offer user-space for buttons and backlights. As for the past 20-odd years, giving hardware and specs away is likely going to make the hardware support better than blobs of executables dumped as tarballs on a forum.

> Each laptop vendor has its own way of connecting these features to WMI functions; as a result, the kernel has to be taught about each new laptop design before it will work as intended.

Which has lead to the kernel containing 42K LOC in the kernel to implement some pretty trivial flotsam and jetsam because the hardware vendors never bothered to standardise on a common set of scan codes and registers. If Microsoft's lenient driver model hadn't let them get away with this pain free for so long, maybe we wouldn't be in this position now.

Changing things so we don't push some of the inconvenience this continual churn creates back onto the hardware vendors who create it doesn't sound like a good idea to me.

Several good thoughts and comments here, most generally echoed in the various mailing list threads as well. One additional piece of context is the initial motivation. The idea behind exporting WMI to userspace was to support Web Based Enterprise Management (WBEM) tools, which is more inline with the intent of WMI in the first place - as opposed to all the other things like LEDs, hotkeys, and radios that have crept in.

WBEM involves SMM. ASL (WMI) accessing SMM, providing a limited access opregion, is arguably an improvement from the OS accessing SMM and providing it full access to physical memory (see the existing Linux kernel dcdbas driver).

There are a number of comments lamenting the choice of the OEMs to implement certain features through WMI. I think it's fair to say that few people appreciate that more than the x86 platform drivers team :-) For the vast majority of these things, we have very little input and are working with platforms that were designed for a fundamentally different software ecosystem.

Finally, from all the discussion, it is clear that caution is required. As we move closer to a design and implementation, we are looking carefully at how to enable vendors who are actively trying to collaborate with the Linux kernel developers to support their platforms, while not opening up pandora's box on other platforms.