Qué es

Escritorio remoto

Tipo de sesión «escritorio». Ves la pantalla del destino y la controlas. En la app de escritorio, o con un ratón conectado al móvil, apuntas directamente sobre la imagen. Con el dedo usas los gestos del mouse pad, con el cursor del destino dibujado sobre la imagen y un zoom de 1x a 3x que lo sigue.

Mouse pad

Tipo de sesión «mouse pad». El móvil hace de touchpad y de teclado del destino mientras miras su pantalla.

Gestos

Un dedo mueve el cursor y tocar hace clic. Dos dedos hacen scroll y tocar con dos es clic derecho. Mantener pulsado arrastra.

Cómo funciona

Los dos usan titan-agent, el agente que la app instala sola en tu cuenta de usuario del destino, sin permisos de administrador ni root. Todo va dentro de la conexión SSH. La pantalla viaja en trozos, y solo se envían los que cambian: el texto y las ventanas llegan exactos y lo fotográfico se comprime.

Para empezar

1. Crea una sesión, elige el host y, en Tipo, marca «escritorio» o «mouse pad».
2. Conéctate con el mismo usuario que tiene la sesión iniciada en el escritorio del destino.
3. Mira en Requisitos si tu sistema necesita algo más: en Windows, el ayudante de escritorio; en KDE y GNOME, aceptar el permiso la primera vez.

Calidad de imagen

Es un ajuste de la sesión de escritorio. Automática (la de serie): el texto llega exacto y las fotos y el vídeo se comprimen según lo rápida que sea la conexión. Sin pérdida: todo exacto, gasta más datos con fotos y vídeo. Baja: más comprimido, para conexiones lentas, y el texto sigue exacto.

Si se corta la red

La pestaña se queda con la última imagen, atenuada, y reconecta sola. Al volver llega la pantalla entera. Mientras tanto no se envía ni ratón ni teclado, y el agente suelta los botones y las teclas que estuvieran pulsados. El escritorio del destino no se entera del corte.

Sistemas

• El mouse pad funciona en los mismos sistemas.
• Versiones. Windows 10 1809 es el mínimo del agente. En Linux no hay un mínimo fijado: la tabla dice con qué versiones se ha probado.
• Wayland en KDE y GNOME necesita PipeWire y xdg-desktop-portal con el backend del escritorio, que vienen con los dos.
• Otros compositores wlroots (labwc, river…) funcionan si ofrecen ext-image-copy-capture-v1 o wlr-screencopy. Para controlar la pantalla, además, wlr-virtual-pointer y virtual-keyboard; sin ellos solo se ve.
• En Linux, una sesión con X11 y otra con Wayland del mismo escritorio se tratan por separado. Si tu escritorio Wayland no está en la tabla, entrar con su sesión X11 es una salida.

Requisitos

En todos los sistemas

• Una sesión iniciada en el escritorio del destino, con el mismo usuario que la conexión SSH. Vale una sesión local o una de escritorio remoto (RDP en Windows, xrdp en Linux); si hay de las dos, se usa la que está en la pantalla del PC. La pantalla de inicio de sesión no cuenta.
• Tu sesión tiene que estar en pantalla. Si otro usuario tiene el escritorio (cambio rápido de usuario), o en Windows tu escritorio remoto se cerró sin cerrar la sesión, no hay imagen.
• El agente. La primera vez, la app lo descarga del GitHub Release de su versión y lo copia al destino, así que el dispositivo necesita Internet. La canary usa su propio agente, aparte del de la estable.

Windows: el ayudante de escritorio

El servidor SSH de Windows arranca los programas fuera de tu escritorio, desde donde no se ve ni se controla tu pantalla. Para llegar a él, el agente registra una tarea programada de tu usuario, que solo se ejecuta mientras tienes la sesión iniciada, y la lanza. Esa tarea arranca el ayudante de escritorio, una copia del agente dentro de tu sesión.

• No necesita permisos de administrador. Vale cualquier edición, también Home.
• La primera conexión tarda unos segundos, mientras arranca el ayudante.
• Cerrar la pestaña no lo para: sigue hasta que cierras la sesión de Windows o lo quitas.
• Lo ves en el Programador de tareas y en el panel del agente (Ver el agente del destino), en la fila «Ayudante de escritorio». Con «Quitar» se borran el ayudante y su tarea, y el siguiente uso los vuelve a instalar.

KDE y GNOME con Wayland: el permiso del escritorio

En Wayland ningún programa puede ver la pantalla sin permiso. La primera vez que te conectas, el escritorio del destino enseña un diálogo para compartir la pantalla, y alguien delante del PC tiene que aceptarlo. El escritorio recuerda la respuesta y las siguientes conexiones ya no preguntan.

• Si nadie responde en unos 90 segundos, o se rechaza, la app da E_SCREEN_CONSENT.
• En GNOME, activa en el diálogo «Permitir interacción remota», que viene apagada. Sin ella el escritorio remoto solo se ve, sin ratón ni teclado, y el mouse pad no arranca.
• El panel del agente enseña el permiso en la fila «Escritorio remoto»: «preguntará en la pantalla del destino» o «permiso recordado». Con «Olvidar el permiso» se cierran los escritorios remotos abiertos en ese destino y el siguiente vuelve a preguntar.

Sin nadie delante

Para conectarte a un PC con KDE o GNOME en Wayland cuando no hay nadie delante, autoriza antes al agente. Hay dos formas:

• Marca «Permitir sin nadie delante» en la sesión de escritorio. El agente se autoriza al conectar.
• O, en el panel del agente, despliega la fila «Escritorio remoto» y pulsa «Permitir sin nadie delante». Pide confirmación.

En KDE, el agente se apunta en los permisos de escritorio remoto del propio KDE. En GNOME usa la interfaz propia del escritorio, que no pregunta. En los demás sistemas el ajuste no cambia nada.

Nunca se activa solo, y se quita en el panel con «Volver a preguntar» o «Olvidar el permiso». Mientras esté activado, quien entre por SSH con tu usuario puede ver y controlar la pantalla sin que nadie lo acepte delante del PC. Actívalo solo en equipos tuyos.

X11 y wlroots

No hay nada que preparar ni ningún diálogo. El agente usa tu propia sesión: en X11, tu cookie de XAUTHORITY o de ~/.Xauthority; en wlroots, los protocolos del compositor.

Límites

Windows bloqueado y UAC

La pantalla de bloqueo, la petición de contraseña, los avisos del UAC y Ctrl+Alt+Supr van en un escritorio seguro que ningún programa de tu sesión puede ver ni controlar. Mientras están en pantalla, la pestaña dice «Escritorio bloqueado», atenúa la última imagen y sigue sola cuando desaparecen. Para desbloquear el PC o aceptar un UAC hay que estar delante.

Bloqueo en Linux

En X11 y Wayland la pantalla de bloqueo se ve y se controla como cualquier otra, si el compositor lo permite.

Varios monitores

Se ve el escritorio entero, con los monitores colocados como en el destino. Todavía no se puede elegir uno solo; en el móvil, el zoom ayuda.

HiDPI y escalas

La imagen llega con los píxeles reales de cada monitor, también si tienen escalas distintas, y el puntero cae donde apuntas.

Cambios de pantalla

Cambiar la resolución o la escala, o conectar o quitar un monitor, se refleja solo en la pestaña.

Acentos en KDE y GNOME con Wayland

Ahí solo se pueden teclear los caracteres que la distribución de teclado del destino tiene sin tecla muerta ni AltGr. Con la distribución española llega la ñ, pero no á, é, ü ni €. En Windows, X11 y wlroots llega todo. Se está trabajando en ello.

Hyprland

Debería funcionar por la vía wlroots, pero no se ha probado: necesita una GPU que el entorno de pruebas no tiene.

Vídeo y juegos

Se ven, pero gastan más datos que el uso normal y, con una conexión lenta, van a saltos: llegan menos fotogramas, pero siempre recientes. Está pensado para trabajar con ventanas y texto.

Sonido y portapapeles

No se transmiten.

App anterior a la 1.5.0

Las versiones estables anteriores a la 1.5.0 no ofrecen el tipo «escritorio»: enseñan esas sesiones pero no las abren. Actualiza la app.

Errores

Cuando no se puede abrir, la pestaña dice «El escritorio remoto no está disponible:» (o «El mouse pad no está disponible:»), el motivo, qué hacer y, al final, entre paréntesis, un código. A veces añade un Detalle que nombra el escritorio o el fallo concreto.

E_NO_DESKTOP

«no hay nadie con la sesión iniciada en el escritorio del destino»

Por qué: nadie ha iniciado sesión en ese PC con tu usuario, o solo está la pantalla de inicio de sesión.

Qué hacer: inicia sesión en el escritorio del PC, también vale por escritorio remoto, con el mismo usuario de la conexión SSH, y reconecta.

E_DESKTOP_INACTIVE

«tu sesión en el destino no está en la pantalla»

Por qué: otro usuario tiene el escritorio (cambio rápido de usuario) o, en Windows, tu sesión está desconectada: un escritorio remoto cerrado sin cerrar la sesión.

Qué hacer: vuelve a tu sesión en ese PC y reconecta.

E_SCREEN_UNSUPPORTED

«el escritorio del destino todavía no admite el escritorio remoto»

Por qué: el sistema no tiene ninguna vía: macOS, FreeBSD, o un Wayland sin portal de escritorio remoto ni protocolos wlroots. El detalle dice qué escritorio encontró el agente.

Qué hacer: mira la tabla de sistemas. Si tu escritorio tiene también una sesión X11, entra con ella.

E_INPUT_UNSUPPORTED

«el destino todavía no admite el mouse pad»

Por qué: lo mismo para el mouse pad, o un destino Linux Wayland con una app anterior a la 1.5.0.

Qué hacer: mira la tabla de sistemas y, si tu app es anterior a la 1.5.0, actualízala.

E_SCREEN_CONSENT

«no se aceptó en el destino el permiso para compartir la pantalla»

Por qué: en KDE o GNOME, el diálogo del escritorio se rechazó o nadie lo aceptó en unos 90 segundos. En GNOME, también un mouse pad sin «Permitir interacción remota».

Qué hacer: que alguien delante del PC lo acepte (en GNOME, con la interacción remota activada) o, si es tu equipo, activa «Permitir sin nadie delante».

E_SCREEN_CAPTURE

«el destino no pudo capturar la pantalla»

Por qué: la vía existe, pero falló: PipeWire, el portal o la captura de Windows. El detalle dice qué pasó.

Qué hacer: reconecta. Si se repite, abre una incidencia en GitHub con el detalle, el sistema y el escritorio del destino.

E_DESKTOP_TASK

«no se pudo preparar la tarea programada que lanza el ayudante de escritorio»

Por qué: solo en Windows. Windows no dejó registrar o lanzar la tarea del ayudante de escritorio; el detalle dice por qué.

Qué hacer: revisa el detalle. La tarea se puede quitar desde el panel del agente y el siguiente uso la vuelve a crear.

E_PROTOCOL

«el agente envió una imagen que esta versión de la app no entiende»

Por qué: la app y el agente del destino no se entienden, normalmente porque la app está desactualizada.

Qué hacer: actualiza la app; si ya está al día, revisa el detalle.

«Escritorio bloqueado»

No es un error. En Windows, el PC está bloqueado o enseña un aviso del UAC. La pestaña sigue sola al desbloquearlo; mira Límites.

Otros códigos

Los fallos al instalar o arrancar el agente (E_NO_BINARY, E_UPLOAD, E_NOEXEC…) son los mismos que en el terminal, y su mensaje dice qué hacer.

What it is

Remote desktop

Session type «escritorio». You see the destination's screen and control it. In the desktop app, or with a mouse plugged into the phone, you point straight at the image. With a finger you use the mouse pad gestures, with the destination's cursor drawn over the image and a 1x to 3x zoom that follows it.

Mouse pad

Session type «mouse pad». The phone works as the destination's touchpad and keyboard while you look at its screen.

Gestures

One finger moves the cursor and a tap clicks. Two fingers scroll and a two-finger tap is a right click. Press and hold to drag.

How it works

Both use titan-agent, the agent the app installs by itself in your user account on the destination, without administrator or root rights. Everything travels inside the SSH connection. The screen is sent in tiles, and only the ones that change: text and windows arrive exact and photographic areas are compressed.

Getting started

1. Create a session, pick the host and set Tipo (type) to «escritorio» or «mouse pad».
2. Connect with the same user that is signed in to the destination's desktop.
3. Check Requirements in case your system needs something else: on Windows, the desktop helper; on KDE and GNOME, accepting the permission the first time.

Image quality

A setting of the remote desktop session. «automática» (automatic, the default): text arrives exact, and photos and video are compressed according to how fast the connection is. «sin pérdida» (lossless): everything exact, uses more data with photos and video. «baja» (low): more compressed, for slow connections; text stays exact.

If the network drops

The tab keeps the last image, dimmed, and reconnects by itself. When it is back, the whole screen arrives again. Meanwhile no mouse or keyboard input is sent, and the agent releases any buttons and keys that were held down. The destination's desktop never notices the drop.

Systems

• The mouse pad works on the same systems.
• Versions. Windows 10 1809 is the agent's minimum. On Linux there is no fixed minimum: the table says which versions it was tested with.
• Wayland on KDE and GNOME needs PipeWire and xdg-desktop-portal with the desktop's backend, which both ship.
• Other wlroots compositors (labwc, river…) work if they offer ext-image-copy-capture-v1 or wlr-screencopy. To control the screen they also need wlr-virtual-pointer and virtual-keyboard; without them you can only watch.
• On Linux, an X11 session and a Wayland session of the same desktop are handled separately. If your Wayland desktop is not in the table, signing in to its X11 session is a way out.

Requirements

On every system

• A session signed in to the destination's desktop, with the same user as the SSH connection. A local session or a remote desktop one (RDP on Windows, xrdp on Linux) both work; if there are both, the one on the computer's screen is used. The login screen doesn't count.
• Your session has to be on screen. If another user has the desktop (fast user switching), or on Windows your remote desktop was closed without signing out, there is no image.
• The agent. The first time, the app downloads it from the GitHub Release of its version and copies it to the destination, so the device needs Internet access. The canary uses its own agent, separate from the stable one.

Windows: the desktop helper

The Windows SSH server starts programs outside your desktop, where your screen can't be seen or controlled. To reach it, the agent registers a scheduled task of your user that only runs while you are signed in, and starts it. The task starts the desktop helper, a copy of the agent inside your session.

• No administrator rights needed. Any edition works, Home included.
• The first connection takes a few seconds while the helper starts.
• Closing the tab doesn't stop it: it keeps running until you sign out of Windows or remove it.
• You can see it in Task Scheduler and in the agent panel (Ver el agente del destino), in the «Ayudante de escritorio» row. «Quitar» (remove) deletes the helper and its task, and the next use installs them again.

KDE and GNOME on Wayland: the desktop's permission

On Wayland no program can see the screen without permission. The first time you connect, the destination's desktop shows a dialog to share the screen, and someone at the computer has to accept it. The desktop remembers the answer and later connections don't ask again.

• If nobody answers within about 90 seconds, or it is refused, the app reports E_SCREEN_CONSENT.
• On GNOME, turn on «Allow Remote Interaction» in the dialog; it is off by default. Without it the remote desktop can only be watched, with no mouse or keyboard, and the mouse pad doesn't start.
• The agent panel shows the permission in the «Escritorio remoto» row: «preguntará en la pantalla del destino» (will ask on the destination's screen) or «permiso recordado» (permission remembered). «Olvidar el permiso» (forget the permission) closes the remote desktops open on that destination, and the next one asks again.

Nobody at the computer

To connect to a KDE or GNOME computer on Wayland with nobody in front of it, authorise the agent beforehand, in one of two ways:

• Tick «Permitir sin nadie delante» (allow with nobody present) in the remote desktop session. The agent authorises itself when it connects.
• Or, in the agent panel, unfold the «Escritorio remoto» row and press «Permitir sin nadie delante». It asks for confirmation.

On KDE, the agent adds itself to KDE's own remote desktop permissions. On GNOME it uses the desktop's own interface, which doesn't ask. On other systems the setting changes nothing.

It never turns on by itself, and you turn it off in the panel with «Volver a preguntar» (ask again) or «Olvidar el permiso». While it is on, anyone who signs in over SSH as your user can see and control the screen without anyone at the computer accepting it. Only turn it on for your own machines.

X11 and wlroots

There is nothing to prepare and no dialog. The agent uses your own session: on X11, your cookie from XAUTHORITY or ~/.Xauthority; on wlroots, the compositor's protocols.

Limits

Windows locked and UAC

The lock screen, the password prompt, UAC prompts and Ctrl+Alt+Del live on a secure desktop that no program in your session can see or control. While they are on screen, the tab says «Escritorio bloqueado» (desktop locked), dims the last image and carries on by itself when they go away. To unlock the computer or accept a UAC prompt you have to be in front of it.

Locking on Linux

On X11 and Wayland the lock screen can be seen and controlled like any other screen, if the compositor allows it.

Several monitors

You see the whole desktop, with the monitors placed as on the destination. Choosing a single one isn't possible yet; on a phone, the zoom helps.

HiDPI and scaling

The image arrives with each monitor's real pixels, even with different scales, and the pointer lands where you point.

Screen changes

Changing the resolution or the scale, or plugging or removing a monitor, shows up in the tab by itself.

Accents on KDE and GNOME on Wayland

There you can only type the characters that the destination's keyboard layout has without a dead key or AltGr. With the Spanish layout ñ arrives, but á, é, ü and € don't. On Windows, X11 and wlroots everything arrives. Work in progress.

Hyprland

It should work through the wlroots path, but it hasn't been tested: it needs a GPU that the test environment doesn't have.

Video and games

They show, but use more data than normal use and, on a slow connection, they stutter: fewer frames arrive, but always recent ones. It is meant for working with windows and text.

Sound and clipboard

Not transferred.

App older than 1.5.0

Stable versions before 1.5.0 don't offer the «escritorio» type: they list those sessions but don't open them. Update the app.

Errors

When it can't open, the tab says «El escritorio remoto no está disponible:» (or «El mouse pad no está disponible:»), the reason, what to do and, at the end in brackets, a code. Sometimes it adds a Detalle (detail) that names the desktop or the exact failure.

E_NO_DESKTOP

«no hay nadie con la sesión iniciada en el escritorio del destino» — nobody is signed in to the destination's desktop.

Why: nobody has signed in to that computer as your user, or only the login screen is there.

What to do: sign in to the computer's desktop (a remote desktop session works too) with the same user as the SSH connection, and reconnect.

E_DESKTOP_INACTIVE

«tu sesión en el destino no está en la pantalla» — your session isn't on the destination's screen.

Why: another user has the desktop (fast user switching) or, on Windows, your session is disconnected: a remote desktop closed without signing out.

What to do: go back to your session on that computer and reconnect.

E_SCREEN_UNSUPPORTED

«el escritorio del destino todavía no admite el escritorio remoto» — the destination's desktop doesn't support the remote desktop yet.

Why: the system has no way to do it: macOS, FreeBSD, or a Wayland desktop with neither a remote desktop portal nor the wlroots protocols. The detail names the desktop the agent found.

What to do: check the systems table. If your desktop also has an X11 session, sign in to that one.

E_INPUT_UNSUPPORTED

«el destino todavía no admite el mouse pad» — the destination doesn't support the mouse pad yet.

Why: the same for the mouse pad, or a Linux Wayland destination with an app older than 1.5.0.

What to do: check the systems table and, if your app is older than 1.5.0, update it.

E_SCREEN_CONSENT

«no se aceptó en el destino el permiso para compartir la pantalla» — the permission to share the screen wasn't accepted on the destination.

Why: on KDE or GNOME, the desktop's dialog was refused or nobody accepted it within about 90 seconds. On GNOME, also a mouse pad without «Allow Remote Interaction».

What to do: have someone at the computer accept it (on GNOME, with remote interaction on) or, if it is your machine, turn on «Permitir sin nadie delante».

E_SCREEN_CAPTURE

«el destino no pudo capturar la pantalla» — the destination couldn't capture the screen.

Why: there is a way, but it failed: PipeWire, the portal or the Windows capture. The detail says what happened.

What to do: reconnect. If it happens again, open an issue on GitHub with the detail and the destination's system and desktop.

E_DESKTOP_TASK

«no se pudo preparar la tarea programada que lanza el ayudante de escritorio» — the scheduled task that starts the desktop helper couldn't be set up.

Why: Windows only. Windows didn't let the agent register or start the desktop helper's task; the detail says why.

What to do: check the detail. The task can be removed from the agent panel, and the next use creates it again.

E_PROTOCOL

«el agente envió una imagen que esta versión de la app no entiende» — the agent sent an image this version of the app doesn't understand.

Why: the app and the destination's agent don't match, usually because the app is out of date.

What to do: update the app; if it is up to date, check the detail.

«Escritorio bloqueado»

Not an error. On Windows, the computer is locked or shows a UAC prompt. The tab carries on by itself once it is unlocked; see Limits.

Other codes

Failures installing or starting the agent (E_NO_BINARY, E_UPLOAD, E_NOEXEC…) are the same as in the terminal, and their message says what to do.