SSD2119 off by one pixel in the first line

[frederikaalund]

I've gotten the SSD2119 controller up and working using the following settings:

FBTFT_DEVICE_MODULE="fbtft_device.ko"
FLEXFB_MODULE="flexfb.ko"
INIT=-1,0x0028,0x0006,-1,0x0000,0x0001,-1,0x0010,0x0000,-1,0x0001,0x72EF,-1,0x0002,0x0600,-1,0x0003,0x6A38,-1,0x0011,0x6E70,-1,0X000F,0x0000,-1,0X000B,0x5308,-1,0x000C,0x0003,-1,0x000D,0x000A,-1,0x000E,0x2E00,-1,0x001E,0x00BE,-1,0x0025,0xA000,-1,0x0026,0x7800,-1,0x004E,0x0000,-1,0x004F,0x0000,-1,0x0012,0x08D9,-1,0x0030,0x0000,-1,0x0031,0x0104,-1,0x0032,0x0100,-1,0x0033,0x0305,-1,0x0034,0x0505,-1,0x0035,0x0305,-1,0x0036,0x0707,-1,0x0037,0x0300,-1,0x003A,0x1200,-1,0x003B,0x0800,-1,0x0007,0x0033,-1,0x0022,0x0000,-3   

modprobe $FBTFT_DEVICE_MODULE name=flexfb speed=50000000 gpios=reset:902,dc:901 busnum=1 cs=0
modprobe $FLEXFB_MODULE width=320 height=240 regwidth=16 setaddrwin=2 init=$INIT

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.

[notro]

You can try changing the first pixel, IIRC this should write a white pixel at 0,0:

echo -ne '\xff\xff' > /dev/fbX

[frederikaalund]

Thanks for the quick reply. I'll try this as the first thing on Monday.

[frederikaalund]

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.

[notro]

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

[frederikaalund]

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:

• Both panels that are faulty
• An issue with the driver
• An issue with way I'm interacting with fb0.
  • My application uses Qt to write to the framebuffer directly. This worked for the full-screen image but not for the gui.
  • As noted above, I can't seem to get the proper behaviour when echoing 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?

[notro]

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.