From: Hans de Goede <hdegoede@redhat.com>
To: "Eray Orçunus" <erayorcunus@gmail.com>, ike.pan@canonical.com
Cc: benjamin.tissoires@redhat.com, dmitry.torokhov@gmail.com,
jikos@kernel.org, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org, mgross@linux.intel.com,
platform-driver-x86@vger.kernel.org, pobrn@protonmail.com
Subject: Re: [PATCH v2 0/7] Add camera access keys, IdeaPad driver improvements
Date: Wed, 9 Nov 2022 17:38:07 +0100 [thread overview]
Message-ID: <9e0074f8-4cbf-e390-6680-39fe3649bbc4@redhat.com> (raw)
In-Reply-To: <20221109125820.14879-1-erayorcunus@gmail.com>
Hi Eray,
Sorry for the long silence, I have not done any pdx86 patch review
the last 2 weeks due to personal circumstances.
On 11/9/22 13:58, Eray Orçunus wrote:
> On 11/08/22 06:56, Ike Panhc wrote:
>> On 10/29/22 20:03, Eray Orçunus wrote:
>>> Nowadays many laptops have camera access keys, yet there is no usage codes
>>> mapped to them, even though it's introduced in HUTRR72. Start point of
>>> this patch series was adding it and making IdeaPads send it to userspace.
>>> But later I discovered that camera_power attribute of ideapad-laptop
>>> driver on my IdeaPad 520-15IKB doesn't work, so I can't toggle it with
>>> that. I managed to find a way to check whether an IdeaPad supports
>>> camera_power attribute (which sends VPCCMD_W_CAMERA to EC), don't expose
>>> it to sysfs so userspace will know that it can't toggle camera access via
>>> camera_power, in my case, after receiving KEY_CAMERA_ACCESS_TOGGLE.
>>>
>>> Along the way I discovered that old IdeaPads, like S10-3, may not be able
>>> to toggle their touchpad as a regression of a commit aimed for newer
>>> IdeaPads, so I reverted it.
>>>
>>> Also I noticed that I can get/set the state of my keyboard light,
>>> so one of the patches also adds supports for this kind of keyboard lights,
>>> which I call "partially supported keyboard lights". I expect that commit
>>> to add keyboard light support for 520-15IKB, 330-17ICH, 5 (15) and more.
>>> Currently only tested on 520-15IKB.
>>
>> Thanks. Also test on my ideapad s410 and it looks good.
>>
>> Acked-by: Ike Panhc <ike.pan@canonical.com>
>
>
> Thank you :)
>
> I need some advice since I'm new in here, sadly another patch has been
> merged to ideapad-laptop along the way and currently it's not possible to
> merge patch #7, does that mean I should send v3 of my patch series?
No that is not necessary, I can rework it to apply on top of the other
patch.
But TBH I think we really need to work on a different solution for
the problem with the touchpad issues with ideapad-laptop we cannot
just keep adding touchpad and/or DMI ids because the driver is
breaking touchpad functionality left and right.
I will send out an email after this one to all authors of recent
patches which all do "priv->features.touchpad_ctrl_via_ec = 0"
in some way.
With a request to gather some more info of why exactly this is
necessary and to see if we cannot come up with a more generic fix.
> And whom should I wait for merge, x86 platform drivers maintainers?
I'm the x86 platform drivers maintainer.
I believe it makes sense to merge this series through the
x86 platform drivers git tree.
I need to coordinate the merging of patch 2/7 with wDmitry
(the input subsystem maintainer) I'll send him an email
about this. After that I can likely merge patches 2-6.
For the touchpad patches I would first like to get
a better handle on how to fix things more generic.
Specifically patch 1/7 will cause priv->features.touchpad_ctrl_via_ec
to get set to 1 on more models and since that is causing issues
I don't think that is a good idea (even though the patch does
make sense) and for 7/7 I hope to come up with something
more generic.
If you can run the tests from the touchpad mail soon that
would really help!
Note I do plan to send 7/7 out as a fix for 6.1 if we
run out of time wrt coming up with a recent fix. Getting
at least some fix out the door is also why I already
merged the other patch using the DMI ids.
> I think that is the only subsystem whose maintainers haven't replied yet.
Correct, but I have replied now :)
Regards,
Hans
next prev parent reply other threads:[~2022-11-09 16:39 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-29 12:03 [PATCH v2 0/7] Add camera access keys, IdeaPad driver improvements Eray Orçunus
2022-10-29 12:03 ` [PATCH v2 1/7] Revert "platform/x86: ideapad-laptop: check for touchpad support in _CFG" Eray Orçunus
2022-11-15 20:25 ` Hans de Goede
2022-10-29 12:03 ` [PATCH v2 2/7] HID: add mapping for camera access keys Eray Orçunus
2022-11-04 8:36 ` Jiri Kosina
2022-11-15 20:33 ` Hans de Goede
2022-11-23 1:56 ` Dmitry Torokhov
2023-06-27 17:35 ` Dmitry Torokhov
2022-10-29 12:03 ` [PATCH v2 3/7] platform/x86: ideapad-laptop: Report KEY_CAMERA_ACCESS_TOGGLE instead of KEY_CAMERA Eray Orçunus
2022-11-15 20:31 ` Hans de Goede
2022-10-29 12:03 ` [PATCH v2 4/7] platform/x86: ideapad-laptop: Add new _CFG bit numbers for future use Eray Orçunus
2022-11-15 20:36 ` Hans de Goede
2022-10-29 12:03 ` [PATCH v2 5/7] platform/x86: ideapad-laptop: Expose camera_power only if supported Eray Orçunus
2022-11-15 20:43 ` Hans de Goede
2022-11-16 15:39 ` Hans de Goede
2022-10-29 12:03 ` [PATCH v2 6/7] platform/x86: ideapad-laptop: Keyboard backlight support for more IdeaPads Eray Orçunus
2022-11-15 20:59 ` Hans de Goede
2022-10-29 12:03 ` [PATCH v2 7/7] platform/x86: ideapad-laptop: Don't expose touchpad attr on IdeaPads with SYNA2B33 Eray Orçunus
2022-11-15 21:00 ` Hans de Goede
2022-11-08 3:56 ` [PATCH v2 0/7] Add camera access keys, IdeaPad driver improvements Ike Panhc
2022-11-09 12:58 ` Eray Orçunus
2022-11-09 16:38 ` Hans de Goede [this message]
2022-11-09 23:30 ` Eray Orçunus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9e0074f8-4cbf-e390-6680-39fe3649bbc4@redhat.com \
--to=hdegoede@redhat.com \
--cc=benjamin.tissoires@redhat.com \
--cc=dmitry.torokhov@gmail.com \
--cc=erayorcunus@gmail.com \
--cc=ike.pan@canonical.com \
--cc=jikos@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mgross@linux.intel.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=pobrn@protonmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox