[How-To] Fix 16 bit banding surround specific. - Surround General

Greetings I know many are aware that sometimes when going through the update process the surround sometimes gets stuck with the 16bit banding issue.
Well like many people I went hunting for an answer. There is of course a thread filled with lots of people saying this trick worked or didn't work, etc. However something unique for the surround that solves the problem is instead of changing the value to 32 (which will still show banding) change the value to 24 instead. This completely fixes the banding issue (at least until next update.)
You will need to be unlocked and have the ability to use a registry editor
These are the values to change:
Code:
HKLM\Drivers\Display\Primary\PrimBPP dword 24
HKLM\Drivers\Display\Primary\bpp dword 24
HKLM\Drivers\Display\Primary\PanelBPP dword 24
One thing I would like is if someone who has a Surround could post the exact default values from a 7004 version. I really don't want to reflash mine just to find out and the 24/24/24 works perfectly, removes the banding, and I have noticed no red screen or slow down issue.

Related

Camcorder resolution stuck

For some reason my 'Camcorder' application resolution is nowstuck on "S (128x96)".
This is when I go into the settings->Advanced page.
It doesn't matter which codec I select, the resolution stays greyed out.
Any ideas? This is really annoying.
Ta,
FM
fatmonk said:
For some reason my 'Camcorder' application resolution is nowstuck on "S (128x96)".
This is when I go into the settings->Advanced page.
It doesn't matter which codec I select, the resolution stays greyed out.
Any ideas? This is really annoying.
Ta,
FM
Click to expand...
Click to collapse
In the main video menu, you have the "mms video" option selected.
There is a camcorder icon in between the settings cog and the album icon, you can change it in there.
Camcorder Resolution Stuck on S (128x96) VIDEO AND NOT MMS VIDEO option
My 'Camcorder' application resolution is stuck on "S (128x96)" also.
This is when I go into the settings->Advanced page on 'Video' option - (MMS Video option is actually set to M (176x144), ie a Higher resolution than Video option).
Changing between MP4 and H.263/4 format doesn't help, the resolution is always greyed out.
I have a stock 1.43.206.4 WWE ROM and have only applied the official HTC Patches.
Does anyone know of a reg edit to fix this???, I've installed dotfred Task Manager with RegEdit built-in.
Hope someone can help, please.
Thanks.
You had me excited there, thought it was going to be that simple, but alas, that's not it.
With 'MMS Video' selected - the envelope with a camcorder at top right - the resolution is fixed at "M (176x144)".
The proble is when I have 'Video' selected - a camcorder on its own - At this point going into the settings cog and then advanced, the resolution is fixed at 128x96. Its greyed out so cannot be changed - just the same as with MMS Video selected bu an even lower resolution!
Very odd.
Any other augestions?
-Ta,
FM
Do you guys have any tweaking apps installed?
The reason I ask is I have MPEG4 as a format option, which I think is only accessible with a tweak app, like BsBTweak (or reg file of course), I notice Firestorm33 does.
The only things greyed out on mine are metering mode and prefix, both of which I can guess the function and doubt they are related to this.
What options do you have selected in the Advanced options for video?
I have:
Resolution: VGA (obviously this is the one in question)
Review Duration: 10 seconds (I have tried all options in here and cannot reproduce your issue)
Capture Format: MPEG4 (which I think is only accessible with a tweak app, like BsBTweak (or reg file of course)
Recording Limit: No Limit
Keep Backlight: On
Record with Audio: On
Shutter Sound: Off (have toggled this, no difference)
Under Image Properties: +3 for all
Effect: None
Metering Mode: Spot (greyed out)
Prefix: Default (greyed out)
Counter: 52 (unlikely to cause issue though!)
Flicker Adjustment: Auto
Help/About are unnecessary.
Do these match yours? (bar the MPEG4 option)
Camcorder stuck resolution - S (128x96)
I don't have a lot of time right now, I'll get back to you rp-x1 on settings and apps later.
Initially I was just re-iterating that I have the same problem as FM, but to explain my problem in more detail, the first day I owned my HD2 I recorded a video (at a higher resolution, ie an acceptable quality for everyday use, will try and get the actual res later) than I can now, so something I've installed since then, whether it be the the official HTC Patches or some other app must've locked down the resolution to the S 128x96 setting. I've not installed a whole lot of 3rd party apps yet, will post more details tonight.
I have thought about doing a Hard Reset to take the phone back to factory settings, but hoping I don't have to.
I do have BSB Tweaks installed, yes.
And to be honest I couldn't say either way whether this problem started around that time.
I'll post a mesage in the BSB Tweaks forum as well to see if anyone there has seen anything similar (there's no mention as I did a search there before posting here just in case).
-FM
fatmonk said:
You had me excited there, thought it was going to be that simple, but alas, that's not it.
With 'MMS Video' selected - the envelope with a camcorder at top right - the resolution is fixed at "M (176x144)".
The proble is when I have 'Video' selected - a camcorder on its own - At this point going into the settings cog and then advanced, the resolution is fixed at 128x96. Its greyed out so cannot be changed - just the same as with MMS Video selected bu an even lower resolution!
Very odd.
Any other augestions?
-Ta,
FM
Click to expand...
Click to collapse
Hi guys,
I've exactly got the same problem, have you found a issue yet ?
Haven't been able to find what caused this, so yesterday I took the plunge and hard reset.
Camcorder, of course, came back all good and I've since installed all my apps again (I think they're all on now) and the problem hasn't come back.
One thing I did notice, though, is that 'mobiletag' no longer seems to work. This possibly stopped working around the same time that the Camcorder issue started - though I'm not sure about that.
Even after the hard reset and re-install 'mobiletag' throws an error that it's 'unable to load camera library'. The error details aren't particularly helpful either as the charcter set appears to be odd. The errors are:
Code:
at #.#.#()
at #.#.#()
at #.#.#()
at #.#.SpecificInit()
at #.#.#()
at #.#.#()
at #.#.#()
at #.#.#()
where each of the # characters above is actually a square character like you get when a character is missing from a articular font.
May be related, may be not.
Would be interesting to know if anyone else who has had this problem also has 'mobiletag' installed - it uses the camera so there's some logic to that being to blame.
-FM

Opera: Benefits of changing Cache Seize

So I am using opera 9.7.
1) If I go to settings >> Advanced>> and slide the cache size up to 10000KB, what are the benefits? The negatives? What is the best cache size I should leave it at?
2) After opera load the entire page, it doesn't remember it. I mean, if I scroll down a long page (ie. engadget) and back up quickly, it tends to give me blank white areas that eventually show what was there before. But this happen only if I scroll very fast up and down. Is there any way for opera to keep what it loaded without disappearing no matter how fast I was scrolling?
24 hr re-bump.
Lemonspeakers:
Can't speak to the cache, but as far as the blank white that you see on scrolling, I found that changing some of opera's buffer settings solved that for me. I open the registry to HKLM\Software\Opera\Info and change "Browser Buffer Height" dword to 3072 and Browser Buffer Width dword to 2048 and softreset. It's essentially just doubling their default decimal values. To be clear, this is for 9.7. Let me know if it works.
EDIT: Sorry Lemospeakers, I tested the tweak on the Engadget site and still got some blank white, albiet it disappeared almost instantly as I was going along, it was still there and you're looking to get rid of it in its entirety.
Sean3 said:
Lemonspeakers:
Can't speak to the cache, but as far as the blank white that you see on scrolling, I found that changing some of opera's buffer settings solved that for me. I open the registry to HKLM\Software\Opera\Info and change "Browser Buffer Height" dword to 3072 and Browser Buffer Width dword to 2048 and softreset. It's essentially just doubling their default decimal values. To be clear, this is for 9.7. Let me know if it works.
EDIT: Sorry Lemospeakers, I tested the tweak on the Engadget site and still got some blank white, albiet it disappeared almost instantly as I was going along, it was still there and you're looking to get rid of it in its entirety.
Click to expand...
Click to collapse
Yes, I just tried it an I don't notice a difference.
Can anyone help out? My question is on the first post.
Imagine it as a swimming pool. The bigger your pool, the more people you can have in there at once. With a smaller pool, sometimes you have to ask a few people in there to leave so others can come in.
Similarly with the cache size, the bigger the cache (say, 10mb in this case with 9.7), the more website contents will be save, allowing the page to render quicker the next time you visit. I'd say just leave it at 10mb, so the same content doesn't have to be re-downloaded and saved as often.
Your second question is referring to what is called the "checkerboard" effect. Personally, I think that's generally the CPU/GPU's part to render the page as quickly as possible. Pretty much every smartphones imaginable go through that "problem" when you scroll up and down too fast. I can't tell you for sure why a 1Ghz processor with 576mb of RAM produce checkerboards (im not a programmer)...maybe this is the missing link between laptop/desktops and mobile computing.
Humm.. I'lll look into how to remove the checkerboard effect. In the mean time anyone know how?
If you are looking for a performance boost involving the cache, i can recommend using a ramdisk and put the opera cache on there.
I use an 8.5 meg opera cache on a 30 meg ramdisk, (hidden, because it messes with the documents tab if you have it showing) and my opera, internet explorer, and system temp are also set to use that.
Opera really flies along, and the system happily uses it for its TempPath, and best of all, being a ramdisk, it gets cleared by a soft reset.
Plus it helps utilise some of that fat ram we have sitting there doing nothing on a 576 enabled rom.
samsamuel said:
If you are looking for a performance boost involving the cache, i can recommend using a ramdisk and put the opera cache on there.
I use an 8.5 meg opera cache on a 30 meg ramdisk, (hidden, because it messes with the documents tab if you have it showing) and my opera, internet explorer, and system temp are also set to use that.
Opera really flies along, and the system happily uses it for its TempPath, and best of all, being a ramdisk, it gets cleared by a soft reset.
Plus it helps utilise some of that fat ram we have sitting there doing nothing on a 576 enabled rom.
Click to expand...
Click to collapse
do you mind telling me how you've hidden it? steps?
do you know how to fix the checkerboard effect?
lemonspeakers said:
do you mind telling me how you've hidden it? steps?
Click to expand...
Click to collapse
Sure. I use a cab file to set up the ramdisk, and in the reg key
HKLM/System/StorageManager/Profiles/RamDisk there is a Dword called MountHidden with a value 0. (if it exists at all). Set/change that to 1, and you can no longer see the ramdisk in any filemanager, but the system can still use it for its cache and what not.
do you know how to fix the checkerboard effect?
Click to expand...
Click to collapse
Sorry i dont know what the chessboard effect is. I'm Opera 9.7, is it 10 specific?
lemonspeakers said:
do you mind telling me how you've hidden it? steps?
do you know how to fix the checkerboard effect?
Click to expand...
Click to collapse
Yes, i would also like to know this
samsamuel said:
Sure. I use a cab file to set up the ramdisk, and in the reg key
HKLM/System/StorageManager/Profiles/RamDisk there is a Dword called MountHidden with a value 0. (if it exists at all). Set/change that to 1, and you can no longer see the ramdisk in any filemanager, but the system can still use it for its cache and what not.
Sorry i dont know what the chessboard effect is. I'm Opera 9.7, is it 10 specific?
Click to expand...
Click to collapse
The white/grey boxes that appear when you scroll through webpages...then the browsers catches up with itself and renders the page correctly
Check this thread out.
http://forum.xda-developers.com/showthread.php?t=627441&highlight=opera+real+full+screen
There are alot of handy tricks in there. It solved the checkerboard problem for me.
Ahh ok, i sort of know what you mean. SOmetimes when i scroll it leaves half teh screen showing what was there a second before, so for instance a list of numbers 1 - 6 might become
1
2
3
4 3
__4
__5
__6
a quick movement always cures it, so im not that fussed by it in truth. No white / grey boxes though.
I have no issues at all with the browsing on 9.7. (Well, flash might be nice, but im not that heavy a flash site user.)
samsamuel said:
Ahh ok, i sort of know what you mean. SOmetimes when i scroll it leaves half teh screen showing what was there a second before, so for instance a list of numbers 1 - 6 might become
1
2
3
4 3
__4
__5
__6
a quick movement always cures it, so im not that fussed by it in truth. No white / grey boxes though.
I have no issues at all with the browsing on 9.7. (Well, flash might be nice, but im not that heavy a flash site user.)
Click to expand...
Click to collapse
re-bump. Does anyone have a solution to the OP's issue?

Bits and bobs...

I'm taking a week off work out in Russia's snowy countryside and have finally had the time to fiddle with some advanced settings available to the galaxy tab. Here are some foibles I've discovered. Also there are some issues that have been raised by people in the general section.
Consider this a reevaluation of my stickied review thread. I don't think any of these detract from the tab in any serious way - most actually improve it!
LCD density - I've had this set to 200 for the last three months, but always wanted to try out lower settings. Interestingly, setting it to 180 changes the stock phone icon to one that looks like a landline set. I can only assume that touchwiz must have been tested on lower density screens.
At 180 web pages are almost perfect in Fennec (I'm using the nightlies with opengl in fullscreen).
Camera - changing the LCD density made some mess out of the camera, especially wrecking the scrolling menus. The riticle gets stuck in the top 3rd of the screen. Also one still can't use both camera and music at the same time.
Saturation/ chroma - changing black and white density levels drastically lowers the battery life of the device for me. Color saturation above stock also has this effect. I'd be interested to know if others are seeing similar results.
Airplane mode - I've talked a lot about this in various threads, but many people would have missed it. In effect airplane mode dramatically increases battery life by physically switching off all the radios.
Services - I don't use the integrated Facebook app, so physically killing the sns service also seems to improve battery life and performance for me. I wonder, is it possible to remove Facebook entirely via titanium? Or would this mess with core functionality?
I also have no need for text to speech, but find that gtalk and tts seem to be unkillable. On my milestone removing either would lead to random fcs. Is this the case on the tab?

[BOUNTY] editing SIEG03 camera firmware to enable LED flash

okay, so apparently SCEF02 FW users r stuck with video recording fps drop when recording in low light conditions (and no official solution from samsung yet)
more about the problem here:
http://forum.xda-developers.com/showthread.php?t=1443658
the only FW that seems to fix the problem is the SIEG03, which indicates that the problem is software related and CAN be fixed
however it disables flash in video recording mode & LED torch
so can't the devs figure a way to edit SIEG03 firmware to give us flash support?
links that may help (thanks bartekaki for providing it):
https://github.com/GalaxySII/samsun...-i9100-gingerbread/drivers/media/video/m5mo.c
personally, I'll pay 10$ if it happens (or more if necessary)
who else???
you copied the link from my post wrong way and it doesn't work:
correct is:
https://github.com/GalaxySII/samsun...-i9100-gingerbread/drivers/media/video/m5mo.c
suzaku said:
https://github.com/GalaxySII/samsung...a/video/m5mo.c
Click to expand...
Click to collapse
Dude, you can't even copy/paste links from others's posts...
I'll chip another 10$.
As much as I love the idea, I think having the source for the phone SIEGE03 comes from also might help. Because the hooks for flash would have to be cross referenced and switched over to properly work (If it is that simple.)
bartekaki said:
you copied the link from my post wrong way and it doesn't work:
correct is:
https://github.com/GalaxySII/samsun...-i9100-gingerbread/drivers/media/video/m5mo.c
Click to expand...
Click to collapse
thx man
radkor said:
Dude, you can't even copy/paste links from others's posts...
Click to expand...
Click to collapse
I thought that since I linked to the original whole thread then it's ok...sorry I'll fix it
karendar said:
As much as I love the idea, I think having the source for the phone SIEGE03 comes from also might help. Because the hooks for flash would have to be cross referenced and switched over to properly work (If it is that simple.)
Click to expand...
Click to collapse
this FW came from the I997 (infuse 4G), and this phone already has flash so I think it's possible
what do u mean by source? sorry I'm a newb
suzaku said:
this FW came from the I997 (infuse 4G), and this phone already has flash so I think it's possible
what do u mean by source? sorry I'm a newb
Click to expand...
Click to collapse
SIEGE03 is a firmware. This firmware is required to run the camera... To access the camera functions, we need a driver. This driver is compiled from source code which is what the link above is...
What probably happened here is that the Infuse uses the same camera module and interface. The flash though might use a different register or address scheme in the source code of the Galaxy S2 to interface with the firmware. So someone would have to figure out the difference between the m5mo.c source code from the Galaxy S2 and the I997 to see if it can be fixed through driver. Otherwise we'd have to reverse engineer the firmware which is too much energy wasted.
The problem with this method is that we'll need to compile a new version of the camera driver. And that, I am not the person to do it.
Another solution would be to pull the camera driver from a stock I997's ROM and overwrite it on our phone to see if it works.
I got a galaxy s2 here last friday (coming from a htc desire), and this week i got around to using the camcorder function. Immediately noticed the stutter issue, checked the forums and the current firmware situation, and switched out my SCEF02 for the SIEG01. Of course it fixed the stutter but broke the flashlight, so i spent an evening looking into fixing it. Here's how far i got...
The firmware binary
First of all the SIEG01 firmware binary itself. I did a hex compare with SCEF02 and there are so many differences (hundreds when set to 16 byte difference comparison) it'd be almost impossible to find the incorrect memory address for the flashlight function control (at least in my limited ability).
Next up i tried looking for seperate sections within the firmware to frankenstein a fix. There was only one certain boundary i found with an identical address, that's around the 166FF area, where both files are padded with FF's to the same position (following is ASCII denoting the firmware version). That's a pretty clear indicator that it's a seperate part of the rom, so, i switched out the bottom half of SCEF02 into SIEG01. The result was no stutters, no flashlight. Likewise replacing the bottom half of SCEF02 with that of SIEG01 resulted in stutters and a working flashlight.
So in short, regarding the firmware itself, the section controlling the flashlight function is somewhere before 166FF in the binary. Everything in that first half of the firmware is reasonably similar between the two firmwares, but not identical. Mostly it's single byte changes (probably just the same variables stored in different addresses), and most of the similar sections are offset by roughly a word of data or more. I didn't spend hours looking through to discover where the extra words of data crept in though.
The driver
You could spend weeks tinkering with values within the first 1300KB of the binary trying to find the flashlight section alone, never mind the specific variable/register for the flashlight mode itself, so i moved on to checking the right values were being set by the driver (m5m0.c).
https://github.com/GalaxySII/samsun...-i9100-gingerbread/drivers/media/video/m5mo.c
the relevant function appears to be m5mo_set_flash on line 858, and the function works pretty simply. First there's a case switch to set the values of two variables called flash and light which will be sent to the firmware. The final case is the one for the flashlight function, and needs flash to be -1 and light to 0x03:
Code:
case FLASH_MODE_TORCH:
light = 0x03;
flash = -1;
break;
If flash is less than 1 then no control command is sent to the firmware for the flash, so we can disregard that (i think). That just leaves the light function. i'll just quote the code here:
Code:
m5mo_writeb(sd, M5MO_CATEGORY_CAPPARM,
M5MO_CAPPARM_LIGHT_CTRL, light);
m5mo_writeb is the function sending (writing) the command to the firmware, sd i believe is the device itself, M5MO_CATEGORY_CAPPARM and M5MO_CAPPARM_LIGHT_CTRL are describing where to send the value of light to, on the device. I think it's safe to say M5MO_CATEGORY_CAPPARM is correct since the flash works fine and the same constant is used for the flash control code directly below the light code. It's also used for a bunch of other functions such as capture size etc.
In C code, variables that're defined in all uppercase are usually constants, so you need to go into m5m0.h to find the value for M5MO_CAPPARM_LIGHT_CTRL. line 272 will show you "#define M5MO_CAPPARM_LIGHT_CTRL 0x40". For the sake of being sure, line 180 also has "#define M5MO_CATEGORY_CAPPARM 0x0B".
Time to check out the Infuse source code and compare...
https://github.com/Entropy512/linux_kernel_sgh-i997r/tree/master/drivers/media/video
first of all m5m0.c, line 1411 you'll find m5m0_set_flash. The layout of the function is slightly different, it's still a switch case, but instead of using temporary variables to hold the values to send the flash and light, the values are just sent within the cases themselves. Anyhow, the light control section:
Code:
case FLASH_MODE_TORCH:
err = m5mo_writeb(client, M5MO_CATEGORY_CAPPARM, M5MO_CAPPARM_LIGHT_CTRL, 0x03);
CHECK_ERR(err);
break;
Again no command is sent to the flash, only the torch, and that value is 0x03 again. The same function and arguments are being sent as with the i9100 code earlier, so all that's left is to check the constants being used. Time to hop to m5mo.h for the infuse.
Line 183 "#define M5MO_CATEGORY_CAPPARM 0x0B" matches our i9100 driver. Line 282 "#define M5MO_CAPPARM_LIGHT_CTRL 0x40" matches our i9100.
Now there are some differences between the m5m0_set_flash functions and also in the m5m0_writeb functions for the two devices, but the values they're using to control the light are the same in both cases.
One thing of interest is that the infuse doesn't support autoflash which is light 0x04 and flash -1. However if you hook up the phone to your pc, run ADB and use the camcorder in low light or any flashlight apps, you can use dmesg to verify 0x03 is being sent, as the dmesg output will contain "m5m0_set_flash: E, value 0x03".
Essentially i think this rules out it being a driver issue. I mean i could be wrong, but it looks like the flashlight control values are identical for both devices. It seems like the issue is within the first section of the firmware binary, somewhere.
Hopefully this is of some use to anyone looking into a fix for the SIEG01 flashlight problem.
Thanks for share your investigation Myshkinbob. Very interesting.
I do believe is an "easy" firmware fix too.
As you did, i compared both firmwares binaries and took the hope for finding the flash part in the code. Without a reference there is too many unknown data for a trial and error. I mean i tried to copy-paste some code differences in the firmwares but no succes.
Since nothing looks broken i will keep trying...
It'd be good to get SGS II simulator on Windows. Without it, it's PITA to load every time APK into phone and reboot it to test one variable lol
Something occured to me this morning, that might help if people are trying to hex edit the firmware binary to fix the flashlight.
Rather than messing with SIEG01 trying to enable the flashlight, you could get far more success editing SCEF02 to disable the flashlight. How so?
Well it's common sense that it's far easier to break something than to fix it.
Apply that logic to this firmware, it's a lot easier to replace a specific working value with a random wrong value, than it is to replace a specific wrong value with a specific working value.
What i mean is it'll be a lot easier to break the working flashlight in SCEF02 than guess the right value for SIEG01. Once you break SCEF02 you'll know where the flashlight control values are in the firmware, and from there you can attempt to insert them into SIEG01.
By FF'ing out small sections of the SCEF02 firmware prior to the boundary section around the 16000 offset, testing the firmware on the phone, then repeating, you could eventually get to where you break the flashlight for it. I'd suggest working back from the face detection copyright notice at the beginning of that 16000 boundary.
Once you break the flashlight in SCEF02, you've just identified which part of the firmware controls the flashlight.
From there it'd just be a matter of locating that similar section within SIEG01, and further narrowing down the specific values(s) that need correcting.
I'm not saying it'd be guaranteed to work, but it'd be an approach worth trying if people are already attempting random hex edits on the firmware.
I guess the success of it depends on the structure of the binary, whether it's a raw assembly code executable image referencing memory and register addresses, or some sort of packed OS image that is expanded and then runs on the camera chip with it's own driver embedded into it for the flashlight.
wish i could help somehow...
Myshkinbob said:
Something occured to me this morning, that might help if people are trying to hex edit the firmware binary to fix the flashlight.
Rather than messing with SIEG01 trying to enable the flashlight, you could get far more success editing SCEF02 to disable the flashlight. How so?
Well it's common sense that it's far easier to break something than to fix it.
Apply that logic to this firmware, it's a lot easier to replace a specific working value with a random wrong value, than it is to replace a specific wrong value with a specific working value.
What i mean is it'll be a lot easier to break the working flashlight in SCEF02 than guess the right value for SIEG01. Once you break SCEF02 you'll know where the flashlight control values are in the firmware, and from there you can attempt to insert them into SIEG01.
By FF'ing out small sections of the SCEF02 firmware prior to the boundary section around the 16000 offset, testing the firmware on the phone, then repeating, you could eventually get to where you break the flashlight for it. I'd suggest working back from the face detection copyright notice at the beginning of that 16000 boundary.
Once you break the flashlight in SCEF02, you've just identified which part of the firmware controls the flashlight.
From there it'd just be a matter of locating that similar section within SIEG01, and further narrowing down the specific values(s) that need correcting.
I'm not saying it'd be guaranteed to work, but it'd be an approach worth trying if people are already attempting random hex edits on the firmware.
I guess the success of it depends on the structure of the binary, whether it's a raw assembly code executable image referencing memory and register addresses, or some sort of packed OS image that is expanded and then runs on the camera chip with it's own driver embedded into it for the flashlight.
Click to expand...
Click to collapse
interesting approach indeed
it'll be a lot easier to break the working flash on SCEF02, problem is, it's gonna take a lot of time since it's based purely on trial and error
suzaku said:
interesting approach indeed
it'll be a lot easier to break the working flash on SCEF02, problem is, it's gonna take a lot of time since it's based purely on trial and error
Click to expand...
Click to collapse
I'm pretty sure that's how samsung codes anyway, we're just lending them a hand in doing so. haha
how's it going guys? any news?
wish I could help but I'm a complete noob
just thought id bump the thread to get some attention...
btw, does the firmware actually improve camera quality? for pics that is...
blunted09 said:
just thought id bump the thread to get some attention...
btw, does the firmware actually improve camera quality? for pics that is...
Click to expand...
Click to collapse
Well this firmware really improves the overall quality of the pics but in shooting vids it really shines. Only thing so far missing is flash light during video capturing.
I would have moved to SIEG03 if it had had support of LED
me too, flashlight is a little bit to important for me

epd_optimizer recommendations thread

So Marshmallow uses this new format for configuration files for apps on the EPD. Maybe we can start collecting recommended configurations for various apps? I noticed that the default files it comes with don't include the Kindle app this time, tho it had a default config in the old LP settings.
So, if you've found good settings for a particular app, please post them here! And I might go look on the Russian site to see if there are any there already - tho if one of the Russian-speaking users here wants to do that first I wouldn't complain
edit: I just found an app for editing the new configuration files, it's by x2009xxx on this hi-pda thread. Attaching for convenience. The button at the bottom to save the configuration and the toast that pops up when you do so aren't in English, but all the options are, so I'm pretty sure you can figure it out. (Don't forget to reboot to activate your changes)
I am wondering is there possibility to set epd to full refresh after 5 pages or every page. There is no sign in readme file. I tried adding ""slowmode" : true" in the configuration cfg but notting happens.
I'm not sure, but I have gathered that you have to reboot for changes to take effect.
Sent from my YD201 using Tapatalk
I know, when I change something (ex. dithering, sharpening etc.) there is effect but problem is that i don't see command which can set full refresh of epd screen after some interval (previously it was slowmode). I'm using moon+ reader (white letters on black background) and without full refreshing after some pages ghosting is terrific and reading seems to be nearly impossible.
Remove the Android GUI transitions/effects on Developers Menu, not only makes your phone faster but it also helps EPD to have less ghost when using the other Android Apps, and folders...
I just edited the first post to add a tool I found for editing the config files.
ahigienix said:
I know, when I change something (ex. dithering, sharpening etc.) there is effect but problem is that i don't see command which can set full refresh of epd screen after some interval (previously it was slowmode). I'm using moon+ reader (white letters on black background) and without full refreshing after some pages ghosting is terrific and reading seems to be nearly impossible.
Click to expand...
Click to collapse
I'm looking at the readme.txt that lives in the epd_optimizer directory, and the option that sounds related to what you're talking about is "update_timeout - timeout of fullscreen update after content change. Use -1 to disable."
Tried to change update_timeout value. There are some changes in update mode but EPD still not doing full refresh (like in Yotareader for example). Still after flipping some pages black background is full of gray shades from previously viewed pages. Tested on CoolReader, Moon+ FBreader, Allreader.
Is there anyone who figured out how to set full refresh of EPD in any book reader?
Nice thread, I had in mind creating one like this. I haven't played with the configuration file yet, but I can post here what I found from other xda posts and a file from Russian Telegram group.
For Whatsapp (but I think it should work also on other similar apps) a configuration found here is the following:
Code:
{
"name": "com.whatsapp",
"description": "WhatsApp",
"dithering": "ATKINSON_BINARY",
"update_timeout": -1,
"sharpening": 2,
"contrast": 0,
"brightness": -5,
"stretch_black": 50,
"stretch_white": 220,
"regional_update": false
}
For Vkontakte (VK - Russian social network) I found this one:
Code:
{
"name": "com.vkontakte.android",
"description": "VKontakte",
"update_type": "GRAYSCALE",
"dithering": "ATKINSON_BINARY",
"update_timeout": 0,
"sharpening": 1.0,
"contrast": 50,
"brightness": 10,
"stretch_black": 50,
"stretch_white": 200,
"regional_update": true
}
Maybe we could develop some configurations for groups of apps: chat, social, e-book readers, office, browser, etc. and post them here!
Don't know if I'm missing something but I've tried all sorts of different values for dithering, update type, contrast, brightness, stretch_black, and stretch_white but after restarting nothing seems to have any effect. No matter what I do, everything just looks way too bright/low contrast and washed out. On the other hand, the Yotahub looks fine--deep blacks and easy to read.
This is on a YD206. Everything looked fine on lollipop. I submitted bug reports to yotadevices but they told me that the YD206 isn't supported. Anyone else having this issue? And if so, are you on YD206?
EDIT: Anyone know how to query what epd_optimizer settings an application is using? The backscreen is the only thing that looks good and AFAIK its package name is com.yotadevices.yotaphone2.launcherbs . Unfortunately there's no corresponding entry in the epd_optimizer directory.
Here is a stock EPD_optimizer folder after OTA upgrade from 5.0. Try replacing your files and reboot.
I figured out that changing values via application make a mess in cfg files. Better to check package name using app, copy some stock cfg, rename it to package name and edit via Total Commander it works fine.
I have yd206 and changing values take effect but i can't set full EPD refresh.
EDIT: Anyone know how to query what epd_optimizer settings an application is using? The backscreen is the only thing that looks good and AFAIK its package name is com.yotadevices.yotaphone2.launcherbs . Unfortunately there's no corresponding entry in the epd_optimizer directory.
Click to expand...
Click to collapse
From readme.txt
If these parameters are missing in app's configuration as well, the system will use parameters which defined in master.cfg configuration file. If this file is deleted, the system will use parameters that are stored within Android framework.
ahigienix said:
Here is a stock EPD_optimizer folder after OTA upgrade from 5.0. Try replacing your files and reboot.
I figured out that changing values via application make a mess in cfg files. Better to check package name using app, copy some stock cfg, rename it to package name and edit via Total Commander it works fine.
I have yd206 and changing values take effect but i can't set full EPD refresh.
From readme.txt
If these parameters are missing in app's configuration as well, the system will use parameters which defined in master.cfg configuration file. If this file is deleted, the system will use parameters that are stored within Android framework.
Click to expand...
Click to collapse
Thanks, I'm no longer using the app to modify the values as you suggested and changing settings has an effect now. (using vim in an arch chroot environment) Using your stock values for a separate firefox config seems to have improved things. Still not nearly as good as 5.0 but I can actually read text now.
However, there is this issue where from moment to moment the screen brightness seems to switch back and forth between two settings: a config with deeper blacks (clear) and a config that's too bright. It's almost as if there are two configs fighting for control. If I let the phone sit (so there are no screen updates), it will eventually settle on one of those configs but not reliably on any particular one--it almost seems random. I spent several hours trying a variety of different settings but I can't seem to get rid of this problem or manage a config that's comparable to 5.0.
At this point I think I'm just going back to 5.0 as I can't really put any more time into this. Maybe the problem will sort itself out in future releases but I'm not hopeful given the lack of support for the YD206.
I have three yd206, one which firmware was sideloaded from 1.1.31 had simmilar to your EPD glitchs, try to delete your epd_optimizer folder, create new one and copy files from attachment, then do a hard reset. It helped me and now this yd206 runs flawlessly.
I found the file /root/sdcard/TitaniumManager/mirror.cfg has some information similar to files in .../android/epd_optimizer and create a configuration for FBReader, but makins some test it seems nothing change.
Follow the last solution for my file org.geometerplus.zlibrary.ui.android.cfg
{
"name": "org.geometerplus.zlibrary.ui.android",
"description": "FBReader",
"dithering": "ATKINSON_BINARY",
"update_timeout": -1,
"sharpening": 1.0,
"contrast": 70,
"brightness": -10,
"stretch_black": 50,
"stretch_white": 220,
"regional_update": false
}
Have you any suggestion?
ahigienix said:
I have three yd206, one which firmware was sideloaded from 1.1.31 had simmilar to your EPD glitchs, try to delete your epd_optimizer folder, create new one and copy files from attachment, then do a hard reset. It helped me and now this yd206 runs flawlessly.
Click to expand...
Click to collapse
Hi, couldn't get this off of my mind so I took another stab at it. I've tried everything you've suggested but haven't been able to get things to an acceptable level. I've put together a couple images comparing 5.0 and 6.0 image quality (attached to this post) with the epd_optimizer .cfgs you've provided.
The two images have a few different icons on the home screen but demonstrate the difference in both brightness and clarity pretty well. I'm not saying those .cfgs didn't improve things--they definitely did (yes, it originally looked even worse than the 6.0.jpg image prior to using the .cfgs you provided) but it still doesn't look nearly as good. Looking at the 6.0.jpg image, you can probably imagine how difficult it would be to read an ebook or browse the web.
I think there's more to this than the .cfg files. Note that I upgraded to 6.0 by restoring the "MMB29M.6.0.1-RU1.1.147" backup provided in this thread via TWRP. I was coming from LRX21M.5.0.0-HK1.1.124d (I always clear the cache and dalvik between firmware changes of course).
EDIT: Whoops, I've mixed up the image names. Fixed the images.
Excuse me i do not know about changing that values for the epd
but as a person who works and edits photos the difference between the pics is remarkable in my eyes
beacuse it seems to be that there are different grey scales that are produced, especially the black value.
You can edit every photo you made into greyscale (8bit or 16bit) and it normally looks fine.
but you can also convert it into a black/white (1bit) picture with a filter like diffusion and it is more grainy.
so for me it looks that the 6.0jpg is too grainy and is not the correct grayscale. It can be washed out but the black part seems not that fine as it is in the 5.0jpg pic.
maybe this isn't that important but i want to point on that.
GetSAS said:
Excuse me i do not know about changing that values for the epd
but as a person who works and edits photos the difference between the pics is remarkable in my eyes
beacuse it seems to be that there are different grey scales that are produced, especially the black value.
You can edit every photo you made into greyscale (8bit or 16bit) and it normally looks fine.
but you can also convert it into a black/white (1bit) picture with a filter like diffusion and it is more grainy.
so for me it looks that the 6.0jpg is too grainy and is not the correct grayscale. It can be washed out but the black part seems not that fine as it is in the 5.0jpg pic.
maybe this isn't that important but i want to point on that.
Click to expand...
Click to collapse
I see, thanks for the insight. Maybe this will help with determining what's causing this.
I changed contrast in the master to 40, and I'm pretty happy with the results.
Full master file:
Code:
{
"name": "master",
"description": "This is default epd update setting. Please modify with caution.",
"update_type": "MONOCHROME",
"dithering": "STUCKI_BINARY",
"update_timeout": -1,
"sharpening": 1,
"contrast": 40,
"brightness": 10,
"stretch_black": 30,
"stretch_white": 220,
"regional_update": false,
"color_inversion": false
}
epd refresh problem
after i upgrade official stock 6.0.1 my epd stop refreshing. am i in the right place? i dont know how to change the values mentioned above. can someone help me please? thanks
lgk350tr said:
after i upgrade official stock 6.0.1 my epd stop refreshing.
Click to expand...
Click to collapse
My navigation program has the same probem. Too much ghosting. Is there a possibility, to set a refresh time? (Maybe a background program with timer and torch screen?) I can do it with developer options (show surface updates). Is it possible, to make a shortcut or start and stop it automatically?
If the yotaphone is in standby, the epd screen is constantly flashing (after 2 minutes) and I don't know, why.
I am experiencing the same. I own a YD206 converted to 201 and running lates MM OTA update.
EPD screen was fine for couple of days, but know ghosting is terrible specially when navigating thru full Android. Also black color on widgets is totally grayed out.
Right now I am trying the full discharge and leave it for couple of hours before I fully charge it.
Any other solution/suggestion on what to try? This is definetly a refresh problem which is not eliminating previous images.
Thanks

Categories

Resources