Rock PI 4b 7 inch Display Touchscreen issue

#1

The touchscreen does not work correctly on 7 inch Raspberry Display.
Sometimes there is no reaction to movement. Sometimes when you tap on the screen, the input event is duplicated.

There are many errors in dmesg logs:
[58093.177155] rockpi-ft5406: fts_i2c_read: i2c read error, -6
[58093.177671] rockpi-ft5406: fts_read_td_status: get reg td_status failed, -6
[58093.296881] rockpi-ft5406: fts_i2c_read: i2c read error, -6
[58093.297397] rockpi-ft5406: fts_read_td_status: get reg td_status failed, -6
[58093.416833] rockpi-ft5406: fts_i2c_read: i2c read error, -6
[58093.417350] rockpi-ft5406: fts_read_td_status: get reg td_status failed, -6

evtest log (tap on screen and hold):

Event: time 1637317152.018684, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value 81
Event: time 1637317152.018684, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 102
Event: time 1637317152.018684, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 257
Event: time 1637317152.018684, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
Event: time 1637317152.018684, -------------- SYN_REPORT ------------
Event: time 1637317152.042661, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value -1
Event: time 1637317152.042661, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
Event: time 1637317152.042661, -------------- SYN_REPORT ------------
Event: time 1637317152.354578, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value 82
Event: time 1637317152.354578, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 105
Event: time 1637317152.354578, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 261
Event: time 1637317152.354578, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
Event: time 1637317152.354578, -------------- SYN_REPORT ------------
Event: time 1637317152.377796, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value -1
Event: time 1637317152.377796, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
Event: time 1637317152.377796, -------------- SYN_REPORT ------------
Event: time 1637317152.522610, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value 83
Event: time 1637317152.522610, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
Event: time 1637317152.522610, -------------- SYN_REPORT ------------
Event: time 1637317152.545817, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value -1
Event: time 1637317152.545817, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
Event: time 1637317152.545817, -------------- SYN_REPORT ------------
Event: time 1637317152.978610, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value 84
Event: time 1637317152.978610, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
Event: time 1637317152.978610, -------------- SYN_REPORT ------------
Event: time 1637317153.001985, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value -1
Event: time 1637317153.001985, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
Event: time 1637317153.001985, -------------- SYN_REPORT ------------
Event: time 1637317153.290575, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value 85
Event: time 1637317153.290575, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
Event: time 1637317153.290575, -------------- SYN_REPORT ------------
Event: time 1637317153.313787, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value -1
Event: time 1637317153.313787, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
Event: time 1637317153.313787, -------------- SYN_REPORT ------------
Event: time 1637317153.602839, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value 86
Event: time 1637317153.602839, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
Event: time 1637317153.602839, -------------- SYN_REPORT ------------
Event: time 1637317153.626220, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value -1
Event: time 1637317153.626220, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
Event: time 1637317153.626220, -------------- SYN_REPORT ------------
Event: time 1637317153.890479, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value 87
Event: time 1637317153.890479, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
Event: time 1637317153.890479, -------------- SYN_REPORT ------------
Event: time 1637317153.914830, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value -1
Event: time 1637317153.914830, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
Event: time 1637317153.914830, -------------- SYN_REPORT ------------
Event: time 1637317154.370732, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value 88
Event: time 1637317154.370732, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
Event: time 1637317154.370732, -------------- SYN_REPORT ------------
Event: time 1637317154.394840, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value -1
Event: time 1637317154.394840, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
Event: time 1637317154.394840, -------------- SYN_REPORT ------------
Event: time 1637317155.318675, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value 89
Event: time 1637317155.318675, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
Event: time 1637317155.318675, -------------- SYN_REPORT ------------
Event: time 1637317155.341784, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value -1
Event: time 1637317155.341784, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
Event: time 1637317155.341784, -------------- SYN_REPORT ------------

Power supply 12v 3 a.

#2

Did you ever get this to work. I am running into a similar issue.

#3

Hello I am new to this but after hours of troubleshooting I was able to get my RIP 7in to work. I first downloaded an image from https://github.com/radxa/rock-pi-images-released/releases. I then went ahead and edited the /boot/hw_intfc.conf file. I changed intfc:i2c2=on, intfc:i2c6=on, intfc:i2c7=on. I then uncommented the line "intfc:dtoverlay=raspberrypi-7-inch-lcd. From there along with the 5v and ground pins I plugged in the SDA and SCL. SDA into GPIO 3 and SCL into GIPO 5. Note you will need to reboot your system after editing the .conf file. Hope this helps!

Rock Pi Debian 10 - Rasperry Pi 7in touch not working
#5

Has anybody ever gotten any DSI panels to work in Armbian? I can’t get the panel to show any output no matter what I do, at least with the 5.10.x kernel. I know some of the node names changed, so I had to rewrite the overlay to switch from dsi to mipi_dsi, but still no luck, though at least I see the changes in the device tree now, so the device tree overlay is at least getting loaded; it just isn’t doing anything.

The only thing even slightly related I see in dmesg is this:

[ 3.074915] vcc_mipi: failed to get the current voltage: -EPROBE_DEFER
[ 3.074934] vcc_mipi: supplied by vcc3v3_sys

which I’m assuming is just one device probing before a dependency’s driver loads, and is uninteresting. And this is six hours into trying to get this thing to actually paint the screen. This really shouldn’t be that hard…

Does anybody have a working overlay that enables DSI output on a 5.10.x or later kernel?

#6

Have you managed to make it work?
I have the same issue on Armbian.

On Radxa image, it displays the same error but then it works:

[ 14.772770] vcc_mipi: failed to get the current voltage: -EPROBE_DEFER
[ 14.772812] vcc_mipi: supplied by vcc3v3_sys
[ 14.772882] vcc_mipi: 3300 mV, enabled

It also loads MIPI-DSI driver which does not load on Armbian (although it should be built in the kernel).
[ 15.209211] dw-mipi-dsi-rockchip ff968000.dsi: [drm:dw_mipi_dsi_bridge_enable] final DSI-Link bandwidth: 696 x 1 Mbps

On Armbian image with 5.15 kernel, it does not display “3300 mV, enabled” message and does not work. The kernel 6.1 seems not to load vcc_mipi at all.
Armbian support is total shit, so I’m trying to fix it on my own.

#7

Armbian is a build framework. If you put shit into, shit will come out. In any case you can’t blame free software initiative also because it officially stop investing into this hardware some time ago, because nobody has interest to cover or at least show respect. Better keeping credibility.

This is generic answer:
https://docs.armbian.com/User-Guide_FAQ/#why-does-hardware-feature-xy-work-in-old-kernel-but-not-in-more-recent-one
If

When you fix things, welcome to join fixes we already made to our common library. And remember to make them 1 USD donation. At least to cover costs of this clarification as total shit support is absolutely not worth supporting.

#8

A nice comparison with Raspberry Pi can be seen here, because although they are free software initiative too, they are very interested in helping others with their problems and almost every time we solved the problems together. On the other side, Armbian forum is full of basic problems (e.g. nonworking USB ports) that absolutely nobody cares about. No responses, no answers, absolutely no interest. Althought the website says to report problem in forum, reporting anything there is like talking to the wall and almost everytime ends up in monolog only. And this is not problem of “this hardware”, because the same pays there for any hardware. And the most funny thing is that reporting problem on Radxa image ends up with “For professional grade software support you need to look elsewhere … Armbian” and when I switch to Armbian, it ends up in “free software initiative also because it officially stop investing into this hardware some time ago”.

#9

Their army of slaves is big.

Don’t try to compare afternoon project that is financed by people that run it with a corporation.

#10

And here we go. Someone who provides development board also provides working updated system and is willing to help the users and you call them slaves. So the main problem here is arrogance.

I understand if something is run by volunteers that work in their free time. I don’t blame Armbian itself that it does not work. I have no problem to invest my own time into the problem and then provide patches to developers (as I did several times for RPi). I also don’t have problem to send the donation if I see at least some effort to help.

But I found out that this problem probably requires custom modification to Rockchip’s MIPI DSI driver and it cannot be done on 6.x kernels due to problems with VCC regulators. So I switch armbian to kernel 5.15 where they work correctly. Then I tried building my own image/kernel and found out that building kernel 5.15 ends up with errors (Armbian building system is not able to download tag/branch from GIT repository although the documentation says it is possible). Searched for the errors by google and what I have found? Posts full of your arrogant shits “we don’t care it does not work but you can send us some money”.

#11

All of HW vendors provides you this illusion. They are making boards / problems and hope community will take it over. Only Rpi has that capacity - also because on its low complexity vs. extreme in this very diverse world (new SoCs designs are coming out fast). Main problem is more complicated but its no point discussing it.

From slaves or HW dealers?

#12

If you think some standard feature does not work, you open a ticket at expected place as nobody will scan 3rd party forums. And wait. If your time is more important then ours, you pay for support. If you act like a spoiled user, you are the one who is arrogant.

All kernels build without problems.

It is possible, but documentation is not up-to-date with changes. Some old methods are deprecated and we haven’t update it you as we have to educated “customers” one by one. This product is a lot better then others but not everything work. Keep the money. Just stop making us expenses.

#13

I agree with you, but vendor that sold you something should be dealing with you.

Armbian framework is a lot more help then “some”. And it seems you are not happy. We didn’t convince you to donate to that effort, you don’t see a point of buying at least some commercial support in order to save weeks of your time and support the project, so why investing even more? Do you have any idea how much efforts (human and financial) are needed to keep this framework in usable state? Not just for this board.

Lets add another to this list, even its pretty futile fight.

Code is provided as is. If something doesn’t work, report the problems this and that way. Relationship ends here. Support is not included or granted. This is illusion that is sold to you by vendors which have strong interest. Their profit lies here. Some vendors also have “professional support agents” in their community (!) forums to keep illusion of community support working and you as consumer also have interest that software works …

If you have problems with open source code and you attack / make pressure to developer with support request, this is one of the responses you will get: “ignore / go away / please pay for services / stop making costs”. Its disrespectful and arrogant from consumer side to push on open source developers and non-profit projects to deal with your (in many cases commercial) problems.

Why others, especially projects who fork us, doesn’t complain? They have no rights and also no problems. They simply don’t deal with them.

#14

From the people who goes to the forum not related to their product, advertise their product in non-related bug reports and then call “slaves” people who have no problem providing support for their product to others.

If it was a true then there would not be a ticket in your github tracker ending with your " we don’t care, it’s your problem but you can co-sponsor".

Right, others don’t complain, expect of many other posts in this forum, many other posts in Armbian forum and many other posts in github tracker.

But in fact, I don’t complain either, I merely noted the truth about Armbian support after you started advertising your product and requesting donations in non-related forum. Nothing more.

#15

You mean for the ticket you have opened for the second time and now its the third time (+ many forum posts here and armbian forums) that problems up in the air? First time I have answered to you what you needed to know, second time I repeat that and gave you commercial support option so you will perhaps understand that its not polite wasting people time, now I am not anymore interested to help regardless of your potential compensation.

The problem you have is not related to Armbian. Its indeed your problem and you know it. Be fair.

The one that doesn’t care would close the ticket down at first suspicious of wrong usage.

#16

I didn’t open any ticket in github tracker so I hardly could have opened there anything for the second or third time. I’m talking about tickets and bug reports that I have found after searching why it is not possible to build 5.15 kernel on Armbian.

The only thing I did was a small polite analysis of non-working DSI/HDMI in Armbian forum to see if someone had the same problem (or possible fix/workaround) too or if I did something wrong. You could simply say “it is not supported” but instead you started to kick around how I hurt Armbian and blah blah blah. https://forum.armbian.com/topic/30811-how-to-make-displays-work-correctly-dsi-hdmi/

I also reported long boot time on official Radxa image and you just came there and started advertising your project. After I said that your project does not support the basic functionality, you started to kick around and beg for donation. Although I have never asked about your project. So if you had nothing to do with the topic of the given problem, then instead of advertising your project, you should have kept your mouth shut.

#17

Apologize. Someone opened similar issue one-two weeks ago.

We have build automation that verifies build-ability of all kernels that are present in the system. The problem is, 5.15.y is not in the system anymore, thus not our problem.

We are developing mechanism to preserve that, but its currently only in the idea phase. I have asked you that you can support development as this means we will develop missing features faster, it will be less burden for us, …

I know that this is pretty long shot. I don’t know many people that can help. I know one or two.

Experiences shows that people usually ignore “not supported”. I always tries to give some context. And I think it was completely professional.

Not really. You forget what you are writing on forums?

“… but since Armbian starts correctly …”

You tried with Armbian and tried to clarify.

#18

If anyone is begging here, its you. You want working display and fast boot? Good luck.

#19

It’s not me who puts a crap begging for donation into every post. I just reported two bugs in two systems. If you consider bug reporting to be begging than you should close Armbian forum and replace all those statement about so-called “support” or bug reporting forms with simple statement “We don’t care something does not work”.

#20

In FOSS its nothing unusual that bug sits in the ticket list for years. Closing time is measured in years.

The basics. Whatever your interpretation of “support” is, you are never in the position to decide: support is best effort.

#21

So it seems that the display does not like to be “contacted” (via i2c_transfer) too often.
I made a workaround in the driver and now the touch works correctly (5.10 kernel).

	int retry = 5;
	while(retry-- > 0) {		
		ret = i2c_transfer(client->adapter, msgs, 2);
		if(ret != -ENXIO) break;
		
		msleep_interruptible(10);
	}