On Mon, Nov 18, 2024 at 09:54:25PM -0600, Mario Limonciello wrote: > Loop Dell Client Kernel M/B for any comments. > > On 11/18/2024 21:47, Kurt Borja wrote: > > Hi! > > > > I'm planning on migrating the alienware-wmi driver to the new WMI > > interface, as it's currently using the deprecated one. > > 🎉 > > > My plan is to: > > > > rename alienware-wmi.c -> alienware-wmi-base.c > > create alienware-wmi.h > > create alienware-wmi-legacy > > create alienware-wmi-wmax > > > > The last two files would not be independent modules, just includes for > > the base module. The base module would be in charge of initializing the > > platform driver plus the correct wmi_driver backend, but the wmi probes > > would register the platform device. This would be very similar to what > > other dell drivers already do. Aditionally I want to migrate everything > > to the state container design pattern. > > > > I would do this in such a way that the legacy and new code would be > > completely independent of each other (i.e. different state containters, > > dmi checks, etc). > > As the original author of this driver when I was at Dell I'll add some > comments. > > The 'legacy' code was very narrowly focused for supporting a handful of > hardware specifically for lighting control. One was the original Alienware > steam machine, and then a few generations of the X51. > > I don't know how much of the driver continues to work on hardware since > then. Maybe Dell guys I added to CC can comment on how much of this has > stuck around over the years and keeps working. My guess is that none of it works on new models. The LEGACY wmi device is not longer included on new machines, as all lighting control is done through an EC and the WMAX device was repurposed to fan/thermal control. I say this based on exploring quite a few acpidumps and a couple RGB control Windows open source alternatives. > > > > > Pros: > > - Modern interfaces and design patterns > > - This is compatible with Mario's upcoming platform profile changes as > > the WMAX device would hold a reference to the platform device > > - Would not break compatibility as legacy code is independent > > - Easier to understand and develop in the future > > > > Cons: > > - Initialy alienware-wmi-base.c would be almost completely legacy code, > > as new features don't require a platform device (yet), so > > alienware-wmi-base would basically just register the wmax wmi driver > > on newer machines > > - With this design users would not be able to completely exclude legacy > > code with CONFIG parameters > > I wonder if you're better off just having the legacy driver as it's own > kernel object? If it only supports a handful of systems, most people won't > need it compiled. Yes! I'd like to do this but unfortunately some user space applications might depend on attributes being available to a platform device named "alienware-wmi". This is why I wanted to have a unified "alienware-wmi" platform driver. Thank you for your feedback! > > > > > After this I want to add HWMON and sparse keymap capabilities to the > > wmax interface. > > 🎉 > > > > > I'm sure there are things I'm not seeing so feedback is greatly > > appreciated! > > > > Regards, > > Kurt >
