Open dangowrt opened 5 years ago
Maybe it is var.order being set wrong. I would guess that the offset for each color should not be the same.
On Tue, 17 Sep 2019, 01:11 Daniel Golle, notifications@github.com wrote:
I'm trying your drive on MT7628AN (MIPS24KEc, little-endian) running OpenWrt master. Somehow the pixel order is wrong. When I write 16 bytes to /dev/fb0 I'd expect that being the first 128 pixels, ie. the first line on the display. However, what I get is chunks of 4x8 pixels, ie. the first 16x8 pixels are affected instead of the expected 128x1. This of course also results in framebuffer console fonts being unreadable and everything being quite a mess...
[ 16.743131] ssd1306: display initialized [ 16.747867] Console: switching to mono frame buffer device 16x8 [ 16.776549] ssd1306fb 0-003c: fb0: SSD1306 OLED framebuffer device registered, using 1024 bytes of video memory [ 16.787206] i2c-mt7621 10000900.i2c: clock 100KHz, re-start not support
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mkschreder/hack-ssd1306-openwrt/issues/2?email_source=notifications&email_token=ABCGVCIMN2QHURO7MN2L5HTQKAHDVA5CNFSM4IXIJH22YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HLWXAUA, or mute the thread https://github.com/notifications/unsubscribe-auth/ABCGVCL3LBNPKUE4Y3QSLY3QKAHDVANCNFSM4IXIJH2Q .
I'm trying your drive on MT7628AN (MIPS24KEc, little-endian) running OpenWrt master. Somehow the pixel order is wrong. When I write 16 bytes to /dev/fb0 I'd expect that being the first 128 pixels, ie. the first line on the display. However, what I get is chunks of 4x8 pixels, ie. the first 16x8 pixels are affected instead of the expected 128x1. This of course also results in framebuffer console fonts being unreadable and everything being quite a mess...