| Message ID | DD9C41AD-6543-47CE-8504-69E4992229B2@live.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Touch Bar support for T2 Macs | expand |
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. > On 17 Aug 2024, at 5:15 PM, Aditya Garg <gargaditya08@live.com> wrote: > > 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 > > -- > 2.43.0 >
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,
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 >
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 >
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,
> On 26 Sep 2024, at 11:33 PM, 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. So I should assume the HID portion is fit to be merged now? > > Dave, who'd be the best person to do this from the DRM side please? > > Thanks, > > -- > Jiri Kosina > SUSE Labs >
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?
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.
On Fri, 27 Sep 2024, Dave Airlie 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? I'm fine either way, once DRM folks either give their Ack, or express their desire to separate it out, I'll follow :) Thanks,
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 > >
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