Switchres (groovymame) de Calamity ya puede usarse en KMS

Archivado
Y qué es eso del KMS os preguntáis? Bueno, voy a dar una explicación un poco larga y poco exacta, pero intentaré hacerme entender lo mejor posible.

Como ya sabéis hay 2 tipos de monitores: los CRT y los actuales (llámalos lcd, oled... como quieras). Los CRT pueden cambiar de resolución y refresco al vuelo, y escupirán lo que les diga la placa/consola que les enchufes. Los LCD también pueden cambiar de resolución pero tienen una "resolución nativa" (y refresco, pero no voy a meterme en eso), que es la que mejor muestran. Cuando le enchufamos una placa/consola lo que hace es coger la imágen y adaptarla a su resolución, mediante escalado. Normalmente lo hacen fatal y es mejor usar un escalador externo, ya sea por hardware (ossc) o por software (emuladores).

El caso es que allá por los años 80 cuando los sistemas tipo UNIX empezaron a mostrar interfaces gráficos lo hicieron mediante un sistema llamado X (hoy en día X.org) que estaba pensado para monitores CRT. Cambios de resolución, etc. X no sólo se encargaba de dibujar, también de gestionar el hardware mediante drivers.
Hoy en día la cosa ha cambiado y los drivers gráficos los gestiona el propio linux, sin necesidad de programas extra, eso es el KMS. Peeeero al ser una implementación moderna está pensada para LCDs y "resolución única". El monitor le dice al SO a qué resolución ponerse y ahí nos quedamos.

Así que ahora mismo si quieres jugar en linux tienes dos opciones: usar el sistema gráfico moderno y jugar a resolución fija o usar el sistema clásico y ajustar las resoluciones al gusto. La primera es más eficiente porque usa drivers modernos y elimina una capa de software (xorg) ofreciendo mejor rendimiento y menos input lag... pero ólvidate de resoluciones originales.

Bueno, pues ahora gracias a @Calamity15kHz esto se acabó, porque desde la versión 0.238 groovymame soporta cambios de resolución en KMS. Podemos usar el sistema moderno, quitarnos una capa de software y usar las resoluciones y refrescos nativos en nuestros CRT, con hardware actual.
http://forum.arcadecontrols.com/index.p ... msg1750741

Y para probarlo podemos descargar la última versión de groovyarcade, livecd de linux con todo ya configurado.
http://forum.arcadecontrols.com/index.p ... msg1751257
https://github.com/substring/os/releases

Siento el tochopost, pero es que esto es un cambio brutal. Yo aún no lo he probado, y supongo que tendrá cosas por pulir, pero abre una puerta al futuro que se estaba cerrando, porque xorg más pronto que tarde dejará de estar disponible en las distribuciones.

Otra de las beneficiadas es la raspberry pi, ya que según leo por aquí la última versión de RGB-PI ya funciona sin xorg, con el nuevo switchres de @Calamity15kHz
https://www.mortaca.com/rgb-pi/wiki/ind ... pberry_Pi4

A ver si este finde saco tiempo y os puedo comentar que tal.
Esto es un notición brutal y todas las distribuciones retro construidas en GNU/Linux se beneficiarán, y si además de poder usar las resoluciones al vuelo en KMS, se pudiera sacar la señal 15kHz por una salida HDMI mediante un conversor digital-analógico, veo en un futuro la Steam Deck conectada a un CRT emulando hasta la última consola que se veía bien en esos televisores. XD

Enhorabuena para todos los Linuxeros y enormes felicidades por el trabajazo de @Calamity15kHz!
@Ronbin
Habra que darle un tiento en el s720.
@1985a siempre me hablaba del kms, igual esto le interesa
Buenas.

No sólo groovymame, retroarch también se venía beneficiando de esta liberación del servidor X, llevo unos días probando con GA, precisamente en el s720, @Tomax_Payne .

Gracias por la explicación @Ronbin
Elazul está baneado por "clon de usuario baneado"
Buuuahh!! Qué gusto da leer este hilo al fin, coño!!

Yo añadí el soporte de KMS/DRM a las SDL2 hace unos años, así que si como sospecho GoovyMAME usa las SDL2 sobre KMS/DRM, todo esto corre sobre mi driver, y lo hice precisamente para esto.
La causa por la que se ha tardado tanto la desconozco, porque SDL sobre KMS/DRM funciona perfecto desde hace años, pero aquí estamos y me alegro MUCHO.

RetroArch también ha funcionado sobre KMS desde... 2013 o así. Ni idea de por qué les ha costado tanto lo de cambiar la resolución al vuelo: es leer la lista de conectores, buscar uno activo, reprogramar el CRTC con el modo de vídeo que queramos (sí, CRTC, no confundir con CRT) y a volar.
Supongo que lo que han resuelto es la generación de modos al vuelo o algo así.
Pero oye, nunca es tarde si la picha es buena.
@Elazul,

No tenía ni idea que al autor del driver KMS/DRM para SDL2 andaba por aquí, ¡qué sorpresa!

Había varios problemas que resolver, que vienen por el hecho de que Switchres necesita añadir modos de vídeo de forma dinámica.

El primero es que para hacer lo que dices sobre KMS, Switchres tiene que ser "drm master", cosa que cuando SDL2 ya lo es, no es fácil resolver (se puede).

La segunda es que SDL2, una vez iniciado, ya no refresca la lista de modos de vídeo, por lo que toca parchearlo para que lo haga.

La tercera es que el kernel no permite añadir modos de vídeo de usuario (existen unas apis pero están anuladas). Tocó reimplementarlas (parche de kernel tocho).

Una vez resuelto estó, GroovyMAME funcionó sobre KMS/DRM a la primera. Tu driver de SDL2 es increíble.

Sólo hubo que parchear otra cosilla de SDL2, para que funcionase en sistemas con más de un monitor.

El caso de RA es direrente porque maneja KMS directamente, sin SDL2. Entonces puede reprogramar el CRTC sin problemas. Aquí Switchres se usa solo como calculadora de modelines.

Aclaro también que el soporte de KMS para Switchres lo ha hecho Substring, el mérito es suyo.
Seguimos atados a las atis/amds?
Ronbin escribió:Otra de las beneficiadas es la raspberry pi, ya que según leo por aquí la última versión de RGB-PI ya funciona sin xorg, con el nuevo switchres de @Calamity15kHz
https://www.mortaca.com/rgb-pi/wiki/ind ... pberry_Pi4


Una aclaración, RGB-Pi utiliza switchres de Calamity solo en modo calculadora para generar las resoluciones pero switchres por si solo con la integración de Substring dentro de Retroarch no es capaz de cambiar de resoluciones a través del GPIO en una Pi4, solo a traves del puerto HDMI a VGA y tampoco dentro del juego, es el Dynares de RubenTomás con aportaciones de cpastuse el que logra que Retroarch cambie de resolución por el puerto GPIO y que sea capaz de cambiar dentro del juego, ninguna otra distro ha conseguido esto sin Dynares en la Pi4.
atg escribió:Una aclaración, RGB-Pi utiliza switchres de Calamity solo en modo calculadora para generar las resoluciones pero switchres por si solo con la integración de Substring dentro de Retroarch no es capaz de cambiar de resoluciones a través del GPIO en una Pi4, solo a traves del puerto HDMI a VGA y tampoco dentro del juego, es el Dynares de RubenTomás con aportaciones de cpastuse el que logra que Retroarch cambie de resolución por el puerto GPIO y que sea capaz de cambiar dentro del juego, ninguna otra distro ha conseguido esto sin Dynares en la Pi4.

Gracias por la info @atg. He esatdo viendo algún vídeo de Dynares y tiene muy buena pinta. ¿El código no es público no? Me gusta ojear estas cosas.
Enhorabuena por la nueva versión del OS, por lo que leo la gente está encantadísima [beer]
@Ronbin
Sin duda se lo han currado, aunque si no me equivoco deberían liberar el código pues RA está bajo GNU GPLv3 y creo es obligatorio hacerlo ante cualquier modificación si no es para uso particular (uso propio no redistribuido)

EDIT: por cierto, como poseedor del cable lo recomiendo totalmente dado que su sistema es el más pulido que puede haber para una rpi, siempre en mi opinión, claro está.
Tomax_Payne escribió:@Ronbin
Habra que darle un tiento en el s720.
@1985a siempre me hablaba del kms, igual esto le interesa



Hace muchos días que no utilizo ese modo.

Si recalco, que obtenía un rendimiento tremendo, al quitar del medio Xorg y el input lag, incluso usando un dispositivo Bluetooth, es imperceptible, tal como te mostré en el video.

Me alegra ver proyectos como este, que tratan de impulsar esta versión de jugar, ya que se obtiene muchos beneficios, a la hora de rendimiento e input lag.
paskhis escribió:@Ronbin
Sin duda se lo han currado, aunque si no me equivoco deberían liberar el código pues RA está bajo GNU GPLv3 y creo es obligatorio hacerlo ante cualquier modificación si no es para uso particular (uso propio no redistribuido)


El código está aquí: https://github.com/rtomasa/RetroArch
@Calamity15kHz gracias por el enlace

He leído por encima el readme y pone esto
Dynares
This feature will enable dynamic native resolution detection and switch in real time. This feature has been tested only with Raspberry Pi4 using KMS/DRM and DPI interface.

Please do note that you need to load every single kms video mode before using this feature. As of now, only RGB-Pi OS includes such DB out of the box.

Así que ahora mismo sólo funcionará en la rpi, pero no creo que sea difícil añadir esos modos en cualquier distro linux.

También veo que las opciones de vídeo son estas
crt_switch_resolution = 1 // 0=off, 1=arcade_15, 2=arcade_31, 3=pc_31_120, 4=switchres.ini

Estaría bien poder añadir el modo doublescan para monitores de 31khz. Así
Resolución original de R-type: 384x256 55 Hz
Si usamos la opción "pc_31_120": 384x256 110 Hz
Si usáramos doublescan: 384x512 55 Hz

Yo la mister (y groovymame) la tengo configurada de la última forma y me encanta como se ve.
Ronbin escribió:Así que ahora mismo sólo funcionará en la rpi, pero no creo que sea difícil añadir esos modos en cualquier distro linux.


Para PC tienes la versión de RA de Substring que funciona con los últimos parches de "15 kHz":
https://github.com/substring/packages/b ... hing.patch

No necesitas ninguna base de datos, los modos los va añadiendo SR de forma dinámica según los requiere el emulador.

Estaría bien poder añadir el modo doublescan para monitores de 31khz.


La opción arcade_31 hace exactamente eso.
@Calamity15kHz gracias por la info. Sois unos cracks, de verdad.
¿Sabéis si el patch the Substring llegará a RetroArch o si podemos encontrar ya una build que lo incluya? He ido a poner una nueva issue en el github the RA y veo que solo tienen plantilla para bugs así que no he seguido por ahí
run000 escribió:¿Sabéis si el patch the Substring llegará a RetroArch o si podemos encontrar ya una build que lo incluya? He ido a poner una nueva issue en el github the RA y veo que solo tienen plantilla para bugs así que no he seguido por ahí

La respuesta la tienes en GroovyArcade.
Me gustaría no tener que utilizar un sistema distinto al que tengo
run000 escribió:Me gustaría no tener que utilizar un sistema distinto al que tengo

GroovyArcade es de lo mejor.
Para hacer funcionar switchres y kms tienes que parchear el sdl2 del SO además del propio RA.
Ya estoy probandolo y muy contento por ahora. Venía ya de un archlinux, así que me está siendo fácil migrar toda la personalización que tenía montada
19 respuestas
Archivado
Volver a Arcade y emulación