Home | Informazioni | Community | Sviluppo | myReactOS | Contattaci
|
Community > ReactOS Newsletter Archive > ReactOS Newsletter: Newsletter 57Newsletter 57by Z98 on 2009-04-30 Driver Video VBoxIl driver video di VirtualBox ha iniziato a funzionare qualche tempo fa, il che significa che chi usa VirtualBox può usare l'accelerazione hardware per la grafica. Per renderlo funzionante, Timo Kreuzer ha sistemato due cose nel sottosistema Win32. Anche se il driver funzionava senza quelle modifiche, la sua funzionalità era in qualche modo ridotta e il rendering aveva dei problemi. La prima fix è stata per il puntatore del mouse, o più precisamente il disegno del movimento dello stesso lungo lo schermo. Quando il puntatore del mouse lascia una posizione, il contenuto che c'era originariamente lì deve essere redisegnato, e il puntatore deve essere nascosto. Dopo, viene aggiornata la posizione del cursore con quella nuova e si rivela e ridisegna il puntatore. Il problema era che il codice per disegnare il cursore nella nuova posizione cercava anche di nasconderlo nuovamente nella vecchia posizione. Tuttavia, poiché la posizione del puntatore era già stata aggiornata, quello che succedeva era che il contenuto della vecchia posizione del puntatore veniva disegnati nella nuova posizione del mouse. Il risultato era sostanzialmente la corruzione massiccia del display. Timo ha rimosso il codice responsabile e adesso il movimento del mouse funziona correttamente. Il secondo problema che è stato risolto era l'aggiornamento della risoluzione dello schermo. Questo è stato più semplice, perché semplicemente ros non scriveva la frequenza di aggiornamento nel registro. Quando il driver video la cercava e non la trovava cambiava alla risoluzione 640x480x256. Nota a margine, il driver video di VMware non dipende da questo valore. topRosBE e RBuildKJK::Hyperion ha fatto recentemente delle grosse (e necessarie) modifiche a RBuild. Tuttavia, ha finito per rivelare un problema in RosBE, in entrambe le versioni sia Windows che Unix. L'aggiornamento di RBuild sul quale lavora KJK richiede o richiederà l'uso di diverse variabili, TARGET_CFLAGS e TARGET_CPPFLAGS, HOST_CFLAGS e HOST_CPPFLAGS. Sfortunatamente, un bug nella versione Windows di GCC impedisce il loro utilizzo. Specificamente, GCC contiene i percorsi alle directory dove giacciono i file da includere incorporati così che è in grado di trovarli quando compila qualcosa che li usa. Apparentemente questo è deifficile da gestire e il nostro RosBE non lo fa in modo corretto. Per scavalcare il problema, definisce le variabili HOST_CFLAGS e HOST_CPPFLAGS per farle puntare alle directory giuste. Chiaramente, questo impedisce il loro utilizzo per aggiungere flag aggiuntive per la compilazione, cosa che KJK vorrebbe fare. Lui ha proposto di rinominare le variabili attualmente in uso a ROSBE_HOST_CFLAGS e così via. Il secondo problema esposto era che Unix RosBE non forniva le directory con i file da includere in TARGET_CFLAGS o TARGET_CPPFLAGS. Le modifiche di RBuild richiedono anche quella informazione per poter fornire ad altri compilatori le locazioni in caso non si usi GCC. Questo è più rilevante nel lato Windows, ma RBuild si aspetta quelle variabili indipendentemente dalla piattaforma dove si trova e la loro assenza in RosBE Unix ha creato più problemi. Questo è stato relativamente facile da risolvere comparato con il problema delle directory in GCC di Windows, poiché Colin semplicemente definiva le variabili per l'ambiente Unix. Al momento, è stata compilata una versione Windows di GCC con quella che sembra le directory corrette ma Daniel Reimer non è riuscito a compilare ReactOS con questa versione. Dal momento in cui un RosBE che non può compilare ROS sarebbe inutile, il team sta lavorando per cercare di capire dov'è il problema. Una volta scoperto, aspettatevi un'altra versione dell'ambiente di build. topDriver di NICCome parte della corsa verso la 0.3.9, Olaf Siejka e gli altri tester hanno provato diverse schede di rete su hardware reale cercando di vedere cosa succedeva quando installavano i driver. Hanno fornito rapporti di debug a Art Yerkes e Cameron Gutman, i quali li hanno esaminato per vedere le funzionalità mancanti oppure non corrette per sistemarle. Da lì, i due hanno iniziato ad implementare e sistemare le funzionalità fornendo delle patch ai tester per provarle. E così si sono scambiati rapporti e patch finché sono riusciti a fare runzionare una mezza dozzina di schede di rete. Ci sono ancora delle incosistenze, del tipo se serve il driver XP oppure quello 2000, bisogna provare, ma ReactOS almeno adesso fornisce funzionalità richieste da codice di terze parti anziché funzionalità richieste dallo stesso sistema operativo per funzionare. Il gruppo intende continuare con questa strategia nella strada verso la 0.3.10, fortunatamente avremo altri successi da raccontare. top0.3.9 e il FuturoAnche se la 0.3.9 ha visto l'inizio di funzionalità interessanti, alcune sono molto grezze. Il supporto audio è limitato e funziona solo su VirtualBox o l'ultima versione di Qemu, altre piattaforme non sono state provate perché Johannes Anderwald non ha tempo. Pure in quelle due piattaforme, i problemi con la cache comune e il driver FAT possono generare un crash mentre si riproduce del suono. Con la 0.3.10, gli sviluppatori intendono mettere a punto quello già raggiunto così che le caratteristiche disponibili siano più facili da usare e il sistema giri in modo più stabile. Allo stesso tempo, ci sono piani per fornire più supporto ai driver oltre le schede di rete e c'è stata una discussione riguardo cosa ci vorrebbe per poter fare girare driver video di terze parti. Il lavoro fatto di recente per fare funzionare il driver video di VBox è un passo, ma il sottosistema Win32 ha dei buchi sostanziali che bisogna patchare onde evitare che i driver video inciampino su delle idiosincrasie nel codice di ROS. top |