Faz alguns dias, comecei a ter o prazer de assistir os vídeos do YouTube em cor-de-rosa:
Principalmente no recente instalado Ubuntu 64 bits. A princípio achei que era um dos tão mencionados problemas de flash em Linux 64, mas pude ver em alguns fóruns que isso tem afetado todos as versões de Linux pra Intel, tanto de 32 quanto 64 bits.
Consegui amenizar um pouco o problema com as dicas que encontrei aqui:
http://www.webupd8.org/2011/03/fix-pinkred-youtube-videos-bug-using.html
Mas o problema persiste. Mais uma boa razão pra abandonar logo o flash, que é proprietário e depende unicamente da Adobe pra corrigir.
Com o lançamento do encurtador eri.cx, alguns novos desafios vão surgindo como o gerenciamento do mesmo. Apesar das limitações, gosto de utilizar o MRTG para monitorar máquinas, ainda mais quando não posso demandar muito tempo administrando as mesmas.
Existem inúmeras ferramentas de monitração, como Nagios, mas nada é tão simples quanto o MRTG. Mesmo tendo sido criado pra tráfego de rede via snmp, qualquer coisa pode ser monitorada por ele, sabendo que a aquisição de dados ocorre a cada 5 minutos somente.
Se eu precisasse de algo com menor tempo ou maior granularidade, com certeza mudaria pra RRDtool. Mas isso já daria muito mais trabalho e iria de encontro ao meu princípio de manter a coisa simples.
Pois eu tenho um script bem antigo, em Python, que gera a saída formatada para uso no MRTG pra monitorar qualquer coisa. De discos à carga do sistema. Basicamente a saída é:
INPUT OUTPUT UPTIME HOSTNAME
Pra casos como o disco, pode-se usar tanto a quantidade de espaço livre quanto ocupado pra INPUT e OUTPUT. Ou deixar INPUT e OUTPUT iguais, mostrando a quantidade de disco usado, por exemplo, em porcentagem. Isso somente pra ilustrar os muitos usos do MRTG. Como exemplo, logo abaixo, como configurar o MRTG para monitorar a carga do sistema, através da saída do comando "uptime". Uma vez que MRTG não monitora números flutuantes, os valores são multiplicados por 100.
Target[load]: `/home/helio/bin/system.py load`
Options[load]: gauge,noinfo, nopercent, growright, unknaszero, nobanner
MaxBytes[load]: 2000
Title[load]: System load (100x)
PageTop[load]: <H1>System load (100x)</H1>
<TABLE>
<TR><TD>System:</TD><TD>eri.cx</TD></TR>
<TR><TD>Maintainer:</TD><TD>Helio Loureiro</TD></TR>
<TR><TD>Interface:</TD><TD>System load (10x)</TD></TR>
<TR><TD>IP:</TD><TD>none</TD></TR>
<TR><TD>Max wan traffic:</TD>
<TD>2 Mbps</TD></TR>
</TABLE>
YLegend[load]: System load (10x)
ShortLegend[load]: load (10x)
Na monitoração do eri.cx, acabei com uma imagem do site parecida com essa abaixo:
A finalidade desse artigo não é entrar muito a fundo na questão de configuração do MRTG ou de scripts de monitoração, mas discutir sobre a limitação de página criada pelo MRTG. E como resolvi isso. Como é possível notar, o MRTG não se integrou ao design da página corretamente pois não existem muitas opções pra adicionar CSS ou javascript no mesmo.
Na configuração do MRTG, adicionei apenas as entradas abaixo:
Extension[_]: php
AddHead[_]: <!--?php // Start YOURLS engine
require_once( dirname(dirname(__FILE__)).'/includes/load-yourls.php' );
require(dirname(dirname(__FILE__)).'/user/config.php' );
yourls_html_head();
?-->
<p><br>
</p>
<div align="center">Change already begun<br>
<br>
<br>
<span style="font-weight: bold;" mce_style="font-weight: bold;">
PageFoot[_]: <br>
</span></div>
<p><br>
</p>
<p><br>
</p>
<--?php
yourls_html_footer();
?-->
Para solucionar isso, alterei a saída para:
Extension[_]: txt
removendo todo o restante. Em seguida fiz uma alteração no código da página em PHP, para incluir o conteúdo do arquivo gerado:
<?php
$target = "load.txt";
$FD = fopen($target, "r");
$DATA = fread($FD, filesize($target));
fclose($FD);
#echo $DATA;
$status = 0;
$content = explode("\n", $DATA);
foreach ($content as $line) {
if (ereg("<body>", $line)) {
$status++;
}
if (ereg("</body>", $line)) {
$status = 0;
}
if ($status) {
echo $line."\n";
}
}
?>
Isso fez com que a página gerada pelo MRTG ficasse dentro do PHP corretamente. Como pode ser visto abaixo:
Já faz algum tempo que comprei uma máquina da STI, Semp Toshiba, do tipo "computador popular". Comprei pelo preço baixo e pelo fato de vir com Linux instalado (um é causa o outro, efeito, mas não sei qual é qual). Isso uns 3 anos atrás. Nunca fui muito adepto de equipamento pré-montado, mas nessa época já estava meio cansado de ficar entrando em boca-de-hardware na Santa Ifigênia pra montar um computador decente.
A grande surpresa foi a qualidade do acabamento do computador: teclado excelente e macio, mouse ótico, entradas de leitor pra cartões de memória (todos os tipos até onde testei), caixas de som com amplificador energizado via USB, 2 GB de RAM, 250 GB de disco SATA e drive gravador de DVD. Realmente um hardware legal (lembre-se que isso foi há 3 anos atrás).
Na época veio com Insigne Linux instalado. Acho que durou uns 5 minutos rodando, o tempo de olhar a cara do sistema, até eu instalar um Ubuntu por cima. Desde então tenho usado o mesmo com Linux 32 bits.
No final do ano passado, por volta de meados de dezembro, só então notei uma mensagem de hardware no boot: EM64T. Sabia que era um Core 2 duo, mas achei que era só isso. Com algumas mensagens no Twitter, algums amigos confirmaram que a CPU era mesmo 64 bits, mas recebi muitas críticas negativas sobre o mesmo em Linux, principalmente em relação à crashes de aplicativos, principalmente em sites com flash. Resolvi então manter os 32 bits.
Recentemente li um artigo dizendo que o Linux fracassou miseravelmente na arquitetura 64 bits. O texto realmente está certo na abordagem do Linux em relação à nova arquitetura: dizia-se que o Windows estava fadado ao esquecimento dos 32 bits e que Linux iria dominar o desktop pois sua migração era tão fácil quanto a instalação em uma torradeira. E o que vemos atualmente é exatamente o oposto disso: várias recomendações pra se manter Linux em 32 bits por questões de estabilidade. No ponto em que li essa frase, confesso que senti uma pontada de culpa, pra não dizer vergonha.
Por um problema com um aplicativo de VPN da empresa, não posso migrar meu laptop pra 64 bits (processador Intel Core i3) e tenho de continuar envergonhado, mas
já o meu desktop... resolvi arregaçar as mangas e instalar. Parti pra instalação do Ubuntu 10.10 em arquitetura AMD64.
Como sempre, dpkg salvou o dia com a lista de aplicativos previamente instalados (dpkg --get-selections >myselections). A migração, ou reinstalação, ocorreu sem demais problemas. Um backup do /etc, bases do mysql e do diretório /root e rapidamente tive o sistema restaurado, e em 64 bits.
Para batizar a *nova* máquina dei o nome de goosfraba, em homenagem ao filme do "tratamento de choque" com Jack Nicholson e Adam Sandler (final meio infeliz, mas em geral é engraçado).
Até o momento a goosfraba tem funcionado melhor que na arquitetura 32 bits: mais rápido. Tenho a sensação de que estava dirigindo uma Audi A3 turbo, mas que antes só colocava até a 4a marcha. E agora vou até a 7a. Mas espero problemas com o Flash Player, pois sei que apesar do Linux não ter fracassado em 64 bits, também não foi o sucesso desejado.
Referências:
[1] What happened to "World Domination 201"? (ou Linux fracassou miseravelmente em 64 bits)
Durante a Campus Party Brasil 2011 (#cpbr4) trabalhei como voluntário na área de Software Livre. Entre várias coisas legais que ocorreram, uma foi o fato do Maddog sempre ficar próximo de nós. E não foi que bem no dia que fiz uma piada com ele, falando que tinha lugar na bancada da Microsoft - esse dia estava difícil achar uma cadeira e cabo de rede sobrando, veio uma repórter do G1 e escreveu sobre ambos: Maddog e minha piada.
São os meus 5 minutos de fama geek.
Como alguém já disse antes: nem todo restart é bom.
Mas infelizmente isso é necessário em alguns momentos. E meu roteador wireless Netgear WGR614 v7 chegou nesse ponto. Diariamente ele exige um leve "restart" pra poder funcionar direito na parte wireless, do contrário nada consegue se conectar nele: notebook, netbook, xbox360, celulare
s...
Deve ser alguma feature chinesa pois todos os produtos de lá padecem do mesmo mal, que sempre começa a aparecer depois de mais de 1 ano de uso. Deve ser uma estratégia de marketing pra nos forçar a fazer um upgrade. Igual ao Windows.
Mas voltando ao problema e sua solução, resolvi partir pra um restart automático (restart do bom, pra deixar claro). Então primeiramente descobri que o roteador faz um restart ao salvar as configurações de wireless. Em seguinda utilizei o Add-on do firefox, Live HTTP Headers, que ajudou a capturar os dados enviados ao equipamento:
POST /wlg_adv.cgi HTTP/1.1
Host: 192.168.34.1
User-Agent: Mozilla/5.0 (X11; U; Linux i686; pt-BR; rv:1.9.2.13) Gecko/20101206 Ubuntu/10.04 (lucid) Firefox/3.6.13
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: pt-br,pt;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://192.168.34.1/WLG_adv.htm
Authorization: Basic ZnVjazp5b3U=
Content-Type: application/x-www-form-urlencoded
Content-Length: 60
enable_ap=enable_ap&ssid_bc=ssid_bc&enable_wmm=0&Apply=Apply
O router exige autenticação, o que pode ser visto pela entrada "Authorization: Basic ZnVjazp5b3U=", que não usa criptografia mas um encode de base 64.
Então criei um script pra fazer o trabalho sujo e enviar os mesmos dados ao roteador, mas em Python.
#! /usr/bin/env python
# Script to restart daily my wireless router
# by Helio Loureiro
import httplib
import base64
import urllib
from time import ctime
user = "admin"
passw = "password"
host = "192.168.0.1"
def GetAuth(user = "user", passw = "passwd"):
auth = user + ":" + passw
return base64.encodestring(auth)[:-1]
headers = {
"Host" : host ,
"User-Agent" : "Mozilla/5.0 (Python)",
"Accept" : "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" ,
"Accept-Language" : "pt-br,pt;q=0.8,en-us;q=0.5,en;q=0.3",
"Accept-Encoding" : "gzip,deflate",
"Accept-Charset" : "ISO-8859-1,utf-8;q=0.7,*;q=0.7",
"Referer" : "http://192.168.34.1/WLG_adv.htm" ,
"Authorization" : "Basic " + GetAuth(user, passw),
"Content-Type" : "application/x-www-form-urlencoded"
}
post_params = {
"enable_ap" : "enable_ap" ,
"ssid_bc" : "ssid_bc",
"enable_wmm" : "0",
"Apply" : "Apply"
}
params = urllib.urlencode(post_params)
web = httplib.HTTPConnection(host)
web.request("POST", "/wlg_adv.cgi", params, headers)
response = web.getresponse()
if (response.status == 200):
print "[" + ctime() + "] Wireless router restarted successfully"
else:
print "[" + ctime() + "] Restart FAILED"
data = response.read()
web.close()
Os dados necessários são usuário, senha e IP do roteador wireless (user, passw e host). Adicionando o script à crontab, o roteador será reiniciado diariamente, aumentando um pouco mais a longevidade de tal produto Chinês.
Hoje, no meio das minhas férias, dei uma conectada na rede da empresa pra verificar uns mails (de uns amigos perdidos que mandaram pro endereço errado).
Por lá o comunicador oficial é o Lotus Sametime, da IBM. Sempre conectei utilizando o Pidgin, um dos melhores clientes multi-serviço para IMs que conheço, e utilizando o módulo meanwhile pra conectar no servidor de sametime. Qual não foi minha surpresa ao descobrir que o mesmo não funcionava mais. Apenas recebia uma mensagem de "Version Mismatch" no rodapé do Pidgin e a conexão se encerrava.
Felizmente encontrei fácil uma solução no site do Pidgin, no TT#12623. A solução sugere que o meanwhile seja configurado pra esconder sua identificação (hide), o que já era feito. Então editei o arquivo ~/.purple/accounts.xml e adicionei somente uma linha com a informação abaixo:
<settings>
<setting name='fake_client_id' type='bool'>1</setting>
<setting name='client_minor' type='int'>8511</setting>
<setting name='port' type='int'>1533</setting>
<setting name='force_login' type='bool'>1</setting>
<setting name='server' type='string'>sametime.internal.server.com</setting>
</settings>
Funcionou xuxu beleza. Reiniciei o Pidgin e imediatamente conectei e pude ver os contatos online.
Somente algumas pessoas sabem, mas eu criei um encurtador de url, o http://eri.cx. A idéia é que seja usado para encurtar as URL da empresa. E também serviu pra mostrar que algo tão simples quanto o encurtador não demanda tanto trabalho, nem pessoas.
Essa última afirmação pode soar estúpida, mas em grandes corporações não. Como somos cercados por idiotas engravatados, algumas atitudes como essa, de criar algo que precisávamos, são necessárias.
Mas eu mesmo estava meio frustrado com o encurtador uma vez que seu uso exigia (na verdade eu que achava que exigia) a compilação dos módulos do Choqok para uso no Twitter, entre outros. O Choqok, para quem não conheçe, é um ótimo cliente KDE4 pra Twitter.
Aproveitando minhas sagradas férias, resolvi olhar um pouco mais a documentação do Yourls, projeto no qual o eri.cx é baseado, pra verificar se isso não era possível de uma forma mais simples. Vi que existe uma API pra isso, a yourls-api.php, mas seu uso não era tão simples quanto eu achava. Ou era e eu não percebi. Mas enfim deu certo e aqui estou descrevendo como configurar.
No próprio Choqok, na aba de Configurações (ou Settings, se estiver em inglês como o meu), clique no último item, Configure Choqok. Ele abrirá a tela de configuração, onde deve-se ir à aba de "encurtadores de url", ou "url shortening". Nessa pasta, selecione o encurtador do tipo Yourls e em seguida clique na ferramenta ao lado, pra configurar.
Na parte de "Yourls API URL", entre como no formato mostrado acima: http://eri.cx/yourls-api?
Foi difícil acertar essa configuração, uma vez que a documentação não é muito clara tanto do lado do Yourls quanto do Choqok, mas deu certo. Precisei dar uma olhada no tráfego web, com o wireshark, pra poder verificar o formato enviado e recebido, uma vez que tenho outra API, a http://eri.cx/api.php, que retorna a URL que será encurtada sem mais nada (exemplo, algo como enviando http://eri.cx/api.php?url=http://helio.loureiro.eng.br retorna http://eri.cx/1).
helio@shibboleet:~$ lynx -dump " http://eri.cx/api.php?url=http://helio.loureiro.eng.br"
http://eri.cx/1
helio@shibboleet:~$ lynx -dump -source " http://eri.cx/yourls-api.php?action=shorturl&format=xml&url=http://helio.loureiro.eng.br"
<?xml version="1.0" encoding="iso-8859-1"?>
<result>
<status>fail</status>
<code>error:url</code>
<url>
<keyword></keyword>
<url>http://helio.loureiro.eng.br</url>
<title>Welcome to the Frontpage</title>
<date>2010-11-09 20:45:13</date>
<ip>198.24.5.13</ip>
<clicks>9</clicks>
</url>
<message>http://helio.loureiro.eng.br already exists in database</message>
<title>Welcome to the Frontpage</title>
<shorturl>http://eri.cx/1</shorturl>
<statusCode>200</statusCode>
</result>
O próximo passo é criar um descritivo de uso para configuração de ferramentas externas. Difícil que preciso fazer isso pra ferramentas em Windows...
Pra quem achar as configurações muito parecidas com o http://miud.in, não é mera coincidência não. Eu realmente pedi ajuda e conselhos ao seu criador, Eduardo Maçan, e sempre olho o mesmo pra ver como o Maçan fez as configurações, inclusive das ferramentas.
Meio tosco, meio fora de lugar, mas adicionei os links do AdSense ao site.
Não espero uma enormidade de retorno, mas... acho que não fará mal algum também.
Gostaria de adicionar ao topo da página, mas tenho encontrado muitas dificuldades de layout com esse tema no Joomla. Talvez isso mostre que já é hora de trocar o mesmo.
Aproveitando as resoluções de ano novo, alterei o template de CSS da página principal do site. Editei o "templates/ja_purity/css/template.css" e fiz a seguinte alteração:
table.contentpaneopen {
border: none;
border-collapse: collapse;
border-spacing: 0;
color: #FFFFFF;
}
Isso melhorou as fontes que aparecem na parte de cima, logo abaixo do logo do site, com informações em branco (cor #FFFFFF).
2011 está aí, férias também, então nada mais justo que acertar essas pequenas pendências de 2010.
= Um pequeno adendo =
Depois de publicar, vi que o links continuavam escuros. Fiz mais um pequeno adendo ao mesmo arquivo:
table.contentpaneopen a {
color: #FFFFFF;
}
Como já tinha comentado no post anterior, adquiri um laptop novo. Decidi fazer isso pra me livrar da chateação corporativa do laptop da empresa. Agora posso utilizar Linux ou FreeBSD, ou o que eu quiser, incondicionalmente, sem amolação. No momento estou com Linux, Ubuntu pra ser mais preciso, mas com certeza gostaria de rodar FreeBSD nele, o que não farei até que o suporte pra suspend/hibernate esteja mais maduro.
Devido às restrições dos aplicativos da empresa, que estão empacados em 32 bits, optei por utilizar Ubuntu X86 ao invés do AMD64. Se perdi desempenho, nem percebi. Habilitei o kernel com PAE, pra endereçar os 4 GB de memória e tudo está funcionando bem.
Mas vamos a uma descrição um pouco mais completa do laptop:
Nem vou detalhar sobre os drivers pois o Ubuntu, ou mais precisamente o Kubuntu, reconheceu tudo de primeira. Vídeo, webcam, wireless, tudo mesmo saiu funcionando com uma pequena exceção: o ACPI de eventos de bateria. No momento o sistema não detecta que está na tomada ou não, não ativando automaticamente os modos de conservação de energia.
Outro detalhe ruim é o teclado. Veio de novo num formato bizarro, não ABNT2, apesar do manual jurar ser um. Resolvi isso da forma mais lusitana possível (ou patolonização, pra quem conheçe o Patola), cobrindo as teclas - pra não me confundir - e utilizando o formato us_intl. Existiam outras opções, como re-mapear o teclado com xmodmap, mas deixar o teclado coberto ficou mais engraçado e ainda por cima evita que os "não iniciados" tentem usar meu laptop.
A bateria, de 6 células, devia se candidatar a Deputado ou outro cargo público, pois jura trabalhar incansávelmente por todo tempo possível sem eletricidade, alcançando até 6 horas de autonomia. Chega, quando tanto, a no máximo 3 horas, isso utilizando o perfil de "powersave". No momento tenho deixado a bateria descarregar até 10% antes de religar na tomada, pra tentar aumentar sua vida útil.
Falando em tomadas, essa veio com o formato novo, de 3 pinos que não encaixam em lugar nenhum. Felizmente consegui trocar o "rabixo" da tomada pelo do HP, que ainda é do formato antigo. E provavelmente precisarei usar os 2 quando estiver na rua, pois a conexão de tomadas tornou-se uma aventura agora: nunca se sabe que padrão irá encontrar.
Dessa vez optei por criar somente uma partição criptografada, o "/home" e fazer um link de "/root", "/tmp" e "/usr/local/tmp" (onde guardava alguns arquivos de trabalho) para esse mesmo diretório. Anteriormente todos já eram criptografados, mas isso exigia que eu entrasse com 3 senhas de partição durante o boot. Agora foi reduzido para somente 1 única vez. A recuperação de dados levou quase um dia, pois fiz a sincronização com o HD externo com "rsync" e extrai tudo com "tar". Tudo sobre partições XFS, que comecei a utilizar depois da sugestão do @eduardomacan, e que realmente funcionam muito bem para recovery rápido dos dados após um desligamento mal feito.
A análise é muito prematura, mas foi com o mesmo tempo que passei com o Dell, que devolvi. Com esse, vou ficar apesar do teclado.
Com certeza o tamanho e peso fizeram toda a diferença.
=-=-=-=-=
Powered by Blogilo
Um último post antes da ceia de Natal, pra fechar bem o dia.
Utilizando o kdenlive (grande dica via Twitter, nem lembro de quem, mas foi uma ótima dica), editei o longo e moroso vídeo original (os vários na verdade) e fiz um pequeno "unboxing" do laptop.
Provavelmente estarei escrevendo uma pequena comparação entre o Sony Vaio e o Dell.
Faz tempo que não escrevo nada por aqui, e confesso que estava com saudades.
Muito coisa mudou desde o meu último post. Shibboleet foi devolvida, migrei pra Ubuntu, comprei outro xbox360, vendi o anterior, criei um encurtador e a reta final do ano veio com tudo: projetos, mais projetos e muito mais projetos. Por isso escrevi tão pouco por aqui.
Começando pela Shibboleet, minha recém adquirida máquina, um Dell Vostro 3500, que foi sumariamente devolvida. Quando abri o pacote, realmente levei um susto: enorme. O equipamento era muito grande. Eu o imaginava como um PowerBook 13 polegadas, só que um *pouquinho* maior. Esse pouco era imenso, tanto em largura e comprimento quanto em altura, o que fazia meus pulso doerem com a digitação.
Invariavelmente tenho de mexer no xorg e acertar as frequências do monitor. Isso não é tão necessário no Linux, mas em FreeBSD é impossível ter uma tela gráfica usável sem o xorg.conf criado.
E testando no Dell Vostro 3500, só consigo uma tela 1024x768 justamente pela falta das frequências suportadas. Para corrigir isso, criei um script já faz alguns anos, mas não tinha publicado ainda. É baseado no xrandr e deve ser rodado a partir da tela gráfica, por pior que seja sua resolução.
#! /usr/bin/perl
$H_SIZE = 1280; # standard horizontal size
$V_SIZE = 800; # standard vertical size
@SIZES = qw( 1280 1152 1024 800 1200 1400 1600 1800 1900 1920 2048);
print "Section \"Modes\"\n\tIdentifier \"MyModes\"\n";
foreach $hs (@SIZES) {
$rate = $hs / $H_SIZE;
$vs = $V_SIZE * $rate;
foreach $freq qw(60 75) {
print "\t\t# $hs x $vs ($rate - $freq Hz)\n";
$output = `gtf $hs $vs $freq -x`;
foreach $line (split(/\n/, $output)) {
next if ($line !~ /[0-9a-z]/);
$line =~ s/ *//;
print "\t\t".$line."\n";
next if ($line =~ "#");
$line =~ s/\"//g;
$line =~ s/_(\d+)//g;
$line =~ s/Modeline //g;
$cmd = "xrandr --newmode ".$line ;
system($cmd."> /dev/null 2>&1");
#print $cmd."\n";
$modeline = $line;
$modeline =~ s/ .*//g;
#print "Mode: $modeline\n";
$cmd = "xrandr --addmode LVDS $modeline > /dev/null 2>&1";
system($cmd);
}
}
}
print "EndSection\n";
O resultado já sai no formato do xorg.conf:
Section "Modes"
Identifier "MyModes"
# 1280 x 800 (1 - 60 Hz)
# 1280x800 @ 60.00 Hz (GTF) hsync: 49.68 kHz; pclk: 83.46 MHz
Modeline "1280x800_60.00" 83.46 1280 1344 1480 1680 800 801 804 828 -HSync +Vsync
# 1280 x 800 (1 - 75 Hz)
# 1280x800 @ 75.00 Hz (GTF) hsync: 62.62 kHz; pclk: 107.21 MHz
Modeline "1280x800_75.00" 107.21 1280 1360 1496 1712 800 801 804 835 -HSync +Vsync
# 1152 x 720 (0.9 - 60 Hz)
# 1152x720 @ 60.00 Hz (GTF) hsync: 44.76 kHz; pclk: 67.32 MHz
Modeline "1152x720_60.00" 67.32 1152 1208 1328 1504 720 721 724 746 -HSync +Vsync
# 1152 x 720 (0.9 - 75 Hz)
# 1152x720 @ 75.00 Hz (GTF) hsync: 56.40 kHz; pclk: 86.63 MHz
Modeline "1152x720_75.00" 86.63 1152 1224 1344 1536 720 721 724 752 -HSync +Vsync
# 1024 x 640 (0.8 - 60 Hz)
# 1024x640 @ 60.00 Hz (GTF) hsync: 39.78 kHz; pclk: 52.83 MHz
Modeline "1024x640_60.00" 52.83 1024 1072 1176 1328 640 641 644 663 -HSync +Vsync
# 1024 x 640 (0.8 - 75 Hz)
# 1024x640 @ 75.00 Hz (GTF) hsync: 50.17 kHz; pclk: 67.44 MHz
Modeline "1024x640_75.00" 67.44 1024 1080 1184 1344 640 641 644 669 -HSync +Vsync
# 800 x 500 (0.625 - 60 Hz)
# 800x500 @ 60.00 Hz (GTF) hsync: 31.08 kHz; pclk: 31.33 MHz
Modeline "800x500_60.00" 31.33 800 824 904 1008 500 501 504 518 -HSync +Vsync
# 800 x 500 (0.625 - 75 Hz)
# 800x500 @ 75.00 Hz (GTF) hsync: 39.22 kHz; pclk: 40.17 MHz
Modeline "800x500_75.00" 40.17 800 832 912 1024 500 501 504 523 -HSync +Vsync
# 1200 x 750 (0.9375 - 60 Hz)
# 1200x750 @ 60.00 Hz (GTF) hsync: 46.62 kHz; pclk: 73.10 MHz
Modeline "1200x750_60.00" 73.10 1200 1256 1384 1568 750 751 754 777 -HSync +Vsync
# 1200 x 750 (0.9375 - 75 Hz)
# 1200x750 @ 75.00 Hz (GTF) hsync: 58.73 kHz; pclk: 93.96 MHz
Modeline "1200x750_75.00" 93.96 1200 1272 1400 1600 750 751 754 783 -HSync +Vsync
# 1400 x 875 (1.09375 - 60 Hz)
# 1400x875 @ 60.00 Hz (GTF) hsync: 54.36 kHz; pclk: 100.46 MHz
Modeline "1400x875_60.00" 100.46 1400 1480 1624 1848 875 876 879 906 -HSync +Vsync
# 1400 x 875 (1.09375 - 75 Hz)
# 1400x875 @ 75.00 Hz (GTF) hsync: 68.55 kHz; pclk: 128.87 MHz
Modeline "1400x875_75.00" 128.87 1400 1488 1640 1880 875 876 879 914 -HSync +Vsync
# 1600 x 1000 (1.25 - 60 Hz)
# 1600x1000 @ 60.00 Hz (GTF) hsync: 62.10 kHz; pclk: 133.14 MHz
Modeline "1600x1000_60.00" 133.14 1600 1704 1872 2144 1000 1001 1004 1035 -HSync +Vsync
# 1600 x 1000 (1.25 - 75 Hz)
# 1600x1000 @ 75.00 Hz (GTF) hsync: 78.30 kHz; pclk: 169.13 MHz
Modeline "1600x1000_75.00" 169.13 1600 1704 1880 2160 1000 1001 1004 1044 -HSync +Vsync
# 1800 x 1125 (1.40625 - 60 Hz)
# 1800x1125 @ 60.00 Hz (GTF) hsync: 69.84 kHz; pclk: 169.29 MHz
Modeline "1800x1125_60.00" 169.29 1800 1920 2112 2424 1125 1126 1129 1164 -HSync +Vsync
# 1800 x 1125 (1.40625 - 75 Hz)
# 1800x1125 @ 75.00 Hz (GTF) hsync: 88.05 kHz; pclk: 216.25 MHz
Modeline "1800x1125_75.00" 216.25 1800 1928 2128 2456 1125 1126 1129 1174 -HSync +Vsync
# 1900 x 1187.5 (1.484375 - 60 Hz)
# 1904x1187 @ 60.00 Hz (GTF) hsync: 73.74 kHz; pclk: 189.95 MHz
Modeline "1904x1187_60.00" 189.95 1904 2032 2240 2576 1187 1188 1191 1229 -HSync +Vsync
# 1900 x 1187.5 (1.484375 - 75 Hz)
# 1904x1187 @ 75.00 Hz (GTF) hsync: 92.92 kHz; pclk: 242.35 MHz
Modeline "1904x1187_75.00" 242.35 1904 2048 2256 2608 1187 1188 1191 1239 -HSync +Vsync
# 1920 x 1200 (1.5 - 60 Hz)
# 1920x1200 @ 60.00 Hz (GTF) hsync: 74.52 kHz; pclk: 193.16 MHz
Modeline "1920x1200_60.00" 193.16 1920 2048 2256 2592 1200 1201 1204 1242 -HSync +Vsync
# 1920 x 1200 (1.5 - 75 Hz)
# 1920x1200 @ 75.00 Hz (GTF) hsync: 93.97 kHz; pclk: 246.59 MHz
Modeline "1920x1200_75.00" 246.59 1920 2064 2272 2624 1200 1201 1204 1253 -HSync +Vsync
# 2048 x 1280 (1.6 - 60 Hz)
# 2048x1280 @ 60.00 Hz (GTF) hsync: 79.50 kHz; pclk: 221.33 MHz
Modeline "2048x1280_60.00" 221.33 2048 2192 2416 2784 1280 1281 1284 1325 -HSync +Vsync
# 2048 x 1280 (1.6 - 75 Hz)
# 2048x1280 @ 75.00 Hz (GTF) hsync: 100.20 kHz; pclk: 280.56 MHz
Modeline "2048x1280_75.00" 280.56 2048 2200 2424 2800 1280 1281 1284 1336 -HSync +Vsync
EndSection
Bastando somente adicionar os valores de frequência, cujo nome é "MyModes", dentro de "Monitor", como abaixo:
Section "Monitor"
DisplaySize 300 230
HorizSync 28-82
Identifier "Monitor1"
ModelName "1280X1024@60HZ"
Option "DPMS"
VendorName "--> LCD"
VertRefresh 50-60
UseModes "MyModes"
EndSection
Page 23 of 33
