Newsgroup: it.comp.os.linux.sys
Titolo: X.org e ati mobility

Ho un portatile (acer 2012) che monta una ati mobility radeon 9700.
Ho appena installato slackaware 10 con 
x.org
, ma non riesco a
configurarlo per usare i driver ati. O meglio, se li installo, poi x
mi si pianta o mentre carica kde o quando parte lo screensaver o in
altri momenti casuali.. Quando si blocca si muove il mouse, ma nn
risponde a nessun comando.
Lo stesso mi succedeva con fedora2, anche lei con xorg.
carlo.
-- 
Ciao,
Carlo.
Per rispondere via mail: blaze83 chiocciolina people punto it
"Bisogna porsi delle mete per aver il coraggio di raggiungerle."
Benito Mussolini (1883-1945), politico italiano.

 Lo stesso mi succedeva con fedora2, anche lei con xorg.
Di che driver parli ??
non mi risulta esistano driver ati per le mobility.......
con la configurazione originale funzionava ?
in /etc/X11/ hai un file XF86Config-4 ?
se c'è salva /etc/X11/xorg.conf e poi rinomina XF86Config-4 in xorg.conf e
prova.....
-- 
Linux user "Slackware-dotato" 

 non mi risulta esistano driver ati per le mobility.......
io uso quelli x le ati std , funzionano abbastanza bene, peccato siano
chiusi....
ciao.
-- 
C'e' un solo modo per avere un matrimonio felice, e non appena lo
scopriro' mi sposero' di nuovo.
                -- Clint Eastwood

prova.....
Ho usato i driver ati per le radeon normali..
Prima avevo il sistema funzionante ma non usava il rendering hardware
e non riuscivo ad andare alla risoluzione massima (una wide,
1280x800).
Cosě ho scaricato i driver, li ho installati (rpm2tgz, configurati e
installati), ho fatto girare il tool di configurazione (fglrxconfig mi
pare), dopodichč ho rinominato il file xf86config-4 in xorg.conf.
A questo punto kde parte pero' spesso si blocca verso la fine del
caricamento, oppure appena parte il salvaschermo (o in altri momenti).
Quando si blocca di solito si muove il mouse, ma nn č possibile fare
niente (ne'ě tornare alla console, ne' fare ctrl-alt-canc o
ctrl-alt-backspace).
Lo stesso problema l'ho avuto con fedora2, anche lei usando xorg.
Usando i driver vga standard invece sembra andare tutto bene.
Ah, ho provato sia usando l'agpgart interno dei driver che il modulo
del kernel.


 Usando i driver vga standard invece sembra andare tutto bene.
Io quando usavo vesa era un disastro totale, avevo anche un difetto di 
visualizzazione-
Con i driver proprietari e' piu veloce e funziona benissimo.
Purtroppo ho provato in tutti i modi a far andare il tv out ma nn c'e' 
verso.
Io credo sia colpa del fatto che fglx funziona *SOLO* a 24 bit e la tv 
nn credo vada a 24... almeno non la mia :/
Qualcuno c'e' riuscito o sbaglio io qualcosa ? (usando il driver ati 
intendo)
Ho notato che parlate di 
x.org
, in sid abbiamo ancora xfree (come al 
solito arriviamo piu o meno un anno dopo... )
Volevo chiedere, se qualcuno ha informazioni al riguardo, per esempio, 
verra' gestito con la stessa velocita' ipersonica di Xfree oppure 
finalmente ci saranno rilasci piu frequenti?
Ciao
Fox
Ah, ne approfitto, visto che hai un acer, sei riuscito a far andare i 
tastini inutili del wireless, bluethoot mail e browser?
Io ho compilato il modulo, l'ho inserito e caricato nel kernel (2.6.7) 
ma nn funziona...

 solito arriviamo piu o meno un anno dopo... )
Mpf. sid, e "anno dopo" nella stessa frase e` un po` forte. Pero` trovo
carino quel "arriviamo".
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
I rarely saw people sitting at computers producing real code wearing ties.

 carino quel "arriviamo".
:-D
Cmq se non e' un anno credo un 9-10 mesi tutti.
Se non erro xfree 4.3 e' stato rilasciato i primi mesi del 2003 
(febbraio?) ed e' approdato "ufficialmente" in sid a dicembre 2003 (per 
un mese poi, se nn sbaglio proprio dicembre... e' rimasto anche 
irreperibile... )
:D

 irreperibile... )
Le prime avvisaglie, risalgono ad agosto:
http://packages.qa.debian.org/x/xfree86/news/25.html
E xfree e` un pacchetto _estremamente_ problematico.
Infatti, mi pare che i messaggi su X tra i gruppi icol* si sprechino. Ci
sara` un perche`. :)


 carlo.
Hai configurato 
x.org
 con xorgconfig?
Se si che modello di scheda hai scelto?
Io ho una ATI sul portatile un po' diversa dalla tua, ma cmq Radeon ed
ho scelto il modello "ATI Radeon (generic)" e funziona senza dare alcun
problema.
In attesa di altri dettagli della tua configurazione.
Mad 

 sara` un perche`. :)
Qui mi piacerebbe aprire un mezzo dibattito... del tipo, e' proprio solo 
perche' e' complesso o anche xche' e' un po studiato male?
Ciao :)

 Ciao :)
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
	Prima di parlare collegare la spina del cervello,
	 leggere e in caso di schermata blu riavviare.

 Mica tutti hanno bosogno di usare degli X terminal
Una discussione su questo argomento sarebbe veramente utile (almeno per 
me) e sinceramente non vedo il motivo di non postare le eventuali nostre 
conclusioni e idee al gruppo di 
x.org
. (io no di sicuro, ma dentro qua 
c'e' gente che ne sa una piu del diavolo :-D )
Io di certo ne sono in grado di sviluppare ne tantomeno di 
concettualizzare i funzionamenti di una architettura cosi complessa, 
pero' non vorrei nemmeno fare come al solito e cioe' limitarmi a 
elencare quelli che per me sono i difetti e fare quello che pretende e 
basta.
Inizio "buttando un bel sassone nel lago" :-D
ritengo assurdo che per cambiare ogni scemata come le forme del 
puntatore sia necessario un riavvio del server grafico.
Penso che serva un modo x poter ricaricare al volo quelle parti che lo 
necessitano, dal cambio del mouse, al puntatore al tv out.
Per i terminali... ti diro', io le funzioni che ci sono, le lascerei, se 
male non fanno, xche' toglierle e non continuare a svilupparle?
Io mi batterei di piu x avere quello che non abbiamo, tipo appunto una 
base solida ma soprattutto chiara e trasparente da fornire ai produttori 
di HW di modo che possano sviluppare i driver. (open o chiusi poi se ne 
parla, l'importante e' che ci siano nell'immediato)
:)

 perche' e' complesso o anche xche' e' un po studiato male?
Perche` e` complesso.
C'e` un motivo del perche` e` complesso. Che poi, a diversi utenti
desktop, le feature aggiuntive della piattaforma client/server di X, non
interessino, e` altro paio di maniche.
In piu` i produttori di HW, fanno davvero scelte, diciamo, fantasiose,
per non dire di peggio. E questo non aiuta. Ovviamente, rilasciare le
specifiche, per molte case di HW e` un tabu`.
Mescola il tutto e ottieni X.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Christ died for our sins, so let's not disappoint him.

 Mica tutti hanno bosogno di usare degli X terminal
Afaik, non credo. Probabilmente perche` l'effort per scrivere software
di supporto alle decine (centinaia) di schede video, undocumented,
closed, sarcazzanti, biturbo, e` amplissimo, per creare un duplicato
degli sforzi.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
If you think you need threads then your processes are too fat.

 
Sarebbe materia per 
x.org
: tagliare tutto il client/server e tenere i 
driver grafici


 driver grafici
imho dovrebbero riscrivere il cuore e renderlo modulare... *molto* 
modulare direi, proprio per permettere di abbracciare tutte le 
implementazioni possibili immaginabili.
Se serve poi uno ci attacca il client, e tutto il resto
:)

  imho dovrebbero riscrivere il cuore e renderlo modulare... *molto* 
Beh, questo lo stanno facendo. Stanno scorporando le libx11, le varie
estensioni e tutto il resto.
Fortunatamente (IMHO) l'abbandono dell'architettura client-server
non pare invece in programma.
-- 
Francesco Romani - Ikitt   (signature under [re]construction)
'A geek is someone who spends time being "social" on a computer.'
'In fact, users don't read /anything/'                         -- Joel Spolsky

 driver grafici
Mi sembra che la fai un filino facile.
i "driver" grafici, funzionano sull'api di xfree. Sono da riscrivere
totalmente, se ne cambi "il motore", afaik.
(oltre a scrivere un motore ex-novo, si intende).


 Se serve poi uno ci attacca il client, e tutto il resto
Non hai scritto molti programmi, sopratutto che facciano interfaccia
all'hw, di la verita` ;)


 all'hw, di la verita` ;)
haha :)
no no, io non saprei nemmeno da dove partire!!
mi piace scrivere qualche scematina base base ma piu in la di tanto non 
vado. Purtroppo non ho nemmeno le conoscenze per farlo. :(
Al massimo io potrei fare l'interfaccia di configurazione del mouse 
pincopalla :P
ciao! :)

 non pare invece in programma.
Ti scoccia dirmi dove si possono trovare info?
io sul sito piu che sapere chi partecipa in che misura e le linee guida 
nn ho trovato... :/
intanto guardate qua:
http://insitu.lri.fr/~chapuis/metisse/index.html
era stamattina su ./
:-D

 
Lo so che la fo facile.. solo che il pupo ha già delle buone prestazioni 
tirandosi dietro tutto un (gran bel) pezzo di software che nel 90% dei 
casi non serve.. Pensa a quanto sarebbe più leggero un sistema non 
client/server: altro che gatos e dri!


  Ti scoccia dirmi dove si possono trovare info?
http://www.freedesktop.org
 , navigando tra le pagine dei progetti
e sfogliando le mailing list. Xorg e 
freedesktop.org
 hanno unito
gli sforzi per la creazione di server/librerie X (per fortuna),
e i lavori stanno procedendo.


  una presa di posizione sul server sonoro (Alsa )
Pare invece ci sia del fermento attorno a NAS. Questa questione e` ancora
aperta, mi pare ne discutessero anche recentemente sulle mailing list
di X.org.


  client/server: altro che gatos e dri!
Beh con Xv e DRI vengono saltati (ove possibile, tipo in locale) 
comunque un bel po` di layer, quindi le prestazioni non dovrebbero
aumentare enormemente... Magari, credo, si ridurrebbe l'occupazione
di memoria, ma pare che quello si possa ottenere riscrivendo (in parte
o del tutto) le librerie di X11.
Leggendo le succitate pagine/ML su 
freedesktop.org
, pare infatti
che riscrivendo le librerie o adottandone di compatibili ma piu`
leggere (XCB/XCL) i risultati siano positivi in questo senso.


 
Attendiamo fiduciosi


 Attendiamo fiduciosi
Ah sicuramente!
Ho letto non ricordo dove, che i software che usano opengl saltano X e 
comunicano direttamente con l'HW.
Date le mie limitate conoscenze fatico a capire se e' un vantaggio o meno.
A naso direi che non avendo niente in mezzo, le prestazioni salgono, 
d'altro canto credo che un qualcosa comune a tutto e tutti, che stia nel 
mezzo, non penso faccia male.


Il problema è che (a me) xscreensaver dopo un po' di opengl crasha la 
vga (ati vecchia) e anche se il pc funziona tranquillo devo resettare :-(
Per ora ho tolto opengl da xscreensaver ma mi piacerebbe saperne di più 
su quello che succede-


 client/server: altro che gatos e dri!
Qui c'e` l'errore: chi ha detto che "nel 90% dei casi non serve"?
Ma come, prima si dice che linux non e` su i desktop, e poi si dice che
il 90% della gente che ha linux e` single user e monta linux su desktop?
Perche` questo e` l'unico caso in cui "non serve".
Per tutte le altre cose, serve.
Del resto, se ci sono decine di progetti per replicare quello che X fa
nativamente, ci sara` un motivo. Mi riferisco a terminal server, vnc,
pcanyware, e via discorrendo...
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Don't use a big word where a diminutive one will suffice.

 mezzo, non penso faccia male.
E` un vantaggio ma vale solo in ambito opengl, ovvero applicazioni che
ne fanno uso. (giochi3d, celestia, robe cosi`).
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------


 pcanyware, e via discorrendo...
a be', nel mio piccolo, qua al lavoro ho un server con un 3-4 terminali
(ho usato ltsp )
se lo levano come faccio :D

>mezzo, non penso faccia male.
Ma OpenGL e` una cosa che sta nel mezzo comune a
tutto e tutti... :-)
bye,
-- 
   Piergiorgio Sartor

 pcanyware, e via discorrendo...
Il problema e` che X11 si fonda su quel concetto, non lo
ha come aggiunta accessoria.
L'idea, od i requisiti, erano quelli dei sistemi client
server, che prima giravano con VT100.
Pero` adesso un client vero e proprio non esiste ed il
vantaggio di avere il sistema X11 si riduce solo al
remote desktop saltuario, con aggravio sulla rete.
Considera che X11 e` inusabile da modem 56k (a meno di
artifici), il remote qualcosa diventa proprio inutile.
Il tutto andrebbe profondamente rivisto, proprio partendo
dai requisiti, che dovrebbero essere modernizzati.
bye,
-- 
   Piergiorgio Sartor

 
Che sia sui server ok, ma non tutti usano le possibilità client/server 
di X; la cosa ideale sarebbe poter scegliere se usare un X client/server 
oppure un X da desktop


 
Ovviamente da mie esperienze personali e dal fatto che la stragrande 
maggioranza dei quesiti che passano qui e su altre liste che leggo (è 
ovviamnte soggettivo) riguardano problemi di configurazione (di X) in 
ambito desktop


  artifici), il remote qualcosa diventa proprio inutile.
Si, ma per limitazione del canale AFAIK. VNC, per dire,
non mi risulta si comporti meglio


 non mi risulta si comporti meglio
Non ho mica detto che VNC sia meglio.
Pero` la possibilita` di collegarmi, chesso` dall'estero,
via modem, ad un server X11 ed usare il laptop come fossi
a casa non e` praticamente possibile.
Ed e` uno dei pochi casi di interesse reale.
Ne consegue che il progetto non e` piu` confacente le
necessita` di oggi.
Mentre PCanywhere mi risulta funzioni.
bye,
-- 
   Piergiorgio Sartor

  Mentre PCanywhere mi risulta funzioni.
Mai usato, non ne ho alcuna esperienza.


 ambito desktop
Be'... personalmente ritengo che le problematiche della configurazione 
riguardino piu che altro le opzioni che si possono settare, non si sa 
mai quante siano e ogni tanto ne imparo qualcuna di nuova...
(l'ultima collegando un touchscreen 3M seriale .... opzioni tutte sue, 
che figata xo' :D )
ad esempio, parlando di mouse, rimanendo sempre nel generico (ps2, 
microsoft, imps2...)si ricade magari nel settare opzioni che alcuni 
mouse non supportano... o tralasciarne alcune.
Come gia' esposto in precedenza ritengo che le problematiche di 
configurazione verrebbero abbondantemente decimate trasformando il file 
di config in un elenco di files da caricare.
E' pur vero che la differenza tra avere piccoli files e avere delle 
sezioni all'interno di un unico file e' minima, ma sono comunque 
convinto che sarebbe una gran cosa. Anche a livello di logs.
Poi dai, c'e' anche da dire che una buona parte pretende sempre la pappa 
pronta ;)
imho 8)

  convinto che sarebbe una gran cosa.
Non e` tanto minima: automatizzare del tutto o in parte le modifiche
ad un unico file centralizzato e` abbastanza rognoso, di solito,
avere un solo file con i default e/o le impostazioni generali
e tanti file-ttini di configurazione per aspetti specifici e` molto
meglio, sia per l'automatizzazione (e [auto]configurazione), sia
per la gestione.


 Mica tutti hanno bosogno di usare degli X terminal 


 un problema.
A mio avviso andrebbe rivisto il concetto client-server
in un ottica piu` locale.
Cioe` in locale, caso comune, dovrebbe esserci una via
diretta, con una "biforcazione" in caso di accesso remoto.
Invece di avere un sistema sempre client-server.
Tra l'altro, in un delle ultime release di XFree86, tra i
vari miglioramenti, citavano il fatto che la connessione
client-server, in locale, veniva fatta tramite memoria
condivisa invece di socket, per motivi prestazionali.
A mio avviso questo denuncia qualche problema alla base...
bye,
-- 
   Piergiorgio Sartor

  diretta, con una "biforcazione" in caso di accesso remoto.
Potrebbe essere interessante, a patto pero` che la soluzione
client-server sia comunque ben ingegnerizzata e non una pezza
messa li` cosi`, per compatibilita` e per ingrossare la feature
list.


 list.
Attualmente la situazione e` come se uno dovesse
montare, per es., sempre e comunque la /home/dir
tramite NFS, dato che cosi` si realizzerebbe il
funzionamento remoto tanto quanto quello locale.
Chiaramente una tale soluzione garantirebbe il
massimo della flessibilita`, ma ovviamente anche
un certo overhead non sempre giustificabile.
Quindi quello che si fa e` avere si lo share NFS,
ma solo in remoto, in locale si usa il disco direttamente.
A mio avviso X11 andrebbe rivisto in questo senso,
cioe` in remoto userebbe, se richiesto, un protocollo
di rete ed in locale un accesso piu` diretto.
bye,
-- 
   Piergiorgio Sartor

 io ho spesso 2 display, eppure ne faccio un uso desktop
<aol>
/me too.
</aol>
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
The linuX Files -- The Source is Out There.

 Temo di non aver capito. Avere piu display solo in caso di accesso remoto?
Non piu` display, avere la struttura client-server
_solo_ in caso di accesso remoto.
Vedi l'esempio NFS.
bye,
-- 
   Piergiorgio Sartor

 
Infatti.. anche perchè se metto un altro display in ufficio esco io.


 si ok, usi un solo display, punto.
Ma cosa c'entra uno o due o tre display con la
struttura client-server?
Se ho capito bene, quello di cui parli e` Xinerama,
o simili.
Oppure usi 2 PC con 2 display e devi avere un po'
di applicativi su un display ed un altro po' sullo
altro display, indipendentemente dal PC dove girano?
bye,
-- 
   Piergiorgio Sartor

 quindi in locale il numero di clienti è 1?
Lascia perdere il client-server.
In locale e` locale. Punto.
Non esiste(rebbe) il concetto di client.
Posso avere, in locale, "n" volte una stessa
home dir, senza usare NFS, ma semplici link.
Quindi, in locale, non mi serve un client ed
un server, mi serve solo un "artificio" (come
il link per il FS), nel caso voglia avere
istanze multiple.
bye,
-- 
   Piergiorgio Sartor

 lavorare con la shell.
Se i display mostrano lo stesso desktop, la cosa si
realizza semplicemente a livello di driver (su di una
stessa macchina).
Cioe` il driver propone un display di, per esempio,
2048x768, che viene diviso tra due monitor, 1024x768.
Oppure e` un altro caso?
bye,
-- 
   Piergiorgio Sartor

 Cioe`?
ci provo...
xnest ?
:)

 xnest ?
Non mi interessa un nome, un caso d'uso.
bye,
-- 
   Piergiorgio Sartor

 Non mi interessa un nome, un caso d'uso.
Cioe` mi interessa sapere quale utilizzo _locale_
necessiterebbe senza appello una struttura come
quella di X11, cioe` client e server.
Per utilizzo intendo proprio qualcosa che si utilizza,
cioe` qualcosa di cui non si puo` fare a meno.
bye,
-- 
   Piergiorgio Sartor

 quella di X11, cioe` client e server.
Ho un applicazione che necessita di girare 24/7, e _purtroppo_ non ha
una modalita` demone o console. Solo grafica.
La macchina su cui gira, e` multiutente. Ho bisogno di due istanze di x,
una ad hoc per l'applicativo, uno per l'uso consueto degli utenti.
E infatti cosi` faccio.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Vote Cthulhu. Why choose the lesser evil?

 E infatti cosi` faccio.
Si, ma questo non giustifica la necessita` di un client ed
un server, bensi` la necessita` di istanze multiple di un
window manager.
Il che, in un qualche modo, si realizzava con Amiga, avendo
gli screen multipli.
Solo che Amiga non aveva la separazione fra utenti, dato che
non aveva utenti...
bye,
-- 
   Piergiorgio Sartor

 non aveva utenti...
Appunto. La parte "utenti" e` altrettanto importante.


 Appunto. La parte "utenti" e` altrettanto importante.
Ma non c'entra nulla con il client e server.
Non e` che il FS necessiti di una strutta CS per
gestire gli utenti.
E` chiaro che ci sono casi in cui la struttura CS,
pur essendo non necessaria, e` auspicabile.
Pero` nello specifico, pur armonizzando la struttura
complessiva, rappresenta piu` un problema che una
soluzione, in primis per le prestazioni, ma non solo.
bye,
-- 
   Piergiorgio Sartor

 soluzione, in primis per le prestazioni, ma non solo.
Tu poche righe prima scrivevi:
"Non mi interessa un nome, un caso d'uso.".
Senza affatto dare l'impressione che voglia insistere, hai una soluzione
per la necessita`, nemmeno troppo remota, che ti ho esposto?
Perche` dalle 5 righe sopra, non si desume, o almeno, io non ce la
leggo.
Ovviamente, "altri utenti" non devono manipolare l'applicazione (e` un
monitor).
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
In God we trust. (All others pay cash.)

 monitor).
Qui mi ricollego a sopra.
Tu hai una macchina che deve funzionare 24/7, con uno
specifico applicativo, ed e` anche multiutente in console?
Non ti sempre un po' azzardato?
bye,
-- 
   Piergiorgio Sartor

 Non ti sempre un po' azzardato?
Affatto. 
Ci sono dei motivi funzionali e accessi con credenziali. Non e` una
macchina "per utenti", e le applicazioni 24/7 solo grafiche, in giro,
sono piu` di quanto non possa a prima vista sembrare.


 sono piu` di quanto non possa a prima vista sembrare.
Non metto in dubbio, mi pare strano che una macchina
24/7 sia multiutente in _console_.
Cioe` 24/7 (con o senza grafica) e multiutenza in
console non mi pare siano due cose da tenere assieme.
Comunque ci saranno sicuramente dei buoni motivi.
bye,
-- 
piergiorgio

 e allora se non c'è non si discute. :)
La discussione e` sui pro o contro di X11, non sulle
alternative ad X11.
bye,
-- 
piergiorgio

 eh, ma neanche per sogno, apro un altro display.
E questo, ancora, cosa c'entra con client-server?
Secondo te quello si puo` realizzare solo CS?
Che vantaggio ha realizzare questo con CS?
Stai confondendo feature con architettura.
bye,
-- 
piergiorgio

 fa proprio.
???
bye,
-- 
piergiorgio

 console non mi pare siano due cose da tenere assieme.
Il 24/7 e` legato all'applicazione.
La multiutenza e` legato alla macchina.
Averci altre dieci macchine si risolvono diversi problemi, eppero`...
Per la cronaca, una situazione analoga, anche se molto piu` semplice
l'ho a casa, con mia moglie che fa login sulla mia macchina (24/7 per
comodita`, piu` che per esigenza) e bidwatch in istanza a parte, per
ebay-related.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Lusers: can't live with them, don't get paid without them.

 ebay-related.
Beh, questo e` un use-case, a mio avviso, molto ragionevole.
Ma, ripeto, il problema non e` lo use-case, ma come X11 lo
realizza. Cioe` non e` che avere screen multipli sia da evitare,
anzi, bensi` il fatto che la struttura sotto, che X11 usa per
funzionare (e fornire anche quel tipo di servizi), non consenta
di realizzare altrettanto bene altri use-case molto piu` critici.
bye,
-- 
piergiorgio

 Allora spiegami che evidentemente non ho capito.
La feature (in questo esempio) e` poter user piu` "screen"
(non li chiamo display perche` mi confondo con "display LCD,
plasma, etc.).
L'architettura e` il design client-server che X11 ha.
La critica che sto facendo e` sull'architettura.
In origine furono raccolte le feature che interessavano e
su queste fu costruita l'architettura.
A parte certi errori concettuali di design, le feature sulle
quali X11 basa la sua architettura sono obsolete e nuove
feature sono diventate fondamentali.
Purtroppo l'attuale architettura non consente agevolmente
di aggiungere queste nuove e fondamentali feature.
Ne consegue che _sarebbe_ meglio rifare X11 in maniera di
dare priorita` a feature come bassa latenza, tempi di
presentazione affidabili, sia in locale (fondamentale) che
in remoto (multimedia, network game), etc.
Il caso degli screen multipli su singola macchina non e` da
ignorare, ma resta un caso secondario rispetto ad altre
priorita`, sicuramente basilari in un PC _moderno_.
bye,
-- 
piergiorgio

 che faccio oggi varrebbe meno di zero, IMHO.
OK, ma questo e` un problema di feature.
Chiaramente sarebbe auspicabile mantenere _tutte_ le
feature che ci sono oggi.
bye,
-- 
piergiorgio

 secondo me no, rispetto un pc casalingo, non necessariamente moderno.
No, rispetto all'uso medio di un PC moderno.
Se devo fare un compromesso lo faro` sugli screen multipli,
non sulla latenza.
Nel improbabile caso si dovesse scegliere, senza alcun dubbio,
considerando l'uso universale che si vuole avere, la latenza
sarebbe da scegliere.
Che poi tale scelta non si pone in questi termini, bensi` in
cosa e dove si vuole "complicare" la struttura di X11.
Al momento e` complicata per la latenza (impossibile) e semplice
per gli screen multipli, sarebbe meglio fosse il contrario,
qualora non sia possibile avere semplicita` in entrambi i casi.
bye,
-- 
piergiorgio

 sicuro?
Relativamente al contesto locale si.
Che poi la cosa possa essere piu` complicata in altri casi,
potrebbe essere, ma si devono sempre fare compromessi,
possibilmente giusti... :-)
bye,
-- 
piergiorgio

 Spiegami come. Usando WM diversi e pure DE diversi.
Diciamo che ti tolgo la possibilita` di usare WM diversi... :-)
Scherzi a parte, devi definire esattamente i requisiti e
poi si vede come realizzarli.
Non e` mica necessario usare i socket per realizzare la
comunicazione fra processi, cosi` come non e` necessario
avere piu` processi per realizzare due compiti.
Puo` essere che sia piu` conveniente, ma non necessario.
bye,
-- 
piergiorgio

 dato da dove esce?
Quale, il 60%?
Ci sono studi in giro, che vengono usati, per esempio, dai
costruttori di CPU e di schede video per ottimizzare i loro
prodotti.
Il problema e` che, sempre per esempio, avendo la bassa
latenza puoi fare i giochi, non avendola no.
Mentre le applicazioni office funzioneranno comunque.
Il problema dei tempi di prensentazione e` critico per le
applicazioni multimediali. Guarda caso una parte notevole
degli sforzi di chi fa CPU e schede video gira attorno a
questo, altrimenti perche` avremmo le "istruzioni multimediali"
e i vari decoder MPEG HW o color space conversion in HW, etc.
E` chiaro che una quantita` notevole di sforzi va in quella
direzione, ignorare la cosa e` da pazzi.
Motivo per cui abbiamo OpenGL che salta X11 e va direttamente
in HW, oppure le estensioni XV (quando supportate in HW).
bye,
-- 
piergiorgio

 ad un unico file centralizzato e` abbastanza rognoso, di solito,
]zac[
Mi aggancio qui per comodità, per non scrivere venti post di risposta.
Su XF86Config ho prodotto un bel pò di bile quando ho cercato di gestirlo
per un mio progetto.
- XF86Config ha una struttura che è difficilissima da essere modificata in
automatico, fai prima a generarlo sempre tutto da zero (che se non sbaglio
è il sistema usato dalla debian).
- XF86Config ha pesanti ed inutili incorenza nella navigazione tra gruppi e
sottogruppi e chiavi/valori, il che rende praticamente impossibile ad uno
script la lettura o la modifica del file, e numerose difficoltà di gestione
ad un programma vero e proprio.
- XF86Config consente chiavi con valori composti nelle maniere più contorte 
possibile (non si limita a chiave più valore o simili).
- X è estremamente ed inutilmente rigido nella sintassi quando
legge il file XF86Config, se un valore prevede "10" e gli metti 10 da
errore e X non si avvia (ci sono valori che devono essere esattamente tipo
"10" 1 "3" R e basta) e solo leggendo la documentazione di una opzione puoi
sapere qual'è la 'cornice' giusta del valore.
- In linux c'è la tendenza di passare da sistemi esageratamente
semplicissimi (cento file con un solo valore) a sistemi stile 'obice da 100
per accoppare una mosca' (XML, file astrusi come sintassi (da intendersi
come di difficile navigazione/modifica da un parte di un sistema non
flessibile come un essere umano) come XF86Config, i file di configurazione
di apache).
Per il resto:
- X è stato riscritto pesantemente, da vari anni il collo di bottiglia non è
il suo sistema client/server, la parte più lenta sta nei desktop manager e
in alcune scelte di fondo (tipo far girare il meno possibile programmi nel
kernel, dare priorità alla sicurezza rispetto alla facilità di
comunicazione fra i programmi), X è da vario tempo modulare.
- Il margine di miglioramento di velocità di qualsiasi cosa sostituisca X è
veramente ridotto (empiricamente diciamo un 10%).
- La mancanza della possibilità di configurare X al volo dipende molto
probabilmente dal fatto che poi le varie applicazioni già attive dovrebbero
adattarsi alle nuove impostazioni (cosa che è probabile che non sia stata
prevista/implementata visto che è parecchio complessa e fonte di problemi).
Tutto il resto ha grossi margini di sviluppo, però è una questione di
organizzazione, di gestione dello sviluppo del progetto, non di voler o non
voler innovare, è lo 'stile' di gestione del progetto che è vecchio e che
ha bisogno di essere  rivoluzionato, non X.
Se il fork attuale porta una organizzaione stile kde (solo per esempio) c'è
tutto da guadagnarci.

  applicazioni multimediali.
A questo proposito, un dubbio in merito:
Attualmente X gestisce solo l'hardware _video_. Un "better X"
ottimizzato per la latenza, o comunque per il multimedia,
dovrebbe comunque gestire _solo_ il video, creando comunque
cosi` problemi ad un player multimediale, no?
In altre parole, fermo restando che ottimizzare per il caso
critico (multimedia) dovrebbe essere una delle priorita`,
per risolvere degnamente il problema il "better X" dovrebbe
comunque gestire _anche_ l'aspetto sonoro, no?
Non sarebbe piu` pensabile avere sia esd sia arts sia nas,
per dire, dovrebbe esserci un unico "x sound server" di 
riferimento, giusto?
-- 
Francesco Romani - Ikitt   (signature under [re]construction)
'A geek is someone who spends time being "social" on a computer.'
'In fact, users don't read /anything/'                         -- Joel Spolsky

  ha bisogno di essere  rivoluzionato, non X.
Questo appunto e` quello che, AFAIK, stanno cercando di fare con 
x.org/fd.org
.


 riferimento, giusto?
Vedi sopra.
Comunque non sarebbe necessario, a meno di non pensare di avere il sistema
operativo integrato con la grafica, il sonoro, e tutto il resto (che
strano, mi viene un ... win), ma questo vorrebbe dire ribaltare
completamente linux, e oltre a sperare caldamente che non succeda mai, non
lo vedo proprio fattibile.
A naso si potrebbe avere qualche incremento significativo solo se fossero
direttamente i desktop manager a gestire il 'DRI' (inteso come gestione
dell'accesso diretto alle risorse), similare a quello che stanno facendo
per il disegno dei font, solo con grossi problemi di stabilità,
compatibilità, riscritture di grosse parte delle applicazioni.

 priorita`, sicuramente basilari in un PC _moderno_.
_DESKTOP_. Che e` economicamente, il mercato _meno_ redditizio e
interessante di tutti.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
And on the seventh day, He exited from append mode.

 Questo appunto e` quello che, AFAIK, stanno cercando di fare con 
x.org/fd.org
.
E speriamo che ci riescano presto perche' mi pare che siamo arrivati ad 
un punto abbastanza critico.
8)

  completamente linux,
Appunto, e` quel che pensavo/temevo e mi domandavo come fosse possibile 
da attuarsi senza stravolgere la struttura attuale.


 cosi` problemi ad un player multimediale, no?
Ottimo ragionamento, davvero.
Non volevo scendere nel dettaglio, ma visto che mi ci costringi... :-)
Tipicamente il problema e` la sincronizzazione audio/video.
Quello che di solito si fa e` far andare l'audio come deve
andare, cioe` alla sua velocita`, senza cambiare la frequenza.
Il motivo e` che un cambiamento sonoro si sente parecchio.
Il video viene "controllato" (indirettamente) dalla parte audio.
Nel dettaglio, ci sara` uno stream di pacchetti audio ed uno
di pacchetti video (questi tipicamente sono frame).
Ogni pacchetto avra` un presentation timestamp.
I pacchetti audio saranno "master", nel senso che tutta la
base dei tempi verra` ricavata da questi, i pacchetti video
saranno "slave", cioe` dipenderanno da quelli audio.
Al sistema di presentazione video e` richiesto di visualizzare
i frame secondo scadenze ben precise (derivate dall'audio) e di
ripetere o saltare i frame in modo da mantenere la sincronizzazione.
Non e` necessario che la parte audio e video siano gestite
assieme, ma e` necessario che siano controllabili da un terzo
SW, tipicamente il player multimediale, che dara` il "tempo"
alle varie sezioni in modo da mantenere la sincronizzazione.
Attualmente i player si affidano all'overlay ed alle prestazioni
della macchina e, con diversi artifici, riescono piu` o meno a
mantenere il sync decentemente.
La soluzione, pero`, non e` certo ottimale e denota un limite
serio del sottosistema grafico, almeno per questo use case.
Ovviamente uno potrebbe concepire un sottosistema multimediale
ed integrare, in qualche modo, audio e video in un unico blocco.
In genere, pero`, non si segue questa strada, per altre ragioni.
bye,
-- 
piergiorgio

 interessante di tutti.
E` il mercato piu` vasto, non e` certo il meno redditizio,
ne` il meno interessante.
No, un PC moderno, non necessariamente desktop, potrebbe
essere un videogioco od un settop box.
Guarda caso nei STB si usano alternative ad X11, che si
basano sul framebuffer.
bye,
-- 
piergiorgio

 la situazione).
Ma non e` affatto vero.
Secondo te perche` si usa OpenGL?
Non e` un'astrazione anche quella?
Mica e` un accesso diretto all'HW, almeno per il programmatore.
bye,
-- 
piergiorgio

 da attuarsi senza stravolgere la struttura attuale.
Facendo come le directx forse .... quando una applicazione vuole il massimo
delle prestazioni prende il controllo esclusivo e diretto dell'hardware
video/audio, X si limita a fare da semaforo.
Peccato che richieda comunque la modifica di tutte le applicazioni che ne
hanno bisogno e senza contare la necessità di scrittura di nuovi driver
video/audio e la mancanza della conoscenza dei dettagli delle varie schede.