La pantalla del MacBook Pro 2012 no se despierta del reposo cuando se ejecuta Catalina a bigsur(patched sur)

Aquí está un resumen de su informe inicial:

1. Has utilizado software de terceros para permitir la instalación de Catalina en un sistema que es demasiado antiguo para ser soportado de forma nativa.
2. Te has dado cuenta de que (A) tu pantalla carece de regulador de brillo y (B) la pantalla no se enciende después de dormir.

Ahora bien, tanto los síntomas (A) como los (B) pueden aparecer por sí solos por diferentes motivos. El hecho de que se produzcan simultáneamente y de que nada parezca resolverlos sugiere fuertemente que hay un fallo en alguna parte del camino del luz de fondo de la pantalla cadena. Sin información adicional, esto puede significar una causa root de hardware, firmware o software. Así que debemos investigar cada una de estas áreas por separado.

La retroiluminación de la pantalla se compone de circuitos dedicados y componentes de software. El circuito incluye el Panel de retroiluminación LED junto con un controlador de hardware que interactúa con la CPU y permite que el software del sistema (y del usuario) le dé órdenes. Por lo tanto, este controlador requiere software de controladores que está escrito específicamente para el hardware del controlador exacto utilizado en su máquina en particular. Si el controlador no está presente y en funcionamiento, el sistema no tiene forma de emitir comandos al controlador de retroiluminación para cambiar la cantidad de corriente eléctrica que envía al panel LED (es decir, cambiar el brillo).

Así que primero debemos comprobar que el controlador está presente y cargado. Para ello, te pedí que comprobaras la salida de kextstat y systemextensionsctl para la presencia de extensiones del núcleo del controlador de la luz de fondo. Su salida confirma que los KEXTs necesarios están, de hecho, cargados correctamente.

Es fundamental recordar que Apple es libre de cambiar la implementación del hardware de retroiluminación entre dos modelos de ordenador cualquiera. Cuando lo hagan, el es necesario actualizar el software del controlador para añadir soporte a una nueva implementación de hardware. Si se utiliza un controlador antiguo con un hardware nuevo, es muy probable que la retroiluminación funcione mal o no funcione en absoluto.

(Por ejemplo, un nuevo microcontrolador puede tener un mapa de direcciones IO diferente y el envío de comandos a la dirección de un periférico en el antiguo microcontrolador (1) impedirá que el periférico vea el comando y (2) probablemente corromperá involuntariamente un registro no relacionado).

Por ello, los controladores, en general, son necesariamente parcial o totalmente específicos del hardware, por lo que antes de que un controlador intente hablar con el hardware debe asegurarse de que sólo se dirige al hardware exacto que soporta. Hay muchas maneras de lograr esto. Una forma primitiva, que sólo funciona porque Apple es un proveedor vertical, es la de bloquear la carga del controlador en el modelo de Mac que usted tiene. Esto se hace a través de IOKit a través del board-id en el nodo del Experto en Plataforma. Se trata de un UUID que tiene una correspondencia 1:1 con su tipo de máquina y su generación (por ejemplo, MacBookPro10,1 ). Si un conductor consulta su board-id y coincide con la lista de placas soportadas por el controlador, entonces el controlador sabe que está familiarizado con su hardware y puede proceder a empezar a controlarlo. Si tu placa no está en la lista, entonces el controlador puede fallar con gracia y no intentar controlar un hardware con el que no sabe cómo hablar.

Una de las posibilidades que sospeché con tu problema, debido a que corres en un sistema no soportado, es que el controlador de la luz de fondo no fue escrito con conocimiento de tu hardware específico de la luz de fondo y por lo tanto es incapaz de controlarlo. Con un poco de investigación, creo que he encontrado el lugar donde se hace esa determinación: Durante el sondeo activo en el AGDCBacklightControl conductor. Cuando eche un vistazo a la entrada IORegistry del controlador ( ioreg -r -c AGDCBacklightControl ) notarás que (1) siempre va a coincidir pasivamente y (2) hay una propiedad llamada ConfigMap que es una matriz de board-id s. La conclusión obvia es que esta es la lista que AGDCBacklightControl utiliza para determinar si soporta o no su luz de fondo.

Por eso le pedí que ejecutara el segundo conjunto de comandos. Quería comparar su board-id con la lista de conductores. Efectivamente, su documento de identidad ( Mac-C3EC7CD22292981F ) no está ahí.

Lo que esto significa para usted, por desgracia, no es una gran noticia: es es probable que su sistema nunca tenga una luz de fondo que funcione en Catalina porque el controlador de Catalina es incompatible con su hardware.

También debo señalar aquí que Apple depura rutinariamente todo su software y elimina el código del hardware al que ya no quiere dar soporte. Esta es una buena práctica por muchas razones (mayor estabilidad, menor superficie de ataque, menor tamaño del código, mayor rendimiento, menor complejidad del código/ingeniería, menor matriz de pruebas). Así pues, aunque el código del controlador de la luz de fondo es oficialmente compatible con Mountain Lion, se ha eliminado intencionadamente en Catalina.

Sus mejores opciones son (1) aceptar la limitación o (2) utilizar una versión de MacOS compatible.

Sin embargo, hay dos experimentos que puedes probar aquí:

1. Puedes intentar engañar a AGDCBacklightControl en la carga y tratar de conducir su luz de fondo. Esto es es poco probable que funcione debido a las razones que he dado anteriormente, y podría causar daños imprevistos a su hardware por las mismas razones (poco probable, pero posible). Sería fácil de probar (sólo tendría que añadir una entrada a ConfigMap en /System/Library/Extensions/AppleGraphicsControl.kext/Contents/PlugIns/AGDCBacklightControl.kext/Contents/Info.plist después de desactivar las protecciones apropiadas y luego actualizar su caché del kernel) pero no voy a detallar el procedimiento aquí. Siga esa ruta bajo su propio riesgo.
2. También puedes intentar copiar la versión de Mountain Lion del controlador a tu instalación de Catalina y esperar que al hacerlo se evite la llamada a la SPI/API incompatible. De nuevo, esto se deja como un ejercicio.