Jump to content

Orange Pi One - generic Waveshare 800x480 HDMI (resolution [solved] / touch [unsolved])

Guest

By Guest
in Allwinner sunxi

 Share

Recommended Posts

Guest

Guest

Posted
Posted (edited)

Hello! I recently bought a generic Waveshare 800x480 HDMI (B) USB Touchscreen (rev 3.0), and I'm having problems to make it work properly on Armbian. After a long research, I ended up realizing it's a common problem, and yet I haven't been able to find a solution. It seems there was a patch somewhere, but that link is not available anymore.

I'm using the Armbian Desktop 5.31 , running on an Orange Pi One.

I've already set it up using h3disp -m 800x480 -d, and tried everything but it won't work. Vertical resolution seems to be right, but horizontal only fits around 3/4 of screen and it's noisy (the same problem everyone seems to have). I have tried this with my PC and works totally right, so it's not screen's fault. Also, xrandr gives the right dimensions.

 

FE1.jpg

 

Despite I'm using TTY, originally it was a Desktop image, and I didn't delete any driver

047.jpg

 

cat /dev/random > /dev/fb0

BA5.jpg

 

Noise can be seen better running xterm

963.jpg

 

B66.png

 

FEX configs: 

[disp_init]
disp_init_enable = 1
disp_mode = 0
screen0_output_type = 3
screen0_output_mode = 31
screen1_output_type = 3
screen1_output_mode = 31
fb0_format = 0
fb0_width = 800
fb0_height = 480
fb1_format = 0
fb1_width = 800
fb1_height = 480
screen0_out_color_range = 1
hdcp_enable = 1
hdmi_cts_compatibility = 0

[hdmi_para]
hdmi_used = 1
hdmi_power = "vcc-hdmi-18"
hdcp_enable = 0
hdmi_cts_compatibility = 1
hdmi_x = 800
hdmi_y = 480

 

Thanks in advance!

Edited by chwe
adjusted title
jernej

jernej

Posted
Posted

Legacy kernel (3.4) doesn't support many resolutions (driver issue). Depending on what you need, you can try with Armbian dev or next, which supports all resolutions, but not everything is well supported.

Guest

Guest

Posted
Posted
1 minute ago, jernej said:

Legacy kernel (3.4) doesn't support many resolutions (driver issue). Depending on what you need, you can try with Armbian dev or next, which supports all resolutions, but not everything is well supported.

I know, but afaik there are some people who made it work using some patches or so. I need graphics acceleration, so mainline isn't a choice (unless you can tell me that QtQuick works good on there, without Mali drivers, which I doubt because it runs on OpenGL) :(

jernej

jernej

Posted
Posted

Well, X11 Mali driver doesn't work well yet, we have troubles with performance. However, gbm Mali driver works just fine (tested with Kodi). AFAIK Qt supports gbm interface, but I didn't test it. gbm interface means dealing directly with screen without any desktop environment.

 

If you want to go hard way, I explained a few times in different topics on forum how to calculate required numbers and how to patch kernel.

jernej

jernej

Posted
Posted

I think second number in this line https://github.com/armbian/build/blob/199eaaec08fd481345983375f2810e3a3ba0024c/patch/kernel/sun8i-default/z-0003-add-additional-video-modes.patch#L166 should be 11 and pll_video should be 297.

 

Rationale:

800x480 has pixel frequency 27 MHz. Divider that can be used are only 1, 2, 4 and 11. Default pll_video clock is 297 MHz so we should be as close as possible to that number.

Fortunately, 27 MHz * 11 = 297 MHz.

zador.blood.stained

zador.blood.stained

Posted
Posted

Are you sure that line 166 (starting with 31) is responsible for this mode? It's confusing, but I believe it should be the line starting with 35: https://github.com/armbian/build/blob/master/patch/kernel/sun8i-default/0026-h3-hdmi-additional-mode-800x480p-from-lobodis-initia.patch

 

Edit: yes, this spaghetti code is confusing, but to me it looks like mode 31 is defined by this 

DISP_TV_MOD_800_480P            = 0x1f,

and not by this 

#define HDMI800_480P            35

 - this defines the row in the para_tab table

Guest

Guest

Posted
Posted
36 minutes ago, Khandoker Mazidul Haque said:

Yes, changing the mode 31 pll_video=594 and then apply the command h3disp -m 31 -d solved the problem for 800x480 res TFP401 based displays.

This made the trick! Thank you all very much for your comments. I tried this before the other solutions because it was the simplest, and it worked perfectly! No needs to recompile the kernel or so. Just in case, I had to update this through the bin2fex and fex2bin because the armbian-config fex editor didn't save that setting.

zador.blood.stained

zador.blood.stained

Posted
Posted

@jernej

So seems that it works with doubled pixel clock: 594/11=54=27*2, so if there are no bad side effects to this it would be easier to patch only h3disp and leave the kernel as is (otherwise upgrading the kernel with changed divider will break video output for people who changed pll_video manually).

jernej

jernej

Posted
Posted
41 minutes ago, zador.blood.stained said:

if there are no bad side effects to this it would be easier to patch only h3disp

I'm not sure about side effects. I know only how it should be :)

 

Anyway, since 594 is dividable with both, 11 and 2, I think it would still work if kernel gets fixed. However, someone should try first.

Guest

Guest

Posted
Posted
On 10/8/2017 at 9:05 AM, zador.blood.stained said:

@jernej

So seems that it works with doubled pixel clock: 594/11=54=27*2, so if there are no bad side effects to this it would be easier to patch only h3disp and leave the kernel as is (otherwise upgrading the kernel with changed divider will break video output for people who changed pll_video manually).

I couldn't find any side effect yet, so it seems to work properly. Way easier than patching the kernel and way easier to maintain with further updates

Guest

Guest

Posted
Posted

Now I'm facing another issue. I can get the touchscreen detected by kernel and by evdev, but it won't go further.

Running on Armbian 5.31 - Ubuntu. Untouched kernel

I can get a raw input by doing: 

root@orangepione:~# cat /dev/hidraw0
<dirty ascii chars, but response variates if I put different amount of fingers on it,
so I know the touch itself is working (besides testing it on Windows)>

This are my usb devices: 

root@orangepione:~# lsusb
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 003: ID 0483:5750 STMicroelectronics
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Evtest output:  

root@orangepione:~# evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:      vmouse
/dev/input/event1:      sunxi-gpiokey
/dev/input/event2:      sunxi-ths
/dev/input/event3:      sunxi-ir
/dev/input/event4:      MCE IR Keyboard/Mouse (sunxi-ir)
/dev/input/event5:      深圳市全动电子技术有限公司 ByQDtech 触控USB鼠标
Select the device event number [0-5]: 5
Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0x483 product 0x5750 version 0x110
Input device name: "深圳市全动电子技术有限公司 ByQDtech 触控USB鼠标"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 330 (BTN_TOUCH)
  Event type 3 (EV_ABS)
    Event code 0 (ABS_X)
      Value      0
      Min        0
      Max      800
    Event code 1 (ABS_Y)
      Value      0
      Min        0
      Max      480
    Event code 24 (ABS_PRESSURE)
      Value      0
      Min        0
      Max      255
    Event code 47 (ABS_MT_SLOT)
      Value      0
      Min        0
      Max        9
    Event code 53 (ABS_MT_POSITION_X)
      Value      0
      Min        0
      Max      800
    Event code 54 (ABS_MT_POSITION_Y)
      Value      0
      Min        0
      Max      480
    Event code 57 (ABS_MT_TRACKING_ID)
      Value      0
      Min        0
      Max    65535
    Event code 58 (ABS_MT_PRESSURE)
      Value      0
      Min        0
      Max      255
Properties:
  Property type 1 (INPUT_PROP_DIRECT)
Testing ... (interrupt to exit)

It dies there. It only prints Event: time 1507570294.157946, -------------- SYN_REPORT ------------  the first time after connection. It will not print that again unless I disconnect and reconnect it.

 

Dmesg:  

[  176.072783] hid-multitouch 0003:0483:5750.0002: input,hidraw0: USB HID v1.10 Device [深圳市全动电子技术有限公司 ByQDtech 触控USB鼠标] on usb-sunxi-ohci-1/input0

 

This touchscreen ended up being way more difficult than what I expected, but the last fix (for video output) was really easy, so I hope this one too. I googled everywhere and I couldn't find anything. I also tried testing it with X11, xinput_calibrator, but no response.

 

Thanks in advance!

Guest

Guest

Posted
Posted

UPDATE:  I built the dev branch and both screen and touchscreen works perfectly on:

uname -a 

Linux orangepione 4.11.12-sun8i #5 SMP Mon Oct 16 22:53:23 ART 2017 armv7l armv7l armv7l GNU/Linux

So it's gotta be a bug in the legacy kernel. I tried a fresh 5.25 Legacy Armbian Desktop to test, and same results than on 5.31. So, the only solution I've currently found is to use Mainline builds. Now I really need Mali Drivers to be released for Mainline because I need HW acceleration :(. Nevertheless, I hope this research helps someone.

I'll update with anything future I achieve.

malekhosseini

malekhosseini

Posted
Posted (edited)

hi jistycs

I am a beginner and have a same problem. I use this solution and my LCD work in 800x480 resolution.  I haven't been able to find a solution for touch screen. 'lsusb' show touch screen as 'STMicroelectronics'. but using 'evtest' hasn't result for it.  

Please explain your solution for beginners like me.

Thanks

Edited by malekhosseini
Andralin

Andralin

Posted
Posted

Dear All,

I'm new to OrangePi, I've just bought my first device.

Using the information above I successfully made my Adafruit 2232 5 inch non-touch HDMI display working perfectly with my Orange Pi PC Plus!

Many thanks, it's a really useful topic.

Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept