Console Mode/Framebuffer Settings?

I just got my TX1, and tried to boot only to find no video like many other people. I won’t have a serial console setup for about a week, but was able to configure DHCP and log in to the TX1 via ssh. From here I discovered that the TX1 is up and running just fine in text mode (probably not even intended to go to GUI until the NVIDIA-INSTALLER/ is run). What I’m finding about failure of the monitor is getting interesting.

Specifically, I see a kernel command line option “video=tegrafb”. This did not exist in TK1, and I’m thinking perhaps this is about local console settings prior to going into graphical mode. This may possibly change what monitor scan rate and resolution is while showing text-login via direct monitor attachment prior to reaching graphical mode. Is there some control over this local monitor text mode via tegrafb?

As it turns out, the reason why the console won’t work in this text-only stage which should work is because TX1 is attempting to set video modes out of range of the monitor. This monitor works great on TK1 and previous x86 computers I’ve used it with before, so something about this framebuffer is failing to stay within range of the monitor’s capabilities.

I installed various EDID query packages, and discovered the TX1 is completely unable to read any EDID information:

root@tegra-ubuntu:~# get-edid 
This is read-edid version 3.0.1. Prepare for some fun.
Attempting to use i2c interface
No EDID on bus 0
No EDID on bus 1
No EDID on bus 3
No EDID on bus 4
No EDID on bus 5
No EDID on bus 6
1 potential busses found: 2
Bus 2 doesn't really have an EDID...
Couldn't find an accessible EDID on this computer.
I'm sorry nothing was successful. Maybe try some other arguments
if you played with them, or send an email to Matthew Kern <>.

On the TK1 this information is available, although there is a claim that some of it isn’t understood. Still, the EDID is there and attached and responding…TX1 thinks EDID is not there at all. Here is what this ViewSonic monitor shows up as when connected to any other computer (this sample from TK1 R21.4 via “get-edid | edid-decode”):

Extracted contents:
header:          00 ff ff ff ff ff ff 00
serial number:   5a 63 1e 59 01 01 01 01 1c 11
version:         01 03
basic params:    80 2f 1e 78 2e
chroma info:     d0 05 a3 55 49 9a 27 13 50 54
established:     bf ef 80
standard:        b3 00 a9 40 95 00 90 40 81 80 81 40 71 4f 31 0a
descriptor 1:    21 39 90 30 62 1a 27 40 68 b0 36 00 da 28 11 00 00 1c
descriptor 2:    00 00 00 ff 00 51 41 35 30 37 32 38 35 32 39 30 34 0a
descriptor 3:    00 00 00 fd 00 32 4b 1e 52 0f 00 0a 20 20 20 20 20 20
descriptor 4:    00 00 00 fc 00 56 58 32 32 33 35 77 6d 0a 20 20 20 20
extensions:      00
checksum:        ea

Manufacturer: VSC Model 591e Serial Number 16843009
Made week 28 of 2007
EDID version: 1.3
Digital display
Maximum image size: 47 cm x 30 cm
Gamma: 2.20
DPMS levels: Off
Supported color formats: RGB 4:4:4, YCrCb 4:2:2
Default (sRGB) color space is primary color space
First detailed timing is preferred timing
Established timings supported:
Standard timings supported:
Detailed mode: Clock 146.250 MHz, 474 mm x 296 mm
               1680 1784 1960 2240 hborder 0
               1050 1053 1059 1089 vborder 0
               -hsync +vsync
Serial number: QA5072852904
Monitor ranges: 50-75HZ vertical, 30-82kHz horizontal, max dotclock 150MHz
Monitor name: VX2235wm
    Checksum: 0xea

Unknown extension block

Via “get-edid | parse-edid” (also TK1 R21.4):

Section "Monitor"
        Identifier "VX2235wm"
        ModelName "VX2235wm"
        VendorName "VSC"
        # Monitor Manufactured week 28 of 2007
        # EDID version 1.3
        # Digital Display
        DisplaySize 470 300
        Gamma 2.20
        Option "DPMS" "true"
        Horizsync 30-82
        VertRefresh 50-75
        # Maximum pixel clock is 150MHz
        #Not giving standard mode: 1680x1050, 60Hz
        #Not giving standard mode: 1600x1200, 60Hz
        #Not giving standard mode: 1440x900, 60Hz
        #Not giving standard mode: 1400x1050, 60Hz
        #Not giving standard mode: 1280x1024, 60Hz
        #Not giving standard mode: 1280x960, 60Hz
        #Not giving standard mode: 1152x864, 75Hz
        #Not giving standard mode: 640x400, 70Hz
        Modeline        "Mode 0" 146.25 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync 

At one point there is a note about an unknown extension from the ViewSonic’s response, but extensions were intended to be ignored if not understood, so this should not cause reading EDID to completely disappear. It appears that text-mode may be hampered in setting up correctly for lack of EDID data, but I’m unsure of this because I don’t know how tegra framebuffer would normally set up prior to reaching the X11 server.

For a very long time there have been various standard timings to support in case no automatic setup succeeds. This particular monitor supports all of those lower resolution “safe standard settings”, and so even if EDID data is missing or broken, text mode direct monitor connect should be working prior to reaching GUI runlevel.

The whole process of the early days of supporting a DDC channel for monitor query had to be expanded for new hardware, which resulted in EDID. Now EDID has to expand to support the ultra-high-def hardware, and so I have no doubt TX1 monitor query and setup has also had to expand to take advantage of newer hardware. Unfortunately, it seems the text-mode is missing setup. How and where is direct monitor text-mode resolution and scan rate determined on TX1? Does text-mode early boot depend on EDID data?

Just an update on the TX1 information. After running the NVIDIA-INSALLER/ X11 boots correctly; also, after this going to a text console (e.g., ctrl-alt-F2) the console runs correctly and is in range of the monitor’s capabilities.

The “get-edid” command now finds data. However, piping through parse-edid shows nothing, while piping through edid-decode works (edid-decode has data, although it isn’t entirely happy with the data). Apparently with the NVIDIA-INSTALLER software in place standard non-GUI console works and EDID information now exists, but EDID information is of a format which can’t be used in X11 configuration according to command line utilities. The odd thing is that if X11 runs correctly (which it does), then the EDID had no choice but to give a valid EDID response which X11 understands…the command line utilities are wrong.

xrandr DOES now work and is likely the method by which otherwise seemingly non-functional EDID data becomes useful…which kind of proves the EDID is both there and formatted correctly, but some other stage of reading monitor data going to some different consumer of EDID data is corrupt or incorrect. It wouldn’t be unusual that some consumer of data needs to be adjusted for switching from 32-bit to 64-bit. Here’s the now-functional-but-previously-non-functional xrandr output:

Screen 0: minimum 8 x 8, current 1680 x 1050, maximum 16384 x 16384
HDMI-0 connected primary 1680x1050+0+0 (normal left inverted right x axis y axis) 470mm x 300mm
   1680x1050      60.0*+
   1600x1200      60.0  
   1440x900       59.9  
   1400x1050      60.0  
   1280x1024      75.0     60.0  
   1280x960       60.0  
   1152x864       75.0  
   1024x768       75.0     70.1     60.0  
   832x624        75.0  
   800x600        75.0     72.2     60.3     56.3  
   720x400        70.0  
   640x480        75.0     72.8     67.1     60.0  
   640x400        70.0