- Na geração M4·M5, o modo 3840×2160@2x HiDPI não é suportado em monitores 4K externos, e o máximo possível é 3360×1890
- Essa limitação ocorre devido a uma mudança na estrutura do firmware do Display Coprocessor (DCP), e não por um problema de desempenho de hardware
- No M5 Max, o orçamento de framebuffer foi realocado por pipe, reduzindo a largura do pipe de fluxo único para 6720 pixels
- Vários métodos foram tentados, como modificação de EDID, troca de porta e ajuste de propriedades de driver, mas nenhum funcionou
- Atualmente, a solução completa seria a Apple corrigir o firmware do DCP; como alternativa temporária, é possível implementar 2x HiDPI por espelhamento de display virtual
Análise da limitação de HiDPI em displays 4K externos no Apple Silicon M4/M5
- Nas gerações Apple Silicon M4 e M5, o modo HiDPI 2x completo (3840×2160@2x) não é oferecido para monitores 4K externos
- O modo HiDPI máximo fica limitado a 3360×1890, tornando impossível o 3840×2160 HiDPI que era viável nas gerações anteriores (M2/M3)
- O usuário precisa escolher entre texto borrado em modo não-HiDPI ou imagem nítida, mas com área de trabalho reduzida
- Essa limitação decorre de uma mudança na estrutura do firmware do Display Coprocessor (DCP), e não de um limite de hardware
- O M5 Max, pelas especificações, suporta 8K@60Hz, mas a capacidade reportada pelo DCP é a mesma do M2 Max
- Nas gerações M4/M5, o framebuffer budget foi realocado por pipe, reduzindo o orçamento do caminho 4K padrão de 7680 pixels para 6720 pixels
- A desmontagem do firmware do DCP mostra que o valor 6720 (0x1A40) existe como constante hardcoded
Ambiente de teste e resultados comparativos
| Item |
M5 Max (com problema) |
M2 Max (funciona normalmente) |
| Chip |
Apple M5 Max |
Apple M2 Max |
| ID do modelo |
Mac17,6 |
Mac14,6 |
| Núcleos de GPU |
40 |
38 |
| macOS |
26.4 (25E246) |
26.4 (25E246) |
| Display |
LG HDR 4K 32UN880 |
LG HDR 4K 32UN880 |
| Conexão |
USB-C/Thunderbolt (HBR3, 8.1Gbps, 4 lanes) |
Igual |
| Modo HiDPI máximo |
3360×1890 |
3840×2160 |
- Em ambos os sistemas, os parâmetros do DCP como
MaxActivePixelRate, MaxW, MaxH e MaxBpc são idênticos
- Na saída de
system_profiler, o backing store do M5 Max aparece como 6720×3780, e a UI como 3360×1890 HiDPI
- Na lista de
HiDPI modes, o item 3840×2160@2x também não existe
Mudanças na estrutura de framebuffer e pipe
- O M2 Max usa um orçamento único por controlador (
MaxSrcRectWidth=7680)
- O M5 Max mudou para uma estrutura de orçamento por sub-pipe (
MaxSrcRectWidthForPipe=(6720,7680,7680,7680))
- A saída 4K de fluxo único usa apenas o sub-pipe 0 (6720)
- A saída 8K usa 2 sub-pipes (0,2)
- Por causa disso, o 4K HiDPI (backing store de 7680×4320) excede o orçamento do sub-pipe 0 e não pode ser gerado
| Sub-pipe |
MaxSrcRectWidth |
Uso |
| 0 |
6720 |
Fluxo único (display padrão) |
| 1–3 |
7680 |
Multi-pipe (8K etc.) |
- Comparação de
MaxVideoSrcDownscalingWidth
| Controlador |
MaxSrcRectWidthForPipe[0] |
MaxVideoSrcDownscalingWidth |
Razão |
| Display interno |
5120 |
10744 |
2.1x |
| Display externo |
6720 |
6720 |
1.0x |
- O display interno tem margem de scaler, mas o externo não, o que impede 3840×2160 HiDPI
MaxSrcRectWidthForPipe e MaxVideoSrcDownscalingWidth ficam fixos no carregamento do driver e não podem ser alterados em runtime
- Mesmo com troca de porta, modo clamshell ou modificação de EDID, o valor continua 6720
Análise do firmware DCP
- O arquivo de firmware fica em
/System/Volumes/Preboot/<UUID>/restore/Firmware/dcp/, e o M5 Max usa t605xdcp.im4p
- Está em compressão LZFSE (4.1MB → 16.4MB) e não é criptografado, podendo ser extraído com
img4tool
- As propriedades relacionadas a HiDPI (
MaxVideoSrcDownscalingWidth, MaxSrcRectWidthForPipe, IOMFBMaxSrcPixels, ExternalAppleLook) são todas definidas dentro desse firmware
- A função
IOMFB::UPPipe::verify_downscaling(SwapRequest *) valida a largura de origem solicitada com base em MaxVideoSrcDownscalingWidth
- Resultado da análise no Ghidra
- Sub-pipe 0 de display externo:
0x1A40 (6720)
- Sub-pipes 1~3:
0x1E00 (7680)
- Sub-pipe 0 de display interno:
0x1400 (5120)
- Altura de todos os sub-pipes:
0x1200 (4608)
- A limitação opera em duas etapas
MaxSrcRectWidthForPipe[0] (6720) → limita na etapa de enumeração de modosMaxVideoSrcDownscalingWidth (6720) → limita na etapa de validação em runtime
- Como outros pipes do mesmo controlador suportam 7680, fica confirmado que é uma política de firmware, não uma restrição de hardware
Tentativas de resolver o problema
-
Display Override Plist
- Adição da resolução HiDPI 7680×4320 em
/Library/Displays/.../DisplayVendorID-1e6d/DisplayProductID-7750
- No M5 Max não teve efeito; no M2 Max funcionou normalmente
- O WindowServer do M5 Max não enumera esse modo
-
Patch de software no EDID
- Inserção de EDID modificado em
IODisplayEDID (4095×4095, pixel clock máximo de 655.35MHz etc.)
- Sem efeito
- O desenvolvedor do BetterDisplay relatou caso de sucesso em M4 obtendo framebuffer 8K via override de EDID por software
- Porém, como um painel 4K não consegue exibir sinal 8K real, isso não é uma solução prática
-
Flash de hardware no EDID
- Após adicionar o modo 7680×4320@60Hz (VIC 199) ao EDID e gravá-lo no EEPROM do monitor LG
- O DCP atualiza para
MaxW=7680, MaxH=4320, mas o limite de 6720 no sub-pipe 0 permanece
- Ao definir timing 8K como padrão, o modo 3840×2160@2x é criado, mas o macOS tenta enviar um sinal 8K real e a imagem não pode ser exibida
-
Modificação do registro IOKit
- Tentativa de alterar diretamente propriedades do DCP como
DisplayHints e ConnectionMapping
- O driver de kernel (
AppleDisplayCrossbar) recusa escrita (kIOReturnUnsupported)
-
Outras tentativas
- Limpeza do cache do WindowServer, redução do número de displays conectados, troca para HDMI e chamada da API privada do SkyLight (
SLConfigureDisplayWithDisplayMode) falharam
- Ao se passar por um display Apple (inserindo Apple Vendor ID no EDID), ele aparece como “Apple Pro Display X”, mas
ExternalAppleLook=No e não há mudança no orçamento
-
Resumo dos resultados de escrita de propriedades no IOKit
| Serviço |
Método |
Resultado |
| IOMobileFramebufferShim |
IORegistryEntrySetCFProperty |
kIOReturnUnsupported |
| AppleDisplayCrossbar etc. |
IORegistryEntrySetCFProperty |
kIOReturnNotReady |
| IOAVController |
IORegistryEntrySetCFProperty |
Accepted (mas não é repassado ao DCP) |
Teste de boot args de RuntimeProperty
- O firmware contém a função
IOMobileFramebuffer::parse_RTP_boot_args(), indicando possibilidade de sobrescrever propriedades no boot
- Ex.:
iomfb_RuntimeProperty_ExternalAppleLook, iomfb_enable_bw_check, iomfb_dual_pipe_policy etc.
- Com SIP e Startup Security relaxados, foi feito teste com
sudo nvram boot-args=, mas o firmware DCP não reagiu
- Supõe-se que esse caminho de código esteja ativado apenas para desenvolvimento
Solução temporária com Virtual Display Mirror
- Foi criada a ferramenta CLI
force-hidpi usando a API privada SLVirtualDisplay do SkyLight para criar um display virtual (7680×4320) e espelhar por hardware o painel 4K real
- O caminho de espelhamento por hardware contorna a verificação
verify_downscaling
- Em
system_profiler, aparece como “Hardware Mirror: Yes”
- Dessa forma, é possível implementar 3840×2160 HiDPI
- O texto fica nítido e a UI do macOS é renderizada com densidade 2x normal
- O display virtual usa PQ (ST 2084) EOTF e aplica correção de gama para painéis SDR
- Desvantagens
- A ferramenta precisa ficar rodando o tempo todo; ao encerrar, volta para 1.0x
- Um display adicional aparece nos Ajustes do Sistema
- A renderização de texto é ligeiramente diferente da HiDPI nativa do M2 Max
- A dependência de API privada pode causar instabilidade em atualizações do macOS
Resumo da causa e possibilidade de correção
- M2 Max: orçamento de 7680 pixels por controlador → 3840×2160 HiDPI possível
- M5 Max: mudança para estrutura por sub-pipe, com o pipe 0 de fluxo único limitado a 6720
- Com isso, o máximo de 4K HiDPI cai para 3360×1890
- Modificação de EDID, troca de porta e ajuste da quantidade de displays não mudam isso
- A solução definitiva é a Apple corrigir o firmware DCP (
t605xdcp.im4p)
- Elevar a constante hardcoded 0x1A40 para 0x1E00
- Permitir backing store HiDPI multi-pipe mesmo em pipe único
- Permitir alocação dinâmica com base nos displays conectados
- Expor propriedade de runtime ou boot args
- O feedback FB22365722 foi enviado à Apple
- A Apple está ciente do problema e, por enquanto, responde adicionando um aviso sobre a limitação de resolução escalada na página do produto
Resumo dos comandos de diagnóstico
ioreg -l -w0 | grep "IOMFBMaxSrcPixels" : verifica o orçamento de framebuffer por pipeioreg -l -w0 | grep "MaxVideoSrcDownscalingWidth" : verifica o limite do scalersystem_profiler SPDisplaysDataType : resumo do displayCGSGetNumberOfDisplayModes : verifica a lista de modos HiDPI
Exemplo de funcionamento normal no M2 Max
- O modo 3840×2160@2x HiDPI está presente
- Parâmetros do DCP:
MaxW=3840, MaxH=2160, MaxActivePixelRate=497,664,000
- Em
IOMFBMaxSrcPixels, é confirmado MaxSrcRectWidth=7680
- No mesmo display LG HDR 4K, é possível usar o modo HiDPI completo
2 comentários
O básico pelo menos deveria estar bem resolvido..
Comentários do Hacker News
Comprei recentemente um MacBook Pro M5 Pro pela primeira vez e estou um pouco arrependido
O notebook em si é excelente, mas não é realmente compatível com meu monitor LG 38WN95C-W (3840x1600@144Hz, USB-C)
Com o BetterDisplay dá para usar 3360x1400 HiDPI, mas acabo perdendo o espaço de tela ao qual estava acostumado
Eu não imaginava que o M5 seria pior que a geração anterior. A Apple acerta muita coisa, mas erra nesse tipo de ponto básico
Agora acho que vou ter que perguntar à Apple Intelligence como explicar para minha esposa que preciso de um monitor novo
Era um bug de DisplayPort DSC em que o macOS, desde o Catalina, não suportava taxas de atualização acima de 60Hz
O suporte da Apple ficou repetindo diagnósticos por semanas e no fim encerrou como “WontFix”, mas depois do e-mail foi corrigido no Sonoma
Link do fórum relacionado
O problema apareceu depois que troquei do macOS Sequoia para o Tahoe
Esse problema atual pode ser uma continuação disso
Dá para ver que o autor colocou um esforço enorme para resolver esse problema.
É triste que precise chegar a esse ponto para a Apple reconhecer a falha
No fim, resolvi destravando as limitações do Mac no BetterDisplay e combinando um cabo DisplayLink com um dongle HDMI com alimentação
5120x1440 @ lodpi era borrado demais, mas consegui estabilizar em 10240x2880 @ 120Hz HDR
Ri ao ver o título. A dor do OP é muito identificável
O autor provavelmente também começou sem quase nenhum conhecimento sobre displays
Também quase enlouqueci porque um monitor externo 4K parecia borrado no meu novo MacBook M4
Nem replicar a configuração anterior resolveu, e comecei a suspeitar que a Apple só otimiza para seus próprios displays
Nem o Windows 11 tem esse tipo de problema, mas no macOS o texto fica estranho em monitores que não são da Apple
Eu já tinha enfrentado isso na época dos Macs Intel ao conectar via dock Thunderbolt
Queria que eles voltassem a oferecer a opção de renderização subpixel
Uso há 8 anos um monitor 4K de 43" em escala 1x e nunca notei diferença entre Linux, M1 e M4
Se for um monitor com EDID bagunçado, talvez dê para resolver com o app CLI screenresolution
Com ele consegui definir resoluções e taxas de atualização arbitrárias e usar até 100Hz com estabilidade
Será que o autor está tentando renderizar um framebuffer 8K em um display 4K e depois fazer downscale?
Fico curioso sobre qual seria a vantagem em relação a um simples 4K low-DPI. É uma espécie de anti-aliasing grátis?
No Windows, em escala 1,5x o texto fica borrado, mas no macOS ele reduz um framebuffer 6K para 4K para manter a nitidez
Mesmo em um monitor 2K, se você reduzir um framebuffer virtual 5K para 2K, fica muito mais nítido do que o 2K padrão do macOS
Também enfrentei um problema parecido com o M5 Air
Um monitor 4K 60Hz funciona bem, mas, quando conecto dois monitores gamer 4K de alta taxa de atualização ao mesmo tempo, um deles não é reconhecido
Depois de testar vários cabos, percebi que no fim era limitação de largura de banda
Isso não é uma configuração Retina comum.
É uma configuração incomum em que o framebuffer fica muito maior que a resolução real e depois é reduzido
Como a maioria dos usuários não quer esse tipo de configuração, a Apple aparentemente não liga muito para isso
então é meio decepcionante que o Mac, a principal plataforma para criadores, não consiga lidar com isso
Em HiDPI, não seria 1080p@2x? Isso ainda é possível?
Mas não entendo por que usar um buffer 7680x4320.
No meu Mac M4, uso um display 4K com buffer 5120x2880 (2560x1440@2x) e funciona bem
Isso no macOS Sequoia
Isso seria apenas 2160p@2x em um monitor 8K. Escala de 100% em 4K fica ruim em qualquer sistema operacional
Acho que o texto ficaria mais convincente se tivesse capturas de tela comparando o borrado do texto