chromebook_gru scarlet variant quirks: battery level not accurate resulting in shutdown when unplugged, no internal display on wake from sleep

[spoelstraethan]

Flashed the latest image I found mentioned for gru/scarlet to a microSD with the Chrome Recovery Extension after extracting the .gz and appending .bin to the name (I can't recall if it is smart enough to write from gz like it does zip files).

It booted but then just after the login screen showed up it powered off. I booted again and watched REALLY carefully and I noticed the battery icon showed as 0% just before it powered off, even though the device had at least 50% battery in ChromeOS, so it looks like something is off with the battery level detection, which I think I had run into on another distro (PrawnOS maybe?) but in that case it didn't shut down, it just didn't help you out with a valid battery level and might shut off without warning if you weren't plugged in.

The interesting thing is after leaving it plugged in on the login screen for a bit and looking up the default username and password I had to unplug the power to plug in a keyboard and it didn't immediately turn itself off. Once I was logged in it showed the battery close to where I thought it should have been at 50-60%. Oddly enough though when I plugged in the power again it took a while for a notification to pop up that the power was present, but the battery icon never reflected the fact that it was charging and seemed to be stuck at the 59% charge it last knew about. The crazy thing is it reports 55-57 hours of available battery life, probably a bad calculation about the charge vs discharge rate since it isn't detecting that correctly.

I did discover that while I could sometimes swap between power sources, when I had both the power supply and the keyboard unplugged for long (a NexDock 360 that can provide tiny amounts of power intended for a phone, not a power hungry RK3399 tablet), the system WOULD decide to shut itself down again, even though it had 57-59% battery reported by the tray icon, the PowerManager daemon must be looking somewhere else and getting bad data.

[spoelstraethan]

I'm currently doing an apt update && apt upgrade -y to get things to newer versions to see if that resolves any of the weirdness, but I have a feeling it might be the ftb or dtb or whatever file maps the hardware features for the kernel that might be slightly off. It might be good to see what PrawnOS or pmOS are doing, as I think they have had support for gru/scarlet for a while (though I'm just getting back into playing with my RK3399 stuff a little bit after doing ALarm and PrawnOS a bit on my CS10 and C100P/C101P systems a year or few ago).

[spoelstraethan]

The apt update had been going pretty well but I had to fix the "/ owned by linux" issue as it was complaining about that pretty often. I also had a case where the terminal window I was working in went away, but the apt was still working in the background so I waited a while until I could run apt upgrade -y without getting a dpkg/apt lock error and then rebooted.

While doing the update I saw something again that had happened yesterday but had been in a weird state already then so I wasn't able to fully debug. It appears when the screens go to sleep (I have the Nexdock 360 providing a second display and keyboard/trackpad/touchscreen input) and then I wake via the keyboard the N360 display wakes fine, but the tablet's screen only turns on the backlight and never fully recovers to display the desktop.

The strange thing was the tablet was working fine for quite a while from the trickle the N360 provides, but then at some point it decided that wasn't enough and shut down again. I'll have to try using a USB-C hub with PD passthrough to see if that helps avoid the shutdowns whenever I get a chance to dig into the battery weirdness.

[hexdump0815]

thanks a lot for the info - i did not play around with gru in that detail, just tried to make it work somehow so far ... there are a few systems where display sleep seems to be broken (chromebook oak, chromebook peach etc.) and my solution for now is to disable the display power management for them and just dim the display after 120 seconds via settings -> power manager -> display or by using the config for the affected images by default: https://github.com/hexdump0815/imagebuilder/blob/main/files/extra-files-bookworm/etc/xdg/xfce4/xfconf/xfce-perchannel-xml/xfce4-power-manager.xml-enabled-no-dpms-suspend

[ryjelsum]

I can confirm this set of issues is still present on scarlet (my model is 'dru-rev5', 'acer chromebook tab 10') in the current gru image, including with the cbg+ 6.6.9 kernel. Probably relevant for the power issues, some output from dmesg (mainly focusing on "power_supply sbs-9-000b"):

[   18.176491] sbs-battery 9-000b: I2C adapter does not support I2C_FUNC_SMBUS_READ_BLOCK_DATA.
               Fallback method does not support PEC.
[   18.182530] power_supply sbs-9-000b: driver failed to report `technology' property: -5
[   18.191258] hantro-vpu ff650000.video-codec: Adding to iommu group 0
[   18.191814] hantro-vpu ff650000.video-codec: registered rockchip,rk3399-vpu-enc as /dev/video0
[   18.192119] hantro-vpu ff650000.video-codec: registered rockchip,rk3399-vpu-dec as /dev/video1
[   18.212132] power_supply sbs-9-000b: driver failed to report `technology' property: -5
[   18.219435] cfg80211: loaded regulatory.db is malformed or signature is missing/invalid
[   18.219641] power_supply sbs-9-000b: driver failed to report `technology' property: -5
[   18.231695] power_supply sbs-9-000b: driver failed to report `technology' property: -5
[   18.243046] ath10k_pci 0000:01:00.0: enabling device (0000 -> 0002)
[   18.251557] ath10k_pci 0000:01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
[   18.256891] power_supply sbs-9-000b: driver failed to report `technology' property: -5
[   18.282078] power_supply sbs-9-000b: driver failed to report `technology' property: -5
[   18.298640] power_supply sbs-9-000b: driver failed to report `technology' property: -5
[   18.307485] usb 1-1: new full-speed USB device number 2 using ohci-platform
[   18.326767] power_supply sbs-9-000b: driver failed to report `technology' property: -5
[   18.353301] power_supply sbs-9-000b: driver failed to report `technology' property: -5
[   18.371063] power_supply sbs-9-000b: driver failed to report `technology' property: -5

[...irrelevant, probably... mostly about bluetooth]

[   25.122189] power_supply_show_property: 6 callbacks suppressed
[   25.122199] power_supply sbs-9-000b: driver failed to report `technology' property: -5
[   25.145875] power_supply sbs-9-000b: driver failed to report `technology' property: -5
[   25.146830] power_supply sbs-9-000b: driver failed to report `energy_full' property: -6
[   25.165746] power_supply sbs-9-000b: driver failed to report `technology' property: -5
[   25.167034] power_supply sbs-9-000b: driver failed to report `charge_full' property: -6
[   25.188461] power_supply sbs-9-000b: driver failed to report `technology' property: -5
[   25.189605] power_supply sbs-9-000b: driver failed to report `charge_full' property: -6
[   25.212415] power_supply sbs-9-000b: driver failed to report `technology' property: -5
[   25.213611] power_supply sbs-9-000b: driver failed to report `temp' property: -6
[   25.228237] power_supply sbs-9-000b: driver failed to report `technology' property: -5 

It seems to be essentially luck of the draw whether the system recognizes the battery percentage quickly enough to avoid shutting itself down.

[hexdump0815]

maybe it is an option to disable the automatic shutdown when the battery is low after bootup for a while - not sure where exactly that was defined, maybe systemd or in the powermanager of the ui ... i have a similar problem on a kukui krane tablet chromebook as well: sometimes the battery starts with 0 and it will reboot and sometimes bettery is ok - i did not find out yet what exactly the problem is ... btw. it is often normal that some properties are not properly reported by the battery, but maybe something like charge_full is problematic (not sure)

[hexdump0815]

@ryjelsum - maybe playing around with / tuning the values in /etc/UPower/UPower.conf might help to prevent unwanted shutdowns, .i.e. maybe at boot the battery does not send proper info yet and the system gets shutdown before it can start sending proper data - so playing with the Time* values in there might be worth a try i guess ...