yashsingh1/xdaforums huggingface dataset:
[EVO 4G Android Development] maejrep:
Actually, mddi is already initialized by the time the init seq array is executed (it has to be, otherwise client_data->remote_write() would not work ;)). When the panel goes to sleep, it calls novtec_suspend(), which will in turn call bridge.uninit() and panel.suspend(). When waking it up, novtec_resume() calls panel.resume() then bridge.init(). The only difference there is that the uninit() function is called, whereas on boot, it is not called. uninit writes (0,0x2800)
[EVO 4G Android Development] Cicatrize:
Do you know where the proc is that actually handles the loop of writing to the display RAM?

I found it interesting that the guy above was saying it updates in 20 frames, then for 20 frames it's blank. It's almost like the refresh happens, then the process waits 500ms to rewrite again or something. Or maybe the MDDI and I2C interfaces wait 500ms to run again.
[EVO 4G Android Development] geyes30:
Actually it doesn't go blank for 20 frames, but rather stays unchanged for 20 frames. I thought it might be forcing a pause, but if that were the case, changing the T2 values would not result in the observed frame rate (i.e. the frame rate changes will be smaller than that observed, since there is a fixed pause involved). e.g., With frames refreshing at 80 hertz, it would take 1/80secs (draw) + 1/60secs (pause) = 1/34secs to refresh the frames, i.e. a frame rate of 34Hz instead of 40 Hz observed.
[EVO 4G Android Development] maejrep:
When geyes30 said it draws in 20 frames, he was referring to 20 frames from his 1200fps camera, which is 1/60 sec (or 1Hz). That's actually 16.67 ms.

Writing to display RAM is done in mdp.c, in put_img(struct file *file), which uses android_pmem (drivers/misc/pmem.c) to do the memory transfer
[EVO 4G Android Development] Cicatrize:
OH yeah, that's what I meant. Sorry, I've been up for a long time lol. Good thinking about this. I want to work backwards from the display draw and try and figure this out.

Thanks. You know your ****. :)

Yeah I knew what he meant though. I was just pointing out that it remains on a fixed display image for the same amount of frames it took to refresh.
[EVO 4G Android Development] Cicatrize:
Also, does the display RAM send the image to the display handled in the driver for the interface?
[EVO 4G Android Development] maejrep:
I tried doubling the mddi clock to 768MHz. The result was a 35-40% lower (26fps) framerate in fps2d. When I cat /sys/kernel/debug/clk/mddi_clk though, I don't get the 768MHz I expected, instead it shows 235930000, which is 61.4% of the original 384MHz speed.
[EVO 4G Android Development] Cicatrize:
I think the MDDI is only capable of 400MHz, so anything over that would probably yield those type of results. Was the system unstable?
[EVO 4G Android Development] justinisyoung:
what about lowering the clock? does changing it to something between 384 and 235 keep it at 235 or does it stay at the value you set it to?
[EVO 4G Android Development] maejrep:
Was not unstable. 400MHz cap might explain that. Trying other values resulted in other equally confusing results, but the actual clock rate directly correlated to the framerate in fps2d.
[EVO 4G Android Development] ffolkes:
i was trying this avenue a few weeks ago. it seems anything over 384 results in a kick down to either the 235930000 you mentioned, or a number starting with 1 (meaning around 100mhz) and 15fps. i don't remember what i did exactly, but messing around in devices.c with the clock flags (minmax, off, etc), got it to 235930000. i'm surprised you got to 235 right off the bat.

i have no idea what's going on in devices.c and all the clock stuff near the bottom. i don't get where ANY clock is being set for any interface - the only clock references i can find are in the cpu-related files, which are irrelevant.

and to the other person who asked about setting it lower, yes you can set it lower and it'll stay - if i remember correctly.
[EVO 4G Android Development] ffolkes:
anyone up?

i've tweaked this dirty hack some more, and before i post it, i want someone else to try it.
[EVO 4G Android Development] sheffield:
Sure, src or binary will work.
[EVO 4G Android Development] sheffield:
If this helps anyone, here's code to look at various registers on the panel...

static uint32_t regs_to_dump[] = {0x0a00,// Display power mode
0x0e00,// Display signaling mode
0x3b00,// RGB Signal control
0xb100,// Timing
0xb101,//
0xb102,//
0xb103,//
0xb104,//
0xb105,//
0xb106,//
0xb107,//
0xb108,//
0xb109,//
0xc100,// Power control 2
0xc101,//
0xc102,//
0xc200,// Power Control 3
0xc201,//
0xc202,//
0xc203,//
0xc300,// Power Control 4
0xc301,//
0xc302,//
0xc303,//
0xc400,// Power Control 5
0xc401,//
0xc402,//
0xc403};

static int dump_panel_regs(struct msm_mddi_client_data *cd) {

int i;
printk("### BEGIN NOVATEK REGISTERS ###\n");
for (i = 0; i < ARRAY_SIZE(regs_to_dump); ++i) {
msleep(5);
uint32_t val = cd->remote_read(cd, regs_to_dump[i]);
printk("NOVATEK reg 0x%.4x: 0x%.2x (%3ud)\n",regs_to_dump[i],val,val);
}
printk("### END NOVATEK REGISTERS ###\n");
return 0;
}

Put it near the top of board-supersonic-panel.c (after the includes) and call it where you want. Add / remove registers from regs_to_dump[] to display what you're interested in. 'adb shell dmesg | grep NOVATEK' to see everything laid out.

Call it in the panel_unblank function to view current state of registers by locking / unlocking screen...

static int
supersonic_panel_unblank(struct msm_mddi_bridge_platform_data *bridge_data,
struct msm_mddi_client_data *client_data)
{
printk(KERN_DEBUG "%s\n", __func__);
if (panel_type == 1) {
// nov
suc_backlight_switch(LED_FULL);
client_data->remote_write(client_data, 0x00, 0x2900);
msleep(100);
client_data->remote_write(client_data, 0x24, 0x5300);
[COLOR="Red"]dump_panel_regs(client_data);[/COLOR]
} else {
// epson
suc_backlight_switch(LED_FULL);
client_data->remote_write(client_data, 0x4000, 0x600);
msleep(10);
qspi_send_9bit(0x00, 0x29);
}
backlight_control(1);
return 0;
}

Also, those power control registers displayed are kind of interesting. They generate a bunch of clocks that divide hsync by 2 when the panel is initialized. Changing them to generate the clocks @ hsync was a dead end by itself (and when setting T2 to 170), but who knows, it may work in conjunction with something.
[EVO 4G Android Development] glokksomniac:
Can something try one more thing for me?

Add:

{0x3601, 0x01},

after

{0x3500, 0x00},

in the init sequence. That should enable the High speed RAM write mode.

I have a theory that the writing of the new frame to the internal memory of the controller happens slower than it should because its not in this "high-speed" write mode.

Basically, we're in the situation that's described in section 5.5.2 (page 78) of the Novatek document. In the diagram there you'll see that the MCU to Memory write take longer then the interval between frames (shown by the ticks on the FTE output signal). There's 3 frames shown on that diagram. When the write takes longer than a frame the effect is that the LCD shows the old frame again (point c on the diagram). On the next frame the screen finally shows the new frame (point e). This effectively halves the framerate of the screen but does it in a way that matches up with the observations we have from the high speed camera: the screen updates within 1/60th of a second and then a long pause until the next update.

We really want to be in the situation described in 5.5.1. Hopefully enabling this "high-speed" write mode does that.
[EVO 4G Android Development] ffolkes:
i tried setting it to high speed a few days ago, it makes no difference. and long ago i found out disabling tearing just blanks the display totally.

sheffield, that's some awesome code you wrote :D i look forward to playing with it tomorrow (or this afternoon i guess). however, i messed with the clk stuff in the power registers days ago. i tried all different values. the only change i ever got was a weird pattern on the display, and no change in fps. the pattern looked like someone made a 20px or so image with a gradient from white to transparent and repeated it down the whole display.
[EVO 4G Android Development] sheffield:
Agreed on both. There's pretty strong evidence that some clock (WRX, PCLK, the internal oscillator/system clock (lower right corner of the block diagram on p 8) is getting set to 30Hz (or 30*480*800 Hz).

If it's WRX or PCLK then the signal is probably coming from outside the novatek chip. In this case futzing around with the controller is likely a waste of time and we need to find where that signal is generated and double it.

If it's the internal oscillator / clock generator we may be able to do something with the controller to double it, but I haven't found anything yet.

Thanks :D It makes things easier.

The power control caught my eye because <any clock> / 2 deserves pretty close scrutiny given the situation. Total dead end as both of us discovered. Argh
[EVO 4G Android Development] ffolkes:
perhaps i asked for volunteers a bit too soon.

so now that i have a flashable zip ready, i'm going to clutter this thread by asking for volunteers yet again. :P

preferably someone who had trouble with the first kernel. this is still a t2 modification like the 2nd kernel i posted, but i'm curious how it will work for those who had trouble with the first one.
[EVO 4G Android Development] halorin:
I'll try it. I have an 0003 with a nova display. The first patch didn't work but the second got me to 40.
[EVO 4G Android Development] kpkimmel:
Have 002 and couldn't get 1 st to work.........let me know ill try
[EVO 4G Android Development] halorin:
Ffolkes is definitely onto something. With the test kernel he gave sent to me I got up to 50 fps. The first patch didn't work for me. I'll run this for a while and see if I have any bugs.
[EVO 4G Android Development] distincthead:
I've got an 0002 (nova screen), I'll give it a shot. The first one was a bit wonky for me.
[EVO 4G Android Development] kpkimmel:
average 50 fps.....getting there..i'll leave the kernal on and check battery life and temp for the day..and i'll let you know ffolkes..but good work man...
[EVO 4G Android Development] jblazea50:
would also like to test out the newer T2 version and report any issues

thanks in advance
[EVO 4G Android Development] kpkimmel:
hey ffolkes..threw ya a small donation...i'm on the new t2 version..i'll let you know any problems..
[EVO 4G Android Development] kpkimmel:
light sensor works..
[EVO 4G Android Development] codeman05:
Ffolkes, if you still need some testers, I'd be happy to give it a go on 0002 Nova.

First patch didn't work, but have been running the T2 since it was posted.

Thanks for the work
[EVO 4G Android Development] kpkimmel:
If ffolkes wants you to test he will pm the link to u
[EVO 4G Android Development] codeman05:
No kidding.....he did ask for volunteers you know.

Let's refrain from cluttering this thread up more than it already has been. :)

Ffolkes, so with T2.v2.....

Getting 50FPS here as well on 0002 nova.

StDev is a bit higher, 10-11 vs ~5 on V1...if that means anything to you.

Battery seems to be running cooler than V1, but I'll know more through the day.

Still seeing an issue with video (MP4 and flash) Force Closing on the initial load (2 different roms).

Reading the player after wards allows the video to play, but it stutters quite a bit vs the stock kernel. oddly enough Slingplayer just works.

Not a big issue IMO, but just wanted to through that out there as well.

Keep up the good work :)
[EVO 4G Android Development] chagio:
I'm a .NET developer and haven't gotten around to Linux and Android yet. So I'm no expert in this. :) My test results with T2 was awesome. Very stable at 40 FPS. However, it broke the camera. Here's my theory, albeit a crazy one. Either the Camera is incapable of playing nice with the LCD > 30FPS or a parameter needs to be changed in the camera when a new instance is called.
[EVO 4G Android Development] Krandor311:
The camera issue is because this kernel isn't actually from the Evo, so it doesn't even know the Evo's cameras are there. Until HTC gets off their butts and releases the source it's likely the camera won't work with this kernel.
[EVO 4G Android Development] timgt:
Since you don't want to read, go to post 581 and you wont be 30fps anymore

and ffolkes, I PM'ed you to see if I could try your newest fix.
[EVO 4G Android Development] EtherealRemnant:
Can someone PM me the link to test? I sent a PM and haven't heard anything and I have the exact conditions he is looking for. Nova that the original 55 patch did nothing on.
[EVO 4G Android Development] kpkimmel:
Ffolkes is tweaking some things...he said he'll release when he is ready
[EVO 4G Android Development] roghaj:
Hey Toast. How about you change the title of this thread and start a new one that might have the proper focus. Still a very productive line of effort here, but the 30fps issue seems like more of an afterthought to me (I've still read every post in this thread).

-Roger
[EVO 4G Android Development] ffolkes:
sorry for not getting back to some of you, i was typing. :P

since i anticipate another flood of replies like last time, i made a separate thread so this one won't get clogged with random people posting/complaining about what does/doesn't work. here: http://xdaforums.com/showthread.php?p=6971586

i'll look into forking the source (i think that's what it's called) later tonight, although all i'm doing is the same T2 tweak.
[EVO 4G Android Development] EtherealRemnant:
Okay so is it possible that my phone has a different light sensor than what is compiled in the kernel? Auto brightness never works with any kernel built off of this source code while others report it working fine. Anything I can do to help resolve this I am willing to do. The light sensor is imperative for me because without it my phone heats up like crazy because I have to leave it on medium high settings since I spend time both in and outdoors.
[EVO 4G Android Development] notown775:
my phone sticks on the htc evo scree (the white one) on the second fix. i have .002 version
[EVO 4G Android Development] Shidell:
Just a few questions for the uninitiated..

When the official EVO kernel is released, will we be switching to that entirely for development?

If we want to help/contribute, and we 'fork' our own branch and make changes and want to re-submit them, is that safe? Does Toast perform the final check/merge at this site (as 'committer')?
[EVO 4G Android Development] Cicatrize:
1. Yes. Working off an official kernel will be much easier.

2. I'm still not sure how all of this works, but work off your own fork and when the changes made are spectacular, I'm sure toast will make the commit to the master.
[EVO 4G Android Development] Shidell:
Thanks Cicatrize. I'd like to help, but I'm afraid of screwing things up. Hopefully just doing a Git and never pushing anything back (at least for now) will prevent problems.

It seems like there is a TON of hardware/drivers/firmware files in the GoDmOdE kernel. I realize this is an Incredible kernel with Supersonic board files, but why are there so many devices? Is this normal, or are things a bit sloppy because it's a hybrid?
[EVO 4G Android Development] justinisyoung:
it's a linux kernel. they keep support for all the possible devices that they can, even if it's a kernel specific to our phone.
[EVO 4G Android Development] Shidell:
Interesting. I assumed they'd strip out everything that's unnecessary to conserve space and speed.

As the kernel ages, then, I assume more and more hardware/devices are added?

Additionally, does that mean (for example) that a 2.6.30 kernel would probably work automatically on a Hero/Eris/G1/myTouch 3G-era phone, as it's dated?

I guess I don't know how they differentiate the kernels, if they're simply always adding functionality and always including as much hardware support as possible.

Does this also mean we can get the latest kernel from a specific repository (wherever it's hosted?) with the latest support?

(My apologies for being a newb. I'm trying to get up to speed a quickly as possible.)
[EVO 4G Android Development] Cicatrize:
I just want to point out that although we talk **** about HTC, their programmers are talented. We have tons of us devs working on this issue, most of us with C programming knowledge, and we still can't figure it out. And this is all with a kernel taken from a device that's not capped. Every time I chase a lead, I run into dead-ends or a non-functional device. Very frustrating...it's like they knew we'd try to figure this out and made it extremely hard to do so.

I'd say that for me alone, I've probably spent over 50 hours on this, and I'm sure some of the other devs have spent as much time if not more...and that's on ONE issue.
[EVO 4G Android Development] maejrep:
Light sensor has been working for a while now.

They leave it there because they have to. GPL and all :)

Not necessarily... The official kernel tree rejected many of Android's drivers because the changes that were requested didn't get applied in a timely fashion. So now all the Android-specific kernel code is kept in individual repositories (much of it is on Android's git repo, but device-specific files are not kept in any sort of source-control repository; instead HTC just releases the code for new devices as a tarball on their developer site). So that means some code is shared, but ultimately they just want to get the devices out the door, and they will hack whatever they need to to make that happen, and will NOT worry about doing it the GNU/Linux way, and will not submit their changes upstream. Google has been the only one trying to get some of the code into mainline kernel branch.
[EVO 4G Android Development] Cicatrize:
maejrep, is it possible the framebuffer can just be stopped for a certain period of time to suspend drawing until you want it to resume? I've been looking into early suspend and have noticed that it can either suspend the display while the framebuffer is still active, or keep the display active while suspending the framebuffer.

EDIT: Also maybe a complete disable of the framebuffer is possible.
[EVO 4G Android Development] Shidell:
Ah. Thanks for the clarification.

So HTC just takes the latest kernel (at the time), mods it to fit the hardware they're working on, and then makes it available (because they must), but doesn't bother submitting it for compilation into the general kernel (trunk?).

One question this raises is how we handle updating the kernel. For example, if HTC's EVO kernel is released as 2.6.29, and let's say down the road we need 2.6.34 to run Gingerbread, do we simply pull down the 2.6.29 kernel and try to merge the changes that HTC applied to their kernel? Or, are we only interested in stripping out the device drivers for hardware support and adding them to the 2.6.34 kernel (again, for example) to get the kernel working with hardware?

It's amazing (and bizarre) that I find this fascinating. Glad to be in welcome company. :)
[EVO 4G Android Development] maejrep:
Not immediately obvious if it can be turned off. Also not entirely sure what the goal would be. If you're basing that on the fact that there is no cap while the screen is off, it's because it's not writing to the display while it's off, but the system is still trying to draw. Because it's not writing to the display, the system is able to draw at full speed.

It's like when you have a terminal window open and it's scrolling a lot of data by on the screen -- if you minimize the terminal window, the program actually runs faster because it doesn't have to wait for the terminal to draw what it's outputting. Or if you redirect the output to /dev/null, it's faster because it doesn't have the latency of figuring out what to do with the output. Similar effect is happening here. The system is trying to draw pixels to the screen at the same 60Hz (vsync) rate, regardless. When the screen is on, that drawing behavior takes twice as long to perform a write of one screen as what it takes for the system to send it. The program (fps2d) is only aware of how fast its frames are being accepted by the system, and is not aware of whether those frames are actually being drawn to the screen or not.
[EVO 4G Android Development] maejrep:
Yes, that's mostly accurate on both counts. Upgrading a kernel is usually a pain (almost as much as reverse engineering the kernel the first time around, like what we've done with .29). Sometimes it's easy, but most times it's not. HTC has the benefit of serial debug consoles and hardware datasheets to help them get everything working in the first place. Our best chance is usually reverse engineering the kernel binary in order to rewrite the code that is missing from our tree but present in the binary. But when going to a new mainline version, it's not always that easy, since the way things are done have usually changed dramatically.
[EVO 4G Android Development] Cicatrize:
Alright, well I'm having trouble figuring out how it's possible to even limit the clock rate on each device attached to the interface. On I2C, the touch sensor is registering 30Hz on input, on MDDI, the system is capping 30fps, and on RGB, I haven't tested, but I'm sure the HDMI port is only outputting 30fps as well. Obviously, this has to be something coded, but how can they even do that? Do you have any ideas?
[EVO 4G Android Development] geyes30:
I'm pretty sure you guys are aware of this already, but just in case, I've been looking at the porting documentation for Android. Under the display drivers, it describes the use of a flipping front/back buffer system to compose and draw, thereby reducing the lag time. (http://source.android.com/porting/display_drivers.html)

Might it be possible that the current implementation of the Evo Novatek driver does not in fact use both framebuffers? It seems, from the high-speed camera experiment, that there is a lag time involved, where nothing happens. :)
[EVO 4G Android Development] AssassinsLament:
Then wouldn't that mean that the epson panel models should also be affected? Unless maejrep and toast accidentally upped the panel frame rate for the epson also?
[EVO 4G Android Development] geyes30:
Yeah I thought about that too, which is why I posted it here to see if toast and maejrep can shed some light on it. I don't really know the exact changes made to enable the Epson panel hack, but if the Novatek hack taught us anything, it is that there are many ways to skin a cat. :D
[EVO 4G Android Development] sheffield:
Short of hooking a running phone to an oscilliscope, is there any way to verify that the mddi_stb and WRX/SCL pins on the novatek IC are getting a full speed (384 MHz?) clock signal?
[EVO 4G Android Development] maejrep:
Other than the epson_init_seq and epson_init_cmds tables in board-ss-panel.c, there was nothing to hack. The reason it didn't boot was due to the epson's product code being 0000, and the mddi driver assuming that a 0 product code has to be fixed by calling the driver's fixup() function, which wasn't defined. The way HTC "resolved" that was by accepting a 0 product code, so that's what I did :)

Although, I did bring the epson client driver up to date to match the kernel binary, and to make it essentially an exact mirror of the novatek client driver: adding locks, adding cabc driver, etc. I'm sure it would have worked without those, but since they existed in the binary, I think it's safe to assume it was simply outdated in our code, since the code we have was forked before the XD hw rev was introduced. Looking at the binary confirmed that they did update all those things to make it essentially a mirror of the novatek client.

On an unrelated (well, related to the thread), it is possible to get more than 2 finger presses from the atmel driver, by modifying the config_T9[14] value. I changed it to 3, and used a multi-touch app I wrote to test, and it does see and track all 3 finger presses. I don't know how high that can go without needing other values tweaked, but 3 works. Also not sure how important it is to really use the "unlimited finger" support of the atmel :) But at least we know it can be done (and once again, we see that HTC is simply limiting us to 2 fingers for the hell of it)