Surface Pro 10: Type Cover non funziona su GParted e Kali Linux in dual boot – cause, diagnosi e soluzioni

Su alcuni modelli Surface di ultima generazione, come Surface Pro 10 for Business, la Type Cover funziona nella primissima fase di avvio delle ISO Live di GParted o Kali Linux, poi smette di rispondere. Qui trovi cause, diagnosi e soluzioni pratiche e sostenibili.

Indice

Panoramica del problema

Il comportamento riportato è chiaro: su Surface Pro 10 for Business la Type Cover (tastiera con touchpad) è operativa per pochi secondi dopo il boot di una Live ISO (ad esempio GParted o Kali Linux), quindi l’input si interrompe. Il cursore e le icone iniziali sembrano reagire, ma subito dopo tastiera e touchpad risultano “morti”. Il fenomeno si ripresenta a prescindere da:

versione specifica della Live ISO di GParted;
modalità di scrittura della chiavetta, sia DD (bit‑per‑bit) sia ISO;
schema di partizionamento del disco (GPT o MBR) e differenti settaggi UEFI/Secure Boot;
uso di un’altra Type Cover identica, aggiornamento UEFI/firmware o import di driver dall’ambiente Windows.

Su altri modelli, come Surface Pro 5, la Type Cover invece continua a funzionare regolarmente nelle stesse condizioni. Questo contrasto è la chiave per capire l’origine del problema.

Perché la tastiera smette di funzionare

La spiegazione più probabile è nel divario fra hardware e supporto del kernel Linux incluso nelle ISO Live: la Type Cover dei Surface più recenti dialoga attraverso un percorso d’integrazione diverso rispetto ai modelli più datati. In sintesi:

nelle fasi di pre‑boot la tastiera può essere gestita dal firmware UEFI tramite servizi di emulazione base per l’input, motivo per cui “funziona all’inizio”;
appena il sistema passa il controllo al kernel Linux della Live, l’emulazione UEFI si disattiva e tutto dipende dai driver effettivamente disponibili;
su Surface Pro 5 i driver generici del kernel coprono bene il controller del cover; sul modello più recente serve un set di driver o patch non ancora presente nelle Live ISO standard;
i driver ufficiali rilasciati da Microsoft nel pacchetto per Windows non sono utilizzabili su Linux e non possono essere “iniettati” in una Live ISO per risolvere la cosa.

In altre parole, l’hardware è sano, ma il kernel delle ISO Live non contiene (ancora) tutto il necessario per il controller che veicola gli eventi della Type Cover del dispositivo più recente. Da qui l’apparente “disattivazione” dell’input al termine della fase iniziale.

Cosa non risolve davvero

È utile chiarire alcuni tentativi frequenti che, seppur ragionevoli, non indirizzano il problema alla radice:

Importare i driver Windows: l’MSI “Surface Pro 10 Drivers and Firmware” e l’installazione massiva via pnputil aiutano solo Windows. Non modificano la dotazione driver del kernel Linux usato nelle Live e non influenzano l’ambiente di recovery WinRE.
Cambiare schema di partizione o opzioni UEFI: GPT/MBR, CSM, Fast Boot e simili non forniscono driver al kernel Linux; possono incidere sul boot, non sulla disponibilità della Type Cover.
Usare una Type Cover identica ma diversa: se l’elettronica interna è della stessa famiglia, il risultato non cambia.
Aggiornare il firmware di sistema: opportuno per altri motivi, ma qui non aggiunge automaticamente i moduli Linux mancanti.

Soluzioni rapide e affidabili

In attesa che il supporto arrivi a bordo delle distribuzioni, le soluzioni immediate sono pragmatiche e sicure:

Tastiera e mouse esterni: collegare periferiche USB‑A o USB‑C (tramite adattatore/hub) garantisce il controllo dell’ambiente Live e durante un’installazione. È l’opzione più lineare e a prova di imprevisto.
Kernel con patch di comunità: progetti come le community dedicate ai dispositivi Surface mantengono kernel e moduli extra per i modelli più recenti. Verifica periodicamente se il modello in uso è incluso e, in caso positivo, valuta l’impiego di un kernel personalizzato.
On‑screen keyboard: su ambienti desktop completi (es. una Live di Kali con GNOME) si può attivare la tastiera virtuale per sopperire alla Type Cover, ma è meno confortevole e non sostituisce il touchpad.

La prima strada è la più robusta per operazioni veloci (cloning, partizionamento, test), mentre l’adozione di un kernel personalizzato è ideale se si intende usare Linux stabilmente sul dispositivo.

Come riconoscere che è un tema di driver

Questi riscontri pratici aiutano a confermare la diagnosi:

L’input funziona nei menu iniziali della Live e sparisce subito dopo l’ingresso nel sistema grafico o nella shell: tipico passaggio da emulazione firmware a gestione del kernel.
Assenza di eventi dai dispositivi di input della Type Cover in strumenti come evtest o libinput.
Messaggi del kernel che indicano un dispositivo HID‑I2C non inizializzato, un bus non agganciato o la mancanza di un driver di trasporto.

Diagnostica rapida da eseguire

Collega una tastiera USB e verifica i seguenti punti per raccogliere dati utili:

# Elenca i dispositivi di input riconosciuti da libinput
sudo libinput list-devices

Mostra i device input secondo il kernel

cat /proc/bus/input/devices

Cerca messaggi chiave nel journal del kernel

sudo dmesg | grep -iE "surface|ssam|i2c|hid|type|cover"

Testa gli eventi della tastiera se presente

sudo evtest

Interpretazione rapida:

se non vedi alcuna voce riconducibile alla Type Cover, o se evtest non può aprire il relativo device, mancano i moduli necessari o non stanno caricando;
se compaiono righe d’errore su I2C, HID o moduli legati al sottosistema Surface, il driver c’è ma non si aggancia correttamente all’hardware.

Percorso avanzato con kernel personalizzato

Se l’obiettivo è usare Linux in modo continuativo su Surface Pro 10, l’approccio più solido consiste nell’installare una distribuzione supportata e sostituire il kernel con una build che includa le patch specifiche per la piattaforma Surface. A livello operativo, la tabella di marcia può essere questa:

Installazione con periferiche esterne: esegui l’installazione utilizzando una tastiera USB. Mantieni la partizione Windows per ricevere futuri aggiornamenti firmware dal canale ufficiale.
Abilita un repository dedicato: aggiungi il repository della community che mantiene kernel ottimizzati per i Surface della generazione più recente. Segui le loro istruzioni per la tua distribuzione (derivati Debian/Ubuntu, Arch, Fedora, ecc.).
Installa kernel, headers e tool: insieme al kernel, installa i pacchetti complementari (headers, firmware aggiuntivo, eventuali demoni utenti per la gestione del touch avanzato).
Gestisci Secure Boot: se il dispositivo usa Secure Boot, firma i moduli o disattiva temporaneamente la funzione. In alternativa, utilizza la procedura di enrollment del MOK per accettare i moduli alla prima accensione.
Rigenera l’initramfs: assicurati che i moduli relativi a HID/I2C e al sottosistema Surface siano inclusi nella fase di early boot.
Riavvia e verifica: controlla con libinput list-devices ed esegui un test con evtest. Se tutto è a posto, la Type Cover e il touchpad tornano operativi senza dover usare periferiche esterne.

Questo percorso richiede qualche attenzione ma è stabile e riproducibile. L’abilitazione di funzioni avanzate come penna, sensori o gestione energetica può richiedere componenti aggiuntivi mantenuti dalla comunità.

Uso di una Live con persistenza

Se preferisci restare in ambito Live, puoi predisporre una chiavetta persistente in modo da installare una versione del kernel più adatta direttamente sul supporto USB. Su una Live di derivazione Debian (come Kali), la procedura tipica è:

crea una partizione dati dedicata alla persistenza, oltre a quella dell’ISO Live;
formatta la partizione in ext4 e chiamala “persistence”;
aggiungi un file persistence.conf alla radice con il contenuto / union;
avvia con l’opzione persistence e installa il kernel desiderato sul sistema Live persistente.

# Esempio sintetico (attenzione a sostituire sdX con il tuo device)
sudo parted /dev/sdX --script mkpart primary ext4 4GB 100%
sudo mkfs.ext4 -L persistence /dev/sdX3
sudo mount /dev/sdX3 /mnt
echo "/ union" | sudo tee /mnt/persistence.conf
sudo umount /mnt
Al boot, scegli l'opzione 'persistence'

In questo modo puoi installare un kernel alternativo e mantenerlo sulla chiavetta, evitando di toccare il disco interno finché non sei soddisfatto del comportamento.

Creare una Live personalizzata per partizionamento

Se l’esigenza primaria è solo GParted, puoi creare una Live minimalista personalizzata in due varianti:

Live Debian con GParted: costruisci una Live con live‑build includendo GParted e un kernel personalizzato che integri i moduli Surface. È una soluzione “cucita su misura” e leggera.
Remaster di una ISO esistente: estrai la ISO, chroot nella root squashfs, installa il kernel e i moduli aggiuntivi, rigenera l’initramfs e poi ricrea la ISO. Richiede dimestichezza ma consente un risultato rapido.

Nota operativa: le Live estremamente essenziali (come alcune build di GParted) potrebbero non includere gli strumenti necessari per signature, DKMS o gestione MOK; una Live più “piena” semplifica la vita.

Impostazioni di sicurezza e firma dei moduli

L’adozione di kernel o moduli non forniti dalla distribuzione può scontrarsi con Secure Boot. Le opzioni sono tre:

Disattivare temporaneamente Secure Boot per validare il funzionamento e poi valutarne la riattivazione con moduli firmati.
Firmare i moduli con una chiave locale, installare la chiave nel database MOK ed eseguire l’enrollment al riavvio.
Usare un kernel già firmato dalla community o dal maintainer, qualora disponibile per la tua distribuzione.

Qualunque strada tu scelga, documenta la procedura così da poterla ripetere su future reinstallazioni o su altre chiavette Live.

Verifiche mirate dopo la modifica del kernel

Dopo aver installato un kernel alternativo, verifica passo‑passo:

# Il dispositivo I2C/HID della Type Cover appare?
sudo dmesg | grep -iE "i2c|hid|surface|keyboard"

Il device di input è presente e fornisce eventi?

sudo libinput list-devices
sudo evtest

I moduli attesi sono caricati?

lsmod | grep -iE "hid|i2c|surface|ssam"

Il touchpad espone gesture libinput?

libinput debug-events --device /dev/input/eventX

Se gli eventi scorrono in evtest e libinput, sei sulla strada giusta. Se continuano a mancare, ricontrolla Secure Boot, l’initramfs e l’effettivo caricamento dei moduli.

Tabella di riferimento rapido

Scenario	Come si manifesta	Probabile causa	Rimedio consigliato
Live di GParted su Surface Pro 10	Type Cover si spegne dopo pochi secondi	Driver mancanti nel kernel della Live	Tastiera USB oppure Live personalizzata con kernel adatto
Live di Kali su Surface Pro 10	Nessun input da tastiera/touchpad	Mancanza del trasporto HID‑I2C del cover	Kernel con patch di comunità, persistenza e Secure Boot gestito
Installazione con periferiche esterne	Funziona regolarmente	Nessun problema hardware	Procedi e poi sostituisci il kernel in post‑install
Surface Pro 5 con le stesse ISO	Type Cover sempre operativa	Controller compatibile con driver generici	Nessuna azione necessaria

Best practice per il dual boot

Se intendi configurare un dual boot con Windows e una distribuzione Linux su Surface Pro 10, considera queste linee guida:

Mantieni Windows su una partizione dedicata per ricevere aggiornamenti firmware e microcode ufficiali.
Usa l’avvio UEFI puro con GPT; semplifica la gestione di BitLocker e dei bootloader moderni.
Backup del disco prima del ridimensionamento delle partizioni con GParted; verifica l’integrità del filesystem prima di toccare partizioni cifrate o di sistema.
Boot‑loader: prediligi soluzioni standard fornite dalla tua distribuzione (grub o systemd‑boot) e non modificare voci UEFI non documentate.
Gestione energia: dopo l’installazione del kernel personalizzato, testa sospensione, ripresa e modalità a basso consumo. L’input della Type Cover deve restare affidabile anche dopo sleep/resume.

Domande frequenti

È un guasto della Type Cover?
Molto improbabile. Il fatto che funzioni su altri modelli o in Windows suggerisce chiaramente un tema di driver del kernel Linux nelle Live ISO.

Installare i driver Windows all’interno della Live può aiutare?
No. I driver Windows non sono caricabili dal kernel Linux e non vengono considerati durante il boot di una ISO Live.

Disattivare o attivare Secure Boot risolve?
Secure Boot non aggiunge driver mancanti. Diventa però rilevante quando installi moduli o kernel non firmati: in quel caso devi firmarli o disattivare temporaneamente la verifica.

Quale distribuzione scegliere per il dual boot?
Scegli una distribuzione con aggiornamenti rapidi del kernel e una community attiva su dispositivi Surface. L’importante è poter installare agevolmente kernel personalizzati e firmware aggiuntivi.

Perché il puntatore si muove per pochi secondi e poi muore?
Perché all’inizio stai usando i servizi di input del firmware UEFI. Quando il kernel prende il controllo, quell’emulazione si spegne e servono i driver nativi. Se mancano, l’input scompare.

Checklist operativa

prepara una tastiera USB‑C/USB‑A e, se serve, un hub per collegare anche un mouse;
avvia la Live e verifica libinput list-devices, evtest, dmesg per confermare la diagnosi;
se devi solo partizionare, valuta una Live personalizzata o usa periferiche esterne senza complicare l’ambiente;
per un uso stabile, installa la distro, aggiungi kernel con supporto Surface, gestisci Secure Boot, rigenera initramfs;
testa sospensione/ripresa e input dopo ogni aggiornamento di kernel o firmware.

Note importanti sulla sicurezza

Quando lavori con GParted o strumenti di partizionamento:

esegui sempre un backup completo o almeno dei dati critici prima di ridimensionare o spostare partizioni;
verifica l’assenza di errori dei filesystem (check/repair) prima di operare, specialmente su volumi cifrati o con snapshot;
annota la tabella delle partizioni attuale e il layout di boot; in caso di imprevisti potrai ripristinare rapidamente la configurazione.

Quando rivolgersi alla community

Se la Type Cover continua a non funzionare anche dopo l’adozione di un kernel personalizzato, vale la pena condividere i log essenziali nei canali tecnici pertinenti. I tre output che accelerano la diagnosi sono:

sudo dmesg -T | grep -iE "surface|ssam|i2c|hid" &gt; dmesg_surface.txt
sudo evtest &gt; evtest_surface.txt
libinput list-devices &gt; libinput_surface.txt

Includere questi file insieme al modello preciso del dispositivo e alla versione del kernel in uso aiuta chi mantiene i driver a capire dove intervenire.

Perché su alcuni Surface tutto funziona e su altri no

Non tutti i Surface adottano la stessa catena di componenti per l’input. Sui modelli meno recenti, il controller della Type Cover rientra bene nel perimetro dei driver HID/I2C già disponibili da anni nel kernel Linux. Sui modelli più moderni, invece, il percorso di trasporto può appoggiarsi a sottosistemi e protocolli aggiuntivi che richiedono driver dedicati, talvolta non ancora integrati nelle Live ISO più diffuse. È il motivo per cui la tua tastiera funziona perfettamente su un modello e si spegne dopo pochi secondi su un altro, pur usando la stessa chiavetta.

Conclusione

Il comportamento osservato su Surface Pro 10 for Business non è sintomo di guasto hardware, bensì della mancanza di driver adeguati nel kernel Linux delle Live ISO provate. La finestra di funzionamento iniziale è l’effetto dell’emulazione UEFI, che termina appena il kernel prende in carico l’hardware. Nell’immediato, la soluzione più solida consiste nell’usare una tastiera esterna per portare a termine le attività Live o l’installazione. Per un impiego quotidiano di Linux sul dispositivo, è consigliabile installare un kernel con patch specifiche mantenute dalle community tecniche e gestire correttamente Secure Boot e initramfs. Con questi accorgimenti otterrai una Type Cover stabile e potrai beneficiare delle potenzialità del dispositivo anche in dual boot.

In sintesi: hardware sano, driver non ancora presenti di default nelle Live; soluzione immediata con periferiche esterne e, nel medio periodo, kernel personalizzati o aggiornati non appena il supporto per la piattaforma viene integrato nelle distribuzioni.