Closed frederikaalund closed 6 years ago
You can try changing the first pixel, IIRC this should write a white pixel at 0,0:
echo -ne '\xff\xff' > /dev/fbX
Thanks for the quick reply. I'll try this as the first thing on Monday.
echo -ne '\xff\xff' > /dev/fbX
It seems to be off-by-one as well.
I also tried filling the screen with a long array of \xff\xff
values:
Same off-by-one pixel issue in the line.
I suspect it's a faulty display, panel miswired. Check with the supplier if they have a library you can use to drive the display without fbtft.
This is the code that is run before the framebuffer (partial/windowed or full) is dumped on the bus:
static void flexfb_set_addr_win_2(struct fbtft_par *par,
int xs, int ys, int xe, int ye)
{
switch (par->info->var.rotate) {
/* R4Eh - Set GDDRAM X address counter */
/* R4Fh - Set GDDRAM Y address counter */
case 0:
write_reg(par, 0x4e, xs);
write_reg(par, 0x4f, ys);
break;
case 180:
write_reg(par, 0x4e, par->info->var.xres - 1 - xs);
write_reg(par, 0x4f, par->info->var.yres - 1 - ys);
break;
case 270:
write_reg(par, 0x4e, par->info->var.yres - 1 - ys);
write_reg(par, 0x4f, xs);
break;
case 90:
write_reg(par, 0x4e, ys);
write_reg(par, 0x4f, par->info->var.xres - 1 - xs);
break;
}
/* R22h - RAM data write */
write_reg(par, 0x22, 0);
}
Ref: http://elixir.free-electrons.com/linux/latest/ident/flexfb_set_addr_win_2
Thanks for taking your time to look at this issue. I've tried with two panels now from different suppliers and the issue seems to persist.
However, I also managed to get a full screen image to display properly (without the one-pixel offset). When I subsequently tried to turn of the top-left pixel (echo -ne '\x00\x00' > /dev/fb0
) it actually turned off two pixels (no idea why). I then tried to turn them on again (echo -ne '\xff\xff' > /dev/fbX
) but this only enabled the second pixel (the top-left pixel was still turned off). Very weird.
This behaviour really makes me wonder what is actually going on. I'm not sure if its:
fb0
.
echo
ing to fb0
either.Anyways, I just wanted to let other people be aware of my findings.
Thanks again for taking your time to look at this issue. I'll close it for now.
Is there anything like the flexfb
for tinydrm?
Is there anything like the flexfb for tinydrm?
No, it's a hack that is only tolerated (temporarily...) in drivers/staging. In tinydrm every display needs a driver, no passing init sequence via module parameters or Device Tree.
I've gotten the SSD2119 controller up and working using the following settings:
It looks like this:
Everything looks almost as I would expect. There is only one issue: The off-by-one line to the far left. It looks like it affects the entire left line:
I've tried with eight different init sequences but all have the same issue (though for some sequences the offset is for the rightmost line).
It also happens when I use
cat /dev/urandom > /dev/fb0
to fill the display. That is, it doesn't seem to be an issue at the application layer.Do you have any idea on how I might fix this? I'm all ears for workarounds as well. Thanks for your great work on fbtft.