mbox series

[v5,0/10] Touch Bar support for T2 Macs

Message ID DD9C41AD-6543-47CE-8504-69E4992229B2@live.com
Headers show
Series Touch Bar support for T2 Macs | expand

Message

Aditya Garg Aug. 17, 2024, 11:44 a.m. UTC
Hi Maintainers

The Touch Bars found on x86 Macs support two USB configurations: one
where the device presents itself as a HID keyboard and can display
predefined sets of keys, and one where the operating system has full
control over what is displayed.

This patch series adds support for both the configurations.

The hid-appletb-bl driver adds support for the backlight of the Touch Bar.
This enables the user to control the brightness of the Touch Bar from
userspace. The Touch Bar supports 3 modes here: Max brightness, Dim and Off.
So, daemons, used to manage Touch Bar can easily manage these modes by writing
to /sys/class/backlight/appletb_backlight/brightness. It is needed by both the
configurations of the Touch Bar.

The hid-appletb-kbd adds support for the first (predefined keys) configuration.
There are 4 modes here: Esc key only, Fn mode, Media keys and No keys.
Mode can be changed by writing to /sys/bus/hid/drivers/hid-appletb-kbd/<dev>/mode
This configuration is what Windows uses with the official Apple Bootcamp drivers.

Rest patches support the second configuration, where the OS has full control
on what's displayed on the Touch Bar. It is achieved by the patching the
hid-multitouch driver to add support for touch feedback from the Touch Bar
and the appletbdrm driver, that displays what we want to on the Touch Bar.
This configuration is what macOS uses.

The appletbdrm driver is based on the similar driver made for Windows by
imbushuo [1].

Currently, a daemon named tiny-dfr [2] is being used to display function keys
and media controls using the second configuration for both Apple Silicon and
T2 Macs.

A daemon for the first configuration is being developed, but that's a userspace
thing.

[1]: https://github.com/imbushuo/DFRDisplayKm
[2]: https://github.com/WhatAmISupposedToPutHere/tiny-dfr

v2:
1. Cleaned up some code in the hid-appletb-kbd driver.
2. Fixed wrong subject in drm/format-helper patch.
3. Fixed Co-developed-by wrongly added to hid-multitouch patch.

v3:
1. Fixed key mapping for Function keys in hid-appletb-kbd driver.

v4:
1. Added support for fn key toggle in the hid-appletb-kbd driver.

v5:
1. Do required changes to hid-appletb-bl as requested by upstream.

Aditya Garg (1):
HID: hid-appletb-kbd: add support for fn toggle between media and
  function mode

Kerem Karabay (9):
HID: hid-appletb-bl: add driver for the backlight of Apple Touch Bars
HID: hid-appletb-kbd: add driver for the keyboard mode of Apple Touch
  Bars
HID: multitouch: support getting the contact ID from
  HID_DG_TRANSDUCER_INDEX fields
HID: multitouch: support getting the tip state from HID_DG_TOUCH
  fields
HID: multitouch: take cls->maxcontacts into account for devices
  without a HID_DG_CONTACTMAX field too
HID: multitouch: allow specifying if a device is direct in a class
HID: multitouch: add device ID for Apple Touch Bars
drm/format-helper: Add conversion from XRGB8888 to BGR888 conversion
drm/tiny: add driver for Apple Touch Bars in x86 Macs

.../ABI/testing/sysfs-driver-hid-appletb-kbd  |  13 +
MAINTAINERS                                   |   6 +
drivers/gpu/drm/drm_format_helper.c           |  54 ++
.../gpu/drm/tests/drm_format_helper_test.c    |  81 +++
drivers/gpu/drm/tiny/Kconfig                  |  12 +
drivers/gpu/drm/tiny/Makefile                 |   1 +
drivers/gpu/drm/tiny/appletbdrm.c             | 624 ++++++++++++++++++
drivers/hid/Kconfig                           |  22 +
drivers/hid/Makefile                          |   2 +
drivers/hid/hid-appletb-bl.c                  | 207 ++++++
drivers/hid/hid-appletb-kbd.c                 | 432 ++++++++++++
drivers/hid/hid-multitouch.c                  |  60 +-
drivers/hid/hid-quirks.c                      |   8 +-
include/drm/drm_format_helper.h               |   3 +
14 files changed, 1509 insertions(+), 16 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-driver-hid-appletb-kbd
create mode 100644 drivers/gpu/drm/tiny/appletbdrm.c
create mode 100644 drivers/hid/hid-appletb-bl.c
create mode 100644 drivers/hid/hid-appletb-kbd.c

Comments

Jiri Kosina Sept. 11, 2024, 12:21 p.m. UTC | #1
On Sat, 31 Aug 2024, Aditya Garg wrote:

> Hi Maintainers
> 
> It has been 2 weeks but I still haven't received a single reply on this 
> version of the patch series. Consider this email as a friendly reminder.

I think it makes most sense to take this whole set through hid.git, but 
for that, I'd like to get Acked-by/Reviewed-by for patches 9 and 10 (drm 
bits).

Dave, Daniel, .. ?

Thanks,
Aditya Garg Sept. 17, 2024, 10:06 a.m. UTC | #2
Hi Jiri

Do I have to send the drm patches again to get their Acked-by/Reviewed-by?
Although I have already cced the DRM maintainers in this patchset.

> On 11 Sep 2024, at 5:51 PM, Jiri Kosina <jikos@kernel.org> wrote:
> 
> On Sat, 31 Aug 2024, Aditya Garg wrote:
> 
>> Hi Maintainers
>> 
>> It has been 2 weeks but I still haven't received a single reply on this 
>> version of the patch series. Consider this email as a friendly reminder.
> 
> I think it makes most sense to take this whole set through hid.git, but 
> for that, I'd like to get Acked-by/Reviewed-by for patches 9 and 10 (drm 
> bits).
> 
> Dave, Daniel, .. ?
> 
> Thanks,
> 
> -- 
> Jiri Kosina
> SUSE Labs
>
Aditya Garg Sept. 26, 2024, 5:50 p.m. UTC | #3
It has been more than a month since I've sent this patch set and I haven't got a clear yes or not for the same. I understand maintainers are busy people, but I'd really appreciate if I get some response for this series of patches from the HID and DRM maintainers.

Thanks
Aditya

> On 11 Sep 2024, at 5:51 PM, Jiri Kosina <jikos@kernel.org> wrote:
> 
> On Sat, 31 Aug 2024, Aditya Garg wrote:
> 
>> Hi Maintainers
>> 
>> It has been 2 weeks but I still haven't received a single reply on this
>> version of the patch series. Consider this email as a friendly reminder.
> 
> I think it makes most sense to take this whole set through hid.git, but
> for that, I'd like to get Acked-by/Reviewed-by for patches 9 and 10 (drm
> bits).
> 
> Dave, Daniel, .. ?
> 
> Thanks,
> 
> --
> Jiri Kosina
> SUSE Labs
>
Jiri Kosina Sept. 26, 2024, 6:03 p.m. UTC | #4
On Thu, 26 Sep 2024, Aditya Garg wrote:

> It has been more than a month since I've sent this patch set and I 
> haven't got a clear yes or not for the same. I understand maintainers 
> are busy people, but I'd really appreciate if I get some response for 
> this series of patches from the HID and DRM maintainers.

Just to reiterate -- I am waiting for Ack from the DRM people and will 
then take it through hid.git.

Dave, who'd be the best person to do this from the DRM side please?

Thanks,
Jiri Kosina Sept. 26, 2024, 6:11 p.m. UTC | #5
On Thu, 26 Sep 2024, Aditya Garg wrote:

> >> It has been more than a month since I've sent this patch set and I
> >> haven't got a clear yes or not for the same. I understand maintainers
> >> are busy people, but I'd really appreciate if I get some response for
> >> this series of patches from the HID and DRM maintainers.
> > 
> > Just to reiterate -- I am waiting for Ack from the DRM people and will
> > then take it through hid.git.
> 
> So I should assume the HID portion is fit to be merged now?

hid-appletb-* I have gone through, and it looks all good to me.

Benjamin, could you please explicitly provide your Ack for the multitouch 
changes?
Dave Airlie Sept. 26, 2024, 8:37 p.m. UTC | #6
On Fri, 27 Sept 2024 at 04:03, Jiri Kosina <jikos@kernel.org> wrote:
>
> On Thu, 26 Sep 2024, Aditya Garg wrote:
>
> > It has been more than a month since I've sent this patch set and I
> > haven't got a clear yes or not for the same. I understand maintainers
> > are busy people, but I'd really appreciate if I get some response for
> > this series of patches from the HID and DRM maintainers.
>
> Just to reiterate -- I am waiting for Ack from the DRM people and will
> then take it through hid.git.
>
> Dave, who'd be the best person to do this from the DRM side please?
>

I think Thomas or Maxime could take a look, though it might be easier
to submit this in pieces, does it really need to all go in at once?

Dave.
Benjamin Tissoires Sept. 27, 2024, 3:22 p.m. UTC | #7
On Sep 26 2024, Aditya Garg wrote:
> It has been more than a month since I've sent this patch set and I haven't got a clear yes or not for the same. I understand maintainers are busy people, but I'd really appreciate if I get some response for this series of patches from the HID and DRM maintainers.

Please look at the time. You sent this a month ago, while v6.11-rc4 was
out the next day.

I was personally taking time off and came back at the end of August
(roughly at rc6).
This is then a problematic time to merge new drivers because they won't
have enough time to be in linux-next before they are sent to Linus.

Also some subsystem are more strict in term of what can go in and when,
and IIRC drm had been strict regarding that because it is heavily making
use of sub-subsystems, and they need time to put back everything
together for sending it to Linus.

Then, when -rc7 is out, I bet no maintainers will take new drivers for
the next 3 weeks:
- the final version will be out the next week, meaning not enough time
  to test in linux-next
- while the merge window is opened, we are not allowed to take any N+1
  material, or this will break everybody testing system.

Merge window is closing this Sunday, but I realized that there was a
regression in HID-BPF which breaks the CI, so at the earliest your new
drivers will be taken at the end of next week.

So yeah, I understand it can be frustrating somehow, but please avoid
all caps in your subject prefix, this really put other people on their
nerves for nothing.

I have a few objections to your series, I'm going to answer individually
in the patches.

Cheers,
Benjamin

> 
> Thanks
> Aditya
> 
> > On 11 Sep 2024, at 5:51 PM, Jiri Kosina <jikos@kernel.org> wrote:
> > 
> > On Sat, 31 Aug 2024, Aditya Garg wrote:
> > 
> >> Hi Maintainers
> >> 
> >> It has been 2 weeks but I still haven't received a single reply on this
> >> version of the patch series. Consider this email as a friendly reminder.
> > 
> > I think it makes most sense to take this whole set through hid.git, but
> > for that, I'd like to get Acked-by/Reviewed-by for patches 9 and 10 (drm
> > bits).
> > 
> > Dave, Daniel, .. ?
> > 
> > Thanks,
> > 
> > --
> > Jiri Kosina
> > SUSE Labs
> >
Aditya Garg Sept. 27, 2024, 4:42 p.m. UTC | #8
Hi Benjamin

I’ve noticed the DRM folks also have requested a lot of changes in the drm bit.

I really appreciate that finally we got some review on the patches, irrespective of whether it was acceptance/rejection/change.

Anyways, since the hid-multitouch changes are needed only for the DRM driver, I’ll for the time being fix up the basic Touch Bar mode driver for upstream. Let’s get it done first, and at least make the upstream kernels be able to at least use the Touch Bar, even if it is in basic mode. I’ll figure out the other macOS mode driver later, and will send it some time later then.

> On 27 Sep 2024, at 8:52 PM, Benjamin Tissoires <bentiss@kernel.org> wrote:
> 
> On Sep 26 2024, Aditya Garg wrote:
>> It has been more than a month since I've sent this patch set and I haven't got a clear yes or not for the same. I understand maintainers are busy people, but I'd really appreciate if I get some response for this series of patches from the HID and DRM maintainers.
> 
> Please look at the time. You sent this a month ago, while v6.11-rc4 was
> out the next day.
> 
> I was personally taking time off and came back at the end of August
> (roughly at rc6).
> This is then a problematic time to merge new drivers because they won't
> have enough time to be in linux-next before they are sent to Linus.
> 
> Also some subsystem are more strict in term of what can go in and when,
> and IIRC drm had been strict regarding that because it is heavily making
> use of sub-subsystems, and they need time to put back everything
> together for sending it to Linus.
> 
> Then, when -rc7 is out, I bet no maintainers will take new drivers for
> the next 3 weeks:
> - the final version will be out the next week, meaning not enough time
> to test in linux-next
> - while the merge window is opened, we are not allowed to take any N+1
> material, or this will break everybody testing system.
> 
> Merge window is closing this Sunday, but I realized that there was a
> regression in HID-BPF which breaks the CI, so at the earliest your new
> drivers will be taken at the end of next week.
> 
> So yeah, I understand it can be frustrating somehow, but please avoid
> all caps in your subject prefix, this really put other people on their
> nerves for nothing.

For the above, I understand and was well aware of the rc6/7 merge windows during those days, and that was the reason I was waiting quite patiently.

Talking about caps in the subject, I apologise for that, my intention was definitely not to "put other people on their nerves for nothing.”

Cheers

Aditya