| 22 Oct 2024 |
 samasaur | In reply to @samasaur:matrix.org
ah okay so if you do a daemon instead of an agent it shows up in system settings like this (key point that it shows up but starts disabled) | 07:18:32 |
| samasaur | (ignore that it is still called "My Example LaunchAgent" instead of "My Example LaunchDaemon") | 07:19:18 |
| samasaur | anyway i'm going to bed. i'll take another look in the morning, but the docs seem to be pretty clear that you need manual admin approval in system settings for daemons. | 07:23:37 |
| * samasaur contemplates using AppleScript to automate enabling the toggle switch | 07:24:14 |
| samasaur | In reply to @emilazy:matrix.org
btw staging-next has enough cached now that you can feasibly play around with it yay! maybe i will also do the rest of the work to make this a drop-in replacement for launchagents in HM and nix-darwin! | 07:25:16 |
| samasaur | these are tomorrow tasks though | 07:25:36 |
 Gaétan Lepage | Any idea why a rust compilation could fail on aarch64-darwin with:
= note: ld: library not found for -lIOReport
clang-16: error: linker command failed with exit code 1 (use -v to see invocation)
but succeed on x86_64-darwin.
For context, I have darwin.apple_sdk.frameworks.IOKit in buildInputs.
Is is a matter of SDK version difference between those two platforms ? | 07:30:52 |
 emily | have you tried staging-next? | 07:31:53 |
| emily | it looks like IOReport is some private thing, maybe. | 07:32:06 |
| emily | what are you building? | 07:32:11 |
| Gaétan Lepage | https://github.com/NixOS/nixpkgs/pull/350098/files#diff-19a8322da7f7dad2c92a0ca5d4e86d5f5a01482e2e6f1b37e976dd5280b257c3R86-R111 | 07:34:16 |
| emily | right. does it work on staging-next? | 07:36:30 |
| Gaétan Lepage | I'm trying right now | 07:39:08 |
| Gaétan Lepage | but some dependencies fail there unfortunately.
I will try to build the rust dep alone though | 07:39:23 |
| Gaétan Lepage | It works on staging-next indeed :) | 07:42:51 |
| Gaétan Lepage | I'll just wait for that then. Thanks for the help ! | 07:43:02 |
| emily | yay | 07:46:45 |
| emily | probably skip marking it as broken | 07:46:48 |
| emily | since it will unbreak soon | 07:46:52 |
| Gaétan Lepage | Ok seems fair | 07:47:10 |
| emily | the macOS EDR stuff is so clever. having something brighter than #fff appear seamlessly on an SDR screen is bizarre. | 07:50:57 |
|  @zarel_it:matrix.org left the room. | 09:31:34 |
 toonn | Tell us how it works! | 09:46:48 |
 K900 | They know the exact colorimetry of the display | 09:47:56 |
| K900 | So they just do everything in display color space. | 09:48:29 |
| K900 | So applications that are aware of the trick get the full physically possible gamut of the display | 09:49:08 |
| K900 | You can generally do the same trick on any OS, except it doesn't work nearly as well when the display colorimetry you get from EDID is literally just wrong most of the time | 09:50:13 |
| toonn | Does that restrict how many panel providers they can work with? Or do they just need precise measurements for whatever panel happens to go in a device? | 09:50:41 |
| K900 | Well presumably they still read the EDID | 09:51:30 |
| K900 | Or just have the profiles hardcoded somewhere | 09:51:40 |
