Scopri cosa fa
Guarda il codice scoprire cosa dovrebbe fare. Se non ne hai bisogno, perché è lì? Qualcos'altro sta facendo il suo lavoro adesso? Se è qualcosa che è ancora richiesto, perché non funziona per te?
Molto spesso vedrai un software specifico per l'hardware scritto per casi limite come una singola gamma di laptop (ad esempio ci sono dozzine di vari driver hardware Thinkpad).
Secondo il suo readme , il driver copre wireless, LED, bluetooth, 3G e retroilluminazione. Per me, sembra che qualcosa che tu (o altri) potresti desiderare, quindi non è auspicabile che venga scaricato o inserito nella lista nera per impostazione predefinita.
Scopri come è stato installato sul tuo computer
Da dove proviene? È inserito nel kernel? È un tiro di Ubuntu? Questo alla fine deciderà dove è necessario presentare il reclamo.
Con problemi a livello di kernel, aiuta davvero a testare l'ultimo kernel vanilla stabile. Puoi prendere una copia dal repository mainline anche se probabilmente scoprirai che ci sono disallineamenti della versione GCC con alcuni driver solo binari (ne ho, con nvidia) quindi non è qualcosa su cui vorrai eseguire IMO tutto il tempo.
Se il problema persiste con un kernel vanilla, aggiungi un bug a monte e collegalo al bug del Launchpad e seguilo anche all'indietro. Un simpatico bug a doppio collegamento aiuterà tutti a rimanere nella stessa pagina.
In questo caso, sembra che sia un driver del kernel in-tree (cioè la sua fonte viene estratta nel repository del kernel e integrata).
Trova la persona o le persone responsabili
Non è ragionevole scaricare un bug su Launchpad e sperare che trovi la persona giusta. Direi che solo una piccola parte degli sviluppatori tiene traccia dei loro bug, quindi è necessario trovare i manutentori del software e mettersi in contatto.
Potrebbe sembrare maleducato iniziare a mandare email a freddo, ma il software è il loro bambino. Se non funziona, penso che vorrebbero saperlo. Nove volte su dieci, ti aiuteranno anche a identificare il problema.
Se è ancora gestito, ottieni le istruzioni di debug. Verificare che l'hardware sia compatibile.
Se non viene mantenuto, e puoi confermare che con il vecchio manutentore, invia un bug nel kernel avvisando le persone che c'è una parte del codice in decomposizione e che ti sta causando problemi.
Suggerisci azioni alle persone giuste
Quando sai qual è il problema, non tenerlo per te. Assicurati di agire sui tuoi bug.
Se è qualcosa che può essere risolto nel driver, inseguire le persone nel kernel per ottenere la nuova versione inserita nella versione di sviluppo. Chiedi di averne il backport su 2.6.35 per gli utenti Ubuntu esistenti. Parla con il team del Kernel riguardo all'introduzione delle modifiche al kernel Maverick (anche se potresti non avere fortuna lì).
Se è in putrefazione, spingere gli sviluppatori del kernel principale a scaricarlo dal loro repository. Chiedi agli sviluppatori del team del kernel Ubuntu di rimuoverlo dal loro repository. Almeno, chiedi che sia inserito nella blacklist (come alcuni moduli sono stati rimossi forzatamente da Ubuntu in passato).
Se si ottiene una buona inversione di tendenza nel riparare / distruggere il driver, dovrebbe essere possibile ottenere la sua correzione nel kernel Natty finale (che è ancora in -nextfase nel repository del kernel corretto).
Il punto che sto cercando di superare è quando fai il tuo triage e parli con le persone giuste, le cose ottengono molta più attenzione e hanno una probabilità così alta di un buon risultato finale.
E non fermarti affatto se vedi un'altra persona con lo stesso problema. Iscriviti, commenta il loro bug, chiedi cosa hanno trovato, chiedi cosa hanno fatto al riguardo ... E poi vai avanti. Non fare affidamento su di loro per risolvere il problema.
Ecco come dovrebbe funzionare l'open source. Collaborazione attraverso una buona comunicazione aperta. Comunica bene il tuo problema, aiuta dove puoi e hai buone possibilità di ottenere software di qualità migliore.