Related
MediaPlayer.setDataSource(url) is not working in my app.
Im puttin the file "hello.mp3" in the assets-folder, and Im using the following
Code:
String soundUrl = "file:///android_asset/hello.mp3";
mp = new MediaPlayer();
try {
mp.setDataSource(soundUrl);
mp.prepare();
mp.start();
}
catch (IOException e) {}
catch (IllegalArgumentException e) {}
catch (IllegalStateException e) {}
This code works when I put the "hello.mp3" in the res/raw-folder:
Code:
mp = new MediaPlayer();
mp = MediaPlayer.create(getBaseContext(), R.raw.hello);
mp.start();
Problem with the last code is that I need to load the sound-files dynamically, and apparently you cant create a string or a uri with the correct sound-file at the end and insert that as the second parameter in the MP.create()-function.
Pseudocode - NOT WORKING
Code:
String mySound = "hello";
Uri myUri = "R.raw." + mySound;
...
mp = MediaPlayer.create(getBaseContext(), myUri);
Any ideas?
Amazing, several months later and still no one is able to realte how to play a local sound dynamically.
An issue with what you are trying to do is that there are multiple versions of MediaPlayer.create() and MediaPlayer.setDataSource() which take different types of parameters.
R.raw.hello is NOT a string. It is an int. Look in the gen directory to find the generated file R.java and in this file you will find raw which has a public static final int definition for R.raw.hello
R.raw.hello has to be passed to one of the routines which takes an int for the parameter and not a string.
hello,
I'm writing a Android App (java) - but I guess this question is pretty general, and isn't java-specific:
so I have an Array of Elements
and I let a random-number-generator pick one array-element randomly and hand it to me.
now I've also built in a "score"-field into each array Element
so what I want to do now, is that the random-number-generator takes the array's "score" in consideration, and gives me the array-elements with the higher/lower scores with a higher/lower probability
I dont want it to ALWAYS/NEVER give me the elements with the highest/lowest score - just with a higher/lower probability
I hope I could describe my problem in a proper way....
does anybody know how to achieve this?
(as I said, i use java, but i guess code in any language - or even pseudo-code would help me out)
*bump*
anybody?
Try this, it's in C# but it's pretty close to Java.
You cannot directly weight the random function so you have to use a different method.
By applying a weight to each item in the array, then using a random function to select using the weighting values, the results of the selection can be swayed.
The weighting values are relative to each other.
Using the values in the code, 'B' should turn up about three times more often than 'A'
The only object that may need some explanation is Random:
http://msdn.microsoft.com/en-us/library/system.random(v=VS.80).aspx
Code:
using System;
namespace RandomWeighting
{
class Program
{
static void Main(string[] args)
{
char[] Select = new char[10] {'A','B','C','D','E','F','G','H','I','J'};
int[] Weight = new int[10] {10,30,25,60,20,70,10,80,20,30};
int[] WeightSum = new int[10];
int i,j,k;
Random Rnd = new Random();
WeightSum[0]=Weight[0];
for (i = 1; i < 10; i++)
WeightSum[i] = WeightSum[i - 1] + Weight[i];
for (j = 0; j < 70; j++)
{
k = Rnd.Next(WeightSum[9]);
for (i = 0; k > WeightSum[i]; i++) ;
Console.Write(Select[i]);
}
Console.WriteLine();
}
}
}
Output:
Code:
HEFIBHHCCFBCAEFFDHACHBEJHHFDFIDFEDFFCHHDJBIDJEHHFHCJJJBHJGBDDGFDDFHHHB
Note the low density of A and G as opposed to H
It is just a sample at random, but 2 'A's and 7 'B's roughly matches the conjecture above, but over a million selections, the distribution is as follows:
Code:
A 30664
B 84187
C 70648
D 168481
E 56529
F 197311
G 28145
H 225764
I 56613
J 81658
If your code changes values in the Weight array then the WeightSum array must be recalculated.
wow, thats a lot!
The only thing I dont understand about the code is this line:
k = Rnd.Next(WeightSum[9]);
for (i = 0; k > WeightSum; i++) ;
what exactly happens here?
what kind of a for-loop is this?
why is there no body?
and strangely, while debugging this line, i noticed that the value of i jumps to some random number in this line - and I have no idea why and how
------
by the way: I've already tried it out, it works pretty good.
although I noticed that the first element always gets picked ALOT, no matter how low the weight.
I think thats a flaw in the algorithm
After the following code:
Code:
for (i = 1; i < 10; i++)
WeightSum[i] = WeightSum[i - 1] + Weight[i];
The WeightSum array contains the following values:
Code:
[0] 10
[1] 40
[2] 65
[3] 125
[4] 145
[5] 215
[6] 225
[7] 305
[8] 325
[9] 355
The Random.Next() function that takes a single integer as an argument is defined as:
-------- Courtesy of MS VS .NET Help ------
public virtual int Next(int maxValue)
Parameters maxValue Type: System.Int32
The exclusive upper bound of the random number to be generated. maxValue must be greater than or equal to zero.
Return Value Type: System.Int32
A 32-bit signed integer greater than or equal to zero, and less than maxValue; that is, the range of return values ordinarily includes zero but not maxValue. However, if maxValue equals zero, maxValue is returned.
-------------- End of Help ----------------
So, we are asking for a random value between 0 and 354,(element WeightSum[9] above). The following code then finds which is the lowest element of WeightSum which holds a value greater than the one we have been given. When this happens 'i' contains the index to use for the selection.
Code:
for (i = 0; k > WeightSum[i]; i++);
The standard construction of a for loop in C is
for(One or more initialisation statements; Do_While_True Condition; One or more iteration statements)
{
loop processing code;
}
If there is nothing to do in the loop body, you don't need it, and you can replace it with the ';' at the end of the for statement. In effect, it is identical to the following code:-
Code:
i=0;
while(k > WeightSum[i])
{
i++;
}
As regards the first element being picked more than the others, have a look at the distribution table in post #3. It is what you would expect for the values given. I assume the difference is either the Random function in Java or some different implementation between C# and Java.
You may have to change some of the code slightly, i.e. change the for() loop to the while() loop above and step though it in the Java debugger to get to the root of the problem.
You can't debug a for loop followed by an immediate ';' The entire for loop is executed to completion when you use debug and try and step through it. To debug it place a dummy statement in the for loop. A breakpoint may now be set on this line.
Code:
int i,z;
for (i = 0; k > WeightSum[i]; i++)
{
z=0;
}
ActionScript and Javascript versions ...
Thanks for the great write-up! In case anyone is interested, I've adapted this into a javascript and ActionScript class. If anyone is interested, I've attached the code. For a more in-depth post, check out blog.teamthinklabs.com.
Cheers!
Kipp Ashford
Art Director
Seven2 Interactive
I have been looking into the C-Sharp__DLLImport project here:
http://forum.xda-developers.com/showthread.php?t=1006331&highlight=dllimport
I am trying to modify the FileSystem project to be able to get a list of the modules that are loaded for each process.
Code:
STDMETHODIMP CFileSystemIO::GetModulesForProcess(DWORD dwPID, BSTR* result)
{
// Get the process snapshot
HANDLE hModuleSnapshot = CreateToolhelp32Snapshot( TH32CS_SNAPMODULE, dwPID );
// Initialize the module entry structure
MODULEENTRY32 moduleEntry = { 0 };
moduleEntry.dwSize = sizeof( moduleEntry );
// Get the first module info
BOOL Return = FALSE;
Return = Module32First( hModuleSnapshot, &moduleEntry);
// Getting process info failed.
if( !Return )
{
CloseHandle( hModuleSnapshot );
return S_FALSE;
}
int x = 1;
CString modList(TEXT(""));
do
{
modList.AppendFormat(TEXT("%d-%d-%d-%d-%d-%d-%s-%s\n"),
moduleEntry.dwSize,
moduleEntry.th32ProcessID,
moduleEntry.GlblcntUsage,
moduleEntry.ProccntUsage,
moduleEntry.modBaseAddr,
moduleEntry.modBaseSize,
moduleEntry.szModule,
moduleEntry.szExePath);
}
while( Module32Next( hModuleSnapshot, &moduleEntry ));
// Close the handle
CloseHandle( hModuleSnapshot );
// set the result
*result = (modList.AllocSysString());
return S_OK;
}
The code is based off a similar function that is already in the project (the CFileSystemIO::MessageBoxRunningProc function which works fine).
By putting some MessageBoxes in there for debugging, I can confirm that the Module32First and Module32Next methods are working correctly. When it gets to the line:
*result = (modList.AllocSysString());
The application crashes. I put a try/catch around there and it didn't trigger a CMemoryException or any other exception.
Any idea why this method would be causing the app to crash?
As an update to this, I was able to figure out the problem. I was unaware of this, but closing the handle generated in the method to get the process messes up the generation of the modules. I didn't think this would be the case since when you generate the handle it also takes a pid. I ended up combining the 2 methods.
The final project uses com interop to call the native methods and it builds a tasklist with all the corresponding modules as subclasses. You can find out which libraries and interfaces are in use by which applications, and where those dll files are located on your phone. If anyone wants to see it, I can post it at some point. It's not a very elegant looking interface, but it gets the job done.
Hi there, many of you would know me.
I am back after a short while, well actually I am here just to help you guys with overclocking. Neither do I have any resource such as high end cpu or hdd space to compile a kernel nor do I have a stable galaxy y as of NOW.
Now all the mathematics and programming geniuses, I need you all here. I am inviting all the developers who can ACTUALLY help. No questions from someone who has just started or something like that. For them I suggest you read a lot about processors first.
The overclock that developers till now have achieved as you all know, DOES NOT INCREASE MFLOPS.
After studying a lot about the arm11 processors. I know that the freq values we set are only the freq which are visible to users in apps. They are just registered so that users can view them as working.
ONLY PROCEED BELOW IF YOU KNOW ABOUT PROGRAMMING.
People who know about programming but not about ARM architecture visit this link : http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0328e/CHDEHCAB.html
Now there are two critical values which define the val, they are m_set and n_set.
The freq table that we create is just an imposture to the real clock. If you study msm boards then you'll notice they feed in the values as *speed->clk=x 000 (converts to mhz). We don't have a clock-21553.c in that manner.
Rather we have this.
long bcm21553_uart_find_m_n(unsigned long freq_val, long *m_set, long *n_set)
{
long factor = 0; /* = m/n */
long eq_2_val = MAX_UART_M_VAL + MAX_UART_N_VAL;
long n_val = 0;
long long n_iter = 0;
long long m_iter = 0;
long long left = 0;
long long right = 0;
long long diff = 0;
long long least_diff = 0;
long long least_diff_m_iter = 1;
long long least_diff_n_iter = 1;
long long val = 0;
long ret_val;
/* Formula : Freq = (156MHz * n) / m. */
if (freq_val > FREQ_MHZ(156)) { /* Can't have freq greater than 156MHz. */
return -EINVAL;
} else if (freq_val == FREQ_MHZ(156)) {
*m_set = *n_set = 1;
return FREQ_MHZ(156);
}
*m_set = 0;
*n_set = 0;
factor = FREQ_MHZ(156) / freq_val;
/* range of m : 0 <= m <= 0x1ff */
/* range of n : 0 <= n <= 0x1ff */
/* Equation 1 : factor = m /n. */
/* so m = (factor * n). */
/* Equation 2 : m + n <= 0x1ff + 0x1ff. */
/* m + n <= (2 * 0x1ff) ; Let's call (2 * 0x1ff) as eq_2_val. */
/* so m + n <= eq_2_val. */
/* Substiture eq1 in eq2. */
/* (factor * n) + n <= eq_2_val. */
/* taking n common : */
/* (factor + 1) * n <= eq_2_val. */
/* so n <= eq_2_val / (factor + 1). <==== This is a very important conclusion. */
/* Now the logic is to iterate(iter) till n, and
* find a value of m, where m = 156MHz * iter / val. */
n_val = eq_2_val / (factor + 1);
pr_info("n_val = %ld, eq_2_val = %ld, factor = %ld\n", n_val, eq_2_val,
factor);
n_iter = 0;
diff = 1;
least_diff = 0xffffffff;
val = freq_val;
while ((n_iter <= n_val) && (diff != 0)) {
n_iter++;
left = FREQ_MHZ(156) * n_iter;
m_iter = 0;
while ((m_iter <= MAX_UART_M_VAL) && (diff != 0)) {
m_iter++;
right = val * m_iter;
/* Always left side must be greater than right. So diff has to be positive. */
diff = left - right;
if ((diff > 0) && (diff < least_diff)) {
least_diff = diff;
least_diff_m_iter = m_iter;
least_diff_n_iter = n_iter;
}
/* pr_info("n_iter = %lld, m_iter = %lld, left = %lld, \
right = %lld, diff = %lld, least_diff = %lld, \
least_diff_m_iter = %lld, \
least_diff_n_iter = %lld\n",
n_iter, m_iter, left, right, diff, least_diff,
least_diff_m_iter, least_diff_n_iter); */
}
}
/* if diff == 0, it means we found a perfect, m, and n value. */
if (diff == 0) {
/* pr_info("We found the correct, m, n values. \
m = %lld, n= %lld\n", m_iter, n_iter); */
*m_set = m_iter;
*n_set = n_iter;
return val;
} else {
/* This means we didn't find a good m,n value. */
*m_set = least_diff_m_iter;
*n_set = least_diff_n_iter;
ret_val = (((FREQ_MHZ(156) / *m_set)) * *n_set);
/* pr_info("Didn't find a perfect m, n value, but will given \
the nearest possible value. m = %lld, n = %lld, \
freq = %ld\n", least_diff_m_iter,
least_diff_n_iter, ret_val) ; */
return ret_val;
}
}
NO SPAMMING IN THIS THREAD.
Stakes were high, time was taken but finally the work is completed, goal achieved.
Now might be a good time to say that we are a COMMUNITY, we help each other to make one device better.
Also could be a good time to take a new initiative, to take up something new as a project.
Reserved.
Trying something new and good.
Uhm maybe you should put that part in code.
Only reported programmers will be considered in the team.
REAL PROGRAMMERS WHO WANT TO JOIN, please post here and do not pm me.
By far the team is :
Master_Key
Mohamed.Anwar
hell_lock
ZakooZ
......
------R-------E------S-----E-----R------V------E------D-------P-----O---S---T------------B---Y--------S-----H-------A--------N--------E
bY
ShAnE
Looks promising
While I do know a decent bit about programming I don't know much about how CPUs work if you know what I mean
But I'll try to have a look at that
Re: [DEV] {WIP} Overclock device! Need a team to work.
Im in.
Sent from my GT-S5360 using XDA
hell_lock said:
Im in.
Sent from my GT-S5360 using XDA
Click to expand...
Click to collapse
+me
---------- Post added at 05:17 PM ---------- Previous post was at 04:34 PM ----------
What I got so far is
factor => 1
FREQ_MHZ(156)*n_iter - (val*m_iter) == 0
n_val => 255.5
am I correct ?
Btw : we need better format of these codes sometimes I get lost
Mohamed.Anwar said:
+me
---------- Post added at 05:17 PM ---------- Previous post was at 04:34 PM ----------
What I got so far is
factor => 1
FREQ_MHZ(156)*n_iter - (val*m_iter) == 0
n_val => 255.5
am I correct ?
Btw : we need better format of these codes sometimes I get lost
Click to expand...
Click to collapse
n_val for FREQ_MHZ(156) is (2*eq_2_val)/(m/n+1) = (2*0x1ff)/(1/1+1) = 0x1ff = 511
You can find proper highlighting and formatting here
How does the frequency translate to the real world freq? I'm assuming FREQ_MHZ(156) is either 832mhz or 1248mhz...
Somewhat interestingly, 0x1ff is 11111111 in binary... So wouldn't any number & 0x1ff equal the number?
Edit: Seems like it's made to return the first byte of a (4-byte) int... I think
Tested and it returns the last byte in little endian ordering
ZakooZ said:
n_val for FREQ_MHZ(156) is (2*eq_2_val)/(m/n+1) = (2*0x1ff)/(1/1+1) = 0x1ff = 511
You can find proper highlighting and formatting here
How does the frequency translate to the real world freq? I'm assuming FREQ_MHZ(156) is either 832mhz or 1248mhz...
Somewhat interestingly, 0x1ff is 11111111 in binary... So wouldn't any number & 0x1ff equal the number?
Edit: Seems like it's made to return the first byte of a (4-byte) int... I think
Tested and it returns the last byte in little endian ordering
Click to expand...
Click to collapse
Sorry forgot the 2 in 2*0x1ff
Anyway... changing the val and ret_val would be useless... As only n and m are put in memory
regVal = (u32) n_set & 0x1FF;
writel(regVal, ADDR_CLKPWR_CLK_UARTB_N);
regVal = (u32) m_set & 0x1FF;
writel(regVal, ADDR_CLKPWR_CLK_UARTB_M);
^ either first of last byte of the n and m values are put in memory. (Don't know the difference between UART A B and C)
Seems like ret_val returns the closest possible frequency if the m and n values aren't "good"
What we need to change is n and m... And apparently the highest they can be is 1
Need to know what calls bcm21553_uart_set_rate() and what "val" values it uses... Supposedly a modified value of the real (832mhz,etc) frequencies
Technically we could call it with FREQ_MHZ(156) and see what happens... but that's pretty dangerous
Re: [DEV] {WIP} Overclock device! Need a team to work.
ZakooZ said:
Anyway... changing the val and ret_val would be useless... As only n and m are put in memory
regVal = (u32) n_set & 0x1FF;
writel(regVal, ADDR_CLKPWR_CLK_UARTB_N);
regVal = (u32) m_set & 0x1FF;
writel(regVal, ADDR_CLKPWR_CLK_UARTB_M);
^ either first of last byte of the n and m values are put in memory. (Don't know the difference between UART A B and C)
Seems like ret_val returns the closest possible frequency if the m and n values aren't "good"
What we need to change is n and m... And apparently the highest they can be is 1
Need to know what calls bcm21553_uart_set_rate() and what "val" values it uses... Supposedly a modified value of the real (832mhz,etc) frequencies
Technically we could call it with FREQ_MHZ(156) and see what happens... but that's pretty dangerous
Click to expand...
Click to collapse
FREQ_MHZ(156) = exact 156 000 000 Hz. You can check it by putting it in the arm11_set_rate function. Instead of putting appspll*2/3 directly put FREQ_MHZ(832) and you'll get the same result.
Yeap. If exact match aren't found then ret val is used.
Most developers were thinking of adding 1024 mhz, this won't be a perfect n and m value.
To actually set the 1024 we need to get to know the iteration more.
Set rate uses the values from get rate. The arm 11 freq developers set till now was in some other static function which did not actually change the clock.
Sent from my GT-S5360 using xda app-developers app
I used this post to dump information I was getting and save it in somewhere that is not in the middle of thousands of lines of code... So It's a bit messy
I've been doing some searching and it looks like all thing referencing find_n_m() are only defined and never actually used to set any frequencies... So I don't know if that's the way to go... It may still use n and m values but calculated elsewhere
bcm21553_arm11_set_rate() and bcm21553_arm11_round_rate()
People have been using these for frequencies for a long time, it works for 156mhz and 624mhz which is interesting... Why wouldn't it work for freqs over 832mhz?
bcm21553_arm11_set_rate() imports a *clk pointer but never uses it... All it does is set the mode for the frequency with bcm215xx_set_armahb_mode()... I'm not discussing it now as im inspecting other parts
bcm21553_arm11_round_rate(clk *clk, long desired_val) also imports *clk but never uses it. It returns bcm21553_generic_round_rate(desired_val,arm11_freq,2);
I don't know where they get desired_val, but that's important for the return
arm11_freq is the frequencies developers defined
2 is the count of arm11_freq arrays... could use sizeof(arm11_freq)/sizeof(u32) i suppose
Code:
int bcm21553_arm11_set_rate(struct clk *clk, unsigned long val)
{
u32 mode;
u32 arm11_freq[2];
u32 apps_pll_freq = bcm21553_apps_pll_get_rate();
arm11_freq[0] = FREQ_MHZ(312);
arm11_freq[1] = (apps_pll_freq*2)/3;
/*we support only two modes - 0xC & 0xF*/
if (val == arm11_freq[0])
{
mode = 0x0C;
}
else if (val == arm11_freq[1])
{
mode = 0x0F;
} else
{
return -EINVAL;
}
//writel(mode, ADDR_CLKPWR_CLK_ARMAHB_MODE);
bcm215xx_set_armahb_mode(mode);
return 0;
}
long bcm21553_arm11_round_rate(struct clk *clk, unsigned long desired_val)
{
u32 arm11_freq[2];
u32 apps_pll_freq = bcm21553_apps_pll_get_rate();
/*we support only two freq - 312Mhz & appPll/1.5*/
arm11_freq[0] = FREQ_MHZ(312);
arm11_freq[1] = (apps_pll_freq*2)/3;
return (long)bcm21553_generic_round_rate(desired_val,
arm11_freq,
2);
}
Code:
u32 bcm21553_generic_round_rate(u32 desired_val, const u32 *supportedFreqList,
u8 count)
{
u32 i = 0;
const u32 *ppossible_freqs = supportedFreqList;
u32 closest_freq = 0xFFFFFFFF; /* Set it to some highest value. */
u32 greatest_freq_in_array = 0;
while (i < count) {
if (desired_val == *ppossible_freqs) {
return desired_val;
} else {
if ((*ppossible_freqs > desired_val)
&& (*ppossible_freqs <= closest_freq)) {
closest_freq = *ppossible_freqs;
}
if (*ppossible_freqs > greatest_freq_in_array) {
greatest_freq_in_array = *ppossible_freqs;
}
}
i++;
ppossible_freqs++;
}
/* This means that desired_val is greater than the maximum possible values */
if (closest_freq == 0xFFFFFFFF) {
/* This means the desired_val is greater than the greatest element */
/* So lets return with the greatest freq in array. */
return greatest_freq_in_array;
} else {
return closest_freq;
}
}
It seems that people are just giving a list of the supported frequencies, but those are not the desired frequency that this last function tries to search for... maybe it wont search for anything higher than 832mhz, it will always return something lower
Meanwhile arm11_set_rate doesn't seem to be connected to this at all, and arm11_round_rate seems to be returning the frequencies to some place that gives them a desired frequency
Anyway I can't seem to find any implementation of bcm215xx_set_armahb_mode(), only a "extern void bcm215xx_set_armahb_mode(u32 mode);" line Looks like it's implemented in Assembly! Fun! Either that is normal for low level stuff or broadcom wants to "encrypt" us out of how this works
I'll edit this post later because at the moment I don't feel like looking at this
Re: [DEV] {WIP} Overclock device! Need a team to work.
Yeap exactly!
There are values not used and there are values which we seem not to find.
The max n and m values have a different variable name which is defined at the start of file before any function is run.
It is somewhat
#Define variable name
This is used no where except this line where it is defined.
The set rate and get rate of arm 11 are just values which developer wants to get registered. The clock does not go above 832. If you use mode 0xD max value you get at 1248 is 832 mips. Mode 0xE 1248 set then 1248 mips. Mode 0xF 1248 set then 1665 mips.
I suppose the set rate only makes array and nothing else. To set above 832, theres still some part untouched.
Sent from my GT-S5360 using xda app-developers app
If you ctrl+F in /common, the only references to bcm21553_arm11_round_rate() and bcm21553_arm11_set_rate() are in clock-21553.c
How the f is that possible... They have to be called somewhere, even if it's just to get the fake rates
Re: [DEV] {WIP} Overclock device! Need a team to work.
Need testers for testing kernel.
Need a developer who can pack the z image I providE.
Any help would be appreciated.
Sent from my GT-S5360 using xda app-developers app
Re: [DEV] {WIP} Overclock device! Need a team to work.
Master_Key said:
Need testers for testing kernel.
Need a developer who can pack the z image I providE.
Any help would be appreciated.
Sent from my GT-S5360 using xda app-developers app
Click to expand...
Click to collapse
Contact hell_lock
I can test it
Sent from my GT-S5360 using xda premium
Re: [DEV] {WIP} Overclock device! Need a team to work.
I can test it...
Sent from my GT-S5360 using xda app-developers app
hears like a nice projekt,i test too when needet.
Master_Key said:
Need testers for testing kernel.
Need a developer who can pack the z image I providE.
Any help would be appreciated.
Sent from my GT-S5360 using xda app-developers app
Click to expand...
Click to collapse
I can pack it
Hi folks,
i did a little research these days and tried to sort out,
what in fact is missing to make HDMI/MHL work in AOSP based ROMs for the S3 series.
It is really hard to find some useful stuff about it.
All i noticed were some ancient posts about attaching MHL cable causing reboots.
Everyone keeps repeating MHL will not work on AOSP.
I know that HDMI/MHL is weird stuff and reference manual for MHL transceiver SII9244 is not available.
On the other hand this chip is only working as a phy and should be set up correctly at kernel level.
I also know that there'd been many attempts to make it work but i am to dumb to find some reference to tech talks about it.
So it really seems that most parts are implemented and ready to be put together.
At least that's the way it seems to me... and might be bit noobish of course.
Anyway i found something, which might be another key to solve this issue.
Some snippets from the sources at kernel level.
mach-midas.c:
Code:
#ifdef CONFIG_SAMSUNG_MHL
/* I2C15 */
static struct i2c_gpio_platform_data gpio_i2c_data15 = {
.sda_pin = GPIO_MHL_SDA_1_8V, /* GPB2, I2C5_SDA */
.scl_pin = GPIO_MHL_SCL_1_8V, /* GPB3, I2C5_SCL */
.udelay = 3,
.timeout = 0,
};
struct platform_device s3c_device_i2c15 = {
.name = "i2c-gpio",
.id = 15,
.dev = {
.platform_data = &gpio_i2c_data15,
}
};
static struct i2c_board_info i2c_devs15_emul[] __initdata = {
};
/* I2C16 */
#if !defined(CONFIG_MACH_T0) && !defined(CONFIG_MACH_M3) \
&& !defined(CONFIG_MACH_GD2)
static struct i2c_gpio_platform_data gpio_i2c_data16 = {
.sda_pin = GPIO_MHL_DSDA_2_8V,
.scl_pin = GPIO_MHL_DSCL_2_8V,
};
struct platform_device s3c_device_i2c16 = {
.name = "i2c-gpio",
.id = 16,
.dev.platform_data = &gpio_i2c_data16,
};
#endif /* !defined(CONFIG_MACH_T0) */
static struct i2c_board_info i2c_devs16_emul[] __initdata = {
};
#endif
midas-mhl.c:
Code:
static int __init midas_mhl_init(void)
{
int ret;
#define I2C_BUS_ID_MHL 15
ret = i2c_add_devices(I2C_BUS_ID_MHL, i2c_devs_sii9234,
ARRAY_SIZE(i2c_devs_sii9234));
if (ret < 0) {
printk(KERN_ERR "[MHL] adding i2c fail - nodevice\n");
return -ENODEV;
}
#if defined(CONFIG_MACH_T0_EUR_OPEN) || defined(CONFIG_MACH_T0_CHN_OPEN)
sii9234_pdata.ddc_i2c_num = 6;
#elif defined(CONFIG_MACH_P4NOTE) || defined(CONFIG_MACH_SP7160LTE) || defined(CONFIG_MACH_T0) \
|| defined(CONFIG_MACH_KONA) || defined(CONFIG_MACH_TAB3) || \
defined(CONFIG_MACH_GD2) || defined(CONFIG_MACH_GC2PD)
sii9234_pdata.ddc_i2c_num = 5;
#else
sii9234_pdata.ddc_i2c_num = (system_rev == 3 ? 16 : 5);
#endif
#ifdef CONFIG_MACH_SLP_PQ_LTE
sii9234_pdata.ddc_i2c_num = 16;
#endif
ret = i2c_add_devices(sii9234_pdata.ddc_i2c_num, &i2c_dev_hdmi_ddc, 1);
if (ret < 0) {
printk(KERN_ERR "[MHL] adding ddc fail - nodevice\n");
return -ENODEV;
}
return 0;
}
This could be found in the AOSP source trees of the Android hal:
https://github.com/omnirom/android_...ynos4/hal/libhdmi/libsForhdmi/libddc/libddc.c
Code:
/**
* @brief DDC device name.
* User should change this.
*/
#ifdef DDC_CH_I2C_1
#define DEV_NAME "/dev/i2c-1"
#endif
#ifdef DDC_CH_I2C_2
#define DEV_NAME "/dev/i2c-2"
#endif
#ifdef DDC_CH_I2C_7
#define DEV_NAME "/dev/i2c-7"
#endif
So i really wonder if someone ever tried to add device "i2c-15" here and compile.
See the implementation for odroid-u3 here as well (which is the base for NamelessROM):
https://github.com/codewalkerster/android_hardware_samsung_slsi_exynos4
Additionally this should be added to the S3 BoardConfig.mk then:
Code:
BOARD_USES_HDMI_SUBTITLES := true
BOARD_USES_HDMI := true
BOARD_HDMI_STD := STD_720P
BOARD_HDMI_DDC_CH := DDC_CH_I2C_15
BOARD_USES_FIMGAPI := true
Please leave some comments and help me to understand what in fact is missing to watch TV with AOSP ROMs :angel:
Regards,
scholbert
That'd be awesome thing having HDMI/MHL out in AOSP. That's the main reason why I'm using stock rom. @codeworkx is the guy you need to talk to but he's no longer in the cyanogenmod team.
Hi [email protected],
thanks for your reply!
I'll try to contact codeworkx, though it seems he had not only left CM team but XDA-devs as well.
[email protected] said:
That'd be awesome thing having HDMI/MHL out in AOSP. That's the main reason why I'm using stock rom. @codeworkx is the guy you need to talk to but he's no longer in the cyanogenmod team.
Click to expand...
Click to collapse
Anyway, i know that there are many parts of code involved to make the MHL interface work, so the main part for me is to know about the missing link.
I guess i'll try to get a better understanding about the kernel side the next days, as there are:
- do we have all parts to map the virtual I2C port for SII9244
- does the initialization of the SII9244 look complete
- what's the state of the HPD GPIO
Next would be of course, to understand how the interaction of framebuffer mapping takes place.
There's the GPU MALI stuff which uses parts of RAM and some framebuffer as well
The internal HDMI logic of Exynos needs some mapping of course to get access to this memory.
This could be the most complex part and maybe this information is missing or done by proprietary stuff...
Let's see if we could get more detailed information about it in the next weeks.
So please help out with useful comments
Best regards,
scholbert
You can find him in the BBQlinux IRC channel. He's the developer of that distro.
Hi there,
again thanks for the reply so far.
I did some further research on this issue on my own....
- Yes, there are proprietary files which handle HDMI (TVOUT) in stock ROMs
- Yes, these libs and services do not seem to match the AOSP implementation
After some investigation on the proprietary files and searching for some ASCII snippets in the binaries, it seems that at least some parts, or better call it functionality, is covered in the HAL present in the AOSP source tree, which had been released for the SMDK4412.
My guessing is that the "framework" is little different in these sources and some of the libraries of the AOSP version have other names, if we manage to compile them.
I still wonder, if someone did ever try to set all necessary compile flags for HDMI and give it a try with the settings i posted in my first thread. So i guess i'll have to do it...
Maybe it's all nonsense and the sources of Exynos HAL which are used by the AOSP ROMs are completely unusable, if it comes to HDMI implementation.
On the other hand there's Hardkernel's odroid platform which has a working HDMI port.
So what's the secret here?
Cheers,
scholbert
@pulser_g2 here please
Seems there is already something on its way
https://gerrit.nameless-rom.org/#/c/13927/
Gesendet von meinem GT-N7105 mit Tapatalk
Hi DerTeufel1980,
thanks for pointing to this patchset... i've already seen some other related patches some days ago.
Looks promising and hopefully this time these hacks will be successful!
Though i'm not sure about the management of the i2c ports at kernel level or maybe i just don't understand its mapping.
While it is correct that the MHL PHY is connected to the physical interface i2c-5 (the pins), it seems that the kernel uses some virtualisation based on the devices address connected to this port...
AFAIK Exynos 4412 got five physical I2C ports, which are used by a variety of physical devices (the real chips).
Each physical device should have a unique i2c address to get addressed by the CPU.
In the end we got multiple chips with different addresses connected to the physical ports which are presented as virtual device starting from i2c-0 up to i2c-21.
So if i interpret the sources correctly, the device id for DDC function should be i2c-15 at userland, or better spoken: Android world.
But as already stated maybe i'm wrong here...
Time will show
Thanks for contributing!!
EDIT:
Just contacted one of the hard working developers at Nameless ROM and he pointed me to another more frustrating issue, which is the missing source code for HWC.
See this information (which is quite old, but you need to find it ) which covers the Exynos CPU's in general:
https://plus.google.com/+AndrewDodd/posts/DHg5z62CHHu
So this snippet says it all:
Edit - HDMI
Insignal's latest reference source has new HDMI code. However, it's tightly integrated with HWC. As covered above, HWC is totally broken in their source release. No HWC, no HDMI.
Click to expand...
Click to collapse
EDIT2:
Some more tech talk to understand the flaw:
https://jira.cyanogenmod.org/browse/ESDB-1
Cheers,
scholbert
Hey there... it's me again
I thought about missing source code and how all stuff get's arranged in the variety of ROM's.
Especially MALI, HWC and proprietary stuff...
Quite irritating though because i'm no hardcore software developer :angel:
Anyway found this:
http://forum.xda-developers.com/showpost.php?p=55809089&postcount=1508
In other words, there is some HWC source code for exynos4.
Why was it dropped then and latest release of Nameless Lollipop ROM stepped back to the older MALI release?
This led to a more proprietary codebase.
I read about r4p0 would not be the best choice for mobile device or is there another reason
Please leave a comment, if you know more about it.
Would be nice to have some open discussion here anyway...
Have fun!
scholbert
The problem came with r4p0 when the proprietary HWC blob was made working with the kernel rebase from fni1 source drop of n7100. The amount of glitches occurring were too high, and the r4p0 drivers used in the device were blobs. There aren't any display related open source Hals for exynos to have a reference from and fix the graphics part having glitches.
As is already notable with chrome, GPU rasterization is broken and had even more issues with newer blobs, which actually even I'm not sure of why so. R3p2 drivers we use actually are based on a newer api as compared to r4p0 and as a result, the blobs are more updated than the r4p0 taken from the Odroid board.
̿ ̿̿’̿’\̵͇̿̿\з==(*͡° ͜ʖ ͡°)==ε/̵͇̿̿/’̿’̿ ̿ ̿̿*