| Message ID | 20240324181201.87882-1-mustafa.eskieksi@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | platform/x86: Add wmi driver for Casper Excalibur laptops | expand |
Am 24.03.24 um 19:12 schrieb mustafa: > From: Mustafa Ekşi <mustafa.eskieksi@gmail.com> > > 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. You mean like the lenovo-wmi-camera driver? In this case, the driver was only using the mutex inside the WMI notify callback, which can only run once the driver has finished probing. In your case however, the mutex can already be used while the driver is still probing, because it registers callbacks with other subsystems. The subsystem (maybe led?) assumes that the device is already fully operational and will begin calling the callbacks immediately, causing a crash. Looking at the code, it seems that you are not calling mutex_destroy() in casper_wmi_remove(). I suggest to use devm_add_action_or_reset() for handling this. Thanks, Armin Wolf > 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 >
> From: Mustafa Ekşi <mustafa.eskieksi@gmail.com> > > 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. 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. 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? 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. 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@gnuweeb.org> Cc: Ammar Faizi <ammarfaizi2@gnuweeb.org> Cc: GNU/Weeb Mailing List <gwml@vger.gnuweeb.org> 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@elrant.team> Cc: Bedirhan KURT <bedirhan_kurt22@erdogan.edu.tr> -- Stella Bloom
On 7.04.2024 03:57, Stella Bloom wrote: >> From: Mustafa Ekşi <mustafa.eskieksi@gmail.com> >> >> 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@gmx.de/ 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). > 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 ``` And don't forget that all leds' initial brightnesses are 0. Also, I'm planning to add support for this API in OpenRGB. > 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). > 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. > 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@gnuweeb.org> > Cc: Ammar Faizi <ammarfaizi2@gnuweeb.org> > Cc: GNU/Weeb Mailing List <gwml@vger.gnuweeb.org> > > 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@elrant.team> > Cc: Bedirhan KURT <bedirhan_kurt22@erdogan.edu.tr> > > -- > Stella Bloom Thanks for your interest, Mustafa Ekşi
-- Stella Bloom
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@gmail.com> >>> >>> 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@gmx.de/ > 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@gnuweeb.org> >> Cc: Ammar Faizi <ammarfaizi2@gnuweeb.org> >> Cc: GNU/Weeb Mailing List <gwml@vger.gnuweeb.org> >> >> 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@elrant.team> >> Cc: Bedirhan KURT <bedirhan_kurt22@erdogan.edu.tr> >> >> -- >> 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
Am 08.04.24 um 18:13 schrieb Stella Bloom: > 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@gmail.com> >>>> >>>> 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@gmx.de/ >> 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. Hi, if you use kernel 6.9-rc2, then wmidev_block_set() is already available, so you do not have to change that. You just have to comment out the line with the no_singleton flag, then the driver should work. Thanks, Armin Wolf >>> 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@gnuweeb.org> >>> Cc: Ammar Faizi <ammarfaizi2@gnuweeb.org> >>> Cc: GNU/Weeb Mailing List <gwml@vger.gnuweeb.org> >>> >>> 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@elrant.team> >>> Cc: Bedirhan KURT <bedirhan_kurt22@erdogan.edu.tr> >>> >>> -- >>> 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 >
> Am 08.04.24 um 18:13 schrieb Stella Bloom: > >> 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@gmail.com> >>>>> >>>>> 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@gmx.de/ >>> 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. > > Hi, > > if you use kernel 6.9-rc2, then wmidev_block_set() is already available, so you do not > have to change that. > > You just have to comment out the line with the no_singleton flag, then the driver should > work. Hi, Thanks for letting me know of that. I'm doing the change locally right away. > Thanks, > Armin Wolf > >>>> 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@gnuweeb.org> >>>> Cc: Ammar Faizi <ammarfaizi2@gnuweeb.org> >>>> Cc: GNU/Weeb Mailing List <gwml@vger.gnuweeb.org> >>>> >>>> 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@elrant.team> >>>> Cc: Bedirhan KURT <bedirhan_kurt22@erdogan.edu.tr> >>>> >>>> -- >>>> 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 -- Stella Bloom
From: Mustafa Ekşi <mustafa.eskieksi@gmail.com> 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