Waveshare 7.9in Touchscreen Support?

#1

Have tried to get this screen functional on a multitude of different images, and just can’t get it to function. The screen works with pc/rpi no issue, but the RZero doesn’t seem to like it.

Upon boot, the screen is a jumbled mess, which then fades out to black. Sometimes, the RZero will boot and the screen wont even turn itself on, as if both devices do not recognize eachother.

I’ve tried to force 400x1280 res in extlinux.conf or even 1280x400, but to no avail.

How would I go about implementing this screen? Would generating a modeline timing be able to force this to work?

#2

Yes, add a modeline. Then cross your fingers.

#3

I’m probably just a bit confused when it comes to properly adding these new resolutions in;

using cvt I’ve generated a new modeline and added them into xrandr in the typical fashion one would use --newmode and --addmode and all that, but xrandr is still refusing to open the display. I’m even forcing -d :0 through ssh just trying to see if anything will happen.

Right now, I’m using the official Debian build from the radxa github full of images, but no luck.

I’ve also tried overriding the Edid info/forcing video modes in the uEnv.txt but again, no luck.

I never would have thought it’d be so difficult to get an HDMI screen to just output something, anything at all, lol. I’m just getting a black screen even after all of this crapola I’ve tried, and the blinking led on the back of the monitor indicates that it doesn’t seem to be seeing a valid signal from the Zero itself.

I’m quite honestly unsure as to why there appears to be no easy way to force a valid resolution to this monitor… its quite odd.

#4

Dude, your monitor use a very odd resolution. The display driver on mainline linux is not that mature on that department. Having support for odd resolutions isn’t an easy thing at all. That’s probably the only thing that rpi have covered and we don’t, on mostly any platform.

Take for example the new quartz64 (rk3566) from pine64 or the rockpi 3(rk3568), they do not output anything AT ALL on mainline linux.

This problems are not strictly related to radxa, they will appear on many other brands, even popular ones like odroid. I already asked to @hipboi and @jack to improve a bit the display support down the road, but a so odd resolution like yours isn’t a priority

#5

Gotcha! I wasn’t meaning to sound like I was dissing the development/programming/etc, I just generally find it odd that there just isn’t some sort of “easy” way to force a non-standard resolution (on anything, I mean, not just radxa products, haha).

I’ve read other suggestions regarding the use of just xrandr and ignoring all the kernel mumbo jumbo, but I can’t really seem to get that to communicate properly with this display either.

It just sucks I can’t figure this out haha, the monitor fits so perfectly with what I’m building size wise, and I had never even considered that its strange resolution would be an issue. Guess I know to stick to something more standard in the future, haha!

Thanks for the help!

#6

No problem, sorry, wasn’t trying to sound rude! This is a priority (better hdmi resolution output support), but probably not that resolution. Hopefully radxa devs could improve thst down the road, but yes, it’s not an easy thing.

#7

There is a very nice new about this topic. It seems that while it should not resolve your problem, we will not need to add support to every resolution. Latest gnome wayland always scale legacy resolution apps to your desktop resolution. So xwayland we will scale 640x480 apps to 1080p and so on. It will probably be stretched but its better than nothing.

That being said, bc your display is hdmi based you may try to force your display to use a different resolution than 1280x400. It may look badly but work at the same time. I dont know exactly how to di it, but for example, my motorola lapdock can do 1920x1080 while isnt his native resolution. It doesn’t look great tho so I just use 1366x768 that have some problems like intermittent shaking behaviors.

Booting the desktop on a 1080p display and switching to my lapdock does retain the 1080p resolution… doesn’t look great tho, but it worked. Just for testing is an initial approach.

#8

While screwing around with Manjaro on a pi4 I did happen to notice the increased,scaling abilities operating within the wayland environment, so that is real good to hear!

Unfortunately, I did try a multitude of different resolutions and didn’t have any luck getting the screen to display anything. With Manjaro on the Zero, I was able to get the screen to monetarily show a corrupted 3 panel, purpleish version of the manjaro logo that would fade out and then disable the screen entirely, as if it wasnt being detected properly, or the internal hdmi scaler wasnt liking its signal.

Unfortunatly I killed the microhdmi port on my current Zero and am waiting for a new board to come in, so no experiments for a little bit (also I must have shorted something as the board no longer even turns on).

I am very impressed with these boards though so it gave me an excuse to get the higher emmc capacity board with 4gb ram… But god damn I hate micro hdmi :joy:

#9

Wow… that’s savage hahaa how you broke it?? It seems a decently solid port to me. But yeah, it’s a tradeoff due the size. That being said, there may some way to solder it. You can still use it with scrcpy (android mirrored) with your pi4 desktop. It’s a very neat usage. Just plug it to your pi4, she will feed it and also be able to mirror your zero android into your pi4 desktop.

#10

Just from plugging and unplugging repeatedly haha. I wasnt being rough with it or anything, the port just stopped being able to produce a signal that was useable; all my monitors could “see” the zero, but the image just remained black. And then when I was fiddling with the port, the zero just stopped turning on so, no idea what happened haha, probably just a lemon. Bit pissed tjat it died, but my 2g ram model has had zero issues and is a trooper in my handheld game console build so, I’m willing to chaulk the issue up to either myself doing something stupid, or just a “eh” quality micro port on this one specific board.

Honestly, and this is slightly off topic, but, I really wish companies would stop using micro hdmi; the connector itself is just too delicate, even on my RasPi models those are the first ports to crap themselves. I’ve never had a full size, or even a mini hdmi port for that matter, randomly shit the bed on me, haha. I get that it saves real estate on the board but… Maybe usb C hdmi would be the more reliable choice for future boards?

Honestly usb c is the god tier “small” port in my mind in terms of reliability :joy:

#11

Probably a short-circuit. Take in count that unlike the rpi zero this zero have sensible electronic staff on the back, so you must use a case or take care where you put that board…

#12

So, I have one of these as well, and someone on the cyberdeck discord had mentioned trying to get it going and having no luck, so I figured I’d try my luck as well.

Here is what I’ve tried…

First, I just tried booting it, got the usual screen initially turns on then kinda fades out with whatever was on the display. Unfortunate, but it wasn’t unexpected.

So I dug in… figured the first thing to do, because of it being an odd resolution, was to do an edid override, and see whats what.

I grabbed the edid from this hardkernel forum post with 400x1280 edid someone made and unfortunately, no luck there, because DRM_LOAD_EDID_FIRMWARE wasn’t enabled in the kernel I have on mine, so I enabled that, and added extraargs=drm.edid_firmware=edid/400x1280.bin video=HDMI-A-1:e to my uEnv.txt
then it was loading, but would complain about no crtc sizes being found.

 rzero kernel: [    2.411481] meson-drm ff900000.vpu: [drm] Cannot find any crtc or sizes

So, then I got the bright idea to download Monitor Asset Manager on my windows machine, because I know that Windows was able to handle the display (mostly) and see what it got. So I took the EDID block from that app, and verified that linux can read it via edid-decode, and it did, so I put that into /lib/firmware/edid and used that for my override. Then I had a weirder issue where DRM was complaining that it couldn’t find the edid… so I created an initramfs hook that simply copied the firmware into the initramfs.

It was still complaining about the crtc size, so I figured, I’d try adding the resolution to the video= as well, so i made it

extraargs=drm.edid_firmware=edid/400x1280.bin video=HDMI-A-1:400x1280@60:e

Now it boots happier, and I get the following

steev@rzero:~$ sudo dmesg | grep -i drm
[    0.000000] Kernel command line: initrd=initrd.img-5.10.136 root=UUID=0a23bd6c-0d3b-458f-9256-9a345cd0e89b rootwait rw rootfstype=ext4 console=tty1 console=ttyAML0,115200 panic=10 consoleblank=0 loglevel=7 drm.edid_firmware=edid/400x1280.bin video=HDMI-A-1:400x1280@60:e  cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1
[    5.494268] systemd[1]: Starting Load Kernel Module drm...
[    7.168780] meson-drm ff900000.vpu: Queued 2 outputs on vpu
[    7.189869] meson-drm ff900000.vpu: CVBS Output connector not available
[    7.237877] meson-drm ff900000.vpu: bound ff600000.hdmi-tx (ops meson_dw_hdmi_ops [meson_dw_hdmi])
[    7.259113] [drm] Initialized meson 1.0.0 20161109 for ff900000.vpu on minor 0
[    7.326097] [drm] Got external EDID base block and 0 extensions from "edid/400x1280.bin" for connector "HDMI-A-1"
[    7.361590] meson-drm ff900000.vpu: [drm] fb0: mesondrmfb frame buffer device
[    7.464199] [drm] Initialized panfrost 1.1.0 20180908 for ffe40000.gpu on minor 1

The edid decoded shows

steev@rzero:~/temp/edid-generator$ edid-decode 400x1280.bin
edid-decode (hex):

00 ff ff ff ff ff ff 00 31 d8 00 00 00 00 00 00
05 16 01 03 6d 0a 21 78 ea 5e c0 a4 59 4a 98 25
20 50 54 00 00 00 13 c0 01 01 01 01 01 01 01 01
01 01 01 01 01 01 cc 10 90 8c 10 00 2a 50 64 0a
4a 00 68 4d 01 00 00 1e 00 00 00 ff 00 4c 69 6e
75 78 20 23 30 0a 20 20 20 20 00 00 00 fd 00 3b
3d 4e 50 05 00 0a 20 20 20 20 20 20 00 00 00 fc
00 34 30 30 78 31 32 38 30 0a 20 20 20 20 00 c4

----------------

Block 0, Base EDID:
  EDID Structure Version & Revision: 1.3
  Vendor & Product Identification:
    Manufacturer: LNX
    Model: 0
    Made in: week 5 of 2012
  Basic Display Parameters & Features:
    Analog display
    Signal Level Standard: 0.700 : 0.000 : 0.700 V p-p
    Blank level equals black level
    Sync: Separate Composite Serration
    Maximum image size: 10 cm x 33 cm
    Gamma: 2.20
    DPMS levels: Standby Suspend Off
    RGB color display
    First detailed timing is the preferred timing
  Color Characteristics:
    Red  : 0.6416, 0.3486
    Green: 0.2919, 0.5957
    Blue : 0.1474, 0.1250
    White: 0.3125, 0.3281
  Established Timings I & II: none
  Standard Timings:
    GTF     :   400x225    59.997230 Hz  16:9     14.039 kHz      6.065000 MHz
  Detailed Timing Descriptors:
    DTD 1:   400x1280   60.234213 Hz   5:16    79.630 kHz     43.000000 MHz (104 mm x 333 mm)
                 Hfront  100 Hsync  10 Hback   30 Hpol P
                 Vfront    4 Vsync  10 Vback   28 Vpol P
    Display Product Serial Number: 'Linux #0'
    Display Range Limits:
      Monitor ranges (GTF): 59-61 Hz V, 78-80 kHz H, max dotclock 50 MHz
    Display Product Name: '400x1280'
Checksum: 0xc4

And the edid itself is (also in the output above)

00 FF FF FF FF FF FF 00 21 F4 4C 4F 01 00 00 00 1F 1D 01 03 80 12 1B 78 0A F0 65 98 57 51 91 27
21 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 CC 10 90 8C 10 00 2A 50 64 0A
4A 04 90 00 15 00 00 1E CC 10 80 8C 10 00 2A 50 64 0A 4A 04 90 00 15 00 00 1E 00 00 00 FC 00 57
61 76 65 53 68 61 72 65 0A 20 20 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 E5
02 03 1A 71 47 C6 46 46 46 46 46 46 23 09 07 01 83 01 00 00 65 03 0C 00 10 00 CC 10 90 8C 10 00
2A 50 64 0A 4A 04 90 00 15 00 00 1E CC 10 90 8C 10 00 2A 50 64 0A 4A 04 90 00 15 00 00 1E CC 10
90 8C 10 00 2A 50 64 0A 4A 04 90 00 15 00 00 1E CC 10 90 8C 10 00 2A 50 64 0A 4A 04 90 00 15 00
00 1E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7F

But unfortunately, there’s no backlight. Perhaps I need to write an overlay or some such to enable it, I’m not sure. Taking a screenshot of the console even with the display off, does show the output is going there, and it’s set to 400x1280 though.

I know this is an older thread and apologize for bumping, but I figured if someone else wants to take up the torch, they could have the progress I made on it this weekend.

Quick edit, sorry… the edid-decode I posted above is not the same, I’m sure someone will notice - the correct edid-decode output (the edid block as pasted is correct) is:

steev@rzero:~/temp$ edid-decode ../waveshare-edid
edid-decode (hex):

00 ff ff ff ff ff ff 00 21 f4 4c 4f 01 00 00 00
1f 1d 01 03 80 12 1b 78 0a f0 65 98 57 51 91 27
21 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 cc 10 90 8c 10 00 2a 50 64 0a
4a 04 90 00 15 00 00 1e cc 10 80 8c 10 00 2a 50
64 0a 4a 04 90 00 15 00 00 1e 00 00 00 fc 00 57
61 76 65 53 68 61 72 65 0a 20 20 20 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 e5

02 03 1a 71 47 c6 46 46 46 46 46 46 23 09 07 01
83 01 00 00 65 03 0c 00 10 00 cc 10 90 8c 10 00
2a 50 64 0a 4a 04 90 00 15 00 00 1e cc 10 90 8c
10 00 2a 50 64 0a 4a 04 90 00 15 00 00 1e cc 10
90 8c 10 00 2a 50 64 0a 4a 04 90 00 15 00 00 1e
cc 10 90 8c 10 00 2a 50 64 0a 4a 04 90 00 15 00
00 1e 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7f

----------------

Block 0, Base EDID:
  EDID Structure Version & Revision: 1.3
  Vendor & Product Identification:
    Manufacturer: HOT
    Model: 20300
    Serial Number: 1
    Made in: week 31 of 2019
  Basic Display Parameters & Features:
    Digital display
    Maximum image size: 18 cm x 27 cm
    Gamma: 2.20
    RGB color display
    First detailed timing is the preferred timing
  Color Characteristics:
    Red  : 0.5966, 0.3427
    Green: 0.3164, 0.5664
    Blue : 0.1533, 0.1308
    White: 0.3134, 0.3291
  Established Timings I & II: none
  Standard Timings: none
  Detailed Timing Descriptors:
    DTD 1:   400x1280   60.234213 Hz   5:16    79.630 kHz     43.000000 MHz (400 mm x 1280 mm)
                 Hfront  100 Hsync  10 Hback   30 Hpol P
                 Vfront   20 Vsync  10 Vback   12 Vpol P
    DTD 2:   384x1280   62.073426 Hz   3:10    82.061 kHz     43.000000 MHz (400 mm x 1280 mm)
                 Hfront  100 Hsync  10 Hback   30 Hpol P
                 Vfront   20 Vsync  10 Vback   12 Vpol P
    Display Product Name: 'WaveShare'
    Empty Descriptor
  Extension blocks: 1
Checksum: 0xe5

----------------

Block 1, CTA-861 Extension Block:
  Revision: 3
  Basic audio support
  Supports YCbCr 4:4:4
  Supports YCbCr 4:2:2
  Native detailed modes: 1
  Video Data Block:
    VIC 198:  7680x4320   50.000000 Hz  16:9    220.000 kHz   2376.000000 MHz
    VIC  70:  1280x720   100.000000 Hz  64:27    75.000 kHz    148.500000 MHz
    VIC  70:  1280x720   100.000000 Hz  64:27    75.000 kHz    148.500000 MHz
    VIC  70:  1280x720   100.000000 Hz  64:27    75.000 kHz    148.500000 MHz
    VIC  70:  1280x720   100.000000 Hz  64:27    75.000 kHz    148.500000 MHz
    VIC  70:  1280x720   100.000000 Hz  64:27    75.000 kHz    148.500000 MHz
    VIC  70:  1280x720   100.000000 Hz  64:27    75.000 kHz    148.500000 MHz
  Audio Data Block:
    Linear PCM:
      Max channels: 2
      Supported sample rates (kHz): 48 44.1 32
      Supported sample sizes (bits): 16
  Speaker Allocation Data Block:
    FL/FR - Front Left/Right
  Vendor-Specific Data Block (HDMI), OUI 00-0C-03:
    Source physical address: 1.0.0.0
  Detailed Timing Descriptors:
    DTD 3:   400x1280   60.234213 Hz   5:16    79.630 kHz     43.000000 MHz (400 mm x 1280 mm)
                 Hfront  100 Hsync  10 Hback   30 Hpol P
                 Vfront   20 Vsync  10 Vback   12 Vpol P
    DTD 4:   400x1280   60.234213 Hz   5:16    79.630 kHz     43.000000 MHz (400 mm x 1280 mm)
                 Hfront  100 Hsync  10 Hback   30 Hpol P
                 Vfront   20 Vsync  10 Vback   12 Vpol P
    DTD 5:   400x1280   60.234213 Hz   5:16    79.630 kHz     43.000000 MHz (400 mm x 1280 mm)
                 Hfront  100 Hsync  10 Hback   30 Hpol P
                 Vfront   20 Vsync  10 Vback   12 Vpol P
    DTD 6:   400x1280   60.234213 Hz   5:16    79.630 kHz     43.000000 MHz (400 mm x 1280 mm)
                 Hfront  100 Hsync  10 Hback   30 Hpol P
                 Vfront   20 Vsync  10 Vback   12 Vpol P
Checksum: 0x7f
1 Like
#13

I’ve made some progress! Someone pinged me on Discord to ask me if I’d done any more digging, and, I hadn’t… I pointed him at this forum post, and he shot back… what if the issue is in the driver, not the monitor?

Then he suggested maybe we needed to add the 400x1280 mode, and I thought back to adding in the patch that adds 2K resolution, and it modifies what is considered a bad mode in the venc driver, so… did that. Because the edid’s second DTD lists 384 as the lowest resolution, I changed the constraints for a bad mode to accept 384 as the lowest (currently it’s 640x480)

And… it sort of works! It doesn’t work to force the edid, that ends up showing the text for a moment and then fading to black (but with the backlight on), however, letting it just use the waveshare’s edid we do get… something :smiley:

For reference, here’s my patch - https://github.com/steev/linux/commit/bac4e2dc8d140b6425327f6ec2c23f739d67a18b

and

1663316182.JPG768×1024 51 KB

There is a picture of it sort of working :smiley:

1 Like
#14

Congratulations! Never thought it’s just a simple fix. Thanks for sharing.

#15

Hi!
Is it possible to force the Zero to output RGB over the HDMI port?
I think its a problem with RGB vs. YCBCR.

Regards
Stefan

#16

@_dev-null was on the right track, and correct.

adding drm.debug=0x02 to extraargs gets us

[    7.661478] [drm:dw_hdmi_phy_init [meson_dw_hdmi]] "400x1280" div10
[    7.839700] [drm:meson_venc_hdmi_encoder_atomic_check [meson_dw_hdmi]] output_bus_fmt 2025

And if we do a quick lookup in the kernel for what output_bus_fmt 2025 is we get MEDIA_BUS_FMT_YUV8_1X24

and if we look in the kernel docs for dw-hdmi we see that it’s YCbCr 4:4:4 8bit

So, a quick google search lead me to https://gist.github.com/RLovelett/171c374be1ad4f14eb22fe4e271b7eeb this gist, which has us edit the edid with wxedid and making the same changes mentioned:

cp /sys/devices/platform/soc/ff900000.vpu/drm/card0/card0-HDMI-A-1/edid ~/edid.bin
Open the edid.bin file with wxEDID
Find SPF: Supported features -> vsig_format -> replace 0b01 wih 0b00
Find CHD: CEA-861 header -> change the value of YCbCr420 and YCbCr444 to 0
Find VSD: Vendor Specific Data Block -> Change the value of DC_Y444 to 0
Click Option on the panel-> Recalc Checksum
Save patched EDID and exit

Then I copied the edid.bin to /lib/firmware/edid/400x1280.bin
rebuild the initramfs with update-initramfs -u -k <mykernelversion>
add extraargs=drm.edid_firmware=edid/400x1280.bin in /boot/uEnv.txt

reboot… and it’s working with the correct colors.

852B8801-9A49-48CD-A997-801C0C2BB2C2
852B8801-9A49-48CD-A997-801C0C2BB2C2.jpg1512×2016 1.58 MB

I tried to attach the edid bin, but the forums don’t accept them, so, you can find it at https://buildd-arm.kali.org/experiments/400x1280.bin - it’s only 256bytes but just in case, the sha256sum for it is b5214db82c0dec28d42828cb0052264469099a7200148025179939476e35d455

Oh, reading back over my previous post, in case someone isn’t aware of how to make an initramfs hook, the one i created goes in /etc/initramfs-tools/hooks/ and i named it… edid and it has the following contents:

#!/bin/sh
PREREQS=""
case $1 in
  prereqs) echo "${PREREQS}"; exit 0;;
esac

. /usr/share/initramfs-tools/hook-functions
copy_file firmware /lib/firmware/edid/400x1280.bin /usr/lib/firmware/edid/400x1280.bin

Don’t forget that if you want the hook to be used when update-initramfs runs, you need to sudo chmod +x /etc/initramfs-tools/hooks/edid - and if you want to stop doing so, sudo chmod -x /etc/initramfs-tools/hooks/edid

Now you really should have everything to be able to get display on boot.

Rotating the screen:

If you want it to be 1280x400, instead of the default vertical, despite the thinking that you should pass video=HDMI-A-1=1280x400 you actually pass fbcon the rotate option.

  • 0 - Normal rotation
  • 1 - Rotate clockwise
  • 2 - Rotate upside down
  • 3 - Rotate counter-clockwise

So for the display as you see it in my picture, where the bottom of the screen is the opposite of the hdmi cable, your extraargs line would look like extraargs=drm.edid_firmware=edid/400x1280.bin fbcon=rotate:3

3 Likes
Armbian on radxa zero doesn't produce picture on 1920x480 display
#17

I’m still rebuilding my kernel, buuuuut, someone else figured out the commit that breaks things; as well as posted a patch - https://github.com/tobetter/linux/issues/37

That patch should fix the issue and make the need for edid hacking moot. Once my kernel finishes rebuilding, will report back if it works.

1 Like
#18

Okay tested, that does indeed work :slight_smile:

So the 2 patches people need to get (most?) waveshare working with their radxa zero’s are gonna be:

github steev/linux/ in my radxa-zero-linux-5.10.y branch. 02ca3d9957984209f46bfb48b492d97adac58646 and 3b48f4afdaaadbdd53fcc093a3f383bd9a603771 additionally, 3b48f4afdaaa relies on 61fee730725bdab2fabbd34ffa95cfe7ea225caa which adds 2K display support

Disclaimer, the second patch was done by Cheaterman, not me, so I need to remove my S-o-b, it’s just on by default, so I don’t get attribution for his patch. Additional disclaimer, for some reason it’s not letting me link github so… there’s that

#19

It seems I screwed up somehow, and now my older posts are marked as spam :frowning: Sorry about that

#20

And I’ve added another hacky patch as well, which seems to fix the screentearing/jiggle of the 1080p display, with an added benefit of the displays being off a few pixels no longer being the case. Additionally, the 400x1280 display also seems to not have its display pushed down about 5-10 pixels.

the commitish is c9f5ef722ae6c17f426299e030699a23ba150c8f

1 Like