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…
Waveshare 7.9in Touchscreen Support?
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
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 
For reference, here’s my patch - https://github.com/steev/linux/commit/bac4e2dc8d140b6425327f6ec2c23f739d67a18b
and
There is a picture of it sort of working
1 Like
Congratulations! Never thought it’s just a simple fix. Thanks for sharing.
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
@_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.
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
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
Okay tested, that does indeed work 
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
It seems I screwed up somehow, and now my older posts are marked as spam 
Sorry about that
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
These are some pretty awesome developments man!
Thanks a ton for all the work you’ve done to get this working!
Once I actually figure out how to implement these commits, I will be doing so, haha!
One easy way, would be to just clone my repo (the radxa-zero-linux-5.10.y) branch, and build it the same way they recommend to build the vendor kernel in the wiki; I’ve tried to stay as close to the vendor repo as possible, I just rebase on top of the latest 5.10 each time it comes out.
Alternatively, just grab the mentioned commits and apply them to the radxa 5.10 kernel sources (or maybe ask @jack if they could pull them in 
)
1 Like
your posts should be restored.
btw, could you make pull-request?
1 Like
Absolutely, I didn’t even think about that, sorry!
1 Like
I was working from home the last few days and still working through my backlogs. Gonna review the PR this week.
Thank you for this I am currently compiling the kernel!
It doesn’t work 
I have a 480 x 1920 screen and no picture sadly.
Can you add “drm.debug=0x02” to your kernel command line, and then after booting, ssh into your machine and run “dmesg | grep drm” and provide the output?
I will try that tomorrow. Also what is a kernel command line I’m new to Linux kernel development.
Ah, well in this case, it should be a matter of just editing or adding “extraargs=drm.debug=0x02” (without the quotes) in /boot/uEnv.txt - this just tells the drm subsystem to give us driver debugging outputs. i want to see if it’s actually not seeing things, or if maybe it’s something else. I looked in my code and it definitely should handle 480x1920.