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]));
Related
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.
Instrument: Spyder4 — LCD (generic)
Correction: EDR for OLED created with primaries R, G, B, White <OLEDFamily_20Jul12.ccss>
Measured luminance: 268.8 cd/m²
Profile whitepoint XYZ (normalized): 246.12 258.29 285.13 (95.29 100 110.39), CCT = 6572K
Measured black luminance: 0.4969 cd/m²
Contrast: 541:1
Measured vs. assumed target whitepoint ΔE*00: 0.62
Average ΔE*00: 0.91
Maximum ΔE*00: 1.77
✔ Nominal tolerance passed
✔ Recommended tolerance passed
XYZ Lut + Matrix
How to add to FireFox
about:config ->
gfx.color_management.display_profile -> /sdcard/jem.icm
gfx.color_management.enablev4 -> true
gfx.color_management.mode -> 1
Restart FireFox
This profile improves shadow detail, highlights, removes the green tint and corrects gamma.
http://petapixel.com/2012/06/25/is-your-browser-color-managed/ - Verify that its working
You can compare with the default browser at http://www.lagom.nl/lcd-test/all_noprofile.php
Rec709 Bt.1886 video profile coming when an android video player finally supports icc or 3d lut.
Hi All!
Kindly share your KCAL settings here
Like this:
Kernel - my kernel - IceMan ( not for public )
OS - LineageOS build myself
My settings:
Red 216
Green 222
Blue 256
Saturation 65
Value 129
Contrast 129
Hue 0
Thank you!
250
240
255
40
132 (140)
132 (140)
10
Red 235
Green 248
Blue 256
Saturation 52
Value 132
Contrast 138
Hue 0
Tianma Panel
Excellent idea to open a thread like this. If anyone has a Kcal profile which makes blacks blacker, whites whiter and colors more vivid, please share your profile. :3. I'm on an LOS based rom by the way.
What app are you using to control the KCal?
techlogik said:
What app are you using to control the KCal?
Click to expand...
Click to collapse
Elementalx app its fine, but also required custom kernel for kcal.
240,240,256,50,130,132,0
Whiter screens
Sent from my HTC 10 using XDA-Developers Legacy app
Hmm, I think I found a profile which I like. I used the DarkDroid profile as the base and changed one value.I only changed saturation.
Red: 250
Blue: 250
Green: 256
Saturation: Default is 45 but I changed it to 65
Value: 120
Contrast: 145
Hue: 0
As different type of panel is available and implemented on our beloved HTC10, shouldn't we share what type of panel too ? it's easily available using DevCheck app
I don't think applying settings from a panel to a different brand is really productive.
It's like calibrating a Sony TV and applying the resulted calibrating profile to a Samsung one, just because models share the same IPS panel ? Hmmmm no !
Btw this topic is an excellent idea !)
Fre$h said:
As different type of panel is available and implemented on our beloved HTC10, shouldn't we share what type of panel too ? it's easily available using DevCheck app
I don't think applying settings from a panel to a different brand is really productive.
It's like calibrating a Sony TV and applying the resulted calibrating profile to a Samsung one, just because models share the same IPS panel ? Hmmmm no !
Btw this topic is an excellent idea !)
Click to expand...
Click to collapse
You are right; I have updated my post
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 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