On Sun, Apr 21, 2024, at 1:17 PM, Mark Pearson wrote:
> Thanks Hans!
>
> On Sun, Apr 21, 2024, at 11:44 AM, Hans de Goede wrote:
>> Hi All,
>>
>> My reply in the "[PATCH v2 1/4] platform/x86: thinkpad_acpi:
>> simplify known_ev handling" handling where I indicated that I would work
>> on
On Sun, Apr 21, 2024 at 6:45 PM Hans de Goede wrote:
>
> Change the default keymap to report the correct keycodes for the volume and
> brightness keys. Reporting key events for these is already filtered out by
> the hotkey_reserved_mask which masks these keys out of hotkey_user_mask at
>
Thanks Hans!
On Sun, Apr 21, 2024, at 11:44 AM, Hans de Goede wrote:
> Hi All,
>
> My reply in the "[PATCH v2 1/4] platform/x86: thinkpad_acpi:
> simplify known_ev handling" handling where I indicated that I would work
> on converting the thinkpad_acpi hotkey handling to use sparse-keymaps
>
Switch the hotkey keymap handling over to the sparse-keymap helpers,
there should be no functional changes from this.
Note all the mappings to KEY_UNKNOWN are removed since that is the default
behavior of sparse_keymap_report_event() for unknown scancodes.
Also drop the big comment about making
The X1 carbon 2014 / 2nd gen's adaptive keyboard top row's "Home" mode,
which is 1 of the 2 modes Linux supports, has clipping-tool and cloud
buttons which so far are not mapped.
I assume these were left as KEY_RESERVED because no suitable KEY_FOO codes
were available when support was added.
In
Change the hotkey_reserved_mask initialization to hardcode the list
of reserved keys. There are only a few reserved keys and the code to
iterate over the keymap will be removed when moving to sparse-keymaps.
Signed-off-by: Hans de Goede
---
drivers/platform/x86/thinkpad_acpi.c | 21
From: Mark Pearson
New Lenovo platforms are adding the Fn + N key to generate system debug
details that support can use for collecting important details on any
customer cases for Windows.
Add the infrastructure so we can do the same on Linux by sending
a KEY_VENDOR keycode to userspace.
Move the mapping of hkey events to scancodes to tpacpi_input_send_key(),
this results in a nice cleanup and prepares things for adding sparse-keymap
support.
Signed-off-by: Hans de Goede
---
drivers/platform/x86/thinkpad_acpi.c | 81 +---
1 file changed, 24
Change the default keymap to report the correct keycodes for the volume and
brightness keys. Reporting key events for these is already filtered out by
the hotkey_reserved_mask which masks these keys out of hotkey_user_mask at
initialization time, so there is no need to also map them to
From: Mark Pearson
Lenovo trackpoints are adding the ability to generate a doubletap event.
This handles the doubletap event and sends the KEY_PROG4 event to
userspace. Despite the driver itself not using KEY_PROG1 - KEY_PROG3 this
still uses KEY_PROG4 because of some keys being remapped to
From: Mark Pearson
The hotkey combination Fn + G can be used to disable the trackpoint
doubletap feature on Windows. Add matching functionality for Linux.
Signed-off-by: Mark Pearson
Signed-off-by: Vishnu Sankar
Link: https://lore.kernel.org/r/20240417173124.9953-4-mpearson-len...@squebb.ca
From: Mark Pearson
Modify how known_ev event is handled in preparation for adding new hkey
event range.
Signed-off-by: Mark Pearson
Link: https://lore.kernel.org/r/20240417173124.9953-1-mpearson-len...@squebb.ca
Reviewed-by: Hans de Goede
Signed-off-by: Hans de Goede
---
The input core already filters out EV_KEY events for KEY_RESERVED,
remove the check for this in tpacpi_input_send_key() and rely
on the input core filtering instead.
Also change tpacpi_input_send_key() to only report the scancode
once instead of reporting it on both press and release. Together
Move hotkey_user_mask check to tpacpi_input_send_key(), this is
a preparation patch for further refactoring.
Signed-off-by: Hans de Goede
---
drivers/platform/x86/thinkpad_acpi.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
Do not send ACPI netlink events for unknown hotkeys, to avoid userspace
starting to rely on them. Instead these should be added to the keymap to
send evdev events.
This should not cause a behavior change for existing laptop models since
all currently known 0x1xxx events have a mapping.
In
Factor out the adaptive kbd non hotkey event handling into
adaptive_keyboard_change_row() and adaptive_keyboard_s_quickview_row()
helpers and move the handling of TP_HKEY_EV_DFR_CHANGE_ROW and
TP_HKEY_EV_DFR_S_QUICKVIEW_ROW to tpacpi_driver_event().
This groups all the handling of hotkey events
Both are only 1 / 2 lines and both only have 1 caller fold the contents
into tpacpi_hotkey_send_key() which is their single caller.
Signed-off-by: Hans de Goede
---
drivers/platform/x86/thinkpad_acpi.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git
All callers of tpacpi_input_send_key() first call tpacpi_driver_event(),
move the tpacpi_driver_event() inside tpacpi_input_send_key() to avoid
code duplication.
For the original hotkey codes 0x1001 - 0x1020 tpacpi_driver_event() never
returns true. So the added "return true;" inside
Modify hotkey_notify_hotkey() and it helpers to mostly directly operate
on hkey codes (TP_HKEY_EV_* returned by "MHKP") instead of on the 0 -
TPACPI_HOTKEY_MAP_LEN scancodes used for scancode -> keycode translation.
Keeping things in the hkey format as long a possible is a bit cleaner and
this
tpacpi_driver_event() already only responds to hkey events which it knows
about. Make it return a bool and return true when it has handled the event.
This avoids the need to list TP_HKEY_EV_foo values to which it responds
both in its caller and in the function itself.
Instead callers can now
Call tpacpi_driver_event() at the top of hotkey_notify_hotkey() for all
(orig / adaptive / extended) hotkey types, rather then having the orig
code path call tpacpi_input_send_key_masked() which calls it through
hotkey_driver_event() and having the adaptive / extended helpers call
it separately.
send_acpi_ev, ignore_acpi_ev are already initialized to true resp. false by
hotkey_notify() before calling the various helpers. Drop the needless
re-initialization from the helpers.
Signed-off-by: Hans de Goede
---
drivers/platform/x86/thinkpad_acpi.c | 24 +---
1 file
Use tpacpi_input_send_key() in adaptive_keyboard_hotkey_notify_hotkey()
instead of re-implementing it there.
Note this change will also result in a behavioral change, key presses on
the adaptive keyboard will now also send a EV_MSC event with the scancode,
just like all other hotkey presses
Provide a hotkey_poll_stop_sync() dummy implementation when
CONFIG_THINKPAD_ACPI_HOTKEY_POLL, so that the #ifdef-ery around
hotkey_poll_stop_sync() can be removed from hotkey_exit().
Signed-off-by: Hans de Goede
---
drivers/platform/x86/thinkpad_acpi.c | 5 +++--
1 file changed, 3
Move the special handling (send_acpi_ev = false, hotkey_source_mask check)
for original hotkeys out of the switch-case in hotkey_notify_hotkey().
This is a preparation patch for further refactoring.
Signed-off-by: Hans de Goede
---
drivers/platform/x86/thinkpad_acpi.c | 14 ++
1
hotkey_exit() already takes the mutex around the hotkey_poll_stop_sync()
call, but not around the other calls.
commit 38831eaf7d4c ("platform/x86: thinkpad_acpi: use lockdep
annotations") has added lockdep_assert_held() checks to various hotkey
functions.
These lockdep_assert_held() checks fail
Setting ignore_acpi_ev to true has the same result as setting
send_acpi_ev to false, so there is no need to have both.
Drop ignore_acpi_ev.
Signed-off-by: Hans de Goede
---
drivers/platform/x86/thinkpad_acpi.c | 56 +---
1 file changed, 17 insertions(+), 39 deletions(-)
Hi All,
My reply in the "[PATCH v2 1/4] platform/x86: thinkpad_acpi:
simplify known_ev handling" handling where I indicated that I would work
on converting the thinkpad_acpi hotkey handling to use sparse-keymaps
underestimated the work this required quite a bit.
The hotkey code is quite old and
28 matches
Mail list logo
