Menu
▾
▴
ibm-acpi-devel — ibm-acpi Linux driver development
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(74) |
Dec
(26) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(14) |
Feb
(70) |
Mar
(116) |
Apr
(64) |
May
(118) |
Jun
(39) |
Jul
(243) |
Aug
(68) |
Sep
(77) |
Oct
(136) |
Nov
(48) |
Dec
(38) |
| 2008 |
Jan
(100) |
Feb
(84) |
Mar
(21) |
Apr
(56) |
May
(24) |
Jun
(19) |
Jul
(47) |
Aug
(27) |
Sep
(20) |
Oct
(65) |
Nov
(54) |
Dec
(14) |
| 2009 |
Jan
(45) |
Feb
(12) |
Mar
(15) |
Apr
(42) |
May
(21) |
Jun
(41) |
Jul
(15) |
Aug
(25) |
Sep
(49) |
Oct
(20) |
Nov
(61) |
Dec
(139) |
| 2010 |
Jan
(42) |
Feb
(56) |
Mar
(30) |
Apr
(27) |
May
(40) |
Jun
(16) |
Jul
(28) |
Aug
(14) |
Sep
(16) |
Oct
(11) |
Nov
(9) |
Dec
(10) |
| 2011 |
Jan
(51) |
Feb
(15) |
Mar
(29) |
Apr
(17) |
May
(70) |
Jun
(37) |
Jul
(6) |
Aug
(20) |
Sep
(7) |
Oct
(18) |
Nov
(28) |
Dec
(9) |
| 2012 |
Jan
(11) |
Feb
(12) |
Mar
(25) |
Apr
(8) |
May
(11) |
Jun
(27) |
Jul
(25) |
Aug
(22) |
Sep
(7) |
Oct
(6) |
Nov
(8) |
Dec
(29) |
| 2013 |
Jan
(11) |
Feb
(16) |
Mar
(41) |
Apr
(5) |
May
(4) |
Jun
(27) |
Jul
(10) |
Aug
(21) |
Sep
(13) |
Oct
(16) |
Nov
(31) |
Dec
(13) |
| 2014 |
Jan
(2) |
Feb
(37) |
Mar
(39) |
Apr
(62) |
May
(13) |
Jun
(6) |
Jul
(3) |
Aug
(4) |
Sep
(15) |
Oct
(13) |
Nov
(45) |
Dec
(2) |
| 2015 |
Jan
(7) |
Feb
(85) |
Mar
(66) |
Apr
(14) |
May
(24) |
Jun
(127) |
Jul
(7) |
Aug
(9) |
Sep
|
Oct
(11) |
Nov
(2) |
Dec
(12) |
| 2016 |
Jan
(71) |
Feb
(17) |
Mar
(8) |
Apr
(26) |
May
(8) |
Jun
(12) |
Jul
|
Aug
(2) |
Sep
(11) |
Oct
(25) |
Nov
(139) |
Dec
(7) |
| 2017 |
Jan
(12) |
Feb
(12) |
Mar
(4) |
Apr
(8) |
May
(37) |
Jun
(12) |
Jul
(5) |
Aug
(5) |
Sep
(18) |
Oct
(21) |
Nov
(10) |
Dec
(91) |
| 2018 |
Jan
(35) |
Feb
(31) |
Mar
(1) |
Apr
(33) |
May
(15) |
Jun
(50) |
Jul
(10) |
Aug
(14) |
Sep
(5) |
Oct
(8) |
Nov
(53) |
Dec
(9) |
| 2019 |
Jan
|
Feb
|
Mar
(7) |
Apr
(14) |
May
(14) |
Jun
(5) |
Jul
(5) |
Aug
|
Sep
(2) |
Oct
(2) |
Nov
|
Dec
(2) |
| 2020 |
Jan
(9) |
Feb
(8) |
Mar
|
Apr
(11) |
May
(14) |
Jun
(35) |
Jul
(53) |
Aug
(23) |
Sep
(15) |
Oct
(6) |
Nov
(14) |
Dec
(8) |
| 2021 |
Jan
(9) |
Feb
(6) |
Mar
(14) |
Apr
(4) |
May
(3) |
Jun
(1) |
Jul
(7) |
Aug
(2) |
Sep
(10) |
Oct
(4) |
Nov
(26) |
Dec
(9) |
| 2022 |
Jan
(13) |
Feb
(1) |
Mar
(1) |
Apr
(7) |
May
(7) |
Jun
(17) |
Jul
(6) |
Aug
(9) |
Sep
|
Oct
(8) |
Nov
(6) |
Dec
|
| 2023 |
Jan
(1) |
Feb
|
Mar
|
Apr
(8) |
May
|
Jun
|
Jul
(4) |
Aug
(1) |
Sep
(13) |
Oct
(1) |
Nov
(9) |
Dec
(4) |
| 2024 |
Jan
(9) |
Feb
|
Mar
(5) |
Apr
(118) |
May
(4) |
Jun
(13) |
Jul
|
Aug
(4) |
Sep
(4) |
Oct
(16) |
Nov
(20) |
Dec
(3) |
| 2025 |
Jan
(7) |
Feb
(1) |
Mar
(3) |
Apr
(8) |
May
(15) |
Jun
(38) |
Jul
(2) |
Aug
(9) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
|
From: Mark P. <mpe...@sq...> - 2024-04-11 02:48:47
|
Hi Dmitry, On Wed, Apr 10, 2024, at 8:02 PM, Dmitry Torokhov wrote: > On Tue, Apr 09, 2024 at 10:17:05PM -0400, Mark Pearson wrote: >> Hi Dmitry >> >> On Tue, Apr 9, 2024, at 9:20 PM, Dmitry Torokhov wrote: >> > On Tue, Apr 09, 2024 at 02:47:05PM -0700, Dmitry Torokhov wrote: >> >> On Tue, Apr 09, 2024 at 03:23:52PM +1000, Peter Hutterer wrote: >> >> > On 09/04/2024 09:31, Dmitry Torokhov wrote: >> >> > > Hi Mark, >> >> > > >> >> > > On Sun, Mar 24, 2024 at 05:07:58PM -0400, Mark Pearson wrote: >> >> > > > Add support for new input events on Lenovo laptops that need exporting to >> >> > > > user space. >> >> > > > >> >> > > > Lenovo trackpoints are adding the ability to generate a doubletap event. >> >> > > > Add a new keycode to allow this to be used by userspace. >> >> > > >> >> > > What is the intended meaning of this keycode? How does it differ from >> >> > > the driver sending BTN_LEFT press/release twice? >> >> > > > >> >> > > > Lenovo support is using FN+N with Windows to collect needed details for >> >> > > > support cases. Add a keycode so that we'll be able to provide similar >> >> > > > support on Linux. >> >> > > >> >> > > Is there a userspace consumer for this? >> >> > >> >> > Funnily enough XKB has had a keysym for this for decades but it's not >> >> > hooked up anywhere due to the way it's pointer keys accessibility >> >> > feature was implemented. Theory is that most of userspace just needs >> >> > to patch the various pieces together for the new evdev code + keysym, >> >> > it's not really any different to handling a volume key (except this >> >> > one needs to be assignable). >> >> >> >> What is the keysym? If we can make them relatable to each other that >> >> would be good. Or maybe we could find a matching usage from HID usage >> >> tables... >> > >> > I was looking through the existing codes and I see: >> > >> > #define KEY_INFO 0x166 /* AL OEM Features/Tips/Tutorial */ >> > >> > We also have KEY_VENDOR used in a few drivers/plafrom/x86, including >> > thinkkpad_acpi.c and I wonder if it would be suitable for this vendor >> > specific debug info collection application (which I honestly doubt will >> > materialize). >> > >> >> That's a somewhat disappointing note on your doubts, is that based on >> anything? Just wondering what we've done to deserve that criticism. > > Sorry, this was not meant as a criticism really, but you mentioned > yourself that there isn't anything in the works yet, you just have some > plans. All good - I was just worried we'd promised something previously and not delivered. We're often slow at delivering - but I try not to fail completely. I try especially hard not to annoy hard working kernel maintainers :) We do have something developed internally, but it's pretty basic and we'll need to have discussion with 'userspace' fol as to if we release that as a standalone application, or if we tie into gnome (which we don't have a lot of experience with)...or something else. Kernel world is much easier :) > > For such a project to succeed Lenovo needs to invest into selling > devices with Linux as a primary operating system, and it has to be > consumer segment (or small business, because for corporate they > typically roll their own support channels). The case of retrofitting > Linux onto a that device originally came with Windows OS rarely gets > much if any response from the normal support channels. > > Is this something that is actually happening? This is way off topic for the patch set, but as you asked :) I'm afraid I'm going to disagree. What you're suggesting is probably the more common and easier route vendors take, but it has some issues and I think some longer term limitations. For me one of the things I like the most about our program using the same exact HW as Windows is it means: - I have a business lever to get Linux support from HW vendors. This makes a difference when you're dealing with 'minor' components - panels, fingerprint readers, touchpads etc - the smaller devices (though it helps for the CPU vendors too). We have requirements that state the upstream Linux support is needed or the chip vendor will not be considered for the platform...and that's a big deal. - It gets FW teams thinking about Linux support. Yeah, there are still a ton of issues there and it's far from perfect, but it means they have to think about Linux support and at least helps us shine a bit of light on what is going on in that horrible closed box. - It means I get Linux running at a good level on a wider range of HW then would be otherwise possible. It means that when there is new technology I get to go and ask "how about Linux" and have that discussion (including schedules). It might come later than I'd like - but at least we get to put Linux on the roadmap rather than being excluded for being so niche. Shrug. I think our Linux program still has a long way to go before it's even close to good - but it's in better shape than it (at least I think so, I don't love the way the industry is going with more being stuffed in FW...but that's above my paygrade) > >> >> That aside, I guess KEY_INFO or KEY_VENDOR could be a good fit (I >> personally don't think KEY_CONFIG matches well), but I would be >> worried about clashing with existing functionality. >> >> Peter - do you have any opinion from the user space side of things, or >> are these likely unused? KEY_VENDOR seems the safer bet to me (but I >> don't love it). >> >> Dmitry - What are the downsides or concerns of introducing a new code? >> I'd like to evaluate that against the potential to cause conflicts by >> re-using existing codes. If you feel strongly about it then I'll defer >> to your judgement, but I'd like to understand better the context. > > The keycode space is finite and extending bitmaps leads to more memory > consumption and weird breakages (like uevent generation exceeding 4K > memory page resulting in failures). I am trying to balance need for new > keycodes with how likely they are to be used. > Ack. So I've been refactoring my patches to implement the feedback from Hans for the latter patches and just need to figure out what works here. For the SYS_DEBUG_INFO, if you'd rather we use KEY_VENDOR (I think that's my preference - as its intended for a Lenovo support role it seems the best fit), and Peter has no objections, I will make that change. I have a stronger preference to keep the KEY_DOUBLECLICK - that one seems less controversial as a genuine new input event. Is that OK? Mark |
|
From: Dmitry T. <dmi...@gm...> - 2024-04-11 00:02:18
|
On Tue, Apr 09, 2024 at 10:17:05PM -0400, Mark Pearson wrote: > Hi Dmitry > > On Tue, Apr 9, 2024, at 9:20 PM, Dmitry Torokhov wrote: > > On Tue, Apr 09, 2024 at 02:47:05PM -0700, Dmitry Torokhov wrote: > >> On Tue, Apr 09, 2024 at 03:23:52PM +1000, Peter Hutterer wrote: > >> > On 09/04/2024 09:31, Dmitry Torokhov wrote: > >> > > Hi Mark, > >> > > > >> > > On Sun, Mar 24, 2024 at 05:07:58PM -0400, Mark Pearson wrote: > >> > > > Add support for new input events on Lenovo laptops that need exporting to > >> > > > user space. > >> > > > > >> > > > Lenovo trackpoints are adding the ability to generate a doubletap event. > >> > > > Add a new keycode to allow this to be used by userspace. > >> > > > >> > > What is the intended meaning of this keycode? How does it differ from > >> > > the driver sending BTN_LEFT press/release twice? > >> > > > > >> > > > Lenovo support is using FN+N with Windows to collect needed details for > >> > > > support cases. Add a keycode so that we'll be able to provide similar > >> > > > support on Linux. > >> > > > >> > > Is there a userspace consumer for this? > >> > > >> > Funnily enough XKB has had a keysym for this for decades but it's not > >> > hooked up anywhere due to the way it's pointer keys accessibility > >> > feature was implemented. Theory is that most of userspace just needs > >> > to patch the various pieces together for the new evdev code + keysym, > >> > it's not really any different to handling a volume key (except this > >> > one needs to be assignable). > >> > >> What is the keysym? If we can make them relatable to each other that > >> would be good. Or maybe we could find a matching usage from HID usage > >> tables... > > > > I was looking through the existing codes and I see: > > > > #define KEY_INFO 0x166 /* AL OEM Features/Tips/Tutorial */ > > > > We also have KEY_VENDOR used in a few drivers/plafrom/x86, including > > thinkkpad_acpi.c and I wonder if it would be suitable for this vendor > > specific debug info collection application (which I honestly doubt will > > materialize). > > > > That's a somewhat disappointing note on your doubts, is that based on > anything? Just wondering what we've done to deserve that criticism. Sorry, this was not meant as a criticism really, but you mentioned yourself that there isn't anything in the works yet, you just have some plans. For such a project to succeed Lenovo needs to invest into selling devices with Linux as a primary operating system, and it has to be consumer segment (or small business, because for corporate they typically roll their own support channels). The case of retrofitting Linux onto a that device originally came with Windows OS rarely gets much if any response from the normal support channels. Is this something that is actually happening? > > That aside, I guess KEY_INFO or KEY_VENDOR could be a good fit (I > personally don't think KEY_CONFIG matches well), but I would be > worried about clashing with existing functionality. > > Peter - do you have any opinion from the user space side of things, or > are these likely unused? KEY_VENDOR seems the safer bet to me (but I > don't love it). > > Dmitry - What are the downsides or concerns of introducing a new code? > I'd like to evaluate that against the potential to cause conflicts by > re-using existing codes. If you feel strongly about it then I'll defer > to your judgement, but I'd like to understand better the context. The keycode space is finite and extending bitmaps leads to more memory consumption and weird breakages (like uevent generation exceeding 4K memory page resulting in failures). I am trying to balance need for new keycodes with how likely they are to be used. Thanks. -- Dmitry |
|
From: Mark P. <mpe...@sq...> - 2024-04-10 02:17:33
|
Hi Dmitry On Tue, Apr 9, 2024, at 9:20 PM, Dmitry Torokhov wrote: > On Tue, Apr 09, 2024 at 02:47:05PM -0700, Dmitry Torokhov wrote: >> On Tue, Apr 09, 2024 at 03:23:52PM +1000, Peter Hutterer wrote: >> > On 09/04/2024 09:31, Dmitry Torokhov wrote: >> > > Hi Mark, >> > > >> > > On Sun, Mar 24, 2024 at 05:07:58PM -0400, Mark Pearson wrote: >> > > > Add support for new input events on Lenovo laptops that need exporting to >> > > > user space. >> > > > >> > > > Lenovo trackpoints are adding the ability to generate a doubletap event. >> > > > Add a new keycode to allow this to be used by userspace. >> > > >> > > What is the intended meaning of this keycode? How does it differ from >> > > the driver sending BTN_LEFT press/release twice? >> > > > >> > > > Lenovo support is using FN+N with Windows to collect needed details for >> > > > support cases. Add a keycode so that we'll be able to provide similar >> > > > support on Linux. >> > > >> > > Is there a userspace consumer for this? >> > >> > Funnily enough XKB has had a keysym for this for decades but it's not >> > hooked up anywhere due to the way it's pointer keys accessibility >> > feature was implemented. Theory is that most of userspace just needs >> > to patch the various pieces together for the new evdev code + keysym, >> > it's not really any different to handling a volume key (except this >> > one needs to be assignable). >> >> What is the keysym? If we can make them relatable to each other that >> would be good. Or maybe we could find a matching usage from HID usage >> tables... > > I was looking through the existing codes and I see: > > #define KEY_INFO 0x166 /* AL OEM Features/Tips/Tutorial */ > > We also have KEY_VENDOR used in a few drivers/plafrom/x86, including > thinkkpad_acpi.c and I wonder if it would be suitable for this vendor > specific debug info collection application (which I honestly doubt will > materialize). > That's a somewhat disappointing note on your doubts, is that based on anything? Just wondering what we've done to deserve that criticism. That aside, I guess KEY_INFO or KEY_VENDOR could be a good fit (I personally don't think KEY_CONFIG matches well), but I would be worried about clashing with existing functionality. Peter - do you have any opinion from the user space side of things, or are these likely unused? KEY_VENDOR seems the safer bet to me (but I don't love it). Dmitry - What are the downsides or concerns of introducing a new code? I'd like to evaluate that against the potential to cause conflicts by re-using existing codes. If you feel strongly about it then I'll defer to your judgement, but I'd like to understand better the context. Thanks Mark |
|
From: Dmitry T. <dmi...@gm...> - 2024-04-10 01:21:07
|
On Tue, Apr 09, 2024 at 02:47:05PM -0700, Dmitry Torokhov wrote: > On Tue, Apr 09, 2024 at 03:23:52PM +1000, Peter Hutterer wrote: > > On 09/04/2024 09:31, Dmitry Torokhov wrote: > > > Hi Mark, > > > > > > On Sun, Mar 24, 2024 at 05:07:58PM -0400, Mark Pearson wrote: > > > > Add support for new input events on Lenovo laptops that need exporting to > > > > user space. > > > > > > > > Lenovo trackpoints are adding the ability to generate a doubletap event. > > > > Add a new keycode to allow this to be used by userspace. > > > > > > What is the intended meaning of this keycode? How does it differ from > > > the driver sending BTN_LEFT press/release twice? > > > > > > > > Lenovo support is using FN+N with Windows to collect needed details for > > > > support cases. Add a keycode so that we'll be able to provide similar > > > > support on Linux. > > > > > > Is there a userspace consumer for this? > > > > Funnily enough XKB has had a keysym for this for decades but it's not > > hooked up anywhere due to the way it's pointer keys accessibility > > feature was implemented. Theory is that most of userspace just needs > > to patch the various pieces together for the new evdev code + keysym, > > it's not really any different to handling a volume key (except this > > one needs to be assignable). > > What is the keysym? If we can make them relatable to each other that > would be good. Or maybe we could find a matching usage from HID usage > tables... I was looking through the existing codes and I see: #define KEY_INFO 0x166 /* AL OEM Features/Tips/Tutorial */ We also have KEY_VENDOR used in a few drivers/plafrom/x86, including thinkkpad_acpi.c and I wonder if it would be suitable for this vendor specific debug info collection application (which I honestly doubt will materialize). Thanks. -- Dmitry |
|
From: Dmitry T. <dmi...@gm...> - 2024-04-09 21:54:38
|
On Tue, Apr 09, 2024 at 12:16:04PM +0200, Hans de Goede wrote: > Hi Dmitry, > > On 4/9/24 2:00 AM, Mark Pearson wrote: > > Hi Dmitry > > > > On Mon, Apr 8, 2024, at 7:31 PM, Dmitry Torokhov wrote: > >> Hi Mark, > >> > >> On Sun, Mar 24, 2024 at 05:07:58PM -0400, Mark Pearson wrote: > >>> Add support for new input events on Lenovo laptops that need exporting to > >>> user space. > >>> > >>> Lenovo trackpoints are adding the ability to generate a doubletap event. > >>> Add a new keycode to allow this to be used by userspace. > >> > >> What is the intended meaning of this keycode? How does it differ from > >> the driver sending BTN_LEFT press/release twice? > > > > Double tapping on the trackpoint is a unique event - it's not the same as BTN_LEFT twice. The BIOS will send a new ACPI event for it and it's not meant to be the same as mouse button clicks. > > To extend a bit on this, this double-tap event is not reported through > the PS/2 trackpoint interface at all. Instead it is reported to > the OS by the ACPI hotkey notifier, which is used to report various > multi-media hotkeys and things like that, this is handled by > the thinkpad_apci driver which sofar only reports key-presses. Ah, I see, so this is just an arbitrary action not connected with the pointer handling in any way. For such actions we typically assign keycodes based on their intended behavior, so instead of KEY_DOUBLECLICK which conveys user gesture but not the intent you should consider using KEY_CONFIG (with is typically mapped to Application Launcher - Consumer Control Configuration in HID spec) or KEY_CONTROLPANEL (Application Launcher - Control Panel). Thanks. -- Dmitry |
|
From: Dmitry T. <dmi...@gm...> - 2024-04-09 21:47:23
|
On Tue, Apr 09, 2024 at 03:23:52PM +1000, Peter Hutterer wrote: > On 09/04/2024 09:31, Dmitry Torokhov wrote: > > Hi Mark, > > > > On Sun, Mar 24, 2024 at 05:07:58PM -0400, Mark Pearson wrote: > > > Add support for new input events on Lenovo laptops that need exporting to > > > user space. > > > > > > Lenovo trackpoints are adding the ability to generate a doubletap event. > > > Add a new keycode to allow this to be used by userspace. > > > > What is the intended meaning of this keycode? How does it differ from > > the driver sending BTN_LEFT press/release twice? > > > > > > Lenovo support is using FN+N with Windows to collect needed details for > > > support cases. Add a keycode so that we'll be able to provide similar > > > support on Linux. > > > > Is there a userspace consumer for this? > > Funnily enough XKB has had a keysym for this for decades but it's not > hooked up anywhere due to the way it's pointer keys accessibility > feature was implemented. Theory is that most of userspace just needs > to patch the various pieces together for the new evdev code + keysym, > it's not really any different to handling a volume key (except this > one needs to be assignable). What is the keysym? If we can make them relatable to each other that would be good. Or maybe we could find a matching usage from HID usage tables... Thanks. -- Dmitry |
|
From: Hans de G. <hde...@re...> - 2024-04-09 10:16:26
|
Hi Dmitry, On 4/9/24 2:00 AM, Mark Pearson wrote: > Hi Dmitry > > On Mon, Apr 8, 2024, at 7:31 PM, Dmitry Torokhov wrote: >> Hi Mark, >> >> On Sun, Mar 24, 2024 at 05:07:58PM -0400, Mark Pearson wrote: >>> Add support for new input events on Lenovo laptops that need exporting to >>> user space. >>> >>> Lenovo trackpoints are adding the ability to generate a doubletap event. >>> Add a new keycode to allow this to be used by userspace. >> >> What is the intended meaning of this keycode? How does it differ from >> the driver sending BTN_LEFT press/release twice? > > Double tapping on the trackpoint is a unique event - it's not the same as BTN_LEFT twice. The BIOS will send a new ACPI event for it and it's not meant to be the same as mouse button clicks. To extend a bit on this, this double-tap event is not reported through the PS/2 trackpoint interface at all. Instead it is reported to the OS by the ACPI hotkey notifier, which is used to report various multi-media hotkeys and things like that, this is handled by the thinkpad_apci driver which sofar only reports key-presses. So there is no BTN_LEFT to report twice and if we add a BTN_LEFT then we end up with an input_device which has a bunch of KEYs + BTN_LEFT but no abs/rel axis which will just confuse userspace. We could add a second input_device which looks like a mouse but only ever reports BTN_LEFT double-clicks I guess, but as Mark said the intention is for this double-tap to work more like a hotkey then a double click. Also note that regular taps on the trackstick do nothing. Clicking the mouse buttons of the stick involves pressing separate physical buttons between the trackpad and the keyboard and those are reported over the same PS/2 port as the relative motion events from the stick. Regards, Hans |
|
From: Mark P. <mpe...@sq...> - 2024-04-09 00:00:43
|
Hi Dmitry On Mon, Apr 8, 2024, at 7:31 PM, Dmitry Torokhov wrote: > Hi Mark, > > On Sun, Mar 24, 2024 at 05:07:58PM -0400, Mark Pearson wrote: >> Add support for new input events on Lenovo laptops that need exporting to >> user space. >> >> Lenovo trackpoints are adding the ability to generate a doubletap event. >> Add a new keycode to allow this to be used by userspace. > > What is the intended meaning of this keycode? How does it differ from > the driver sending BTN_LEFT press/release twice? Double tapping on the trackpoint is a unique event - it's not the same as BTN_LEFT twice. The BIOS will send a new ACPI event for it and it's not meant to be the same as mouse button clicks. For example, on Windows this launches a utility that let's you do various configurations on your laptop (some Lenovo specific), but that's not available on Linux (yet). We did want to make it flexible in this implementation so users could use it for whatever was useful to them. >> >> Lenovo support is using FN+N with Windows to collect needed details for >> support cases. Add a keycode so that we'll be able to provide similar >> support on Linux. > > Is there a userspace consumer for this? There isn't yet, though we would like to implement something, and do plan to. We still have to work through the details of the best way to do this, and if it's Lenovo specific, or (probably better) something generic. I don't have as much knowledge on the user-space side development, and my experience is it tends to move a bit slower for getting things implemented. We thought we'd get the framework in, so it's available, and then work with user-space folk to deliver a solution in a suitable manner. Ultimately this is something we'll need in our Linux preloads and the aim is to make it easier for Linux users to get help from our support team (not always the easiest currently). I don't know if other vendors have something similar, but I wouldn't be surprised if this could be re-used in other cases so I hope it's not Lenovo specific. It felt like it would be useful functionality to have :) Mark |
|
From: Dmitry T. <dmi...@gm...> - 2024-04-08 23:31:53
|
Hi Mark, On Sun, Mar 24, 2024 at 05:07:58PM -0400, Mark Pearson wrote: > Add support for new input events on Lenovo laptops that need exporting to > user space. > > Lenovo trackpoints are adding the ability to generate a doubletap event. > Add a new keycode to allow this to be used by userspace. What is the intended meaning of this keycode? How does it differ from the driver sending BTN_LEFT press/release twice? > > Lenovo support is using FN+N with Windows to collect needed details for > support cases. Add a keycode so that we'll be able to provide similar > support on Linux. Is there a userspace consumer for this? Thanks. -- Dmitry |
|
From: Rafael J. W. <ra...@ke...> - 2024-04-08 17:05:23
|
On Mon, Apr 8, 2024 at 6:41 PM Hans de Goede <hde...@re...> wrote:
>
> Hi Gergo,
>
> On 4/6/24 2:01 AM, Gergo Koteles wrote:
> > Some laptops have a key to switch platform profiles.
> >
> > Add a platform_profile_cycle() function to cycle between the enabled
> > profiles.
> >
> > Signed-off-by: Gergo Koteles <so...@ir...>
>
> Thank you for your patch, 1 small remark below,
> otherwise this looks good to me.
>
> Rafael, may I have your Ack for merging this through the pdx86 tree
> together with the rest of the series once my remark has been addressed ?
Sure, please feel free to add
Acked-by: Rafael J. Wysocki <raf...@in...>
to this patch. Thanks!
> > ---
> > drivers/acpi/platform_profile.c | 39 ++++++++++++++++++++++++++++++++
> > include/linux/platform_profile.h | 1 +
> > 2 files changed, 40 insertions(+)
> >
> > diff --git a/drivers/acpi/platform_profile.c b/drivers/acpi/platform_profile.c
> > index d418462ab791..acc606af812a 100644
> > --- a/drivers/acpi/platform_profile.c
> > +++ b/drivers/acpi/platform_profile.c
> > @@ -136,6 +136,45 @@ void platform_profile_notify(void)
> > }
> > EXPORT_SYMBOL_GPL(platform_profile_notify);
> >
> > +int platform_profile_cycle(void)
> > +{
> > + enum platform_profile_option profile;
> > + enum platform_profile_option next;
> > + int err;
> > +
> > + err = mutex_lock_interruptible(&profile_lock);
> > + if (err)
> > + return err;
> > +
> > + if (!cur_profile) {
> > + mutex_unlock(&profile_lock);
> > + return -ENODEV;
> > + }
> > +
> > + err = cur_profile->profile_get(cur_profile, &profile);
> > + if (err) {
> > + mutex_unlock(&profile_lock);
> > + return err;
> > + }
> > +
> > + next = find_next_bit_wrap(cur_profile->choices,
> > + ARRAY_SIZE(profile_names), profile + 1);
> > +
> > + if (WARN_ON(next == ARRAY_SIZE(profile_names))) {
>
> Other code in drivers/acpi/platform_profile.c uses PLATFORM_PROFILE_LAST
> instead of ARRAY_SIZE(profile_names) (these are guaranteed to be equal)
> please switch to using PLATFORM_PROFILE_LAST for consistency.
>
> Regards,
>
> Hans
>
>
>
>
>
> > + mutex_unlock(&profile_lock);
> > + return -EINVAL;
> > + }
> > +
> > + err = cur_profile->profile_set(cur_profile, next);
> > + mutex_unlock(&profile_lock);
> > +
> > + if (!err)
> > + sysfs_notify(acpi_kobj, NULL, "platform_profile");
> > +
> > + return err;
> > +}
> > +EXPORT_SYMBOL_GPL(platform_profile_cycle);
> > +
> > int platform_profile_register(struct platform_profile_handler *pprof)
> > {
> > int err;
> > diff --git a/include/linux/platform_profile.h b/include/linux/platform_profile.h
> > index e5cbb6841f3a..f5492ed413f3 100644
> > --- a/include/linux/platform_profile.h
> > +++ b/include/linux/platform_profile.h
> > @@ -36,6 +36,7 @@ struct platform_profile_handler {
> >
> > int platform_profile_register(struct platform_profile_handler *pprof);
> > int platform_profile_remove(void);
> > +int platform_profile_cycle(void);
> > void platform_profile_notify(void);
> >
> > #endif /*_PLATFORM_PROFILE_H_*/
>
|
|
From: Hans de G. <hde...@re...> - 2024-04-08 16:41:55
|
Hi Gergo,
On 4/6/24 2:01 AM, Gergo Koteles wrote:
> Some laptops have a key to switch platform profiles.
>
> Add a platform_profile_cycle() function to cycle between the enabled
> profiles.
>
> Signed-off-by: Gergo Koteles <so...@ir...>
Thank you for your patch, 1 small remark below,
otherwise this looks good to me.
Rafael, may I have your Ack for merging this through the pdx86 tree
together with the rest of the series once my remark has been addressed ?
> ---
> drivers/acpi/platform_profile.c | 39 ++++++++++++++++++++++++++++++++
> include/linux/platform_profile.h | 1 +
> 2 files changed, 40 insertions(+)
>
> diff --git a/drivers/acpi/platform_profile.c b/drivers/acpi/platform_profile.c
> index d418462ab791..acc606af812a 100644
> --- a/drivers/acpi/platform_profile.c
> +++ b/drivers/acpi/platform_profile.c
> @@ -136,6 +136,45 @@ void platform_profile_notify(void)
> }
> EXPORT_SYMBOL_GPL(platform_profile_notify);
>
> +int platform_profile_cycle(void)
> +{
> + enum platform_profile_option profile;
> + enum platform_profile_option next;
> + int err;
> +
> + err = mutex_lock_interruptible(&profile_lock);
> + if (err)
> + return err;
> +
> + if (!cur_profile) {
> + mutex_unlock(&profile_lock);
> + return -ENODEV;
> + }
> +
> + err = cur_profile->profile_get(cur_profile, &profile);
> + if (err) {
> + mutex_unlock(&profile_lock);
> + return err;
> + }
> +
> + next = find_next_bit_wrap(cur_profile->choices,
> + ARRAY_SIZE(profile_names), profile + 1);
> +
> + if (WARN_ON(next == ARRAY_SIZE(profile_names))) {
Other code in drivers/acpi/platform_profile.c uses PLATFORM_PROFILE_LAST
instead of ARRAY_SIZE(profile_names) (these are guaranteed to be equal)
please switch to using PLATFORM_PROFILE_LAST for consistency.
Regards,
Hans
> + mutex_unlock(&profile_lock);
> + return -EINVAL;
> + }
> +
> + err = cur_profile->profile_set(cur_profile, next);
> + mutex_unlock(&profile_lock);
> +
> + if (!err)
> + sysfs_notify(acpi_kobj, NULL, "platform_profile");
> +
> + return err;
> +}
> +EXPORT_SYMBOL_GPL(platform_profile_cycle);
> +
> int platform_profile_register(struct platform_profile_handler *pprof)
> {
> int err;
> diff --git a/include/linux/platform_profile.h b/include/linux/platform_profile.h
> index e5cbb6841f3a..f5492ed413f3 100644
> --- a/include/linux/platform_profile.h
> +++ b/include/linux/platform_profile.h
> @@ -36,6 +36,7 @@ struct platform_profile_handler {
>
> int platform_profile_register(struct platform_profile_handler *pprof);
> int platform_profile_remove(void);
> +int platform_profile_cycle(void);
> void platform_profile_notify(void);
>
> #endif /*_PLATFORM_PROFILE_H_*/
|
|
From: Mark P. <mpe...@sq...> - 2024-04-08 15:16:31
|
Thanks Hans
On Mon, Apr 8, 2024, at 9:11 AM, Hans de Goede wrote:
> Hi,
>
> On 3/24/24 10:08 PM, Mark Pearson wrote:
>> 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 generating a
>> SYS_DEBUG_INFO keycode to userspace.
>>
>> Signed-off-by: Mark Pearson <mpe...@sq...>
>> Signed-off-by: Nitin Joshi <nj...@le...>
>> ---
>> drivers/platform/x86/thinkpad_acpi.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
>> index 2bbb32c898e9..854ce971bde2 100644
>> --- a/drivers/platform/x86/thinkpad_acpi.c
>> +++ b/drivers/platform/x86/thinkpad_acpi.c
>> @@ -1787,6 +1787,7 @@ enum { /* hot key scan codes (derived from ACPI DSDT) */
>> TP_ACPI_HOTKEYSCAN_NOTIFICATION_CENTER,
>> TP_ACPI_HOTKEYSCAN_PICKUP_PHONE,
>> TP_ACPI_HOTKEYSCAN_HANGUP_PHONE,
>> + TP_ACPI_HOTKEYSCAN_SYS_DEBUG_INFO = 81,
>>
>> /* Hotkey keymap size */
>> TPACPI_HOTKEY_MAP_LEN
>> @@ -3337,6 +3338,9 @@ static int __init hotkey_init(struct ibm_init_struct *iibm)
>> KEY_NOTIFICATION_CENTER, /* Notification Center */
>> KEY_PICKUP_PHONE, /* Answer incoming call */
>> KEY_HANGUP_PHONE, /* Decline incoming call */
>> + KEY_UNKNOWN, /* AMT Toggle (event), 0x31A */
>> + KEY_UNKNOWN, KEY_UNKNOWN,
>> + KEY_SYS_DEBUG_INFO, /* System debug info, 0x31D */
>> },
>> };
>>
>
> Looking at the next patch 0x131c is TP_HKEY_EV_DOUBLETAP_TOGGLE and 0x131a is
> TP_HKEY_EV_AMT_TOGGLE based on this please change this to:
>
> KEY_NOTIFICATION_CENTER, /* Notification Center */
> KEY_PICKUP_PHONE, /* Answer incoming call */
> KEY_HANGUP_PHONE, /* Decline incoming call */
> KEY_UNKNOWN, /* TP_HKEY_EV_AMT_TOGGLE handled in driver, 0x31a */
> KEY_UNKNOWN, /* ?, 0X31b */
> KEY_UNKNOWN, /* TP_HKEY_EV_DOUBLETAP_TOGGLE handled in driver, 0x31c */
> KEY_SYS_DEBUG_INFO, /* System debug info, 0x31d */
> },
>
Will do
Mark
|
|
From: Mark P. <mpe...@sq...> - 2024-04-08 15:11:56
|
Hi Hans,
Many thanks for the review.
On Mon, Apr 8, 2024, at 9:04 AM, Hans de Goede wrote:
> Hi Mark,
>
> On 3/24/24 10:07 PM, Mark Pearson wrote:
>> Lenovo trackpoints are adding the ability to generate a doubletap event.
>> This handles the doubletap event and sends the KEY_DOUBLECLICK event to
>> userspace.
>>
>> Signed-off-by: Mark Pearson <mpe...@sq...>
>> Signed-off-by: Vishnu Sankar <vs...@le...>
>> ---
>> drivers/platform/x86/thinkpad_acpi.c | 17 +++++++++++++++++
>> 1 file changed, 17 insertions(+)
>>
>> diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
>> index 82429e59999d..2bbb32c898e9 100644
>> --- a/drivers/platform/x86/thinkpad_acpi.c
>> +++ b/drivers/platform/x86/thinkpad_acpi.c
>> @@ -232,6 +232,7 @@ enum tpacpi_hkey_event_t {
>>
>> /* Misc */
>> TP_HKEY_EV_RFKILL_CHANGED = 0x7000, /* rfkill switch changed */
>> + TP_HKEY_EV_TRACKPOINT_DOUBLETAP = 0x8036, /* doubletap on Trackpoint*/
>> };
>>
>> /****************************************************************************
>> @@ -4081,6 +4082,22 @@ static void hotkey_notify(struct ibm_struct *ibm, u32 event)
>> break;
>> }
>> fallthrough; /* to default */
>
> This now no longer fallsthrough to default. IMHO the best thing to do
> here is add a new preparation patch which initializes known_ev to false
> inside the while before the switch-case (together with the send_acpi_ev
> and ignore_acpi_ev init). and then change this fallthrough to a break
> in the preparation patch. You can then also remove the default case
> altogether in this prep patch.
>
Ack - that makes sense. I'll look at doing that.
>> + case 8:
>> + /* 0x8036: Trackpoint doubletaps */
>> + if (hkey == TP_HKEY_EV_TRACKPOINT_DOUBLETAP) {
>> + send_acpi_ev = true;
>> + ignore_acpi_ev = false;
>
> These 2 values are set as the default above the switch-case, please
> drop these 2 lines.
Agreed. Will change.
>
>> + known_ev = true;
>> + /* Send to user space */
>> + mutex_lock(&tpacpi_inputdev_send_mutex);
>> + input_report_key(tpacpi_inputdev, KEY_DOUBLECLICK, 1);
>> + input_sync(tpacpi_inputdev);
>> + input_report_key(tpacpi_inputdev, KEY_DOUBLECLICK, 0);
>> + input_sync(tpacpi_inputdev);
>> + mutex_unlock(&tpacpi_inputdev_send_mutex);
>
> This code duplicates tpacpi_input_send_key(), what you want to do here
> is define a hotkey_keycode_map scancode range for new 0x8xxx codes like how this
> was done when extended scancodes where added to deal with the new 0x13xx hotkey
> event codes for the 2017+ models.
>
> See commit 696c6523ec8f ("platform/x86: thinkpad_acpi: add mapping for
> new hotkeys")
>
> Despite re-using tpacpi_input_send_key() there are 2 reasons why we want
> scancodes for these new "keys".
>
> 1. By adding the keys to the hotkey_keycode_map they automatically
> also get input_set_capability(tpacpi_inputdev, EV_KEY, hotkey_keycode_map[i]);
> called on them advertising to userspace that tpacpi_inputdev can actually
> generate these keypresses. Something which is currently lacking from your
> patch. Related to this did you test this with evtest? I think that the input
> core will suppress the events when you do not set the capability ?
>
> 2. This allows remapping scancodes to different KEY_foo values with hwdb
> entries.
>
Will look into doing this.
There was a reason originally I did it like this, but I can't remember what it was. I'll revisit it.
I did test with evtest but I ended up having to cheat as there's quite a few layers in userspace and I got a bit bogged down chewing my way through those (building them against the right headers etc).
I ended up using an already existing code to make sure it was doing the right thing in the driver - and then assumed that once the keycode was 'released', and the different user space projects updated per normal procedure, it would work. It's possible it meant I bypassed/missed this issue so I'll retry once I've made the updates.
Mark
|
|
From: Hans de G. <hde...@re...> - 2024-04-08 13:13:24
|
Hi,
On 3/24/24 10:08 PM, Mark Pearson wrote:
> 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 <mpe...@sq...>
> Signed-off-by: Vishnu Sankar <vs...@le...>
> ---
> drivers/platform/x86/thinkpad_acpi.c | 24 +++++++++++++++++-------
> 1 file changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
> index 854ce971bde2..21756aa3d28d 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c
> @@ -167,6 +167,7 @@ enum tpacpi_hkey_event_t {
> TP_HKEY_EV_VOL_MUTE = 0x1017, /* Mixer output mute */
> TP_HKEY_EV_PRIVACYGUARD_TOGGLE = 0x130f, /* Toggle priv.guard on/off */
> TP_HKEY_EV_AMT_TOGGLE = 0x131a, /* Toggle AMT on/off */
> + TP_HKEY_EV_DOUBLETAP_TOGGLE = 0x131c, /* Toggle trackpoint doubletap on/off */
> TP_HKEY_EV_PROFILE_TOGGLE = 0x131f, /* Toggle platform profile */
>
> /* Reasons for waking up from S3/S4 */
> @@ -354,6 +355,7 @@ static struct {
> u32 hotkey_poll_active:1;
> u32 has_adaptive_kbd:1;
> u32 kbd_lang:1;
> + u32 trackpoint_doubletap:1;
> struct quirk_entry *quirks;
> } tp_features;
>
> @@ -3598,6 +3600,9 @@ static int __init hotkey_init(struct ibm_init_struct *iibm)
>
> hotkey_poll_setup_safe(true);
>
> + /* Enable doubletap by default */
> + tp_features.trackpoint_doubletap = 1;
> +
> return 0;
> }
>
> @@ -3739,6 +3744,7 @@ static bool hotkey_notify_extended_hotkey(const u32 hkey)
> case TP_HKEY_EV_PRIVACYGUARD_TOGGLE:
> case TP_HKEY_EV_AMT_TOGGLE:
> case TP_HKEY_EV_PROFILE_TOGGLE:
> + case TP_HKEY_EV_DOUBLETAP_TOGGLE:
> tpacpi_driver_event(hkey);
> return true;
> }
> @@ -4092,13 +4098,15 @@ static void hotkey_notify(struct ibm_struct *ibm, u32 event)
> send_acpi_ev = true;
> ignore_acpi_ev = false;
> known_ev = true;
> - /* Send to user space */
> - mutex_lock(&tpacpi_inputdev_send_mutex);
> - input_report_key(tpacpi_inputdev, KEY_DOUBLECLICK, 1);
> - input_sync(tpacpi_inputdev);
> - input_report_key(tpacpi_inputdev, KEY_DOUBLECLICK, 0);
> - input_sync(tpacpi_inputdev);
> - mutex_unlock(&tpacpi_inputdev_send_mutex);
> + if (tp_features.trackpoint_doubletap) {
> + /* Send to user space */
> + mutex_lock(&tpacpi_inputdev_send_mutex);
> + input_report_key(tpacpi_inputdev, KEY_DOUBLECLICK, 1);
> + input_sync(tpacpi_inputdev);
> + input_report_key(tpacpi_inputdev, KEY_DOUBLECLICK, 0);
> + input_sync(tpacpi_inputdev);
> + mutex_unlock(&tpacpi_inputdev_send_mutex);
> + }
> break;
> }
> fallthrough; /* to default */
This chunk will need to change after incorporating my review comments into
patch 2/4. With that said this looks good to me:
Reviewed-by: Hans de Goede <hde...@re...>
Regards,
Hans
> @@ -11228,6 +11236,8 @@ static void tpacpi_driver_event(const unsigned int hkey_event)
> /* Notify user space the profile changed */
> platform_profile_notify();
> }
> + if (hkey_event == TP_HKEY_EV_DOUBLETAP_TOGGLE)
> + tp_features.trackpoint_doubletap = !tp_features.trackpoint_doubletap;
> }
>
> static void hotkey_driver_event(const unsigned int scancode)
|
|
From: Hans de G. <hde...@re...> - 2024-04-08 13:11:57
|
Hi,
On 3/24/24 10:08 PM, Mark Pearson wrote:
> 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 generating a
> SYS_DEBUG_INFO keycode to userspace.
>
> Signed-off-by: Mark Pearson <mpe...@sq...>
> Signed-off-by: Nitin Joshi <nj...@le...>
> ---
> drivers/platform/x86/thinkpad_acpi.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
> index 2bbb32c898e9..854ce971bde2 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c
> @@ -1787,6 +1787,7 @@ enum { /* hot key scan codes (derived from ACPI DSDT) */
> TP_ACPI_HOTKEYSCAN_NOTIFICATION_CENTER,
> TP_ACPI_HOTKEYSCAN_PICKUP_PHONE,
> TP_ACPI_HOTKEYSCAN_HANGUP_PHONE,
> + TP_ACPI_HOTKEYSCAN_SYS_DEBUG_INFO = 81,
>
> /* Hotkey keymap size */
> TPACPI_HOTKEY_MAP_LEN
> @@ -3337,6 +3338,9 @@ static int __init hotkey_init(struct ibm_init_struct *iibm)
> KEY_NOTIFICATION_CENTER, /* Notification Center */
> KEY_PICKUP_PHONE, /* Answer incoming call */
> KEY_HANGUP_PHONE, /* Decline incoming call */
> + KEY_UNKNOWN, /* AMT Toggle (event), 0x31A */
> + KEY_UNKNOWN, KEY_UNKNOWN,
> + KEY_SYS_DEBUG_INFO, /* System debug info, 0x31D */
> },
> };
>
Looking at the next patch 0x131c is TP_HKEY_EV_DOUBLETAP_TOGGLE and 0x131a is
TP_HKEY_EV_AMT_TOGGLE based on this please change this to:
KEY_NOTIFICATION_CENTER, /* Notification Center */
KEY_PICKUP_PHONE, /* Answer incoming call */
KEY_HANGUP_PHONE, /* Decline incoming call */
KEY_UNKNOWN, /* TP_HKEY_EV_AMT_TOGGLE handled in driver, 0x31a */
KEY_UNKNOWN, /* ?, 0X31b */
KEY_UNKNOWN, /* TP_HKEY_EV_DOUBLETAP_TOGGLE handled in driver, 0x31c */
KEY_SYS_DEBUG_INFO, /* System debug info, 0x31d */
},
Regards,
Hans
|
|
From: Hans de G. <hde...@re...> - 2024-04-08 13:04:41
|
Hi Mark,
On 3/24/24 10:07 PM, Mark Pearson wrote:
> Lenovo trackpoints are adding the ability to generate a doubletap event.
> This handles the doubletap event and sends the KEY_DOUBLECLICK event to
> userspace.
>
> Signed-off-by: Mark Pearson <mpe...@sq...>
> Signed-off-by: Vishnu Sankar <vs...@le...>
> ---
> drivers/platform/x86/thinkpad_acpi.c | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
> index 82429e59999d..2bbb32c898e9 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c
> @@ -232,6 +232,7 @@ enum tpacpi_hkey_event_t {
>
> /* Misc */
> TP_HKEY_EV_RFKILL_CHANGED = 0x7000, /* rfkill switch changed */
> + TP_HKEY_EV_TRACKPOINT_DOUBLETAP = 0x8036, /* doubletap on Trackpoint*/
> };
>
> /****************************************************************************
> @@ -4081,6 +4082,22 @@ static void hotkey_notify(struct ibm_struct *ibm, u32 event)
> break;
> }
> fallthrough; /* to default */
This now no longer fallsthrough to default. IMHO the best thing to do
here is add a new preparation patch which initializes known_ev to false
inside the while before the switch-case (together with the send_acpi_ev
and ignore_acpi_ev init). and then change this fallthrough to a break
in the preparation patch. You can then also remove the default case
altogether in this prep patch.
> + case 8:
> + /* 0x8036: Trackpoint doubletaps */
> + if (hkey == TP_HKEY_EV_TRACKPOINT_DOUBLETAP) {
> + send_acpi_ev = true;
> + ignore_acpi_ev = false;
These 2 values are set as the default above the switch-case, please
drop these 2 lines.
> + known_ev = true;
> + /* Send to user space */
> + mutex_lock(&tpacpi_inputdev_send_mutex);
> + input_report_key(tpacpi_inputdev, KEY_DOUBLECLICK, 1);
> + input_sync(tpacpi_inputdev);
> + input_report_key(tpacpi_inputdev, KEY_DOUBLECLICK, 0);
> + input_sync(tpacpi_inputdev);
> + mutex_unlock(&tpacpi_inputdev_send_mutex);
This code duplicates tpacpi_input_send_key(), what you want to do here
is define a hotkey_keycode_map scancode range for new 0x8xxx codes like how this
was done when extended scancodes where added to deal with the new 0x13xx hotkey
event codes for the 2017+ models.
See commit 696c6523ec8f ("platform/x86: thinkpad_acpi: add mapping for new hotkeys")
Despite re-using tpacpi_input_send_key() there are 2 reasons why we want
scancodes for these new "keys".
1. By adding the keys to the hotkey_keycode_map they automatically
also get input_set_capability(tpacpi_inputdev, EV_KEY, hotkey_keycode_map[i]);
called on them advertising to userspace that tpacpi_inputdev can actually
generate these keypresses. Something which is currently lacking from your
patch. Related to this did you test this with evtest? I think that the input
core will suppress the events when you do not set the capability ?
2. This allows remapping scancodes to different KEY_foo values with hwdb
entries.
Regards,
Hans
> + break;
> + }
> + fallthrough; /* to default */
> default:
> known_ev = false;
> }
|
|
From: Hans de G. <hde...@re...> - 2024-04-08 12:46:15
|
Hi, On 3/24/24 10:07 PM, Mark Pearson wrote: > Add support for new input events on Lenovo laptops that need exporting to > user space. > > Lenovo trackpoints are adding the ability to generate a doubletap event. > Add a new keycode to allow this to be used by userspace. > > Lenovo support is using FN+N with Windows to collect needed details for > support cases. Add a keycode so that we'll be able to provide similar > support on Linux. > > Suggested-by: Peter Hutterer <pet...@re...> > > Signed-off-by: Mark Pearson <mpe...@sq...> > Signed-off-by: Nitin Joshi <nj...@le...> > Signed-off-by: Vishnu Sankar <vs...@le...> Thanks, patch looks good to me: Reviewed-by: Hans de Goede <hde...@re...> Dmitry, can I have your ack for merging this change through the pdx86 tree (since the first driver using these is a pdx86 driver) ? Regards, Hans > --- > include/uapi/linux/input-event-codes.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h > index 03edf2ccdf6c..bd3baca95749 100644 > --- a/include/uapi/linux/input-event-codes.h > +++ b/include/uapi/linux/input-event-codes.h > @@ -686,6 +686,8 @@ > #define KEY_SIDEVU_SONAR 0x287 > #define KEY_NAV_INFO 0x288 > #define KEY_BRIGHTNESS_MENU 0x289 > +#define KEY_DOUBLECLICK 0x28a > +#define KEY_SYS_DEBUG_INFO 0x28b > > /* > * Some keyboards have keys which do not have a defined meaning, these keys |
|
From: Mark P. <mpe...@sq...> - 2024-03-24 21:26:27
|
Lenovo trackpoints are adding the ability to generate a doubletap event.
This handles the doubletap event and sends the KEY_DOUBLECLICK event to
userspace.
Signed-off-by: Mark Pearson <mpe...@sq...>
Signed-off-by: Vishnu Sankar <vs...@le...>
---
drivers/platform/x86/thinkpad_acpi.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
index 82429e59999d..2bbb32c898e9 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -232,6 +232,7 @@ enum tpacpi_hkey_event_t {
/* Misc */
TP_HKEY_EV_RFKILL_CHANGED = 0x7000, /* rfkill switch changed */
+ TP_HKEY_EV_TRACKPOINT_DOUBLETAP = 0x8036, /* doubletap on Trackpoint*/
};
/****************************************************************************
@@ -4081,6 +4082,22 @@ static void hotkey_notify(struct ibm_struct *ibm, u32 event)
break;
}
fallthrough; /* to default */
+ case 8:
+ /* 0x8036: Trackpoint doubletaps */
+ if (hkey == TP_HKEY_EV_TRACKPOINT_DOUBLETAP) {
+ send_acpi_ev = true;
+ ignore_acpi_ev = false;
+ known_ev = true;
+ /* Send to user space */
+ mutex_lock(&tpacpi_inputdev_send_mutex);
+ input_report_key(tpacpi_inputdev, KEY_DOUBLECLICK, 1);
+ input_sync(tpacpi_inputdev);
+ input_report_key(tpacpi_inputdev, KEY_DOUBLECLICK, 0);
+ input_sync(tpacpi_inputdev);
+ mutex_unlock(&tpacpi_inputdev_send_mutex);
+ break;
+ }
+ fallthrough; /* to default */
default:
known_ev = false;
}
--
2.44.0
|
|
From: Mark P. <mpe...@sq...> - 2024-03-24 21:26:27
|
Hi,
This series adds support trackpoint doubletap and some new hotkey
functionality which is being added on Lenovo laptops.
- FN+N - display system debug info. Used by customer support with
Windows users.
- FN+G - disable/enable trackpoint doubletap.
We combined these into a series because there was commonality between
what the different features were doing.
Please let us know if you would prefer to have them as separate commits.
Many thanks to Peter Hutterer and Benjamin Tissoires for the guidance on
what would be best for exporting the events from trackpoint doubletap to
userspace. Any mistakes are ours :)
Features have been tested on Z13 G2 (doubletap & FN+G) and X1 Carbon
G12 (FN+N)
Mark Pearson (4):
Input: Add trackpoint doubletap and system debug info keycodes
platform/x86: thinkpad_acpi: Support for trackpoint doubletap
platform/x86: thinkpad_acpi: Support for system debug info hotkey
platform/x86: thinkpad_acpi: Support hotkey to disable trackpoint
doubletap
drivers/platform/x86/thinkpad_acpi.c | 31 ++++++++++++++++++++++++++
include/uapi/linux/input-event-codes.h | 2 ++
2 files changed, 33 insertions(+)
--
2.44.0
|
|
From: Mark P. <mpe...@sq...> - 2024-03-24 21:26:23
|
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 <mpe...@sq...>
Signed-off-by: Vishnu Sankar <vs...@le...>
---
drivers/platform/x86/thinkpad_acpi.c | 24 +++++++++++++++++-------
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
index 854ce971bde2..21756aa3d28d 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -167,6 +167,7 @@ enum tpacpi_hkey_event_t {
TP_HKEY_EV_VOL_MUTE = 0x1017, /* Mixer output mute */
TP_HKEY_EV_PRIVACYGUARD_TOGGLE = 0x130f, /* Toggle priv.guard on/off */
TP_HKEY_EV_AMT_TOGGLE = 0x131a, /* Toggle AMT on/off */
+ TP_HKEY_EV_DOUBLETAP_TOGGLE = 0x131c, /* Toggle trackpoint doubletap on/off */
TP_HKEY_EV_PROFILE_TOGGLE = 0x131f, /* Toggle platform profile */
/* Reasons for waking up from S3/S4 */
@@ -354,6 +355,7 @@ static struct {
u32 hotkey_poll_active:1;
u32 has_adaptive_kbd:1;
u32 kbd_lang:1;
+ u32 trackpoint_doubletap:1;
struct quirk_entry *quirks;
} tp_features;
@@ -3598,6 +3600,9 @@ static int __init hotkey_init(struct ibm_init_struct *iibm)
hotkey_poll_setup_safe(true);
+ /* Enable doubletap by default */
+ tp_features.trackpoint_doubletap = 1;
+
return 0;
}
@@ -3739,6 +3744,7 @@ static bool hotkey_notify_extended_hotkey(const u32 hkey)
case TP_HKEY_EV_PRIVACYGUARD_TOGGLE:
case TP_HKEY_EV_AMT_TOGGLE:
case TP_HKEY_EV_PROFILE_TOGGLE:
+ case TP_HKEY_EV_DOUBLETAP_TOGGLE:
tpacpi_driver_event(hkey);
return true;
}
@@ -4092,13 +4098,15 @@ static void hotkey_notify(struct ibm_struct *ibm, u32 event)
send_acpi_ev = true;
ignore_acpi_ev = false;
known_ev = true;
- /* Send to user space */
- mutex_lock(&tpacpi_inputdev_send_mutex);
- input_report_key(tpacpi_inputdev, KEY_DOUBLECLICK, 1);
- input_sync(tpacpi_inputdev);
- input_report_key(tpacpi_inputdev, KEY_DOUBLECLICK, 0);
- input_sync(tpacpi_inputdev);
- mutex_unlock(&tpacpi_inputdev_send_mutex);
+ if (tp_features.trackpoint_doubletap) {
+ /* Send to user space */
+ mutex_lock(&tpacpi_inputdev_send_mutex);
+ input_report_key(tpacpi_inputdev, KEY_DOUBLECLICK, 1);
+ input_sync(tpacpi_inputdev);
+ input_report_key(tpacpi_inputdev, KEY_DOUBLECLICK, 0);
+ input_sync(tpacpi_inputdev);
+ mutex_unlock(&tpacpi_inputdev_send_mutex);
+ }
break;
}
fallthrough; /* to default */
@@ -11228,6 +11236,8 @@ static void tpacpi_driver_event(const unsigned int hkey_event)
/* Notify user space the profile changed */
platform_profile_notify();
}
+ if (hkey_event == TP_HKEY_EV_DOUBLETAP_TOGGLE)
+ tp_features.trackpoint_doubletap = !tp_features.trackpoint_doubletap;
}
static void hotkey_driver_event(const unsigned int scancode)
--
2.44.0
|
|
From: Mark P. <mpe...@sq...> - 2024-03-24 21:26:23
|
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 generating a
SYS_DEBUG_INFO keycode to userspace.
Signed-off-by: Mark Pearson <mpe...@sq...>
Signed-off-by: Nitin Joshi <nj...@le...>
---
drivers/platform/x86/thinkpad_acpi.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
index 2bbb32c898e9..854ce971bde2 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -1787,6 +1787,7 @@ enum { /* hot key scan codes (derived from ACPI DSDT) */
TP_ACPI_HOTKEYSCAN_NOTIFICATION_CENTER,
TP_ACPI_HOTKEYSCAN_PICKUP_PHONE,
TP_ACPI_HOTKEYSCAN_HANGUP_PHONE,
+ TP_ACPI_HOTKEYSCAN_SYS_DEBUG_INFO = 81,
/* Hotkey keymap size */
TPACPI_HOTKEY_MAP_LEN
@@ -3337,6 +3338,9 @@ static int __init hotkey_init(struct ibm_init_struct *iibm)
KEY_NOTIFICATION_CENTER, /* Notification Center */
KEY_PICKUP_PHONE, /* Answer incoming call */
KEY_HANGUP_PHONE, /* Decline incoming call */
+ KEY_UNKNOWN, /* AMT Toggle (event), 0x31A */
+ KEY_UNKNOWN, KEY_UNKNOWN,
+ KEY_SYS_DEBUG_INFO, /* System debug info, 0x31D */
},
};
--
2.44.0
|
|
From: Mark P. <mpe...@sq...> - 2024-03-24 21:22:02
|
Add support for new input events on Lenovo laptops that need exporting to user space. Lenovo trackpoints are adding the ability to generate a doubletap event. Add a new keycode to allow this to be used by userspace. Lenovo support is using FN+N with Windows to collect needed details for support cases. Add a keycode so that we'll be able to provide similar support on Linux. Suggested-by: Peter Hutterer <pet...@re...> Signed-off-by: Mark Pearson <mpe...@sq...> Signed-off-by: Nitin Joshi <nj...@le...> Signed-off-by: Vishnu Sankar <vs...@le...> --- include/uapi/linux/input-event-codes.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h index 03edf2ccdf6c..bd3baca95749 100644 --- a/include/uapi/linux/input-event-codes.h +++ b/include/uapi/linux/input-event-codes.h @@ -686,6 +686,8 @@ #define KEY_SIDEVU_SONAR 0x287 #define KEY_NAV_INFO 0x288 #define KEY_BRIGHTNESS_MENU 0x289 +#define KEY_DOUBLECLICK 0x28a +#define KEY_SYS_DEBUG_INFO 0x28b /* * Some keyboards have keys which do not have a defined meaning, these keys -- 2.44.0 |
|
From: Hans de G. <hde...@re...> - 2024-01-24 11:36:29
|
Hi Rafał, On 1/23/24 23:25, Rafał Lalik wrote: > Hi, > > Thanks for reply. > > I cannot recall it now but I think the issue hit me with one of the 6.x version and stays until now, but I don't remember when one exactly. > > I am not very familiar with kernel internals. Do you have any idea how I could start digging it? > > What part of kernel I could look into to make it perhaps working again or being closer to solution? I have no idea. You are the only person reporting this, so this likely is something specific to your setup. It could even mean your laptop is starting to break down / be a hardware defect. Maybe you can try gentoo's pre-build kernel binaries and see if those have the same issue ? Or try setting your use-flags and the kernel-config to the default gentoo settings ? Basically for starters I would try to remove any configuration which is special to your installation. I expect that will lead to a stable setup again (unless there really is a hw (RAM?) defect). Then after this you can re-introduce any customizations you have done *one at a time* until you have found what causes the problem and then we can see from there. Regards, Hans > wt., 23 sty 2024, 11:02 użytkownik Hans de Goede <hde...@re... <mailto:hde...@re...>> napisał: > > Hi, > > On 1/23/24 02:22, Rafal Lalik wrote: > > Hi, > > > > I am experiencing issues with tpacpi module. It started with one of the kernel-6 versions, but cannot pin point exact version. It stated with being unable to hibernate the system. I figured out it was due to one of the udev-worker processes being in the 'uninterruptible sleep' state. > > > > I dig the issue further and found out that there are issues with the thinkpad_acpi module which crashes on loading. it was autoloaded so I blacklisted it and the hibernation issues were gone. > > > > But now with it being blacklisted on boot, I ma trying to load it manually with following result. > > > > # modprobe thinkpad_acpi > > Killed > > The crash seems to happen on module loading time, before even > the module's init() function is run. > > You mention that you are seeing this with multiple kernel > versions right ? > > So I guess this is something specific to your kernel configuration > and/or the compiler you are using. > > Regards, > > Hans > > > > > dmesg shows me this: > > > > [ 590.531829] BUG: unable to handle page fault for address: ffffc900033ebe98 > > [ 590.531838] #PF: supervisor read access in kernel mode > > [ 590.531841] #PF: error_code(0x0000) - not-present page > > [ 590.531845] PGD 100000067 P4D 100000067 PUD 10012c067 PMD 107853067 PTE 0 > > [ 590.531852] Oops: 0000 [#2] PREEMPT SMP PTI > > [ 590.531874] CPU: 0 PID: 10985 Comm: modprobe Tainted: P UD O 6.7.1-gentoo-r1 #1 > > [ 590.531878] Hardware name: LENOVO 20ARS0XL00/20ARS0XL00, BIOS GJETA4WW (2.54 ) 03/27/2020 > > [ 590.531880] RIP: 0010:idempotent_init_module+0xac/0x290 > > [ 590.531887] Code: 7a ca ae 00 49 c1 ed 38 31 c9 4a 8b 14 ed 20 31 d4 82 4e 8d 24 ed 20 31 d4 82 48 8d 42 f8 48 85 d2 48 0f 44 c1 48 85 c0 74 1b <4c> 3b 38 0f 84 bf 00 00 00 48 8b 40 08 48 85 c0 74 09 48 83 e8 08 > > [ 590.531891] RSP: 0018:ffffc90003fcfe98 EFLAGS: 00010282 > > [ 590.531895] RAX: ffffc900033ebe98 RBX: 0000562e105ae560 RCX: 0000000000000000 > > [ 590.531898] RDX: ffffc900033ebea0 RSI: ffffffff822467bd RDI: 0000000000000000 > > [ 590.531900] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 > > [ 590.531902] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82d43398 > > [ 590.531905] R13: 000000000000004f R14: ffff888233f34000 R15: ffff888207e67338 > > [ 590.531907] FS: 00007ff004bd5c40(0000) GS:ffff888332200000(0000) knlGS:0000000000000000 > > [ 590.531910] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > [ 590.531913] CR2: ffffc900033ebe98 CR3: 000000012dcc0004 CR4: 00000000001706f0 > > [ 590.531915] Call Trace: > > [ 590.531918] <TASK> > > [ 590.531921] ? __die+0x1a/0x60 > > [ 590.531927] ? page_fault_oops+0x158/0x440 > > [ 590.531932] ? fixup_exception+0x1d/0x2f0 > > [ 590.531936] ? exc_page_fault+0x7e/0x130 > > [ 590.531942] ? asm_exc_page_fault+0x22/0x30 > > [ 590.531949] ? idempotent_init_module+0xac/0x290 > > [ 590.531953] ? idempotent_init_module+0x86/0x290 > > [ 590.531957] __x64_sys_finit_module+0x4d/0x80 > > [ 590.531962] do_syscall_64+0x47/0xe0 > > [ 590.531966] entry_SYSCALL_64_after_hwframe+0x4b/0x53 > > [ 590.531971] RIP: 0033:0x7ff004cdcad9 > > [ 590.531975] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 27 73 0c 00 f7 d8 64 89 01 48 > > [ 590.531978] RSP: 002b:00007ffedaa273a8 EFLAGS: 00000202 ORIG_RAX: 0000000000000139 > > [ 590.531982] RAX: ffffffffffffffda RBX: 0000562e105adc90 RCX: 00007ff004cdcad9 > > [ 590.531984] RDX: 0000000000000000 RSI: 0000562e105ae560 RDI: 0000000000000003 > > [ 590.531986] RBP: 0000000000000000 R08: 00007ff004da4b20 R09: 000000000000003f > > [ 590.531988] R10: 0000000000000050 R11: 0000000000000202 R12: 0000562e105ae560 > > [ 590.531991] R13: 0000000000040000 R14: 0000562e105addc0 R15: 000000000000003f > > [ 590.531994] </TASK> > > [ 590.531996] Modules linked in: thinkpad_acpi(+) nvram ledtrig_audio platform_profile 8021q uinput nvidia(PO) fuse nft_chain_nat nf_nat hid_lenovo bbswitch(O) snd_aloop rfcomm bluetooth ecdh_generic ecc uvcvideo videobuf2_vmalloc videobuf2_memops uvc videobuf2_v4l2 videodev videobuf2_common mc snd_hda_codec_hdmi dm_multipath dm_mod dax i2c_dev intel_rapl_msr rtsx_pci_sdmmc intel_rapl_common x86_pkg_temp_thermal intel_powerclamp iwlmvm coretemp kvm_intel kvm irqbypass input_leds snd_hda_codec_generic led_class rtsx_pci iwlwifi i915 tpm_tis tpm_tis_core snd_hda_intel i2c_algo_bit snd_intel_dspcfg drm_buddy e1000e snd_hda_codec drm_display_helper snd_hwdep ttm snd_hda_core [last unloaded: nvidia(PO)] > > [ 590.532048] CR2: ffffc900033ebe98 > > [ 590.532051] ---[ end trace 0000000000000000 ]--- > > [ 590.532054] RIP: 0010:tpacpi_rfk_procfs_write+0x90/0x140 [thinkpad_acpi] > > [ 590.532076] Code: c4 08 89 d8 5b 5d 41 5c 41 5d c3 bd 01 00 00 00 eb 9e 83 fd ff 74 e7 f6 05 25 70 00 00 80 75 54 4a 8b 04 e5 70 85 4b a1 89 ef <48> 8b 40 10 48 8b 40 08 e8 33 ce 78 e0 4a 8b 2c e5 70 85 4b a1 89 > > [ 590.532079] RSP: 0018:ffffc900033ebc78 EFLAGS: 00010246 > > [ 590.532082] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000065 > > [ 590.532084] RDX: 0000000000000006 RSI: ffffffffa14bc0d7 RDI: 0000000000000001 > > [ 590.532086] RBP: 0000000000000001 R08: ffffffffa14cd096 R09: 000000000000002c > > [ 590.532089] R10: 0000000000000000 R11: ffffc900033eba60 R12: 0000000000000000 > > [ 590.532091] R13: 0000000000000124 R14: ffffffffa14cd090 R15: 0000000000000000 > > [ 590.532093] FS: 00007ff004bd5c40(0000) GS:ffff888332200000(0000) knlGS:0000000000000000 > > [ 590.532096] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > [ 590.532098] CR2: ffffc900033ebe98 CR3: 000000012dcc0004 CR4: 00000000001706f0 > > [ 590.532101] note: modprobe[10985] exited with irqs disabled > > [ 590.532103] note: modprobe[10985] exited with preempt_count 1 > > > > > > > > Dunno whetehr this is kernel bug or some other problem with my kernel. So just let you know and please give me some ideas here. > > > > regards, > > Rafał > > > |
|
From: Hans de G. <hde...@re...> - 2024-01-23 10:03:11
|
Hi, On 1/23/24 02:22, Rafal Lalik wrote: > Hi, > > I am experiencing issues with tpacpi module. It started with one of the kernel-6 versions, but cannot pin point exact version. It stated with being unable to hibernate the system. I figured out it was due to one of the udev-worker processes being in the 'uninterruptible sleep' state. > > I dig the issue further and found out that there are issues with the thinkpad_acpi module which crashes on loading. it was autoloaded so I blacklisted it and the hibernation issues were gone. > > But now with it being blacklisted on boot, I ma trying to load it manually with following result. > > # modprobe thinkpad_acpi > Killed The crash seems to happen on module loading time, before even the module's init() function is run. You mention that you are seeing this with multiple kernel versions right ? So I guess this is something specific to your kernel configuration and/or the compiler you are using. Regards, Hans > dmesg shows me this: > > [ 590.531829] BUG: unable to handle page fault for address: ffffc900033ebe98 > [ 590.531838] #PF: supervisor read access in kernel mode > [ 590.531841] #PF: error_code(0x0000) - not-present page > [ 590.531845] PGD 100000067 P4D 100000067 PUD 10012c067 PMD 107853067 PTE 0 > [ 590.531852] Oops: 0000 [#2] PREEMPT SMP PTI > [ 590.531874] CPU: 0 PID: 10985 Comm: modprobe Tainted: P UD O 6.7.1-gentoo-r1 #1 > [ 590.531878] Hardware name: LENOVO 20ARS0XL00/20ARS0XL00, BIOS GJETA4WW (2.54 ) 03/27/2020 > [ 590.531880] RIP: 0010:idempotent_init_module+0xac/0x290 > [ 590.531887] Code: 7a ca ae 00 49 c1 ed 38 31 c9 4a 8b 14 ed 20 31 d4 82 4e 8d 24 ed 20 31 d4 82 48 8d 42 f8 48 85 d2 48 0f 44 c1 48 85 c0 74 1b <4c> 3b 38 0f 84 bf 00 00 00 48 8b 40 08 48 85 c0 74 09 48 83 e8 08 > [ 590.531891] RSP: 0018:ffffc90003fcfe98 EFLAGS: 00010282 > [ 590.531895] RAX: ffffc900033ebe98 RBX: 0000562e105ae560 RCX: 0000000000000000 > [ 590.531898] RDX: ffffc900033ebea0 RSI: ffffffff822467bd RDI: 0000000000000000 > [ 590.531900] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 > [ 590.531902] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82d43398 > [ 590.531905] R13: 000000000000004f R14: ffff888233f34000 R15: ffff888207e67338 > [ 590.531907] FS: 00007ff004bd5c40(0000) GS:ffff888332200000(0000) knlGS:0000000000000000 > [ 590.531910] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 590.531913] CR2: ffffc900033ebe98 CR3: 000000012dcc0004 CR4: 00000000001706f0 > [ 590.531915] Call Trace: > [ 590.531918] <TASK> > [ 590.531921] ? __die+0x1a/0x60 > [ 590.531927] ? page_fault_oops+0x158/0x440 > [ 590.531932] ? fixup_exception+0x1d/0x2f0 > [ 590.531936] ? exc_page_fault+0x7e/0x130 > [ 590.531942] ? asm_exc_page_fault+0x22/0x30 > [ 590.531949] ? idempotent_init_module+0xac/0x290 > [ 590.531953] ? idempotent_init_module+0x86/0x290 > [ 590.531957] __x64_sys_finit_module+0x4d/0x80 > [ 590.531962] do_syscall_64+0x47/0xe0 > [ 590.531966] entry_SYSCALL_64_after_hwframe+0x4b/0x53 > [ 590.531971] RIP: 0033:0x7ff004cdcad9 > [ 590.531975] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 27 73 0c 00 f7 d8 64 89 01 48 > [ 590.531978] RSP: 002b:00007ffedaa273a8 EFLAGS: 00000202 ORIG_RAX: 0000000000000139 > [ 590.531982] RAX: ffffffffffffffda RBX: 0000562e105adc90 RCX: 00007ff004cdcad9 > [ 590.531984] RDX: 0000000000000000 RSI: 0000562e105ae560 RDI: 0000000000000003 > [ 590.531986] RBP: 0000000000000000 R08: 00007ff004da4b20 R09: 000000000000003f > [ 590.531988] R10: 0000000000000050 R11: 0000000000000202 R12: 0000562e105ae560 > [ 590.531991] R13: 0000000000040000 R14: 0000562e105addc0 R15: 000000000000003f > [ 590.531994] </TASK> > [ 590.531996] Modules linked in: thinkpad_acpi(+) nvram ledtrig_audio platform_profile 8021q uinput nvidia(PO) fuse nft_chain_nat nf_nat hid_lenovo bbswitch(O) snd_aloop rfcomm bluetooth ecdh_generic ecc uvcvideo videobuf2_vmalloc videobuf2_memops uvc videobuf2_v4l2 videodev videobuf2_common mc snd_hda_codec_hdmi dm_multipath dm_mod dax i2c_dev intel_rapl_msr rtsx_pci_sdmmc intel_rapl_common x86_pkg_temp_thermal intel_powerclamp iwlmvm coretemp kvm_intel kvm irqbypass input_leds snd_hda_codec_generic led_class rtsx_pci iwlwifi i915 tpm_tis tpm_tis_core snd_hda_intel i2c_algo_bit snd_intel_dspcfg drm_buddy e1000e snd_hda_codec drm_display_helper snd_hwdep ttm snd_hda_core [last unloaded: nvidia(PO)] > [ 590.532048] CR2: ffffc900033ebe98 > [ 590.532051] ---[ end trace 0000000000000000 ]--- > [ 590.532054] RIP: 0010:tpacpi_rfk_procfs_write+0x90/0x140 [thinkpad_acpi] > [ 590.532076] Code: c4 08 89 d8 5b 5d 41 5c 41 5d c3 bd 01 00 00 00 eb 9e 83 fd ff 74 e7 f6 05 25 70 00 00 80 75 54 4a 8b 04 e5 70 85 4b a1 89 ef <48> 8b 40 10 48 8b 40 08 e8 33 ce 78 e0 4a 8b 2c e5 70 85 4b a1 89 > [ 590.532079] RSP: 0018:ffffc900033ebc78 EFLAGS: 00010246 > [ 590.532082] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000065 > [ 590.532084] RDX: 0000000000000006 RSI: ffffffffa14bc0d7 RDI: 0000000000000001 > [ 590.532086] RBP: 0000000000000001 R08: ffffffffa14cd096 R09: 000000000000002c > [ 590.532089] R10: 0000000000000000 R11: ffffc900033eba60 R12: 0000000000000000 > [ 590.532091] R13: 0000000000000124 R14: ffffffffa14cd090 R15: 0000000000000000 > [ 590.532093] FS: 00007ff004bd5c40(0000) GS:ffff888332200000(0000) knlGS:0000000000000000 > [ 590.532096] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 590.532098] CR2: ffffc900033ebe98 CR3: 000000012dcc0004 CR4: 00000000001706f0 > [ 590.532101] note: modprobe[10985] exited with irqs disabled > [ 590.532103] note: modprobe[10985] exited with preempt_count 1 > > > > Dunno whetehr this is kernel bug or some other problem with my kernel. So just let you know and please give me some ideas here. > > regards, > Rafał > |
|
From: Hans de G. <hde...@re...> - 2024-01-14 18:57:08
|
Hi,
On 1/14/24 18:14, Heiner Kallweit wrote:
> Since 64f67b5240db ("leds: trigger: audio: Add an activate callback to
> ensure the initial brightness is set") the audio triggers have an
> activate callback which sets the LED brightness as soon as the
> (default) trigger is bound to the LED device. So we can remove the
> call to ledtrig_audio_get.
>
> Positive side effect: There's no code dependency to ledtrig-audio any
> longer, what allows to remove some Kconfig dependencies.
>
> Signed-off-by: Heiner Kallweit <hka...@gm...>
> ---
> v2:
> - remove Kconfig dependencies related to the audio LED trigger
Thanks, patch looks good to me:
Reviewed-by: Hans de Goede <hde...@re...>
Regards,
Hans
> ---
> drivers/platform/x86/Kconfig | 6 ------
> drivers/platform/x86/asus-wmi.c | 1 -
> drivers/platform/x86/dell/Kconfig | 3 ---
> drivers/platform/x86/dell/dell-laptop.c | 2 --
> drivers/platform/x86/dell/dell-wmi-privacy.c | 1 -
> drivers/platform/x86/huawei-wmi.c | 1 -
> drivers/platform/x86/thinkpad_acpi.c | 1 -
> 7 files changed, 15 deletions(-)
>
> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index bdd302274..6dbd40e2a 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -56,8 +56,6 @@ config HUAWEI_WMI
> depends on INPUT
> select INPUT_SPARSEKMAP
> select LEDS_CLASS
> - select LEDS_TRIGGERS
> - select LEDS_TRIGGER_AUDIO
> select NEW_LEDS
> help
> This driver provides support for Huawei WMI hotkeys, battery charge
> @@ -269,8 +267,6 @@ config ASUS_WMI
> select INPUT_SPARSEKMAP
> select LEDS_CLASS
> select NEW_LEDS
> - select LEDS_TRIGGERS
> - select LEDS_TRIGGER_AUDIO
> select ACPI_PLATFORM_PROFILE
> help
> Say Y here if you have a WMI aware Asus laptop (like Eee PCs or new
> @@ -507,8 +503,6 @@ config THINKPAD_ACPI
> select NVRAM
> select NEW_LEDS
> select LEDS_CLASS
> - select LEDS_TRIGGERS
> - select LEDS_TRIGGER_AUDIO
> help
> This is a driver for the IBM and Lenovo ThinkPad laptops. It adds
> support for Fn-Fx key combinations, Bluetooth control, video
> diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
> index 18be35fdb..21dee425e 100644
> --- a/drivers/platform/x86/asus-wmi.c
> +++ b/drivers/platform/x86/asus-wmi.c
> @@ -1620,7 +1620,6 @@ static int asus_wmi_led_init(struct asus_wmi *asus)
> if (asus_wmi_dev_is_present(asus, ASUS_WMI_DEVID_MICMUTE_LED)) {
> asus->micmute_led.name = "platform::micmute";
> asus->micmute_led.max_brightness = 1;
> - asus->micmute_led.brightness = ledtrig_audio_get(LED_AUDIO_MICMUTE);
> asus->micmute_led.brightness_set_blocking = micmute_led_set;
> asus->micmute_led.default_trigger = "audio-micmute";
>
> diff --git a/drivers/platform/x86/dell/Kconfig b/drivers/platform/x86/dell/Kconfig
> index e712df67f..bd9f44597 100644
> --- a/drivers/platform/x86/dell/Kconfig
> +++ b/drivers/platform/x86/dell/Kconfig
> @@ -57,8 +57,6 @@ config DELL_LAPTOP
> select POWER_SUPPLY
> select LEDS_CLASS
> select NEW_LEDS
> - select LEDS_TRIGGERS
> - select LEDS_TRIGGER_AUDIO
> help
> This driver adds support for rfkill and backlight control to Dell
> laptops (except for some models covered by the Compal driver).
> @@ -165,7 +163,6 @@ config DELL_WMI
>
> config DELL_WMI_PRIVACY
> bool "Dell WMI Hardware Privacy Support"
> - depends on LEDS_TRIGGER_AUDIO = y || DELL_WMI = LEDS_TRIGGER_AUDIO
> depends on DELL_WMI
> help
> This option adds integration with the "Dell Hardware Privacy"
> diff --git a/drivers/platform/x86/dell/dell-laptop.c b/drivers/platform/x86/dell/dell-laptop.c
> index 658643835..42f7de2b4 100644
> --- a/drivers/platform/x86/dell/dell-laptop.c
> +++ b/drivers/platform/x86/dell/dell-laptop.c
> @@ -2252,7 +2252,6 @@ static int __init dell_init(void)
> if (dell_smbios_find_token(GLOBAL_MIC_MUTE_DISABLE) &&
> dell_smbios_find_token(GLOBAL_MIC_MUTE_ENABLE) &&
> !dell_privacy_has_mic_mute()) {
> - micmute_led_cdev.brightness = ledtrig_audio_get(LED_AUDIO_MICMUTE);
> ret = led_classdev_register(&platform_device->dev, &micmute_led_cdev);
> if (ret < 0)
> goto fail_led;
> @@ -2261,7 +2260,6 @@ static int __init dell_init(void)
>
> if (dell_smbios_find_token(GLOBAL_MUTE_DISABLE) &&
> dell_smbios_find_token(GLOBAL_MUTE_ENABLE)) {
> - mute_led_cdev.brightness = ledtrig_audio_get(LED_AUDIO_MUTE);
> ret = led_classdev_register(&platform_device->dev, &mute_led_cdev);
> if (ret < 0)
> goto fail_backlight;
> diff --git a/drivers/platform/x86/dell/dell-wmi-privacy.c b/drivers/platform/x86/dell/dell-wmi-privacy.c
> index c517bd45d..4d94603f7 100644
> --- a/drivers/platform/x86/dell/dell-wmi-privacy.c
> +++ b/drivers/platform/x86/dell/dell-wmi-privacy.c
> @@ -288,7 +288,6 @@ static int dell_privacy_leds_setup(struct device *dev)
> priv->cdev.max_brightness = 1;
> priv->cdev.brightness_set_blocking = dell_privacy_micmute_led_set;
> priv->cdev.default_trigger = "audio-micmute";
> - priv->cdev.brightness = ledtrig_audio_get(LED_AUDIO_MICMUTE);
> return devm_led_classdev_register(dev, &priv->cdev);
> }
>
> diff --git a/drivers/platform/x86/huawei-wmi.c b/drivers/platform/x86/huawei-wmi.c
> index 0ef1c46b6..dde139c69 100644
> --- a/drivers/platform/x86/huawei-wmi.c
> +++ b/drivers/platform/x86/huawei-wmi.c
> @@ -310,7 +310,6 @@ static void huawei_wmi_leds_setup(struct device *dev)
> huawei->cdev.max_brightness = 1;
> huawei->cdev.brightness_set_blocking = &huawei_wmi_micmute_led_set;
> huawei->cdev.default_trigger = "audio-micmute";
> - huawei->cdev.brightness = ledtrig_audio_get(LED_AUDIO_MICMUTE);
> huawei->cdev.dev = dev;
> huawei->cdev.flags = LED_CORE_SUSPENDRESUME;
>
> diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
> index c4895e9bc..d1c9f91fd 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c
> @@ -9285,7 +9285,6 @@ static int mute_led_init(struct ibm_init_struct *iibm)
> continue;
> }
>
> - mute_led_cdev[i].brightness = ledtrig_audio_get(i);
> err = led_classdev_register(&tpacpi_pdev->dev, &mute_led_cdev[i]);
> if (err < 0) {
> while (i--)
|
15 messages has been excluded from this view by a project administrator.
