Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

support for kernel 6.0 #43

Closed
SacDin opened this issue Nov 21, 2022 · 33 comments
Closed

support for kernel 6.0 #43

SacDin opened this issue Nov 21, 2022 · 33 comments

Comments

@SacDin
Copy link

SacDin commented Nov 21, 2022

Hi, how to get it to work for kernel 6.0.0 ?
patch script seems to be failing with following error

patching file asus-nb-wmi.c
Hunk #1 succeeded at 545 (offset -33 lines).
Hunk #2 FAILED at 588.
Hunk #3 succeeded at 568 (offset -32 lines).
1 out of 3 hunks FAILED -- saving rejects to file asus-nb-wmi.c.rej
patching file asus-wmi.c
Hunk #1 succeeded at 29 with fuzz 2 (offset -3 lines).
Hunk #2 FAILED at 187.
Hunk #3 FAILED at 689.
Hunk #4 succeeded at 691 with fuzz 2 (offset -74 lines).
2 out of 4 hunks FAILED -- saving rejects to file asus-wmi.c.rej
@jibsaramnim
Copy link

The currently available patches are no longer compatible with Kernel 6.0 and up. I'm not the original creator of this work, but I am working on an updated patch that will support 6.0+. It's taking a bit longer than I'd like, because work and life, but I hope to have something up soon.

For now, it might be best to pin your kernel to the last 5.x release available to your distro of choice -- or be ok with not having brightness control of your secondary display.

@sanjibukai
Copy link

Yes please make it compatible with Kernel 6!

I don't know much about kernel development, but I somehow had it work in a previous installation.
Since the laptop is brand new I wanted to test any distro that will work flawlessly..
For that I tried many distros (Fedora, Manjaro, Endeavour, OpenSuse, PopOS, Mint, Ubuntu) and the closest one that worked out of the box (main issue was nvidia graphics) was Manjaro, OpenSuse and Fedora).
With Manjaro (since it's dead easy to switch kernel) at one point I managed to make it work with 5.x (don't remember the exact version) and then after having switched to kernel 6, somehow the screenpad was still here in the brightness devices 🤷‍♂️
But because of nvidia issues, I switched to Fedora and I don't know how to easily switch kernels so I did not try it.
So kernel 6 support is very welcome.
I tried to adjust the diff file of OP's patch files by looking and diffing the kernel files, but I did not yet figured out how things work..

Will be happy to help if I can (and if I found something I'll update you here).

@SacDin
Copy link
Author

SacDin commented Nov 22, 2022

@jibsaramnim that's ray of hope to hear this, I really appreciate your efforts. Like @sanjibukai I also tried to make patches to existing module but in vain. Let me know if I can be of any help.

@lwarranty
Copy link

its this type of challenge that turns many folks off, however for those wanting to dig into their systems and make it their own, it turns them on! the unfortunate reality is relying on a few ambitious talented folks to respond to each curve ball the linux kernel takes seems a short term solution, to a long term problem. in this instance i get it, the notebookk a bit of an anomoly in the dual screen and myriad of function keys, however i found little use for the dual screen in microsoft but linux wakes the beast, absolutly priceless in code, terminnals and more. drop a link, a few donations might take the edge off? excellent solution and effort, it would be nice if asus kicked down some code or in the least blobs, till then its hats off to the folks in this project - NOW to the issue - it fails on 6.0x AND the recent update to 6.0 has rendered the previously working install, useless, the module is loaded, the led asus::screenpad sys file is no longer present, i reinstalled, with 5.9x we had a working solution, upgrading to 6.0x while keeping 5.9x as backup - it borked both installations..

@jibsaramnim
Copy link

i reinstalled, with 5.9x we had a working solution, upgrading to 6.0x while keeping 5.9x as backup - it borked both installations.

You might have to specifically target whatever 5.x Kernel version you have installed to correctly (re-)build this dkms module.

In short;

  1. Either reboot into your 5.x kernel first, or manually edit the VERSION value in prepare-for-current-kernel.sh to have the major and minor (e.g. 5.19) version of your currently installed 5.x kernel.
  2. Run prepare-for-current-kernel.sh
  3. Run sudo dkms build and specifically target the 5.x kernel version you have installed. E.g. sudo dkms build -m asus-wmi -v 1.0 -k 5.19.16-200.fc36.x86_64 Be sure to look up your exact kernel version naming convention.
  4. Like above, run sudo dkms install with the exact kernel version again, e.g. sudo dkms install -m asus-wmi -v 1.0 -k 5.19.16-200.fc36.x86_64

Reboot, and you should have working brightness controls for the secondary display again :).

The updated patch I'm working on is something that hopefully could also be submitted for merging directly in the Kernel. I have not ever done this before, so there might be some caveats that would have to be considered, but my plan is to write it up with the hopes that it can be merged, and in the mean time offer it up as a patch for anyone here who wants to use it in the dkms way.

The way I'm implementing it is a little different, in that it actually shows up as display brightness controls rather than "abusing" LED functionality. This would mean the GNOME extension might need to be updated to work with this too, but the way I'm actually currently looking at implementing it, it would just natively adjust brightness of both displays at the same time when using the keyboard shortcuts -- though you do have the option of setting brightness directly through /sys/class/backlight/*.

Anyway, please let me know if the above steps worked for you to get things up and running again on your 5.x kernel! :)

@WohthaN
Copy link

WohthaN commented Nov 24, 2022

Thanks @jibsaramnim for your efforts, it's really appreciated!
I don't have kernel development experience but i'm a programmer, happy to provide
any help i can, reach out to me anytime.

@lwarranty
Copy link

lwarranty commented Nov 24, 2022 via email

@jibsaramnim
Copy link

I did in fact edit the prepare .sh file as I read it browsing thru the posts, it failed to resolve. i stripped all but the 5.19x code and it still failed.

Right, though the steps required to build for specific kernel versions also included running specific dkms build and install commands. I am not sure if you have tried those too, if you did then I apologize for misunderstanding your message :).

Somewhat related, two questions for everyone here: May I ask what Linux flavor you are running, and whether you have experience or familiarity with building and installing your own Kernel for said Linux flavor?

@WohthaN
Copy link

WohthaN commented Nov 28, 2022

@jibsaramnim: i'm on debian. Used to be able to compile and install a kernel, didn't do it in a while though...

@macbrownzie
Copy link

I sincerely APPRECIATE all the efforts that people are making to get (keep) this hardware working with the new Linux Kernel, and I LOVE the idea that under 6.0 it could possibly be both merged into the mainline kernel AND that it might work with the native brightness controls. :) That would be EXCELLENT.

I also very much believe that even in open-source (or maybe especially in open-source) people should be rewarded for their contributions, SO.... how would you all like to structure that? Is there an on-line crowd-source funding solution that would work, or should we do some kind of bounty system? Plippo, this is your project, what would you like to see?

@zardoz99
Copy link

zardoz99 commented Dec 6, 2022

I updated the patch to apply to 6.0.11 but it no longer works.

The kernel routine "egpu_enable_store()" that used to get things started is no longer called anywhere.

I guess this needs a rethink...

@SacDin
Copy link
Author

SacDin commented Dec 6, 2022

As a temporary solution, @Plippo's original solution is always available as explained here : s-light/ASUS-ZenBook-Pro-Duo-UX581GV#1 (comment) and does not require to build kernel module as it use acpi_call module directly.

With this, I am able to control brightness on 6.0.0 manually with commands. Setting is static as startup works for me as I do not need to change it often. I mainly use bottom screen for terminals.

@sanjibukai
Copy link

As a temporary solution, @Plippo's original solution is always available as explained here : s-light/ASUS-ZenBook-Pro-Duo-UX581GV#1 (comment) and does not require to build kernel module as it use acpi_call module directly.

With this, I am able to control brightness on 6.0.0 manually with commands. Setting is static as startup works for me as I do not need to change it often. I mainly use bottom screen for terminals.

Oh.. Seriously?
In my case it's totally fine to do it that way, as long as it works.

Do you know if this will work as is with a zenbook duo 15" (UX582). I mean in here echo '\_SB.ATKD.WMNB 0x0 0x53564544 b32000500xx000000' | sudo tee /proc/acpi/call does those values depend on the hardware?

I guess it's not harmful if I try it...

@SacDin
Copy link
Author

SacDin commented Dec 7, 2022 •
edited

As a temporary solution, @Plippo's original solution is always available as explained here : s-light/ASUS-ZenBook-Pro-Duo-UX581GV#1 (comment) and does not require to build kernel module as it use acpi_call module directly.
With this, I am able to control brightness on 6.0.0 manually with commands. Setting is static as startup works for me as I do not need to change it often. I mainly use bottom screen for terminals.

Oh.. Seriously? In my case it's totally fine to do it that way, as long as it works.

Do you know if this will work as is with a zenbook duo 15" (UX582). I mean in here echo '\_SB.ATKD.WMNB 0x0 0x53564544 b32000500xx000000' | sudo tee /proc/acpi/call does those values depend on the hardware?

I guess it's not harmful if I try it...

Not sure if it works for UX582, may be you can try and provide feedback so we all can know. I am using this for UX481 (14 inch LCD variant) and working without any problem on 6.0.0 kernel.

As long as it is LCD, it does not seem harmful to the hardware to me in any way. If yours is OLED, I suggest not to set full brightness and do not keep static content on it for long. But as OLED burn in is fully different issue and there are ways to mitigate it, you can try this solution and see if works to control brightness at least.

As @Plippo's original comment was for UX581, I guess it works for UX581. For UX582 having OLED, it may require different value in command as per hardware but we can be sure of that only after trying. Did this dkms module work for you on 5.x kernels ? If yes, there are chances it is using same value or we can get that value from this repo itself.

@WohthaN
Copy link

WohthaN commented Dec 7, 2022

It works fine in my UX582ZM. Actually, it has a desirable feature wrt the leds interface:
when you set it to zero luminosity, it turns off but doesn't report to the OS, so
your windows don't get repositioned (which is great, imho as expected from a laptop screen,
0 luminosity should not correspond to 'disconnected monitor').
Max value corresponds to max value using leds interface.

@Plippo Would there be a way to read the current value through acpi commands? If yes, we (I) could
replicate the existing shell script to set luminosity using the acpi interface, to get at least a working temporary solution while a proper one is worked on...

@sanjibukai
Copy link

It works fine in my UX582ZM. Actually, it has a desirable feature wrt the leds interface: when you set it to zero luminosity, it turns off but doesn't report to the OS, so your windows don't get repositioned (which is great, imho as expected from a laptop screen, 0 luminosity should not correspond to 'disconnected monitor'). Max value corresponds to max value using leds interface.

@Plippo Would there be a way to read the current value through acpi commands? If yes, we (I) could replicate the existing shell script to set luminosity using the acpi interface, to get at least a working temporary solution while a proper one is worked on...

Oh that's cool indeed.
May I ask you which distro you're using?

I'm using Fedora, and I didn't succeed to have acpi_call installed..

I tried compiling from source various repo (forked from each others). None of them worked.

@sanjibukai
Copy link

As a temporary solution, @Plippo's original solution is always available as explained here : s-light/ASUS-ZenBook-Pro-Duo-UX581GV#1 (comment) and does not require to build kernel module as it use acpi_call module directly.
With this, I am able to control brightness on 6.0.0 manually with commands. Setting is static as startup works for me as I do not need to change it often. I mainly use bottom screen for terminals.

Oh.. Seriously? In my case it's totally fine to do it that way, as long as it works.
Do you know if this will work as is with a zenbook duo 15" (UX582). I mean in here echo '\_SB.ATKD.WMNB 0x0 0x53564544 b32000500xx000000' | sudo tee /proc/acpi/call does those values depend on the hardware?
I guess it's not harmful if I try it...

Not sure if it works for UX582, may be you can try and provide feedback so we all can know. I am using this for UX481 (14 inch LCD variant) and working without any problem on 6.0.0 kernel.

As long as it is LCD, it does not seem harmful to the hardware to me in any way. If yours is OLED, I suggest not to set full brightness and do not keep static content on it for long. But as OLED burn in is fully different issue and there are ways to mitigate it, you can try this solution and see if works to control brightness at least.

As @Plippo's original comment was for UX581, I guess it works for UX581. For UX582 having OLED, it may require different value in command as per hardware but we can be sure of that only after trying. Did this dkms module work for you on 5.x kernels ? If yes, there are chances it is using same value or we can get that value from this repo itself.

Will definitely update if it works. But I'm not able to get acpi_call in Fedora.. Which is a pity..

@SacDin
Copy link
Author

SacDin commented Dec 7, 2022

@sanjibukai oh, wasn't that hard for me in debian bullseye. which version of fedora are you using ?

@yuiiio
Copy link

yuiiio commented Dec 11, 2022

I rebased for kernel 6.1-rc

diff --git a/asus-wmi.c b/asus-wmi.c
index eec7d0e..b1f375c 100644
--- a/asus-wmi.c
+++ b/asus-wmi.c
@@ -29,6 +29,7 @@
 #include <linux/pci.h>
 #include <linux/pci_hotplug.h>
 #include <linux/platform_data/x86/asus-wmi.h>
+#include "inc/asus-wmi.h"
 #include <linux/platform_device.h>
 #include <linux/platform_profile.h>
 #include <linux/power_supply.h>
@@ -208,11 +209,14 @@ struct asus_wmi {
 	int kbd_led_wk;
 	struct led_classdev lightbar_led;
 	int lightbar_led_wk;
+	struct led_classdev screenpad_led;
+	int screenpad_led_wk;
 	struct led_classdev micmute_led;
 	struct workqueue_struct *led_workqueue;
 	struct work_struct tpd_led_work;
 	struct work_struct wlan_led_work;
 	struct work_struct lightbar_led_work;
+	struct work_struct screenpad_led_work;

 	struct asus_rfkill wlan;
 	struct asus_rfkill bluetooth;
@@ -1039,6 +1043,75 @@ static int micmute_led_set(struct led_classdev *led_cdev,
 	return err < 0 ? err : 0;
 }

+static int screenpad_led_read(struct asus_wmi *asus, int *level)
+{
+	int value, retval;
+	retval = asus_wmi_get_devstate(asus, ASUS_WMI_DEVID_SCREENPAD, &value);
+	if (retval == 0 && (value & 0x1) == 0x1)
+	{
+		// screen is activated, so read backlight
+		retval = asus_wmi_get_devstate(asus, ASUS_WMI_DEVID_SCREENPAD_LIGHT, &value);
+		if (retval == 0)
+		{
+			*level = value & ASUS_WMI_DSTS_BRIGHTNESS_MASK;
+		}
+	}
+	else
+	{
+		*level = 0;
+	}
+
+	if (retval < 0)
+		return retval;
+	return 0;
+}
+
+static void screenpad_led_update(struct work_struct *work)
+{
+	struct asus_wmi *asus;
+	int ctrl_param;
+
+	asus = container_of(work, struct asus_wmi, screenpad_led_work);
+
+	ctrl_param = asus->screenpad_led_wk;
+	if (ctrl_param == 0x00)
+	{
+		// turn off screen
+		asus_wmi_set_devstate(ASUS_WMI_DEVID_SCREENPAD, ctrl_param, NULL);
+	}
+	else
+	{
+		// set backlight (also turns on screen if is off)
+		asus_wmi_set_devstate(ASUS_WMI_DEVID_SCREENPAD_LIGHT, ctrl_param, NULL);
+	}
+}
+
+static void screenpad_led_set(struct led_classdev *led_cdev,
+			     enum led_brightness value)
+{
+	struct asus_wmi *asus;
+
+	asus = container_of(led_cdev, struct asus_wmi, screenpad_led);
+
+	asus->screenpad_led_wk = value;
+	queue_work(asus->led_workqueue, &asus->screenpad_led_work);
+}
+
+static enum led_brightness screenpad_led_get(struct led_classdev *led_cdev)
+{
+	struct asus_wmi *asus;
+	int retval, value;
+
+	asus = container_of(led_cdev, struct asus_wmi, screenpad_led);
+
+	retval = screenpad_led_read(asus, &value);
+	if (retval < 0)
+		return retval;
+
+	return value;
+}
+
+
 static void asus_wmi_led_exit(struct asus_wmi *asus)
 {
 	led_classdev_unregister(&asus->kbd_led);
@@ -1046,6 +1119,7 @@ static void asus_wmi_led_exit(struct asus_wmi *asus)
 	led_classdev_unregister(&asus->wlan_led);
 	led_classdev_unregister(&asus->lightbar_led);
 	led_classdev_unregister(&asus->micmute_led);
+	led_classdev_unregister(&asus->screenpad_led);

 	if (asus->led_workqueue)
 		destroy_workqueue(asus->led_workqueue);
@@ -1130,6 +1204,20 @@ static int asus_wmi_led_init(struct asus_wmi *asus)
 			goto error;
 	}

+	if (asus_wmi_dev_is_present(asus, ASUS_WMI_DEVID_SCREENPAD)
+		&& !screenpad_led_read(asus, &led_val)) {
+		asus->screenpad_led_wk = led_val;
+		INIT_WORK(&asus->screenpad_led_work, screenpad_led_update);
+
+		asus->screenpad_led.name = "asus::screenpad";
+		asus->screenpad_led.brightness_set = screenpad_led_set;
+		asus->screenpad_led.brightness_get = screenpad_led_get;
+		asus->screenpad_led.max_brightness = 0xff;
+
+		rv = led_classdev_register(&asus->platform_device->dev,
+					   &asus->screenpad_led);
+	}
+
 error:
 	if (rv)
 		asus_wmi_led_exit(asus);

@lwarranty
Copy link

I rebased for kernel 6.1-rc

It's a homerun - awesome and thanks to all!

@Plippo
Copy link
Owner

Plippo commented Dec 11, 2022

Hi everyone, I'm sorry I couldn't contribute earlier as I was on vacation.
Thank you @yuiiio for your work! If it's okay for you, I'd add your patch to the repo so the script automatically chooses it for 6.x kernels.

@Plippo
Copy link
Owner

Plippo commented Dec 11, 2022

Would there be a way to read the current value through acpi commands?

It's possible, but it's a bit of a nuisance. In the acpi_call command, you have to replace 0x53564544 by 0x53545344, like this:

echo '\_SB.ATKD.WMNB 0x0 0x53545344 b3200050000000000' > /proc/acpi/call

After calling this, you can now read the return value from /proc/acpi/call, like this:

cat /proc/acpi/call
echo ' '

@yuiiio
Copy link

yuiiio commented Dec 11, 2022

@Plippo Ok! thanks your work.
but, maybe fail 6.0 kernel to apply that patch.
because asus-wmi.c was changed on 6.1-rc*.

@Plippo
Copy link
Owner

Plippo commented Dec 11, 2022

I was able to create a patch for 6.0 based on yours @yuiiio
I added it to the script. Would be great if someone using kernel 6.0 could test it so we can close this issue.

@lwarranty
Copy link

lwarranty commented Dec 11, 2022 •
edited

Both Fedora 37 and Arch - not happy with 6.0x patch, seem to compile fine, installs the module, reboot but no /sys/class/leds/*screenpad on either platform - fresh installs... Works great on 5.x kernels - equipment Zephyrus GX650RX Duo Linux 6.0.12-300.fc37.x86_6 Linux Won't be on the ground for a few hours - can't offer much more at this time... Secure and Fastboot off in addition previous kernels / screenpad installs work fine...

@hashcheck01
Copy link

hashcheck01 commented Dec 12, 2022 •
edited

Fedora 37 with 6.1.0-0.rc8.20221209git0d1409e4ff08.62.vanilla.1.fc37 Kernel Vanilla Repo
Worked perfectly with your patch. Thanks for uploading fix for merging this repo so quickly, I wrote my own prior to this.
Asus Zenbook Duo 14"

@SacDin
Copy link
Author

SacDin commented Dec 12, 2022

patch script seems to fail on debian with 6.0.0 with following error

patching file asus-nb-wmi.c
patching file asus-wmi.c
rm: cannot remove '*.orig': No such file or directory

@Plippo
Copy link
Owner

Plippo commented Dec 12, 2022

patch script seems to fail on debian with 6.0.0 with following error

patching file asus-nb-wmi.c
patching file asus-wmi.c
rm: cannot remove '*.orig': No such file or directory

That is okay, the error only happens when trying to clean up, the script should run fine anyway.

@lwarranty
Copy link

Both Fedora 37 and Arch - not happy with 6.0x patch, seem to compile fine, installs the module, reboot but no /sys/class/leds/*screenpad on either platform - fresh installs... Works great on 5.x kernels - equipment Zephyrus GX650RX Duo Linux 6.0.12-300.fc37.x86_6 Linux Won't be on the ground for a few hours - can't offer much more at this time... Secure and Fastboot off in addition previous kernels / screenpad installs work fine...

Upgraded kennel to 6.1x and similar result, no sys/class/asus::screenpad using the script everything seemed to be fine however I found the module installed but not enabled, I went manually removing the module, reinstalled from src, updated dkms, installed module, initramfs and it works great, not sure why but it seems the process of dkms and initramfs are where the challenges were, this is fresh install arch 6

@zardoz99
Copy link

As I explained previously in #43 (comment) the routine the initializes the code no longer is called by anywhere in the kernel. Therefore the patch, even if it's in place, does not get activated.

@jibsaramnim
Copy link

jibsaramnim commented Dec 13, 2022 •
edited

Can you try this patch and see if this works on your system? I was able to get it to build and run fine on my UX482EA running Fedora 37 (Workstation), using the as of right now recent-most Rawhide kernel release (6.1.0-0.rc8).

Note that this is based off of the above shared patch, and not the cleanest of implementations; it could still fail to initialize the screenpad bits if asus_wmi_led_init fails on your particular model for whatever reason.

Edit: removed my patch as it's unnecessary.

@Plippo
Copy link
Owner

Plippo commented Dec 13, 2022

As I explained previously in #43 (comment) the routine the initializes the code no longer is called by anywhere in the kernel. Therefore the patch, even if it's in place, does not get activated.

I don't see why that function should be of any relevance to this. The initialization is called by asus_wmi_register_driver which initializes all the WMI access and has nothing to do with any function called egpu_enable_store. It has been reported here in more than one comment that the patch works in 6.1 (after solving some module/dkms related problems) and it should work in 6.0 too, thus code is obviously still called by the kernel.

@SacDin
Copy link
Author

SacDin commented Dec 13, 2022

patch script seems to fail on debian with 6.0.0 with following error

patching file asus-nb-wmi.c
patching file asus-wmi.c
rm: cannot remove '*.orig': No such file or directory

That is okay, the error only happens when trying to clean up, the script should run fine anyway.

@Plippo Indeed that worked despite of cleanup error. Thank you, your great work prevails once again. Working perfectly fine on 6.0.0 with debian bullseye.

@SacDin SacDin closed this as completed Dec 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
10 participants
@jibsaramnim @Plippo @zardoz99 @WohthaN @SacDin @hashcheck01 @sanjibukai @macbrownzie @yuiiio @lwarranty