WaveShare HDMI LCD on Banana - 1

[beu]

Hello,

 

I've got two WaveShare HDMI LCDs:

 

• 7inch HDMI LCD (C), 1024x600

• 10.1inch HDMI LCD (B), 1280x800

 

Has anybody managed to configure them for the Banana (with Armbian legacy kernel)?

 

The company WaveShare provides a Raspbian image that works okay (screen and touch).

I used fbset to figure out the current settings while running the provided Raspbian image:

 

7inch:

 

mode "1024x600-43"
    # D: 32.000 MHz, H: 27.778 kHz, V: 43.066 Hz
    geometry 1024 600 1024 1200 32
    timings 31250 40 40 29 13 48 3
    rgba 8/16,8/8,8/0,8/24
endmode

 

10inch:

 

mode "1280x800-60"
    # D: 75.002 MHz, H: 49.474 kHz, V: 60.041 Hz
    geometry 1280 800 1280 1600 32
    timings 13333 124 64 12 5 48 7
    hsync high
    rgba 8/16,8/8,8/0,8/24
endmode

 

Then I started an Armbian 5.31 image (unmodified), and tried to set

display mode with fbset using the above mentioned settings, but no success:

the 7inch LCD displays the desktop four times horizontally (and every other line seems to be blank);

the 10.1inch LCD picture looks normal, but has an empty stripe at the bottom of the screen (as if

it would be using only768 rows instead of 800 - see 1280x768 instead of 1280x800).

 

Anybody can help me with the correct settings, please?

 

 

 

[tkaiser]

11 minutes ago, beu said:

7inch HDMI LCD (C), 1024x600

http://forum.lemaker.org/thread-15430-1-1.html

[tkaiser]

17 minutes ago, beu said:

The company WaveShare provides a Raspbian image that works okay (screen and touch)

 

They provide an image for Banana Pi? Or Raspberry Pi? This is important since on Raspberry Pis the real config happens in /boot/config.txt being read by the VideoCore GPU.

[beu]

They provide the image for the Banana Pi.

(For Raspberry Pi they do not provide an image, because they say no driver is needed.)

 

Thanks for the link, I had already tried it before, but it gave the same picture (desktop displayed 4x horizontally).

[tkaiser]

26 minutes ago, beu said:

They provide the image for the Banana Pi.

Then you might check /proc/cmdline there and contents of script.bin ('apt install sunxi-tools' then using bin2fex)

 

26 minutes ago, Tido said:

I have merged the topic of Cheap HDMI and WaveShare HDMI, because you struggle with the same problem

Seriously? Please keep this separated since it's about two different displays that show different behaviour (up to now no one provided EDID info/compatibility of the WaveShare displays)

[tkaiser]

6 minutes ago, Tido said:

They have the same resolution, HDMI and don't work as expected

 

Can you please split both threads again? IMO it's important to keep the Xunlong display separated from WaveShare and software configuration issues since Xunlong's thing targets their own boards and with legacy H3 kernel the display won't work anyway at the native resolution (it's important for future buyers to spot this problem -- Xunlong board + Xunlong display != working)

 

This here is a software config issue with a totally different kernel. And if the WaveShare display provides correct EDID data (the Xunlong one doesn't!) then it should work with mainline u-boot/kernel flawlessly. This stuff should not be merged/mixed!

[beu]

The kernel cmd.line is:

 

console=ttyS0,115200 console=tty0 consoleblank=0 disp.screen0_output_mode=EDID:1280x720p60 hdmi.audio=EDID:0 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait

 

In the FEX file I can't see anything special:

 

[hdmi_para]
hdmi_used = 1

 

[disp_init]
disp_init_enable = 1
disp_mode = 0
screen0_output_type = 3
screen0_output_mode = 5
screen1_output_type = 2
screen1_output_mode = 11
fb0_framebuffer_num = 2
fb0_format = 10
fb0_pixel_sequence = 0
fb0_scaler_mode_enable = 1
fb1_framebuffer_num = 2
fb1_format = 10
fb1_pixel_sequence = 0
fb1_scaler_mode_enable = 0

 

(are there other relevant sections in the FEX I should consider?)

 

Actually the difference between Armbian 5.31 stock bananapipro.fex file (left side) and the WaveShare script.fex (right side) is not that much:

 

3c3
< machine = "LeMaker Banana Pro"
---
> machine = "bananapro"
16d15
< power_start = 1
822,824c821,823
< usb_detect_type = 0
< usb_id_gpio = port:PH04<0><1><default><default>
< usb_det_vbus_gpio = "axp_ctrl"
---
> usb_detect_type = 1
> usb_id_gpio = port:PH03<0><1><default><default>
> usb_det_vbus_gpio = port:PH26<0><0><default><default>
826,827c825
< usb_ac_enable_gpio = port:PH05<1><0><default><0>
< usb_restrict_gpio = 0
---
> usb_restrict_gpio =
945c943
< i2s_used = 1
---
> i2s_used = 0
972c970
< leds_num = 1
---
> leds_num = 2
973a972
> leds_pin_2 = port:PG02<1><default><default><0>
975c974,976
< leds_trigger_1 = "mmc0"
---
> leds_name_2 = "blue:pg02:led2"
> leds_trigger_1 = "heartbeat"
> leds_trigger_2 = "mmc0"

 

What is interesting to me, is that xvidtune shows 1280x720 while fbset at the same time shows 1024x600:

 

When I boot Armbian with disp.screen0_output_mode=EDID kernel cmd.line, fbset looks like:

 

mode "1280x720-60"
    # D: 74.250 MHz, H: 45.000 kHz, V: 60.000 Hz
    geometry 1280 720 1280 1440 32
    timings 13468 220 110 20 5 40 5
    hsync high
    vsync high
    rgba 8/16,8/8,8/0,8/24
endmode

 

And xvidtune -show outputs

 

"1280x720"     74.25   1280 1390 1430 1650    720  725  730  750 +hsync +vsync -csync

 

(these values describe the same timings as that of fbset)

 

As if EDID would not have been read (or used) by the disp driver (or it can't switch to the 1024x600 mode).

 

By the way, the display looks OK (of course it shows only the upper left 1024x600 rectangle of the 1280x720 area).

So these timing parameters are not that bad. Only the display (or frame buffer) size is larger than the real size.

 

I did get-edid | parse-edid to see if EDID is correct. I got the following Modeline:

 

            Modeline        "Mode 0" 32.00 1024 1064 1112 1152 600 613 616 645 -hsync -vsync

 

it seems to be correct. When I convert the timing values to fbset "timings" parameters:

 

mode "FromEDID"
    # D: 32.000 MHz, H: 27.778 kHz, V: 43.066 Hz
    geometry 1024 600 1024 1200 32
    timings 31250 40 40 29 13 48 3
    rgba 8/16,8/8,8/0,8/24
endmode

 

and do fbset FromEDID I get the 4x repeated desktop again. Surprisingly,  fbset shows the newly set (1024x600) parameters,

while xvidtune -show outputs the 1280x720 Modeline. Maybe the framebuffer was changed, but X did not follow?

 

After restarting the X session, 1280x720 look comes back.

It seems to be unable to switch to the 1024x600 mode, even if I explicitly tell the parameters to fbset.

 

Xorg.0.log shows:

 

[   882.258] (II) FBTURBO(0): checking modes against framebuffer device...
[   882.258] (II) FBTURBO(0): checking modes against monitor...
[   882.258] (--) FBTURBO(0): Virtual size is 1280x720 (pitch 1280)
[   882.259] (**) FBTURBO(0):  Built-in mode "current": 74.2 MHz, 45.0 kHz, 60.0 Hz
[   882.259] (II) FBTURBO(0): Modeline "current"x0.0   74.25  1280 1390 1430 1650  720 725 730 750 +hsync +vsync -csync (45.0 kHz
 

I don't know, where fbturbo this 1280x720 resolution takes from ...

 

/etc/X11/xorg.conf.d/50-fbturbo.conf  contains only this:

 

Section "Device"
        Identifier      "Allwinner A10/A13 FBDEV"
        Driver          "fbturbo"
        Option          "fbdev" "/dev/fb0"

        Option          "SwapbuffersWait" "true"
EndSection

 

So I am stuck ...