9 ms·

Merge tag 'arm-Apple-M1-5.13' of Linux

189 points by boramalper 5y ago

600frogs 5y ago
I'm not hugely familiar with the Linux release cycle, can anyone explain why such rudimentary support should be merged in now, instead of waiting until it's ready?
- bbojan 5y ago
  Release early, release often?
- gregkh 5y ago
  Merge the portions that you know are correct and will have no affect on anyone else now, which makes future work easier as you do not have to keep those "working" commits up to date. We do this all the time with kernel development, and is one reason why breaking changes up into tiny pieces is so powerful. We can take the pieces that make sense now, and allow the developer to redo the portions that are not ready yet, instead of having to reject the whole thing if it were done in one single "chunk." Also note that the TTY/serial portions of this hardware support was already merged through the serial tree because they were independent and didn't affect anyone else.
  - 600frogs 5y ago
    Interesting, thanks for the explanation. Has this style of development ever come back to bite you?
    - nousermane 5y ago
      Not GP, but... In the context of recent event, [0] where not reviewing thoroughly enough some tiny patches had a major come-back-to-bite fallout, I can't help but wonder: How, exactly are you expecting an increase in average patch size to help? [0] https://news.ycombinator.com/item?id=26887670 https://news.ycombinator.com/item?id=26887670
      - 600frogs 5y ago
        I did read through this debacle when it came out actually, I'm thoroughly on team Greg. I suppose my question was separate from malicious patches - I was interested in knowing if this incremental "merge tiny patches as and when they're ready" mode of development has ever caused issues with half-baked solutions affecting other parts of the kernel where perhaps it wouldn't have otherwise done so if the release was given more time for polishing and testing.
    - gregkh 5y ago
      Off the top of my head, no. The big "downside" is that it takes more work on the patch submitter side. But the benefits in the end are almost always more than worth it (easier reviewer time, easier time to track down problems, better development cycle as feedback can be more specific, easier evolution of changes, etc.) I wrote a whole chapter in the book "Beautiful Code" about how this development model can help create an end result that is almost always better than the initial "huge" submission model. Check it out if you are interested, it should be free online somewhere...
      - 600frogs 5y ago
        My instinct would have been that it's easier for the submitter (as they have less to polish and test) and more irksome for the reviewer as they have to go through multiple rounds of submissions, but naturally I'll take your word for it! This kind of discussion is always of interest to me, I'll check out the book, thank you.
        Filligree 5y ago
        Reviewing three changelists, which individually do only a single thing each, is in my experience much easier than reviewing a single changelist bundling the changes from all three. This is true even if the same lines are changed multiple times. It's something you'll learn with experience, but it's also not even close. Break your patches up as much as possible, and everyone will be happier.
      - joseluisq 5y ago
        I found it, Greg's chapter `The Linux Kernel Driver Model: The Benefits of Working Together` on page 267 - https://www.oreilly.com/library/view/beautiful-code/9780596510046/ https://www.oreilly.com/library/view/beautiful-code/97805965... - https://github.com/stormtrooper96/books/blob/master/software-development/Beautiful%20Code.pdf https://github.com/stormtrooper96/books/blob/master/software... So I'll definitely give it a read. Thanks!
- richardanaya 5y ago
  One idea might be building a relationship of trust around a certain architecture in the Kernel, another idea is that it makes future work faster to merge in if the basics are already in.
- soneil 5y ago
  There's a relatively low cost to having this merged as it becomes available. It's not like x86 distros will be building it into their kernel.
- regularfry 5y ago
  It lets others build on it.
- gsnedders 5y ago
  Obviously you should listen to Greg and not me, but in many ways you can summarise it as "are the changes correct and do they work?". That they don't amount to end-user useful support is a very separate matter. What's the benefit of delaying submission of correct and working branches?
  - aquadrop 5y ago
    If you plan for such model beforehand you already might be lowering overall efficiency. You know that you can't get the whole thing you want as one piece, but you plan "one third now, another third in a couple of months and the last third in more couple of months". Overall you might end up with twice the effort, since you had to account for that split, but in the context of kernel it still makes sense because of all the complexity and many people working on it simultaneously. And of course it also depends on "splitability" of the thing you're working on.
    - marcan_42 5y ago
      It's actually more efficient to do it this way. When you develop in a fork, you end up having to both keep rebasing on mainline, and then on submission, you might find that large parts of the code are the wrong approach or do not meet upstream standards, and need to be rewritten. By planning for incremental merges, you ensure that your foundation is solid and acceptable and avoid wasted work.
- trissylegs 5y ago
  It seems like it's ready to go in mailine. Linux doesn't really do "Big-bang" Everything is done releases of new features. Support is added incrementally. Here it says USB, PCIe, IOMMU, NVMe. Haven't been finished. But given those features are spread occross difference subsystems and have different maintainers it'll be easier to work on those once the platform is in Mainline. (You won't be able to expect all the PCIe developers to have the special M1 mac branch ready for testing)
  - 600frogs 5y ago
    So it seems to be it's primarily solving branching issues rather than providing any benefit of the incremental support, is that correct?
    - viraptor 5y ago
      Depends what you mean by incremental support. It would definitely help someone to base new work on what's already approved, merged and supported without the need to hunt for the latest updated external branch and reconciling it with their local version. (But maybe that's what you're calling branching issues)
    - cestith 5y ago
      I'd rather spend time writing new branches against approved, merged upstream rather than submitting to an upstream branch that may never get reviewed and merged. Keep in mind, too, that the longer a branch lives the more rebasing it goes through. Also, the bigger the branch is, the more it is to review when finally considering whether to merge it. I think giving people a foundation on which to build is a good way to prevent a lot of extraneous work and also to build confidence in the direction of development.
- Rhedox 5y ago
  Easier to address feedback on the initial code now than when you have hundreds of lines building on top of it.
- jononor 5y ago
  This is an example of "integrate early, integrate often" which is a core part of Continuous Integration (CI). These days people tend to focus on the automation aspect of CI, but getting code into mainline early is also key.
pimeys 5y ago
So, if the machines last a long time without Louis Rossman style of issues, getting a M1 Macbook for NixOS in about a few years might make sense. Very nice.
- nix23 5y ago
  Bravo, watching Rossman and learned nothing...but hey, buy your Macbook if you like to produce e-waste.
  - simonh 5y ago
    I'll take my environmental responsibility and recyclability advice from Greenpeace thanks.
    - lurker1928 5y ago
      cant tell if sarcasm....
    - nix23 5y ago
      That Advice? >>While transitioning to 100% recycled materials is critical to reducing the sector’s footprint, it is also fundamental for Apple and other major IT companies to design products that last, are easy to repair, and recyclable at their end of life. are easy to repair..... https://www.greenpeace.org/usa/news/apple-announces-commitment-to-100-recycled-materials-major-step-for-it-sector-greenpeace-response/ https://www.greenpeace.org/usa/news/apple-announces-commitme...
- kreetx 5y ago
  Would be great if everything were ready by the time 16" M models come out. :)
- bobmaxup 5y ago
  Who is Louis Rossman? What are his style of issues? Why should I know this?
  - 5y ago
deleted 5y ago
[deleted]
apatheticonion 5y ago
How cool would it be if the iPhone got a pro variant running the M1 chip, someone unlocked the bootloader and installed Linux on it. Plug it into a thunderbolt dock and you have a full Linux desktop.
- Teledhil 5y ago
  The A14 is basically a M1 with less CPU and GPU cores, so I guess most of the work done for supporting the M1 on Linux could be reused for the A14.
- vetinari 5y ago
  In the past (pre-Android 10), you could do that with Samsung Galaxy phones - plug them into USB-C dock, launch Linux-on-Dex and you got Linux desktop.
  - goffi 5y ago
    you can do that right now with a PinePhone.
    - apatheticonion 5y ago
      Wait... What?! EDIT: ah, sadly looks like it's not something that's daily drive-able https://www.youtube.com/watch?v=fCKMxzz9cjs https://www.youtube.com/watch?v=fCKMxzz9cjs
      - goffi 5y ago
        you can get a convergence pack with more RAM (3GB) and storage and with a USB-C docking bar (that you can also buy separately). Once plugged, you have a desktop GNU/Linux, I've tested with Plasma Mobile and it's working quite well (got a few crashes, but it's not flagged as fully stable yet).
      - josteink 5y ago
        The software is OKish and getting better at a steady rate. The SOC in the PinePhone is nowhere near beefy enough though. Running the same stack on an M1-chip would probably a game changer usability-wise.
mraza007 5y ago
Imagine running Linux on your iPhone. I just can’t wait for that day but the it doesn’t seem to happen anytime soon
- joana035 5y ago
  I guess that is already possible, I remember seeing a guy doing that somewhere in the internet.
  - gtirloni 5y ago
    "A developer got Ubuntu Linux booting on the Apple iPhone 7" https://www.xda-developers.com/apple-iphone-7-ubuntu-linux-checkra1n-project-sandcastle/ https://www.xda-developers.com/apple-iphone-7-ubuntu-linux-c...
  - gtk40 5y ago
    I've seen ways of running Android (Linux kernel) on iPhones for over a decade on-line, though I don't know that any ever fully supported it.
- kreetx 5y ago
  My dream would be to run nixos on my phone so I could have all my devices configured from a single set of config files. Could then unify entire infra from config to sync and backups.
- peteretep 5y ago
  Why though? Is the iPhone hardware that much better than their high-end competitors? I’m a big Apple fanboy but I buy an iPhone (and indeed a Mac) to run iOS (and macOS)
  - boxed 5y ago
    Yes it is. Apple is way ahead of the competition in CPU design. Which is why the M1 is making Intel look so bad right now.
mishagale 5y ago
Doesn't Linux already have mature support for ARM? What's so different about the M1 that it needs all this extra work?
- mhh__ 5y ago
  Peripherals
- mirthflat83 5y ago
  …
- tyingq 5y ago
  A good overview: https://asahilinux.org/2021/03/progress-report-january-february-2021/ https://asahilinux.org/2021/03/progress-report-january-febru...
- cestith 5y ago
  ARM is a CPU ISA. A MacBook is a whole computer. A general purpose OS to be really useful needs to support the CPU, yes, but also the boot hardware, the bus, the video devices, keyboard, pointing devices, speakers, mic, line in, line out, the network hardware, internal storage, external storage, and preferably any peripheral through the USB ports or wirelessly that's USB or Bluetooth with a standard profile. Also remember that M1 is not only ARM. It's a SOC which combines ARM cores with GPU cores and AI-targeted cores. Targeting just that is a lot more work than just porting the ARM portion from a Raspberry Pi or an Android phone. I'm sure just getting a framebuffer up was a lot of new work. Fully supporting the GPU cores will be necessary for a lot of people's use cases. Once that and most of the peripherals are sorted, maybe the AI cores will be addressed.
- jamadazi 5y ago
  ARM is just an instruction set architecture specification. It is not any specific CPU; there are many different implementations (different chip designs). They can differ to various degrees, and often have at least a few non-standard features. Hence, each ARM chip/platform often needs at least a little bit of special support (or drivers) to fully work in Linux, besides the standard ARM stuff. Apple's platform is actually very different, with much more non-standard stuff, compared to other ARM implementations. Hence, much more extensive work was required to support them, than would be typical for other ARM platforms. Even some of the really low-level features are different. For example, Apple have their own Interrupt Controller. Supporting it (in place of ARM's standard General Interrupt Controller) was a prerequisite to even be able to boot the linux kernel. Another weird thing about this platform is the bus configuration. Also, Power management is something that is virtually always chip-specific, and the Apple M1 has some unusual quirks on top of that.
skrtskrt 5y ago
Does anyone know about any progress about getting the latest Intel Macbooks working on Linux? I have a 2020 Intel MBA and it "works" as in it boots, but the laptop trackpad and keyboard don't do anything. Externals work, so it seems like a driver thing. There could be other problems, but I haven't gotten far enough to hit them because I don't see a point in using it unless the keyboard and trackpad work.
- cmrdsprklpny 5y ago
  I don't think this works with 2019 or later Intel Macbooks, but as far as I know the most recent relevant information and drivers are here: https://github.com/roadrunner2/macbook12-spi-driver https://github.com/roadrunner2/macbook12-spi-driver. In my own experience, it's the trackpad, keyboard, and built-in speakers that don't work, but everything else seemed to be fine (2015 macbook). Edit: this driver got the keyboard and trackpad to work, but the microphone, speakers, and webcam did not work. I also needed to downgrade to an older kernel (4.14) to get storage to work. All external things worked fine even through a hub, and the headphone jack also worked fine.
- n_u_l_l 5y ago
  A quick search led me to this: https://github.com/Dunedan/mbp-2016-linux#keyboard--touchpad https://github.com/Dunedan/mbp-2016-linux#keyboard--touchpad It seems to be related to the T2 chip and the BCE driver linked there should solve it.

189 points by boramalper 5y ago

I'm not hugely familiar with the Linux release cycle, can anyone explain why such rudimentary support should be merged in now, instead of waiting until it's ready?

bbojan 5y ago
Release early, release often?
gregkh 5y ago
Merge the portions that you know are correct and will have no affect on anyone else now, which makes future work easier as you do not have to keep those "working" commits up to date. We do this all the time with kernel development, and is one reason why breaking changes up into tiny pieces is so powerful. We can take the pieces that make sense now, and allow the developer to redo the portions that are not ready yet, instead of having to reject the whole thing if it were done in one single "chunk." Also note that the TTY/serial portions of this hardware support was already merged through the serial tree because they were independent and didn't affect anyone else.
- 600frogs 5y ago
  Interesting, thanks for the explanation. Has this style of development ever come back to bite you?
  - nousermane 5y ago
    Not GP, but... In the context of recent event, [0] where not reviewing thoroughly enough some tiny patches had a major come-back-to-bite fallout, I can't help but wonder: How, exactly are you expecting an increase in average patch size to help? [0] https://news.ycombinator.com/item?id=26887670 https://news.ycombinator.com/item?id=26887670
    - 600frogs 5y ago
      I did read through this debacle when it came out actually, I'm thoroughly on team Greg. I suppose my question was separate from malicious patches - I was interested in knowing if this incremental "merge tiny patches as and when they're ready" mode of development has ever caused issues with half-baked solutions affecting other parts of the kernel where perhaps it wouldn't have otherwise done so if the release was given more time for polishing and testing.
  - gregkh 5y ago
    Off the top of my head, no. The big "downside" is that it takes more work on the patch submitter side. But the benefits in the end are almost always more than worth it (easier reviewer time, easier time to track down problems, better development cycle as feedback can be more specific, easier evolution of changes, etc.) I wrote a whole chapter in the book "Beautiful Code" about how this development model can help create an end result that is almost always better than the initial "huge" submission model. Check it out if you are interested, it should be free online somewhere...
    - 600frogs 5y ago
      My instinct would have been that it's easier for the submitter (as they have less to polish and test) and more irksome for the reviewer as they have to go through multiple rounds of submissions, but naturally I'll take your word for it! This kind of discussion is always of interest to me, I'll check out the book, thank you.
      - Filligree 5y ago
        Reviewing three changelists, which individually do only a single thing each, is in my experience much easier than reviewing a single changelist bundling the changes from all three. This is true even if the same lines are changed multiple times. It's something you'll learn with experience, but it's also not even close. Break your patches up as much as possible, and everyone will be happier.
    - joseluisq 5y ago
      I found it, Greg's chapter `The Linux Kernel Driver Model: The Benefits of Working Together` on page 267 - https://www.oreilly.com/library/view/beautiful-code/9780596510046/ https://www.oreilly.com/library/view/beautiful-code/97805965... - https://github.com/stormtrooper96/books/blob/master/software-development/Beautiful%20Code.pdf https://github.com/stormtrooper96/books/blob/master/software... So I'll definitely give it a read. Thanks!
richardanaya 5y ago
One idea might be building a relationship of trust around a certain architecture in the Kernel, another idea is that it makes future work faster to merge in if the basics are already in.
soneil 5y ago
There's a relatively low cost to having this merged as it becomes available. It's not like x86 distros will be building it into their kernel.
regularfry 5y ago
It lets others build on it.
gsnedders 5y ago
Obviously you should listen to Greg and not me, but in many ways you can summarise it as "are the changes correct and do they work?". That they don't amount to end-user useful support is a very separate matter. What's the benefit of delaying submission of correct and working branches?
- aquadrop 5y ago
  If you plan for such model beforehand you already might be lowering overall efficiency. You know that you can't get the whole thing you want as one piece, but you plan "one third now, another third in a couple of months and the last third in more couple of months". Overall you might end up with twice the effort, since you had to account for that split, but in the context of kernel it still makes sense because of all the complexity and many people working on it simultaneously. And of course it also depends on "splitability" of the thing you're working on.
  - marcan_42 5y ago
    It's actually more efficient to do it this way. When you develop in a fork, you end up having to both keep rebasing on mainline, and then on submission, you might find that large parts of the code are the wrong approach or do not meet upstream standards, and need to be rewritten. By planning for incremental merges, you ensure that your foundation is solid and acceptable and avoid wasted work.
trissylegs 5y ago
It seems like it's ready to go in mailine. Linux doesn't really do "Big-bang" Everything is done releases of new features. Support is added incrementally. Here it says USB, PCIe, IOMMU, NVMe. Haven't been finished. But given those features are spread occross difference subsystems and have different maintainers it'll be easier to work on those once the platform is in Mainline. (You won't be able to expect all the PCIe developers to have the special M1 mac branch ready for testing)
- 600frogs 5y ago
  So it seems to be it's primarily solving branching issues rather than providing any benefit of the incremental support, is that correct?
  - viraptor 5y ago
    Depends what you mean by incremental support. It would definitely help someone to base new work on what's already approved, merged and supported without the need to hunt for the latest updated external branch and reconciling it with their local version. (But maybe that's what you're calling branching issues)
  - cestith 5y ago
    I'd rather spend time writing new branches against approved, merged upstream rather than submitting to an upstream branch that may never get reviewed and merged. Keep in mind, too, that the longer a branch lives the more rebasing it goes through. Also, the bigger the branch is, the more it is to review when finally considering whether to merge it. I think giving people a foundation on which to build is a good way to prevent a lot of extraneous work and also to build confidence in the direction of development.
Rhedox 5y ago
Easier to address feedback on the initial code now than when you have hundreds of lines building on top of it.
jononor 5y ago
This is an example of "integrate early, integrate often" which is a core part of Continuous Integration (CI). These days people tend to focus on the automation aspect of CI, but getting code into mainline early is also key.

pimeys 5y ago

So, if the machines last a long time without Louis Rossman style of issues, getting a M1 Macbook for NixOS in about a few years might make sense. Very nice.

nix23 5y ago
Bravo, watching Rossman and learned nothing...but hey, buy your Macbook if you like to produce e-waste.
- simonh 5y ago
  I'll take my environmental responsibility and recyclability advice from Greenpeace thanks.
  - lurker1928 5y ago
    cant tell if sarcasm....
  - nix23 5y ago
    That Advice? >>While transitioning to 100% recycled materials is critical to reducing the sector’s footprint, it is also fundamental for Apple and other major IT companies to design products that last, are easy to repair, and recyclable at their end of life. are easy to repair..... https://www.greenpeace.org/usa/news/apple-announces-commitment-to-100-recycled-materials-major-step-for-it-sector-greenpeace-response/ https://www.greenpeace.org/usa/news/apple-announces-commitme...
kreetx 5y ago
Would be great if everything were ready by the time 16" M models come out. :)
bobmaxup 5y ago
Who is Louis Rossman? What are his style of issues? Why should I know this?
- 5y ago

deleted 5y ago

[deleted]

apatheticonion 5y ago

How cool would it be if the iPhone got a pro variant running the M1 chip, someone unlocked the bootloader and installed Linux on it. Plug it into a thunderbolt dock and you have a full Linux desktop.

Teledhil 5y ago
The A14 is basically a M1 with less CPU and GPU cores, so I guess most of the work done for supporting the M1 on Linux could be reused for the A14.
vetinari 5y ago
In the past (pre-Android 10), you could do that with Samsung Galaxy phones - plug them into USB-C dock, launch Linux-on-Dex and you got Linux desktop.
- goffi 5y ago
  you can do that right now with a PinePhone.
  - apatheticonion 5y ago
    Wait... What?! EDIT: ah, sadly looks like it's not something that's daily drive-able https://www.youtube.com/watch?v=fCKMxzz9cjs https://www.youtube.com/watch?v=fCKMxzz9cjs
    - goffi 5y ago
      you can get a convergence pack with more RAM (3GB) and storage and with a USB-C docking bar (that you can also buy separately). Once plugged, you have a desktop GNU/Linux, I've tested with Plasma Mobile and it's working quite well (got a few crashes, but it's not flagged as fully stable yet).
    - josteink 5y ago
      The software is OKish and getting better at a steady rate. The SOC in the PinePhone is nowhere near beefy enough though. Running the same stack on an M1-chip would probably a game changer usability-wise.

mraza007 5y ago

Imagine running Linux on your iPhone. I just can’t wait for that day but the it doesn’t seem to happen anytime soon

joana035 5y ago
I guess that is already possible, I remember seeing a guy doing that somewhere in the internet.
- gtirloni 5y ago
  "A developer got Ubuntu Linux booting on the Apple iPhone 7" https://www.xda-developers.com/apple-iphone-7-ubuntu-linux-checkra1n-project-sandcastle/ https://www.xda-developers.com/apple-iphone-7-ubuntu-linux-c...
- gtk40 5y ago
  I've seen ways of running Android (Linux kernel) on iPhones for over a decade on-line, though I don't know that any ever fully supported it.
kreetx 5y ago
My dream would be to run nixos on my phone so I could have all my devices configured from a single set of config files. Could then unify entire infra from config to sync and backups.
peteretep 5y ago
Why though? Is the iPhone hardware that much better than their high-end competitors? I’m a big Apple fanboy but I buy an iPhone (and indeed a Mac) to run iOS (and macOS)
- boxed 5y ago
  Yes it is. Apple is way ahead of the competition in CPU design. Which is why the M1 is making Intel look so bad right now.

mishagale 5y ago

Doesn't Linux already have mature support for ARM? What's so different about the M1 that it needs all this extra work?

mhh__ 5y ago
Peripherals
mirthflat83 5y ago
…
tyingq 5y ago
A good overview: https://asahilinux.org/2021/03/progress-report-january-february-2021/ https://asahilinux.org/2021/03/progress-report-january-febru...
cestith 5y ago
ARM is a CPU ISA. A MacBook is a whole computer. A general purpose OS to be really useful needs to support the CPU, yes, but also the boot hardware, the bus, the video devices, keyboard, pointing devices, speakers, mic, line in, line out, the network hardware, internal storage, external storage, and preferably any peripheral through the USB ports or wirelessly that's USB or Bluetooth with a standard profile. Also remember that M1 is not only ARM. It's a SOC which combines ARM cores with GPU cores and AI-targeted cores. Targeting just that is a lot more work than just porting the ARM portion from a Raspberry Pi or an Android phone. I'm sure just getting a framebuffer up was a lot of new work. Fully supporting the GPU cores will be necessary for a lot of people's use cases. Once that and most of the peripherals are sorted, maybe the AI cores will be addressed.
jamadazi 5y ago
ARM is just an instruction set architecture specification. It is not any specific CPU; there are many different implementations (different chip designs). They can differ to various degrees, and often have at least a few non-standard features. Hence, each ARM chip/platform often needs at least a little bit of special support (or drivers) to fully work in Linux, besides the standard ARM stuff. Apple's platform is actually very different, with much more non-standard stuff, compared to other ARM implementations. Hence, much more extensive work was required to support them, than would be typical for other ARM platforms. Even some of the really low-level features are different. For example, Apple have their own Interrupt Controller. Supporting it (in place of ARM's standard General Interrupt Controller) was a prerequisite to even be able to boot the linux kernel. Another weird thing about this platform is the bus configuration. Also, Power management is something that is virtually always chip-specific, and the Apple M1 has some unusual quirks on top of that.

skrtskrt 5y ago

Does anyone know about any progress about getting the latest Intel Macbooks working on Linux? I have a 2020 Intel MBA and it "works" as in it boots, but the laptop trackpad and keyboard don't do anything. Externals work, so it seems like a driver thing. There could be other problems, but I haven't gotten far enough to hit them because I don't see a point in using it unless the keyboard and trackpad work.

cmrdsprklpny 5y ago
I don't think this works with 2019 or later Intel Macbooks, but as far as I know the most recent relevant information and drivers are here: https://github.com/roadrunner2/macbook12-spi-driver https://github.com/roadrunner2/macbook12-spi-driver. In my own experience, it's the trackpad, keyboard, and built-in speakers that don't work, but everything else seemed to be fine (2015 macbook). Edit: this driver got the keyboard and trackpad to work, but the microphone, speakers, and webcam did not work. I also needed to downgrade to an older kernel (4.14) to get storage to work. All external things worked fine even through a hub, and the headphone jack also worked fine.
n_u_l_l 5y ago
A quick search led me to this: https://github.com/Dunedan/mbp-2016-linux#keyboard--touchpad https://github.com/Dunedan/mbp-2016-linux#keyboard--touchpad It seems to be related to the T2 chip and the BCE driver linked there should solve it.