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
Nenhum comentário:
Postar um comentário