linux-kernel - Re: [PATCH RESEND v2 1/4] HID: hid-appletb-bl: add driver for the backlight of Apple Touch Bars

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID:
 <MAZPR01MB8280DB01B272D489E700C229B8F42@MAZPR01MB8280.INDPRD01.PROD.OUTLOOK.COM>
Date: Tue, 4 Feb 2025 02:11:44 +0000
From: Aditya Garg <gargaditya08@...e.com>
To: Jiri Kosina <jikos@...nel.org>
CC: "bentiss@...nel.org" <bentiss@...nel.org>, Benjamin Tissoires
	<benjamin.tissoires@...hat.com>, Thomas Weißschuh
	<linux@...ssschuh.net>, Thomas Weißschuh
	<thomas@...ch.de>, Kerem Karabay <kekrby@...il.com>, Orlando Chamberlain
	<orlandoch.dev@...il.com>, Linux Kernel Mailing List
	<linux-kernel@...r.kernel.org>, "linux-input@...r.kernel.org"
	<linux-input@...r.kernel.org>
Subject: Re: [PATCH RESEND v2 1/4] HID: hid-appletb-bl: add driver for the
 backlight of Apple Touch Bars

Hi Jiri

> On 4 Feb 2025, at 3:25 AM, Jiri Kosina <jikos@...nel.org> wrote:
> 
> On Mon, 3 Feb 2025, Aditya Garg wrote:
> 
>> From: Kerem Karabay <kekrby@...il.com>
>> 
>> This commit adds a driver for the backlight of Apple Touch Bars on x86
>> Macs. Note that currently only T2 Macs are supported.
>> 
>> This driver is based on previous work done by Ronald Tschalär
>> <ronald@...ovation.ch>.
>> 
>> Signed-off-by: Kerem Karabay <kekrby@...il.com>
>> Co-developed-by: Aditya Garg <gargaditya08@...e.com>
>> Signed-off-by: Aditya Garg <gargaditya08@...e.com>
>> ---
>> drivers/hid/Kconfig          |  10 ++
>> drivers/hid/Makefile         |   1 +
>> drivers/hid/hid-appletb-bl.c | 207 +++++++++++++++++++++++++++++++++++
>> drivers/hid/hid-quirks.c     |   4 +-
>> 4 files changed, 221 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/hid/hid-appletb-bl.c
>> 
>> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
>> index 4d2a89d65..f6678db27 100644
>> --- a/drivers/hid/Kconfig
>> +++ b/drivers/hid/Kconfig
>> @@ -148,6 +148,16 @@ config HID_APPLEIR
>> 
>>    Say Y here if you want support for Apple infrared remote control.
>> 
>> +config HID_APPLETB_BL
>> +    tristate "Apple Touch Bar Backlight"
>> +    depends on BACKLIGHT_CLASS_DEVICE
>> +    help
>> +      Say Y here if you want support for the backlight of Touch Bars on x86
>> +      MacBook Pros.
>> +
>> +      To compile this driver as a module, choose M here: the
>> +      module will be called hid-appletb-bl.
>> +
>> config HID_ASUS
>>    tristate "Asus"
>>    depends on USB_HID
>> diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
>> index 24de45f36..444d24cec 100644
>> --- a/drivers/hid/Makefile
>> +++ b/drivers/hid/Makefile
>> @@ -29,6 +29,7 @@ obj-$(CONFIG_HID_ALPS)        += hid-alps.o
>> obj-$(CONFIG_HID_ACRUX)        += hid-axff.o
>> obj-$(CONFIG_HID_APPLE)        += hid-apple.o
>> obj-$(CONFIG_HID_APPLEIR)    += hid-appleir.o
>> +obj-$(CONFIG_HID_APPLETB_BL)    += hid-appletb-bl.o
> 
> Is there a reason not to build hid-appletb-bl into hid-apple(.ko) driver
> proper?
> 

You might have noticed that the hid-apple driver has code for the magic backlight. Now we have a case of MacBook Air 2020, which does not have a touchbar but still shows presence of the touchbar backlight device, just because it needs it for the keyboard backlight. In case we merge both the backlight and touchbar code in a driver, on that model, the backlight breaks. If kept separate, the touchbar driver simply doesn't load and backlight works.

In the future, we also shall send another driver, which shall support the macOS mode of the touchbar, that is we can use the touchbar as a second display. It shall be a drm driver and both current and the drm driver need the touchbar backlight driver in common.
> Otherwise the code looks good to me, but I'd prefer to have this built-in
> as we generally try to keep things contained in one single per-vendor HID
> driver.
> 
> Thanks,
> 
> --
> Jiri Kosina
> SUSE Labs
>