I have a A505FN with the rom A505FNXXS4BTCA - XEF. I flashed my device with the TWRP patched and the custom splash screen.
It was a success because I'm rooted now, but not whitout problem.
Since I have an important border on my device.
https://zupimages.net/up/20/20/uvwe.jpg
I have for example + 8mm of border on the bottom of the screen..And I can't remove it.
It's an important problem. I restored the rom stock, but the border remained... Could you help me ?
I taped the commande in adb dumpsys display | grep mBaseDisplayInfo
The answer is:
mBaseDisplayInfo=DisplayInfo{"Écran intégré, displayId 0", uniqueId "local:0", app 1080 x 2340, real 1080 x 2340, largest app 1080 x 2340, smallest app 1080 x 2340, mode 1, defaultMode 1, modes [{id=1, width=1080, height=2340, fps=60.000004}], colorMode 0, supportedColorModes [0], hdrCapabilities [email protected], rotation 0, density 420 (403.411 x 404.326) dpi, layerStack 0, appVsyncOff 0, presDeadline 17666666, type BUILT_IN, address {port=0}, state DOZE_SUSPEND, FLAG_SECURE, FLAG_SUPPORTS_PROTECTED_BUFFERS, removeMode 0}
Thank you
It seems to be normal for me, may it be you had a dark background image before? 8mm including the navigation bar? You can put your phone under some ligth and see the reel edges of the screen, if you see an extra black border then you have a problem .there is ~3mm buttom border in the A50 .
Looks normal to me
Related
Hi. (htc desire android 2.1)
In my app-i'm trying to show on screen values of light (lux) , but i get only few values(0-min 40, 90, 160, 225, 640, 1280-max). Is there oportunity to get much more values between 0 - 1280?? Maybe i use wrong variable. Is there a variable of sensor's current or voltage ?? Can you help me??
sensorManager = (SensorManager) getSystemService(SENSOR_SERVICE);
sensorManager.registerListener(this, sensorManager.getDefaultSensor(Sensor.TYPE_LIGHT), sensorManager.SENSOR_DELAY_GAME);
sensorManager.unregisterListener(this,sensorManager.getDefaultSensor(Sensor.TYPE_LIGHT));
outputX.setText("E:"+Float.toString(event.values[0]));
Using AndroSensor, I get the following output from my HD2:
800x480
160 dpi (custom set)
Logical Density: 1.0
X DPI: 254
Y DPI: 254
Refresh Rate: 60Hz
32-Bit colour
Which looks fine. But the One X gives:
1280x720
320dpi
Logical Density 2.0
X DPI: 345.0566
Y DPI: 342.23157
Refresh Rate: 58Hz
32-Bit colour
Why are the X and Y DPI values different? Should they not be the same for a square pixel ratio?
Also, a minor thing but why a refresh rate of 58Hz and not 60? Is AndroSensor just not reading it right?
The reason I ask about the X/Y DPI thing, is that the screen jumping bug looks like a monitor trying to autofit a non-native resolution signal, and perhaps this is related somehow?
Or are the physical pixels not square?
I have no idea but I'm going to post here so this thread is not forgotten in time cuz if this is related to the screen flickering issue (that isn't really gone with 1.28 OTA) I think it deserves more attention
Dave Trouser said:
But the One X gives:
1280x720
320dpi
Logical Density 2.0
X DPI: 345.0566
Y DPI: 342.23157
Refresh Rate: 58Hz
32-Bit colour
Click to expand...
Click to collapse
None of those DPI values are correct for the screen anyway which is roughly 312dpi.
The odd values are from DisplayMetrics in Android itself. Android tries to be device independant and a lot of the "pixel" values are actually Density Independant Pixels which need to be converted to physical pixels.
I don't think this is significant. My One X has exactly the same values and it doesn't have the screen corruption or tearing at all.
It makes sense then. The refresh rate is meant to be at 60, not 58, or else you get flicker. I remember seeing an identical problem on a monitor recently, where the refresh was slightly off 60 and caused flickering. This could be what's causing it. I will run a test on my other HTC One X that seems bug free to see if it is also running at 58. The one I'm posting from is currently doing 58.
So I've been messing around with wallpapers on my Galaxy Nexus (Jelly Bean 4.1.1). I've tried several 720x1280 and 1440x1280 wallpapers and didn't crop any of them (or rather, I selected the whole image when it prompted me to crop them).
Now we all know that the Galaxy Nexus has soft keys at the bottom (96 pixels) and a status bar at the top (50 pixels). Obviously, if selecting an image with 1280 pixels in height, parts of that image will be cropped.
There are two "logical" ways that the Galaxy Nexus can do this:
1- Crop 96 pixels from the bottom and 50 pixels from the top.
2- Average them out --> (96+50)/2 = 146/2 = 73 (crop 73 pixels from the top and bottom and display what's left in the centre).
But it doesn't seem to be doing either one of those. After messing around with Photoshop and comparing different crops, I've come to the conclusion that the Galaxy Nexus is in fact cropping a total of 146 pixels, but it's doing it backwards.
It's cropping 96 pixels from the TOP of the image and 50 pixels from the BOTTOM of the image...
Now this isn't a big deal or anything, but who decided to do it this way and why? It seems like a lot of trouble for nothing.
What's up with that?!
The same thing happens with tablet wallpapers. I don't know why either. http://www.rarst.net/hardware/android-tablet-wallpaper-size/
The link above says:
- area to the top becomes visible in applications menu;
- area to the bottom becomes visible in home screen settings menu;
Click to expand...
Click to collapse
But I don't see that at all. There is no background showing in my app drawer on my ASUS tablet. And I don't have a "home screen settings menu".
ive wondered about this too.. ive never looked into it but now you have i wanna know why they do it like this!! weird
Phhoenyxx said:
So I've been messing around with wallpapers on my Galaxy Nexus (Jelly Bean 4.1.1). I've tried several 720x1280 and 1440x1280 wallpapers and didn't crop any of them (or rather, I selected the whole image when it prompted me to crop them).
Now we all know that the Galaxy Nexus has soft keys at the bottom (96 pixels) and a status bar at the top (50 pixels). Obviously, if selecting an image with 1280 pixels in height, parts of that image will be cropped.
There are two "logical" ways that the Galaxy Nexus can do this:
1- Crop 96 pixels from the bottom and 50 pixels from the top.
2- Average them out --> (96+50)/2 = 146/2 = 73 (crop 73 pixels from the top and bottom and display what's left in the centre).
But it doesn't seem to be doing either one of those. After messing around with Photoshop and comparing different crops, I've come to the conclusion that the Galaxy Nexus is in fact cropping a total of 146 pixels, but it's doing it backwards.
It's cropping 96 pixels from the TOP of the image and 50 pixels from the BOTTOM of the image...
Now this isn't a big deal or anything, but who decided to do it this way and why? It seems like a lot of trouble for nothing.
What's up with that?!
Click to expand...
Click to collapse
Man, you got a loooooot of free time
Sent from my AOKP Nexus using xda Premium
Hi all,
first things first i dont have a problem its just a question out of curiousity.
I was i the App "Easy DPI Changer" to change the DPI scaling on my OP3 to 480.
That was when i saw the "Display Info" Page was showing a Resolution of 2064x1080, which in it self is a strange meassure.
Everywhere i checked (and how i remembered it) the OP3 & 3T where using a Panel with a Resolution of 1920x1080p.
Now my question, where are the other 144 pixel coming from?
Do i have some naughty pixels that make babys when im sleeping? (that would be the new definition of creepy though)
Or (the more likly one) is it because i dont use the on-screen Buttons and the that space is used?
Thanks in advance and happy weekend
DeMon
Your second assumption is correct. The absence of navigation bar causes the app to assume the physical screen size (or so called resolution) wrongly. Here we see the app trying to add or subtract its available pixels (for example, on yours its 1920x1080, on mine with navigation bar, it's 1790x1080).
The way I (or anyone) can know it's the navigation bar is due to the only number increasing or decreasing is the physical vertical size. So, how do we know precisely what's causing the size to increase apart from assuming it? Maths, that's what.
First, we should know that everything on your screen is displayed in a metrics known as 'dp', density-independent pixels. This metric relies on the dpi, pixel density per inch. Thankfully, this metric can be easily converted to dp, with the formula of:
px = dp * (dpi / 160)
Thanks to the peeps at the Android Developer Support Site for supplying the formula.
So, we have our formula and metrics. Let's insert the numbers.
We know the size of navigation bar is constant, 48dp, whichever or whenever you are, as long as it has a navigation nar, it's 48dp. Of course, some ROMs have a feature to resize this to your willing. But, we aren't going to factor that, we're going to what the standard says.
Then, the DPI is a pretty easy variable to figure out, it's 480.
Punch the numbers and you have:
px = 48 * (480 / 160)
px = 48 * 3
px = 144
Voilà. 144 pixels. Add this to our original vertical resolution, 1920, and we have 2064. Funny thing is that even if you set this to a different DPI, it still works. Let's try the case on mine. I have 48dp navigation bar height with 432 DPI.
px = 48 * (432 / 160)
px = 48 * 2.7
px = 129.6
Add up that 129.6 to 1790 and we'll have, well, 1919.6 but you can round that up to 1920.
I can also consider those pixels making babies, that isn't off the logic.
Cheers!
F4uzan said:
Your second assumption is correct. The absence of navigation bar causes the app to assume the physical screen size (or so called resolution) wrongly. Here we see the app trying to add or subtract its available pixels (for example, on yours its 1920x1080, on mine with navigation bar, it's 1790x1080).
The way I (or anyone) can know it's the navigation bar is due to the only number increasing or decreasing is the physical vertical size. So, how do we know precisely what's causing the size to increase apart from assuming it? Maths, that's what.
First, we should know that everything on your screen is displayed in a metrics known as 'dp', density-independent pixels. This metric relies on the dpi, pixel density per inch. Thankfully, this metric can be easily converted to dp, with the formula of:
px = dp * (dpi / 160)
Thanks to the peeps at the Android Developer Support Site for supplying the formula.
So, we have our formula and metrics. Let's insert the numbers.
We know the size of navigation bar is constant, 48dp, whichever or whenever you are, as long as it has a navigation nar, it's 48dp. Of course, some ROMs have a feature to resize this to your willing. But, we aren't going to factor that, we're going to what the standard says.
Then, the DPI is a pretty easy variable to figure out, it's 480.
Punch the numbers and you have:
px = 48 * (480 / 160)
px = 48 * 3
px = 144
Voilà. 144 pixels. Add this to our original vertical resolution, 1920, and we have 2064. Funny thing is that even if you set this to a different DPI, it still works. Let's try the case on mine. I have 48dp navigation bar height with 432 DPI.
px = 48 * (432 / 160)
px = 48 * 2.7
px = 129.6
Add up that 129.6 to 1790 and we'll have, well, 1919.6 but you can round that up to 1920.
I can also consider those pixels making babies, that isn't off the logic.
Cheers!
Click to expand...
Click to collapse
Wow didnt thought of this kind of extended answer. Thanks for that .
This explains so much
so long
DeMon
I didnt like everything so big on the screen, so I changed the screen density in the developer options (smallest width) from 360 dp to 411 dp, it didnt accepted 411 dp but changed itself to 426 dp instead.
Now everything is a little bit too small.
So I want something in between 360 dp and 426 dp.
But now the problem is, it doesan't accept any other numbers anymore and stucks with 426 dp.
Edit:
Ok I succesfully changed it now in adb, but is this normal that is reacts to weird, that the density in adb reflects in the phone as a completly different one?
I tried those:
density in adb | density in the phone
300 = 768
390 = 590
400 = 576
500 = 460
560 = 411 (my current)
600 = 384
Try turning off Developer options... to reset it.
Clear system cache if you have that option.
Hard reboot.
Try in safe mode if those fail.
blackhawk said:
Try turning off Developer options... to reset it.
Clear system cache if you have that option.
Hard reboot.
Try in safe mode if those fail.
Click to expand...
Click to collapse
Sorry, I just edited my msg.
But you can read again.