The recent platform profile changes prevent the tpacpi platform driver
from registering. This error is seen in the kernel logs, and the
various tpacpi entries are not created:
[ 7550.642171] platform thinkpad_acpi: Resources present before probing
This happens because devm_platform_profile_register() is called before
tpacpi_pdev probes (thanks to Kurt Borja for identifying the root
cause).
For now revert back to the old platform_profile_register to fix the
issue. This is quick fix and will be re-implemented later as more
testing is needed for full solution.
Tested on X1 Carbon G12.
Fixes: 31658c916f ("platform/x86: thinkpad_acpi: Use devm_platform_profile_register()")
Signed-off-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Reviewed-by: Kurt Borja <kuurtb@gmail.com>
Link: https://lore.kernel.org/r/20250211173620.16522-1-mpearson-lenovo@squebb.ca
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The F11 key on the new Lenovo Thinkpad T14 Gen 5, T16 Gen 3, and P14s
Gen 5 laptops includes a symbol showing a smartphone and a laptop
chained together. According to the user manual, it starts the Microsoft
Phone Link software used to connect to Android/iOS devices and relay
messages/calls or sync data.
These laptops send the 0x1320 hkey event when the key is pressed. Map
this event to the new KEY_LINK_PHONE keycode.
Signed-off-by: Illia Ostapyshyn <illia@yshyn.com>
Link: https://lore.kernel.org/r/20241114173930.44983-3-illia@yshyn.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Pull driver core updates from Greg KH:
"Here is the small set of driver core and kernfs changes for 6.10-rc1.
Nothing major here at all, just a small set of changes for some driver
core apis, and minor fixups. Included in here are:
- sysfs_bin_attr_simple_read() helper added and used
- device_show_string() helper added and used
All usages of these were acked by the various maintainers. Also in
here are:
- kernfs minor cleanup
- removed unused functions
- typo fix in documentation
- pay attention to sysfs_create_link() failures in module.c finally
All of these have been in linux-next for a very long time with no
reported problems"
* tag 'driver-core-6.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
device property: Fix a typo in the description of device_get_child_node_count()
kernfs: mount: Remove unnecessary ‘NULL’ values from knparent
scsi: Use device_show_string() helper for sysfs attributes
platform/x86: Use device_show_string() helper for sysfs attributes
perf: Use device_show_string() helper for sysfs attributes
IB/qib: Use device_show_string() helper for sysfs attributes
hwmon: Use device_show_string() helper for sysfs attributes
driver core: Add device_show_string() helper for sysfs attributes
treewide: Use sysfs_bin_attr_simple_read() helper
sysfs: Add sysfs_bin_attr_simple_read() helper
module: don't ignore sysfs_create_link() failures
driver core: Remove unused platform_notify, platform_notify_remove
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 <mpearson-lenovo@squebb.ca>
Signed-off-by: Vishnu Sankar <vishnuocv@gmail.com>
Link: https://lore.kernel.org/r/20240417173124.9953-4-mpearson-lenovo@squebb.ca
[hdegoede@redhat.com: Adjust for switch to sparse-keymap keymaps]
[hdegoede@redhat.com: Do not log unknown event msg for doubletap when disabled]
Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20240424122834.19801-25-hdegoede@redhat.com
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.
Signed-off-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Signed-off-by: Nitin Joshi <njoshi1@lenovo.com>
Link: https://lore.kernel.org/r/20240417173124.9953-3-mpearson-lenovo@squebb.ca
[hdegoede@redhat.com: Adjust for switch to sparse-keymap keymaps]
Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20240424122834.19801-24-hdegoede@redhat.com
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 KEY_PROG1 -
KEY_PROG3 by default by the upstream udev hwdb containing:
evdev:name:ThinkPad Extra Buttons:dmi:bvn*:bvr*:bd*:svnLENOVO*:pn*:*
...
KEYBOARD_KEY_17=prog1
KEYBOARD_KEY_1a=f20 # Microphone mute button
KEYBOARD_KEY_45=bookmarks
KEYBOARD_KEY_46=prog2 # Fn + PrtSc, on Windows: Snipping tool
KEYBOARD_KEY_4a=prog3 # Fn + Right shift, on Windows: No idea
Signed-off-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Signed-off-by: Vishnu Sankar <vishnuocv@gmail.com>
Link: https://lore.kernel.org/r/20240417173124.9953-2-mpearson-lenovo@squebb.ca
[hdegoede@redhat.com: Adjust for switch to sparse-keymap keymaps]
Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20240424122834.19801-23-hdegoede@redhat.com
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 the mean time we have gotten KEY_SELECTIVE_SCREENSHOT and this has been
used for the clipping-tool function under Fn + PrtSc on more traditional
ThinkPad keyboards already.
Finding a KEY_FOO code for the cloud key is harder looking at the symbol
it seems to refer to cloud-storage which made me think of file syncing,
or file transfer which has let me to pick KEY_XFER for this.
Note this is based on looking at a picture of the adaptive top row
in Home mode and has not been tested on an actual adaptive keyboard.
Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20240424122834.19801-21-hdegoede@redhat.com
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
these 2 changes make tpacpi_input_send_key() behave the same as
sparse_keymap_report_event().
The goal of this patch is to have a separate commit with
the slightly different behavior from sparse_keymap_report_event()
before switching over to using the sparse-keymap helpers.
Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20240424122834.19801-19-hdegoede@redhat.com
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 KEY_RESERVED.
This avoids users, who want these to be reported, having to also remap
the keycodes on top of overriding hotkey_user_mask to report these
and Linux userspace has already been overriding the KEY_RESERVED mappings
with the correct keycodes through udev/hwdb/60-keyboard.hwdb for years now.
Also drop hotkey_unmap() it was only used to dynamically map the brightness
keys to KEY_RESERVED and after removing that it has no remaining users.
Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20240424122834.19801-18-hdegoede@redhat.com
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.
Note only the 32 original hotkeys are affected by the hotkey_*_mask values:
if (i < sizeof(hotkey_reserved_mask)*8)
hotkey_reserved_mask |= 1 << i;
The (i < sizeof(hotkey_reserved_mask)*8) condition translates to (i < 32)
so this code only ever set bits in hotkey_reserved_mask for the 32 original
hotkeys. Therefor this patch does not set any bits in hotkey_reserved_mask
for the KEY_RESERVED mappings for the adaptive keyboard scancodes.
Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20240424122834.19801-17-hdegoede@redhat.com
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 hindsight the ACPI netlink events should have been suppressed for
the adaptive keyboard and extended hotkeys events too. But the kernel has
been sending ACPI netlink events for those for a long time now, so we
cannot just stop sending them without potentially causing issues for
existing users who may depend on these.
Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20240424122834.19801-16-hdegoede@redhat.com
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 tpacpi_input_send_key()
never happens when called from tpacpi_hotkey_send_key() so behavior does
not change.
Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20240424122834.19801-15-hdegoede@redhat.com
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 which do not emit
a key press event together in tpacpi_driver_event().
This also drops the returning of false as known-event value when
adaptive_keyboard_get_mode() / adaptive_keyboard_set_mode() fail.
These functions already log an error on failure, returning false just
leads to an extra messgae being logged about the hkey event being
unknown, which is wrong as the event is not unknown.
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20240424122834.19801-9-hdegoede@redhat.com
hotkey_exit() already takes the mutex around the hotkey_poll_stop_sync()
call, but not around the other calls.
commit 38831eaf7d ("platform/x86: thinkpad_acpi: use lockdep
annotations") has added lockdep_assert_held() checks to various hotkey
functions.
These lockdep_assert_held() checks fail causing WARN() backtraces in
dmesg due to missing locking in hotkey_exit(), fix this.
Fixes: 38831eaf7d ("platform/x86: thinkpad_acpi: use lockdep annotations")
Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20240424122834.19801-2-hdegoede@redhat.com
