1 points par GN⁺ 29 일 전 | Aucun commentaire pour le moment. | 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

Aucun commentaire pour le moment.

Aucun commentaire pour le moment.