Ongoing HDMI limited compatability

[tllim]

cat: graphics/fb0/modes: No such file or directory

These are relative paths, most likely relative to /sys/class (don't know -- booted the Pine64 a few weeks ago the last time). You might succeed doing a 'find /sys -type d -name fb0' to know the prefix needed to chdir to or create absolute paths.

Thanks, when acting as 'smart hands' and troubleshooting using instructions from another person I tend to be terribly literal. Using the info you provided;

Code:

root@localhost:~# find /sys -type d -name fb0
/sys/devices/soc.0/1000000.disp/graphics/fb0
root@localhost:~# cat /sys/devices/soc.0/1000000.disp/graphics/fb0/modes
U:1920x1080p-0

Decided to get a bit more info using another method. I hooked my pi to the monitor and pulled EDID info. 

Code:

root@raspberrypioldpi:~# tvservice -s
state 0x120006 [DVI DMT (57) RGB full 16:10], 1680x1050 @ 60.00Hz, progressive
root@raspberrypioldpi:~# tvservice -m DMT
Group DMT has 4 modes:
          mode 4: 640x480 @ 60Hz 4:3, clock:25MHz progressive
          mode 9: 800x600 @ 60Hz 4:3, clock:40MHz progressive
          mode 16: 1024x768 @ 60Hz 4:3, clock:65MHz progressive
 (prefer) mode 57: 1680x1050 @ 60Hz 16:10, clock:119MHz progressive
root@raspberrypioldpi:~# tvservice -m CEA
Group CEA has 7 modes:
          mode 1: 640x480 @ 60Hz 4:3, clock:25MHz progressive
          mode 2: 720x480 @ 60Hz 4:3, clock:27MHz progressive
          mode 3: 720x480 @ 60Hz 16:9, clock:27MHz progressive
 (native) mode 4: 1280x720 @ 60Hz 16:9, clock:74MHz progressive
          mode 5: 1920x1080 @ 60Hz 16:9, clock:74MHz interlaced
          mode 6: 720x480 @ 60Hz 4:3, clock:27MHz x2 interlaced
          mode 7: 720x480 @ 60Hz 16:9, clock:27MHz x2 interlaced

Thats the simple stuff, attached is the output of;

Code:

root@raspberrypioldpi:~# tvservice -d edid.dat
Written 256 bytes to edid.dat
root@raspberrypioldpi:~# edidparser edid.dat > edid.txt

Also adding full pi serial console boot log.

Code:

root@raspberrypioldpi:~# cat /sys/devices/platform/soc/soc:fb/graphics/fb0/modes
U:1680x1050p-0

ATTENTION Moderator Note

Forum doesn't allow upload of files with the extension .log seriously? Might what to address that lol.

I will check out.

[rahlquist]

I will check out.

tllim while you are at it, can you please check if Allwinner will be adding CEC support for HDMI, for all OS's? It would make life a lot easier. 

[   11.102069] [DISP] boot_disp:0x40a
[   11.111232] [HDMI] power vcc-hdmi-33
[   11.120221] [HDMI] cec support = 0
[   11.633738] [DISP] disp_device_attached,line:94:attched ok, mgr0<-->device1, type=4

[longsleep]

These are relative paths, most likely relative to /sys/class (don't know -- booted the Pine64 a few weeks ago the last time). You might succeed doing a 'find /sys -type d -name fb0' to know the prefix needed to chdir to or create absolute paths.

Yes sorry that should have been

Code:

xxd /sys/class/hdmi/hdmi/attr/edid
cat /sys/class/graphics/fb0/modes

Decided to get a bit more info using another method. I hooked my pi to the monitor and pulled EDID info. 

Code:

root@raspberrypioldpi:~# tvservice -s
state 0x120006 [DVI DMT (57) RGB full 16:10], 1680x1050 @ 60.00Hz, progressive

So why is your RPi not use 1080p @60.00Hz? This is the only physical resolution currently supported with my images.

---

[code]root@raspberrypioldpi:~# tvservice -d edid.dat
Written 256 bytes to edid.dat
root@raspberrypioldpi:~# edidparser edid.dat > edid.txt

So, from the edid data your monitor does not support 1080p @ 60Hz and thus does not work.

See http://paste.ubuntu.com/15954272/ as example for a TV which works without any issue (Toshiba).

[rahlquist]

So why is your RPi not use 1080p @60.00Hz? This is the only physical resolution currently supported with my images.

---

[code]root@raspberrypioldpi:~# tvservice -d edid.dat
Written 256 bytes to edid.dat
root@raspberrypioldpi:~# edidparser edid.dat > edid.txt

So, from the edid data your monitor does not support 1080p @ 60Hz and thus does not work.

See http://paste.ubuntu.com/15954272/ as example for a TV which works without any issue (Toshiba).

Exactly the point. If a TV or Monitor wont accept 1080p in the Pine just doesnt work. It is not uncommon for 720p devices to not downscale from 1080p. So that is why it doesnt work. 

To verify I set the pi to force 1080p out and the screen no longer works.

Is there any possibility of you adding 720p support? That should cover another large portion of devices increasing compatibility?

[tkaiser]

Exactly the point. If a TV or Monitor wont accept 1080p in the Pine just doesnt work.

As expected: Unlike others longsleep updates his images and documents their behaviour. That's the first sentence everyone can read when clicking on the threads describing both his Arch and Xenial image:

What you get:


- HDMI at 1080p with 60Hz

Now please look at http://wiki.pine64.org/index.php/Pine_A6...ge_Release

HDMI resolution limitation warning disappeared. The 'featured' OS images are outdated, descriptions insufficient and wrong. Links to longsleep's images have been added a few hours ago (before there was nothing, only links to the 'featured' images based on his work). And instead of linking to the threads where everything is explained just links to torrents.

Everything as expected causing frustration and hours of hours of wasted time by countless users (like you for example). And they still do NOT have a quickstart guide where all this is explained. Instead the mess continues. Again: the whole issue is just another example for missing/wrong documentation and therefore surreal expectations.

Did you ever had a look into the BSP kernel sources? Now that tllim announced he got a BSP 2.0 (maybe based on a different kernel version?) everything will get even worse. Dealing with this BSP crap is PITA so I would suspect the real developers will start to focus on mainline kernel from now on. Who wants to throw his own work in the bin just to start from scratch with a new kernel tree (most likely containing the same mistakes as before) since Allwinner feels the need to play 'port and forget' every few months?

And I would suspect in the new BSP both libdram and libhdmi are closed source again. Why should a developer in his own spare time deal with this crap at all? Only since the Pine64 folks raised expectations by removing documentation?

The official Pine64 check list:

• use Micro USB for DC-IN to encourage users to use Phone chargers, bad USB cables, insufficient 'smart chargers' and the like to reliably prevent their boards from booting
  
• do NOT provide a quickstart guide warning for fake/counterfeit SD cards and do NOT explain that Phoenix Card throwing errors is an indication for 'something's wrong', encourage users to use fake/counterfeit cards to get in trouble
  
• take a community member's OS images, add some stuff, remove documentation and links to the original to raise expectations (adding XFCE to an image that is know to only show display output at ONE SPECIFIC HDMI resolution and then removing the specific warning is a statement: "Take a look newbies, this is our Desktop Linux image")
  
• save a programmable onboard led able to provide user feedback to ensure everyone plagued by the above thinks his board is DOA
  

and so on... everything as expected: KS backers wasting their time and thinking their boards are bricked. And with every new OS image variant appearing here it will get even more worse.

[rahlquist]

and so on... everything as expected: KS backers wasting their time and thinking their boards are bricked. And with every new OS image variant appearing here it will get even more worse.

Yeah. I had hopes this would work out better for my needs than a pi, unfortunately the KS team made promises that I know Allwinner is just not going to let them deliver on (I thought they had by some miracle already achieved them).

I guess I will just unplug my board and set it on the shelf as a reminder of how stupid it is to believe in an KS..

[tllim]

cat: graphics/fb0/modes: No such file or directory

These are relative paths, most likely relative to /sys/class (don't know -- booted the Pine64 a few weeks ago the last time). You might succeed doing a 'find /sys -type d -name fb0' to know the prefix needed to chdir to or create absolute paths.

Thanks, when acting as 'smart hands' and troubleshooting using instructions from another person I tend to be terribly literal. Using the info you provided;

Code:

root@localhost:~# find /sys -type d -name fb0
/sys/devices/soc.0/1000000.disp/graphics/fb0
root@localhost:~# cat /sys/devices/soc.0/1000000.disp/graphics/fb0/modes
U:1920x1080p-0

Decided to get a bit more info using another method. I hooked my pi to the monitor and pulled EDID info. 

Code:

root@raspberrypioldpi:~# tvservice -s
state 0x120006 [DVI DMT (57) RGB full 16:10], 1680x1050 @ 60.00Hz, progressive
root@raspberrypioldpi:~# tvservice -m DMT
Group DMT has 4 modes:
          mode 4: 640x480 @ 60Hz 4:3, clock:25MHz progressive
          mode 9: 800x600 @ 60Hz 4:3, clock:40MHz progressive
          mode 16: 1024x768 @ 60Hz 4:3, clock:65MHz progressive
 (prefer) mode 57: 1680x1050 @ 60Hz 16:10, clock:119MHz progressive
root@raspberrypioldpi:~# tvservice -m CEA
Group CEA has 7 modes:
          mode 1: 640x480 @ 60Hz 4:3, clock:25MHz progressive
          mode 2: 720x480 @ 60Hz 4:3, clock:27MHz progressive
          mode 3: 720x480 @ 60Hz 16:9, clock:27MHz progressive
 (native) mode 4: 1280x720 @ 60Hz 16:9, clock:74MHz progressive
          mode 5: 1920x1080 @ 60Hz 16:9, clock:74MHz interlaced
          mode 6: 720x480 @ 60Hz 4:3, clock:27MHz x2 interlaced
          mode 7: 720x480 @ 60Hz 16:9, clock:27MHz x2 interlaced

Thats the simple stuff, attached is the output of;

Code:

root@raspberrypioldpi:~# tvservice -d edid.dat
Written 256 bytes to edid.dat
root@raspberrypioldpi:~# edidparser edid.dat > edid.txt

Also adding full pi serial console boot log.

Code:

root@raspberrypioldpi:~# cat /sys/devices/platform/soc/soc:fb/graphics/fb0/modes
U:1680x1050p-0

ATTENTION Moderator Note

Forum doesn't allow upload of files with the extension .log seriously? Might what to address that lol.

I will check out.

The extension .log file now allow to upload.

[tllim]

So why is your RPi not use 1080p @60.00Hz? This is the only physical resolution currently supported with my images.

---

[code]root@raspberrypioldpi:~# tvservice -d edid.dat
Written 256 bytes to edid.dat
root@raspberrypioldpi:~# edidparser edid.dat > edid.txt

So, from the edid data your monitor does not support 1080p @ 60Hz and thus does not work.

See http://paste.ubuntu.com/15954272/ as example for a TV which works without any issue (Toshiba).

Exactly the point. If a TV or Monitor wont accept 1080p in the Pine just doesnt work. It is not uncommon for 720p devices to not downscale from 1080p. So that is why it doesnt work. 

To verify I set the pi to force 1080p out and the screen no longer works.

Is there any possibility of you adding 720p support? That should cover another large portion of devices increasing compatibility?

This is software limitation and also push for more video resolution.

[rahlquist]

This is software limitation and also push for more video resolution.

Sorry but what  you are saying here isnt horribly clear. Are you saying the limitation of only one resolution is tied to the same issues as the lack of higher resolutions?

[tllim]

I will check out.

tllim while you are at it, can you please check if Allwinner will be adding CEC support for HDMI, for all OS's? It would make life a lot easier. 

[   11.102069] [DISP] boot_disp:0x40a
[   11.111232] [HDMI] power vcc-hdmi-33
[   11.120221] [HDMI] cec support = 0
[   11.633738] [DISP] disp_device_attached,line:94:attched ok, mgr0<-->device1, type=4

I will check out on next week.