Install problem with monitor

Help and Support Vero
1

I decided, yesterday, to do a clean install of the latest version on Vero.
I was surprised that the latest offered was for the 2015.06-1, but pushed ahead anyway.
The bootup of the SD Card was successful, except that the screen display had the right hand side cut, so that when the prompt to accept the licence conditions came, I couldn’t view or accept it.
As I’ve had this before, I SSH’d in and touch walkthrough_completed

  • this allowed me to boot to the usual home screen, where I set about fixing the problem.
    Settings|System|Video output was set to -
    Windowed (no option to change, as it was blacked)
    Resolution 1920x1080p
    Refresh rate 60.0
    I tried using the calibration, but the display already measured square, and no corner arrows were displayed - display still cut on RHS so no time visible.
    Next I set resolution to 1280x70p, and adjusted the calibration.
    Now I went back to information for the monitor, recorded when using RaspBMC -

[code]pi@raspbmc1:~$ /opt/vc/bin/tvservice -d edid.dat
Written 128 bytes to edid.dat

pi@raspbmc1:~$ /opt/vc/bin/edidparser edid.dat
Enabling fuzzy format match…
Parsing edid.dat…
HDMI:EDID version 1.3, 0 extensions, screen size 38x30 cm
HDMI:EDID features - videodef 0x80 !standby !suspend active off; colour encoding:RGB444|YCbCr422; sRGB is not default colourspace; preferred format is native; does not support GTF
HDMI:EDID found monitor S/N descriptor tag 0xff
HDMI:EDID found monitor name descriptor tag 0xfc
HDMI:EDID monitor name is DELL_E198FP
HDMI:EDID found monitor range descriptor tag 0xfd
HDMI:EDID monitor range offsets: V min=0, V max=0, H min=0, H max=0
HDMI:EDID monitor range: vertical is 56-76 Hz, horizontal is 31-83 kHz, max pixel clock is 140 MHz
HDMI:EDID monitor range does not support GTF
HDMI:EDID found preferred DMT detail timing format: 1280x1024p @ 60 Hz (35)
HDMI:EDID established timing I/II bytes are A5 4B 00
HDMI:EDID found DMT format: code 4, 640x480p @ 60 Hz in established timing I/II
HDMI:EDID found DMT format: code 6, 640x480p @ 75 Hz in established timing I/II
HDMI:EDID found DMT format: code 9, 800x600p @ 60 Hz in established timing I/II
HDMI:EDID found DMT format: code 11, 800x600p @ 75 Hz in established timing I/II
HDMI:EDID found DMT format: code 16, 1024x768p @ 60 Hz in established timing I/II
HDMI:EDID found DMT format: code 18, 1024x768p @ 75 Hz in established timing I/II
HDMI:EDID found DMT format: code 36, 1280x1024p @ 75 Hz in established timing I/II
HDMI:EDID standard timings block x 8: 0x714F 8180 0101 0101 0101 0101 0101 81C0
HDMI:EDID found DMT format: code 21, 1152x864p @ 75 Hz (4:3) in standard timing 0
HDMI:EDID found DMT format: code 35, 1280x1024p @ 60 Hz (5:4) in standard timing 1
HDMI:EDID found DMT format: code 85, 1280x720p @ 60 Hz (16:9) in standard timing 7
HDMI:EDID filtering formats with pixel clock > 162 MHz or h. blanking > 1023
HDMI:EDID best score mode initialised to DMT (4) 640x480p @ 60 Hz with pixel clock 25 MHz (score 0)
HDMI:EDID best score mode is now DMT (4) 640x480p @ 60 Hz with pixel clock 25 MHz (score 36864)
HDMI:EDID best score mode is now DMT (6) 640x480p @ 75 Hz with pixel clock 31 MHz (score 46080)
HDMI:EDID best score mode is now DMT (9) 800x600p @ 60 Hz with pixel clock 40 MHz (score 57600)
HDMI:EDID best score mode is now DMT (11) 800x600p @ 75 Hz with pixel clock 49 MHz (score 72000)
HDMI:EDID best score mode is now DMT (16) 1024x768p @ 60 Hz with pixel clock 65 MHz (score 94370)
HDMI:EDID best score mode is now DMT (18) 1024x768p @ 75 Hz with pixel clock 78 MHz (score 117964)
HDMI:EDID best score mode is now DMT (21) 1152x864p @ 75 Hz with pixel clock 108 MHz (score 174298)
HDMI:EDID best score mode is now DMT (35) 1280x1024p @ 60 Hz with pixel clock 108 MHz (score 5260929)
HDMI:EDID DMT mode (36) 1280x1024p @ 75 Hz with pixel clock 135 MHz has a score of 196608
HDMI:EDID DMT mode (85) 1280x720p @ 60 Hz with pixel clock 74 MHz has a score of 135592
HDMI:EDID preferred mode remained as DMT (35) 1280x1024p @ 60 Hz with pixel clock 108 MHz
HDMI:EDID has only DVI support and no audio support
edid_parser exited with code 0[/code]
This shows an optimum of 1280x1024p @60 Hz - which wasn’t in the vero/osmc list.

Q1) can I somehow force that mode?
Q2) is there a fix to avoid this in future? - I remember there was a discussion at the technical level about such problems and how the offered resolutions were to be selected.
Q3) any chance of TVservice or the equivalent for the vero?

In case this is relevant, the monitor is a Dell E198FP connected via a HDMI to VGA converter (works well with RaspBMC and OSMC and various Pi models)
Derek

2

Hi Derek,

Have you ever used this monitor with the Vero before? If so, it gives us something go on at least.

Can you upgrade to the July update and see if things improve. There have been some changes to enumeration of display modes.

Possibly, but it’d be good to find the root cause first.

That’s a Broadcom proprietary function, which is why we see it on Pi only.

Sam

3

Thanks Sam,
Yes - been using this monitor all along, since I got the vero.
Already upgraded to 2015.07-1 - still appears the same as far as the video settings entries are concerned (same list and blacked out Windows bit).
I started the clean install, hoping that I could start with the 2015.70-1, but was frustrated in that.
I do have a couple of other models of monitor, and will take steps to try them if you think it will help (swapping around can be a bit disruptive, as I have to try to remember what works with what).
Any other diagnostic bits I can try?

Just noticed, in the kodi log, that 1280x1024p @60 doesn’t appear!
Derek

4

Hi Derek,

There is actually a July image that can be directly installed. It’s at http://download.osmc.tv/installers/diskimages/OSMC_TGT_vero1_20150805.img.gz. I haven’t published it on the website, as there is a small bug where going through the Walkthrough process too quickly can result in a crash. Downloading the June version and upgrading should suffice.

Kodi ‘ignores’ some display modes if they’re not appropriate for video. This may be why it’s not showing. The way that the modes are enumerated has also changed, but it should work with either June or July, but maybe not both.

If you can run ‘dmesg’ via SSH and paste the output on the July update that will help a great deal and should show the supported modes in a similar way that tvservice does

Sam

5

OK - here goes with the relevant section

[ 0.386936] mxc_sdc_fb fb@0: register mxc display driver hdmi [ 0.387023] mxc_hdmi 20e0000.hdmi_video: Detected HDMI controller 0x13:0x1a:0xa0:0xc1 [ 0.387048] fbcvt: 1920x1080@60: CVT Name - 2.073M9 [ 0.501925] Console: switching to colour frame buffer device 240x67 [ 0.549245] mxc_hdmi 20e0000.hdmi_video: mxc_hdmi_read_edid HDMI in HDMI mode [ 0.549286] mxc_hdmi 20e0000.hdmi_video: vic: 4, xres = 1280, yres = 720, ratio = 16/9, freq = 60.0Hz, vmode = 8192, flag = 1, pclk = 13468 [ 0.549299] mxc_hdmi 20e0000.hdmi_video: vic: 4, xres = 1280, yres = 720, ratio = 16/9, freq = 59.940Hz, vmode = 40960, flag = 1, pclk = 13481 [ 0.549314] mxc_hdmi 20e0000.hdmi_video: vic: 4, xres = 1280, yres = 720, ratio = 16/9, freq = 60.0Hz, vmode = 8192, flag = 2, pclk = 13468 [ 0.549325] mxc_hdmi 20e0000.hdmi_video: vic: 4, xres = 1280, yres = 720, ratio = 16/9, freq = 59.940Hz, vmode = 40960, flag = 2, pclk = 13481 [ 0.549337] mxc_hdmi 20e0000.hdmi_video: vic: 3, xres = 720, yres = 480, ratio = 16/9, freq = 60.0Hz, vmode = 8192, flag = 2, pclk = 37037 [ 0.549347] mxc_hdmi 20e0000.hdmi_video: vic: 3, xres = 720, yres = 480, ratio = 16/9, freq = 59.940Hz, vmode = 40960, flag = 2, pclk = 37074 [ 0.549358] mxc_hdmi 20e0000.hdmi_video: vic: 2, xres = 720, yres = 480, ratio = 4/3, freq = 6 0.0Hz, vmode = 2048, flag = 2, pclk = 37037 [ 0.549369] mxc_hdmi 20e0000.hdmi_video: vic: 2, xres = 720, yres = 480, ratio = 4/3, freq = 5 9.940Hz, vmode = 34816, flag = 2, pclk = 37074 [ 0.549380] mxc_hdmi 20e0000.hdmi_video: vic: 1, xres = 640, yres = 480, ratio = 4/3, freq = 6 0.0Hz, vmode = 2048, flag = 2, pclk = 39722 [ 0.549390] mxc_hdmi 20e0000.hdmi_video: vic: 1, xres = 640, yres = 480, ratio = 4/3, freq = 59.940Hz, vmode = 34816, flag = 2, pclk = 39761 [ 0.549402] mxc_hdmi 20e0000.hdmi_video: vic: 16, xres = 1920, yres = 1080, ratio = 16/9, freq = 60.0Hz, vmode = 8192, flag = 2, pclk = 6734 [ 0.549413] mxc_hdmi 20e0000.hdmi_video: vic: 16, xres = 1920, yres = 1080, ratio = 16/9, freq = 59.940Hz, vmode = 40960, flag = 2, pclk = 6740 [ 0.549424] mxc_hdmi 20e0000.hdmi_video: vic: 4, xres = 1280, yres = 720, ratio = 16/9, freq = 60.0Hz, vmode = 8192, flag = 1, pclk = 13468 [ 0.549434] mxc_hdmi 20e0000.hdmi_video: vic: 4, xres = 1280, yres = 720, ratio = 16/9, freq = 59.940Hz, vmode = 40960, flag = 1, pclk = 13481 [ 0.549444] mxc_hdmi 20e0000.hdmi_video: vic: 4, xres = 1280, yres = 720, ratio = 16/9, freq = 60.0Hz, vmode = 8192, flag = 1, pclk = 13468 [ 0.549483] mxc_hdmi 20e0000.hdmi_video: vic: 4, xres = 1280, yres = 720, ratio = 16/9, freq = 59.940Hz, vmode = 40960, flag = 1, pclk = 13481 [ 0.549495] mxc_hdmi 20e0000.hdmi_video: vic: 3, xres = 720, yres = 480, ratio = 16/9, freq = 59.0Hz, vmode = 8192, flag = 1, pclk = 37037

later: just realised that the same 2015.07-1 on RPi2 notices the 1280x1024p at 60, and uses it (identical monitor)
Derek

6

It seems that the kernel does not detect this video mode at all. @mk01 may have more of an idea about this. Some modes are ignored, because it’s assumed that they will have a matching mode. I think if 1024x768 is a D mode, there should be an S mode too.

Can you upload your edid?

I am willing to guess you didn’t see this issue on RC3.

Sam

7

re uploading edid - how do I accomplish that with a binary file?

re RC3 - this would have been done as an update/upgrade, and I don’t remember it changing my resolution from the 1024x720p (which I had to adopt right from the start). I’m quite happy to do a fresh install with the RC3 if this would help, and you tell me which of the versions in the downloads folder to use.
Derek

8

Can you chuck it on Dropbox or something?

Sam

9

So obvious I didn’t think of it.
Done
Derek

10

Can you send me the link to the Dropbox file?

11

See slack - posted it there

12

@dandnsmith

edid can be exported in nice hex-text form:

find /sys -name edid -exec cat {} +

copy & paste is enough. even you can cut out all the 0x00 after last non zero byte.

13

OK - using it with sudo

0x00 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x00 0x17 0x10 0x74 0x00 0xE9 0xD7 0x01 0x00 0x08 0x16 0x01 0x03 0x80 0x35 0x1D 0x78 0x2A 0x60 0x85 0xA6 0x56 0x4A 0x9C 0x25 0x12 0x50 0x54 0x21 0x08 0x00 0x61 0x40 0x45 0x40 0x81 0xC0 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x64 0x19 0x00 0x40 0x41 0x00 0x26 0x30 0x18 0x88 0x36 0x00 0x30 0xE4 0x10 0x00 0x00 0x00 0x01 0x1D 0x00 0x72 0x51 0xD0 0x1E 0x20 0x6E 0x28 0x55 0x00 0x10 0x09 0x00 0x00 0x00 0x1E 0x00 0x00 0x00 0xFC 0x00 0x48 0x44 0x4D 0x49 0x20 0x74 0x6F 0x20 0x56 0x47 0x41 0x0A 0x20 0x00 0x00 0x00 0xFD 0x00 0x38 0x4C 0x1F 0x53 0x12 0x00 0x0A 0x20 0x20 0x20 0x20 0x20 0x20 0x01 0x60 0x02 0x03 0x18 0x41 0x45 0x84 0x03 0x02 0x01 0x10 0x23 0x09 0x07 0x07 0x83 0x01 0x00 0x00 0x65 0x03 0x0C 0x00 0x10 0x00 0x01 0x1D 0x00 0x72 0x51 0xD0 0x1E 0x20 0x6E 0x28 0x55 0x00 0x10 0x09 0x00 0x00 0x00 0x1E 0x01 0x1D 0x00 0x72 0x51 0xD0 0x1E 0x20 0x6E 0x28 0x55 0x00 0x10 0x09 0x00 0x00 0x00 0x1E 0x8C 0x0A 0xD0 0x8A 0x20 0xE0 0x2D 0x10 0x10 0x3E 0x96 0x00 0x10 0x09 0x00 0x00 0x00 0x18 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x1D

HTH
Derek

14

@dandnsmith

this edid differs from what you shown earlier - DELL monitor. this ~ describes more what your cubox provided. this is it via edidparser from RPI.

HDMI:EDID established timing I/II bytes are 50 54 21
HDMI:EDID found DMT format: code 11, 800x600p @ 75 Hz in established timing I/II
HDMI:EDID found DMT format: code 17, 1024x768p @ 70 Hz in established timing I/II
HDMI:EDID standard timings block x 8: 0x0800 6140 4540 81C0 0101 0101 0A01 0101 
HDMI:EDID unknown standard timing 312x312 @ 60 Hz aspect ratio (1:1)
HDMI:EDID found DMT format: code 16, 1024x768p @ 60 Hz (4:3) in standard timing 1
HDMI:EDID found DMT format: code 9, 800x600p @ 60 Hz (4:3) in standard timing 2
HDMI:EDID found DMT format: code 85, 1280x720p @ 60 Hz (16:9) in standard timing 3
HDMI:EDID unknown standard timing 328x328 @ 61 Hz aspect ratio (1:1)
HDMI:EDID skipping over unknown extension tag 0x20
HDMI:EDID failed to read block 2, parse aborted
HDMI:EDID adding mandatory support for DMT (4) 640x480p @ 60Hz
HDMI:EDID filtering formats with pixel clock > 162 MHz or h. blanking > 1023
HDMI:EDID no known preferred format has been set
HDMI:EDID filtering preferred group has been changed from Invalid to DMT
HDMI:EDID best score mode initialised to DMT (4) 640x480p @ 60 Hz with pixel clock 25 MHz (score 0)
HDMI:EDID best score mode is now DMT (4) 640x480p @ 60 Hz with pixel clock 25 MHz (score 36864)
HDMI:EDID best score mode is now DMT (9) 800x600p @ 60 Hz with pixel clock 40 MHz (score 82600)
HDMI:EDID DMT mode (11) 800x600p @ 75 Hz with pixel clock 49 MHz has a score of 72000
HDMI:EDID best score mode is now DMT (16) 1024x768p @ 60 Hz with pixel clock 65 MHz (score 119370)
HDMI:EDID DMT mode (17) 1024x768p @ 70 Hz with pixel clock 75 MHz has a score of 110100
HDMI:EDID best score mode is now DMT (85) 1280x720p @ 60 Hz with pixel clock 74 MHz (score 135592)
HDMI:EDID preferred mode is updated to DMT (85) 1280x720p @ 60 Hz with pixel clock 74250000 Hz
HDMI:EDID has only DVI support and no audio support
edid_parser exited with code 0
15

Sorry @mk01, I’m lost as to where this is going - I don’t have a cubox
Derek

16

Try putting:

mxc_hdmi.ignore_edid=1 in /boot/uEnv.txt. This will cause it to use ‘standard’ video modes. You should also edit 1920x1080@60 in /boot/uEnv.txt to the desired resolution

Sam

17

Now I’m really confused. I added both those changes, and rebooted - then it said it couldn’t display in the desired mode (video that I had OK before). OK when I reverted the changes - so I’ll think about it, as I’m a bit addled ATM, and experiment further. I won’t post logs until I’ve gone a bit more into it (I might have done something really stupid)
Derek

18

@sam_nazarko
this will hardly add 1280x1024 resolution, right ?

@dandnsmith
perhaps if you attach same monitor as was to RPI, you will get same resolutions as available.
if your monitor doesn’t support 1920x1080, you will NOT force this resolution in boot parameters, would you?

19

@mk01 I have the same monitor attached to the vero as did to the RPi1 when I grabbed that edid (I actually have 2 identical Dell 198FP monitors).
The initial display on booting the vero was readable, but not wholly contained withing the visible screen area, so I overrode the resolution (but I don’t now have a record of initial and changed).
My RPi2, using the 2nd Dell monitor is quite happy on 1280x1024
There is a slight difference in connection detail - both use a HDMI to VGA conversion cable, but that to the Vero passes through a KVM switch so that I can also get to a Win8 PC(which is also quite happy on the higher resolution 1280x1024:60Hz).
Currently the Vero system info shows the screen resolution as 1280x720@60Hz, and it plays mpeg2 videos at 720x576, which was what the modified uEnv.txt gave a problem
Anything I can sensibly add?

Later: I just did the trial I should have done a while back. I swapped the RPi2 into the position the Vero was occupying, and it doesn’t get the same edid results - the 1280x1024 is missing.
Now I need to check the rest of the train to see what stage the stuff goes missing.
I’m afraid I’ve had people on a wild-goose chase.

Still later: I’ve found that the KVM switch seems to be where the problem originates. I seem to recall having had some other confusion when using one of these with a different hardware setup (no RPIs or Vero involved at that time).
Derek

20

@dandnsmith

yes, I sent you the ‘presented’ EDID (by KVM) earlier.
there is not much you can do in such cases (if other hardware is re-forcing invalid data into cable).

but as you confirmed the EDID IS injected AND is wrong, I can release a change to kernel which will allow you to provide previously stored FILE be used as EDID.
(I just wasn’t sure it’s working properly - obviously data are BAD - but you was confirming it is the same. but no problem anymore, we cleared it up and I will release the code).

what you will do - you will connect the monitor directly, boot, grab EDID into file and then you use it on any attach / configuration you will use, always this file will be used.
there is no other way to fight against such HW.