linux-kernel - Re: [PATCH 00/22] Fallback to native backlight

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <84d86b61-7694-2e22-3593-b11b3ce33cf8@redhat.com>
Date:   Mon, 24 Oct 2022 15:23:46 +0200
From:   Hans de Goede <hdegoede@...hat.com>
To:     Pali Rohár <pali@...nel.org>,
        Akihiko Odaki <akihiko.odaki@...nix.com>
Cc:     David Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Jonathan Corbet <corbet@....net>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Len Brown <lenb@...nel.org>,
        Jani Nikula <jani.nikula@...ux.intel.com>,
        Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
        Rodrigo Vivi <rodrigo.vivi@...el.com>,
        Tvrtko Ursulin <tvrtko.ursulin@...ux.intel.com>,
        "Lee, Chun-Yi" <jlee@...e.com>, Mark Gross <markgross@...nel.org>,
        Corentin Chary <corentin.chary@...il.com>,
        Cezary Jackiewicz <cezary.jackiewicz@...il.com>,
        Matthew Garrett <mjg59@...f.ucam.org>,
        Jonathan Woithe <jwoithe@...t42.net>,
        Ike Panhc <ike.pan@...onical.com>,
        Daniel Dadap <ddadap@...dia.com>,
        Kenneth Chan <kenneth.t.chan@...il.com>,
        Mattia Dongili <malattia@...ux.it>,
        Henrique de Moraes Holschuh <hmh@....eng.br>,
        Azael Avalos <coproscefalo@...il.com>,
        Lee Jones <lee@...nel.org>,
        Daniel Thompson <daniel.thompson@...aro.org>,
        Jingoo Han <jingoohan1@...il.com>,
        Helge Deller <deller@....de>,
        Robert Moore <robert.moore@...el.com>,
        dri-devel@...ts.freedesktop.org, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
        intel-gfx@...ts.freedesktop.org,
        platform-driver-x86@...r.kernel.org,
        acpi4asus-user@...ts.sourceforge.net,
        ibm-acpi-devel@...ts.sourceforge.net, linux-fbdev@...r.kernel.org,
        devel@...ica.org
Subject: Re: [PATCH 00/22] Fallback to native backlight

Hi,

On 10/24/22 15:14, Pali Rohár wrote:
> On Monday 24 October 2022 21:58:57 Akihiko Odaki wrote:
>> Regarding the second limitation, I don't even understand the difference
>> between vendor and native. My guess is that a vendor backlight device uses
>> vendor-specific ACPI interface, and a native one directly uses hardware
>> registers. If my guess is correct, the difference between vendor and native
>> does not imply that both of them are likely to exist at the same time. As
>> the conclusion, there is no more motivation to try to de-duplicate the
>> vendor/native combination than to try to de-duplicate combination of devices
>> with a single type.
> 
> Hello! I just want to point one thing. On some Dell laptops there are
> 3 different ways (= 3 different APIs) how to control display backlight.
> There is ACPI driver (uses ACPI), GPU/DRM driver (i915.ko; uses directly
> HW) and platform vendor driver (dell-laptop.ko; uses vendor BIOS or
> firmware API).

Right and that is just one example of laptops which can register both
vendor + native backlight devices, which is why this whole series is
a bad idea.

Regards,

Hans



> Just every driver has different pre-calculated scaling
> values. So sometimes user wants to choose different driver just because
> it allows to set backlight level with "better" granularity. Registering
> all 3 device drivers is bad as user does not want to see 3 display
> panels and forcing registration of specific one without runtime option
> is also bad (some of those drivers do not have to be suitable or has
> worse granularity as other).