Newsgroup: it.comp.os.linux.development
Titolo: little e big endian: il pippone del sabato pomeriggio.

scusate la domanda cretina, ma stavo pensando una cosa.
Ho visto che molte architetture usano il bus pci per le schede, non a caso
il kernel di linux ha i driver in una parte dei sorgenti che è
indipendente dalla parte legata alle architetture.
Cambia qualcosa nel funzionamento di queste schede se vengono messe su una
architettura big endian?
Il mio dubbio nasce dal fatto che ho un programma che acquisisce video da
una telecamera, il tutto mi arriva in formato targa e i colori sono
nell'ordine blu, verde e rosso. Siccome staimo pensando di far girare
l'applicazione linux su un powerpc, che dovrebbe essere big endian, mi
ritroverò con l'ordine dei colori rosso, verde e blu?


Scommetterei sul no.
Mi sembra piu' facile e conveniente gestire la conversione in hardware.
Alessandro.

 ritroverò con l'ordine dei colori rosso, verde e blu?
Secondo me avrai grosse possibilita' di doverti riscrivere buona parte 
del driver e swappare RGB in BGR sara' il minore dei tuoi problemi :)
Comunque se il formato in uscita e' TARGA e non raw e' molto probabile 
che usi gia' da ora la sintassi big endian anche se sei su intel.
Bye,
  Gabry

 architettura big endian?
Se il driver e` ben fatto, no. Se l'hardware e` ben fatto, la conversione
(se necessaria) potrebbe essere addirittura gestita dall'hardware. Se invece
il driver e` mal fatto... Molto dipende anche dall'API. Ho visto ben
pochi device che funzionavano sia in big che in little. Tranne per i device
memory mapped col codice utente scritto a dovere.
Poi esiste il problema del tuo codice (se ne hai). Come indirizzi i dati?
Casti a un puntatore (un array)? Di che cosa? Oppure lasci che il driver
ti crei i tuoi files TGA?
Ciao, e buona fortuna,
-- 
       Roberto Divia`             Love at first sight is one of the greatest
       =============             labour-saving devices the world has ever seen.
Mailbox: C02110                 CERN-European Organization for Nuclear Research
E-mail: 
Robert...@cern.ch
           CH-1211 GENEVE 23, Switzerland

 ti crei i tuoi files TGA?
io faccio un memory mammping del frame grabber per fare il bouble
buffering. Quindi mi arriva giù il mega array di unsigned char, che vado a
leggere sequenzialmente. Poi questi dati devono essere caricati in un
GtkDrawingImage e necessito di invertire il primo ed il terzo byte di ogni
pixel. Poi se volgio salvare devo rigirare di nuovo.
Insomma, ho paura che girando tutte queste volte e cambiando endianess
l'entropia del programma cresca eccessivamente. E allora visto che per ora
la scelta del g4 è solo sulla carta potrebbe essere stroncata sul nascere
in favore di qualche altro processore.

 pixel. Poi se volgio salvare devo rigirare di nuovo.
Quindi probabilmente su un'architettura PowerPC non dovresti fare 
nessuno swap :)
Da quello che dici probabilmente fai l'acquisizione tramite 
l'interfaccia video4linux e le relative ioctl() di sync e grab dei 
frame, sinceramente non penso che il big endian sia un grosso problema, 
piuttosto forse ti conviene informarti se il il driver bttv (se 
acquisisci con il classico bt878) o cmq il driver che usi e' stato 
testato anche su architetture big endian, nel caso del bttv io non ne 
sono tanto sicuro, e te lo dico avendoci messo le mani dentro per un 
progetto l'anno scorso, in quanto il codice (e pure l'architettura) di 
quel driver sono veramente di scarsa qualita'.
Bye,
  Gabry

 quel driver sono veramente di scarsa qualita'.
<urlo di dolore>nooo!!!!</urlo>
sul serio?!?! dai non dirmi che il bttv fa schifo. Uso proprio quello....
che problemi hai avuto di preciso?
cosa ne dici di v4l2? sono un po' meglio? nella speranza che i 2.6 escano
presto...
Che swappamento di balle.... Altro che di pixel.... :-(