Arreglar los menús contextuales de DaVinci Resolve en Hyprland

En mi equipo, los menús contextuales y ventanas de diálogo de DaVinci Resolve no respondían al clic del ratón. Al hacer clic derecho sobre un clip, o al abrir Normalize Audio o Render, el menú aparecía pero ningún clic seleccionaba nada. Lo curioso: con las flechas ↑/↓ del teclado sí funcionaba.

No era un ratón roto ni un fallo de Resolve en sí, sino un problema conocido entre DaVinci Resolve (cliente XWayland/Qt) y Hyprland.

El síntoma

Aquí las flechas sí funcionan porque Xwayland mantiene un grab de teclado, pero no de puntero.

La causa

Los menús y diálogos de Resolve son ventanas flotantes transitorias. Al abrirse, pierden el foco, y si la ventana no tiene el foco, Hyprland no le entrega los eventos del ratón. Por eso el teclado responde (va al grab de X) pero el puntero no.

La solución: forzar el foco con stayfocused

Hyprland permite aplicar reglas de ventana por clase o etiqueta. La solución de la comunidad (foros de Blackmagic, Omarchy) es:

1. Etiquetar las ventanas flotantes de Resolve.
2. Aplicarles stayfocused, que fuerza el foco mientras la ventana esté visible.

Config en formato Lua (hyprland.lua)

Mi configuración usa el formato Lua nativo de Hyprland (0.55+), donde las reglas se declaran con hl.window_rule({ ... }). Añadí esto:

-- DaVinci Resolve (XWayland): sus menús contextuales y diálogos flotantes
-- pierden el foco al abrirse, por lo que el clic del ratón no los registra
-- (solo responden las flechas arriba/abajo). Se etiquetan y se fuerza el
-- foco con "stayfocused" para que el puntero vuelva a funcionar.
hl.window_rule({
    name  = "resolve-popup-tag",
    match = { class = "^(resolve)$", float = true },
    tag   = "+drpopup",
})

hl.window_rule({
    name         = "resolve-popup-focus",
    match        = { tag = "drpopup" },
    stay_focused = true,
    border_size  = 0,
    no_shadow    = true,
    rounding     = 0,
    opaque       = true,
})

• La primera regla etiqueta (+drpopup) toda ventana flotante cuya clase sea resolve.
• La segunda coincide con esa etiqueta y le fuerza el foco (stay_focused). Las opciones de borde/sombra/redondeo son cosméticas: los popups de Resolve a veces aparecían con bordes borrosos.

⚠️ En la API Lua no existe el efecto no_border. Para quitar el borde se usa border_size = 0.

Equivalente en el formato antiguo (hyprland.conf)

Si usas hyprlang en lugar de Lua:

windowrulev2 = tag +drpopup, class:^(resolve)$, floating:1
windowrulev2 = stayfocused, tag:drpopup

Aplicar los cambios

hyprctl reload

Comprobar que las ventanas de Resolve siguen intactas (la principal debe seguir en tiling y sin etiquetas):

hyprctl -j clients | grep -i resolve

Si aún no funciona

Dos ajustes de respaldo, también en Hyprland:

• misc:focus_on_activate = true — enfoca la ventana cuando pide activación.
• cursor:no_hardware_cursors = true — relevante en NVIDIA, donde el cursor por hardware puede interferir con el foco de menús en Wayland.

Entorno donde lo probé

• SO: CachyOS Linux (Arch-like), kernel 7.2.8-cachyos.
• Compositor: Hyprland 0.56.2 sobre Wayland (Aquamarine 0.15.1).
• GPU: NVIDIA GeForce GTX 1060 6GB, driver 580.178.04.
• Resolve: 21.1 build 17 (/opt/resolve), ejecutándose como cliente XWayland.

Nota: por si te lo encuentras, hay un problema distinto de menús en Hyprland relacionado con tablets gráficas (issue #3004); este no era el caso.

Conclusión

El ratón “no funcionaba” en Resolve porque los popups perdían el foco al abrirse. Con una etiqueta y stayfocused vuelven a recibir los clics, sin tocar nada de Resolve. Es una de esas correcciones que se hacen una vez en la config del compositor y te olvidas del problema.