Attualmente sto eseguendo il rendering di video in Linux direttamente sul framebuffer utilizzando GStreamer.
Mi chiedevo come avrei fatto a nascondere la console virtuale durante il rendering. Posso impedire al cursore di lampeggiare, ma funziona solo quando nessun testo cambia sulla console.
X sembra creare una nuova schermata accessibile con Ctrl(+Alt)+F7:è possibile fare qualcosa del genere da solo? In qualche modo essere in grado di passare da una console alla schermata di rendering con Ctrl+Alt+F1 e Ctrl+Alt+F2.
Risposta accettata:
X non crea una nuova schermata.
Per utilizzare gli stessi dispositivi di visualizzazione e input degli eventi utilizzati dall'emulatore di terminale integrato del kernel (per presentare i suoi terminali virtuali), un programma deve predisporre per condividerli. L'emulatore di terminale del kernel fornisce un'API attraverso la quale un programma del genere può negoziare quando ha la responsabilità di input e output e quando lo ha l'emulatore di terminale integrato nel kernel.
Questa API è tramite ioctl()
chiama un descrittore di file che è aperto a un dispositivo a caratteri del terminale virtuale del kernel. Ci sono 64 di questi dispositivi in Linux, 16 in FreeBSD/PC-BSD. X non li crea. Ne apre uno esistente, per convenzione uno che nessun programma TUI sta tentando di utilizzare contemporaneamente come terminale virtuale del kernel. In altre parole:per convenzione non esiste una sessione di accesso TUI eseguita sul dispositivo terminale virtuale del kernel che X apre e utilizza.
Un programma che condivide con l'emulatore di terminale del kernel deve...
- ... indica all'emulatore di terminale del kernel di interrompere la scrittura nel framebuffer per visualizzare l'output o il cursore. Questo viene fatto con
KDSETMODE
ioctl()
per impostareKD_GRAPHICS
al giorno d'oggi abbastanza erroneamente chiamato modalità. Quando inKD_TEXT
modalità l'emulatore di terminale del kernel al giorno d'oggi di solito non ha nulla a che fare con l'hardware di visualizzazione che si trova in una modalità testo reale. Le cosiddette console framebuffer avere l'hardware del display in modalità grafica. La distinzione traKD_TEXT
eKD_GRAPHICS
modalità è che nella prima modalità l'emulatore di terminale del kernel disegnerà glifi dei caratteri sul framebuffer mentre la disciplina della riga terminale gli fornisce l'output e disegnerà anche un cursore; mentre in quest'ultima modalità non eseguirà alcun disegno. Al giorno d'oggi sarebbe meglio pensarli come modalità "disegna grafica" e "non disegnare grafica", se quella sbagliata non fosse chiamata "grafica". ☺ - … negozia il cambio di terminale virtuale, se applicabile. Questo viene fatto con il
VT_SETMODE
ioctl()
, con cui il programma può provvedere a ricevere segnali quando il terminale virtuale che sta utilizzando perioctl()
le chiamate vengono trasferite o disattivate. - … negozia la gestione dell'input con l'emulatore di terminale del kernel.
- Su Linux si potrebbe leggere direttamente dal sottosistema degli eventi di input, nel qual caso il programma dice all'emulatore di terminale del kernel di interrompere la lettura degli stessi eventi di input, di cui riceve copie, di interrompere la loro traduzione in caratteri e di interrompere inviandoli alla disciplina di linea come input. Il modo in cui ciò viene eseguito varia:
- Il modo originale per farlo era con
KDSKBMODE
ioctl()
, trasformando il terminale virtuale inK_RAW
modalità. In questa modalità, l'emulatore di terminale del kernel riceve ancora eventi di input dal sottosistema di eventi di input del kernel, ma non ne esegue alcuna elaborazione, passandoli alla disciplina di linea come input di caratteri. Tuttavia, questo meccanismo (che aveva le sue radici nel modo in cui X funzionava prima che esistesse un sottosistema di eventi di input) era rotto, in quanto l'input veniva ancora inviato alla disciplina di linea e doveva ancora essere svuotato. E richiedeva che iltermios
anche lo stato di input per il terminale è in modalità raw, altrimenti i codici di scansione non elaborati verrebbero interpretati erroneamente come caratteri speciali come i caratteri STOP o INTR dalla disciplina di riga. - Un modo, una volta considerato migliore, per farlo era con
KDSKBMODE
ioctl()
, trasformando il terminale virtuale inK_OFF
modalità. In questa modalità, l'emulatore di terminale del kernel non solo non elaborerà gli eventi di input, ma non li invierà alla disciplina di linea. Tuttavia, questo meccanismo è stato interrotto, perché faceva parte di unK_OFF
/K_RAW
/K_CODE
/K_XLATE
interruttore di modalità. systemd e altri sistemi simili gestirebbero le modalità del terminale virtuale e finirebbero per commutare i terminali virtuali out diK_OFF
modalità. - Il modo migliore al giorno d'oggi è usare il
KDSKBMUTE
bandiera. Questo disattiva l'elaborazione di tutti gli eventi di input senza interessare o essere influenzato daK_RAW
/K_CODE
/K_XLATE
cambio modalità.
- Il modo originale per farlo era con
- Su FreeBSD/PC-BSD, in primo luogo, non esiste un dispositivo di input per caratteri di evento separato. Si legge l'input della tastiera attraverso il terminale virtuale del kernel comunque , quindi anche se si potrebbe voler cambiarlo in scancode (
K_RAW
) o codice chiave (K_CODE
) modalità, non si vuole spegnerlo.
- Su Linux si potrebbe leggere direttamente dal sottosistema degli eventi di input, nel qual caso il programma dice all'emulatore di terminale del kernel di interrompere la lettura degli stessi eventi di input, di cui riceve copie, di interrompere la loro traduzione in caratteri e di interrompere inviandoli alla disciplina di linea come input. Il modo in cui ciò viene eseguito varia:
Ci sono alcune interazioni, qui. Un server X, ad esempio, commuta il terminale virtuale in modalità keycode, legge i keycode e li trasforma in keysyms X, facendoli passare attraverso i meccanismi di gestione della tastiera X. Ciò significa che l'emulatore di terminale integrato nel kernel non riesce mai a eseguire l'elaborazione speciale per Alt +Fn sequenze di tastiera. È il server X che deve riconoscere da solo Ctrl +Alt +Fn .
Ulteriori letture
- Arthur Taylor (02-02-2013). systemd non dovrebbe chiamare KDSKBMODE su un VT con X . systemd-devel.
- Adam Jackson (16-11-2012). [PATCH] vt:rilascia K_OFF per VC_MUTE . Mailing list del kernel Linux.
- Adam Jackson (16-11-2012). [PATCH] linux:preferisci ioctl(KDSKBMUTE, 1) su ioctl(KDSKBMODE, K_OFF) . xorg-devel.
- Michael K. Johnson (1994-06-01). Suggerimenti per la programmazione Linux . Giornale Linux.