Waveshare 7.9in Touchscreen Support?

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

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

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 :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

It seems I screwed up somehow, and now my older posts are marked as spam :frowning: 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 :wink: )

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 :confused: 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.

Here is the output:

[ 2.275911] meson-drm ff900000.vpu: Queued 2 outputs on vpu
[ 2.276359] meson-drm ff900000.vpu: CVBS Output connector not available
[ 2.307010] meson-drm ff900000.vpu: bound ff600000.hdmi-tx (ops meson_dw_hdmi_ops)
[ 2.307398] [drm] Initialized meson 1.0.0 20161109 for ff900000.vpu on minor 0
[ 2.360614] meson-drm ff900000.vpu: [drm] Cannot find any crtc or sizes
[ 3.696342] systemd[1]: Starting Load Kernel Module drm…
[ 3.772312] systemd[1]: modprobe@drm.service: Deactivated successfully.
[ 3.773025] systemd[1]: Finished Load Kernel Module drm.
[ 4.771994] [drm] Initialized panfrost 1.1.0 20180908 for ffe40000.gpu on minor 1

Which kernel are you building, and how are you building it? And what does your /boot/uEnv.txt or /boot/extlinux/extlinux.conf file look like? there should be more messages if you have drm.debug=0x02 in the kernel command line.

To be clear, you’re not just trying to use my edid file I linked are you? because that edid file is specifically for the 400x1280 display, not yours which is apparently 400x1920?