Database Info

Strange WMPlayer related keys. Who knows them?

These registry entries control wmvdecoder.dll behaviour when playing WMV content on Windows Media Player 10. The keys are almost the same as they exist on the XP PC. You can use RegMon.exe to examine them on the PC. Some values are a little different.
The values starting with _ are not active.
"Post Process Mode" can range from 0 (no) to 4 (max) and when -1 it goes into auto mode.
[HKEY_CURRENT_USER\Software\Microsoft\Scrunch]
"Force Post Process Mode"=dword:00000001 ; obvious
"Adapt MHz"=dword:00000000 ; adapt the CPU clock frequency?
"_Current Post Process Mode"=dword:ffffffff ; this key should always be -1?
"Adapt QPC Level 0"=dword:00000014 ; ?
"Adapt QPC Level 1"=dword:00000028
"Adapt QPC Level 2"=dword:0000003c
"Post Process Mode"=dword:00000000 ; mode to use now
"Count CPU Cycles"=dword:00000000 ; ?
"_Adapt Post Process Mode"=dword:00000001 ; make it dynamic (works on PC)
"Omit BF Mode"=dword:00000000 ; ?
"Fake Player Behind"=dword:00000000 ; ?
[HKEY_CURRENT_USER\Software\Microsoft\Scrunch\Video]
"Bitrate"=dword:00000100 ; 256 kbs
"_Resolution"=dword:00014000 ; ?
So a lot of unknows in the equation here.
Also GAPI is used with WMP. I will place the keys tonite.
Still experimenting with the \windows\gxdma.dll (see attachement)
(\windows\gx.dll should be present in ROM)
WMP looks up these registry entries.
It can use GDI or GAPI.
[HKEY_CURRENT_USER\Software\Microsoft\MediaPlayer\Preferences]
"RenderGDI"=dword:00000000 ; use GDI instead of GAPI?
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MediaPlayer\GAPI]
"Buffer"=dword:00025800 '; 320x240x2
"DeviceID"=hex:\
01,00,02,00,E6,4C,B4,6D,32,33,32,39,30,37,14,14,09,04,01,02
"cbxPitch"=dword:00000002 ; pixel shift in buffer for 1 x pixel on screen
"cbyPitch"=dword:00000640 pixel shift in buffer for 1 y pixel on screen
"cBPP"=dword:00000010 ; 16 bitsperpixel
"cxWidth"=dword:000000f0 ; 240 pixel
"cxHeight"=dword:00000140 ; 320 pixel
"ffFormat"=dword:000000a8 ; have seen A0 as well
These values are a big dunno. Got them from a SNES emu site.
Also the DeviceID is hard to find. I just copied the
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing\HardwareID]
"ClientHWID"=hex:\
01,00,02,00,E6,4C,B4,6D,32,33,32,39,30,37,14,14,09,04,01,02
Then you can put gxdma.dll in the \windows directory. Still investigating if that is improving performance.
I also try to use divx codecs with WMP10 CE. It can be done.
To be continued
Cheers

tweakradje said:
When running WMP 10 and CE Regspy I found these strange (very undocumented) registry entries that look kinda exiting:
Click to expand...
Click to collapse
And they look exciting because....?

tweakradje said:
These registry entries control wmvdecoder.dll behaviour when playing WMV content on Windows Media Player 10. The keys are almost the same as they exist on the XP PC. You can use RegMon.exe to examine them on the PC. Some values are a little different.
The values starting with _ are not active.
"Post Process Mode" can range from 0 (no) to 4 (max) and when -1 it goes into auto mode.
[HKEY_CURRENT_USER\Software\Microsoft\Scrunch]
"Force Post Process Mode"=dword:00000001 ; obvious
"Adapt MHz"=dword:00000000 ; adapt the CPU clock frequency?
"_Current Post Process Mode"=dword:ffffffff ; this key should always be -1?
"Adapt QPC Level 0"=dword:00000014 ; ?
"Adapt QPC Level 1"=dword:00000028
"Adapt QPC Level 2"=dword:0000003c
"Post Process Mode"=dword:00000000 ; mode to use now
"Count CPU Cycles"=dword:00000000 ; ?
"_Adapt Post Process Mode"=dword:00000001 ; make it dynamic (works on PC)
"Omit BF Mode"=dword:00000000 ; ?
"Fake Player Behind"=dword:00000000 ; ?
[HKEY_CURRENT_USER\Software\Microsoft\Scrunch\Video]
"Bitrate"=dword:00000100 ; 256 kbs
"_Resolution"=dword:00014000 ; ?
So a lot of unknows in the equation here.
Also GAPI is used with WMP. I will place the keys tonite.
Still experimenting with the \windows\gxdma.dll (see attachement)
(\windows\gx.dll should be present in ROM)
WMP looks up these registry entries.
It can use GDI or GAPI.
[HKEY_CURRENT_USER\Software\Microsoft\MediaPlayer\Preferences]
"RenderGDI"=dword:00000000 ; use GDI instead of GAPI?
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MediaPlayer\GAPI]
"Buffer"=dword:00025800 '; 320x240x2
"DeviceID"=hex:\
01,00,02,00,E6,4C,B4,6D,32,33,32,39,30,37,14,14,09,04,01,02
"cbxPitch"=dword:00000002 ; pixel shift in buffer for 1 x pixel on screen
"cbyPitch"=dword:00000640 pixel shift in buffer for 1 y pixel on screen
"cBPP"=dword:00000010 ; 16 bitsperpixel
"cxWidth"=dword:000000f0 ; 240 pixel
"cxHeight"=dword:00000140 ; 320 pixel
"ffFormat"=dword:000000a8 ; have seen A0 as well
These values are a big dunno. Got them from a SNES emu site.
Also the DeviceID is hard to find. I just copied the
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing\HardwareID]
"ClientHWID"=hex:\
01,00,02,00,E6,4C,B4,6D,32,33,32,39,30,37,14,14,09,04,01,02
Then you can put gxdma.dll in the \windows directory. Still investigating if that is improving performance.
I also try to use divx codecs with WMP10 CE. It can be done.
To be continued
Cheers
Click to expand...
Click to collapse
Any news? It's interesting

buffer Size
So do you know if there is a Reg Key to increase the buffer size for streaming video?
Yhanks

Touchscreen Driver improvements (Touch.dll)

Touchscreen Driver improvements (Touch.dll)
This Polaris thread contains a new Touchscreen Driver and various registry keys to improve touchscreen response.
http://forum.xda-developers.com/showthread.php?t=446126
***WARNING***
Unfortunately, at this stage this improved touchscreen driver is not compatible with Kaiser Roms. Hopefully further testing and development with change this.
__________________
According to my Kaiser Taskmanager (I have tried this on at least 5 Roms and is a well know HTC bug on many devices), just placing pressure and motion on the touchscreen uses an addition 50%+ CPU usage even if no function is being accessed by touching the screen. Touchscreen driver is also at Highest Priority setting by default. This is a major cause of sluggishness on HTC devices as all tasks, including screen re-draws is suspended in favour of the touchscreen mindlessly using 50%+ CPU.
Creating this following registry keys can lower the CPU priority but the screen is very unresponsive -
HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Touch
(DWORD)
Name = "Priority256"
Value = "255"
Name = "PriorityHigh256"
Value = "255"
The following registry keys (Original Microsoft value that can be found at MSDN for a normal driver) lower the CPU priority but still maintain usability (CPU can still reach 50%+) -
HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Touch
(DWORD)
Name = "Priority256"
Value = "109"
Name = "PriorityHigh256"
Value = "109"
A soft reset is required to test these values. I am currently testing different values to find the best blend between screen response and screen refresh rate.
There are other registry keys which may help as well. I look forward to your feedback.
I am not a programmer but I started this thread in the hope that one of our highly talented chefs would be able to make a port of Polaris driver for Kaiser. I have tried playing with the registry and it does have an effect but there are trade-offs between graphics performance vs touch screen response.

TITAN-23 said:
Touchscreen Driver improvements (Touch.dll)
This Polaris thread contains a new Touchscreen Driver and various registry keys to improve touchscreen response.
http://forum.xda-developers.com/showthread.php?t=446126
According to my Kaiser Taskmanager (I have tried this on at least 5 Roms and is a well know HTC bug on many devices), just placing pressure and motion on the touchscreen uses an addition 50%+ CPU usage even if no function is being accessed by touching the screen. Touchscreen driver is also at Highest Priority setting by default. This is a major cause of sluggishness on HTC devices as all tasks, including screen re-draws is suspended in favour of the touchscreen mindlessly using 50%+ CPU.
Creating this following registry keys can lower the CPU priority but the screen is very unresponsive -
HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Touch
(DWORD)
Name = "Priority256"
Value = "255"
Name = "PriorityHigh256"
Value = "255"
The following registry keys (Original Microsoft value that can be found at MSDN for a normal driver) lower the CPU priority but still maintain usability (CPU can still reach 50%+) -
HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Touch
(DWORD)
Name = "Priority256"
Value = "109"
Name = "PriorityHigh256"
Value = "109"
A soft reset is required to test these values. I am currently testing different values to find the best blend between screen response and screen refresh rate.
There are other registry keys which may help as well. I look forward to your feedback.
Click to expand...
Click to collapse
Im thinking about doing the opposite. I want faster touch response. lol

TheParadox said:
Im thinking about doing the opposite. I want faster touch response. lol
Click to expand...
Click to collapse
Actually, the touch "user experienced" responsiveness is slower if the touch.dll has too high a priority as the screen refreshes slow down (lower frames per second on scrolling and animations).
Have you noticed that frames per second DECREASE dramatically the longer you touch the screen? This is because screen re-draws (refreshes) are at a lower priority to the touch driver. The touch driver is hogging the CPU. This makes the interface sluggish and slow.

resulted in a completely unresponsive touchscreen in my Kaiser .. hard reset was needed. Perhaps incompatible with the rom i was using? (Ultimate X v7 .. excellent rom btw).

bump
would love to see some progress made on this

When i saw the title i thought there was a new driver that was less cpu intensive . Oh well, i should give this a try and see if it is compatible with josh's kitchen.
Edit: there is a driver, but work on it appears to be discontinued?
This guy was doing the winmo world quite a favor by attempting to fix a problem that plagues us all (or at least the HTCers among us.) I wonder if htc will fix this eventually.

I am not a programmer but I started this thread in the hope that one of our highly talented chefs would be able to make a port of Polaris driver for Kaiser. I have tried playing with the registry and it does have an effect but there are trade-offs between graphics performance vs touch screen response.

marbella property
First Time it is worked for me, but now it is look like i have jailbreaked my device

bump.
as for me 2d drivers more important that 3d one.

It works
I'm currently using a value of 109 as recommended and feel it more responsive.
The ROM i'm using is Josh 21806 Full.

A run through of the panel code and mddi interface

Hey guys,
Over the last few days, I've been reading through the code and just trying to understand how it all works.
I think I've got some pretty good guesses on how the panel interacts with the video hardware now, so I thought I'd share. Some of you probably already know this stuff, so if I'm getting anything wrong, please tell me. Note this whole post is pretty much 100% guesses, so take it all with salt.
The phone uses a "Mobile Station Modem" (msm) chipset which is this specialized chipset made for hand held devices that provides a grab bag of features.
This chipset seems to be what drives access to the various features of the phone (video, cameras, gps, etc). The chipset can be used in a variety of phones and things, so it provides some features that aren't relevant or wired up to the evo 4g.
Inside msm_fb.h there's a list of the output interfaces:
enum {
MSM_MDDI_PMDH_INTERFACE = 0,
MSM_MDDI_EMDH_INTERFACE,
MSM_EBI2_INTERFACE,
MSM_LCDC_INTERFACE,
MSM_TV_INTERFACE,
MSM_MDP_NUM_INTERFACES = MSM_TV_INTERFACE + 1
};
In reverse order, I'm guessing this translates to, "old school tv out", "typical digital video output (for LCDs and other digital outputs)", "memory i/o (unrelated to video? or maybe for driving 'dumb framebuffers'?)", "External mobile display via mddi", "primary mobile display via mddi".
mddi is apparently "Mobile Display Digital Interface" which is some new way to connect lcd panels to the video hardware using less wires than more typical digital video outputs. I guess a usecase for mddi would be a flip phone, where the big screen would take the primary interface, and the little viewfinder screen you use when the phone is closed would be driven via the external interface.
Apparently, the HDMI port on the EVO is hooked up to the LCDC interface (where on other android phones, the LCDC interface is used for the screen). So that leaves the two mddi interfaces left. Which one of the mddi interfaces does driver use for the main display? Unsurprisingly, it seems to use the "primary interface" aka mddi0
Note this code in board-supersonic-panel.c:
if (panel_type == 0) {
mddi_pdata.power_client = mddi_epson_power;
} else {
mddi_pdata.power_client = mddi_novatec_power;
}
msm_device_mddi0.dev.platform_data = &mddi_pdata;
and this code in devices.c:
static struct resource resources_mddi0[] = {
...
.start = MSM_PMDH_PHYS;
...
}
struct platform_device msm_device_mddi0 = {
...
.resource = resources_mddi0
...
}
Okay, so now we know the panel talks to the graphics hardware via mddi. But, how is the image data transferred? Apparently, there are two possible DMA channels. The "primary" dma channel and the "secondary" dma channel. I think these channels are closely tied with the interface the panel is hooked up to. i.e. the panel uses the primary interface, so it would use the primary dma channel. I'm not 100% sure though. It might be that either channel is okay. I suspect the former is true, though, because at some point the epson panels weren't working when they were trying to use the secondary dma channel and Joe Hansche made them work by forcing them to use the primary channel (among other changes).
There is a little mystery here, though. mdp_probe has this:
if (pdata == NULL || pdata->dma_channel == MDP_DMA_P) {
ret = mdp_out_if_register(&mdp->mdp_dev,
MSM_MDDI_PMDH_INTERFACE, mdp, MDP_DMA_P_DONE,
mdp_dma_to_mddi);
} else if (pdata->dma_channel == MDP_DMA_S) {
ret = mdp_out_if_register(&mdp->mdp_dev,
MSM_MDDI_PMDH_INTERFACE, mdp, MDP_DMA_S_DONE,
mdp_dmas_to_mddi);
}
The else half of that code says something like:
if we've found a panel in our devices database that is configured to use the secondary dma channel, then link the primary interface up to the secondary dma channel code.
As the code stands now, there is no panel in the devices database configured for the secondary dma channel, so that else clause will never run, afaict. Anyway the driver is at least structured to allow the primary interface to use the secondary dma channel. It just might not work in practice.
The driver looks incomplete for handling the external interfaces. It hardcodes using the primary interface. That's okay though, since the evo4g apparently doesn't use that interface (since it's not a clamshell phone with a viewfinder display i guess).

the logic seems pretty sound and makes sense. appreciate the detailed write up with the sections of code!
for arguments sake, assume you're 100% correct in everything you stated, im not clear on the immediate next step or options of steps which can be taken from here?

i think this wouldve done more good to be posted in the thread thats topic is about the source u are commenting on. :/

Thanks, extremely helpful even if they are only guesses!

toastcfh said:
i think this wouldve done more good to be posted in the thread thats topic is about the source u are commenting on. :/
Click to expand...
Click to collapse
I thought about it, but I thought it might be a little too much of a deep dive and didn't want to hijack that thread.
We can move the discussion there if you want.

joeykrim said:
the logic seems pretty sound and makes sense. appreciate the detailed write up with the sections of code!
for arguments sake, assume you're 100% correct in everything you stated, im not clear on the immediate next step or options of steps which can be taken from here?
Click to expand...
Click to collapse
well the point of this is code spelunking is just educational, not necessarily with a specific end goal in mind. Since this is the developer forum, it's probably useful in general to have stuff like this written out so that when people (with specific end goals in mind) don't know where to start they can do a read through and figure out the best place to dive in.

[Q] Basic Java Programming - pi as a float

Forgive me if this has been asked, but I searched for pi and Math.PI and couldn't find anything relevant.
I am new to programming, so I am starting out with basic Java.
Problem as follows:
input:
a number which is a radius​output:
area and circumference of the circle with input as radius
volume and surface area of the sphere with input as radius​
I got a working class, but when I attempted to change the variables to floats, in the interest of learning, it errored out. The reason is that Math.PI yields a double. I tried: float pi = Math.PIF​ That doesn't work. The only way I was able to have a working class using floats, I had to initialize pi as follows:
pi = 22/7F​Is there a way to use Java's Math.PI as a float?

just out of curiousity, since i'm taking a java class now.
why would you want to change math.pi into a float?
edit:
don't have a working copy of the java ide yet but, have you tried var = (float)math.pi?

As I said in the post:
in the interest of learning​
When I begin to write larger programs, if I need to save memory, need to use pi, and won't be hindered by the inaccuracy of float calculations, then I will want to know how to do this.

just finished installing my java ide and netbeans.
and well, to change Math.PI into a float, you can do
final float var = (float) Math.PI
Since you said you're new, final means it can't be overridden (ie, change numbers) and is optional per your needs.
if you want to check it;
float fpi = (float) Math.PI;
System.out.println("Floated Pi " + fpi);
System.out.println("Normal Pi " + Math.PI);
also, if you want a java pdf, send me a pm and i'll send you the link

That worked. Just so you know, with an input of 1, the only value which was off was that of the surface area of the sphere. 12.57 when it should be 12.56. This may be due to my formatting the output to 2 decimal places, or to the inaccuracy of the float. I'll cross that bridge when I come to it.

a spheres radius of 1's surface area is (float)12.566371. so your 12.57 seems correct. Its been fun, but its 5am here. time for bed

I think I had used 3.14 on a calculator to come up with 12.56. That would definitely not be the best number to use. I was tired. Thanks for the help though.

Code Question RE: 4.0~ 720p recording

I'm hoping someone here might be able to help with this. As some of you know, I've been hacking away at the camera problem. I suspect that at least part of the issue is that somewhere along the line our phone is reporting a 50Hz field rate rather than 60Hz (as it should). The result is that with the back camera only, the camera is limited to 25fps. I've been searching everywhere for where this might happen and today I think I found something. The problem is I can't really understand the code well enough to know what to do, where to look, etc. So, I'm posting this here in the hope that someone might know and be able to help! The offending file is in the kernel ~drivers/media/video/gspca/sonixb.c The pertinent lines begin on 951:
Code:
static void setfreq(struct gspca_dev *gspca_dev)
{
struct sd *sd = (struct sd *) gspca_dev;
switch (sd->sensor) {
case SENSOR_OV6650:
case SENSOR_OV7630: {
/* Framerate adjust register for artificial light 50 hz flicker
compensation, for the ov6650 this is identical to ov6630
0x2b register, see ov6630 datasheet.
0x4f / 0x8a -> (30 fps -> 25 fps), 0x00 -> no adjustment */
__u8 i2c[] = {0xa0, 0x00, 0x2b, 0x00, 0x00, 0x00, 0x00, 0x10};
switch (sd->freq) {
default:
/* case 0: * no filter*/
/* case 2: * 60 hz */
i2c[3] = 0;
break;
case 1: /* 50 hz */
i2c[3] = (sd->sensor == SENSOR_OV6650)
? 0x4f : 0x8a;
break;
}
i2c[1] = sensor_data[sd->sensor].sensor_addr;
if (i2c_w(gspca_dev, i2c) < 0)
PDEBUG(D_ERR, "i2c error setfreq");
break;
}
What we want is case 2, but it seems like we're getting case 1. I don't know what I might do to correct it either!

I'm wondering if you set it to 20fps if it records fine ? Not true HD or anything but not jumpy?
I'm thinking i2c3=0 is making it stay at 25fps can you modify that to change it to 20?
This code sounds like it is trying to compensate for indoor lighting... Not the frequency of the screen? Weird.
Sent from my SGH-I997 using xda app-developers app

Skwerl23 said:
I'm wondering if you set it to 20fps if it records fine ? Not true HD or anything but not jumpy?
I'm thinking i2c3=0 is making it stay at 25fps can you modify that to change it to 20?
This code sounds like it is trying to compensate for indoor lighting... Not the frequency of the screen? Weird.
Sent from my SGH-I997 using xda app-developers app
Click to expand...
Click to collapse
I'm honestly not sure how you would. You can reduce a number of artifacts by reducing the framerate, but it doesn't completely solve the problem. I suspect that the 25fps issue is not entirely the cause of 720p recording problems. Another issue is the codecs. I noticed logcats that the camera is avoiding on board codecs. It seems like it should be calling up the OMX.sec codec, but instead it's defaulting to the software codecs. More than likely has everything to do with the limited source Samsung has released. And probably the biggest issue is that there is something wrong with the structure of the camera hal. Right now I'm trying to work out whether v4l2_reqbufs and v4l2_dqbufs are being deployed properly. I came across an OMAP datasheet that explains that if vidioc_dqbuf is called with the file descriptor and vidioc_reqbuf is not performed, the driver will return an error. Since all logcats point to vidioc_dqbuf not dqing the buf, I'm guessing that this is the source of the choppiness. Problem is, I don't know where to look for a working example!