From: Denis Benato <denis.benato@linux.dev>
To: Victor <victor.gillholm@gmail.com>
Cc: corentin.chary@gmail.com, luke@ljones.dev, hansg@kernel.org,
ilpo.jarvinen@linux.intel.com,
platform-driver-x86@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] platform/x86: asus-nb-wmi: map ScreenPad and Task Swap keys
Date: Sun, 18 Oct 2026 22:05:07 +0200 [thread overview]
Message-ID: <ddf53c75-80bb-43f6-9e48-629b49a6339b@linux.dev> (raw)
In-Reply-To: <CAKspSoNJxEcEH1AwXHyNY5cWVvCQ3LN0fcZ8d9ajAoShdBMRKg@mail.gmail.com>
On 10/18/26 21:25, Victor wrote:
> On 10/18/26 20:02, Denis Benato wrote:
>> The driver is handling the screenpad so why not implementing the
>> functionality in the driver instead of doing the dance driver -> evdev
>> -> remap -> driver ?
>>
>> Unless I misunderstood what you want to do... Hopefully not!
> Hi Denis,
>
> Thanks for looking at this.
>
> Handling it in the driver would work, but the key would then only be an
> on/off switch for the ScreenPad. If I remember correctly, on Windows the
> same key cycled between modes: on, off, and using the ScreenPad as a
> touchpad. If the driver toggles the power on every press, userspace
> cannot do that, because the panel is already switched off before it
> sees the key.
>
> Reporting the key as KEY_F13 allows both. Users who only want on/off can
> bind it to the asus_screenpad backlight device, so the power control
> still goes through the driver, and others can use it to switch modes.
>
> It also matches hid-asus, which already reports the same ScreenPad code
> 0x6a as KEY_F13.
Alright, I see what's going on. Then yeah I agree with this decision.
My remaining question is if that screenpad-as-touchpad is fully
software emulation (like dialpad on newer models) or is actually
something different that can be made in driver... I think I can see
some code using hidraw to send special commands to screenpad
and I really want that inside the kernel...
If it can be made in a driver that would be preferable. Guess I will
need to take a look at asus_screenpad... Can you point me at the
correct repo?
> While testing this I also found that the ScreenPad power control looks
> inverted on this model (UX482EG, stock asus-wmi on 7.2.5). Writing 0
> (power on) to /sys/class/backlight/asus_screenpad/bl_power switches the
> panel off, about three seconds later its DRM connector reports
> disconnected, and writing 4 (power off) brings it back. The result was
> the same each time I tried. While the panel is off, actual_brightness
> still reads 89, so the firmware seems to report it as powered. I can
> look into that separately if it is useful.
>
I am very familiar with this issue. I was hoping to never read this, but
apparently the moment has come.
Please take a look at the link below and all links you find to reconstruct
the story about the current code of power handling.
Link: https://lore.kernel.org/all/20260916143838.170950-1-denis.benato@linux.dev/
You will need to create a quirk for handling inverted power states and
add that quirk to your laptop using a dmi match to get things working.
Before doing anything please be absolutely sure you are running a kernel
with that patch series included or you will see the same "inverted" issue
after inverting the bit only to chase a ghost issue wasting a lot of your time.
>>> + { KE_KEY, 0x9C, { KEY_F14 } }, /* Task Swap key on Zenbook Duo */
>> Fair.
> Thanks.
>
> Best regards,
> Victor
>
>
> Den sön 18 okt. 2026 kl 20:02 skrev Denis Benato <denis.benato@linux.dev>:
>>
>> On 10/17/26 20:13, Victor Gillholm via B4 Relay wrote:
>>> From: Victor Gillholm <victor.gillholm@gmail.com>
>>>
>>> The ASUS Zenbook Duo 14 UX482EG has two keys next to the power button:
>>> one toggles the ScreenPad Plus, the second screen above the keyboard,
>>> and one swaps windows between the two screens (Task Swap in ASUS'
>>> ScreenXpert software). They emit ASUS WMI event codes 0x6a and 0x9c.
>>> Neither code is in the asus-nb-wmi sparse keymap, so pressing them only
>>> logs "Unknown key code 0x6a" or "Unknown key code 0x9c", and both keys
>>> are reported as KEY_UNKNOWN, so ordinary desktop key bindings cannot
>>> tell them apart.
>>>
>>> Map 0x6a to KEY_F13, the same keycode hid-asus already uses for the
>>> ScreenPad toggle code 0x6a. No existing keycode describes moving windows
>>> between screens, so map 0x9c to KEY_F14, following the existing use of
>>> KEY_F13 and KEY_F14 for other ASUS-specific keys in this keymap. Both
>>> keys then emit distinct, bindable events.
>>>
>>> Tested on an ASUS Zenbook Duo 14 UX482EG: with this change the keys
>>> arrive in userspace as KEY_F13 and KEY_F14 and the "Unknown key code"
>>> messages are gone.
>>>
>>> Assisted-by: Claude:claude-opus-5-5
>>> Signed-off-by: Victor Gillholm <victor.gillholm@gmail.com>
>>> ---
>>> Tested by building asus-nb-wmi against 7.2.5 and loading it in place of
>>> the stock module. The key mapping was checked with wev: before the change
>>> both keys arrived as keycode 248 with no keysym, after it as XF86Tools
>>> (KEY_F13) and XF86Launch5 (KEY_F14).
>>> ---
>>> drivers/platform/x86/asus-nb-wmi.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/platform/x86/asus-nb-wmi.c b/drivers/platform/x86/asus-nb-wmi.c
>>> index 3b0f3346d..c6eb525ec 100644
>>> --- a/drivers/platform/x86/asus-nb-wmi.c
>>> +++ b/drivers/platform/x86/asus-nb-wmi.c
>>> @@ -641,6 +641,7 @@ static const struct key_entry asus_nb_wmi_keymap[] = {
>>> { KE_KEY, 0x65, { KEY_SWITCHVIDEOMODE } }, /* SDSP LCD + TV */
>>> { KE_KEY, 0x66, { KEY_SWITCHVIDEOMODE } }, /* SDSP CRT + TV */
>>> { KE_KEY, 0x67, { KEY_SWITCHVIDEOMODE } }, /* SDSP LCD + CRT + TV */
>>> + { KE_KEY, 0x6A, { KEY_F13 } }, /* ScreenPad toggle on Zenbook Duo */
>> Hi Victor,
>>
>> The driver is handling the screenpad so why not implementing the functionality in
>> the driver instead of doing the dance driver -> evdev -> remap -> driver ?
>>
>> Unless I misunderstood what you want to do... Hopefully not!
>>
>>> { KE_KEY, 0x6B, { KEY_TOUCHPAD_TOGGLE } },
>>> { KE_IGNORE, 0x6E, }, /* Low Battery notification */
>>> { KE_KEY, 0x71, { KEY_F13 } }, /* General-purpose button */
>>> @@ -666,6 +667,7 @@ static const struct key_entry asus_nb_wmi_keymap[] = {
>>> { KE_KEY, 0x93, { KEY_SWITCHVIDEOMODE } }, /* SDSP LCD + CRT + TV + DVI */
>>> { KE_KEY, 0x95, { KEY_MEDIA } },
>>> { KE_KEY, 0x99, { KEY_PHONE } }, /* Conflicts with fan mode switch */
>>> + { KE_KEY, 0x9C, { KEY_F14 } }, /* Task Swap key on Zenbook Duo */
>> Fair.
>>
>> Best regards,
>> Denis Benato
>>
>>> { KE_KEY, 0X9D, { KEY_FN_F } },
>>> { KE_KEY, 0xA0, { KEY_SWITCHVIDEOMODE } }, /* SDSP HDMI only */
>>> { KE_KEY, 0xA1, { KEY_SWITCHVIDEOMODE } }, /* SDSP LCD + HDMI */
>>>
>>> ---
>>> base-commit: ea40f1e9f07aab937b9a217633be7a1f66260394
>>> change-id: 20261017-zenbook-duo-keys-7e0b3f94354a
>>>
>>> Best regards,
>>> --
>>> Victor Gillholm <victor.gillholm@gmail.com>
>>>
>>>
next prev parent reply other threads:[~2026-10-18 20:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-17 18:13 Victor Gillholm via B4 Relay
2026-10-18 18:02 ` Denis Benato
2026-10-18 19:25 ` Victor
2026-10-18 20:05 ` Denis Benato [this message]
2026-10-19 14:48 ` Victor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ddf53c75-80bb-43f6-9e48-629b49a6339b@linux.dev \
--to=denis.benato@linux.dev \
--cc=corentin.chary@gmail.com \
--cc=hansg@kernel.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luke@ljones.dev \
--cc=platform-driver-x86@vger.kernel.org \
--cc=victor.gillholm@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®