It's a bit like Terminus, but more rounded and less harsh on the eyes. Ubuntu has shipped
it as their default console font for years, before they switched to the "Ubuntu" font. Putting
this in the kernel has practically no benefit except to reduce the amount of "glitching"
swapping the built-in kernel console font for a new one halfway through boot when you see the
kernel output on a screen.
Note to gain the benefit of it not swapping the font around again when "consolefont" or
similar service starts, you need to set your font to Uni3-Fixed16.psf.gz or something very
similar.
If the internal clock is deadly accurate for the desired mode, that will be used instead
(the accuracy is set to within 1/200th which is well within VESA standards of 1/50th) to
save power.
efikamx changes: for HDMI, try external clock when necessary. For LVDS, don't since there
is some weird clock mess with the binary blob for the LCD panels in the mtl017 driver
which we think is derived from the lack of external clock support in more ancient kernels.
It is fudging the values to both correct some kind of panel EDID bug and also to fix the
potential deviation in clock, but since it's a binary blob it's kind of hard to change.
Since there isn't a noticable effect on display compatibility in higher values, we may as well not waste time idling for something that already has taken effect.
Net benefit of this is that DVI monitors, due to not requiring an InfoFrame drain time, now change resolution much, much faster than HDMI monitors (which may now take about 50ms longer, but this isn't noticable in benchmarks)
* siihdmi.dvi=1 switch for kernel command line (and sysfs) which will force an HDMI display into DVI sink mode (will disable audio!)
* EDID handling reworked to better match the operational mode described in the manual, and to streamline the DDC bus locking (it will now lock the bus once instead of twice, and get all EDID data while the lock is held instead of trying twice once it realises there is an extension
* more consistently set the DVI/HDMI operational mode every type the System Control register is touched
* set Power Control to "D0" after setting the DVI/HDMI operational mode as a 0x00 write here seems to help latch the previous register set
* misc: renumber "steps" to enable display to match the manual
* only delay for InfoFrame drain time if it's an HDMI sink (DVI sinks do not get sent InfoFrames so there is nothing to drain)
* add a "resolution stabilization" delay (currently 255ms, manual states 50-500ms) in case the IPU is not sending data yet (will be ratcheted down later to make resolution changing faster)
HDMI compatibility has improved somewhat (no more pink lines) and as far as tested with all the test monitors, no breakages have occurred.
Monitor resolution change time has increased due to the stabilization delay, which may not actually be necessary as by the time we have gotten to this point to change resolution it could be assumed the notification through the Linux framebuffer subsystem is more than long enough. Your mileage may vary.
* do not power down the chip just because the monitor is still in standby and waking up
* EDID will be requested but if the monitor has not properly powered yet then it will give a default mode
* also fix the symlink error (try remove device vs. make new phys-link, both are phys-link now, so it will remove the phys-link attribute before recreating it)
Essentially where before we simply picked a 1080p or 720p mode and then fall back to
EDID preferred mode, now we basically do
if (teneighty)
if (native is 1680x1050, 1440x900) return native
if (1080p) return 1080p
if (seventwenty)
if (native is 1366x768, 1360x768, 1280x768, 1280x800, 1024x768) return native
if (720p) return 720p
fallback: use preferred mode
This means far more "close to 720p" modes for plasmas are used instead of 720p with
a scaler, and for monitors that SAY they can do 1080p (but it's actually scaled down
or overscanned because native res is smaller) then use panel native instead for a
much better experience.
Tested on every monitor we have available and matches native res on most, and the
best mode fallback is used as per previous mode selection on the few fringe cases
left. Experience is crisper displays.
Note that if teneighty is selected, the modes returned absolutely will suck at video
playback performance - mfw_v4lsink will fail to fullscreen at anything above 1366x768
due to lack of bandwidth. 1440x900 may work if you're lucky. mfw_xvimagesink simply
cannot convert YV12 to YUY2 fast enough to work (and double buffering seems broken).
It is therefore still disabled by default.
Also: add a siihdmi.vic= option, so you can give it any CEA VIC from the CEA spec
(look for an entry in drivers/video/cea861_modes.c and use that number) if it's
still in the modelist.
Requesting specific video modes requires some duplication of option parsing and I
feel that's really not going to give people a reasonable experience, so it's not
being done right now. Investigation into exactly what the mitigating factor for
a lower_margin < 2 actually working is underway so we can cull less modes and give
people much better monitor experience once we get XRandR working.
8MB on Smartbook, 32MB on Smarttop. Dynamically allocating the framebuffer for 1920x1080-32 didn't work with the
dynamic method anyway (sigh) due to memory fragmentation.
Also, align framebuffer stride to 32 bytes to fix Z430 acceleration in X
siihdmi: don't reconfigure the SII9022 just because there was a mode change if the mode is identical
ipuv3fb: default to a real 640x480 mode and not a "dummy" xres/yres
modedb: move cea modes to an extern so it only gets included once in the kernel
also: whitespace police
If you disable display, the display port's pin may keep high voltage which
may cause power leakage. Fix this issue by make all pin go into low level
after display disable.
Signed-off-by: Jason Chen <b02280@freescale.com>
(cherry picked from commit 165df9e8d525082e70a165516e2bcd1d0529b148)
FlashPlayer 11.05 BSP has been fixed to support 32-bit modes so it will function
correctly on Smarttop now. GPU performance hit is still noticable but the extra
colour definition more than makes up for it. Smartbook is not affected.
This reverts commit 1ce3ee7a5a.
* 720p and 1080p are now attempted on DVI monitors on the revelation that some DVI monitors can display real CEA-style modes
* use the fb_find_best_nearest_mode function to better select resolutions and refresh rates
* cleanups
