-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alessandro Pellizzari ha scritto lo scorso 11/01/2009 11:17: > Il giorno dom, 11/01/2009 alle 09.46 +0100, Davide Prina ha scritto: > >> se così fosse, allora con un solo driver si potrebbero gestire i >> firmware di tutti gli hardware tra loro "simili" (per esempio le >> webcam). Inoltre conoscendo come colloquiare con un firmware, allora si >> potrebbe colloquiare con qualunque altro "simile" ... ma ciò non è >> affatto vero, basta vedere l'esempio delle schede video (tra ATI e >> Nvidia ad esempio) o delle webcam ... >> >> In realtà ogni firmware ha un'interfaccia diversa ed è il driver che si >> occupa di creare un'interfaccia comune per i programmi che usano quel >> dato tipo di hardware, in modo che anche cambiando l'hardware e quindi >> anche il driver si avrà che il programma continua a funzionare >> correttamente. > > Sono vere entrambe le cose. > > Riprendo il tuo esempio delle ATI. C'e` un firmware (OpenBIOS) su ogni > scheda ATI degli ultimi anni che permette a un driver > (xserver-xorg-video-ati e ...-radeonhd) di supportare tutte le schede > ATI dalla X300 alla HD4870X2. Questo perche` il firmware espone al > driver una serie di API (o meglio, di registri) comuni, ma poi imposta i > "veri" registri delle schede in modo diverso. > > L'hardware e` molto diverso tra scheda e scheda, ma il driver (almeno in > 2D) non "vede" differenze. Per il 3D non c'e` ancora questo firmware, > perche` le caratteristiche variano troppo velocemente per fare una API > stabile. >
Ancora piu' complesso: il problema delle radeonhd non e' legato alla licenza del firmware - ATI ha dichiarato e dimostrato piu' volte di voler aprire specifiche e codice firmware - quanto ai moduli IP utilizzati nelle nuove GPU. E qui ritorniamo al problema ciclico: dove finisce il firmware e dove inizia l'hardware? Anche senza arrivare ai compilatori di silicio e alle logiche FPGA che implementano un core IP proprietario, anche un alimentatore che usa un microcontrollore implementa via software funzioni fino a pochi anni fa realizzate mediante circuiti analogici. Quando io progetto un dispositivo del genere, posso anche rilasciare il codice C con una licenza "libera", ma dal punto di vista funzionale equivale a rilasciare l'hardware con una licenza libera. Sebbene esista qualche esempio in questo senso (vedi baloon), a mio parere non ha molto senso `fissarsi` sulla licenza del firmware, almeno non piu' di quanto si sia disposti a fare per la licenza dell'hardware su cui gira tutto il sistema. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBAgAGBQJJa4APAAoJECVi+PFMdzdC0mkIAJm0qGXLJmlwDOuCCQ/CRpnu BNajZev35WA7VWqp7ixlXO10+eLexGadcAXtMtMtwxMULOKs0scX+3U7jXEsz9mn k/Tj3GVF7Ji6Q8SX1SsV6cxMWsuaAUTKR/FLX2e9qBdW2yd2z4VLUngv2t8hb0lJ wbW6qTbv1DvL+tr4SPjauatTvCK7P/yiTQNJX9dG6ViXFUVwsRLp7IuFgaPXm+Pj wZbnKKNLNAKnXpr9rygnlFQHruDNisQG5afpBoPz+zuA85Aq6Sr9PcMnKsoB44co +QO6l4f6V5JSoE1dTCHXEVq9xK1O2y496VXG7kJo5vtRfE3xUCa+w18bojm6pTo= =T+fu -----END PGP SIGNATURE----- -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org