This issue has been corrected on recent ChromeOS updates.

I also have the same issue on R11.  Dev channel, software up to date.  Keyboard does not deactivate and screen does not rotate past 180 degrees.


Version 53.0.2785.23 dev (64-bit)
Platform 8530.24.0 (Official Build) dev-channel cyan
ARC Version 3077498
Firmware Google_Cyan.7287.57.64

I just tried it on cyan with most recent dev build 53.0.2785.29, and didn't see this issue happen.

johnnychastie@, Could you try to update to 53.0.2785.29 and let me know if you can still see this?

52.0.2743.85 is the version I'm on and it's definitely still happening.  I've hard reset and no improvement.  It's like the unit doesn't recognise tablet mode at all.  The physical keyboard doesn't deactivate past 180 degrees, no onscreen keyboard is ever present and the screen does not rotate when used in tent mode.   Hardware issue?

I suspect that one (or both) of the accelerometers may be "stuck". Unfortunately you can only directly observe the lid one from the web, but check if the acceleration values at http://www.albertosarullo.com/demos/accelerometer/ are updating.

If this is the case, holding refresh and tapping power will reset the EC and I believe it should start working again. I don't believe we should be getting into this state though, adding some folks who may be able to provide more context.

Observed behaviour from:  http://www.albertosarullo.com/demos/accelerometer/ 

Acceleration values change and fluctuate too quickly to observe, but the blue ball, slides from the top left, across the top of the screen to top right, then slides down to right hand side of the screen to rest at the bottom.  This is with unit in laptop mode.  It will not move from this position again, regardless of position of laptop (tent/tablet/laptop).  

Resetting the EC has no impact on behaviour.  

Running this test on a cyan and minnie.

What SHOULD happen with the test? The blue dot appears to react to device tilt POSITION rather than acceleration. Is this just a naming issue?

I am NOT seeing any problems with either device switching between tablet and laptop modes.

Ok, I installed 52.0.2743.85 on cyan and still not able to repro. Have you seen this on other cyans?

kathrelkeld@ Do we see this behavior on today's Beta build? If not, we should consider closing this out as a no-repro.

Cannot repro here on today's beta.  Given that there's only one machine which has this problem (and it has the problem reliably), this sounds like a hardware problem.

Closing this bug - please reopen if we see more machines with this

I can the see the issue on 8530.43.0 minnie machine. The machine doesn't detect the touchview mode

i checked on 3 minnie devices and it was happening only on one device.

pbathini@, could you update your findings when running this test 
http://www.albertosarullo.com/demos/accelerometer/ on the device?
Just want to see if the accelerometers are still working.

The blue ball was not moving when i move the machine to touchview mode

Deleted: Screenshot 2016-08-05 at 9.58.11 AM.png 43.2 KB

	Screenshot 2016-08-05 at 9.58.11 AM.png 43.2 KB View Download

I have updated to M54 and cannot repro the issue. The accelerometer test works fine too.Now i again tried loading the M53 build mentioned in #12 and cannot reproduce the issue.

Jim@, can you try updating your device and see whether that fixes the issue

Both the Minnie and Cyan are properly detecting tablet mode. They have been.

Minnie on dev channel, cyan on beta.

Version 53.0.2785.47 dev
Platform 8530.43.0 (Official Build) dev-channel veyron_minnie
ARC Version 3117197
Firmware Google_Veyron_Minnie.6588.197.0

Version 53.0.2785.47 beta (64-bit)
Platform 8530.43.0 (Official Build) beta-channel cyan
ARC Version 3117197
Firmware Google_Cyan.7287.57.64

Both devices respond to tilting the device, but X and Y tilts are being handled incorrectly. If I tilt the screen left/right, the ball moves up/down and vice/versa

If I raise the left side of the device, the ball moves to the top of the page. If I tilt the top of the screen up, the ball moves to the right of the page.

Both devices react the same

Potentially another occurrence:  issue 627090 

 Issue 627090  has been merged into this issue.

At this point we have several devices (both minnie and cyan) which failed to enter TouchView mode on 8530.6.0, 8530.24.0, and 8530.43.0 and were working again on the next update.

Given that it wasn't one particular build and the fact that we have no clue why this happened, I'm reopening this bug.  It seems likely to me that this could still hit users in M53.

Thanks. We will watch for new posts on CBC.

xiaoyinh@ are you actively investigating this issue? This is currently a stable blocker.

Sorry for the late reply. I'm investigating this issue, but so far I haven't managed to get a repro. If we have a device that has the issue/log files to look into, that will be great. 

kathrelkeld@ can you please help with #23?

We cannot repro this either, but I think the severity of the bug warrants more care.

Here are some feedback reports on cyan (with logs) which sound similar:
http://feedback/#/Report/11486524919
http://feedback/#/Report/11452972555
http://feedback/#/Report/11078048266
http://feedback/#/Report/11422647243
http://feedback/#/Report/10971797814

These reports are from M53 .0, .4, and .6

From the logs:

[WARNING:accelerometer_reader.cc(238)] Accelerometer device directory is empty at /dev/cros-ec-accel

Which means that either udev rules did not create the expected symlink, or the EC firmware never wrote any data to the accelerometer directory.

@26: Looking at http://feedback/#/Report/11422647243, a missing link in /dev/cros-ec-accel is an indication that the udev rule /lib/udev/rules.d/99-cros-ec-accel.rules did not fire before chrome started.

Looking in system_logs.txt, I do not see other accelerometer related error, and cros-ec-accel driver seems to have been loaded. 

Note I am upgrading Cyan EC to support ARC++. It is not in M53, but the firmware has been upgraded on the cyan branch (7287.57.78). I haven't tested against current 3.14 kernel.
Anyway, that firmware was not installed in case 11422647243

#27 the report you link also has:

:WARNING:accelerometer_reader.cc(238)] Accelerometer device directory is empty at /dev/cros-ec-accel"

The latest offical cyan firmware is 7287.57.75, looks like we need to update cyan with .78 https://crosland.corp.google.com/log/7287.57.75..7287.57.78 and in particular https://chromium-review.googlesource.com/#/c/359413/

+gwendal please coordinate with +vwang to file a new firmware test request.  Will this be RW only or RO also ?

+gwendal, 

we do have accelerometer test during firmware qual 
https://testtracker.googleplex.com/efforts/testcase/detail/5805776?tp_id=382&result=&environment=  

Is that not enough to confirm that the accelerometer is working ?

Not sure if this is relevant, I see multiple call to cros-ec-accel and it returned 0.

2016-07-10T08:42:58.291975+02:00 INFO kernel: [ 1890.616837] calling  cros-ec-accel.1+ @ 28885, parent: cros-ec-dev.0
2016-07-10T08:42:58.291980+02:00 INFO kernel: [ 1890.616848] call cros-ec-accel.1+ returned 0 after 0 usecs
2016-07-10T08:42:58.291984+02:00 INFO kernel: [ 1890.616859] calling  cros-ec-accel.0+ @ 28885, parent: cros-ec-dev.0
2016-07-10T08:42:58.291989+02:00 INFO kernel: [ 1890.616870] call cros-ec-accel.0+ returned 0 after 0 usecs


Does this mean we need to get the latest firmware to resolve this issue? 

It implies something is up at a lower level in the stack.

snanda@ can someone on your team take a look?

c#31 is probably from suspend/resume sequence and should be ok.

Gwendal, thoughts?  Should asavery take this on?

Looking with Sameer in the log from #26, the whole cros_ec_ stack is loaded after chrome started:
[    6.541804] frecon(235): Chrome started, our work is done, exiting.
...
[    7.153287] cros_ec_lpcs cros_ec_lpcs.0: Chrome EC device registered

It is therefore understandable the links where not ready when chrome started.

I made a change to put the whole cros_ec stack as loadable modules:
set in cl/341674
reverted in cl/350050
set again in cl/350893
reverted for good in cl/358632 (in 8530.12.0).

The reason for reversal was because the factory image does not like modules (chrome-os-partner/13068#112, chrome-os-partner/54762)

This could also cause the stack to be loaded too late: Looking at the init scripts, I am not loading cros_ec_lpcs explicitly, so unless machines come with a new coreboot, the module is only loaded from user space through module dependency.

Correction, the module loading reversal is in 8530.13.0
Do we still see the issue in 8530.13.0 and after?

There's a report from 8530.24.0 in #2.  There's a report of the same behavior on Minnie with 8530.43.0 in #12, which worked after au to M54.  There were quite a few feedback reports for cyan dev channel, but they seem to stop after 8530.6.0.

Do we see this issue on the latest 8530.49.0?

kathrelkeld@ please chime in if we see any instances in the latest builds. Let us watch this one closely till a week before the stable date. At the time we need to make a call on whether we should move this to the next milestone.

I've encountered the same issue on a C100P minnie and have created a separate bug report. Should I paste that here?

re #41: please do

https://bugs.chromium.org/p/chromium/issues/detail?id=639635

THis issue seems to be on M52 and not M53. DO we have any recent occurrences on M53 beta builds kathrelkeld@? We are a week away from Stable lockdown and we need to make a call on whether we should keep this as an M53 Stable blocker.

kathrelkeld@ any concerns if we punted this to M54? We are very close to M53 stable.

FYI: Please see following bug.

* 632486: accelerometer: Do not assume trigger0 the trigger to use.
  - https://bugs.chromium.org/p/chromium/issues/detail?id=632486
  - Following CLs must be checked in for resolving OS issue for R52 and R53. (R54 is okay).
    * CL/2198543002 - Accelerometer: find trigger name
      - https://codereview.chromium.org/2198543002
    * CL/364692 - cromeos-accelerometer-init: Set trigger properly
      - https://chromium-review.googlesource.com/364692

* Test has been done at Quanta:
  Cyan_R52-8350.68.0 + FW 7287.57.64(EC 1.1.3499): OS can rotate to tablet mode.
  Cyan_R52-8350.68.0 + FW 7287.57.80(EC 1.1.3563): OS can’t rotate to tablet mode. <-- R52
  Cyan_R52-8350.68.0 + FW 7287.57.82(EC 1.1.3564): OS can't rotate to tablet mode. <-- R52
  Cyan_R52-8350.74.0 + FW 7287.57.82(EC 1.1.3564): OS can't rotate to tablet mode. <-- R52
  Cyan_R53-8530.68.0 + FW 7287.57.82(EC 1.1.3564): OS can't rotate to tablet mode. <-- R53
  Cyan_R54-8738.0.0  + FW 7287.57.82(EC 1.1.3564): OS can rotate to tablet mode. 
  Cyan_R54-8738.0.0  + FW 7287.57.64(EC 1.1.3499): OS can rotate to tablet mode

#46. This bug is unrelated with the new Cyan firmware qual.
OS rotation not working with cyan firmware is due to missing CLs in M52 and M53, but these are now in the trees. See crbug/632486.

The issue described here is much more difficult to reproduce. 

Thank you for the advice. Please ignore #46.

If this particular issue is hard to reproduce let us keep working on it but take it off the RBS list.

Still seeing this in M54, on a newly purchased R11.

Version 54.0.2840.93 (64-bit)
Platform 8743.83.0 (Official Build) stable-channel cyan
ARC Version 3433215
Firmware Google_Cyan.7287.57.82

The original symptoms are present (no onscreen KB in tablet mode), and the accelormeter test above starts in the upper left corner.. and over time bounces down (to the right of the frame) to the lower right and stays there.

Clarification: the accelerometer is behaving that way while still in laptop mode.. and it seems to go up when tilting right and stuck in the lower right when tilting left (which seems to be the wrong axises).

It sounds like your lid accelerometer is at least reporting values.

Can you try an EC-reboot? (Power+Refresh)
After that can it enter tablet mode?

Possibly a new occurrence of this reported in CBC, this time on a Flip 2 'cave'.
https://productforums.google.com/forum/#!topic/chromebook-central/YJgi65z4StQ

RE: #c53

Sorry, just discovered crbug.com/679622- Rotation and convertibility on cave is broken

Will track it there.

It looks like those two issues are the same. deduping, please break if we find out it's wrong.

I've been suffering from this issue intermittently for the past month . I am on Version 60.0.3112.80 (Official Build) beta (64-bit)

Doing a refresh button + power reset clears the issue most times but sometimes have to repeat it.

only just found this thread ..

I was wondering if this bug is active?

This issue is getting worse for me -I'm mostly resort to using the accessibility menu to turn on the onscreen keyboard
Acer R11
Version 61.0.3163.51 (Official Build) beta (64-bit) 

I am having this issue. Acer R11 60.0.3112.112 

My acer Chromebook R11 is not allowing me to rotate the screen. Also when I go-to tablet mode my keyboard does not engage, nor does the on screen keyboard appear.  

#61 Please file a feedback report with 626938 in the title.

I filed one out previously. Should I take my Chromebook in for repair or is this a system malfunction that can only be corrected by Google?

I was having the same problem, and came looking for help. I followed the instructions in comment #6, and it worked! Thank you for your help!

Hi, my chromebook has been working great until today when I noticed my chromebook no longer recognizes tablet mode. Even past 180 degrees, the chromebook physical keyboard is still active. I tried the power and refresh method but I am still having the problem. I am also updated to the latest firmware. Is there anything more I can do? Is this something that is being worked on, or is it a hardware issue?

hi, just yesterday after i installed the newest update my chrome book has been doing the same thing as whats happened in the past. i tried the methods or resolving this issue, but none have been successful. 

Hello. I am not especially tech-savvy but I wanted to add in another "me too" after experiencing the same problem as the previous two posters. Hopefully it is able to be resolved quickly, as it is messing with some of our apps. Thanks!

I have been trying to fix this all day. I have not used my chromebook in a while, so I needed to update when i powered it up. I tried resetting multiple times and nothing worked. Then, someone said something about a wireless mouse and the piece that goes into your usb port. I took that piece out and now everything works fine. 

Can confirm the above. Just removed the USB mouse receiver that was in the right side USB port, and the tablet mode worked. Tried moving it to the left USB port, and again the tablet mode would not engage. With tablet mode engaged, placing the USB receiver would disengage the tablet mode. Also, tablet mode would not engage once I paired a Bluetooth mouse. Logitech K400 Plus combination keyboard/trackpad (USB wireless) also blocked tablet mode. However, a wired USB keyboard (Alphasmart Neo) did not interrupt it. I also tried putting a USB flash drive in and the tablet mode worked fine. So it seems to be specifically a conflict with mouse input, from what I can see. Hope this helps.

Thanks for these confirmations. I checked on an older build and USB mice worked there. So it looks like this is a regression.

I've filed issue 882410 to track this. Thanks for the reports, as well as confirming that having a mouse is a cause.

We'll look into fixing this, sorry for the inconvenience!

it worked for me, thanks but i love my mouse!! i cant wait for the fix lol

Can confirm fix. Logitch USB plugin blocks tablet mode.
Doubting that this is a bug, it may well be a function.

#72 - see this bug for more details
https://bugs.chromium.org/p/chromium/issues/detail?id=884096&desc=2

Note the explanation regarding Logitech dongles:
3. More complicated - it looks like some dongles (at least Logitech ones) for external mouse and keyboard do not report correctly when they are connected or not, hence users staying in laptop mode even though they undocked and rotated to tablet mode. While in normal case this indicates the user wants full laptop environment, there is also a use case of taking a convertible and rotating it to tablet mode.