gildot

Topo
Sobre
FAQ
Tópicos
Autores
Preferências
Artigos
Sondagens
Propor artigo


8/3
gildicas
9/30
jobs
10/9
perguntas
10/25
press

 
Instalar Xfree 4.0.2 (e relacionados)
Contribuído por chbm em 29-12-00 18:14
do departamento make:-out-of-memory
X O cgd escreveu um HOWTO para compilar, instalar e por a funcionar o XFree86 4.0.2. Segue no desenvolvimento.
cgd escreve "

fazer o setup de xfree 4.0.2 a partir das sources

1. obter as sources (mirror no tux.cprm.net)

existem os seguintes ficheiros FILES README SUMS.md5 SUMS.md5sum X402src-1.tgz X402src-2.tgz X402src-3.tgz doctools-1.2.tgz

sacar apenas o SUMS.md5sum X402src-1.tgz X402src-2.tgz

o resto nao é necessario (mesmo o src-2 (fontes), tb nao é estritamente necessario)

verificar se o download correu bem:

$ grep src-\[12\] SUMS.md5sum | md5sum -c -

o doctools é um pacote externo ao xfree, mas usado por eles para formatarem a documentacao, pode ser sacado e instalado à parte, mas nao é importante para o xfree em si

o X402src-3 sao os docs em postscript, que podem ser refeitos a partir do X402src-1 (embora em linux isso dê algum trabalho extra), seja como for, nao interessam muito na maior parte dos casos

2. descompactar

$ tar zxf X402src-1.tgz $ tar zxf X402src-2.tgz

é criada uma subdir "xc" no directorio corrente.

esse directorio vai ter cerca de 240MB, com os cerca de 40MB dos dois TARs, mais cerca de 140MB de ficheiros intermedios de compilacao, dá um total de 420MB de espaco em disco necessario para fazer a compilacao (ou 380 se se apagarem os TARs depois de serem descompactados)

a compilacao total demora cerca de 1 hora e 10 min num pentium III (para portatil) a 600Mhz.

3. compilar

para se fazer a compilacao a partir das sources, basta executar um "make World" a partir da raiz

$ cd xc $ make World

mas calma! Neste directorio, vao haver os seguintes subdirs: (a seguinte seccao é apenas de descricao)

config cf dados sobre configuracoes imake utilitario para gerar Makefiles a partir de Imakefiles makedepend gerar dependencias de C code

o imake tenta autodetectar algumas coisas: . o SO que esta a correr (eu: linux) . a libc que se esta a usar (eu: 2.2) . a distribuicao que se está a correr (eu: +/- redhat) basicamente, apenas vê se existe algum destes ficheiros (imake.c:952)

/sbin/YaST suse
/etc/redhat-release redhat
/etc/debian_version debian

por isso, caso haja problemas na compilacao, basta fazer um $ touch /etc/redhat-release para enganar o imake

doc documentacao: interessa especialmetne o man e o misc

exports usado durante o make, para colocar bibliotecas, includes, etc... necessarios a contrucao do xfree todo extras algum 3rd party software. é todo tratado automaticamente excepto o que está na subdir "freetype2"

fonts, include, lib, nls, programs, util ...

Dentro da subdir "extras" o "freetype2" nao é tratado automaticamente pelo "make World".

Essa bibliteca, é usada para dar mais suporte a mais fontes à extensao RENDER .

Para se usa-la, tem que se a compilar à parte:

$ cd extras/freetype2 $ make setup $ make $ make install $ ldconfig

E dizer ao sistema de "make"s que temos essa biblioteca no nosso sistema: $ cd ../.. $ echo "#define Freetype2Dir /usr/local" > config/cf/host.def

Depois entao, fazer: $ make World

e esperar.

4. Algumas notas antes da instalacao do XF402

Esta versao Xfree4.0.2 corrige alguns problemas (como o do xmessage nao mostrar a mensagem, sem ter que ser "resize"d primeiro), mas vem com o xterm com alguns defeitos (ver abaixo)

O "xset r rate " finalmente funciona bem (extensao XKB), por isso, para aqueles desgracados que, como eu, tinham "xset r rate 1 255" na iniciacao do X, se comecarem a ver caracteres a saltar por toda a parte, aumentem/reduzam os valores, respectivamente.

Eu uso isto no meu ".xinitrc" :

xset r rate 220 80

e parece-me porreiro. (220ms antes de as teclas comecarem a repetir-se, 80 caracteres por segundo, depois de terem comecado)

Ler com muita antencao o ficheiro: programs/Xserver/hw/xfree86/doc/README.xxx

referente à placa de video do sistema.

Para saber qual o "xxx" a usar para casa placa, ver o RELNOTES (na raiz da distribuicao descompactada), linha 294.

O XF86Config das versao 4.0.x anteriores em principio funciona sem alteracoes, mas podem haver ligeiras alteracoes nos drivers que causem alteracoes.

Por exemplo, no meu caso, tenho um ATI RAGE (qq coisa), e o meu driver é o "ati".

Quando liguei ao monitor, o X nao arrancava (mas no LCD do portatil funcionava).

Acontece que quem fez o driver, modificou o comportamento para quando o driver detectar LCD **e** CRT, tentar usar os dois.

No meu caso, bastou adicionar na seccao do monitor CRT, a linha: Option "crt_screen" e funcionou tudo ok

5. instalar

usar este comando, para deixar uma copia dp que ira ser posto no sistema, sob a directoria "zz":

$ make install install.man DESTDIR=`pwd`/zz

ou colocar directamente no sistema:

$ make install install.man

esta dist instala menos ficheiros que a anterior (pareceu-me)

alguns cleanups que eu fiz apos a instalacao (a minha instalacao foi limpa, dado que limpei todo o X que tinha):

$ cd /usr/X11R6/lib/X11/doc $ rm -rf html [o html é gerado a partir dos mans, e dos txts em ".." nao é necessario e ocupa espaco]

$ apagar os symlinks que sao metidos em /usr/lib e /usr/include ( /usr/lib/libGL.so* e /usr/include/GL ) [nao sao precisos, porque o /usr/X11R6/include é usado nas compilacoes com o -I, e em relacao à lib, o path "/usr/X11R6/lib", deve estar em /etc/ld.so.conf

$ cd /usr/X11R6/man $ find . -type f ! -name \*gz -size +1k | xargs gzip [isto pode ser feito em todos os man dirs]

$ cd /usr/X11R6/lib $ strip -gx *.a && ranlib *.a $ strip *.so

$ cd /usr/X11R6/bin $ file -L * | grep -w -e 'executable' | grep 'not strip' | cut -d: -f1 | xargs -r strip

[eu fiz tudo isto numa dir separada, usando o truque do DESTDIR de cima, e depois espalhei symlinks pelo sistema, usando o stow da GNU]

uma instalacao assim, vai ocupar cerca de 63MB, o que nem é muito

6. XTERM

o xterm que vem neste Xf4.0.2 dá alguns problemas, especialmente a quem usa bold (i.e. uma fonte para produzir bolds), e que o xterm nao reconheca a bold correspondente à fonte que usamos

por exemplo: eu uso a fonte 8x13, o meu bold vai usar a 8x13bold o xterm que vem na dist nao gera bolds (nem underlines), com estas fontes

sacar a versao mais recente em :

página

compilar usando o ./configure

$ ./configure --disable-tek4014 --disable-vt52 [eu fiz estes disables, porque nao preciso deles, e causam a reduccao do xterm em cerca de 250K de memoria que ocupa]

$ make install prefix=`pwd`/zz

e fazer o overwrite dos ficheiros no sistema, com os que ficaram sob "zz"

alternativamente, pode-se colocar este xterm em "xc/programs/xterm" (apagar o que la esta antes), e proceder com normalmente com o "make World"

7. Notas gerais sobre o xterm

. quando se usa o less, ou vi[m], ou [...] o ecran fica todo preto

este tipo de programas, usam as termcap entries "ti" e "te" (terminfo: "smcup" e "rmcup"), para trocar entre o visor alternativo e o normal.

solucoes: (1) apagar as entradas ti=... e te=... do /etc/termcap *e* apagar as smcup=.. e rmcup=... do terminfo: $ infocmp > /tmp/xx $ vi /tmp/xx [apagar smcup=... ] $ tic /tmp/xx

(2) fazer um hack para a termcap (eu tenho isto como alias)

eval "`resize -c | \ sed -e s/\\!/\\\\\\!/g -e s/t[ie]=[^:]*::*//"

funciona para a [t]csh

(3) Resource do XTERM:

adicionar em ~/.Xdefaults ou ~/.Xresources o seguinte:

XTerm*titeInhibit: True

. programas graficos em modo texto nao funcionam (ex: mc; cd /usr/src/linux && make menuconfig) especificar as cores no ~/.Xdefaults:

 XTerm*VT100*color0: black XTerm*VT100*color1: red3 XTerm*VT100*color2: green3 XTerm*VT100*color3: yellow3 XTerm*VT100*color4: blue3 XTerm*VT100*color5: magenta3 XTerm*VT100*color6: cyan3 XTerm*VT100*color7: gray90 XTerm*VT100*color8: gray30 XTerm*VT100*color9: red XTerm*VT100*color10: green XTerm*VT100*color11: yellow XTerm*VT100*color12: blue XTerm*VT100*color13: magenta XTerm*VT100*color14: cyan XTerm*VT100*color15: white 
8. Os meus resources para XTERM

no ficheiro ~/.Xdefaults:

 --- #ifdef COLOR *customization: -color #else *customization: -bw #endif XTerm*Font: 8x13 #ifdef CSET1 XTerm*Background: DarkSlateBlue XTerm*cursorColor: yellow XTerm*pointerColor: yellow XTerm*Foreground: yellow XTerm*BorderColor: yellow #endif #ifdef CSET2 XTerm*Background: black XTerm*cursorColor: green XTerm*pointerColor: green XTerm*Foreground: green XTerm*BorderColor: green #endif #ifndef COLOR XTerm*Background: black XTerm*cursorColor: DarkSlateGrey XTerm*pointerColor: DarkSlateGrey XTerm*Foreground: WhiteSmoke XTerm*BorderColor: WhiteSmoke #endif XTerm*ttyModes: erase ^h kill ^u intr ^c quit ^\ eof ^d \ susp ^z start ^q stop ^s eol ^@ dsusp ^y XTerm*autoWrap: true XTerm*cutNewline: true XTerm*cutToBeginningOfLine: true !XTerm*charClass: 33:48,37:48,45-47:48,64:48 #ifdef COLOR Xterm*colorMode: on XTerm*dynamicColors: on XTerm*VT100*color0: black XTerm*VT100*color1: red3 XTerm*VT100*color2: green3 XTerm*VT100*color3: yellow3 XTerm*VT100*color4: blue3 XTerm*VT100*color5: magenta3 XTerm*VT100*color6: cyan3 XTerm*VT100*color7: gray90 XTerm*VT100*color8: gray30 XTerm*VT100*color9: red XTerm*VT100*color10: green XTerm*VT100*color11: yellow XTerm*VT100*color12: blue XTerm*VT100*color13: magenta XTerm*VT100*color14: cyan XTerm*VT100*color15: white #endif #if defined(COLOR) && defined(BOLD_COLOR) XTerm*colorBDMode: on XTerm*colorBD: blue #else XTerm*colorBDMode: off #endif #if defined(COLOR) && defined(UNDERLINE_COLOR) XTerm*colorULMode: on XTerm*colorUL: magenta XTerm*underLine: off #else XTerm*colorULMode: off XTerm*underLine: on #endif XTerm*eightBitInput: false XTerm*eightBitOutput: true XTerm*jumpScroll: on XTerm*loginShell: on XTerm*reverseWrap: on XTerm*saveLines: 512 XTerm*scrollBar: on XTerm*scrollKey: on XTerm*titeInhibit: True --- 

é usado, a partir do ~/.xsession ou ~/.xinitrc (conforme o X seja lancado por xdm,gdm (etc) ou startx, respectivamente):

cd $HOME
xrdb -DCSET2 -merge .Xdefaults

"

Netscape 6 Desilude | TV-OUT em Linux - é possível?  >

 

gildot Login
Login:

Password:

Referências
  • Linux
  • Debian
  • Red Hat
  • cgd
  • mirror no tux.cprm.net
  • página
  • cgd
  • Mais acerca X
  • Também por chbm
  • Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário.
    E ja' agora, Xfree sobre uma G400Max-DualHead (Pontos:1)
    por xeon em 29-12-00 19:15 GMT (#1)
    (Utilizador Info) http://pthelp.org
    Ja' agora, aqui vai o meu XFConfig-4 para a G400Max Dual-Head (para quem quer xinerama ...).

    Note-se que os meus monitores sao Compaq V55. Ha' que substituir as entradas correspondentes pelas dos _seus_ monitores.

    A configuracao do rato e' para um Compaq com scroll-wheel.

    IMPORTANTE: O driver para a Matrox que acompanha o XFree 4.0.2 NAO SUPORTA dual-head.
    Para suportar DH, e' necessario fazer download do mais recente driver de http://www.matrox.com/mga

    Como nota final, procurar no "startx" a linha:
            xinit $clientargs -- $serverargs
    (deve ser a ultima linha...) e substituir por:
            xinit $clientargs -- $serverargs +xinerama

    Posto isto, ca' vai:

    --------------cut here---------------
            Section "ServerLayout"
                Identifier "TS 2000-08-21"
                Screen 0 "Screen1" LeftOf "Screen2"
                Screen 1 "Screen2"
                InputDevice "Mouse0" "CorePointer"
                InputDevice "Keyboard0" "CoreKeyboard"
            EndSection

            Section "Files"
                    EndSection

                    Section "Module"
                        Load "pex5"
                        #Load "dri"
                        Load "GLcore"
                        Load "record"
                        Load "glx"
                        Load "extmod"
                        Load "dbe"
                        Load "xie"
            EndSection

                    Section "InputDevice"
                Identifier "Keyboard0"
                        Driver "keyboard"
                Option "XkbLayout" "pt"
                    EndSection

              Section "InputDevice"
                    Identifier "Mouse0"
                    Driver "mouse"
                    Option "Protocol" "IMPS/2"
                    Option "Device" "/dev/mouse"
                    Option "Buttons" "5"
                    Option "ZAxisMapping" "4 5"
              EndSection

              Section "Monitor"
                    Identifier "MON1"
                    VendorName "CPQ"
                    ModelName "1331"
                    HorizSync 30.0 - 60.0
                    VertRefresh 48.0 - 125.0
                    EndSection

                    Section "Monitor"
                    Identifier "MON2"
                    VendorName "CPQ"
                    ModelName "1331"
                    HorizSync 30.0 - 60.0
                    VertRefresh 48.0 - 125.0
                    EndSection
                    Section "Device"
                    Identifier "G400_1"
                    Driver "mga"
                    BoardName "MGA G400 AGP"
                    BusID "PCI:1:0:0"
                    Screen 0
              EndSection

                    Section "Device"
                    Identifier "G400_2"
                    Driver "mga"
                    BoardName "MGA G400 AGP"
                    BusID "PCI:1:0:0"
                    Screen 1
                    EndSection

                    Section "Screen"
                    Identifier "Screen1"
                    Device "G400_1"
                    Monitor "MON2"
                    DefaultDepth 16
                    SubSection "Display"
                    Depth 16
                    Modes "1024x768"
                    ViewPort 0 0
              EndSubSection
                    EndSection

              Section "Screen"
          Identifier "Screen2"
                    Device "G400_2"
                    Monitor "MON1"
                    DefaultDepth 16
              SubSection "Display"
                    Depth 16
                    ViewPort 0 0
              Modes "1024x768"
                    EndSubSection
                    EndSection

                    #Section "DRI"
                    #EndSection


    Howto Alternativo (Pontos:2)
    por fog em 29-12-00 19:43 GMT (#2)
    (Utilizador Info) http://www.fog.nu/
    Ou então podem fazer como eu (RedHat 6.2 ;)

    rpm --rebuild ftp://rawhide.redhat.com/pub/rawhide/SRPMS/SRPMS/XFree86-4.0.2-0.1.src.rpm

    rpm -Uvh /usr/src/redhat/RPMS/i386/XFree86*
    Re:Howto Alternativo (Pontos:1)
    por _Mordor_ em 29-12-00 22:30 GMT (#3)
    (Utilizador Info) http://www.plug.pt/
    Exactamente!

    Não sei porque, mas encontro tanto pessoal compilaholics. São howtos destes complicados que em vez de ajudar, só transmitem a ideia que o Linux é um bicho de 7 cabeças. Não é preciso compilar quase nada em Linux. Só pessoas que não tem mais nada que fazer ou porque têm um necessidade muito especial é que o fazem.

    Instalar programas em Linux é tão fácil (ou mais) que em Windows.
    Re:Howto Alternativo (Pontos:1)
    por MacLeod em 29-12-00 22:46 GMT (#4)
    (Utilizador Info)
    Instalar programas em Linux é tão fácil (ou mais) que em Windows.

    Também não abusemos. É verdade que com o RPM as coisas se simplificaram imenso, mas o que é que dá mais trabalho, é escrever rpm (...) ou clicar umas quantas vezes seguidas com o rato? ;)

    E quanto ao compilar, não concordo muito com o que dizes. Há também outras pessoas que compilam, pois deves saber que as coisas compiladas na tua máquina naturalmente correm mais rápido pois foram compiladas de acordo com as especificidades da *tua* máquina. Essa é uma das razões porque o linux é tão eficiente.

    Re:Howto Alternativo (Pontos:1)
    por Strange em 30-12-00 1:33 GMT (#6)
    (Utilizador Info)

    Normalmente não.

    Ora vejamos, qual é a diferença entre usar um pacote compilado para o rh 7.0 e compilar o programa a partir da source num rh 7.0? O kernel é o mesmo, e mesmo que não fosse, não altera a compilação de programas (com as devidas excepções); as bibliotecas são as mesmas; o compilador é o mesmo....

    É claro que se compilares por ti próprio, tens a vantagem de poder remover ou adicionar características ao programa na configuração, definir as optimizações no compilador, etc. Mas são coisas que também são feitas quando se criam os pacotes RPM.

    No entanto, eu também prefiro compilar o software por mim próprio. Principalmente porque não gosto de esperar pelos updates oficiais da RedHat ou de outros e busco logo as últimas versões dos programas. E depois, porque confio mais em mim próprio a compilar os programas do que os programas já compilados por desconhecidos.

    hugs

    Luciano Rocha


    A diferença principal (Pontos:0)
    por Anonimo Cobarde em 30-12-00 2:19 GMT (#7)
    é teres a maior parte dos programas não optimizados para 686, ie, compilados para i386. Se achas que isso não faz diferença é lá contigo.
    Re:A diferença principal (Pontos:1)
    por _Mordor_ em 30-12-00 6:11 GMT (#9)
    (Utilizador Info) http://www.plug.pt/
    Faz uma experiencia. Compila dois src.rpm para 386 e outro para 686 e ve a diferenca de performance. Sera' assim tao significativo que valha a pena o trabalho? Naaaa.

    E tens sempre o Mandrake, optimizado para 586. Embora eu nao note diferenca de performance. Experiemnta o apache. Usa o ab para testares e posta aqui os resultados
    Re:A diferença principal (Pontos:0)
    por Anonimo Cobarde em 30-12-00 19:50 GMT (#14)
    Epá tal e qual, eu sinceramente não noto grandes diferenças, nunca fiz testes rigorosos nem nada é verdade.
    De facto não noto nada de espantoso... Mas pronto também gosto sempre de compilar as cenas é verdade... talvez seja mais uma mania do que outra coisa qualquer...
    Re:A diferença principal (Pontos:2)
    por Gamito em 30-12-00 20:08 GMT (#15)
    (Utilizador Info)
    Oi!

    Ainda há dias falávamos ao almoço acerca disto.
    Eu continuo na minha: gosto de compilar os programas, pois posso definir as coisas como gosto, pôr as libs onde quero, etc. e de um modo geral estar a par de tudo o que está a acontecer.

    Também concordo que de um ponto de vista filosófico, não convém dizer aos recém-chegados ao Linux que isso de compilar não tem interesse, pois acho que é muito bom o pessoal entender que é aí precisamente que reside grande parte da difererença entre o Open Source e o software proprietário.

    Admito que para quem tenha muitas máquinas em mãoes, os rpms possam dar jeito, though.

    Cumprimentos,
    Mário
    Re:A diferença principal (Pontos:1)
    por L0ngshot em 30-12-00 17:11 GMT (#11)
    (Utilizador Info)
    Exactamente! Uma das maiores vantagens de se dispor da source dum programa é que temos a hipotese de optimizar a compilação para o nosso processador.
    Parece-vos pouco? Dêem uma olhada a este link.
    Neste artigo discute-se a maravilha que é o Pentium 4, havendo um parte muito pertinente para a presente discussão:
    How many people still run Microsoft Office 95? Ok, do a DUMPBIN on WINWORD.EXE or EXCEL.EXE to get the version number of the compiler tools. That product was written in an old version of Visual C++ which targets now obsolete 486 processors. Do the same thing with Office 97 or Office 2000. Newer tools that target P6. Wonder why your Office 97 runs faster than your Office 95 on the same Pentium III computer? Ditto for Windows 98 over Windows 95. Windows 2000 over Windows 98. Etc. etc. The newer the compiler tools, the better optimized the code is for today's processors.
    Ou seja, uma simples actualização do compilador permitiu à Microsoft por-se a cantar de galo e dizer que melhorou muito o Office.
    Reparem que dispondo da source podemos compilar o programa no nosso computador, tendo assim a certeza que ele fará um melhor uso dos hardware.

    Se conseguissemos que a Microsoft nos desse a source do Windows... :)
    Re:A diferença principal (Pontos:1)
    por Strange em 30-12-00 17:49 GMT (#12)
    (Utilizador Info)

    Eu nunca disse que não se teria vantagem nenhuma se se compilasse o programa optimizando para a nossa máquina.

    O que eu disse é que não optimizas nenhum programa por compilares na tua máquina, se usares o que vem por defeito na distrbibuição que usas.

    Pois se fores ver, o egcs que vem com o rh 7.0 não suporta optimizações para processadores ia32 superiores ao 486...

    E já agora, a biblioteca padrão do C que instalaste já vem optimizada para o teu processador. (A RedHat disponibiliza versões para i386, i586 e i686 no seu cd de instalação, e a que mais se adequa ao sistema é a instalada)

    E como todos os programas abusam dessa biblioteca, e como essa já é optimizada, o que ganharias se compilasses todos os programas na tua máquina seria irrisório...

    hugs

    Luciano Rocha


    Re:Howto Alternativo (Pontos:1)
    por bofh em 30-12-00 10:10 GMT (#10)
    (Utilizador Info)
    ou clicar umas quantas vezes seguidas com o rato...

    Já ouviste falar, por exemplo, no gnorpm?

    "I explicitly give people the freedom not to use Perl as God gives people the freedom to go to the devil if they so choose." - L. Wall
    Re:Howto Alternativo (Pontos:1)
    por NeVErMinD em 31-12-00 14:18 GMT (#16)
    (Utilizador Info)
    È que o ppl instala o X para depois correr o xterm e usar a linha de comandos á mesma, enfim.. ;)
    btw, experimenta o kpackage tb tá engraçado
    Re:Howto Alternativo (Pontos:2)
    por Gamito em 29-12-00 23:52 GMT (#5)
    (Utilizador Info)
    Eh eh eh!

    Mário Gamito
    Re:Howto Alternativo (Pontos:1)
    por NeVErMinD em 30-12-00 18:28 GMT (#13)
    (Utilizador Info)
    Boas...
    Para fazer um update ao XFree até era bem capaz de usar um rpm, visto que normalmente so se faz um update destes numa workstation em que a performance nao é assim tao importante.
    Agora dizer que em Linux nao é preciso compilar, é no minimo perigoso, pois vem desvirtuar o conceito Open Source e em consequencia logica o proprio linux. Pessoalmente nao gostos dos rpms, apenas os uso em pacotes basicos que se compilar nao me tras muitas vantagens, tipo net-tools, agora uma base-de-dados ou um servidor de www (entre muitos outros) é um must compilar, nao quer dizer que vá ver a source mas pelo menos tenho essa opcao, depois gosto sempre de definir a directoria onde vou instalar tal como o que quero ou nao suportar, no fim depois comparamos a performance do meu programa compilado com o do rpm e dou por bem gasto tempo que empreguei. Nem vou falar do kernel que como default vem bem pesado, mesmo que muitos suportes sejam feitos por modules.
    Há uns anos li algures qualquer coisa como isto "Se queres ser um bom utilizador de linux habitua-te a compilar os programas" portanto para aqueles que nao se interessam pela source nem pela "liberdade de movimentos" que a mesma oferece, entao ja têm o windows para quê usar linux?
    drivers da NVIDIA (Pontos:1)
    por ekstassy em 30-12-00 5:35 GMT (#8)
    (Utilizador Info) http://linus.uac.pt/~milton_m/site/
    Alguem sabe se por acaso os drivers existentes para as placas com os chips da nvidia (TNT/TNT2/GeForce/etc) funcionam nesta versão ou nem por isso?

    - xtc (a *not so* proud owner of a nvidia card)

    Re:drivers da NVIDIA (Pontos:1)
    por TarHai em 02-01-01 19:43 GMT (#17)
    (Utilizador Info)
    Funcionam tao bem como com o X4.01 (alguns artefactos persistem q devem ser dos drivers nvidia).

    Ao contrario de toda a gente :o) saquei o binario i386 do X para nao perder tempo em compilacoes e configuracoes. Instalei com o scipt de instalacao (Xinstall.sh, se nao me engano). Depois de ter dado uns toques no fontpath (o X nao arrancava por nao encorntrar a fonte fixed) ficou tudo impecavel.

    linux mdk7.2/creative TNT2U/glibc2.1
    
    TH

    PS: Finalmente os problemas com o rato foram resolvidos e o quake3 ja funciona decentemente!!!!

     

     

    [ Topo | Sugerir artigo | Artigos anteriores | Sondagens passadas | FAQ | Editores | Preferências | Contacto ]