A maneira mais fácil é simplesmente especificar o desejo de usar o X durante o processo de instalação do FreeBSD.
Depois disso, leia e siga as instruções documentadas na ferramenta xf86config, que auxilia o usuário a configurar o XFree86 para os diversos monitores, placas de vídeo, mouse e etc, suportados pelo X, sistema de interface gráfica.
Também pode ser interessante dar uma olhada no servidor Xaccel. Confira a seção do FAQ pertinente à Xi Graphics ou Metro Link para obter mais detalhes.
11.2. Tentei rodar o X, mas o erro “KDENABIO failed (Operation not permitted)” sempre aparece, quando eu digito o comando startx. O que posso fazer?
Seu sistema está rodando com um securelevel (nível de segurança do sistema) elevado, não está? É impossível iniciar o X com um secureleve elevado. Para saber exatamente os motivos dessa inviabilidade, por gentileza, de uma olhada na página de manual do init(8).
Então, a pergunta pode ser sobre o que você deve fazer nesse caso; basicamente, existem duas escolhas: diminua seu securelevel (nível de segurança do sistema), colocando-o de volta para zero (normalente via /etc/rc.conf), ou então inicie o xdm(1) durante o processo de inicialização do sistema (antes que o securelevel (nível de segurança do sistema) seja elevado).
Veja a pergunta P: 11.8., para obter mais informações sobre como iniciar o xdm(1) durante o boot.
Caso esteja usando o syscons (o driver padrão do console), o FreeBSD pode ser configurado para suportar um cursor de mouse em cada tela virtual. Com o intúito de evitar conflitos com o X, o syscons suporta um dispositivo virtual, chamado /dev/sysmouse. Todos os eventos relacionados ao mouse, que o sistema recebe, são antes enviados para o device sysmouse, por meio do moused. Se a intenção é usar o mouse em um ou mais consoles virtuais, e também usar o X, leia P: 4.13. e configure o moused.
Depois, edite o /etc/XF86Config e garanta que existam as seguintes linhas no arquivo:
Section Pointer Protocol "SysMouse" Device "/dev/sysmouse" .....
O exemplo acima refere-se ao XFree86 3.3.2 e posteriores. Para versões anteriores, a cláusula Protocol deve ser substituída por MouseSystems.
Alguns preferem usar a device /dev/mouse sob o X. Para que isso funcione, faça um link de /dev/mouse para /dev/sysmouse (veja a página de manual do sysmouse(4)).
# cd /dev # rm -f mouse # ln -s sysmouse mouse
Pode, mas é necessário customizar os programas do X. Veja a página do Colas Nahaboo sobre o assunto ( http://www.inria.fr/koala/colas/mouse-wheel-scroll/.
Caso queira usar o programa imwheel, simplesmente siga os seguintes passos:
Traduza os eventos da esfera de scroll:
O programa imwheel funciona assim: ele traduz os botões 4 e 5 do mouse em eventos do teclado do computador. Dessa forma é necessário assegurar que o driver do mouse esteja traduzindo os eventos da esfera de scroll para os eventos dos botões 4 e 5, ou seja assimilar suas funções. Existem duas formas de fazer isso, a primeira é usando o moused(8) para fazer essas assimilações, e a segunda, é usar o próprio X para traduzir os eventos.
Usando o moused(8) para traduzir os eventos da bolinha de scroll.
Para que o moused(8) faça
as assimilações de eventos, basta adicionar as opções -z 4 nas opções de linhas de comando, usadas para
iniciar o moused(8). Por
exemplo, se normalmente você inicia o moused(8) via moused -p /dev/psm0 basta substituir o comando por moused -p /dev/psm0 -z 4. Se o moused(8) é
executado automaticamente durante o processo de inicialização do FreeBSD,
por meio das entradas definidas no /etc/rc.conf, basta
adicionar -z 4 na variável moused_flags do /etc/rc.conf.
Você precisa agora dizer para o X que você tem o botão 5 no mouse. Para fazer isto, simplesmente adicione a linha Buttons 5 para a seção “Pointer” do /etc/XF86Config. Por exemplo, você pode seguir a seção “Pointer” em /etc/XF86Config.
Exemplo 11-1. Seção “Pointer” no XF86Config para o mouse com bolinha de scroll, da série 3.3.x do XFree86, usando a tradução se;rie 3.3.x do XFree86, usando a tradução por meio do moused
Section "Pointer" Protocol "SysMouse" Device "/dev/sysmouse" Buttons 5 EndSection
Usando o X Server para traduzir os eventos da esfera de scroll.
Se você não usa o moused(8) ou simplesmente não quer que ele faça a tradução de eventos, é possível que o servidor X faça o trabalho, no lugar do moused(8). Essa ação requer algumas alterações no seu arquivo /etc/XF86Config. Primeiro, é necessário definir o protocolo apropriado para o mouse. A maioria dos mouses com esferas de scroll usam o protocolo “IntelliMouse”. De qualquer forma, o XFree86 não suporta outros protocolos como o “MouseManPlusPS/2” dos MouseMan+ Logitechfor. Uma vez definido o protocolo, é necessário criar uma entrada apropriada na seção “Pointer”.
Depois, é preciso definir que o servidor X deve remapear os eventos 4 e 5 do
mouse. A opção ZAxisMapping é usada
para essa finalidade.
Por exemplo, caso não estejas usando o moused(8) e exista um IntelliMouse ligado na PS/2 do seu computador, use o seguinte, no /etc/XF86Config.
Exemplo 11-4. Seção “Pointer” do XF86Config com um mouse com scroll na série 3.3.x do XFree86.
Section "Pointer" Protocol "IntelliMouse" Device "/dev/psm0" ZAxisMapping 4 5 EndSection
Instale o imwheel
Depois, instale o imwheel à partir da coleção de ports do FreeBSD; ele pode ser encontrado sob a categoria x11. A finalidade desse programa é assimilar os eventos dos botões 4 e 5 do mouse, com os eventos de alguma tecla do teclado. Por exemplo, o programa deve enviar o evento da tecla Page Up quando a esfera for deslocada para frente. O imwheel usa um arquivo de configurações para assimilar esses eventos à uma tecla, de forma que possam ser configuradas ações diferentes (teclas diferentes) para aplicações diferentes. O arquivo de configuração padrão do imwheel é instalado em /usr/X11R6/etc/imwheelrc. Ele pode ser copiado para ~/.imwheelrc e editado, caso se deseja customizar o arquivo de configuração. O formato esperado para o arquivo é documentado na página de manual do imwheel(1).
Configure o Emacs para trabalhar em conjunto com o Imwheel (optional)
Se você usa o emacs ou o Xemacs, será necessário adicionar uma breve seção ao arquivo ~/.emacs. No emacs, adicione o seguinte:
Exemplo 11-7. Configuração do Emacs para Imwheel
;;; For imwheel (setq imwheel-scroll-interval 3) (defun imwheel-scroll-down-some-lines () (interactive) (scroll-down imwheel-scroll-interval)) (defun imwheel-scroll-up-some-lines () (interactive) (scroll-up imwheel-scroll-interval)) (global-set-key [?\M-\C-\)] 'imwheel-scroll-up-some-lines) (global-set-key [?\M-\C-\(] 'imwheel-scroll-down-some-lines) ;;; end imwheel section
Pro Xemacs, adicione o seguinte, no seu arquivo ~/.emacs:
Exemplo 11-8. Configuração do Xemacs para Imwheel
;;; For imwheel (setq imwheel-scroll-interval 3) (defun imwheel-scroll-down-some-lines () (interactive) (scroll-down imwheel-scroll-interval)) (defun imwheel-scroll-up-some-lines () (interactive) (scroll-up imwheel-scroll-interval)) (define-key global-map [(control meta \))] 'imwheel-scroll-up-some-lines) (define-key global-map [(control meta \()] 'imwheel-scroll-down-some-lines) ;;; end imwheel section
Execute o Imwheel
Basta digitar imwheel em algum terminal X (xterm) para inicia-lo, uma vez que tudo esteja pronto. Imediatamente o programa vai estar efetivo e vai se tornar um processo em segundo plano. Caso queira sempre iniciar o imwheel, basta adicionar o comando no seu arquivo .xinitrc ou no .xsession. É possível que o imwheel mostre algumas mensagens de advertência sobre arquivos PID; elas podem ser seguramente ignoradas, visto que são mensagens que se aplicam à versão para Linux.
11.5. Por quê os menus e caixas de diálogo do X, sistema de interface gráfica não funcionam direito?
Tente desativar a tecla Num Lock.
Se por padrão seu Num Lock é ativo na hora do processo de inicialização, adicione a seguinte linha a seção Keyboard do seu arquivo XF86Config.
# Deixar o servidor fazer o trabalho do NumLock. Deve ser usado apenas em versoes anteriores a R6
ServerNumLock
Consoles virtuais simplesmente permitem que se tenha várias sessões simultâneas em uma mesma máquina, sem a necessidade de fazer nada complicado como configurar uma rede ou usar um servidor X.
Quando o sistema é iniciado, a primeira ação é apresentar um prompt de login na tela do usuário, tão logo todas as mensagens do processo de inicialização sejam apresentadas. Nesse momento é possível entrar com seu nome de usuário e senha para começar trabalhar (ou brincar!) no primeiro console virtual.
Em algum momento, é provável que se deseje iniciar uma outra sessão, talvez para ler a documentação de alguma aplicação que está sendo usada, ou para ler e-mail enquanto a transferência FTP se conclúi, enfim, qualquer ação (a)típica de um sistema multitarefa. Nesse caso, basta pressionar Alt+F2 (segure a tecla Alt e depois aperte a tecla F2), e outro prompt de login estará esperando você no segundo “console virtual”! Quando quizer alternar de volta à sessão original, digite Alt+F1.
A instalação padrão do FreeBSD oferece três consoles virtuais já habilitados (8 a partir do 3.3-RELEASE), e as teclas Alt+F1, Alt+F2, e Alt+F3 irá alternar entre esses consoles.
Para habilitar mais consoles, edite o /etc/ttys (veja a página de manual do ttys(5)) e adicione as entradas da ttyv4 à ttyvc depois do comentário sobre “Virtual terminals”:
# Edite as entradas existentes para ttyv3 e mude de "off" para "on" ttyv3 "/usr/libexec/getty Pc" cons25 on secure ttyv4 "/usr/libexec/getty Pc" cons25 on secure ttyv5 "/usr/libexec/getty Pc" cons25 on secure ttyv6 "/usr/libexec/getty Pc" cons25 on secure ttyv7 "/usr/libexec/getty Pc" cons25 on secure ttyv8 "/usr/libexec/getty Pc" cons25 on secure ttyv9 "/usr/libexec/getty Pc" cons25 on secure ttyva "/usr/libexec/getty Pc" cons25 on secure ttyvb "/usr/libexec/getty Pc" cons25 on secure
Use quantos consoles desejar. Quanto mais, maior o uso de recursos; essa é uma consideração relevante quando se tem 8MB de RAM ou menos. Também pode ser interessante mudar o terminal de secure para insecure.
Importante: Caso se deseje usar um servidor X, é necessário garantir que exista ao menos um terminal virtual fora de uso (ou desligado). Com isso, entenda que, se sua inteção for usar consoles virtuais nas suas doze teclas de funções, nada feito; apenas onze poderão ser usadas caso deseje-se usar o X na mesma máquina.
A maneira mais simples de desabilitar um console, é desligando-o. Por exemplo, caso existam 12 terminais definidos, como mencionado na situação acima, e se queira usar o servidor X, o mais interessante é mudar as configurações do terminal 12 de:
ttyvb "/usr/libexec/getty Pc" cons25 on secure
para:
ttyvb "/usr/libexec/getty Pc" cons25 off secure
Caso seu teclado tenha apenas dez teclas de funções, basta encerrar as definições com:
ttyv9 "/usr/libexec/getty Pc" cons25 off secure ttyva "/usr/libexec/getty Pc" cons25 off secure ttyvb "/usr/libexec/getty Pc" cons25 off secure
(Claro que as linhas poderiam simplesmente ser apagadas.)
Uma vez editado o /etc/ttys, o passo seguinte é garantir que existam devices o bastante pros terminais virtuais. A forma mais fácil de fazer isso é:
# cd /dev # sh MAKEDEV vty12
Em seguida, a maneira mais fácil (e mais limpa) de ativar cada um dos consoles virtuais é reiniciar o sistema. Mas se reiniciar o FreeBSD não é a intenção, basta desligar o servidor X, sistema de interface gráfica e executar (logado como root):
# kill -HUP 1
É obrigatório tirar por completo o X, sistema de interface gráfica do ar antes de dar esse comando, caso o X esteja sendo usado. Se isso não for feito, o sistema vai parecer que travou.
Use Ctrl+Alt+Fn para alternar de volta para algum console virtual. Por exemplo, Ctrl+Alt+F1 retornaria ao primeiro console virtual.
Uma vez de volta ao console textual, pode-se usar Alt+Fn normalmente, para alternar entre os consoles virtuais.
Pra voltar para sessão X basta alternar para o console virtual onde o X está sendo executado. Caso o X tenha sido iniciado por linha de comando (por exemplo, com o comando startx) a sessão terá sido assimilada ao próximo console virtual fora de uso, e não ao console onde o comando foi digitado. Caso existam oito terminais virtuais ativos, o X estará sendo executado no nono. Nesse caso as teclas Alt+F9 retornarão ao sistema gráfico.
Existem duas formas clássicas de iniciar o xdm. A primeira consiste em inciá-lo a partir do /etc/ttys (veja a página de manual do ttys(5)) usando o exemplo disponível no arquivo; a segunda forma é simplesmente executar o xdm a partir do rc.local (veja a página de manual do rc(8)) ou então por um script X.sh em /usr/local/etc/rc.d. As duas maneiras são igualmente válidas, mas algumas podem ser mais eficientes em algumas situações, onde a outra forma não seria ideal. Nos dois casos, o resultado será o mesmo: o X iniciará o mostrando uma tela de login: gráfica.
O método de inicialização via ttys oferece a vantagem de definir explicitamente em qual vtyX o servidor gráfico vai ser carregado, passando a responsabilidade da reinicialização do X para o init, no momento do logout. O método via rc.local oferece facilidades caso seja necessário encerrar o processo xdm, no caso, por exemplo, de ocorrerem problemas ao carregar o servidor gráfico.
Ao usar o rc.local para carregar o xdm, ele não deve ser acompanhado de nenhum argumento (deve ser iniciado como um daemon e deve ser iniciado DEPOIS que o getty já estiver em execussão, senão é provável que ocorram conflitos entre ambos, podendo travar o console. A melhor forma de assegurar o correto funcionamento desse método é fazer com que o script espere 10 segundos (por exemplo, com um sleep 10;) antes de iniciar o xdm.
Se a inteção é iniciar o xdm a partir do /etc/ttys, ainda existe a probabilidade de conflitos entre o xdm e o getty(8). Uma forma interessante de evitar esse tipo de desconforto, é definir, no arquivo /usr/X11R6/lib/X11/xdm/Xservers, o número do vt onde o X deve ser iniciado, da seguinte forma:
:0 local /usr/X11R6/bin/X vt4
O exemplo acima indica que o servidor X será ativado no /dev/ttyv3. Note que existe um offset de um vt, já que o X começa a contar os terminais (vty) a partir do um, enquando o kernel do FreeBSD os conta a partir do zero.
Se o X for iniciado com um startx, as permissões do /dev/console não serão redefinidas, resultando em situações onde um xterm -C ou mesmo o xconsole não funcionarão corretamente.
O motivo disso é a forma como as permissões são definidas por padrão. Em sistemas multiusuário, normalmente não se espera que qualquer pessoa possa escrever no console do sistema. Para os usuários que estão se logando diretamente na máquina, em algum VTY, existe o arquivo fbtab(5) que resolve esse tipo de problema.
Se for apropriado, garanta que exista uma linha assim
/dev/ttyv0 0600 /dev/console
No arquivo /etc/fbtab (veja a página de manual do fbtab(5)). Essa linha garantirá que qualquer usuário que se logar no /dev/ttyv0 será também proprietário do console.
11.10. Antes eu conseguia usar o XFree86 com um usuário sem privilégios. Porque agora o servidor diz que eu tenho que ser root?
Todo servidor gráfico precisa ser executado como root para que o sistema permita acesso direto aos equipamentos de vídeo. Acontece que nas versões mais antigas, o XFree86 (versões <= 3.3.6) instalava o servidor de forma que ele era automaticamente executado como root (setuid de root). Óbviamente esse comportamente implica em riscos de segurança em qualquer caso onde o programa em questão seja complexo e grande; esse é o caso dos servidores X. As versões mais atuais do XFree86 não instalam os servidores gráficos com todo esse poder, exatamente por esse motivo.
É claro que rodar o X como usuário root não é uma idéia muito aceitável, especialmente em relação à segurança. Existem duas formas de usar o X como usuário comum. A primeira é usar o xdm ou qualquer outro gerenciador de display (como o kdm); a segunda é usar o Xwrapper.
O xdm é um daemon que controla logins gráficos. Normalmente ele é iniciado no processo de inicialização e é responsável pela autenticação dos usuários, e por inciar suas sessões; essencialmente é a união gráfica do getty(8) como o login(1). Para mais informações sobre o xdm, por gentileza, refira-se à documentação do XFree86 e à questão do FAQ sobre xdm.
O Xwrapper é um intermediador do servidor gráfico; é um programa bem pequeno que possibilita a inicialização manual do servidor gráfico por qualquer usuário, garantindo razoável segurança à operação. O programa ainda faz algumas verificações na linha de comando definida pelo usuário, para garantir a sanidade das intenções do mesmo. Se todas as intenções forem aprovadas, ele executa o X. Se por qualquer razão, a idéia de usar um gerenciador de displays não te agrada, o Xwrapper é feito para você. Caso a coleção de Ports esteja instalada, o programa pode ser encontrado em /usr/ports/x11/wrapper.
O seu mouse e a device que o controla devem ter desincronizado.
Nas versões 2.2.5 e anteriores, a simples alternância entre o X e o terminal, e voltar para o X, força a resincronização do mouse. Se o problema se tornar frequênte, adicione a seguinte opção ao arquivo de configuração do seu kernel, e o recompile:
options PSM_CHECKSYNC
Veja a seção sobre a compilação do kernel, caso você não tenha experiência com isso.
Com essa opção as chances de ter problemas com a sincronia do mouse são bem pequenas. Contudo, se ainda assim o problema persistir, clique em qualquer botão durante o movimento do mouse. É o bastante para resincroniza-lo.
Infelizmente essa opção pode não funcionar em alguns sistemas, dependendo de qual driver controle o seu mouse PS/2; especialmente se a device de controle for do tipo ALPS GlidePoint.
Na versão 2.2.6 e posteriores, a verificação de sincronia se tornou razoávelmente melhor, e é padrão nos mouses PS/2. Deve funcionar corretamente com GlidePoint, inclusive (como o código de verificação de sincronia ter se tornado padrão, a opção PSM_CHECKSYNC não existe mais). Contudo, em situações muito raras, o driver de controle do mouse pode, errôneamente reportar problemas de sincronização, mostrando a seguinte mensagem do kernel:
psmintr: out of sync (xxxx != yyyy)
Pensando que seu mouse não está funcionando corretamente.
Se for o caso, desligue o código de verificação de sincronia do
mouse PS/2, definindo a flag 0x100 na device de controle do mesmo. Entre no modo UserConfig definindo a
opção -c na tela do processo de
inicialização:
boot: -c
Depois, na linha de comando do UserConfig, digite:
UserConfig> flags psm0 0x100 UserConfig> quit
Existem notícias que alguns modelos de mouse PS/2 da MouseSystems funcionam corretamente apenas em modo de alta resolução. Do contrário, o cursor do mouse costuma pular para diagonal superior esquerda da tela com certa frequência.
Infelizmente não existe solução à esse problema, nas versões 2.0.X e 2.1.X. Contudo, das versões 2.2 à 2.2.5, basta aplicar o seguinte patch, no /sys/i386/isa/psm.c e recompilar o kernel. Veja a seção sobre compilação do kernel caso não tenha experiência com o assunto.
@@ -766,6 +766,8 @@
if (verbose >= 2)
log(LOG_DEBUG, "psm%d: SET_DEFAULTS return code:%04x\n",
unit, i);
+ set_mouse_resolution(sc->kbdc, PSMD_RES_HIGH);
+
#if 0
set_mouse_scaling(sc->kbdc); /* 1:1 scaling */
set_mouse_mode(sc->kbdc); /* stream mode */
Na versão 2.2.6 e versões posteriores, basta especificar a flag 0x04
para device de controle do mouse PS/2, colocando-o em modo de alta
resolução. Entre no modo UserConfig com a opçãp -c na tela do processo de inicialização:
boot: -c
Depois, na linha de comando do UserConfig digite:
UserConfig> flags psm0 0x04 UserConfig> quit
Veja a pergunta anterior, sobre outra causa possível de problemas com o mouse.
O Imake.tmpl é parte do pacote Imake, uma aplicação padrão para construção de aplicações gráficas. O Imake.tmpl, assim como vários outros arquivos de cabeçalhos necessários para compilar aplicações gráficas, é parte da distribuição do X. Eles podem ser instalados pelo sysinstall ou manualmente a partir dos arquivos da distribuição.
11.14. Estou construindo uma aplicação gráfica que depende do XFree86 3.3.X, mas eu estou com o XFree86 4.X instalado. O que fazer?
Pra definir que a construção do Port deve ser linkada às bibliotecas do XFree86 4.X, adicione o seguinte, no seu /etc/make.conf, (se o arquivo não existir, crie-o):
XFREE86_VERSION= 4
Execute o comando xmodmap -e "pointer = 3 2 1" à partir do .xinitrc ou do .xsession.
A partir da lançamento do FreeBSD 3.1, uma nova característica foi adicionada ao sistema, permitindo que alguns arquivos de imagens sejam usados como “Splash Screens” durante as mensagens do processo de inicialização. Tais imagens devem ser arquivos do tipo bitmap com 256 cores (*.BMP) ou então ZSoft PCX (*.PCX). Devem ainda ter resolução de 320x200 pixels (ou menos), para funcionarem corretamente em adaptadores de vídeo VGA tradicionais. Caso o kernel tenha sido compilado com suporte à VESA, então podem ser usados bitmaps maiores, até 1024.768 px. O suporte à VESA pode ser diretamente compilado no kernel, com a opção VESA no arquivo de configuração, ou carregado como módulo, com o kld, durante o processo de inicialização do sistema.
Para definir a “Splash Screens”, basta modificar alguns arquivos de inicialização que controlam o processo de inicialização do FreeBSD. Tais arquivos foram alterados na versão 3.2 do FreeBSD, existindo portanto duas formas de carregar uma “Splash Screens”:
No FreeBSD 3.1
O primeiro passo é escolher o seu bitmap, e sua versão. Até o FreeBSD 3.1, apenas os bitmaps do tipo Windows eram suportados. Assim que escolher (ou criar) sua “Splash Screens”, copie-a para /boot/splash.bmp. Depois, basta editar (ou criar, caso não exista) o arquivo /boot/loader.rc e adicionar as seguintes linhas:
load kernel load -t splash_image_data /boot/splash.bmp load splash_bmp autoboot
No FreeBSD 3.2 e posteriores
Além de adicionar suporte a “Splash Screens” de formato PCX, o FreeBSD 3.2 passou a oferecer uma maneira mais interessante de configurar o processo de inicialização. Caso prefira, o método descrito acima, para o FreeBSD 3.1 também funciona. Nesse caso, se a imagem for do tipo PCX basta substituir a entrada splash_bmp por splash_pcx. Caso queira usar a nova configuração do processo de inicialização, basta criar um arquivo /boot/loader.rc com o seguinte conteúdo:
include /boot/loader.4th start
e depois, um /boot/loader.conf com o seguinte:
splash_bmp_load="YES" bitmap_load="YES"
Essa configuração assume que o /boot/splash.bmp deve ser usado como sua “Splash Screens”. Caso prefira usar um arquivo PCX, copie para o /boot/splash.pcx, e crie um /boot/loader.rc, da forma como foi indicado anteriormente; depois crie um /boot/loader.conf com o seguinte:
splash_pcx_load="YES" bitmap_load="YES" bitmap_name="/boot/splash.pcx"
Agora você só precisa de uma imagem, para servir de “Splash Screens”. Pra isso, dê uma navegada na galeria disponível em http://www.baldwin.cx/splash/.
Pode. Basta usar o xmodmap(1) para redefinir a função das teclas.
Assumindo que todos os teclados “Windows®” sejam padrão, os códigos de mapeamento pras 3 teclas são:
115 - Windows, entre a tecla Ctr e a Alt do lado esquerdo.
116 - Windows, à direita a tecla AltGr.
117 - Menu, do lado esquerdo da tecla Ctrl esquerda
Por exemplo, para fazer com que a tecla Windows® esquerda imprima uma vírgula, faça o seguinte:
# xmodmap -e "keycode 115 = comma"
É provável que seu gerenciador de janelas tenha que ser reiniciado, para visualizar o resultado.
Pra forçar o carregamento automático do mapeamento das teclas Windows, coloque os comandos do xmodmap no arquivo ~/.xinitrc ou de preferência, crie um arquivo ~/.xmodmaprc e inclua as opções do xmodmap uma por linha, nesse arquivo. Depois adicione:
xmodmap $HOME/.xmodmaprc
No seu ~/.xinitrc.
Por exemplo, pode-se mapear as 3 teclas em questão para fazer o papel das teclas F13, F14, e F15, respectivamente. Dessa forma, seria fácil mapear as aplicações de forma que as teclas tivessem ações no seu sistema, como veremos agora.
Adicione o seguinte conteúdo, no arquivo ~/.xmodmaprc.
keycode 115 = F13 keycode 116 = F14 keycode 117 = F15
Se o gerenciador de janelas em questão for o fvwm2, por exemplo, pode-se mapear as teclas de forma que o F13 minimize (ou maximize) a janela que o cursor está apontando, a tecla F14 de forma que ela traga a janela marcada pelo cursor para frente (ou volte para trás, caso já esteja à frente), e o F15 pode alternar o menu da área detrabalho principal, o que é bem útil quando a tela não é visível.
As seguintes definições no ~/.fvwmrc implementam a configuração acima descrita:
Key F13 FTIWS A Iconify Key F14 FTIWS A RaiseLower Key F15 A A Menu Workplace Nop
A disponibilidade da aceleração 3D depende da versão do XFree86 e da placa de vídeo. Caso a placa seja NVIDIA, verifique a página da Iniciativa de Driver NVIDIA para o FreeBSD, que discute a aceleração 3D em chips NVIDIA com XFree86-4. Pra outras placas em conjunto com o XFree86-4, incluindo a Matrox G200/G400, a ATI Rage 128/Radeon, as 3dfx Voodoo 3, 4, 5, e Banshee, refira-se à página sobre Renderização Direta do XFree86-4 no FreeBSD. Usuários do XFree86 na versão 3.3 podem usar o port do Utah-GLX que pode ser encontrado em graphics/utah-glx para conseguir alguma (limitada) aceleração 3D para o OpenGL em placas Matrox Gx00, ATI Rage Pro, SiS 6326, i810, Savage, e algumas NVIDIA antigas.
Este, e outros documentos, podem ser obtidos em ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
Para perguntas sobre FreeBSD, leia a documentação antes de contatar <questions@FreeBSD.org>.
Para perguntas sobre esta documentação, envie e-mail para <doc@FreeBSD.org>.