On Mon, 2024-04-08 at 18:23 +0300, Mustafa Ekşi wrote: > On 7.04.2024 03:57, Stella Bloom wrote: >>> From: Mustafa Ekşi <mustafa.eskieksi@xxxxxxxxx> >>> >>> Hi, >>> I want to note that moving mutex_init to the bottom of the function >>> crashes the driver when mutex_lock is called. I didn't investigate it >>> further but I wanted to say that since Ai Chao also did it like that. >>> >>> Driver sets all leds to white on start. Before that, when a led's >>> brightness is changed, that led's color gets set to white but others >>> keep their old colors which creates a bad user experience (at least for >>> me). Please inform me if this is a bad approach. >>> Also, this driver still lacks support for changing modes and I seek >>> advise for that. >>> >>> Mustafa Ekşi (1): >>> platform/x86: Add wmi driver for Casper Excalibur laptops >>> >>> MAINTAINERS | 6 + >>> drivers/platform/x86/Kconfig | 14 + >>> drivers/platform/x86/Makefile | 1 + >>> drivers/platform/x86/casper-wmi.c | 641 ++++++++++++++++++++++++++++++ >>> 4 files changed, 662 insertions(+) >>> create mode 100644 drivers/platform/x86/casper-wmi.c >>> >> Hi there, >> >> I just wanted to pitch in by testing the driver on the kernel I use >> on my Arch install on an Excalibur G770.1245, namely xdevs23's >> linux-nitrous (https://gitlab.com/xdevs23/linux-nitrous), but trying to >> compile the driver using LLVM, which is the default compilation behavior >> in this kernel's AUR package, spits out the following error; >> ``` >> drivers/platform/x86/casper-wmi.c:633:3: error: field designator 'no_singleton' does not refer to any field in type 'struct wmi_driver' >> 633 | .no_singleton = true, >> | ~^~~~~~~~~~~~~~~~~~~ >> 1 error generated. >> make[5]: *** [scripts/Makefile.build:243: drivers/platform/x86/casper-wmi.o] Error 1 >> make[4]: *** [scripts/Makefile.build:481: drivers/platform/x86] Error 2 >> make[3]: *** [scripts/Makefile.build:481: drivers/platform] Error 2 >> make[2]: *** [scripts/Makefile.build:481: drivers] Error 2 >> make[1]: *** [/home/stella/.cache/yay/linux-nitrous/src/linux-nitrous/Makefile:1919: .] Error 2 >> make: *** [Makefile:240: __sub-make] Error 2 >> ``` >> >> I want to help debug this somehow, but I'm more of an Android custom >> ROM developer than a Linux kernel maintainer, so my knowledge on the >> programming and build system languages other than Java, Makefile, Bash, >> etc is pretty much limited if not outright non-existent. > Hi, > This is because of a newly merged patch from Armin Wolf: > https://lore.kernel.org/platform-driver-x86/20240226193557.2888-2-W_Armin@xxxxxx/ > You can comment that line or apply that patch to your tree to make it > compile. Also, you'll probablyneed to change the call to wmidev_block_set in > casper_query function with wmi_set_block (which is now deprecated). Well, I prefer not to touch the driver itself, so I already resorted to picking the patch over the latest RC, which is v6.9-rc2 as of now, and got onto compiling `linux-mainline` AUR package with it. It will be kind of a hassle considering how I have to write systemd-boot entries after the installation to get the kernel to appear (one for normal initramfs and the other for fallback one) and sign the kernel image using `sbctl` so I don't fail secure boot, but I'm willing to go through it just for the sake of seeing this driver in action without bugs related to the "backport" modifications I would do to it. >> I would *love* to see this driver actually hit mainline repos, and >> eventually the upcoming kernel releases, given how much I need to use >> this laptop of mine as a computer engineering student. >> >> Asking just for the case I manage to get this driver up and going on >> my end somehow: Is there a tool made for controlling the LED colors yet? >> I can still use CLI tools much like on ASUS ROG series laptops, but it >> would be much easier and more appreciated to have a GUI provided >> Excalibur series laptops' LED lights can virtually take any color in >> the RGB space - At least that's how I interpreted with the >> configurations I used to do on mine using Excalibur Control Center >> on Windows 10/11. > No, there isn't a tool yet but controlling leds via sysfs ispretty easy. > For example, if you wanted to change the left led zone's color to red: > ``` > # echo 0xff0000 > /sys/class/leds/casper\:\:kbd_zoned_backlight-left/multi_intensity > ``` Oh so the LED zones are in different sysfs directories, that's pretty good. I might code a simple Bash script to make things easier later down the road. > And don't forget that all leds' initial brightnesses are 0. Yeah I think I read that somewhere in the initial message. Can't I change the brightness of the LEDs using Fn+Space anyway if I can't find the sysfs entries for that? At least it works just fine on the latest stable release - v6.8.4. > Also, I'm planning to add support for this API in OpenRGB. That's pretty nice to hear! If you need someone to test it out on a 12th gen G770, I'm more than willing to do so! >> And as for the profiles, let me make sure we're talking about the same >> thing in this term: You're talking about the "Office", "Gaming" and >> "High Performance" modes as seen in Excalibur Control Center, right? > For laptops with 11th gen processors or newer: yes. > For laptops with 10th gen processors or older: no, there are 4 power > profiles for these laptops (High Performance, Gaming, Text Mode andPower > save). Oh so that's a yes in my case as my laptop has a 12th gen processor. Glad to know. >> If so, can this be somehow integrated into `power-profiles-daemon` >> SystemD service for easier controlling with GNOME and other DEs that >> use it? It's fine if it can't be, this was just a thought struck on my >> mind for whatever reason. > Yes, power-profiles-daemon is already integrated with platform_profile. Now that's exciting to hear. I haven't seen a laptop that has its power profiles integrated into the system with a driver in terms of Linux... At least on the Monster and ASUS laptops I've tried Ubuntu on IIRC. >> Please do CC me and the people I've added to the CC list with this email >> of mine on the upcoming revisions, if any. We would love to keep track >> of this driver and I personally would love to contribute into testing >> as a power user. >> >> Cc: Alviro Iskandar Setiawan <alviro.iskandar@xxxxxxxxxxx> >> Cc: Ammar Faizi <ammarfaizi2@xxxxxxxxxxx> >> Cc: GNU/Weeb Mailing List <gwml@xxxxxxxxxxxxxxxx> >> >> Also adding my organizational and school email addresses to the CC list >> so I can still be notified while I stay offline on this email address. >> GNOME Evolution doesn't run in the background and periodically check >> for emails sadly, and I switch ROMs every now and then on my phone as a >> source maintainer of 3 different custom ROMs. :/ >> >> Cc: Stella Bloom <stelbl@xxxxxxxxxxx> >> Cc: Bedirhan KURT <bedirhan_kurt22@xxxxxxxxxxxxxx> >> >> -- >> Stella Bloom > Thanks for your interest, > Mustafa Ekşi Also I apologize for the previous (empty) email. I forgot to put one newline after the "Subject" line, which caused git-send-email to not pick up the email content. -- Stella Bloom
