mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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>
>>>
>>>

  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®