Hi, i have the problem that my desire reboots in my pocket. Sometimes in my jeans, but very often when i am snowboarding. This really sucks. You want to take a quick picture and your desire is off or rebooting. Is there a chance to edit the behavior of the power button?
I also tried the lock screen with pin, but it also happens.
I use 2.3 c Leedroid. The power off or reboot thing only happens in the pocket. If i have the desire on a table or not in the jeans it never reboots. So it should not be a stability issue.
Someone with the same experience? Any advices or a patch to change the power off /reboot behavior?
Best regards
Stefan
What is the temperature of the phone in your pocket? Seems very unlikely that you actually power the phone on and off in your pocket especially if you use a pin lock screen.
When i am snowboarding it can be that the phone gets a little bit colder. But if i carry my desire in my jeans it is at normal temperature. Mostly i hear the boot sound after sitting down in my car for example. So it must have something to do with pressing the power button.
But can the temperature when snowboarding really cause the rebooting? I put the phone in the inner pocket of my jacket, so that it not gets to cold.
Best regards
Stefan
No idea how to stop this reboot / power off issue?
Have you ever deliberately tried to turn the phone off/reboot when the screen is turned off? And did you succeed?
And the phone reboots when the temperature gets to high not to low, if it gets to low it will just freeze up(not literally). So again what is the temperature of the phone in your pocked?
Ok,
thanks for the answer. Than it seems that my phone reboots. But it strange that it only happens in the packet. Ok in my normal jeans i guess its 25 degrees.
But when Snowboarding i guess it is 5 - 10 degrees in the pocket, eventually less?
Best regards
Stefan
Hi,
so today the phone reboots again in my pocket...
It reboots when i am driving in my car, or when i am out skiing. Normally it do not reboot. Prhaps it is an issue with changing the gsm cells or something.
I am pretty shure that it must be a stability issue. As written above i use LeeDroid.
Has someone a recommendation what i can use instead? Or how to make the image rock solid?
Best regards
Kai
kai-t said:
Hi,
so today the phone reboots again in my pocket...
It reboots when i am driving in my car, or when i am out skiing. Normally it do not reboot. Prhaps it is an issue with changing the gsm cells or something.
I am pretty shure that it must be a stability issue. As written above i use LeeDroid.
Has someone a recommendation what i can use instead? Or how to make the image rock solid?
Best regards
Kai
Click to expand...
Click to collapse
Usually hardware issues cause reboots..Does this happen only in your pocket?
And there is no problem with Leedroid perse..Not unless you've overclocked it, or installed one of the datato-alternatelocation patches and crapped it.
Hi,
yes normally in the pocket when travelling.
One time i had a reboot when using the phone. I use the phone since 3 month.
But when the phone is in a pocket and i am traveling a reboot happens regularly.
Waht do you mean with Overclocking? I use Set CPU. Should i restrict it to 1000 MHZ?
At the moment i set onDemand profile from 128 - 1190 MHZ.
Thanks and best regards
Stefan
LeeDroid said:
Known Issues: NONE!!
Some CPU's may struggle with higher O/C values, if you experience instablilities try a lower clock speed.
You can check the mini-site Wiki category for the latest.
Click to expand...
Click to collapse
Nice to know you read the first post of the rom thread and overclock with caution.
So yes, clock it down at least to 1152 Mhz or 1113 Mhz and if you still expiriance issues go back to 998 Mhz. Don't know if you use a screen off profile but it is also better to set the minimum to 245 Mhz.
Ok thanks, i will try and report...
Hello all,
just got my G2 and rooted and installed some different ROMs to try out. I tried a few including Virtuous Sense Fusion 3.0, the Desire Z port of the Sense, and even CM7 and SuperCM7. Currently I am on SuperCM7. When I was using the base Virtuous Desire Z /w bug fixes/enhancements, I had the standard kernel which gives the phone a moderate 1Ghz overclock supposedly with screen-off built in profiles? Anyway, my point is with that, my phone randomly rebooted once and ever since that I got off that ROM. Eventually I skipped over plain CM7 since I was having MASSIVE data issues with that, and am now on superCM7 which runs fine except that I also had a reboot occur. I was overclocked to 1113mhz in setcpu min and max and had a 245/368 min/max screen off profile enabled. Could the overclock be the problem? I did not adjust any phone voltages or anything of that nature.
Also, I googled this and saw that the "Noisy keyboard" thread under the Q&A and read about how it makes like crinkly and plasticy noises and stuff. Obviously the guy did not notice the piece of thin, film like material underneath the keyboard as that is probably the cause. But is it normal for that material to make extra noise IN ADDITION to typing? What I mean is, okay, say you press a key with like a pen, obviously you will only hear the key click down, but if you actually practically type and type somewhat relatively quickly you will hear the noise every other letter in addition to the keys going down. Is this a defect? My keys do not make any kind of noise if i just grave over them with the surface of my fingers, only when i'm typing. Is this normal for everyone?
Thanks
Today...the unthinkable happened.
I dropped my phone from about 3 feet!
Luckily, I had a case on it, and there wasn't any damage to it...cosmetically. When I went to make sure there wasn't any internal damage, I tried a SetCPU stress test, a quadrant benchmark, an antutu benchmark, and a Linpack benchmark.
SetCPU was stable, quadrant was higher than before, and linpack was about the same. However, when I got to Antutu, my score was about 1000 less than before.
Before, I got RAM=~950, CPU Integer=~1825, and CPU Float=~1427. However, now I get RAM = ~700, CPU Integer = ~1350, and Cpu Float = ~1150. Everything else was about the same.
I should also note that at the time of testing, the phone was pretty hot (100 degrees Fahrenheit). The original scores were achieved on 80-90 degrees. Would you say this is a coincidence (and it was caused by heat), or hardware damage?
Coincidence.
Sent from my Galaxy Nexus using xda premium
I can run quadrant twice, doing nothing between tests but push the start test button, and get two completely different scores.
It was the heat after all. I let it cool down to 80 degrees fahrenheit, and it's back to the normal 6000+ scores. I feel so relieved now.
Did you pick up all the binary bits from the floor? Maybe some bits fell out so phone is still busy looking for the missing bits.
Sent from my Galaxy Nexus using XDA App
You're fine. Luckily the phone was ok. I think I would crap my pants. What case are you using?
Sent from my GSM Galaxy Nexus using Tapatalk
Ulver said:
You're fine. Luckily the phone was ok. I think I would crap my pants. What case are you using?
Sent from my GSM Galaxy Nexus using Tapatalk
Click to expand...
Click to collapse
Incipio Sylicrylic
It has this awesome silicon layer that absorbs the impact.
rubiconjp said:
Did you pick up all the binary bits from the floor? Maybe some bits fell out so phone is still busy looking for the missing bits.
Sent from my Galaxy Nexus using XDA App
Click to expand...
Click to collapse
Nonphysical stuff can't fall, silly.
clichename122 said:
Incipio Sylicrylic
It has this awesome silicon layer that absorbs the impact.
Nonphysical stuff can't fall, silly.
Click to expand...
Click to collapse
Lol
Sent from my GT-P6800 using xda premium
My HTC One M8 fell by 2 feet. On the corner; has hard shell.
After this, the phone was very slow. The kind of slowliness I do not try to dig, and just reboot. Reboot took over 5mn. Then, phone kept screen off; I knew the phone was working: received a phone call; power button was working fine because long press on it could light the flash (Xposed customisation); volume buttons also work fine. After long press power+volume, I could reboot, and during reboot, the screen came one again. Screen could turn on each time I rebooted. After boot was completed, if I let screen timeout and go of, no way to turn it on again.
If I don't let screen go off, and keep it busy, and try to use my phone:
- background image animation lags a lot
- tactile screen works almost fine
- apps are responsive, but viewing on screen lags a lot.
- all system tools report a good iddle time, low load, and available CPU and RAM.
- the whole phone behaves like when it's over-heating, but temperature was low. The problem was perfectly reproductable during several hours.
- system behavior could also be compared toa computer working with full software rendering, without any hardware acceleration. CPU and RAM feel good, CPU reports iddle time, but graphics lag.
Power button was working fine on hardware side because i could use it to force reboot, and switch light on. But power button could not turn screen on. Hardware of screen was working fine, because after reboot, i could get a working screen. But, how could a simple fall produce a software issue ?
I had replaced my battery myself some time ago; so, I know that I have not glued it the way it's done at the manufactory; also I had to break tapes, and could not replace them. I have placed all screws correctly. My thoughts have been:
- CPU or GPU are not strictly overheating, but, maybe their physical connection to heat sink is bad
- maybe the battery moved a bit, and is pressing against something, deforming a heat connection, or pressing hard against a sensible component (and alter it's value)
- inertia could have pulled a cable out of it's plug; maybe there is a bad connection somewhere. Power lines had poor connexion providing too little current (or undervoltage); data line disconnected.
If the GPU is partly broken, system can fall back in software rendering, and a broken GPU may not imply a loss of screen; just switching to an other video mode.
After leaving the phone off for 1h, and rebooting 12 times, phone works perfectly fine again.
There is no way this could be a software issue.
It was a hardware issue, that had very little impact on something, and fixed itself after some hours.
May not be GPU itself, but really thinck it was "video related".
This thread deals specifically with the 'Auto brightness backlight flicker'. Which only occurs when the phone is set to 'Auto brightness'.
This does not deal with the various other screen glitches, or the constant flicker at various brightness levels when looking at grey screens.
Please do not get the two issues confused.
_____________________________________________________________________________________________
I have observed a few patterns, on two seperate handsets with the same symptoms....
*Firstly, the flicker occurs while the CPU is under load, and particularly at lower battery levels.
*Secondly, The flicker occurs momentarily when you plug in a charger.
*Thirdly, The flicker doesn't occur while the device is charging.
*Fourthly (is that even a word), The flicker is often seen immediately after a screen settles, such as when the screen stops moving after scrolling.
All of these things are evidence of a power management issue. As if the backlight voltage is not being regulated correctly.
I did some more testing over the last few hours and have found something interesting. If you go to 'Settings' - 'Developer Options' - and enable 'Show Screen Updates', your phone will blink the screen different colours whenever the screen is updated. I found that when the screen settles, the screen is updated one final time, just a moment after it has settled. This is exactly when the flicker occurs. As i see it, this is further evidence that the flicker is power management related.
It seems to me that when the CPU goes from load to idle and changes its power draw, the backlight voltage regulation does not filter these fluctuations and the backlight flickers.
The question is, can this be altered either by the power management built in to the kernel, or by other power management software? Or is it a physical design flaw in the power regulation circuit?
The fact that the fluctuation only seems to occur when the brightness is set to auto leads me to believe that it indeed can be fixed with software.
If it was a physical supply voltage fluctuation when the CPU goes from load to idle, it would surely flicker all the time, not only on Auto Brightness.
I assume that the CPU voltage is altered by the kernel as the load level changes.
My question is, if the governor is changed to one which doesn't allow the CPU to scale or voltage step, does the issue go away?
Is there anyone out there who has rooted their device and can test my theory? I don't want to root my device as I may need to send it back DOA (it's only a day old).
If you can change the governor to a profile which doesn't allow stepping or voltage adjustment (100% Voltage and Frequency all the time), and the problem goes away, we have an answer and HTC can work on developing a new Kernel to fix the issue.
Thanks!!
Sentinel196 said:
Please do not get the two issues confused.
Click to expand...
Click to collapse
It is highly likely that all the graphics issues are related. This includes various types of flickering, notification bar corruption, and strange bands in the camera app. Similar issues occurred with the Teg3 Asus Prime when it launched and all were corrected with updates. There are also some performance variations that can be seen in benchmarks when the issues are at their peak that go away when the phone's rebooted.
Nvidia, not HTC (or the devs) controls the Teg3 low-level code, drivers, and kernel. All this has been discussed in the other two threads. As has a communication from HTC UK received yesterday that they've identified the issue and will be issuing an update (not 1.29) to address it.
64 pages of flickering and graphics issues discussion here:
http://forum.xda-developers.com/showthread.php?t=1617009
Thanks for the info. I'm well aware of the other thread and have been following it closely.
Not looking to start a debate about the cause and if the problems are related. Just looking for someone to help me test my theory.
Sentinel196 said:
This thread deals specifically with the 'Auto brightness backlight flicker'. Which only occurs when the phone is set to 'Auto brightness'.
This does not deal with the various other screen glitches, or the constant flicker at various brightness levels when looking at grey screens.
Please do not get the two issues confused.
_____________________________________________________________________________________________
I have observed a few patterns, on two seperate handsets with the same symptoms....
*Firstly, the flicker occurs while the CPU is under load, and particularly at lower battery levels.
*Secondly, The flicker occurs momentarily when you plug in a charger.
*Thirdly, The flicker doesn't occur while the device is charging.
*Fourthly (is that even a word), The flicker is often seen immediately after a screen settles, such as when the screen stops moving after scrolling.
All of these things are evidence of a power management issue. As if the backlight voltage is not being regulated correctly.
I did some more testing over the last few hours and have found something interesting. If you go to 'Settings' - 'Developer Options' - and enable 'Show Screen Updates', your phone will blink the screen different colours whenever the screen is updated. I found that when the screen settles, the screen is updated one final time, just a moment after it has settled. This is exactly when the flicker occurs. As i see it, this is further evidence that the flicker is power management related.
It seems to me that when the CPU goes from load to idle and changes its power draw, the backlight voltage regulation does not filter these fluctuations and the backlight flickers.
The question is, can this be altered either by the power management built in to the kernel, or by other power management software? Or is it a physical design flaw in the power regulation circuit?
The fact that the fluctuation only seems to occur when the brightness is set to auto leads me to believe that it indeed can be fixed with software.
If it was a physical supply voltage fluctuation when the CPU goes from load to idle, it would surely flicker all the time, not only on Auto Brightness.
I assume that the CPU voltage is altered by the kernel as the load level changes.
My question is, if the governor is changed to one which doesn't allow the CPU to scale or voltage step, does the issue go away?
Is there anyone out there who has rooted their device and can test my theory? I don't want to root my device as I may need to send it back DOA (it's only a day old).
If you can change the governor to a profile which doesn't allow stepping or voltage adjustment (100% Voltage and Frequency all the time), and the problem goes away, we have an answer and HTC can work on developing a new Kernel to fix the issue.
Thanks!!
Click to expand...
Click to collapse
i like the theory, but on the 4 out of 6 handsets i've had, the flicker started off only on auto brightness, then got worse over a day or two, and then would develop into a constant flicker, regardless of backlight settings.
Well i really hope thats not the case here as I only have 10 hours left of DOA return window. :S
Sentinel196 said:
This thread deals specifically with the 'Auto brightness backlight flicker'. Which only occurs when the phone is set to 'Auto brightness'.
This does not deal with the various other screen glitches, or the constant flicker at various brightness levels when looking at grey screens.
Please do not get the two issues confused.
_____________________________________________________________________________________________
I have observed a few patterns, on two seperate handsets with the same symptoms....
*Firstly, the flicker occurs while the CPU is under load, and particularly at lower battery levels.
*Secondly, The flicker occurs momentarily when you plug in a charger.
*Thirdly, The flicker doesn't occur while the device is charging.
*Fourthly (is that even a word), The flicker is often seen immediately after a screen settles, such as when the screen stops moving after scrolling.
All of these things are evidence of a power management issue. As if the backlight voltage is not being regulated correctly.
I did some more testing over the last few hours and have found something interesting. If you go to 'Settings' - 'Developer Options' - and enable 'Show Screen Updates', your phone will blink the screen different colours whenever the screen is updated. I found that when the screen settles, the screen is updated one final time, just a moment after it has settled. This is exactly when the flicker occurs. As i see it, this is further evidence that the flicker is power management related.
It seems to me that when the CPU goes from load to idle and changes its power draw, the backlight voltage regulation does not filter these fluctuations and the backlight flickers.
The question is, can this be altered either by the power management built in to the kernel, or by other power management software? Or is it a physical design flaw in the power regulation circuit?
The fact that the fluctuation only seems to occur when the brightness is set to auto leads me to believe that it indeed can be fixed with software.
If it was a physical supply voltage fluctuation when the CPU goes from load to idle, it would surely flicker all the time, not only on Auto Brightness.
I assume that the CPU voltage is altered by the kernel as the load level changes.
My question is, if the governor is changed to one which doesn't allow the CPU to scale or voltage step, does the issue go away?
Is there anyone out there who has rooted their device and can test my theory? I don't want to root my device as I may need to send it back DOA (it's only a day old).
If you can change the governor to a profile which doesn't allow stepping or voltage adjustment (100% Voltage and Frequency all the time), and the problem goes away, we have an answer and HTC can work on developing a new Kernel to fix the issue.
Thanks!!
Click to expand...
Click to collapse
As for your first issue regarding flickering at lower power levels, have you tried accessing the power-saving settings and turning off the setting which changes brightness at lower battery levels? The method of accessing power-saving settings is outlined here: http://forum.xda-developers.com/showthread.php?t=1627517
oh well again i guess
NVIDIA PRISM Display Technology - PRISM (or Pixel Rendering Intensity and Saturation Management) reduces a mobile device’s backlight power while simultaneously enhancing the pixel color to deliver the same visual quality with substantially extended battery life.
Click to expand...
Click to collapse
http://www.nvidia.com/object/tegra-3-processor.html
Thanks. I'll test that out to see if it makes a difference too.
Still hopeful someone with root can test changing the scaling setting for the CPU.
hamdir said:
oh well again i guess
Click to expand...
Click to collapse
It's a great guess. The sensitivity of this being wonky was one of the things causing problems on the Prime. It also affected individual devices differently, was worse in certain apps, and was most prominent when the display was showing a predominantly dark background.
So how did they fix it?
Sentinel196 said:
So how did they fix it?
Click to expand...
Click to collapse
Drivers and low-level code. And it took four updates to get everything stabilized (battery usage, CPU performance/stepping, graphics). This has little to do with HTC (the XL having no similar issues) and everything to do with Nvidia.
designgears said:
Pretty sure this has to do with the crappy gfx drivers. The same thing that cause the camera to have issues and the notification bar. While I had the international one x, the phone benched really well while those problems weren't happening, but as soon as I was able to reproduce them and ran the tests again, score was reduced by a lot.
I could reboot the phone and the problems would go away, only to come back after some use.
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?t=1619432
OK. So it looks like I'm on the right track and it's hopeful that this can be fixed in future updates
Thanks for the info.
Sentinel196 said:
OK. So it looks like I'm on the right track and it's hopeful that this can be fixed in future updates
Thanks for the info.
Click to expand...
Click to collapse
There were a bunch of really smart people and quite a few established devs on the Prime forum when it launched. When these problems started to occur, everyone was equally flummoxed. The one question that never was answered is why devices with identical h/w and s/w would perform differently and react to updates differently. Clearly they shouldn't. No one believed the issues could be corrected with s/w alone. Somehow they were. Neither Asus nor Nvidia ever answered the question as to the differences in individual device behavior. I don't blame anyone here for being skeptical. Something really funky is going on with Teg3 that no one will probably every truly understand. Truthfully, if the HSPA version of the One X was S4 too I’d have preferred it.
I guess it just comes down to variation in the tolerances of components.
I used to work in mil-spec electronics design and manufacturing and even with the tightest possible manufacturing tolerances, there was always variation.
BarryH_GEG said:
There were a bunch of really smart people and quite a few established devs on the Prime forum when it launched. When these problems started to occur, everyone was equally flummoxed. The one question that never was answered is why devices with identical h/w and s/w would perform differently and react to updates differently. Clearly they shouldn't. No one believed the issues could be corrected with s/w alone. Somehow they were. Neither Asus nor Nvidia ever answered the question as to the differences in individual device behavior. I don't blame anyone here for being skeptical. Something really funky is going on with Teg3 that no one will probably every truly understand. Truthfully, if the HSPA version of the One X was S4 too I’d have preferred it.
Click to expand...
Click to collapse
there is a lot to love about the Tegra mate, h264 video playback is amazing on it, also android is on steroids thanks to T3
but yes im with you on the issues, semi accurate reported crazy silicon issues, i don't find it hard to image that the Prism feature is just a cover up too
it was added later on the nvidia specs page
So, to sum this up guys - are you closer to say that flickering problem is actually only a matter of s/w?
I'm wondering how long it'll take HTC to admit that there are real issues and then how long we'll have to wait for the possible solution - replace, repair or just update the firmware :O
Anyways, this made me a bit more optimistic, since with unlocked bootloader it'd be hard to fight for the replacement
Sentinel196 said:
I guess it just comes down to variation in the tolerances of components.
I used to work in mil-spec electronics design and manufacturing and even with the tightest possible manufacturing tolerances, there was always variation.
Click to expand...
Click to collapse
Here's my theory. Nvidia's having yield issues with Teg3 and what's shippable is functional but varies in spec to a degree. The s/w is anticipating a range of responses from the h/w and what it's receiving is outside that range causing it to bork. Nvidia's "fix" is a combination of taming the h/w via low-level code and expanding what the s/w and drivers are capable of interpreting. And because of variations between chips, it's hard to test in a lab which is why it took four updates to resolve the Prime's issues. Again, just my theory.
I also believe both Asus and HTC were victims. There's no way both companies could be so ****ty at testing to have not caught this pre-production. My second theory is that Nvidia provided hand-picked chips early on that were right on spec and consistent so all the internal testing passed and units sent to professional reviewers all behaved optimally. It wasn't until production that inconsistencies between chips started to rear their ugly heads. Add to this that Nvidia's code, their drivers, and the kernel (still GB vs. ICS on the XL) are proprietary so both Asus and HTC are 100% dependent on them to resolve these issues.
Pretty ugly if I'm right.
BarryH_GEG said:
Here's my theory. Nvidia's having yield issues with Teg3 and what's shippable is functional but varies in spec to a degree. The s/w is anticipating a range of responses from the h/w and what it's receiving is outside that range causing it to bork. Nvidia's "fix" is a combination of taming the h/w via low-level code and expanding what the s/w and drivers are capable of interpreting. And because of variations between chips, it's hard to test in a lab which is why it took four updates to resolve the Prime's issues. Again, just my theory.
I also believe both Asus and HTC were victims. There's no way both companies could be so ****ty at testing to have not caught this pre-production. My second theory is that Nvidia provided hand-picked chips early on that were right on spec and consistent so all the internal testing passed and units sent to professional reviewers all behaved optimally. It wasn't until production that inconsistencies between chips started to rear their ugly heads. Add to this that Nvidia's code, their drivers, and the kernel (still GB vs. ICS on the XL) are proprietary so both Asus and HTC are 100% dependent on them to resolve these issues.
Pretty ugly if I'm right.
Click to expand...
Click to collapse
not hard to believe
one of the advertised features of Gerfoce 6 series was the pure video decoder, the entire 1st gen batch did not even work, it was broken in the silicon and Nvidia did not admit it until much later when the series was obsolete
hamdir said:
not hard to believe
one of the advertised features of Gerfoce 6 series was the pure video decoder, the entire 1st gen batch did not even work, it was broken in the silicon and Nvidia did not admit it until much later when the series was obsolete
Click to expand...
Click to collapse
Then you'll find this fascinating. Nvidia's PR exceeds their product’s capabilities by about 2:1.
http://semiaccurate.com/2012/05/01/why-cant-nvidia-supply-keplergk104gtx680/
BarryH_GEG said:
Then you'll find this fascinating. Nvidia's PR exceeds their product’s capabilities by about 2:1.
http://semiaccurate.com/2012/05/01/why-cant-nvidia-supply-keplergk104gtx680/
Click to expand...
Click to collapse
still you cant live without them bro, in our CG industry they are pioneers now thanks to their cuda cores and language
im sure they let marketing tint their transparency but semi accurate goes too far
I got this White HTC One X from a friend who dropped it in the waters.
It boots up just fine, the digitizer works, as well as... partially... the screen
Now i got the data from it, so mission accomplished in terms of data loss. He gave it to me for free so i rooted it with the bad screen.
So now i have this rooted phone running latest stock ROM.
The screen's brightness is too low even though the brightness settings is set to maximum. After a hellova lot of testing i found out that when the device is cold, the brightness increases when i turn the screen on. And when the processor is running (ie opening an app, or rendering animations), the screen's brightness starts to get lower and lower until it just completely shuts off.
What i did was put it in the freezer to make it REALLY cold, and it works just fine for like 5 minutes until the CPU gets hot again and the screen turns black.
I tore it down, and changed the screen, but the problem is still there, so it must be some part of the motherboard.
I won't change all the motherboard because honestly i don't want to spend that much money on something older than my nexus 4
So if anyone can tell me what part exactly is responsible for the brightness IN THE MOTHERBOARD, so that i can find a way to keep it cold, it'll be very much appreciated.
PS: I can see and control everything from PC too when the screen shuts off... so i can still practically try and do anything with it. Also, the actual LCD screen is cracked and black on it's right and bottom half, and it's currently "half open" (ie i can see the Nvidia CPU, and the vibration motor under the screen)