Hi,
On 9/17/20 3:36 PM, Mark Pearson wrote:
Hi all,
More emails came in since I wrote this....but I'm going to send anyway and catch up with those after. I need to write faster :)
On 9/17/2020 7:50 AM, Bastien Nocera wrote:
Hey,
On Thu, 2020-09-17 at 13:22 +0200, Hans de Goede wrote:
<snip>
Compared to the WIP lenovo-dytc "perfmode" driver, we're missing
something to advertise the unavailability of a profile, and the reason
for that unavailability.
In all honesty I was slightly dreading this email :) I know the similar issue killed our ePrivacy patch...but I fully appreciate that is part of open source contribution
Getting offtopic here, but the e-privacy screen stuff is already available to userspace through /proc/acpi/ibm/lcdshadow.
What is on hold is adding userspace support for it, because we want to use the new generic API for that once it lands.
So yes - I agree that having a common interface would be a good idea and making it common between the vendors makes sense. Let me know how to contribute and make that happen.
From Lenovo's firmware point of view - our three settings should map on to this quite closely with the exception that we have one setting that covers balance_power and power (I never understood why the FW team did that - as they have the four states in Windows - I wasn't able to get a satisfactory answer to that question)
I would like to think that the above proposal is a good start,
if we can quickly (*) decide on an userspace API here
Yes and understood. Let me know what is the best place to make this happen - from my point of view the main aim is to get this to our users to make the whole performance mode implemetnation more usable and obvious. Without my proposed patch it's really hard to tell what mode you are in on our platforms (and leads to lots of support questions).
I'm particularly aware of the eprivacy patch where that got rejected for a generic solution that was under development - but the person working on the generic solution stopped part way through to work on other things. We didn't have the knowledge or experience of the graphics driver to be able to really go and contribute effectively so for now that feature is dead even though our initial patch was fairly simple. It is still disappointing that our users don't get useful functionality (and I also have to argue with marketing as to whether we can sell Linux systems with ePrivacy screens which is
no fun - I spend way too much of my life doing Lenovo internal paperwork).
I figure on this item it's less complicated (not tied into the graphics drivers details) so I hope I can contribute more directly - let me know if I'm being naive.
One question - the main reason for a common interface is for user space to not deal with a mess of APIs.
Correct.
Is it worth me doing a simplified version of my patch (maybe using debugfs?) so I can expose the modes to users whilst we work on the common solution? I'm assuming there is no mileage in getting my patch (with the fix I owe Benjamin) in and then changing it in the future once the generic solution is available as that potentially messes up userspace too much?
Using debugfs as an intermediate solution is a good idea. debugfs interfaces have no ABI guarantees, so we can simply drop it when the generic stuff lands.
Something as a stopgap measure that won't annoy the kernel community but is good for Linux users as I'm guessing the generic solution
is likely to be months away
The generic solution will definitely not make the 5.10 kernel, but 5.11 is not entirely out of the question, although to be honest 5.12 seems more realistic.
<snip>
I guess we should also add an optional lap_mode sysfs attribute
to the class-device, to have all the info for the Thinkpads in
one place.
I'm good with this too - but the lapmode patch is accepted and there is the palm sensor patch too which I'm hoping is accepted soon. Whilst I'm happy to make them part of this implementation (if they fit) I'd appreciate if they didn't get removed or held up as they're needed for our WWAN implementation which is already overdue.
The main consumer there will be our WWAN enablement utility and we can change that to support different API if needs be :)
As the rest of the dicussion has shown the lap_mode thingie indeed is best left in place as a
thinkpad_acpi only interface for now.
I guess the same applies to the palm_sensor stuff. We may want to advertise that through
some standardize API later, but for now we can just use a thinkpad_acpi specific API and
then also export the info through the standardized API later, as we will do for the
lcdshadow stuff.
Regards,
Hans
