3 ms·

Doesn't macOS also use this for power savings, rather than only DRM? This is something that Linux is also starting to pick up, and is probably one of the bigges

Doesn't macOS also use this for power savings, rather than only DRM? This is something that Linux is also starting to pick up, and is probably one of the biggest reasons for Apple Silicon Macs having superior battery life. The GPU is the thing decoding the video stream and putting it directly on the display (via hardware planes). It doesn't need to send it back (aka copy) to the main CPU. Screenshots can't see what's there because the CPU has no knowledge of whats there. Rather than the GPU decoding the video, sending it back to the CPU which then will send the frame back to the GPU as part of composition, and wasting power.

walterbell 2y ago
If the user requests a screenshot, the CPU can request a frame from the GPU.
bigyabai 2y ago
Digital Rights Management != Direct Rendering Manager
mjg59 2y ago
Video RAM is accessible to the OS, if you render into it it can be read back. In this case it's deliberately rendered into a separate protected area of RAM the OS can't read, and composited at scanout time.
- krackers 2y ago
  Compositing is done by the OS though (WindowServer in case of mac). Ever since OSX stopped allowing direct framebuffer access I think the only way to read (e.g. for screenshots) windows of other processes' is by asking WindowServer to do it for you, so I'm guessing that's how this protection is implemented. WindowServer ultimately still needs to get access to the framebuffer somehow though, so there must be some private API somewhere to bridge kernel and userspace part. I suspect if you could bypass SIP or just write a kext to access video memory directly then it'd be possible to defeat this protection.
  - mjg59 2y ago
    Compositing into the framebuffer is done by the OS, the compositing of the DRMed video stream into the output is done in hardware. The OS literally has no visibility into the decoded content. You suspect incorrectly.

walterbell 2y ago

If the user requests a screenshot, the CPU can request a frame from the GPU.

bigyabai 2y ago

Digital Rights Management != Direct Rendering Manager

mjg59 2y ago

Video RAM is accessible to the OS, if you render into it it can be read back. In this case it's deliberately rendered into a separate protected area of RAM the OS can't read, and composited at scanout time.

krackers 2y ago
Compositing is done by the OS though (WindowServer in case of mac). Ever since OSX stopped allowing direct framebuffer access I think the only way to read (e.g. for screenshots) windows of other processes' is by asking WindowServer to do it for you, so I'm guessing that's how this protection is implemented. WindowServer ultimately still needs to get access to the framebuffer somehow though, so there must be some private API somewhere to bridge kernel and userspace part. I suspect if you could bypass SIP or just write a kext to access video memory directly then it'd be possible to defeat this protection.
- mjg59 2y ago
  Compositing into the framebuffer is done by the OS, the compositing of the DRMed video stream into the output is done in hardware. The OS literally has no visibility into the decoded content. You suspect incorrectly.