Database Develop

Excel VB question: re: Arrays

Hey,
I am working on something for work and it has to do with a simple database (excel file) with data kept in rows. This data is accessed using a userform that looks up a query that happens to be the data kept in the first column of the spreadsheet. Basically, each row contains 46 cells, including the first cell (the query).
I am hoping to use the same userform to search, update, save, print and quit excel. So far search works:
Code:
Sub CommandButton1_Click()
dim query as range
set query = range("A:A")
call readData(query.find(TextBox1, lookat:=xlWhole).row)
End Sub
Private Sub readData(x as integer)
Dim boxes as range
set boxes = range("A:A")
TextBox1 = boxes.cells(x).offset(0,0)
TextBox2 = boxes.cells(x).offset(0,1)
....
End Sub
This works fine for search; however, as there is 45 boxes containing different kinds of data, I would rather read the cells from the spreadsheet using a loop and setting the TextBoxN as a static array:
Code:
Sub readData(x as integer)
***** VB treats array(45) as an array having 46 elements *****
dim textBoxArray(45) as [u]Variant[/u]
set textBoxArray = array(TextBox1, TextBox2... TextBox46)
For i = 1 to 46
textBoxArray(i-1) = cells(x, i)
Next i
End Sub
Note that "query.find(TextBox1, lookat:=xlWhole).row" returns the row number of the query and this is passed as an integer to the readData sub-routine and is referred to as "x".
I would like to do this for the read and then do the same, although opposite for the update (i guess I could call it the 'write' back to the excel worksheet).
The problem is, with this code I get an error that says the array is not declared or arranged (Japanese laptop: 配列は割り当てられません。)
Question 1
Any of you developers with any vb experience know how I can correctly declare my array (would be nice if I could decare the array globally so that I don't have to re-declare it for every sub-routine, and I can just use the for loop in each sub-routine)?
At present, all the code is within the userform and I cannot seem to declare outside of a subroutine:
Code:
Public boxArray(45) as Variant
Sub CommandButton_Click()
...
End Sub
Question 2 SOLVED I removed the "set" from the line where I filled the array with each textbox. Tested it again and all data is flowing correctly. Only need question 1 answered.
Thank you.

Hey all, thanks for the replies; I didn't think the thread would be this popular.
I solved the problem with global variables. Instead of setting a fixed array size in the main code section dec area, I found another way of assigning values to all 46 textboxes.
Instead of:
Code:
Dim boxArray(45) as Variant
boxArray(45) = array(TextBox1, TextBox2, ... TextBox46)
then
Code:
For i = 1 to 46
boxArray(i-1) = cells(x,i)
Next i
I used vb's Control method/function (no array necessary):
Code:
For i = 1 to 46
Control("TextBox" + CStr(i)) = cells(x,i)
Next i
So i turned 46+ lines into 6+ lines into 3 lines.
MODS, this thread may be closed. THanks.

!!Finally!! Fix for low Bluetooth Headset sound issue!!!

Hi there,
since i got my Kaiser i always had a problem with the low BT Volume. I tried many fixes from here but noone works for 100%.
The only lud roms were the PDA Corner ones.
So i made my own
Install the attached cab and restart your device. Then sound will be fine and loud.
If you use SRS Wow it won't work after installation, cause i had to change the drivers in registry.
@MODS: CAN WE MOVE THIS TO DEV/HACKING SECTION? CAUSE I THINK THIS COULD WORK FOR ALL DEVICES!!!

what exactly does this do (on your phone, what does it change, or is it a program always running?) and if it makes things worse is it uninstallable ? (since I see it's a cab).

Mr. Kayne said:
what exactly does this do (on your phone, what does it change, or is it a program always running?) and if it makes things worse is it uninstallable ? (since I see it's a cab).
Click to expand...
Click to collapse
The .cab file just contains registry settings and the file 'AudioPara3.csv'. As far as I can tell the 'AudioPara3.csv' is identical to the one already in my ROM (stock-ish 5.2.19212), however there are quite a few new registry entries that I can't see in my ROM
Code:
[HKEY_LOCAL_MACHINE\Software\Microsoft\Bluetooth\A2DP\Settings]
"SampleRate" = 48000
"BitPool" = 0
"UseJointStereo" = 0
[HKEY_LOCAL_MACHINE\Software\Microsoft\Bluetooth\AudioGateway]
"PowerSave" = 1
"ConnectHFOnCall" = 1
"Capability" = 101
"BTAGExtModule" = OEMAGW.dll
"SupportCLI" = 0
"BTAGPBModule" = \Windows\BthAGPhonebook.dll
"NoRoleSwitch" = 1
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\BtA2dpSnd]
"GainADC_LoudSpkMIC_12h" = 60
"OldDriver" =
"Dll" = bta2dp.dll
"SPKVol_NotPhoneCall_02h_06h" = 0
"SPKVol_PhoneCall_02h_06h" = 3
"HPVol_PhoneCall_04h" = 4
"GainADC_BluetoothMIC_12h" = 33
"GainADC_HeadsetMIC_12h" = 42
"GainADC_ReceiverMIC_12h" = 55
"3DEff" = 0
"MicGain" = 39
"AGC" = 0
"Treble" = 0
"Bass" = 0
"IClass" = {A32942B7-920C-486b-B0E6-92A702A99B35}
"Sysintr" = 25
"Flags" = 65538
"Index" = 8
"Order" = 8
"Prefix" = WAV
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\WaveDev]
"OldDriver" =
"Dll" = Wavedev.dll
"Flags" = 0
"IClass" = {A32942B7-920C-486b-B0E6-92A702A99B35}
"DACVol_0Ch" = 7
"SPKVol_NotPhoneCall_02h_06h" = 0
"SPKVol_PhoneCall_02h_06h" = 3
"HPVol_PhoneCall_04h" = 4
"GainADC_BluetoothMIC_12h" = 33
"GainADC_HeadsetMIC_12h" = 42
"GainADC_ReceiverMIC_12h" = 55
"3DEff" = 0
"MicGain" = 39
"AGC" = 0
"Treble" = 0
"Bass" = 0
"Sysintr" = 25
"Priority256" = 149
"Order" = 11
"Index" = 1
"Prefix" = WAV
Andy

The .cab file just contains registry settings and the file 'AudioPara3.csv'. As far as I can tell the 'AudioPara3.csv' is identical to the one already in my ROM (stock-ish 5.2.19212), however there are quite a few new registry entries that I can't see in my ROM
Code:
Click to expand...
Click to collapse
Yes thats right, the most of the cab are just reg keys, there is no app or similar that runs in background. The audiopara.csv is from an oldr att rom.
First i trie every fix around here on xda-developers, but no one of them worked properly. Then i mixed some of the together, and i noticed an improvement. Some days ago i got the csv file and replace it with the one in my actually rom and volume was very high. I checked this on several roms and for me it seems to work. Some of the reg keys don't do anything with the volume but they improve the sound quality over bluetooth.
Would be great if some of you could post their results.
Don't matter, i don't know if you can completly uninstall this, but there is no key or so that will make bt or so not work anymore.
Also it would be great if you could send my you audiopara.csv files and the reg keys of the rom you are usin (if it's loud), so i try to improve it more and more, or am i the only one with bad volume?
If anyone is using a pda corner rom at the moment, please send me the reg keys and the audiopara3.csv cause theese roms had the best sound quality and volume with bt.

well I tried it out and I guess my bluetooth is slightly louder. ( I checked it before and after)
No adverse effects.
Solace v1 (ROM version 3.29.707.0 WWE)
Radio 1.70.19.09
Windows Mobile 6.1 of course. Hope that helps in some way.

Thanks my brother,i'll test your cab.​

Hi Jecky
Thanks for this !!!!!!
To be honest, can't differentiate a "absolutely louder" feeling.
Can you tell us how to modify / what / which part to modify by ourselves to alter the volume up or down? Thanks.
My BTHS is Omiz2099, when matched to ELF is loud as hell. But when match to Asus P552w GalaxyMini2 is soft as hell.
Hence this is much appreciated. eventhough not feeling significantly, but Thanks still.

Did u changed the parameters of the sound variables to their maximum values in that registry tweak ????

BT headset micro_speaker volume change
BT headset's micro_speaker volume hasn't increased, but MIC pickup has, after I changed everything to "100".
I notice there isn't any BT heatset micro_speaker's volume control.
i.e. I suspect need "BTVol_PhoneCall_??h_??h" = ??
but I don't know how many h or whatever to use behind.
Anyone can shead of light?

Priority256 in WM6.5 (i.e. Touch)

I noticed that some people have set their touch priority to relatively high values, I am not sure if this is the intent, but lower values actually raise the priority (although if you go too low, bad things can happen).
Here is some info:
>>>>
The priority system has 256 Priority Levels numbered 0 (zero) through 255. Priority level 0 is the highest priority level. The original eight priority levels for Windows CE 2.12 are mapped to levels 248 through 255.
Applications and device drivers should use the CeGetThreadPriority and CeSetThreadPriority APIs, instead of the legacy APIs, GetThreadPriority and SetThreadPriority. The legacy APIs are still available with the same interfaces as before, but those APIs have access to only the original eight priority levels.
The priority level system is divided into four ranges. The following table shows these ranges.
Levels Description
0 through 96
Reserved for real-time above drivers.
97 through 152
Used by the default Windows Mobile device drivers.
153 through 247
Reserved for real-time below drivers.
248 through 255
Mapped to non-real-time priorities.
The following table shows the default priority levels that are associated with device drivers. You can override these values by changing the source code for the drivers or by setting values in the registry. The registry paths in the table assume that the root Drivers key is HKEY_LOCAL_MACHINE\Drivers\BuiltIn; the registry uses hexadecimal values for the priority levels.
Decimal priority Hexadecimal priority Device driver Override
99
0x63
Power Manager resume thread
HKEY_LOCAL_MACHINE\CurrentControlSet\Control\Power\ResumePriority256
100
0x64
USB Function
None
101, also uses +1 and -1 relative priorities
0x65, also uses +1 and -1 relative priorities
USB OHCD
HKEY_LOCAL_MACHINE\Drivers\BuiltIn\OHCI\Priority256
101, also uses +1, +3, +5 and +7 relative priorities
0x65, also uses +1, +3, +5, and +7 relative priorities
USB UHCD
HKEY_LOCAL_MACHINE\Drivers\BuiltIn\UHCI\Priority256
103
0x67
Serial
HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial\Priority256
105, also uses +1 and +2 relative priorities
0x69, also uses +1 and +2 relative priorities
PCMCIA
HKEY_LOCAL_MACHINE\Drivers\PCMCIA\Priority256
109
0x6D
Touch
HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Touch\Priority256
110, also uses +2 and +4 relative priorities
0x6E, also uses +2 and +4 relative priorities
IRSIR
HKEY_LOCAL_MACHINE\Comm\Irsir1\Parms\Priority256
116, also uses +2, +4, +6, +8, +10 and +12 relative priorities
0x74, also uses +2, +4, +6, +8, +10, and +12 relative priorities
NDIS
HKEY_LOCAL_MACHINE\Drivers\BuiltIn\NDIS\Priority256
131
0x83
KITL
Override in the OEM Application Layer
. In OEMInit, set g_dwKITLThreadPriority (extern DWORD) to the desired priority before calling KitlInit.
131
0x83
VMINI
HKEY_LOCAL_MACHINE\Comm\VMini\Priority256
132
0x84
CxPort
HKEY_LOCAL_MACHINE\Comm\Cxport\Priority256
145
0x91
PS/2 Keyboard
HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\KEYBD\Priority256
148
0x94
IR Comm
HKEY_LOCAL_MACHINE\Drivers\BuiltIn\IrComm\Priority256
150
0x96
TAPI (Unimodem)
HKEY_LOCAL_MACHINE\Drivers\Unimodem\Priority256
210
0xD2
WaveDev
HKEY_LOCAL_MACHINE\Drivers\BuiltIn\WaveDev\Priority256
248
0xF8
PM (Power Manager)
HKEY_LOCAL_MACHINE\CurrentControlSet\Control\Power\Priority256
249
0xF9
PS/2 Mouse
HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\MOUSE\Priority256
249
0xF9
Power Manager device registration thread
HKEY_LOCAL_MACHINE\CurrentControlSet\Control\Power\PnPPriority256
249
0xF9
Power Manager system management thread
HKEY_LOCAL_MACHINE\CurrentControlSet\Control\Power\SystemPriority256
249
0xF9
Power Manager activity timer thread
HKEY_LOCAL_MACHINE\CurrentControlSet\Control\Power\TimerPriority256
250
0xFA
WaveAPI
HKEY_LOCAL_MACHINE\Drivers\BuiltIn\WAPIMAN\Priority256
251
0xFB
Power Manager battery monitor thread
HKEY_LOCAL_MACHINE\CurrentControlSet\Control\Power\PowerPollPriority256
Remarks
Threads in Normal (as apposed to Privileged) applications can use thread priorities 248 through 255.
Threads in Privileged applications can use any thread priority.

[TUT] Build.prop Modifications how to !

Hello all from research and test o my rom dev discovered this and want share it with all can help ^^
The following lines in the build.prop file can be added and edited to change several properties in your device:
debug.sf.hw = 1
Render UI with GPU (relieves pressure on CPU)
dalvik.vm.heapsize = 32m
Set size of Dalvik VM heap (how much RAM each instance of the VM is allowed); depending on how much RAM that is available to a device, this can be increased.
persist.adb.notify = 0
Stop debugging icon from appearing in status bar
windowsmgr.max_events_per_sec = 120
Increase to improve scrolling response
persist.sys.use_dithering = 0
Do not use surface dithering (surface dithering improves image quality)
debug.sf.nobootanimation = 1
Disable boot animation
ro.HOME_APP_ADJ = 1
force home launcher into memory
ro.sf.lcd_density = 240
Set screen density; change according to your device or what suits you, a lower value will display more but may be too small to use on a device with a smaller screen. Also note that changing the pixel density will make some applications in the new market ‘incompatible with your device’.
mot.proximity.delay = 150
Lower to fix black screen after calls issue
ro.telephony.call_ring.delay = 0
Decrease dialling out delay
ro.gsm.2nd_data_retry_config = max/_retries=3, 2000, 2000, 2000
Change MMS APN retry timer from 5s to 2s
wifi.supplicant_scan_interval = 120
ro.ril.disable.power.collapse = 0
pm.sleep_mode = 1
Increase battery saving potential
ro.com.android.dataroaming=true
Enables data-roaming by default in the build
ro.com.android.dateformat=dd-MM-yyyy
Changes default date format to day-month-year
ro.config.alarm_alert=*.ogg
ro.config.ringtone=*.ogg
ro.config.notification_sound=*.ogg
Changes the default sounds for each item. Must correlate to ogg files available in /system/media/audio/
ro.build.display.id=NAMEOFROM
In Settings>About Phone, it lists the name of the build number. This is where you set it.
ro.product.locale.language=en
ro.product.locale.region=GB
Sets the default region and language. You must have the correct letter combo, and the language must be available for this to work.
video.accelerate.hw=1 or 0
Whether to use hardware acceleration to render videos, doesn’t work on all devices​

Some of those lines are missing from my build.prop. Can I place them anywhere in my build.prop or not?

jayrome876 said:
Some of those lines are missing from my build.prop. Can I place them anywhere in my build.prop or not?
Click to expand...
Click to collapse
yes after all line add thos you want

[R&D][MOD]Nexus S Color Correction

This started out as an idea I had while trying to calibrate the screen color of my Nexus S using a colorimeter. While a lot of users are not particularly picky about colors, I do hope quite a number of people would also be interested in this. To give a clearer understanding for all, I'll put in a not-so-short introduction.
As most of us would know, AMOLED screens, while good in terms of brightness and contrast, tend to distort colors. If you're viewing an image on an AMOLED screen, you'll likely notice areas which appear oversaturated and have blown-out details. The reason behind this is that our AMOLED screens have a much wider gamut (i.e. displays more colors) than how images are encoded. If you look at the image below, the bigger triangle represents the set of colors that the AMOLED screen can display. The smaller triangle is the sRGB reference color which is how Android and most images are encoded.
​
Unfortunately for us, the Android OS isn't aware of this difference. A color with value of #00FF00 (pure green) should look like the green at the upper peak of the smaller triangle. But in reality, it is shown to us as the green of the larger triangle. This remapping between the two color spaces causes lighter shades of color to appear darker (or actually more saturated).
So far, the solution to fixing the problem is through the use of voodoo color (cheers to supercurio). Voodoo allows for the modification of gamma which somehow compensates for the saturation levels of the colors. Also, color multipliers allow for the shifting of the white point. White point, you ask? See, the intersection of the dotted lines? That is the white point which is how white would appear on the screen. Some like warm colors (white points to the right) while cool colors are to the left. However, gamma and multipliers only operate on a single color at a time. This means that the larger triangle will always remain the same shape regardless of the settings we use. Colors would look better but still not the same as the original intent.
So what can we do about it? Well one way would be by analyzing the way in which colors are mapped to a visually-oriented reference (such as the xyY/XYZ space shown in the above image). A standard sRGB image would be mapped using:
​
While the Nexus S (using the marmite kernel by bedalus with equal multipliers) would map out like:
​
In effect, you can find a map to convert the intended sRGB colors to the values usable by the screen to simulate the original rendering intent of the colors. This is done by using the following relationship:
​
Note that the other non-labelled matrix here is simply a way to shift the white point from 6500K (warm) to 9300K (cool) to display good colors on our devices using chromatic adaptation. The end effect is a means to fix color by simply mixing together red, green, and blue values (after gamma correction to be strictly accurate but this has its tolerances). The mix is just as shown above or in a more non-scientific notation:
Code:
R = 0.7043 * R + 0.3440 * B - 0.0028 * B
G = 0.0160 * R + 0.8930 * G + 0.0598 * B
B = 0.0195 * R + 0.0846 * G + 1.1185 * B
As an example, I've uploaded a before-and-after comparison of a test image. On a computer display, the right image (modified) would appear weird compared to the left image but if you load it up (or just view it) on your phone, you can see that the right one actually looks better (no oversaturation). This would be better if you have voodoo color with the multipliers set to more or less equal values.
​
The task then is to implement this on a kernel level (or similar) which I will touch on my next post (maybe tomorrow). Note that I have not successfully done the modifications as I lack the development skillz to match. In this regard, I would like to solicit the assitance of the dev community with a much wider experience with these things than I do.

So I decided to continue writing this today...
Unlike the voodoo color codes which rely on hardware (TL2796 AMOLED driver) to implement gamma correction, the color mixing process is a bit more involved on the software end. There are no chips on the Nexus S which can be configured to perform the mixing process natively. Instead, I have a few ideas on the implementation of the mixing process.
1. Rewrite the framebuffer
I've attempted doing this using native code by opening the /dev/graphics/fb0 device but the problem lies in timing. If the timing is off, the mixing either never occurs or is repeated several times for a given frame causing color distortions. This is further complicated by the use of double buffering on the device. Even more so with the switching behavior between double and triple buffering in JB! I've tried hijacking the VSYNC signal to operate on the timing (see colormix.c attached) but the result is still very glitchy. Or I may be doing it wrong...
2. Handle all routines that write to the framebuffer
Another way would be to handle all the writes to the framebuffer device. This eliminates the need for timing as processing occurs only once as the data is transferred to the framebuffer. I've seen the codes for cfbcopyarea.c, cfbimgblit.c, and cfbfillrect.c but I'm not sure where direct writes to the framebuffer (using mmap access) are handled (if at all handled). So again, I'm not too sure about this one.
3. Hijack the interface from the LCD driver
Yet another unsure idea by the way. Since the LCD driver interact with the physical hardware through 24 GPIO pins, there should be some code describing how data is transferred to these pins. At that level, it might be possible to manipulate the signal just before it is sent to avoid timing issues mentioned earlier.
Most of these ideas are speculative from a person who is not really that deep into development (I'm more of an image processing researcher ). Any feedback and ideas from the community would be great!

I'm down with matrices. Sign me up!

some good ideas here, if you manage to calibrate our screens without using voodoo, this idea can potentially be used on other amoled devices such as s3 to calibrate it, removing it's over-saturation

bedalus said:
I'm down with matrices. Sign me up!
Click to expand...
Click to collapse
LOL. Matrices are fun! Thanks bedalus!
By the way, I took a look at the driver codes and it may be possible to find the next framebuffer using ioctl (from an external program).
Code:
case S3CFB_GET_CURR_FB_INFO:
next_fb_info.phy_start_addr = fix->smem_start;
next_fb_info.xres = var->xres;
next_fb_info.yres = var->yres;
next_fb_info.xres_virtual = var->xres_virtual;
next_fb_info.yres_virtual = var->yres_virtual;
next_fb_info.xoffset = var->xoffset;
next_fb_info.yoffset = var->yoffset;
next_fb_info.lcd_offset_x = 0;
next_fb_info.lcd_offset_y = 0;
if (copy_to_user((void *)arg,
(struct s3cfb_next_info *) &next_fb_info,
sizeof(struct s3cfb_next_info)))
return -EFAULT;
break;
Invoking this should at least resolve the double buffering issues if timed correctly with VSYNC. Again, IF.
noobiekins said:
some good ideas here, if you manage to calibrate our screens without using voodoo, this idea can potentially be used on other amoled devices such as s3 to calibrate it, removing it's over-saturation
Click to expand...
Click to collapse
Yes actually. You just need colorimeter readings of the locations of the red, green, and blue primaries to build the matrix for any other device and compensate for it.

So based on my last post I tried looking at the behavior of the framebuffer device. It seems that there are a few parameters which are being used by the device namely:
xres/yres - dimensions of the visible image in pixels
xres_virtual/yres_virtual - dimensions of the virtual image in pixels
xoffset/yoffset - position in the framebuffer being used
Click to expand...
Click to collapse
Dumping from a test program, I get one of two sets of values from the framebuffer device:
Code:
Start address: 4debf000
Visible resolution: 480, 800
Virtual resolution: 480, 5600
Offsets: 0, 800
Start address: 4debf000
Visible resolution: 480, 800
Virtual resolution: 480, 5600
Offsets: 0, 0
This more or less tells us that the framebuffer memory is actually divided into multiple buffers each with the visible size (480x800) of the display. They alternate (using the offsets) to provide the double buffering effect Android uses. However, what I can't understand is why there are 7 buffers allocated for the device instead of at most 3 (for triple buffering). It might be useful to take snapshots of the entire framebuffer and write them to consecutive bitmaps but I won't bother with that at the moment.
I've also tried using this behavior to synchronize the framebuffer writes using changes in the offset as a trigger:
Code:
for (;;)
{
do
{
// Extract variable framebuffer information
if(ioctl(fd, FBIOGET_VSCREENINFO, &next_vi) < 0)
{
perror("Cannot extract variable framebuffer information");
return -1;
}
} while (next_vi.yoffset == cur_vi.yoffset);
...
<insert color mixing here>
...
}
Unfortunately, the screen still doesn't update as desired. Lots of flickering involved. I'm not sure if the memory accesses are just too slow such that the screen refreshes before we completely rewrite the framebuffer or if its some other problem. I've attached the full code for anyone who might be able to shed some light on this. In this code, I just did a dummy rewrite (red = green, blue = green) instead of color mixing to avoid computation therefore minimizing CPU loading and to have a more pronounced effect on the screen.

I'm clueless about video, but I'm digging around... These are the files that compile in /drivers/video/
Code:
/home/dave/android/androidkernel/drivers/video/backlight/lcd.o
/home/dave/android/androidkernel/drivers/video/backlight/backlight.o
/home/dave/android/androidkernel/drivers/video/backlight/built-in.o
/home/dave/android/androidkernel/drivers/video/fb_notify.o
/home/dave/android/androidkernel/drivers/video/display/built-in.o
/home/dave/android/androidkernel/drivers/video/fb.o
/home/dave/android/androidkernel/drivers/video/fbsysfs.o
/home/dave/android/androidkernel/drivers/video/samsung/s3cfb.o
/home/dave/android/androidkernel/drivers/video/samsung/s3cfb_nt35580.o
/home/dave/android/androidkernel/drivers/video/samsung/s3cfb_tl2796.o
/home/dave/android/androidkernel/drivers/video/samsung/s3cfb_fimd6x.o
/home/dave/android/androidkernel/drivers/video/samsung/built-in.o
/home/dave/android/androidkernel/drivers/video/cfbimgblt.o
/home/dave/android/androidkernel/drivers/video/fbmem.o
/home/dave/android/androidkernel/drivers/video/modedb.o
/home/dave/android/androidkernel/drivers/video/cfbcopyarea.o
/home/dave/android/androidkernel/drivers/video/fbcmap.o
/home/dave/android/androidkernel/drivers/video/omap2/displays/built-in.o
/home/dave/android/androidkernel/drivers/video/omap2/built-in.o
/home/dave/android/androidkernel/drivers/video/built-in.o
/home/dave/android/androidkernel/drivers/video/fbcvt.o
/home/dave/android/androidkernel/drivers/video/cfbfillrect.o
/home/dave/android/androidkernel/drivers/video/fbmon.o
I'm combing through these files now to see if there's any obvious points to hack in.

bedalus said:
I'm clueless about video, but I'm digging around... These are the files that compile in /drivers/video/
Code:
/home/dave/android/androidkernel/drivers/video/backlight/lcd.o
/home/dave/android/androidkernel/drivers/video/backlight/backlight.o
/home/dave/android/androidkernel/drivers/video/backlight/built-in.o
/home/dave/android/androidkernel/drivers/video/fb_notify.o
/home/dave/android/androidkernel/drivers/video/display/built-in.o
/home/dave/android/androidkernel/drivers/video/fb.o
/home/dave/android/androidkernel/drivers/video/fbsysfs.o
/home/dave/android/androidkernel/drivers/video/samsung/s3cfb.o
/home/dave/android/androidkernel/drivers/video/samsung/s3cfb_nt35580.o
/home/dave/android/androidkernel/drivers/video/samsung/s3cfb_tl2796.o
/home/dave/android/androidkernel/drivers/video/samsung/s3cfb_fimd6x.o
/home/dave/android/androidkernel/drivers/video/samsung/built-in.o
/home/dave/android/androidkernel/drivers/video/cfbimgblt.o
/home/dave/android/androidkernel/drivers/video/fbmem.o
/home/dave/android/androidkernel/drivers/video/modedb.o
/home/dave/android/androidkernel/drivers/video/cfbcopyarea.o
/home/dave/android/androidkernel/drivers/video/fbcmap.o
/home/dave/android/androidkernel/drivers/video/omap2/displays/built-in.o
/home/dave/android/androidkernel/drivers/video/omap2/built-in.o
/home/dave/android/androidkernel/drivers/video/built-in.o
/home/dave/android/androidkernel/drivers/video/fbcvt.o
/home/dave/android/androidkernel/drivers/video/cfbfillrect.o
/home/dave/android/androidkernel/drivers/video/fbmon.o
I'm combing through these files now to see if there's any obvious points to hack in.
Click to expand...
Click to collapse
Great! And here I was having trouble figuring out which files were actually being used...
I'm not sure about other types of hacks but if we're talking about framebuffer rewriting (like what I've been trying to do), the following segment in s3cfb.c may be useful:
Code:
static irqreturn_t s3cfb_irq_frame(int irq, void *data)
{
struct s3cfb_global *fbdev = (struct s3cfb_global *)data;
s3cfb_clear_interrupt(fbdev);
fbdev->vsync_timestamp = ktime_get();
wmb();
wake_up_interruptible(&fbdev->vsync_wq);
return IRQ_HANDLED;
}
Assuming the system interrupt for VSYNC is enabled (which I assume to be the case otherwise the Choreographer API of JB shouldn't work), then maybe a hack there could be done to process the framebuffer just in time with the frame refresh. This is of course under the assumption that the rewrite is fast enough. I'll try sorting through those files as well to see if there's some easier hack.

Couldn't you pre-process the data before it gets to the fb? It sounds like you want to read it and rewrite it. Did i understand correctly?

bedalus said:
Couldn't you pre-process the data before it gets to the fb? It sounds like you want to read it and rewrite it. Did i understand correctly?
Click to expand...
Click to collapse
Yep, you got it right. Right now, I'm trying to read and re-write but as you said, ideally it should be pre-processed before it even arrives at the framebuffer. I'm not sure if its possible though. Applications can access the framebuffer by mmap-ing it onto shared memory which they can write directly to. I've found functions for fb_write and fb_mmap (both in fbmem.c) but I'm not sure if they're being used internally by the kernel to handle mmap and write requests. I have too little knowledge of kernel processes to know for sure.

fb_write looks fully internal to me.
It looks like the OS is given access in drivers/video/fbsysfs.c

bedalus said:
fb_write looks fully internal to me.
It looks like the OS is given access in drivers/video/fbsysfs.c
Click to expand...
Click to collapse
I'm not quite sure what you mean by internal. Does that mean that if we modify it, we can change how all data is written to the framebuffer?
As for fbsysfs.c, I can see how the OS writes the variable information pertaining to the framebuffer. However, I can't seem to find any reference to the actual data being written to the framebuffer. Did I miss something?

nightsky87 said:
I'm not quite sure what you mean by internal. Does that mean that if we modify it, we can change how all data is written to the framebuffer?
As for fbsysfs.c, I can see how the OS writes the variable information pertaining to the framebuffer. However, I can't seem to find any reference to the actual data being written to the framebuffer. Did I miss something?
Click to expand...
Click to collapse
I'm not 100% sure yet, but I think if you needed to, there is probably a way to hack in at that point.
However supercurio hacked into the gamma here arch/arm/mach-s5pv210/herring-panel.c
...and RGB: drivers/video/samsung/s3cfb_tl2796.c
Is your gamut correction totally independent of RGB/gamma?
EDIT: Oh, I see it now. You have to correct R based partly on G and B etc. Okay. I'll keep looking.

bedalus said:
I'm not 100% sure yet, but I think if you needed to, there is probably a way to hack in at that point.
However supercurio hacked into the gamma here arch/arm/mach-s5pv210/herring-panel.c
...and RGB: drivers/video/samsung/s3cfb_tl2796.c
Is your gamut correction totally independent of RGB/gamma?
EDIT: Oh, I see it now. You have to correct R based partly on G and B etc. Okay. I'll keep looking.
Click to expand...
Click to collapse
Yep... I realized that my attempt at buffer rewrites read and write from the framebuffer one byte at a time! Major I/O overheads! I totally forgot about that.
I'll try rewriting that code as well.

Here's another file:
Code:
include/linux/tl2796.h
It contains the template for the RGB multipliers.
EDIT: I'm trying to see which files use this header now
EDIT: arch/arm/mach-s5pv210/herring-panel.c
...and drivers/video/samsung/s3cfb_tl2796.c
...these are the only two files, so the matrix transformation you want to perform probably needs to happen in one of these files only.

bedalus said:
Here's another file:
Code:
include/linux/tl2796.h
It contains the template for the RGB multipliers.
EDIT: I'm trying to see which files use this header now
EDIT: arch/arm/mach-s5pv210/herring-panel.c
...and drivers/video/samsung/s3cfb_tl2796.c
...these are the only two files, so the matrix transformation you want to perform probably needs to happen in one of these files only.
Click to expand...
Click to collapse
I think the RGB multipliers you're referring to are the same ones used by supercurio and they operate on a per-color basis. In fact, those two files don't directly modify RGB values as far as I can tell. By the time the signal reaches the TL2796 AMOLED driver, they're already mapped to the GPIO_LCD_D<> ports (see /arch/arm/mach-s5pv210/include/mach/gpio-herring.h for the physical mapping).
EDIT:
I did a grep on fb_write and bumped into this code in /include/linux/fb.h:
Code:
/* For framebuffers with strange non linear layouts or that do not
* work with normal memory mapped access
*/
ssize_t (*fb_read)(struct fb_info *info, char __user *buf,
size_t count, loff_t *ppos);
ssize_t (*fb_write)(struct fb_info *info, const char __user *buf,
size_t count, loff_t *ppos);
Since I can confirm that the framebuffers with our devices can support mmap, I suppose this means any app can directly read/write to the framebuffer without going through some intermediate function. This leaves us with framebuffer rewrites or hijacking the transfer of data from framebuffer to physical device. I like the second option better.

nightsky87 said:
I think the RGB multipliers you're referring to are the same ones used by supercurio and they operate on a per-color basis. In fact, those two files don't directly modify RGB values as far as I can tell. By the time the signal reaches the TL2796 AMOLED driver, they're already mapped to the GPIO_LCD_D<> ports (see /arch/arm/mach-s5pv210/include/mach/gpio-herring.h for the physical mapping).
Click to expand...
Click to collapse
After a lot of head scratching, I see what you mean.
I performed a search for S5PV210_GPF* and found these files:
Code:
drivers/gpio/gpio-s5pv210.c
arch/arm/mach-s5pv210/herring-panel.c
arch/arm/mach-s5pv210/setup-fb.c
arch/arm/mach-s5pv210/mach-herring.c
...all of which are compiled into the kernel.
Probably if the best place to intervene is on the GPIOs, it must be in one of these files. I'll keep looking!
EDIT: I just saw your edit in the previous post, and I agree! Option 2 seems preferable.

bedalus said:
After a lot of head scratching, I see what you mean.
I performed a search for S5PV210_GPF* and found these files:
Code:
drivers/gpio/gpio-s5pv210.c
arch/arm/mach-s5pv210/herring-panel.c
arch/arm/mach-s5pv210/setup-fb.c
arch/arm/mach-s5pv210/mach-herring.c
...all of which are compiled into the kernel.
Probably if the best place to intervene is on the GPIOs, it must be in one of these files. I'll keep looking!
EDIT: I just saw your edit in the previous post, and I agree! Option 2 seems preferable.
Click to expand...
Click to collapse
Ironically, register definitions don't seem to be in those files. They probably used a different set of defines. What I did find was this in /drivers/video/samsung/s3cfb_fimd6x.c:
Code:
int s3cfb_set_buffer_address(struct s3cfb_global *ctrl, int id)
{
struct fb_fix_screeninfo *fix = &ctrl->fb[id]->fix;
struct fb_var_screeninfo *var = &ctrl->fb[id]->var;
struct s3c_platform_fb *pdata = to_fb_plat(ctrl->dev);
dma_addr_t start_addr = 0, end_addr = 0;
u32 shw;
if (fix->smem_start) {
start_addr = fix->smem_start + (var->xres_virtual *
(var->bits_per_pixel / 8) * var->yoffset);
end_addr = start_addr + fix->line_length * var->yres;
}
if (pdata->hw_ver == 0x62) {
shw = readl(ctrl->regs + S3C_WINSHMAP);
shw |= S3C_WINSHMAP_PROTECT(id);
writel(shw, ctrl->regs + S3C_WINSHMAP);
}
writel(start_addr, ctrl->regs + S3C_VIDADDR_START0(id));
writel(end_addr, ctrl->regs + S3C_VIDADDR_END0(id));
if (pdata->hw_ver == 0x62) {
shw = readl(ctrl->regs + S3C_WINSHMAP);
shw &= ~(S3C_WINSHMAP_PROTECT(id));
writel(shw, ctrl->regs + S3C_WINSHMAP);
}
dev_dbg(ctrl->dev, "[fb%d] start_addr: 0x%08x, end_addr: 0x%08x\n",
id, start_addr, end_addr);
return 0;
}
Unfortunately for use, this seems to use DMA transfers. The driver sets the start and end addresses for the hardware to automatically transfer the data to the registers representing the GPIO. The only way I can think of to modify this behavior is in this sequence:
1. Create our own "framebuffer" (or double the size of the current framebuffer)
2. Mix colors from the original buffer and write it to ours
3. Repeat every new frame
4. Point the DMA transfer source to our framebuffer instead of the original
Quite a complex process I think... I'm not even sure if its worth the development effort.

nightsky87 said:
Ironically, register definitions don't seem to be in those files. They probably used a different set of defines. What I did find was this in /drivers/video/samsung/s3cfb_fimd6x.c:
Code:
int s3cfb_set_buffer_address(struct s3cfb_global *ctrl, int id)
{
struct fb_fix_screeninfo *fix = &ctrl->fb[id]->fix;
struct fb_var_screeninfo *var = &ctrl->fb[id]->var;
struct s3c_platform_fb *pdata = to_fb_plat(ctrl->dev);
dma_addr_t start_addr = 0, end_addr = 0;
u32 shw;
if (fix->smem_start) {
start_addr = fix->smem_start + (var->xres_virtual *
(var->bits_per_pixel / 8) * var->yoffset);
end_addr = start_addr + fix->line_length * var->yres;
}
if (pdata->hw_ver == 0x62) {
shw = readl(ctrl->regs + S3C_WINSHMAP);
shw |= S3C_WINSHMAP_PROTECT(id);
writel(shw, ctrl->regs + S3C_WINSHMAP);
}
writel(start_addr, ctrl->regs + S3C_VIDADDR_START0(id));
writel(end_addr, ctrl->regs + S3C_VIDADDR_END0(id));
if (pdata->hw_ver == 0x62) {
shw = readl(ctrl->regs + S3C_WINSHMAP);
shw &= ~(S3C_WINSHMAP_PROTECT(id));
writel(shw, ctrl->regs + S3C_WINSHMAP);
}
dev_dbg(ctrl->dev, "[fb%d] start_addr: 0x%08x, end_addr: 0x%08x\n",
id, start_addr, end_addr);
return 0;
}
Unfortunately for use, this seems to use DMA transfers. The driver sets the start and end addresses for the hardware to automatically transfer the data to the registers representing the GPIO. The only way I can think of to modify this behavior is in this sequence:
1. Create our own "framebuffer" (or double the size of the current framebuffer)
2. Mix colors from the original buffer and write it to ours
3. Repeat every new frame
4. Point the DMA transfer source to our framebuffer instead of the original
Quite a complex process I think... I'm not even sure if its worth the development effort.
Click to expand...
Click to collapse
Well, i need a new challenge

bedalus said:
Well, i need a new challenge
Click to expand...
Click to collapse
Great then! Good luck!!
...just kidding
The way I see it, it might not be that hard after all. The way the code is structured, seems to show that you can just retain most of the fb routines. They mostly describe stuff like offsets, dimensions, and the like. If you copy the ENTIRE framebuffer into another memory location and manipulate that, you won't have to concern yourself with the rest of those functions. Yeah it uses up about 17 MB more of precious RAM (if my calculations are right) but at least you only have to set the DMA addresses instead of recoding a lot of things.
Before anything, can you somehow check which files in the /drivers/gpu/ folder are being used/compiled? I think I may see something useful in those files but I'm not sure if its even relevant.