Orange Pi HDMI/DVI output on Samsung SyncMaster T220

Playing with my Orange Pi Mini board, (using a DVI/HDMI conector) the monitor was unable to display the original 1280×720 resolution, cutting the image. I couldn’t get the monitor’s maximum resolution (1680×1050) yet, but managed to configure the boot environment variables to set up a 1280×1024, which worked OK (at least it shows all the text).

In the boot partition (on bananian 15.01, it was /dev/mmcblk0p1), you must edit the uEnv.txt file. You should find something similar to:

...
bootargs=console=ttyS0,115200 console=tty0 sunxi_g2d_mem_reserve=0 sunxi_ve_mem_reserve=0 disp.screen0_output_mode=EDID:1280x720p50 hdmi.audio=EDID:0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
...

and modify the disp.screen0_output_mode variable to the following:

...
bootargs=console=ttyS0,115200 console=tty0 sunxi_g2d_mem_reserve=0 sunxi_ve_mem_reserve=0 disp.screen0_output_mode=EDID:1280x1024p60 hdmi.audio=EDID:0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
...

Update:

There are some distros (such as Lubuntu and Debian) for Orange Pi where the correct bootarg variable to be changed is disp.screen1_output_mode instead.

In the case of Lubuntu, the uEnv.txt file is placed in another partition (/dev/mmcblk0p1). You can just mount it somewhere:


# mount /dev/mmcblk0p1 /mnt

add the disp.screen1_output_mode definition to the bootargs:

# vi /mnt/uEnv.txt
# sync
# umount /mnt

and reboot to make the changes effective:

# reboot

For Debian, the bootargs definition is found in /boot/boot.cmd, and after modify it, you should recreate /boot/boot.scr file with the following:

# mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

Publicidade

Remote audio server with Pulseaudio

In the session running pulseaudio in the machine that has a sound board (in this example, it has IP address 192.168.0.25), run the following command to accept audio from the network 192.168.0.0/24:

$ pactl load-module module-native-protocol-tcp 'auth-ip-acl=127.0.0.1;192.168.0.0/24' auth-anonymous=1

In the client session that run the program, export the PULSE_SERVER address, like this:

$ PULSE_SERVER=192.168.0.25 chromium &

Fedora 17 and 18: How to disable auto suspend when laptop lid is closed

Right after install Fedora 17 with LXDE (and update to 18), I noticed this annoying behavior when closing the laptop lid: it just stop replying pings and went to sleep, even with the AC power plugged in.

Since I didn’t have the GNOME config tools available here (and didn’t want to install tons of libs and applications just to config this), I investigated a bit and found that logind was the culprit for that. After google a bit more, I’ve found this procedure that solves the issue:

All you have to do is edit the file /etc/systemd/logind.conf (as root) and uncomment/set the variable “HandleLidSwitch” to “ignore”, as in the example below:

[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
#Controllers=
#ResetControllers=cpu
#InhibitDelayMaxSec=5
#HandlePowerKey=poweroff
#HandleSuspendKey=suspend
#HandleHibernateKey=hibernate
HandleLidSwitch=ignore
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes


With this change, reboot your system (or just restart your display manager (thanks dmelo87)) and feel free to close your laptop lid that it will no longer go to sleep inadvertently.

Source: https://bbs.archlinux.org/viewtopic.php?id=154368

SLiM: Um gerenciador de login bonito e barato

<em meio a gigantescas teias de aranha… />

Quando você procurava gerenciador de login gráfico para carregar seu window manager bem leve e simples, quase sempre se deparava com alternativas de “peso” como GDM ou KDM ou outras não tão atraentes aos olhos como o humilde XDM. (Vale lembrar que os usuários do Enlightment estão a salvo com seu belo Entrance).
Pois agora temos mais uma boa alternativa: SLiM, como o próprio nome já diz, é um login manager que preza pela leveza e simplicidade, sem deixar de ser bem agradável visualmente.

O SLiM conta ainda com suporte a temas e um arquivo de configuração bastante simples.
O pacote é facilmente instalado no Gentoo Linux através do emerge. Há ainda um ebuild contendo temas.

emerge slim slim-themes

No Debian, também já se encontra pacote disponível para instalação via apt na versão Sid (unstable) e Lenny (testing).

aptitude install slim

Porém, no caso do Debian (para ambas versões), há um bug no carregamento das variáveis de locale para as sessões abertas pelo SLiM. Felizmente, esta falha pode ser facilmente corrigida exportando as variáveis no script de inicialização. Isso é feito incluindo as linhas seguintes no princípio do script de inicialização /etc/init.d/slim (logo abaixo das linhas de comentário no cabeçalho):

if [ -r /etc/default/locale ]; then
. /etc/default/locale
export LANG LC_ALL LANGUAGE
fi

Com isso, a partir da próxima inicialização do SLiM, sua sessão terá os locales corretamente definidos.

Modificando o driver fglrx para nova versão do Xorg (Debian Sid)

Drivers proprietários são realmente problemáticos. Nos últimos dias tive um bom exemplo disso, quando o X em meu Debian Sid amd64, configurado para utilizar o driver proprietário da ATI, fglrx, inesperadamente parou de funcionar. Através do log, verifiquei a seguinte mensagem:


X version mismatch - detected X.org 1.3.0.0, required X.org 7.1.0.0


O “problema” na verdade era que o Debian havia alterado a numeração no versionamento do pacote xserver-xorg-core em seu branch ‘unstable’ e o driver fglrx utilizava justamente essa numeração (como através de um `/usr/bin/Xorg -version`) para verificar a compatibilidade. Bem, a primeira vista, parecia que se tratava de algo trivial, que um simples ajuste em determinado ‘#define’ no fonte bastaria, mas… onde estão os fontes? Lamentavelmente, a ATI não os disponibiliza, entregando apenas os binários, justamente onde se encontra essa verificação.

Porém, procurando um pouco mais, supreendentemente encontrei um pessoal que estava corrigindo esse problema de uma forma bem, hã, interessante. Basta realizar algumas minúsculas alterações no seu binário e pronto. A teoria explicada parece bem simples (basta substituir umas instruções ‘js’ por ‘jns’), mas longe de ser algo que eu seja capaz de fazer com tanta facilidade :p

But talk is cheap… Vamos ao que interessa.

Primeiramente, verifiquei que a versão do driver fglrx que eu possuia instalado não estava na listagem de versões que o script corrigia e precisei baixar do site da AMD/ATI o instalador com a versão mais recente do driver (8.36.5).
Para instalar a nova versão do driver, segui este roteiro desenvolvido para o Ubuntu Edgy. Desinstalei a versão anterior e gerei os pacotes .deb a partir do instalador com:


# chmod +x ati-driver-installer-8.36.5-x86.x86_64.run
# ./ati-driver-installer-8.36.5-x86.x86_64.run --buildpkg Debian/sid


Removi os arquivos fglrx-* do diretório /usr/src e, utilizando dpkg, instalei os pacotes .deb gerados pelo instalador:


# dpkg -i fglrx-kernel-src_8.36.5-1_amd64.deb
# dpkg -i fglrx-amdcccle_8.36.5-1_amd64.deb
# dpkg -i fglrx-driver_8.36.5-1_amd64.deb
# dpkg -i fglrx-driver-dev_8.36.5-1_amd64.deb


Após a instalação dos pacotes, execute ‘apt-get -f install’ a fim de corrigir qualquer provável problema com dependências.
Em seguida, utilizando module-assistant, compilei e instalei a nova versão do driver automaticamente:


# module-assistant build fglrx
# module-assistant install fglrx
# depmod -ae


Agora sim, necessitamos modificar os binários. No script http://kanotix.com/files/install-fglrx-debian.sh você poderá encontrar o trecho em sed para alterar o driver na versão desejada. No meu caso (versão 8.36.5), bastou aplicar as linhas abaixo ao arquivo fglrx_drv.so (localizado no diretório /usr/lib/xorg/modules/drivers/).


# sed -i 's/\xe8\xaa\x72\xfe\xff\x85\xc0\x7f\x23/\xe8\xaa\x72\xfe\xff\x85\xc0\x90\x90/' /usr/lib/xorg/modules/drivers/fglrx_drv.so
# sed -i 's/\x0f\x88\x3b\x08\x00\x00/\x90\xe9\x3b\x08\x00\x00/' /usr/xorg/modules/drivers/fglrx_drv.so


Sim, isto é feio; os próprios criadores concordam (” Our patches are just ugly hacks…”), mas “funciona” :D.
Feito isso, agora basta alterar o seu arquivo /etc/X11/xorg.conf para utilizar o driver fglrx novamente, reiniciar o X e voilá.

Fonte:
http://www.rage3d.com/board/showthread.php?t=33889029
http://wiki.cchtml.com/index.php/Ubuntu_Edgy_Installation_Guide#Method_2:_Install_the_8.35.5_Driver_Manually

Montando dispositivos automaticamente no GNU/Linux

Com a popularização de dispositivos de armazenamento móveis, como pen drives e mp3 players, câmeras digitais, entre outros, além dos já “antigos” CDs e DVDs, torna-se interessante possuir um sistema que facilite a interação com esses equipamentos. Hoje, sistemas GNU/Linux apresentam diferentes opções que se adequam de acordo com a necessidade e disponibilidade do usuário, sem precisar, por exemplo, ficar modificando o arquivo de configuração /etc/fstab.

Usuários Gnome têm o gnome-volume-manager, que em conjunto com o gnome-volume-properties automatiza a montagem desses dispositivos. Caso você possua o Gnome instalado em sua máquina e utilize um outro window manager, basta incluir no arquivo .xinitrc, o comando para inicializar o programa em modo background:

gnome-volume-manager &

Já para os que preferem uma interface mais leve, minimalista ou sofrem com limitações de hardware, temos o ivman. Atualmente encontrado nas distribuições mais conhecidas (testei em Debian e Gentoo), o ivman, assim como o gnome-volume-manager, dependem de uma camada de outros softwares que realizam o controle desses dispositivos em mais baixo nível, como o hal (Hardware Abstraction Layer), dbus (sistema de comunicação entre aplicativos) e udev (responsável pelo gerenciamento dos devices para o espaço do usuário).

Testei o ivman nas distribuições Debian Etch e Gentoo sem problemas: atualmente o pacote encontra-se tanto nos repositórios testing do Debian quanto no Portage do Gentoo.

A instalação foi simples em ambas distribuições. Como já abordado anteriormente, para o funcionamento do ivman são necessários os aplicativos dbus e hal, que funcionam como daemon do sistema. Portanto, no Gentoo, é necessário incluir o chamada para o hald na inicialização, com o comando:

rc-update add hald default

Após instalado, os usuários que utilizarão o ivman e poderão desmontar os pontos de montagem deverão ser adicionados ao grupo plugdev. Lembre-se de logar novamente para que as alterações de grupos tenham efeito.

O ivman pode ser configurado para ser chamado na inicialização do sistema como root (como funciona por padrão no Debian, por exemplo) ou como processo do usuário. Para isto, basta rodar:

ivman &

Como sugestão, pode-se adicionar esse comando, em seu arquivo .profile ou .xinitrc.

Com o ivman rodando, você tem seus dispositivos montados automaticamente no diretório /media ou no ponto de montagem especificado no arquivo /etc/fstab.

Para desmontar os dispositivos, utilize normalmente o comando umount, para o caso de pontos de montagem especificados no arquivo /etc/fstab, ou pumount, para pontos de montagem criados dinamicamente, como são utilizados normalmente as pen drives e similares.

Observação: caso o ivman tenha sido inicializado como root (configuração default no Debian), lembre-se de adicionar a opção “users” na configuração seus dispositivos móveis incluídos no /etc/fstab (como é o caso normalmente dos drives de cd/dvd), para possibilitar que o usuário normal desmonte o dispositivo.

Logicamente, há ainda a possibilidade de configurações mais específicas do ivman, como a customização de regras de montagem para chamar aplicativos de acordo com o dispositivo detectado.

Fontes:
http://www.xaprb.com/blog/2006/05/20/how-to-auto-mount-removable-devices-in-gnulinux/
http://www.gentoo.org/doc/pt_br/kde-config.xml
http://gentoo-wiki.com/HOWTO_ivman

Comentários no vim

Para esta pequena rotina que facilita na inclusão e remoção comentários em estilo C/C++ e PHP (com as duas barras a esquerda do texto), fiz uma razoável busca na listagem de scripts do vim e, não encontrando, parti pra “leitura” do famigerado :help, em busca de algo que me ajudasse. Nessas, acabei arranjando uma solução na família de tratamento de exceções (é, tem até isso!) que acabou servindo muito bem nesse caso:

" Função para comentar linhas em C/C++ e PHP
fu! ComenteCPHP()
try
execute 's/^\(\( \|\t\)*\)\/\//\1'
catch
execute 's/\(\( \|\t\)*\)/\1\/\/'
endtry
endfu
" Mapeando teclas de atalho
map <C-c> :call ComenteCPHP()<cr>


Basta acrescentar esse trecho acima ao seu .vimrc, encontrado em seu diretório de usuário. Na última linha, eu ainda mapeei a combinação ‘CTRL+c’ para executar a função de comentário, mas logicamente você pode trocar a combinação de acordo com a preferência.
E com pequenas alterações já se tem algo pra auxiliar no comentarios em estilo bash script e python (com o símbolo ‘#’ a esquerda do texto):

" Função para comentar linhas em bash
fu! ComenteBash()
try
execute 's/^\(\( \|\t\)*\)\#/\1'
catch
execute 's/\(\( \|\t\)*\)/\1\#'
endtry
endfu
" Mapeando teclas de atalho
map <C-x> :call ComenteBash()<cr>


Vale lembrar que você ainda pode comentar/descomentar várias linhas de uma só vez, fazendo a seleção da linha com ‘V’.

#0

1,2,3,4

Aqui começa?