Linux: tvservice -o then tvservice -p resulta no dipslay ligado, mas nada é exibido.

Criado em 17 mar. 2015  ·  9Comentários  ·  Fonte: raspberrypi/linux

Eu tentei isso com dois monitores diferentes e 3.12 e 3.18 .... em um B + e rev2 B.

Comentários muito úteis

O aplicativo sdl terá criado seu próprio framebuffer e terá um ponteiro para a memória do framebuffer, então terá que lidar com isso sozinho.
Realmente, acho que você não deve desligar o HDMI quando os aplicativos estiverem usando a tela.
Você pode usar:

vcgencmd display_power 0

e

vcgencmd display_power 1

que é uma maneira menos invasiva de remover o sinal de saída HDMI, mas deixa as sobreposições intactas.

Todos 9 comentários

Isso é normal. Desligar o destrói todas as sobreposições (das quais o framebuffer é uma).
Você pode recriá-lo com "fbset -depth 8 && fbset -depth 16"

O aplicativo que tenho é baseado em sdl e ainda está exibindo na tela para ver,
17 de março 14:33:46 raspberrypi user.err fbcp [3318]: Não foi possível fazer o instantâneo -1. (60)
17 de março 14:34:00 kernel raspberrypi user.info: [326.704707] bcm2708_fb_ioctl 40044620,0 retorna = 0 p [1] = 0x80000001
17 de março 14:34:00 kernel raspberrypi user.err: [326.704940] bcm2708_fb_pan_display (0,0) retorna = 16
17 de março 14:34:46 raspberrypi user.err fbcp [3318]: Não foi possível fazer o instantâneo -1. (120)
17 de março 14:35:00 kernel raspberrypi user.info: [386.693696] bcm2708_fb_ioctl 40044620,0 retorna = 0 p [1] = 0x80000001
17 de março 14:35:00 kernel raspberrypi user.err: [386.693907] bcm2708_fb_pan_display (0,720) retorna = 16

Tentei restaurar com
(tvservice -p && sleep 2 && fbset -depth 8 && fbset -depth 16) 2> & 1
sem saída de tela
17 de março 14:43:26 kernel raspberrypi user.warn: [268.637255] detectou o erro fb_set_par, código do erro: 16
17 de março 14:43:26 kernel raspberrypi user.err: [268.649473] bcm2708_fb_blank (0) retorna = 0 p [1] = 0x80000001
17 de março 14:43:26 kernel raspberrypi user.info: [268.821121] bcm2708_fb_ioctl 40044620,0 retorna = 0 p [1] = 0x80000001
17 de março 14:43:26 kernel raspberrypi user.err: [268.821395] bcm2708_fb_pan_display (0,0) retorna = 16
17 de março 14:43:26 kernel raspberrypi user.info: [268.972086] bcm2708_fb_ioctl 40044620,0 retorna = 0 p [1] = 0x80000001
17 de março 14:43:26 kernel raspberrypi user.err: [268.972286] bcm2708_fb_pan_display (0,720) retorna = 16
17 de março 14:43:26 kernel raspberrypi user.info: [269.105637] bcm2708_fb_ioctl 40044620,0 retorna = 0 p [1] = 0x80000001
17 de março 14:43:26 kernel raspberrypi user.err: [269.105901] bcm2708_fb_pan_display (0,0) retorna = 16

alterar VT neste ponto resultou em cunha de pi.

O aplicativo sdl terá criado seu próprio framebuffer e terá um ponteiro para a memória do framebuffer, então terá que lidar com isso sozinho.
Realmente, acho que você não deve desligar o HDMI quando os aplicativos estiverem usando a tela.
Você pode usar:

vcgencmd display_power 0

e

vcgencmd display_power 1

que é uma maneira menos invasiva de remover o sinal de saída HDMI, mas deixa as sobreposições intactas.

Sim, o aplicativo SDL usou um buffer duplo HW alocado por meio do dispositivo fb do kernel e faz uma panorâmica entre os dois buffers. Estou redesenhando o buffer depois, emitindo o conjunto de comandos de restauração. de acordo com a saída de fbset -i o endereço fb não muda depois de passar pelo ciclo de energia, mas eu não acho que isso seja verossímil e provavelmente está fora de sincronia, portanto, a falha na alteração vt. Forçar uma mudança de modo nesse ponto para realocar o fb e atualizar os ponteiros?

Isso tudo dito vcgencmd display_power (menos os s em displays) parece fazer o que eu quero (implementando um soft off) obrigado.

Há uma versão corrigida da biblioteca SDL referenciada nesta postagem do fórum (http://www.raspberrypi.org/forums/viewtopic.php?f=38&t=99822&p=692525&hilit=sdl#p692525) que lida com o endereço base de o FB mudando em uma mudança de resolução. Pode valer a pena tentar essa versão para ver se ela se comporta melhor.

@pelwell lol sim era eu, daquela página ;-)

Você pode ler sobre o problema aqui - https://github.com/raspberrypi/firmware/issues/354 - Felizmente, alguém chamado pssc já havia corrigido o problema principal como parte de seu trabalho de squeezeplay, então eu incorporei a correção em um Pacote SDL.

LOL de fato. Em minha defesa, foi há um tempo, e uma alça impronunciável se parece muito com outra ...

A memória framebuffer alocada não é liberada quando a energia é desligada, mas quaisquer elementos dispmanx serão removidos. Se você estiver usando o backend dispmanx de sdl, então a sequência dispmanx_element_add usual irá colocar o framebuffer de volta no display.
Se você estiver usando o back-end do framebuffer padrão, será necessário alterá-lo para que seja removido / adicionado. Efetivamente faça o mesmo que "fbset -depth 8 && fbset -depth 16" de dentro do SDL (por exemplo, altere o tamanho ou a profundidade).
No entanto, a solução "vcgencmd display_power" é provavelmente a mais simples.

vcgencmd display_power coded solution faz o que eu preciso para encerrar o problema.

Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

incyi picture incyi  ·  9Comentários

fivdi picture fivdi  ·  9Comentários

pvouzis picture pvouzis  ·  9Comentários

ncguk picture ncguk  ·  4Comentários

KevinStartup picture KevinStartup  ·  6Comentários