yashsingh1/xdaforums huggingface dataset:
[Nexus S Android Development] nightsky87:
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:

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. :p
[Nexus S Android Development] bedalus:
Well, i need a new challenge
[Nexus S Android Development] nightsky87:
Great then! Good luck!! :p

...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.
[Nexus S Android Development] :
Yep, i know there's some files in drivers/gpu/pvr that are compiling. I'll find out which ones when i get back to my machine

EDIT:

drivers/gpu/pvr/bridged_pvr_bridge.o drivers/gpu/pvr/metrics.o drivers/gpu/pvr/power.o
drivers/gpu/pvr/bridged_support.o drivers/gpu/pvr/mmap.o drivers/gpu/pvr/proc.o
drivers/gpu/pvr/buffer_manager.o drivers/gpu/pvr/mm.o drivers/gpu/pvr/pvr_bridge_k.o
drivers/gpu/pvr/built-in.o drivers/gpu/pvr/module.o drivers/gpu/pvr/pvr_debug.o
drivers/gpu/pvr/deviceclass.o drivers/gpu/pvr/mutex.o drivers/gpu/pvr/pvrsrvkm.o
drivers/gpu/pvr/devicemem.o drivers/gpu/pvr/mutils.o drivers/gpu/pvr/pvrsrv.o
drivers/gpu/pvr/event.o drivers/gpu/pvr/osfunc.o drivers/gpu/pvr/queue.o
drivers/gpu/pvr/handle.o drivers/gpu/pvr/osperproc.o drivers/gpu/pvr/ra.o
drivers/gpu/pvr/hash.o drivers/gpu/pvr/pdump_common.o drivers/gpu/pvr/refcount.o
drivers/gpu/pvr/lists.o drivers/gpu/pvr/pdump.o drivers/gpu/pvr/resman.o
drivers/gpu/pvr/mem.o drivers/gpu/pvr/perproc.o drivers/gpu/pvr/s3c_lcd.o

Lots of files in pvr get compiled.
[Nexus S Android Development] nightsky87:
Nice... Does that mean the codes in drivers/gpu/pvr/s3c_lcd/s3c_displayclass.c are included? I can see how the framebuffer behaves as it does if that's the case. A swap chain is created which describes how the offsets are changed for each new frame. What's interesting is that after initializing the swap chain, it activates the VSYNC ISR.

static irqreturn_t S3C_VSyncISR(int irq, void *dev_id)
{
if( dev_id != gpsLCDInfo)
{
return IRQ_NONE;
}

queue_work(gpsLCDInfo->psWorkQueue, &gpsLCDInfo->sWork);

return IRQ_HANDLED;
}

If we create a function to modify the colors and write to a secondary buffer, we can use queue_work to queue that function to the kernel for processing

in time

with the screen refresh. So this is an interesting candidate for code hacking. :p But for now, time to get me some sleep. :eek:

Great working with you bedalus! :D
[Nexus S Android Development] granets:
woah, this sounds like a great idea. unfortunately I'm not a dev, but I'd love to opt in as a guinea pig when things get to that stage. bedalus, I would not be mad at all if you focus on this, your last kernel is pretty good imo, and this looks like it could be a great new thing you can add to it :)
[Nexus S Android Development] :
I took the liberty of mirroring your sample image. For some reason the one from the OP appears very tiny on the XDA app. Maybe you want to copy this url to your OP instead?
[Nexus S Android Development] nightsky87:
Fixed! Thanks for that. I don't really use the XDA app so I haven't tested it there.

By the way, I have another pseudo-fix for the color that should be more plausible and less resource consuming. Of course we have to trade-off some color accuracy. The hardware AMOLED driver (TL2796) supports 5 gamma adjustment points. If I recall correctly, voodoo usually operates on the bottom point v0. I suppose its possible to use all 5 points to rescale RGB values to appear close to the equivalent sRGB values with 2.2 gamma. I'll have to run this by a genetic algorithm to optimize the values of the 5 gamma points but hey that should be fun. This would at least present a mod on the hardware level which leaves us with no extra computational cost and I/O overhead. :p

Less accuracy because the red, green, and blue primaries would always stay the same on the XYZ triangle leaving us with the same colorimeter reading. But at least it should handle the oversaturation issue and be a close approximation of sRGB. :p
[Nexus S Android Development] :
I like the sound of no-overhead. I'd be really interested in more details of your genetic algorithm too.
[Nexus S Android Development] nightsky87:
Well, I could give you the MATLAB code when I'm done with it (I recall you use Scilab right?).

The idea is generally to create a 3-by-16777216 matrix containing all possible combinations of RGB at 8-bit precision. For notation, lets stick with RGB. Apply gamma, then perform two parallel conversions to the XYZ color space using the two color matching matrices C_sRGB and C_NS I mentioned at the OP and convert those to L*a*b* color:

RGB -> pseudo-gamma -> XYZ (sRGB) -> L*a*b*
RGB -> pseudo-gamma -> XYZ (NS) -> L*a*b*

I call it pseudo-gamma since it doesn't really follow a gamma curve. The TL2796 chip uses linear-piecewise mapping of RGB to RGB(gamma) with 6 segments (5-point gamma control). The resulting fitness function (score) for the genetic algorithm will be the Euclidean distance between the two sets of L*a*b* values:

sqrt(sum((L_sRGB - L_NS) .^ 2) + sum((a_sRGB - a_NS) .^ 2) + sum((b_sRGB - b_NS) .^ 2))

The genetic algorithm is then set to test and evolve values for the 5 gamma points (at 6-bit precision btw). I haven't coded this yet (kinda need to do thesis stuff so I'll take a break from this) but this should more or less be the flow. :D
[Nexus S Android Development] polobunny:
The way I see it this would be a better solution, for the sake of keeping the Nexus S a usable phone (overhead would likely kill the already "weak" phone under JB, kinda starved on RAM already too) and this mod could be "just good enough" to bring the Nexus S to more accurate colors.

I'm wondering what settings one could be satisfied with though, the green is really out of bounds. So it's either we don't display all colors for red and blue (D:) or we leave the green super wide.
[Nexus S Android Development] nightsky87:
Green can most likely be left super wide. Well the goal is really just to find the pseudo-gamma curve which works so we can leave that to the searching algorithm. Handling in the L*a*b* color space should also help get a better response than the XYZ space so we can just try to see.
[Nexus S Android Development] polobunny:
That's what I imagined as the best "just enough" solution too. Cutting down on the rest to make the green fit just doesn't seem like a good idea, even though green is what we see best. =)
[Nexus S Android Development] :
I don't think I answered this question, but yes, they are included. However, the PVR code is for the GPU chip, which I think usually only handles 3D stuff. Although there is an option in development settings > Force GPU rendering (for 2D) but you probably understand this better than me anyway!

I've used MATLAB once... I've used Derive a little bit. I recommend you upload the code in your OP if you're okay with sharing it in public. It might be useful for other developers too.

I wonder why Euclid gets the credit for that. It's Pythagoras' formula, and it works in N dimensions. Euclid was all about the plane.

Anyway, I get the rough idea of what your genetic algorithm will do. Lemme read it back to you to see if I got it right.

For both matrix transformations in the OP, simultaneously we

a) Put the quite large RGB matrix through the gamma with 5-point control

b) Perform matrix transform from OP

c) Convert to L*a*b* (which is a 3D colour space)

The closer the linear distance between the two results the better.

I still have some questions. How do you evaluate the score for linear distance? Smaller is better obviously. But you produce a large set of individual Euclidean distances for each genetic algorithm, right? So do you then take the mean of all the linear distances? Or will it be more statistical? E.g. calculate a score three standard deviations above the mean (i.e. 99% of the distances are guaranteed to be below that threshold)

How many starting points do you have for the 5-point control? Will they all be randomly set? Do any formulas exist to predict how quickly the algorithm can converge on an acceptable solution?

I'm concerned with the size of the matrices involved, it could be a very long process. Do you have some powerful processors at your disposal?
[Nexus S Android Development] nightsky87:
Oh... I totally forgot about that. So scrap that thought then. Either way, we just need the same sources as voodoo (herring-panel.c and s3cfb_tl2796.c) to pull off the gamma corrections anyway.

Sure! That really isn't a problem. That is, as soon as I actually code it. :eek:

Pythagoras arrived at the formula but Euclid did describe the three-dimensional space to begin with. and since the Pythagorean formula actually measures the physical distance in that space (i.e. Euclidean space), it's the Euclidean distance. :p

You nailed that one! :D

Close but not quite. The Euclidean distance is taken for the entire set not just each L*a*b* pair. So it will be a 50331648-dimensional (3*256^3) space computed using the same formula. And yep, smaller is better.

I usually perform a run with a population size of 100 each one randomly set at the beginning. Scores are computed for each candidate set and the genetic algorithm picks the best candidates (usually with tournament selection in my previous GAs) and proceeds with "mating" the sets one pair at a time resulting in a new set of 100. Repeat until the algorithm converges to a good solution.

I just usually run the algorithm with my i7 laptop, but yeah, it takes some time and the algorithms I run sometimes takes days to finish. :p
[Nexus S Android Development] granets:
maybe I can help with computing power? i have a 2600K i7 and a very fast overall pc, that I dont use almost all day long, because I am at work. I am willing to give you team viewer access to it, if this will help you
[Nexus S Android Development] :
I can't wait to see this MATLAB code!
[Nexus S Android Development] nightsky87:
Change of plans... The MATLAB memory overhead is just too darn large it won't process well. I blame Java!! :mad:

I'll have to rely on good old C for this one. :p
[Nexus S Android Development] :
Need any help with that?
[Nexus S Android Development] ShadowVlican:
I have no programming abilities, but as an amateur photographer and hobbyist, I support this movement for colour correction and management
[Nexus S Android Development] nightsky87:
Well technically I could... me being bad at code optimization and all... But then again, I wanted to try my hadn at parallelizing the code using OpenMP so I'll give this as shot first. But before that, I'll have to take a break at this with schoolwork deadlines approaching and all that. :p

zati

As a fellow photography hobbyist, this is why I'm for this movement as well... I'll do my best! :p
[Nexus S Android Development] :
Don't worry about optimisation, just make it understandable and maintainable. Other developers for other devices may be interested.
[Nexus S Android Development] Erythnul:
Hey guys! Good luck on all this, I don't really have much to contribute here (I wish I knew how to code, but where to start? :/ )

Anyway, I came across this video from XDAtv, maybe you've already seen it, maybe not, but at ~13 minutes Erica talks about SuperCurio developing a new display control app called DisplayExpert and shows off what the beta can do on an SGSIII. Thought you might be interested in seeing that if you hadn't yet. The rest is also a pretty good video explaining the differences between LCD and AMOLED screens and all that, but you probably know most of that already (though I was shocked to find out that "true black"on an AMOLED screen doesn't actually mean the LEDs are completely off, as that is supposedly a big selling point, but it's pretty damn close to it anyway ;) )

http://youtu.be/uypD7QUgcyM?t=13m
[Nexus S Android Development] :
How's your course coming along? Hopefully you'll have time to check this:

https://github.com/coolcpu/matisse_kernel_crespo/commit/a158a4339c49ba4524404f628463fc2175534073

It's from a Galaxy S kernel: http://coolcpu.blogspot.co.uk/

Thanks to Articudos for the tip!
[Nexus S Android Development] nightsky87:
Hey, someone correct me if I'm wrong but this seems to work on the ACL feature of the TL2796 AMOLED driver chip. As far as I can tell, that feature is mostly for luminance correction. The block diagram seems to show that it takes the sum of the RGB values and uses an lookup table to find a corresponding pulse width to control the AMOLED pantel. I've attached the relevant diagrams from the datasheet for anyone interested.

I'm not sure what exactly to take of this but personally, I think this is useful for making gamma-stable brightness control but some kernels (like yours) are already good with that. :D

However, this doesn't seem to affect individual RGB values so I'm not sure what to make of this in the context of color correction.

Oh and to answer the first question, it might take a few more weeks for my coursework to clear up enough to have some time for this little project.:p
[Samsung Galaxy Player 4.0, 5.0] noob4000001:
I found that video for the Samsung Note where the guy shows you some lesser known tips and tricks, but what are some for the Galaxy Player 5.0?

The only one I've found on accident is to increase the brightness you can hold your finger on the status bar for a few seconds. I love this feature but I wish you could also decrease the brightness in a similar manner. Do you know how to do that? Or any other lesser known shortcuts? Post um here!
[Samsung Galaxy Player 4.0, 5.0] EcHoFiiVe:
It also decreases the brightness if you move it back too
[Samsung Galaxy Player 4.0, 5.0] rockerblood:
you dont need a trick just download screen filter which i currently using. u can filter the screen as dim as ur eyes can. heres the link to g.play

https://play.google.com/store/apps/...um=organic&utm_term=google+play+screen+filter

hope this helps :)
[Samsung Galaxy Player 4.0, 5.0] Dr. Cyanide:
Let's see...

-Screen brighter, hold down top right notification bar

-Screen dimmer, hold down to left notification bar

-You can change out the apps in the dock at the bottom. Open the app drawer, menu button, then drag an app out and a new one in.

-Holding the menu button acts like pressing a search button.

-Holding down the home button brings up recently used apps, letting you multi task better.

-If you plan to use Skype or do any other audio recording, the mic that came on the earbuds is better than the built in one.

Those are the things that come to mind right off. Some may be impressive, others not.
[AT&T, Rogers HTC One X, Telstra One XL] hcricket:
Also, can you charge the battery in recovery?
[AT&T, Rogers HTC One X, Telstra One XL] 18th.abn:
With twrp recovery it charges....wiping /system is formatting /system partition, which is your OS, or Rom. Whichever you prefer. So if you wipe /system you must flash a new Rom or you wont have a OS to boot into.

Sent from my HTC One X+ P-type_0.91.1
[HTC One X] boogiecornejo:
notifications for go launcher is not working on my hox. i have both nova and go launcher installed. notifications(tesla) are working fine on nova but go notifications isnt working at all in go launcher which is really weird coz its supposed to be native to that app. is it wrong to have both?
[Transformer TF300T Q&A, Help & Troubleshooting] Ulric099:
I'm currently on stock, and I found this little weird thing that changes from time to time.

the spaces in between the home pages changes, it's not a big deal but it did catch my attention.

I attached screenshots to show you guys what I mean
[Transformer TF300T Q&A, Help & Troubleshooting] Ulric099:
Can anyone explain this please?
[Transformer TF300T Q&A, Help & Troubleshooting] UndisputedGuy:
It just happens. When the spaces are larger, then you can click on the side of the screen to scroll pages but when they are shorter, you can't do this. It really does seem random
[Transformer TF300T Q&A, Help & Troubleshooting] Ulric099:
Actually, I can still tap on either side even when it's shorter. Kinda just found it weird that it changes at random
[Sprint HTC EVO 4G LTE] Bastafari:
So I really like the ribbon notifications in Miui roms but I'm nota fan of the room itself. There's a icon pack that I really like called miui suave hd and was wondering if there is anyway to implement the ribbon notifications in an aosp Rom? I know there are some themes like label theme that use ribbons but It would be cool if there was an app or system setting that would allow this irrespective of the theme used in t mobile theme chooser. I don't mean the icons them self, I'm using apex so i got that covered. Thanks.

Edit: Here's the icons i was talking about. http://xdaforums.com/showthread.php?t=1330577

Sent from my EVO
[Sprint HTC EVO 4G LTE] et4g:
Unless you can decompile the .mtz and you can differentiate where it is no...if you send me a link of both themes through pm ill take a look
[Android General] guru_shastri:
Hi,

the Jetstream forum got a bounty going for getting ics/jb to run on our tablet.

at this point, most of the hard work is behind us: the bootloader is open, s-off and root achieved.

at the moment we got 350$, and counting.

original:

http://xdaforums.com/showthread.php?t=1910426

hopefully someone will pick this up.
[Android General] guru_shastri:
anyone?
[Android General] guru_shastri:
we're at 350$..

also, we have a few testers willing to put the devices and computers up for remote accessing..
[Android General] guru_shastri:
we're also willing to simply buy a device for a known developer instead of the bounty.
[Samsung Galaxy SL i9003] Skander1998:
Hey guys.. It's unfortunate that i don't use this device anymore and gave it to my mom, i now use an S3.

So i will not be able to be as active in this device forum and will probably focus on the S3 forum.

I really had a great time with you guys, and i will certainly keep helping here and there, and keeping a look at Kernel 3.x and CM development.

I really hope the best for all of you.

<3.
[Samsung Galaxy SL i9003] emptyragnarok:
unfair -.-' anyways keep on coming here :) We would miss you ^_^
[Samsung Galaxy SL i9003] bscraze:
All the best with your s3:)
[Samsung Galaxy SL i9003] Hetalk:
Sad to see you go .. now who'll scare off the new users?

Anyway, all the best.
[Samsung Galaxy SL i9003] wrishaba:
miss u no no

We miss u surely.

But I wish u a good selves on s3

By the way be here also.

Since SL is only on yr mom.

Hence you have full liberty to do anything.

Visit here if time permits.

Good luck.
[Samsung Galaxy SL i9003] kkrraazzyy:
bbye friend and just enjoy with your S3
[Samsung Galaxy SL i9003] pratik_s:
bye friend it was nice to share thoughts with u.enjoy ur s3 :)
[Xoom Q&A, Help & Troubleshooting] dawg98:
I visited my sister in Germany and she gave me a Vodafone branded Xoom2 UMTS :) (MZ616). I was able to flash it with ICS and everything works great.

I got a new sim card from ATT (I live in ghe US)and put it into the tablet. This is were my issues start.

I see no APNs. When I add an APN it disappears or I cannot save it.

I tried everything. Sometimes when I try to manually search for the network ATT pops up. When I select it, it will show bars for a short time or i may get a "sim not authorized for this network error.". When I add data roaming, it may shows the ATT APNs for a short time.

I also get an error when trying to add a simlock I get a "no sim card" error.

I am stumped. I searched the various forums and I get a lot of inconsistent info.

Is this issue related to the tablet being locked? Does that even matter? Is this some sort of region issue? Do I need to unlock the bootloader or should I use a different ROM?

I do not think the sim card is faulty.

Any help appreciated.
[Xoom Q&A, Help & Troubleshooting] dawg98:
Sim Card Size????

So I compared the old Vodafone sim card with the 'new' AT&T sim card. The plastic outline of both cards seesm to be micro. However, the gold plated contacts on the new cards are definitely micro sim, but the old Vodafone card seems to be old school size (not sure what that size is called). If the size of the gold plated material matters, then this may be may issue. Like I said, above, when I first boot into the tablet with the new sim card I will have bars for a short time, but they disappear and the sim card does not seem to be recognized.

Can someone knowledgeable on sim card size matters as they pertain to the Xoom2 please weigh in and let me know if this is the issue?
[Xoom Q&A, Help & Troubleshooting] dawg98:
I took a pic of the sim cards. From left to right: Old Vodafone sim, new AT&T sim, 2FF (mini sim card) for size comparison.
[Verizon Samsung Galaxy S III] tomalrocks:
Hello,

I recently installed custom Jellywiz rom on my Verizon S3.

My question is if I have new custom rom versions or if I want to switch to a different rom, do I always have to go back to stock firmware and then install the custom rom or can I directly flash over my existing custom rom ?
[Verizon Samsung Galaxy S III] Neverendingxsin:
New custom rom versions: Unless otherwise stated by the developer you can go ahead and just dirty flash right on top of the current one, but if you experience issues then i'd wipe data and cache and do a clean install.

Switching to a different rom: ALWAYS do a clean install (wipe data, and cache), i can't urge how important that is, while you may not have any issues whatsoever, you definitely could encounter issues because each developer may have different changes, and you don't want stuff to mix and match.
[Verizon Samsung Galaxy S III] tomalrocks:
Thanks. So just flashing over existing rom after wiping data and cache will work. Will do that. I do not want to go back to stock rom always as that is time consuming.
[Verizon Samsung Galaxy S III] aypeeootrek:
Yeah this is fine. The way I've always done it. Also in clockwork, go to advanced >wipe dalvic
[Verizon Samsung Galaxy S III] tomalrocks:
Thanks :good:

Do you know whether I am use CWMod recovery to flash stock roms or do i need to use ODIN for that?