O servidor X está cada vez mais prático e inteligente. Antes, tudo tinha que ser feito através do arquivo de configuração de /etc/X11/xorg.conf. Após as modificações, deveria reiniciá-lo (por exemplo, via Ctrl+Alt+Backspace).

Agora, ele é capaz de detectar várias características do sistema e gerar apenas um esboço do xorg.conf automaticamente. E quase nunca será necessário editá-lo.

Vai saber desde quando – mas antes de 2007, existe o XRandR. Ele permite o controle das saídas de imagem do sistema, através das diversas saídas de vídeo que sua placa de vídeo suportar! Por controle entenda: redimensionar, rotacionar, clonar, estender a imagem por mais de uma tela (seja acima, abaixo, à esquerda, à direita) … Claro que existem restrições, depende de sua placa e do respectivo driver… Uma coisa é obrigatória: o driver tem que oferecer suporte a TVOut.

Eu tive problemas, para variar, com o driver ATI Radeon do próprio X11. Pobre placa do meu notebook (Radeon Xpress 220M, de um HP Pavilion dv5000). A saída S-Video não funcionava. Eis como resolvi:

1. É possível ver quais as saídas você têm (conforme o driver) usando o comando:
   $ xrandr

   Aparece que tenho saída LVDS (que é a tela do notebook), VGA (que funciona normal) e S-video. Ops, a S-Video aparece como desconectada, mesmo com o cabo conectado à TV.

   S-video disconnected (normal left inverted right x axis y axis)
   

2. Se quiser algo mais detalhado:
   $ xrandr –verbose
3. Já que o driver falha, é preciso forçar um modo (resolução) válido para a S-Video. Por isso, adicionei (mas ainda não ativei) a resolução de 800×600.
   $ xrandr –add-mode S-video 800×600
   (o nome da saída a configurar é conforme o que informa o xrandr; S-video, no meu caso).
4. Agora algo muito importante: precisa definir o padrão da TV, antes de ativar o modo. No meu caso, é NTSC só que reconhece a TV:
   $ xrandr –output S-video –set tv_standard ntsc
   Outro valor possível é pal.
5. Por fim, ativei o modo:
   $ xrandr –output S-video –auto
   ou ainda
   $ xrandr –output S-video –mode 800×600
6. Caso algo saia errado, você pode desligar a saída e tentar de novo:
   $ xrandr –output S-video –off

Fica para outra postagem, se eu fizer, sobre como usar outros recursos e parâmetros do xrandr.

Existem alternativas gráficas para essas configurações, como o ARandR (que eu prefiro) e gRandr . Mas nenhum permitiu que eu configurasse uma saída (adicionar um modo, por exemplo, como precisei).

Se alguém souber usar as propriedades de script do ARandr, eu agradeço.

A partir daí, basta acrescentar a opção -m32 ao compilador gcc.
gcc -m32 -o hello hello.c

Uma arquitetura em particular (i386, i486, pentium etc.), pode ser especificada com -march.
gcc -m32 -march=i386 -o hello hello.c
Fontes:

Debian AMD64 How-to
Debian AMD64 Faq

Devido ao suporte nativo da arquitetura x86_64 (desenvolvida pela AMD) à arquitetura x86 (criada pela Intel), o Debian utiliza um método que ele considera uma emulação 32 bits. No diretório raiz do sistema, criou uma pasta /emul onde lá estariam as arquiteturas emuladas: no caso /emul/ia32-linux/.

Nesse diretório, fica “toda” a árvore do sistema de arquivos para aplicativos 32 bits. “Toda” porque, na verdade, só a pasta usr/ e lib/ ficam lá. Os aplicativos 32 bits usarão as pastas nativas para arquivos de configuração, registro etc (/etc/ e /var/, por exemplo).
Além disso, dentro da pasta /usr/ “oficial” do sistema, criou duas novas pastas: lib32/ e lib64/. A pasta /usr/lib/ é uma ligação para /usr/lib64/, diretório no qual residem todas as bibliotecas 64 bits, como o própio nome sugere.

Ao se executar um programa que se vale de bibliotecas dinâmicas (ou seja, quase todos), conforme a arquitetura do aplicativo, ele vai procurar primeiro a biblioteca compatível no pasta das de 32 bits; caso não encontre, recai nas de 64 bits. Contudo, não adianta tentar fazer a ligação dinâmica de programas 32 bits com bibliotecas 64 bits, ocorre erro na quase totalidade dos casos. Então, o que se deve fazer é instalar as bibliotecas 32 bits faltantes.

Primeiramente, para poder rodar os aplicativos 32 bits menos exigentes em bibliotecas, o mínimo que se deve instalar é o pacote ia32-libs. Para aplicativos com interface gráfica que utilizam GTK+, deve se instalar ia32-libs-gtk. O pacote lib32nss-mdns, por sua vez, é para auxiliar nas conexões com a internet (relativos a DNS).

Passemos a um exemplo de caso, agora, em que essas bibliotecas não são o suficiente:

———————————————————————-
Gens-GS no Debian-AMD64 (x86_64)
———————————————————————-

Esse aplicativo citei em outro post, referente a emuladores de sistemas SEGA. No caso, é um emulador de Mega Drive.
Esse Gens modificado ainda não terminou de reescrever o código para que possa ser portado enfim para 64bits. No entanto, dá para executá-lo no Debian instalando as bibliotecas 32 bits que ele disponibiliza.
Como é um aplicativo 32 bits, e usa a interface GTK+, é necessário instalar dois pacotes:

• ia32-libs
• ia32-libs-gtk

Como gosto do aptitude pela memória que ele tem para remoção das dependências depois que o pacote que as convocou é removido, sempre o uso:
# aptitude install ia32-libs ia32-libs-gtk
Quem não gosta, ou prefere o apt-get:
# apt-get install ia32-libs ia32-libs-gtk
Ou utilize synaptic para fazer com uma amigável GUI. Os programas devem ser executados como super-usuário (root) ou via sudo.

Feito isso, podemos instalar o pacote pré-compilado do Gens-GS para Ubuntu 32 bits. Para tal feito, é preciso obrigar o utilitário dpkg a instalar o pacote ignorando o problema de arquitetura…
# dpkg --force-architecture -i meu-diretório/Gens_2.15.5-gs-m6-1_i386.deb
Instalado com sucesso, é o momento de executarmos o emulador:
$ gens
E então ocorre o momento que todos “queriam”: o erro.
$ gens
gens: error while loading shared libraries: libGL.so.1: cannot open shared object file: No such file or directory
Ou, em português,
$ gens
gens: erro ao carregar as bibliotecas dinâmicas: libGL.so.1: não é possível abrir o arquivo objeto compatilhado: O arquivo ou o diretório não existe

Ou seja, o sistema não encontrou as bibliotecas 32 bits do OpenGL que o Gens-gs precisa (na verdade, na execução, você pode optar por usar SDL). O que é preciso fazer, então, é instalá-las. Suponhamos que você não saiba em que pacote que elas vêm. É possível usar o site de pacotes do Debian para pesquisar. No caso, é preciso buscar pelo conteúdo do pacote: libGL.so.1. Na página do resultado da pesquisa para a versão debian/lenny, observa-se alguns pacotes possíveis:

• fglrx-glx-ia32 [amd64] : para placas de vídeo AMD/ATI
• nvidia-glx-ia32 [amd64] ou nvidia-glx-legacy-96xx-ia32 [amd64]: para placas de vídeo da NVIDIA
• libgl1-mesa-glx [i386, amd64]: para renderização direta ou indireta

“Tanto faz” qual utilizar. Óbvio que para melhor desempenho, deveria utilizar o apropriado para sua placa de vídeo.

Para generalizar a solução, vou escolher o pacote libgl1-mesa-glx. Embora tenha a versão própria para AMD64, nós precisamos é da versão 32 bits (repare que os demais pacotes citados já são para isso – 32 bits em máquinas 64 bits, o que é bem melhor).

O que se deve fazer é baixar o pacote para i386 do site do Debian:

http://packages.debian.org/lenny/libgl1-mesa-glx

E fazer o dpkg, em vez de instalar de fato no sistema, apenas extrair para a pasta de emulação de 32 bits…
# dpkg --extract meu-diretório/libgl1-mesa-glx_7.0.3-7_i386.deb /emul/ia32-linux/
Et voilà! Gens/GS funciona enfim.

Lembro que deve isso ser feito como super-usuário, que o que deve ficar na pasta /emul/ia32-linux/ são apenas as lib/ e usr/, as demais, se criadas, devem ser apagadas ou ter seu conteúdo movido para as equivalentes do sistema.

Destaco aqui que é/seria muito melhor instalar os pacotes *-ia32. Essa solução é para quando não estão disponíveis. Esse método pode ser melhorado modificando o pacote já para fazer a instalação nas pastas adequadas e modificando a arquitetura de instalação: isso permite remover o conteúdo do pacote depois com apt-get, aptitude, synaptic etc. Contudo, foi feito assim por simplicidade.

Emulador de Master System:
osmose: Enfim um emulador com som no meu Debian 64 bits. Só conhecia o Meka, que não consegui rodar com som, já que está bem desatualizado sua versão linux.

Emuladores de Mega Drive:
gens-gs : Modificação do Gens oficial, que pretende juntar todos os mods de Gens disponíveis e reescrever tudo para a linguagem C (existem partes em assembly i386). Por ora, sem suporte a 32 bits. Consegui executá-lo direito aqui, mas isso é assunto para outro post. Muito bom, mas há erros no som, como quase todos os emuladores de mega-drive.
regen: Tem a intenção de ser o mais perfeito de todos em termos de emulação, inclusive no sincronismo. Tem as mesmas falhas de som que o Gens, contudo. A versão linux, sempre desatualizada perante a windows, é só para 32 bits, mas executável da mesma forma que o Gens/Gs em sistemas 64 bits. Aliás, mais fácil.

Emulador de Saturn:
yabause: Nunca testei, não tenho jogos de Saturn (nem nunca joguei um…). Uns gostam, outros não. O que sei é que existe nos repositórios do Debian, inclusive para 64 bits

Emulador de Dreamcast
lxdream: Ótimo emulador, embora o desenvolvimento dele tenha caído de velocidade. Já o mencionei aqui antes, mas não ia deixar o último sistema da SEGA fora dessa lista

O Osmose, o Gens/gs e o Yabause foram dicas de um amigo meu. Embora ainda não tenha divulgado em lugar algum sobre o Osmose, ele já noticiou sobre Gens/gs e Yabause.
O Yabause também foi me notificado pelo Leandro Santiago em um comentário neste blog (embora seja querendo outro emulador para o Saturn…)

Pidgin (antigo GAIM) e Kopete são dois clientes que uso ou usei no Linux e ambos têm esse recurso, mas se resumem a notificar textualmente e, no máximo, sonoramente. Embora ambos recebam e notifiquem o nudge, eu acreditava que o Pidgin perdia para o Kopete neste recurso porque não havia como enviar um nudge (que o Kopete traduz como “abanão”) Pidgin. Mas agora descobri pela internet que pode sim. Basta imaginá-lo como um cliente de IRC e enviar a mensagem
/nudge
na janela de batepapo. Destacando, só escreva isso e pressione a tecla [Enter].
/me fiz alguma coisa
também funciona como esperado em um cliente de IRC.

—
Comentários pessoais
Não costumo expor opiniões aqui, mas desta vez irei, só que ainda assim de forma contida.

• Detesto este recurso, é muito mal usado por brasileiros, pelo menos. A idéia é ótima, mas ficam brincando ou chamando atenção para algo completamente irrelevante… Ainda bem que sou salvo disso por usar clientes diferentes dos oficiais do protocolo MSNP.
• Como a Microsoft tem problemas de criatividade ou de subestimar a inteligência e memória de seus clientes: depois do MS-DOS (sigla em inglês para sistema operacional em disco como se fosse o primeiro e único), MS-Windows (como se a Apple não usasse o termo janela), MS-Internet Explorer (UAU!), ela vem com Windows Messeger, MSNM (Mensageiro da rede Microsoft) e Windows Live Messeger… Tsc tsc. Viva Excel e Access, nomes que não têm nada a ver com nada!
• Eita gente ignorante que nunca viu a letra m em minúscula na sigla do programa: MSNm…. MSN é um serviço da Microsoft muito aquém de um mero mensageiro (mas não que prestasse)
• Esse protocolo um dia permitirá os “sempre visíveis” como no antigo e excelente ICQ?
• Esse cliente/protocolo um dia permitirá bloquear o grupo (afinal, esse recurso precisa de uma utilidade maior que esconder quem não te interessa no momento)?
• Apesar de eu não usar, o Pidgin deveria disponibilizar o nudge como botão… Para mim, o Pidgin ainda perde neste quesito para o Kopete.

O método de entrada que uso agora é o uim-anthy (método de entrada anthy (front-end) sobre a biblioteca uim (backend)). É muito bom. Juntamente com o seus applets disponíveis (para GNOME e KDE), a vida fica muito mais fácil e prática.

Não lembro muito o que eu fiz exatamente, como já disse, mas segue o que tenho agora no meu sistema (Debian Lenny AMD64). Tenho instalados os pacotes:

• uim-anthy (que instalará anthy, libanthy0, libuim6, uim-common, uim-utils)
• uim-applet-gnome (mas existe também o uim-applet-kde)

Acredito que basta instalar esses dois pacotes (e suas dependências, claro). Claro que seu sistema tem que ter fontes japonesas ou com suporte à língua japonesa.

Caso eu esteja enganado, uma página boa (acho) como referência é Aletéia. Só um detalhe: não precisei de instalar nada de scim, que é uma alternativa mais antiga ao uim.

Para quem não quer instalar nada (e também para usuários de MS-Windows), existe uma página que permite digitação em caracteres japoneses usando apenas o navegador web.
Testei, e funciona no Opera, meu navegador. Essa dica peguei do grupo de discussão NihongoBR do qual não participo. No entanto, não usarei essa página, já que não preciso…

Este post aqui é só para informar que o produto USB Bluetooth adaptor EM-BT1 (baseado no Bluetooth Dongle v2.0), da ECOmania, funcionou sem qualquer problema no meu Debian/Etch. Automaticamente! Claro, tenho instalados os pacotes referentes a Bluetooth: bluetooth e bluez-utils.

Fica aí reportado para quem tiver dúvida se compra ou não ;)

Segui meus passos relatados no post anterior. Reiniciei a interface gráfica e… não funcionou! Ficou bem estranho mesmo: a tela preta com algo verde. Tentei mudar para o modo terminal tty1 (CTRL+ALT+F1) e nada: mesma coisa esquisita! Apertei então o famoso CTRL+ALT+DEL para reiniciar e ver se isso corrigiria o problema. Continuou igualzinho!

Tive que reiniciar o PC de novo e tentar entrar no modo terminal. Meu bootloader GRUB tinha como opção de boot o modo single-user. Ai de mim se não tivesse =P

Para os que não têm, dá para resolver na tela do GRUB mesmo. Selecione o kernel que você quer usar e pressione E em vez de ENTER. Isso faz entrar no modo de edição (não permanente). Acrescente o argumento single. No meu caso, é assim:

/boot/vmlinuz-2.6.18-6-amd64 root=/dev/hda3 ro single

Pressione ENTER então para dar o boot. Quando chegar o momento, pedirá a senha de root. Digite-a Pronto! Modo terminal!

Depois de reinstalar as versões anteriores (eu já tinha os pacotes prontos, só precisei executar o dpkg -i), descobri o problema: esqueci de usar o module-assistant para gerar o módulo do novo driver para o kernel. Isto é:
# module-assistant prepare
# module-assistant update
# module-assistant a-i fglrx

Pressionei CTRL+ALT+D para fazer log-off e assim o sistema terminar de iniciar. E ok!
Conclusão, nunca esqueça de gerar o novo módulo antes de reiniciar! Ah! Descobri também que nem sempre só reiniciar o servidor X resolve!

Usei, então, o comando:
$ fglrxinfo
E a resposta foi que o “OpenGL vendor string” era Mesa (indirect) em vez de ser meu driver ATI Radeon Xpress series.

Motivo descoberto: atualizei o kernel e o módulo não estava mais funcionando

Tive, então, que relembrar os passos que segui outrora. Só baixar o driver do fabricante e rodar o instalador não funciona!
Em todo caso, é necessário baixar o driver correto, sendo que o meu é Radeon Xpress para 64bits (o arquivo baixado foi ati-driver-installer-8.443.1-x86.x86_64.run).

Uma vez descarregado o arquivo, em vez de mandar instalá-lo, é melhor fazer gerar os pacotes para posteriores instalações, quem sabe?
$ sh ./ati-driver-installer-8.443.1-x86.x86_64.run --buildpkg Debian/etch
Obs.: Se alguém estiver usando para outra distribuição, obtenha a lista das possíveis usando o comando
$ sh ./ati-driver-installer-8.443.1-x86.x86_64.run --listpkg

Eis a lista de pacotes gerados:

• fglrx-amdcccle_8.443.1-1_amd64.deb
• fglrx-driver_8.443.1-1_amd64.deb
• fglrx-driver-dev_8.443.1-1_amd64.deb
• fglrx-kernel-src_8.443.1-1_amd64.deb

Além do arquivo texto:

• fglrx-installer_8.443.1-1_amd64.changes

Construídos os pacotes, hora de instalá-los, seja via apt-get, seja por dpk.
$ dpkg -i fglrx*443*deb
(eu tinha outra versão na mesma pasta)

Agora que veio a parte que eu não me lembrava. Contudo, graças a um link no site da própria ATI para um site não oficial, achei o que precisava.

Faltava gerar o módulo para o kernel! Que até agora não sei por que não geram no instalador =P

$ module-assistant prepare
$ module-assistant update
$ module-assistant a-i fglrx

Caso não possua o module-assistant, obtenha-o via apt-get.

Não sei se é necessário isso aqui, mas a página falou, tá falado.
$ aticonfig --initial

Agora a página sugere reiniciar o computador. Não precisa. Bastou reiniciar o servidor gráfico (o X): Ctrl+Alt+Backspace. Lembre-se de que tudo será fechado (quase) instantaneamente, salve tudo antes de apertar essas teclas! Se preferir, faça log-off e só então reinicie o X.

Reiniciado o servidor gráfico, efetuei o login e executei o comando:
$ fglrxinfo

Et voilà, a mensagem que eu tanto almejava!

display: :0.0 screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI Radeon Xpress Series
OpenGL version string: 2.1.7170 Release


E tudo voltou ao que era antes…