notro / fbtft

Linux Framebuffer drivers for small TFT LCD display modules. Development has moved to https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/tree/drivers/staging/fbtft?h=staging-testing
1.85k stars 496 forks source link

OLED SSD1351: Not Using Full Width #452

Closed BlacknovaY closed 3 years ago

BlacknovaY commented 7 years ago

Firstly, I wanted to say I love this project, I am working on replacing my smartphone with super capacitors and SPI displays :P, so thank you. However, with this OLED it is not using the full width of the display and there is a flicker if fb0 is updating regularly.

Although I think this is a problem with fbcp as I have checked the size of fb0 and fb1, and they both come to 128x128. Also the text is blurry, which makes me think it is a sampling issue. I do have a ST7735R LCD on which this setup does work though.

So my question is can I setup this module to read from fb0 to the display rather than creating fb1. Or is there a good reason for fb1 if you don't need the HDMI working?

notro commented 7 years ago

Why do you need to use fbcp?

fbcp is for the cases where userspace needs gpu acceleration, so rendering happens on "fb0" and the result is copied to fb1.

You can get rid of the border with some config.txt changes, I don't remember which.

This DT overlay fragment will disable HDMI on fb0 resulting in fbtft using fb0:

    fragment@0 {
        target = <&fb>;
        __overlay__  {
            status = "disabled";
        };
    };
BlacknovaY commented 7 years ago

I was using fbcp because it was easier to get than con2fbmap(which was in the AUR). But using your DT overlay fragment I got it working on fb0. With this dts file:

// Disable HDMI
/dts-v1/;
/plugin/;

/ {
        compatible = "brcm,bcm2708";

        fragment@0 {
               target = <&fb>;
               __overlay__  {
                       status = "disabled";
               };
        };
};

But I am getting some wrong colour artefacts on the screen when the framebuffer updates frequently. Also I take it reading from fb0 will allow for GPU usage?

notro commented 7 years ago

But I am getting some wrong colour artefacts on the screen when the framebuffer updates frequently.

You probably have to lower the SPI speed.

Also I take it reading from fb0 will allow for GPU usage?

I don't know what you mean by reading here. Disabling the 'fb' node, disables GPU rendering for apps that don't use dispmanx directly (I guess). fbcp enables these displays to take advantage of GPU rendering, which is nice for e.g. games that only works with opengl or libraries that needs hw acceleration.

BlacknovaY commented 7 years ago

The SPI speed was the problem, my display has a level shifter which slows it down. I had tried the SPI baudrate before, but I tried setting it in /boot/config.txt with spi_baudrate=4000000.

It seems that I misunderstood what the DT overlay fragment does. What I meant by "reading from" is that I made a python script for another display that that read from fb0 without the DT overlay fragment, in other words turning off GPU usage. I then setup fb0 to the right resolution with these lines in config.txt

hdmi_ignore_hotplug=1
framebuffer_width=64
framebuffer_height=128

That was for a ssd1306 OLED. Which if I have understood correctly would allow GPU usage without fbcp.

github-actions[bot] commented 3 years ago

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days.