Re: [ARMini-support] 4k is here, and very usable

  • From: A Rawnsley <rcomp@xxxxxxxxxxx>
  • To: <armini-support@xxxxxxxxxxxxx>
  • Date: Thu, 20 Aug 2015 16:51:39 +0100


I started by connecting it directly to the ARMX6. TV said "No
signal". Changed back to monitor and switched from 2048x1152 to
1080p mode. Now it did work, although the screen wasn't centered.

Changed to 4k but the TV did not manage to display anything, again
a "no signal".

My question now is this: It seems to me my TV is quite picky on
what it wants to accept. 1080p works, but strangely it is not
centered (I thought that was a CRT-thing). So are the modes in the
monitorfile made in such a way that they adhire to the standard
(assuming there is one)? Or are they just made in a way that
"seems to work on most monitors" (but not my TV)?

By and large, the mode def files we generate use VESA timings, but
often tweaked to ensure compatibility with as many devices as we can
test. There are, unfortunately, different implementations of the VESA
standards, which can't be easily made accessible via the RISC OS UI.
For example, there are so-called "reduced blanking" modes, which
massively reduce the "wait times" on the mode timings, and in turn
reduce bandwidth. Most monitors prefer this, but some *may* work
better with longer blanking.

Initially, I tried to use longer blanking with ARMX6 because we had
more video bandwidth to play with, but I found that it was a double
edged sword, and most test monitors seemed to like the lower bandwidth
reduced blank modes.

HINT: It is worth commenting that the MDF contains a number of refresh
rates for high resolution modes. Some of these use different
calculation methods, with the goal that different refresh rates may
work better with some monitors.

By way of example, one of our testers has a DGM 27" 2560x1440 screen.
At 1080p, it worked best with the 56hz MDF mode, and at 2560x1440 the
55hz one works best (actual numbers may not be accurate). This is a
very fussy, very cheap korean IPS 2.5k panel, but gives good picture
when it works. As such, *do* experiment!

At 4k, full (ie. no reduced blanking) bandwidth would exceed what we
can do on i.MX6, so we have to use reduced blanking, but it falls in
line with 4k standard definitions that I've seen for Linux online. I
should, however, stress that I've only tested on one 4k monitor, due
to funds!


TVs can be a bit funny generally. Often they will only do 720p, 1080p
and so on. They *may* only accept very specific timings. I have an
issue with my Pana Plasma whereby it is correctly positioned when
wired to my ARMX6 directly, but shifted if connected via Pioneer
amp/receiver.


This build of ARMX6 OS will allow you to read monitor specs via EDID.
To do this press F12 and do a *Help ScreenModes. It'll tell you the
*command needed to read EDID to an MDF. I think it is something like
*CreateModeFile SCSI::4.$

It'll write the EDID/MDF to a file with the device's name in the
folder specified.


You'd think this would be the magic bullet needed for any monitor or
device, but I've not found this to be so. Indeed, with the DGM
mentioned above, even using EDID info doesn't seem to result in
happiness, yet the (55hz) mode I mentioned produces a lovely picture.

However, it *may* help get a bit of a handle on your TV.


One last thing - you mention KVM... the sooner you can move away from
KVMs the better. I've had several people with issues related to KVMs
(esp old KVMs) in the last few weeks, and loathe them now even more
than I already did. Screens have multiple inputs for a reason, and
unless you're prepared to regularly drop 100ukp+ on a decent new KVM,
I'd strongly advise trying to stop relying on them. I even lost a
sale of some ARMX6s because they weren't compatible with a 1990s
VGA/PS2 KVM! Sorry to rant.

Kind wishes,

Andrew

--
R-Comp
22 Robert Moffat, High Legh, Knutsford, Cheshire WA16 6PS
Tel: 01925 755043 Fax: 01925 757377 http://www.rcomp.co.uk
---
To alter your preferences or leave the group,
visit //www.freelists.org/list/armini-support
List-related queries to info@xxxxxxxxxxxx

Other related posts: