1080p Kernel for broken EDID Screens

[C_Peine]

Please find my first Kernel for the X7:

kernel2.img.zip

It enables 1080p for all Screens that do not get detected correctly. (i.e you only get 720p even with a 1080p Kernel)

I didnt do much testing so far but 1080p works on both of my Screens(both did not with all sorts of different 1080p kernels)
I use the Finless 1.6 Rom, video playback with the Stock Player seems to work fine in 1080p, ethernet, blutooth , wifi etc. are all working.

So if you are not lucky with other 1080p kernels on your screen give it a try!

Cheers, Chris

PS: i added a mode 1080p 48Hz, if you experience a noisy screen give it a try.

[C_Peine]

I used phjanderson's kernel source: http://www.freaktab.com/showthread.p...r-X7-available

First I thought this would be the Fix: http://hwswbits.blogspot.de/2013/03/...lution-in.html

but...

dmesg still told me "warning: no CEA video mode parsed from EDID"
which i found in hdmi-lcdc.c:

int hdmi_ouputmode_select(struct hdmi *hdmi, int edid_ok)

Basically the EDID parser does not return a single valid mode.
If that happens Standard modes are activated, based on some calculations.

I commented the section out that checks those modes against edid spec calculations...

for(i = 0; i < ARRAY_SIZE(hdmi_mode); i++) {
            mode = (struct fb_videomode *)&(hdmi_mode[i].mode);
        /*    if(modedb) {
                if( (mode->pixclock < specs->dclkmin) || 
                    (mode->pixclock > specs->dclkmax) || 
                    (mode->refresh < specs->vfmin) ||
                    (mode->refresh > specs->vfmax) ||
                    (mode->xres > modedb->xres) ||
                    (mode->yres > modedb->yres) )
                continue;
            }*/
            hdmi_add_videomode(mode, head);
        }

Now all Modes Listed in

static const struct hdmi_video_timing hdmi_mode []

will be used.

Because i had noise issues with one of my Screens i added the following mode with a reduced clocking.

    { {    "1920x1080p@48Hz",    48,            1920,    1080,    125000000,    148,    88,        36,        4,        44,        5,        FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,            0,        0    },    21,      1,        OUT_P888    },

Cheers, Chris

[walter]

I used phjanderson's kernel source: http://www.freaktab.com/showthread.p...r-X7-available

First I thought this would be the Fix: http://hwswbits.blogspot.de/2013/03/...lution-in.html

but...

dmesg still told me "warning: no CEA video mode parsed from EDID"
which i found in hdmi-lcdc.c:

int hdmi_ouputmode_select(struct hdmi *hdmi, int edid_ok)

Basically the EDID parser does not return a single valid mode.
If that happens Standard modes are activated, based on some calculations.

I commented the section out that checks those modes against edid spec calculations...

for(i = 0; i < ARRAY_SIZE(hdmi_mode); i++) {
            mode = (struct fb_videomode *)&(hdmi_mode[i].mode);
        /*    if(modedb) {
                if( (mode->pixclock < specs->dclkmin) || 
                    (mode->pixclock > specs->dclkmax) || 
                    (mode->refresh < specs->vfmin) ||
                    (mode->refresh > specs->vfmax) ||
                    (mode->xres > modedb->xres) ||
                    (mode->yres > modedb->yres) )
                continue;
            }*/
            hdmi_add_videomode(mode, head);
        }

Now all Modes Listed in

static const struct hdmi_video_timing hdmi_mode []

will be used.

Because i had noise issues with one of my Screens i added the following mode with a reduced clocking.

    { {    "1920x1080p@48Hz",    48,            1920,    1080,    125000000,    148,    88,        36,        4,        44,        5,        FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,            0,        0    },    21,      1,        OUT_P888    },

Cheers, Chris

Thank you!

I have been digging at this problem for a while and put it aside to work on other things. I have noticed that different source trees manipulate pixclock differently (dividing it, not dividing it, etc.) in the same places, I suspect this is where the issue lies (timing calcs). I have two displays that show this issue, and they both work fine with an MK808b (I tested one clone, one original, both work). I haven't found ANY rk3188 kernels that will show 1080p on these displays without dirty hacks to force modes, and when I had enabled debug I got the same 'No CEA modes found..' output and they default to 720p.

At the same time I wonder, why, if the display reports a detailed timing mode...the driver never appears to use/consider it? Both of these displays list a detailed timing description for 1080p. EDID 1.3

I think I still have the edid debug output if it helps you. I don't have direct access to these displays at the moment, but I will test this fix as soon as I get a chance.

Thanks again for the work!

[C_Peine]

I looked further today and found the problem in:

hdmi-lcdc.c:

modedb = &specs->modedb[0]; 
for (i = 0; i < specs->modedb_len; i++) { 
  if(specs->modedb[i].xres > modedb->xres) 
    modedb = &specs->modedb[i]; 
  else if(specs->modedb[i].yres > modedb->yres) 
    modedb = &specs->modedb[i];

This loop is supposed to find the mode with the highest resolution in the screens edid modelist

however my modelist (and probably yours too) looks like:

1920x1080
...
...
1600x1200
1680x1050

and i end up with the 1680x1050
you go figure...

my patch that should resolve this:

    modedb = &specs->modedb[0];
             for (i = 0; i < specs->modedb_len; i++) {
-                if(specs->modedb[i].xres > modedb->xres)
-                    modedb = &specs->modedb[i];
-                else if(specs->modedb[i].yres > modedb->yres)
+                if(specs->modedb[i].xres*specs->modedb[i].yres > modedb->xres*modedb->yres)
                     modedb = &specs->modedb[i];
             }

i did update the Kernel.img in my first post.

Cheers!

Chris

rockchip_edid.zip

[gen2thomas]

Eventually this bugfix could help for some problematic EDID's.

https://www.miniand.com/forums/forums/picuntu-linux/topics/how-to-change-the-resolution?page=2

[walter]

    modedb = &specs->modedb[0];
             for (i = 0; i < specs->modedb_len; i++) {
-                if(specs->modedb[i].xres > modedb->xres)
-                    modedb = &specs->modedb[i];
-                else if(specs->modedb[i].yres > modedb->yres)
+                if(specs->modedb[i].xres*specs->modedb[i].yres > modedb->xres*modedb->yres)
                     modedb = &specs->modedb[i];
             }

I tested this patch on an ELO 2400L 42" 1080p touchscreen, still no 1080p.

I'm going to try your original fix and gen2thomas's patch next...

[walter]

I tested this patch on an ELO 2400L 42" 1080p touchscreen, still no 1080p.

I'm going to try your original fix and gen2thomas's patch next...

I tried again with the original patch (commenting out the block), but no 1080p. I then tried gen2thomas's patch and... 1080p! For the first time I have full 1080p on this monitor and all of the others that I have tried, including a Planar 23" touchscreen that worked on some kernels but not others.

It may be in the end that both patches are the route to go, but for now this solves my problem

Thanks!

[C_Peine]

when trying my Patch did u also apply this patch?

http://hwswbits.blogspot.de/2013/03/bugfix-for-wrong-monitor-resolution-in.html

i think in order to work properly you need them both.

On the other hand i dont see no real harm in overriding all modes and using defaults, as most screens will support 1080p anyway.

Cheers!

[gen2thomas]

Improved kernel debugging now possible for resolution problems

I tried again with the original patch (commenting out the block), but no 1080p. I then tried gen2thomas's patch and... 1080p! For the first time I have full 1080p on this monitor and all of the others that I have tried, including a Planar 23" touchscreen that worked on some kernels but not others.

Thank you for testing the patch.

Now I have added this patch and also some improvements for debugging to my fork of aloksinha2001 git repo:

https://github.com/gen2thomas/Linux3188_CloudnetGoCR9

In case you switch on some debugging (using the configuration file) you will get the complete basic and extended EDID blocks of your monitor. Reading/posting this blocks is a good idea for further investigation of resolution problems.

[gen2thomas]

Looking for biggest Resolution

I looked further today and found the problem in:

hdmi-lcdc.c:

modedb = &specs->modedb[0]; 
for (i = 0; i < specs->modedb_len; i++) { 
  if(specs->modedb[i].xres > modedb->xres) 
    modedb = &specs->modedb[i]; 
  else if(specs->modedb[i].yres > modedb->yres) 
    modedb = &specs->modedb[i];

This loop is supposed to find the mode with the highest resolution in the screens edid modelist

The code above only work for an sorted list. The sort must be first by "xres" than by "yres". This seems to be wrong in your case.

But using the ratio seems to be also an good way:
1600x1200 --> 1,33 => 4:3
1680x945 --> 1,78 => 16:9 (theoretically, not in your list)
1680x1050 --> 1,6 => 16:10
1920x1080 --> 1,78 => 16:9

To make the right decision we need the "height" and "width" of the "fb_var_screeninfo" structure OR "max_x" and "max_y" of "fb_monspecs" structure OR at least the ratio. I will make an patch for that idea and push it to my git repository in the next days.

[walter]

when trying my Patch did u also apply this patch?

http://hwswbits.blogspot.de/2013/03/bugfix-for-wrong-monitor-resolution-in.html

i think in order to work properly you need them both.

On the other hand i dont see no real harm in overriding all modes and using defaults, as most screens will support 1080p anyway.

Cheers!

I just looked and that patch doesn't seem to be in the Rockchip-3.0 repo I used. I tested the patch from your link on some of the other kernel repos with no success, but I didn't try that patch and the one you posted in this thread together. When I get time/access to another one of these displays (should be soon) I will test again.

[gen2thomas]

Patch for "Find Best Mode"

The code above only work for an sorted list.
...
I will make an patch for that idea and push it to my git repository in the next days.

Now I have make a patch for that wrong find algorithm and pushed it to the repo. The patch can be activated inside the .config file by switch CONFIG_EDID_FINDBESTMODE_GEN2THOMAS_FIX = y

https://github.com/gen2thomas/Linux3188_CloudnetGoCR9

Description:
There are nine cases to looking for the best mode with using of "x_res" and "y_res". In the cases below "x_new" means the new "x_res", "x_old" means the "x_res" of the actual found best mode, same for "y".

case 1: (x_new > x_old)
1a: (y_new > y_old) --> for sure it is a BETTER mode!
1b: (y_new = y_old) --> for sure it is a BETTER mode!
1c: (y_new < y_old) --> it is only an better mode in case of the RATIO match better than actual mode does

case 2: (x_new = x_old)
2a: (y_new > y_old) --> for sure it is a BETTER mode!
2b: (y_new = y_old) --> same resolution, but take it only in case of an better (higher) FREQUENCY
2c: (y_new < y_old) --> never an better mode

case 3: (x_new < x_old)
3a: (y_new > y_old) --> it is only an better mode in case of the RATIO match better than actual mode does
3b: (y_new = y_old) --> never an better mode
3c: (y_new < y_old) --> never an better mode

[adam770]

rikomagic mk802 IV in 1280x800 possible,

Dear all,

Can someone help me, if its possible to attach a rikomagic android stick to a chalk-elec display, which can handle only 1280x800 ?
I am a begginner android user,and cannot manipulate kernel, ect only give commands from commandpromt as root.

I recently bought a 10" screen with hdmi-lvds connector.it have no picture.
I tested it on several settop boxes, dvr-s, other hdmi devices but worked only on amd radeon HD6870 hdmi port.
I need it as a android-car-pc, powered my rikomagic mk802 IV stick with rootted 4.22 android.
(i am able to give commands as root from android terminal, but i cant modify files in system directory)