Ok, então eu tenho um Framebuffer que pode ser mapeado em espaço de usuário, entrega as informações via "fbset -i" corretamente, porém é utilizado erroneamente pela API DFB.
Utilizando o hexdump /dev/fb0 -n 4, posso averiguar o que exatamente é escrito no framebuffer.
Pintando um retângulo de teste com a cor:
R: 0x01
G: 0x02
B: 0x03
A: 0x04
Deveria aparecer pelo hexdump
0x0102 0x0304
Porém, obtenho
0xFF01 0x0203
Isso dá a entender que 1) o DFB não entende o formato RGBA, apenas o ARGB 2) o canal A não está sendo corretamente utilizado
Averiguando rapidamente os fontes do DFB, parece que realmente uma solução possível é "ensinar" a API esta difícil tarefa. Mas ela é invasiva demais... será que consigo achar outra melhor?
quinta-feira, 25 de julho de 2013
terça-feira, 23 de julho de 2013
Linux-Fusion fundido
Depois de um bom tempo tentando resolver questões relativas ao funcionamento do DirectFB em sistemas mais atuais, hoje consegui chegar a uma configuração funcional.
O grande problema de instalar o DirectFB 1.4.5 é que seu modo multi-processo requer um módulo Linux chamado linux-fusion. As versões mais antigas desse módulo, durante o processo de instalação, verificam qual a versão do Kernel utilizada e setam um Makefile especial de acordo - o que gera problemas quando é utilizada as versão "comemorativas" do Linux 3.x.y pois esses Makefiles funcionam apenas com os 2.x.y.
A solução foi, a força bruta, achar uma versão desse módulo que não só funcionasse com o Kernel 3.x.y como também com a versão 1.4.5 do DirectFB . Testando uma-a-uma, encontrei a versão 8.8.1, e agora posso testar aplicações DFB em uma máquina Linux qualquer.
O próximo passo agora é criar a aplicação de test_bars para encontrar qual a configuração adequada do Framebuffer do Linux para o SoC. Ela imprimirá na tela 8 barras de cores, a fim de ver quais canais estão sendo invertidos, e um degrade de cinza para ver se não estou invertendo o endianness na leitura das cores.
O grande problema de instalar o DirectFB 1.4.5 é que seu modo multi-processo requer um módulo Linux chamado linux-fusion. As versões mais antigas desse módulo, durante o processo de instalação, verificam qual a versão do Kernel utilizada e setam um Makefile especial de acordo - o que gera problemas quando é utilizada as versão "comemorativas" do Linux 3.x.y pois esses Makefiles funcionam apenas com os 2.x.y.
A solução foi, a força bruta, achar uma versão desse módulo que não só funcionasse com o Kernel 3.x.y como também com a versão 1.4.5 do DirectFB . Testando uma-a-uma, encontrei a versão 8.8.1, e agora posso testar aplicações DFB em uma máquina Linux qualquer.
O próximo passo agora é criar a aplicação de test_bars para encontrar qual a configuração adequada do Framebuffer do Linux para o SoC. Ela imprimirá na tela 8 barras de cores, a fim de ver quais canais estão sendo invertidos, e um degrade de cinza para ver se não estou invertendo o endianness na leitura das cores.
quinta-feira, 18 de julho de 2013
Framebufer continua inserindo mas não remove.
Mais um dia se passa, e mais um dia com bugs terei amanhã.
Contextualizando: tenho que escrever um driver de vídeo usando a API de framebuffer do Linux. Esta tarefa já havia sido iniciada anteriormente, porém, esse driver utilizava um identificador de hardware para se "encaixar" dentro do sistema maluco de platform_device do Linux, declarando uma tabela de identificadores que possuía apenas o ID do controlador de memória.
Porém, o projeto mudou, o identificador sumiu, e o driver então parou de funcionar. A solução? Utilizar um sistema "alternativo" (e obviamente não recomendado) que consiste em alocar dinamicamente o dispositivo e então registrar o seu driver, ao invés de utilizar apenas os identificadores como referência para a inserção e inicialização do driver do dispositivo. Esse método foi descoberto olhando os fontes do Framebuffer arkfb, ou algo assim, corrigirei depois.
Essa solução havia resolvido o problema de inicialização. Mas, como não dá para se ter tudo na vida, a remoção grotescamente gerava um Kernel Taint por um dereferência a um ponteiro nulo - e não poder remover um driver significa que não poderei compilá-lo como módulo a fim de teste, me obrigando a carregar a imagem do linux via porta serial toda hora que fizesse uma modificação.
Entonces, hoje foi mais um dia tentando resolver esse empecilho. Como não posso perder mais muito tempo nisso, vou ter que utilizar o método brucutu de carregar as imagens toda hora que modificar apenas uma linha de código. Sigh.
Ok, próximos passos então:
Contextualizando: tenho que escrever um driver de vídeo usando a API de framebuffer do Linux. Esta tarefa já havia sido iniciada anteriormente, porém, esse driver utilizava um identificador de hardware para se "encaixar" dentro do sistema maluco de platform_device do Linux, declarando uma tabela de identificadores que possuía apenas o ID do controlador de memória.
Porém, o projeto mudou, o identificador sumiu, e o driver então parou de funcionar. A solução? Utilizar um sistema "alternativo" (e obviamente não recomendado) que consiste em alocar dinamicamente o dispositivo e então registrar o seu driver, ao invés de utilizar apenas os identificadores como referência para a inserção e inicialização do driver do dispositivo. Esse método foi descoberto olhando os fontes do Framebuffer arkfb, ou algo assim, corrigirei depois.
Essa solução havia resolvido o problema de inicialização. Mas, como não dá para se ter tudo na vida, a remoção grotescamente gerava um Kernel Taint por um dereferência a um ponteiro nulo - e não poder remover um driver significa que não poderei compilá-lo como módulo a fim de teste, me obrigando a carregar a imagem do linux via porta serial toda hora que fizesse uma modificação.
Entonces, hoje foi mais um dia tentando resolver esse empecilho. Como não posso perder mais muito tempo nisso, vou ter que utilizar o método brucutu de carregar as imagens toda hora que modificar apenas uma linha de código. Sigh.
Ok, próximos passos então:
- Criar a aplicação DirectFB TestCard, de teste de cores
- Rodar ela na placa e ver como as cores estão sendo interpretadas pela API
- Corrigir o Framebuffer
Update: depois de verificar os sources de novo, decidi ignorar o problema da remoção, uma vez que o método que estou utilizando é descrito como "desencorajado" pelos mainteners do Linux e um comentário propício em um deles salienta que o módulo não é removível
Monk da Luz
Vamos ver: 20 Lightmonk
STR 14
DEX 15
CON 14
INT 10
WIS 16
CHA 8
Helf, Dilletante de Rogue
Feats legais, ainda não final
Power Attack
Cleave
Great Cleave
Dodge
Mobility
Combat Expertise
Whirlwind Attack
Two Weapon FIghting (x3)
Stunning Fist
Stunning Blow
Toughness
13... acho q n rola, mimimi. Vamos ver: 7 de lvl ups (1,3,6,9,12,15,18)
1,3,6 marciais ... 10 feats no total.
não sou monge de força - logo no Cleaves, 11, só tenho 10, Humano?
STR 14
DEX 15
CON 14
INT 10
WIS 16
CHA 8
Helf, Dilletante de Rogue
Feats legais, ainda não final
Power Attack
Cleave
Great Cleave
Dodge
Mobility
Combat Expertise
Whirlwind Attack
Two Weapon FIghting (x3)
Stunning Fist
Stunning Blow
Toughness
13... acho q n rola, mimimi. Vamos ver: 7 de lvl ups (1,3,6,9,12,15,18)
1,3,6 marciais ... 10 feats no total.
não sou monge de força - logo no Cleaves, 11, só tenho 10, Humano?
quarta-feira, 17 de julho de 2013
Assinar:
Postagens (Atom)