• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root [Boost Mobile] CWM touch

Status
Not open for further replies.
i would suggest saving for an external hard drive of your own i know you can buy 1 trilobyte for around $200 maybe cheaper depending where you buy it :D
 
well its been a while since i posted here, but here are some updates. I think I figured out what is up with my recovery. The board has flipped screen code works fine, BUT, just below that code there is an issue:

Code: 
    { 
    memcpy(gr_framebuffer[gr_active_fb].data, gr_mem_surface.data,
           vi.xres_virtual * vi.yres * PIXEL_SIZE);
    }

this line of code in the stock twrp minui graphics.c is missing a way to change the 16 bit framebuffer to 32 bit. I tried to figure out a fix with this bit of code...:

Code: 
  [COLOR=Red]if[/COLOR]( vi.bits_per_pixel ==[COLOR=Magenta] 32[/COLOR])
    {
        gr_flip_32(([COLOR=SeaGreen]unsigned[/COLOR] *)gr_framebuffer[gr_active_fb].data, \
                  ([COLOR=SeaGreen]unsigned short[/COLOR] *)gr_mem_surface.data, \
                   (vi.xres_virtual * vi.yres); 
    }
    [COLOR=Red]else[/COLOR]
    { 
    memcpy(gr_framebuffer[gr_active_fb].data, gr_mem_surface.data,
           vi.xres_virtual * vi.yres * PIXEL_SIZE);
    }

then adding this above void gr_flip(void); :

Code: 
[COLOR=SeaGreen]void [/COLOR]gr_flip_32([COLOR=SeaGreen]unsigned[/COLOR] *bits, [COLOR=SeaGreen]unsigned short[/COLOR] *ptr, [COLOR=SeaGreen]unsigned[/COLOR] count)
{
   [COLOR=SeaGreen]unsigned[/COLOR] i=0;
   [COLOR=Red]while[/COLOR] (i<count) {
        [COLOR=SeaGreen]uint32_t[/COLOR] rgb32, red, green, blue, alpha;

        [COLOR=RoyalBlue]/* convert 16 bits to 32 bits */[/COLOR]
        rgb32 = ((ptr[i] >> [COLOR=Magenta]11[/COLOR]) & [COLOR=Magenta]0x1F[/COLOR]);
        red = (rgb32 << [COLOR=Magenta]3[/COLOR]) | (rgb32 >> [COLOR=Magenta]2[/COLOR]);
        rgb32 = ((ptr[i] >> [COLOR=Magenta]5[/COLOR]) & [COLOR=Magenta]0x3F[/COLOR]);
        green = (rgb32 << [COLOR=Magenta]2[/COLOR]) | (rgb32 >> [COLOR=Magenta]4[/COLOR]);
        rgb32 = ((ptr[i]) & [COLOR=Magenta]0x1F[/COLOR]);
        blue = (rgb32 << [COLOR=Magenta]3[/COLOR]) | (rgb32 >> [COLOR=Magenta]2[/COLOR]);
        alpha = [COLOR=Magenta]0xff[/COLOR];
        rgb32 = (alpha << [COLOR=Magenta]24[/COLOR]) | (blue << [COLOR=Magenta]16[/COLOR])
        | (green << [COLOR=Magenta]8[/COLOR]) | (red);
        android_memset32(([COLOR=SeaGreen]uint32_t[/COLOR] *)bits, rgb32, [COLOR=Magenta]4[/COLOR]);
        i++;
        bits++;
    }
}

What this code does is loops, converting each pixel and color to 32 bit. my issue is getting it to work, because when I use this piece of code, the graphics still look like they did before adding this code. half of the screen is right side up, and the other half is upside down, it's basically only working for half of the pixels. which is tearing me up.. cant figure out whats wrong.....
 
QuietStorm1785 said:
...What this code does is loops, converting each pixel and color to 32 bit. my issue is getting it to work, because when I use this piece of code, the graphics still look like they did before adding this code. half of the screen is right side up, and the other half is upside down, it's basically only working for half of the pixels. which is tearing me up.. cant figure out whats wrong.....
Click to expand...

I haven't studied your source, but I'm assuming to do the loop through the pixels, you set up some sort of nested loop:

Code: 
for x = 0 to 479
   for y = 0 to 799
     'do stuff here
 next
next

and if this is the case, did you make sure the x and y numbers are right? Maybe you swapped x for y and the logic is only processing half (480) of the phones 800 lines... just a thought, based on a mistake I've done countless times lol

And yes, I know... shame on me for using BASIC for my illustration :rolleyes:


Edit: Okay, after reviewing the post, it looks like you're converting pixels linearly, which means the variable i should start at 0 and proceed upward to count which should be set to 383,999 in order to account for every pixel on the screen. I realize this may be a dumb suggestion, but maybe count isn't set to the proper number?
 
QuietStorm1785 said:
I was thinking the same thing, altho I really dont know if vi.xres_virtual * vi.yres would equal the exact number of pixels. Ima edit some more and see, but if u want to study my source, I posted it on my github a couple days ago...:

https://github.com/QuietStorm1785/zte_warp_twrp_configs

the file twrpgraphics.c will be in the recovery folder and thats the graphics source code for twrp.
Click to expand...

I'll take a look and see if I can make anything of it. What development environment do you use?
 
Ugh... now I remember why I hate C :p Okay, so I'm not sure where the code is messing up, but maybe you could do something like this:

Code: 
void gr_flip_32(unsigned *bits, unsigned short *ptr, unsigned count)
{
    printf("count = %i\n", count);
    unsigned i=0;
    while (i<count) {
        uint32_t rgb32, red, green, blue, alpha;

        /* convert 16 bits to 32 bits */
        rgb32 = ((ptr[i] >> 11) & 0x1F);
        red = (rgb32 << 3) | (rgb32 >> 2);
        rgb32 = ((ptr[i] >> 5) & 0x3F);
        green = (rgb32 << 2) | (rgb32 >> 4);
        rgb32 = ((ptr[i]) & 0x1F);
        blue = (rgb32 << 3) | (rgb32 >> 2);
        alpha = 0xff;
        rgb32 = (alpha << 24) | (blue << 16) | (green << 8) | (red);
        android_memset32((uint32_t *)bits, rgb32, 4);
        i++;
        bits++;
    }
}

Basically all I did was add the printf line near the top to actually show the variable's contents as the code executed. A kind of poor-man's watchpoint, if you will. Then you can see if count is the proper value.
 
hroark13 said:
I had to compile a new kernel for this

kernel config needs

CONFIG_FB_MSM_DEFAULT_DEPTH_RGB565=y
# CONFIG_FB_MSM_DEFAULT_DEPTH_ARGB8888 is not set
# CONFIG_FB_MSM_DEFAULT_DEPTH_RGBA8888 is not set


and the board config for twrp needs

#TARGET_RECOVERY_PIXEL_FORMAT := "BGRA_8888"
#TARGET_RECOVERY_PIXEL_FORMAT := "RGBX_8888"
TARGET_RECOVERY_PIXEL_FORMAT := "RGB_565"



took me a couple hours to figure out the graphics issues
Click to expand...

Hroark figured out the twrp graphics, so if you ever come back to life quiestorm, I'd thought I'd repost for you
 
downthemachine said:
Hroark figured out the twrp graphics, so if you ever come back to life quiestorm, I'd thought I'd repost for you
Click to expand...

Well, sorry for the long absence guys... Lots of issues with life right now preventing me from working on anything. Relationship issues with fiancee, work, etc etc. So, Im gonna be gone for a bit. I dont have my desktop with all my files on it right now, but when i get the rest of my stuff from the apartment she lives in, I will be back. Btw, hroark... welcome back, and thanks for fixing the issue i have been having SO much trouble with.
 
QuietStorm1785 said:
the touch panel was installed the correct way, but the screen itself was installed upside down.

I spoke to Dees_Troy, one of the devs of twrp, he didnt know what was wrong, me either, because TWRP has the same code in it as cwm when it comes to flipping the buffer 180 degrees, I checked their graphics.c in the minui folder, the code is almost exactly the same, except they added a few things for the RGB modes. heres is the bit of code in twrp's graphics.c:

Code: 
#ifdef BOARD_HAS_FLIPPED_SCREEN
    /* flip buffer 180 degrees for devices with physicaly inverted screens */
    unsigned int i;
    for (i = 1; i < (vi.xres * vi.yres); i++) {
        unsigned short tmp = gr_mem_surface.data[i];
        gr_mem_surface.data[i] = gr_mem_surface.data[(vi.xres * vi.yres * 2) - i];
        gr_mem_surface.data[(vi.xres * vi.yres * 2) - i] = tmp;
    }
#endif
and heres the code from my cwm source graphics.c :

Code: 
#ifdef BOARD_HAS_FLIPPED_SCREEN
    /* flip buffer 180 degrees for devices with physicaly inverted screens */
    unsigned int i;
    for (i = 1; i < (vi.xres * vi.yres); i++) {
        unsigned short tmp = gr_mem_surface.data[i];
        gr_mem_surface.data[i] = gr_mem_surface.data[(vi.xres * vi.yres * 2) - i];
        gr_mem_surface.data[(vi.xres * vi.yres * 2) - i] = tmp;
    }
#endif
notice it's exactly the same... no differences whatsoever? which is why it has me so stumped. ima haveta play with it a bit to see what can be done to it, it's been nagging me since twrp 2.0 came out. and i built twrp for the warp way back then, just never published it since it was upside down, and as shinru said, you hadta press the top of the screen (which was the bottom of the actual screen your looking at) to reboot and such.

[EDIT]
also from what dees_troy said, the actual graphics.c that twrp uses is in the minuitwrp folder of the source. it does have the setting for the flipped screen. Ima play around with it a bit for a while and see what happens, hopefully i can get it working top notch for our warp, but idk. I need to find a good usb cable to use for my computer so i can copy my finished cwm installer, and if it shits on me, I can boot into windows and use fastboot to fix it.
Click to expand...



hi bro
I'm Jimmy from Vietnam
I got issue with the screen, it's rotated to 18 degrees with CWM Recovery
and I used this function to fix it !


Code: 
void gr_flip(void)
{
    GGLContext *gl = gr_context;
 
    /* flip buffer 180 degrees for devices with physicaly inverted screens */
    unsigned int i;
    for (i = 1; i < (fi.line_length/PIXEL_SIZE * vi.yres); i--) {
        unsigned short tmp = gr_mem_surface.data[i];
        gr_mem_surface.data[i] = gr_mem_surface.data[(fi.line_length * vi.yres * 2) - i];
        gr_mem_surface.data[(fi.line_length * vi.yres * 2) - i] = tmp;
    }

    /* copy data from the in-memory surface to the buffer we're about
    * to make active. */
   memcpy(gr_framebuffer[gr_active_fb].data, gr_mem_surface.data,
          fi.line_length * vi.yres);
 
   /* inform the display driver */
   set_active_framebuffer(gr_active_fb);
}
 
Status
Not open for further replies.
Back
Top Bottom