Ejecutando aplicaciones x86/x86-64 en Fedora Asahi Remix

Entonces puede utilizar `romdev-extract` para extraer el contenido del RPM, y entonces configure `LD_LIBRARY_PATH` como sea apropiado.

También es posible sobrecargar los RPM en el existente RootFS, a través de esto estaría considerada funcionalidad avanzada. Una vez que tenga un RPM, puede convertirlo a una imagen erofs utilizando estos comandos:

``` rpm2archive -n mipaquete.rpm mkfs.erofs --tar=f mipaquete.rpm.erofs mipaquete.rpm.tar ```

Entonces, puede lanzar manualmente `muvm` con las imágenes base erois y su imagen personal erofs encima, como esto:

Esto cubrirá el paquete adjunto en el RootFS utilizado para FEX. Conserve en mente que esto puede o no funcionar como intentaba, y no sería considerado una solución mantenida.

=== Steam dice que stamwebhelper se ha estrellado, ¿qué hago?

Tan solo deje reiniciar, y funcionaría en el segundo intente. Steam tiene un tiempo de espera para steamwebhelper, y cuando ejecute bajo emulación, inicio es lento suficiente que el tiempo de espera caduca. Esto usualmente solo sucede en un arranque frío.

=== No soy capaz de descargar/ejecutar ciertos juegos en Steam

Asegure que Steam Play está activado para todos los juegos. Estaría bajo Menú > Opciones > Compatibilidad > Activar Steam Play para todos los otros títulos. Reinicie Steam una vez activado.

=== Presionando teclas hace que el touchpad detenga la respuesta

Esto es causado por la característica del touchpad "Desactivar cuando tecleo". Puede apagarlo en las opciones touchpad/input para su entorno de escritorio.

=== ¿Puedo ejecutar aplicaciones Windows® fuera de Steam?

En este punto, no mantenemos ejecutar apps Windows® fuera de Steam como Wine no proton aún no funciona en Fedora. Estamos trabajando en resolver subyacentes https://github.com/FEX-Emu/FEX/pull/4225[problema FEX], por tanto esperamos mantener esto relativamente pronto.

En el tiempo medio, puede utilizar Proton Steam para ejecutar aplicaciones de Windows® no Steam directamente desde Steam.

=== ¿Puedo ejecutar aplicaciones x86-64/x86 de Linux?

Los juegos Native Linux generalmente funcionarían bajo muvm, tan largo como sean auto-contenidos y no hace dependencia en bibliotecas de sistema host compleja (llevaría una selección grande de dependencias comunes, pero no todo bajo el sol).

=== ¿Está admitido Wayland?

Wayland no está mantenido dentro de la MV en este momento. Como muchas de las aplicaciones heredadas de x86/x86-64 la gente desea ejecutar son aplicaciones X11, estamos enfocando primero en soporte de X11. Esto significa que no puede ejecutar apps nativas Wayland dentro de la MV en este momento. Por supuesto, el escritorio host aún es un escritorio Wayland, y el soporte X11 está proporcionado por XWayland.

=== ¿Puedo acceder al hardware desde aplicaciones ejecutando dentro de la microMV?

Como la MV no aprueba a través de cualquier hardware host distinto que el GPU y el sistema de archivo virtual, no será capaz de utilizar aplicaciones que requieren acceso por hardware directo. Utilizamos pase por software para los siguientes interfaces:

- Protocolo X11 (pantalla, teclado, ratón)
- Gamepads traspaso vía traspaso hid/uinput
- E/S de sonido por medio de protocolo de zócalo PulseAudio footnote:[Esto funciona con PipeWire ejecutando en el host con pipewire-pulse, como instalado por defecto. *No* necesita y no instalaría el propio PulseAudio, ya que romperá su soporte al amplificador!]

Estamos investigando la posibilidad de traspasar por medio de PipeWire, lo cual permitirá cámaras web que sean usadas dentro de la MV.

=== ¿Puedo utilizar métodos de entrada (IME) en aplicaciones con el microMV?

Puede usar el sistema clásico de métodos de entrada _xim_ de X11. muvm ya debería configurar las variables de entorno correctamente para que funcione con aplicaciones Qt y GTK (cargando el complemento "xim"), siempre que el marco de métodos de entrada que utilice en su sistema host lo admita. Hemos probado esto con _fcitx5_ y Steam ejecutándose en KDE Plasma.

En el futuro, una vez que se admita el paso a través de Wayland, el mecanismo de protocolo de entrada nativo de Wayland debería funcionar con cualquier marco de método de entrada de host (a través de un complemento generalmente llamado "wayland"). No hay planes para soportar métodos de entrada que no estén basados en sistemas de ventanas (como los complementos directos "ibus" y "fcitx"), ya que requerirían que enviemos bibliotecas compartidas x86-64 para todos los métodos de entrada posibles en el sistema virtual x86-64 inmutable, y también requerirían la representación de sus protocolos personalizados, lo cual no es factible.

=== ¿Es esto como una MV Qemu/libvirt/UTM/Parallels/VMWare/VirtualBox/etc.?

No, muvm no funciona como una máquina virtual tradicional de todo el sistema. Si bien también utiliza KVM como back-end para una virtualización eficiente, el concepto es muy diferente al de las máquinas virtuales tradicionales que ejecutan sistemas operativos invitados completamente separados. El kernel invitado es un https://github.com/containers/libkrunfw[kernel especial] optimizado para iniciarse en una fracción de segundo, y el monitor de VM pasa por el sistema de archivos del host prácticamente tal como está. No existe una conexión directa de hardware de bajo nivel (USB, etc.), sino que nos centramos en la conexión directa de protocolos de software de alto nivel, como X11/Wayland. Esto significa que el entorno dentro de la máquina virtual debería "sentirse" igual que el sistema operativo host desde el punto de vista de las aplicaciones, solo que con un tamaño de página de 4K en lugar de un tamaño de página de 16K.

=== ¿Haz que los exploradores funcionen con el invitado MV?

Sí, pero ejecutará en modo X11. Sin embargo, hay uno ausencia: *las instancias del explorador dentro del invitado no puede comunicarse con instancias de explorador fuera del invitado, y es peligroso ejecutar el mismo perfil de explorador en ambos el invitado y el anfitrión*.

Para evitar estos problemas, muvm configura una variable de entorno para forzar Firefox para utilizar un perfil dedicado cuando lanzó con la MV. Esto significa que las aplicaciones que lanzan un explorador (tal como para acceder o propósitos de documentación) funcionará como se intenta, pero Firefox lanzará utilizando un perfil dedicado son acceso a sus galletas, historial, etc.

CAUTION: Si inicia el mismo perfil de navegador en el invitado y el host simultáneamente, los datos de su perfil podrían corromperse. Si su navegador predeterminado no es Firefox y utiliza aplicaciones emuladas que podrían iniciarlo accidentalmente, le recomendamos encarecidamente cerrar todas las ventanas del navegador antes de usar muvm o configurar manualmente perfiles separados.

=== ¿Puedo hacer sudo dentro de la MV?

Dado que el monitor de la máquina virtual se ejecuta con su propia identidad de usuario, no puede obtener privilegios de root. "root" dentro de la máquina virtual solo tiene los privilegios de su propio usuario, por lo que usar sudo no tiene mucho sentido (y de hecho no funciona). Recomendamos instalar el software que desee usar con muvm+FEX en su directorio personal. Para el software diseñado para instalarse en /opt o similar, recomendamos realizar los pasos de instalación manualmente en el sistema operativo host y luego ejecutar la aplicación en muvm.

Si necesita acceder a un shell raíz dentro de la máquina virtual para depurar, puede ejecutar `muvm -tip 3335 +++--+++ bash`. Tenga en cuenta que, a pesar de ser "root", no podrá modificar la mayoría de los archivos del sistema que le pertenecen, y cualquier archivo que cree pertenecerá a su usuario no root. Un shell raíz es principalmente útil para realizar acciones como rastrear otros procesos o cambiar la configuración del kernel del invitado o de la red (pero estos cambios no persistirán tras reiniciar la MV)).

=== ¿Pueden las aplicaciones con la MV comunicarse con aplicaciones fuera de la MV?

La comunicación está limitada mayormente al sistema de archivos del host. La MV comparte su directorio inicial (y de hecho muchos de los sistemas de archivos) con el host, tal que cualquier archivo que cree en un lado será visible en el otro.

Gracias a virtiofs-DAX, la comunicación de memoria compartida (`/dev/shm`) también está disponible entre apps invitadas y apps hospedadas. Esto es utilizado, por ejemplo, por el código de reenvío (forwarding) de X11.

Además es posible compartir sonido entre app hospedajes (host) e invitados (guest) utilizando el soporte de re-envío PulseAudio. Por ejemplo, puede registrar sonido de invitado utilizando una apps de grabación en el hospedado (host) y grabando desde el sistema dispositivo «Monitor». Además puede configurar vaciados/fuentes virtuales en el hospedado (host) utilizando los mecanismos usuales de PipeWire, y apps invitadas directas para utilizar aquellos para E/S de sonido para tener enrutado y preprocesamiento de sonido personalizado. Note que el protocolo PipeWire nativo no está atravesado, solo el protocolo PulseAudio el cual es más limitado (pero más comúnmente utilizado por aplicaciones). Las aplicaciones ALSA están mantenidas por medio del plug-in `pulse`.

Si está utilizando un compositor host que admite el puente de video XWayland (tal como KDE Plasma / KWin), podrás compartir/capturar pantalla desde la MV, incluidas pantallas completas del host y ventanas de Wayland. Asegúrate de que la aplicación que estás ejecutando sea compatible con la captura de pantalla/ventana XComposite clásica. Al compartir la pantalla, podrás seleccionar directamente las ventanas de la aplicación X11 o elegir la ventana virtual «Xwayland Video Bridge». Cuando lo haga, KDE le solicitará automáticamente la ventana o pantalla que desea compartir.

=== ¿Por qué tengo menos cores de CPU dentro de la MV?

Por defecto, `muvm` aprueba a través de muchas CPU como ha realizadas cores en su máquina hospedada, y pines aquellos vCPU para el rendimiendo físico de cores. Desde el planificador de CPU host no tiene visibilidad en la planificación de CPU invitada, esto mejora que el rendimiento es consistente. Puede moficiar este comportamiento con la opción `muvm --cpu-list=CPU_LIST`.

=== ¿Como utilizo una unidad externa como una carpeta de biblioteca Steam?

Siga estos pasos para obtener una unidad externa configurada para Steam:

. Formatea sus unidades externas utilizando un sistema de archivos nativo de Linux como ext4.
+
NOTE: FAT32, exFAT, y otros sistemas de archivos sin soporte para permisos de Linux no funcionarán.

. Monte sus unidades manualmente bajo un directorio accesible a muvm, tales como `/mnt/steam`.
+
NOTE: Recomendamos montar la unidad manualmente (p.ej. `sudo mount /dev/sdX1 /mnt/steam`, donde `sdX1` es su archivo de dispositivo de unidad). So configura la unidad para montar automáticamente usando `/etc/fstab`, entonces su sistema no arrancará si esa unidad no está conectada.
+
NOTE: El punto de montaje para unidades montadas por medio del entorno de escritorio (udisks) no funcionarán en este momento.

. Asegure que el sistema de archivos raíz es accesible a su usuario usual:
+
`sudo chown $\{USER}: /mnt/steam`

. Cree una carpeta vacía nombrada `steamapps` en la raíz del montaje:
+
`mkdir /mnt/steam/steamapps`

. Arrancar Steam normalmente

. Pulse en la lengüeta Biblioteca, después pulse el icono (parámetros) del engranage

. Seleccione *Storage* en el menú izquierdo, pulse sobre la caja combo en la cima del panel, y seleccione *Añadir Unidad*.

. Explore su unidad montada (`/mnt/steam`), tal como esa la carpeta solo visible en el listado selector de archivo para ventana es la carpeta vacía `steamapps`, después (sin hacer ninguna más selecciones) pulse sobre el botón *Seleccionar*.

Ahora sería capaz de seleccionar el lugar de la descarga nueva, haciéndola la predeterminada, y descarga juegos en ella.