On 10/04/17 10:30, Gene Heskett wrote:
On Monday 10 April 2017 04:55:39 Mark Morgan Lloyd wrote:On 10/04/17 02:30, Alan Corey wrote:I think you can add entries to /etc/fb.modes but it's like making old-style modelines, it takes lots of information. And my old buddy xvidtune doesn't work on a Pi. But you're a tv guy.Video modes have been causing me a great deal of pain over the last few weeks. I could say much more but will keep it short with just two comments to start with: * Look at what's in your X log file and at /sys/class/graphics/fb0/modes (should apply to most systems that use standard video).pi@raspberrypi:~/linuxcnc $ cat /sys/class/graphics/fb0/modes U:1366x768p-0 pi@raspberrypi:~/linuxcnc $ From the log: [ 12.657] (WW) Falling back to old probe method for modesetting [ 12.657] (EE) open /dev/dri/card0: No such file or directory [ 12.657] (WW) Falling back to old probe method for fbdev -- [ 12.780] (II) AIGLX: Screen 0 is not DRI2 capable [ 12.780] (EE) AIGLX: reverting to software rendering [ 14.243] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer How can these be fixed? The video's update rate sux.
You'll need to check with somebody who knows the specific RPi/Raspbian situation. I suspect it will require non-free drivers... and that's non-free as in beer as well as speech.
* Use tvservice to get EDID info from your screen and feed it to edid-decode (systems other than RPi will have some different means of getting the binary EDID block, e.g. an Odroid uses a modified U-Boot). It's obviously important though to distinguish between resolution/sync configuration and the colour depth, the latter being largely determined by available memory.And 128 megs is not enough for 32 bit apparently. It (24 bit) also slows rendering speed noticably.
Stop flailing around and get the EDID info to see what refresh rate the screen will offer for any given resolution. Then start off at 16 bits, try to get that working, and then try 24.
The best I can get at 3840x2160 (?) is 24 fps from an RPi3. 16 bit video is OK, 24-bits is marginal (I suspect a problem with mouse pointer etc. code), 32 bits has a major impact on system stability (i.e. length of time it will run before it's using swap). HDMI is designed around a 24-bit data stream and I don't know to what extent trying to use 32 confers any advantage, and there's some unpleasant maximum pixel rates etc. to contend with. In principle it should be possible to tune the RPi modeline to emit sync rates etc. that don't exceed the limitations of the clock rate, in practice we've had no success with that yet but I'm still to start playing with full modelines... note that modeline format is not the classic XFree86 one.
In practical terms the video capabilities of an Odroid C2 are substantially better, even if their Ubuntu-derived UI sucks and they've got package dependency problems. I don't know to what extent that indicates an inherent superiority of the Odroid's Mali graphics subsystem over the RPi's Broadcom one, or whether it's fair to say that the developer community understands Mali better that Broadcom, or if it's just me drawing some wrong conclusions.
The driving force at this end is a colleague with sight problems who can only handle a spreadsheet etc. with a large fount and screen. Since very often I'm in the position of trying to set up his computer remotely when he's plugged it into an HDMI TV I've never seen I'm not exactly enjoying the experience.
-- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]