Trova il proprietario del grab del puntatore X.org


17

Ho un'applicazione che sembra aver afferrato il mouse (posso spostarlo ma non posso fare clic da nessuna parte), c'è un modo per trovare quale app possiede il mouse grab di X.org?

La scorciatoia fornita qui per rilasciare il mouse non sembra funzionare, quindi sono interessato a qualcosa che potrebbe darmi maggiori informazioni.


Sei sicuro che sia questo il problema? Sarebbe alquanto bizzarro per un'applicazione che non stai usando per fare questo (se lo facessi, smetterei di usare quell'app), quindi è probabile che, se questa è davvero la causa, è qualunque cosa stavi usando.
Riccioli d'oro

Ho scoperto quale per tentativi ed errori, uccidendo alcune cose fino a quando qualcosa (un'app di vino) ha rilasciato la presa.
Tobu,

Risposte:


16

Puoi farlo premendo il XF86LogGrabInfotasto, introdotto in questo commit .

Per impostazione predefinita, questo keysym non è associato a nessuna chiave fisica o combinazione di tasti. Ma puoi ancora attivarlo usando xdotool:

xdotool key "XF86LogGrabInfo"

Dopo aver eseguito quel comando, un elenco di grab attivi verrà registrato nel registro X. Almeno su Ubuntu, questo è /var/log/Xorg.0.log. Si troverà da qualche parte vicino alla fine del file di registro, ma potrebbero esserci diversi messaggi di registro irrilevanti sotto di esso. Se non ci sono prese, scrive:

[1199271.146] (II) Printing all currently active device grabs:
[1199271.146] (II) End list of active device grabs

Se ci sono prese (qui, ho aperto un menu in Firefox), registra qualcosa come:

[1199428.782] (II) Printing all currently active device grabs:
[1199428.782] Active grab 0x4c00000 (core) on device 'Virtual core pointer' (2):
[1199428.782]       client pid 15620 /usr/lib/firefox/firefox 
[1199428.782]       at 1199423728 (from active grab) (device thawed, state 1)
[1199428.782]         core event mask 0x7c
[1199428.782]       owner-events true, kb 1 ptr 1, confine 0, cursor 0x0
[1199428.782] (II) End list of active device grabs

2

Ho appena avuto un problema simile e l'ho ridotto a un bug che in qualche modo fa pensare a X11 che il pulsante centrale sia premuto e non rilasciato. La disconnessione fisica del mouse non aiuta, fino a quando non si verifica un evento di mouseup.

Il problema può essere riprodotto utilizzando xdotool mousedown 2: è impossibile cambiare lo stato attivo tra le finestre,

xdotool key XF86LogGrabInfo mostra la finestra del processo attualmente focalizzata, ma quando uno la uccide, un'altra finestra riceve lo stato attivo e lo stesso scenario continua.

Soluzione alternativa: problema xdotool mouseup 2.

Aggiornamento: il pulsante centrale premuto e non rilasciato è semplicemente il meno evidente, perché la maggior parte delle app non risponde, e alcuni mouse non hanno questo pulsante per provare e fare clic per vedere se il problema scompare.


0

Le voci nel registro Xorg possono essere piuttosto indecifrabili. Ho scritto un programma che li analizza e li presenta in una forma trattabile dall'uomo:

https://gist.github.com/CyberShadow/6412d11aea64144f8905cc0b8196f38e

Da usare, prima esecuzione xdotool key XF86LogGrabInfo, come descritto nella risposta della lumaca meccanica. Quindi, esegui il programma collegato sopra. Se il file di registro di Xorg non si trova in /var/log/Xorg.0.log, è possibile specificare la sua posizione utilizzando l' --xorg-logopzione. Vedi --helpper i dettagli.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.