Les puces Apple Silicon M4·M5 imposent une limite de résolution HiDPI sur les écrans externes 4K

 (smcleod.net)
1 points par GN⁺ 2026-04-01 | 2 commentaires | Partager sur WhatsApp
  • Sur la génération M4·M5, le mode 3840×2160@2x HiDPI n’est pas pris en charge sur les moniteurs externes 4K, et la résolution maximale possible est limitée à 3360×1890
  • Cette limitation provient d’un changement dans l’architecture du firmware du Display Coprocessor (DCP), et non d’un problème de performances matérielles
  • Sur le M5 Max, le budget de framebuffer a été réalloué par pipe, ce qui réduit la largeur d’un pipe mono-flux à 6720 pixels
  • Diverses méthodes ont été testées, comme la modification de l’EDID, le changement de port ou l’ajustement de propriétés du pilote, mais aucune n’a fonctionné
  • À ce jour, la seule solution complète serait qu’Apple corrige le firmware du DCP ; en attendant, il est possible d’obtenir un 2x HiDPI via une méthode temporaire de mise en miroir avec écran virtuel

Analyse de la limite HiDPI des écrans externes 4K sur Apple Silicon M4/M5

  • Les Apple Silicon de génération M4 et M5 ne proposent pas de mode HiDPI 2x complet (3840×2160@2x) sur les moniteurs externes 4K
    • Le mode HiDPI maximal est limité à 3360×1890, ce qui rend impossible le 3840×2160 HiDPI disponible sur les générations précédentes (M2/M3)
    • Les utilisateurs doivent choisir entre du texte flou en mode non-HiDPI ou un espace de travail net mais réduit
  • Cette limitation provient d’un changement dans l’architecture du firmware du Display Coprocessor (DCP), et non d’une limite matérielle
    • Le M5 Max prend en charge le 8K@60Hz sur le papier, mais les capacités rapportées par le DCP sont identiques à celles du M2 Max
    • Sur la génération M4/M5, le budget de framebuffer a été réalloué par pipe, réduisant le budget du chemin 4K standard de 7680 pixels à 6720 pixels
    • Le désassemblage du firmware DCP montre que la valeur 6720 (0x1A40) est présente comme constante codée en dur

Environnement de test et résultats comparatifs

Élément M5 Max (problème présent) M2 Max (fonctionnement normal)
Puce Apple M5 Max Apple M2 Max
ID modèle Mac17,6 Mac14,6
Cœurs GPU 40 38
macOS 26.4 (25E246) 26.4 (25E246)
Écran LG HDR 4K 32UN880 LG HDR 4K 32UN880
Connexion USB-C/Thunderbolt (HBR3, 8.1Gbps, 4 lanes) Identique
Mode HiDPI maximal 3360×1890 3840×2160
  • Sur les deux systèmes, les paramètres DCP comme MaxActivePixelRate, MaxW, MaxH et MaxBpc sont identiques
  • Dans la sortie de system_profiler, le backing store du M5 Max apparaît en 6720×3780, et l’interface en 3360×1890 HiDPI
  • La liste des HiDPI modes ne contient pas non plus d’entrée 3840×2160@2x

Évolution de la structure des framebuffers et des pipes

  • Le M2 Max utilise un budget unique par contrôleur (MaxSrcRectWidth=7680)
  • Le M5 Max adopte une structure de budget par sous-pipe (MaxSrcRectWidthForPipe=(6720,7680,7680,7680))
    • Une sortie 4K mono-flux n’utilise que le sub-pipe 0 (6720)
    • Une sortie 8K utilise 2 sub-pipes (0,2)
  • En conséquence, un mode 4K HiDPI (backing store 7680×4320) dépasse le budget du sub-pipe 0 et ne peut pas être créé
Sub-pipe MaxSrcRectWidth Usage
0 6720 Flux unique (écran standard)
1–3 7680 Multi-pipe (8K, etc.)
  • Comparaison de MaxVideoSrcDownscalingWidth
    Contrôleur MaxSrcRectWidthForPipe[0] MaxVideoSrcDownscalingWidth Ratio
    Écran interne 5120 10744 2.1x
    Écran externe 6720 6720 1.0x
    • L’écran interne dispose d’une marge de mise à l’échelle, mais pas l’externe, ce qui empêche le 3840×2160 HiDPI
  • MaxSrcRectWidthForPipe et MaxVideoSrcDownscalingWidth sont figés au chargement du pilote et ne peuvent pas être modifiés à l’exécution
    • Le changement de port, le mode clamshell ou la modification de l’EDID conservent tous la valeur 6720

Analyse du firmware DCP

  • Le fichier du firmware se trouve dans /System/Volumes/Preboot/<UUID>/restore/Firmware/dcp/ ; le M5 Max utilise t605xdcp.im4p
    • Il est compressé en LZFSE (4.1MB → 16.4MB) et n’est pas chiffré, ce qui permet son extraction avec img4tool
  • Les propriétés liées au HiDPI (MaxVideoSrcDownscalingWidth, MaxSrcRectWidthForPipe, IOMFBMaxSrcPixels, ExternalAppleLook) sont toutes définies dans ce firmware
  • La fonction IOMFB::UPPipe::verify_downscaling(SwapRequest *) vérifie la largeur source demandée en s’appuyant sur MaxVideoSrcDownscalingWidth
  • Résultats de l’analyse avec Ghidra
    • Sub-pipe 0 de l’écran externe : 0x1A40 (6720)
    • Sub-pipes 1 à 3 : 0x1E00 (7680)
    • Sub-pipe 0 de l’écran interne : 0x1400 (5120)
    • Hauteur de tous les sub-pipes : 0x1200 (4608)
  • La limitation fonctionne en deux étapes
    1. MaxSrcRectWidthForPipe[0] (6720) → limitation au stade de l’énumération des modes
    2. MaxVideoSrcDownscalingWidth (6720) → limitation au stade de la validation à l’exécution
  • Comme d’autres pipes du même contrôleur prennent en charge 7680, cela confirme qu’il s’agit d’une politique du firmware, et non d’une contrainte matérielle

Tentatives de résolution du problème

  • Display Override Plist

    • Ajout d’une résolution HiDPI 7680×4320 dans /Library/Displays/.../DisplayVendorID-1e6d/DisplayProductID-7750
    • Aucun effet sur le M5 Max ; fonctionnement normal sur le M2 Max
    • Le WindowServer du M5 Max n’énumère pas ce mode

  • Patch logiciel de l’EDID

    • Injection d’un EDID modifié dans IODisplayEDID (4095×4095, pixel clock maximal 655.35MHz, etc.)
    • Aucun effet
    • Le développeur de BetterDisplay a signalé un cas de réussite sur M4 pour obtenir un framebuffer 8K via override logiciel de l’EDID
    • Mais un panneau 4K ne peut pas réellement afficher un signal 8K, ce qui n’en fait pas une solution pratique

  • Flash matériel de l’EDID

    • Ajout du mode 7680×4320@60Hz (VIC 199) dans l’EDID puis flash de l’EEPROM du moniteur LG
    • Le DCP met bien à jour MaxW=7680 et MaxH=4320, mais la limite de 6720 sur le sub-pipe 0 reste en place
    • Si le timing 8K est défini par défaut, le mode 3840×2160@2x est généré, mais macOS tente alors de sortir un véritable signal 8K, impossible à afficher

  • Modification du registre IOKit

    • Tentatives de modification directe des propriétés DCP comme DisplayHints et ConnectionMapping
    • Le pilote kernel (AppleDisplayCrossbar) refuse l’écriture (kIOReturnUnsupported)

  • Autres essais

    • Échec également de la suppression du cache WindowServer, de la réduction du nombre d’écrans connectés, du passage en HDMI ou de l’appel à l’API privée SkyLight SLConfigureDisplayWithDisplayMode
    • En se faisant passer pour un écran Apple (insertion du Vendor ID Apple dans l’EDID), l’écran apparaît comme « Apple Pro Display X », mais ExternalAppleLook=No et le budget reste inchangé

  • Résumé des résultats d’écriture de propriétés IOKit

    Service Méthode Résultat
    IOMobileFramebufferShim IORegistryEntrySetCFProperty kIOReturnUnsupported
    AppleDisplayCrossbar, etc. IORegistryEntrySetCFProperty kIOReturnNotReady
    IOAVController IORegistryEntrySetCFProperty Accepted (mais non transmis au DCP)

Test des boot args RuntimeProperty

  • Le firmware contient une fonction IOMobileFramebuffer::parse_RTP_boot_args() laissant envisager une redéfinition de propriétés au démarrage
    • Exemples : iomfb_RuntimeProperty_ExternalAppleLook, iomfb_enable_bw_check, iomfb_dual_pipe_policy, etc.
  • Des tests ont été effectués avec sudo nvram boot-args= après assouplissement de SIP et de Startup Security, mais le firmware DCP ne réagit pas
    • Il est supposé que ce chemin de code n’est activé qu’en environnement de développement

Solution de contournement temporaire via Virtual Display Mirror

  • Un outil CLI force-hidpi a été développé afin d’utiliser l’API privée SLVirtualDisplay de SkyLight pour créer un écran virtuel (7680×4320) puis effectuer une mise en miroir matérielle vers le panneau 4K réel
    • Le chemin de miroir matériel contourne la vérification verify_downscaling
    • system_profiler affiche alors « Hardware Mirror: Yes »
  • Cette méthode permet d’obtenir du 3840×2160 HiDPI
    • Le texte est net et l’interface macOS est rendue avec une densité 2x normale
    • L’écran virtuel utilise un EOTF PQ (ST 2084) avec correction gamma appliquée pour les panneaux SDR
  • Inconvénients
    • L’outil doit rester lancé en permanence, et sa fermeture fait revenir l’affichage en 1.0x
    • Un écran supplémentaire apparaît dans les réglages système
    • Le rendu du texte diffère légèrement du HiDPI natif d’un M2 Max
    • La dépendance à une API privée peut rendre la solution instable lors des mises à jour de macOS

Résumé de la cause et des possibilités de correction

  • M2 Max : budget de 7680 pixels par contrôleur → 3840×2160 HiDPI possible
  • M5 Max : passage à une structure par sub-pipe, avec pipe mono-flux (0) limité à 6720
  • Cela réduit le maximum 4K HiDPI à 3360×1890
  • La modification de l’EDID, le changement de port ou l’ajustement du nombre d’écrans n’y changent rien
  • La solution de fond serait qu’Apple corrige le firmware DCP (t605xdcp.im4p)
    1. Relever la constante codée en dur de 0x1A40 à 0x1E00
    2. Autoriser un backing store HiDPI multi-pipe même en mode mono-pipe
    3. Permettre une allocation dynamique selon l’écran connecté
    4. Exposer des propriétés runtime ou des boot args
  • Le feedback Apple FB22365722 a été soumis
  • Apple est au courant du problème et répond pour l’instant en ajoutant un avertissement sur la limitation des résolutions à l’échelle sur les pages produit

Récapitulatif des commandes de diagnostic

  • ioreg -l -w0 | grep "IOMFBMaxSrcPixels" : vérifier le budget de framebuffer par pipe
  • ioreg -l -w0 | grep "MaxVideoSrcDownscalingWidth" : vérifier la limite du scaler
  • system_profiler SPDisplaysDataType : résumé de l’affichage
  • CGSGetNumberOfDisplayModes : vérifier la liste des modes HiDPI

Exemple de fonctionnement normal sur M2 Max

  • Le mode 3840×2160@2x HiDPI est présent
  • Paramètres DCP : MaxW=3840, MaxH=2160, MaxActivePixelRate=497,664,000
  • IOMFBMaxSrcPixels confirme MaxSrcRectWidth=7680
  • Le mode HiDPI complet est disponible sur le même écran LG HDR 4K

À lire aussi

2 commentaires

 
cnaa97 2026-04-01

Le minimum, ce serait de bien assurer les bases...
 
GN⁺ 2026-04-01
Réactions sur Hacker News

  • J’ai récemment acheté mon premier MacBook Pro M5 Pro et je le regrette un peu
    Le portable lui-même est excellent, mais il n’est pas correctement compatible avec mon moniteur LG 38WN95C-W (3840x1600@144Hz, USB-C)
    Avec BetterDisplay, je peux obtenir du 3360x1400 HiDPI, mais je perds l’espace d’affichage auquel j’étais habitué
    Je ne pensais pas que le M5 serait pire que la génération précédente. Apple fait beaucoup de choses bien, mais se trompe sur des points aussi basiques
    Maintenant, je vais sans doute demander à Apple Intelligence comment expliquer à ma femme qu’il me faut un nouveau moniteur

    • J’ai eu un problème similaire, et il a été résolu après avoir envoyé un e-mail à Tim Cook
      C’était un bug DisplayPort DSC qui empêchait macOS de prendre en charge les taux de rafraîchissement au-dessus de 60 Hz depuis Catalina
      Le support Apple a passé des semaines à répéter des diagnostics pour finir par conclure par un « WontFix », mais après l’e-mail, ça a été corrigé dans Sonoma
      Lien vers le forum concerné
      • Je ne m’attends pas vraiment à ce qu’un e-mail au CEO lui parvienne, mais on ne sait jamais, alors j’en ai envoyé un aussi
      • J’ai moi aussi upgradé de M1 Pro à M5 Pro, et même avec la même combinaison dock + moniteur, je n’obtiens plus plus de 4K 60 Hz
        Le problème est apparu après être passé de macOS Sequoia à Tahoe
      • Je viens moi aussi d’envoyer un e-mail. C’est vraiment un problème absurde
      • C’est en lisant ça que j’ai compris pourquoi mon macOS me semblait plus lent que Windows sur le même moniteur 144 Hz
      • Ce n’est pas totalement corrigé. Apple a manipulé le DP 1.4 pour faire tourner le ProDisplay XDR,
        et il est possible qu’ils aient négocié avec des moniteurs non Apple en faisant croire que le GPU ne prenait en charge que le 1.2.
        Ce problème pourrait être dans la continuité de ça

  • On voit que l’auteur a déployé des efforts énormes pour essayer de résoudre ce problème.
    C’est triste qu’il faille aller aussi loin pour qu’Apple reconnaisse le souci

    • J’ai moi aussi galéré avec un 57" G9 ultrawide à cause des réglages PIP/PBP
      J’ai fini par résoudre ça en débloquant les restrictions du Mac dans BetterDisplay, puis en combinant un câble DisplayLink et un dongle HDMI alimenté
      Le 5120x1440 @ lodpi était beaucoup trop flou, mais j’ai stabilisé le tout en 10240x2880 @ 120Hz HDR
      Le titre m’a fait rire. Je compatis tellement à la souffrance de l’OP
    • J’ai moi aussi passé tout le week-end à me casser la tête pour trouver une solution, mais il n’y avait pas vraiment de contournement valable
    • J’ai eu un problème similaire, et le fait d’explorer le matériel avec Claude ou GPT m’a été utile, car ils proposaient rapidement des étapes de dépannage
      L’auteur aussi a probablement commencé avec très peu de connaissances sur les écrans

  • J’ai moi aussi cru devenir fou avec un nouveau MacBook M4 parce que mon moniteur 4K externe paraissait flou
    Même en recopiant ma configuration précédente, rien n’a résolu le problème, et je soupçonne Apple d’optimiser uniquement pour ses propres écrans

    • La façon dont macOS gère la résolution et la mise à l’échelle reste étrange
      Même Windows 11 n’a pas ce genre de problème, alors que sur macOS les polices ont un rendu bizarre sur les moniteurs non Apple
      J’avais déjà rencontré ce problème à l’époque des Mac Intel avec une connexion via dock Thunderbolt
      J’aimerais qu’ils réintroduisent l’option de rendu sous-pixel
    • Je ne comprends pas pourquoi « lodpi » serait flou.
      J’utilise un moniteur 4K de 43" en échelle 1x depuis 8 ans, et je n’ai jamais senti de différence entre Linux, M1 et M4
    • J’ai moi aussi essayé toutes les combinaisons avec BetterDisplay, mais les polices restaient floues. Sur les grands moniteurs 5k2k, c’était particulièrement frustrant
    • Vu l’instabilité générale de la qualité de macOS ces temps-ci, il est fort possible que ce soit simplement dû à une mauvaise gestion interne de l’entreprise

  • Si c’est un moniteur avec un EDID corrompu, on peut peut-être le corriger avec l’appli CLI screenresolution
    Avec ça, j’ai pu définir des résolutions et fréquences arbitraires et l’utiliser de manière stable jusqu’à 100 Hz

    • Merci. Cela dit, cet outil semble seulement modifier la résolution et le taux de rafraîchissement, sans contrôle de la mise à l’échelle HiDPI

  • Est-ce que l’auteur essaie d’afficher un écran 4K en rendant dans un framebuffer 8K puis en réduisant l’échelle ?
    Je me demande quel avantage cela apporte par rapport à un simple 4K low-DPI. Est-ce une sorte d’anticrénelage gratuit ?

    • Oui. Sur macOS, la qualité du rendu du texte est mauvaise quand l’échelle n’est pas en 2x, donc c’est pour ça
    • L’idée est surtout d’éviter une perte de qualité lors de la mise à l’échelle sur une résolution non native
      Sous Windows, en échelle 1.5x, le texte devient flou, mais macOS réduit un framebuffer 6K vers du 4K pour conserver la netteté
    • J’utilise moi aussi BetterDisplay de cette manière
      Même sur un moniteur 2K, réduire un framebuffer virtuel 5K vers 2K est bien plus net que le 2K natif de macOS

  • J’ai eu un problème similaire sur un M5 Air
    Un moniteur 4K 60 Hz fonctionne bien, mais si je branche deux moniteurs gaming 4K à haut taux de rafraîchissement en même temps, l’un des deux n’est pas reconnu
    En changeant de câbles, j’ai fini par comprendre que c’était dû à une limite de bande passante

  • Ce n’est pas une configuration Retina classique.
    Le framebuffer est bien plus grand que la résolution réelle, puis réduit, ce qui en fait une configuration atypique
    Comme la plupart des utilisateurs ne veulent pas de ce type de configuration, Apple ne semble pas y prêter attention

    • J’ai simplement branché un LG UltraFine 4K standard à un MacBook Pro M5, donc j’ai du mal à comprendre en quoi ce serait une configuration anormale
    • Ce n’est pas une sorte de suréchantillonnage 2x ? Pour un anticrénelage parfait, ça semble nécessaire
    • Je suis moi aussi d’accord avec l’idée que c’est une configuration atypique. Je me demande pourquoi rendre avec deux fois plus de pixels pour ensuite réduire de moitié
    • Mais même des PC portables Windows d’entrée de gamme gèrent ce type de résolution sans difficulté,
      donc c’est un peu décevant que le Mac, plateforme de référence pour les créatifs, n’en soit pas capable

  • En HiDPI, ce n’est pas plutôt du 1080p@2x ? Est-ce que ça fonctionne encore ?

    • Oui. Sur un écran 3840x2160, l’usage courant sous macOS est du 1920x1080@2x
      Mais je ne comprends pas pourquoi on utiliserait un buffer 7680x4320.
      Sur mon Mac M4, j’utilise un écran 4K avec un buffer 5120x2880 (2560x1440@2x) et ça fonctionne bien
      C’est sous macOS Sequoia
    • Je ne suis pas sûr de bien comprendre l’idée principale de cet article. Le 4K HiDPI n’existe pas sur un moniteur 4K.
      Ce serait simplement du 2160p@2x sur un moniteur 8K. Le 4K à 100 % d’échelle n’est agréable à regarder sur aucun OS
    • Au final, il semble parler d’une configuration atypique en 2160p@2x

  • L’article serait plus convaincant avec des captures d’écran comparant le flou du texte

    • Merci pour le retour. Ce n’est pas facile à photographier correctement, mais je vais essayer d’ajouter des photos après le travail et de mettre à jour le billet