Suspend fixed in C720/Peppy ROM

As the name implies, suspend is fixed in the C720/Peppy ROM’s. Turns out I had forgotten to conditionalise/remove something from the board’s DSDT, which I didn’t forget for Falco/HP Chromebook 14.

Additionally, I have updated all the other Haswell Chromebook ROM’s to make sure the DSDT is suitable in those.

Jeltka has also had i915 frame buffer support added, so even if something is wrong with the graphics ID/ROM, you can still easily get the display to work. There’s probably something else in there which escapes me, but that seems like enough for the moment.

31 thoughts on “Suspend fixed in C720/Peppy ROM”

  1. Suspend is working great without any module blacklisting, nice work! :).

    I do now have an issue with xbacklight not working, saying “No outputs have backlight property”. Can anyone test backlight control after flashing this updated rom?

    1. It works in the bog standard 3.10 kernel that comes with CentOS 7, but not in 3.15.7 or 3.17.rc1 that I compiled myself. In the latter case there is no /sys/class/backlight/intel_backlight and I can’t figure out why not. I guess it’s most likely because of something missing from my .config, but even using the config from 3.10, it still doesn’t work (I guess the needed options could’ve changed names or something, and not been switched on by make oldconfig).

  2. You might need a quirk applied. The backlight stopped working by default in 3.15-rc2. It may work on Acer C720, HP 14, and Toshiba CB35, some of which may have quirks. All others will probably fail because of a misconfigured VBT.

    The output of “lspci -vn|grep -C 1 VGA” would help us rule things in or out more precisely, though.

  3. Here’s the output on a Toshiba:

    00:02.0 0300: 8086:0a06 (rev 09) (prog-if 00 [VGA controller])
    Subsystem: 1179:0a88

    The four (4-digit) numbers shown are sometimes called the PCI vendor, device, subvendor and subdevice ID’s.

    All four id’s need to match for the quirk to be applied. In intel_display.c you can see the last three of the four id’s listed. (Assume the first id is always 8086, which means Intel.)

    So your output shows 8086:0a06:8086:0a06 instead of something like I posted, which shows 8086:0a06:1179:0a88. From what I’ve seen, the subvendor and subdevice numbers of the sequence will vary based on manufacturer. Some newer C720’s (i3 4005U) will have device id 0a16 instead of the older (2955U) 0a06. These will also have a quirk soon.

    Can you set these id’s in the firmware builds?

  4. Peppy ~ $ lspci -vn|grep -C 1 VGA

    00:02.0 0300: 8086:0a06 (rev 09) (prog-if 00 [VGA controller])
    Subsystem: 103c:21ed

    Acer C720 / 2955U = Peppy

    Does anybody has the internal microphone working on the Acer C720 / 2955U?

  5. The expected id pairs are

    Acer C720 and C720P (2955U)
    8086:0a06 1025:0a11

    Acer C720 (4005U)
    8086:0a16 1025:0a11

    HP Chromebook 14 (2955U)
    8086:0a06 103c:21ed

    Toshiba CB35 (2955U)
    8086:0a06 1179:0a88

    The backlight on the Haswell Chromebooks won’t work unless one of these sets of four id’s above is detected. And there is no patch in the kernel for the Dell 11 yet.

    A better fix would be to correct the VBT (Video BIOS table). If the VBT reported a backlight present, then there would be no need to match these device id’s.

    1. That worked. I see there’s some information on the libreboot website regarding extracting the self-modified VBT from an X60/X230. I’ll have a fanny around with that and see if the VBT magically updates itself when the backlight is enabled. I assume if that worked I would be able to put that into the ROMs, assuming I haven’t got the wrong end of the stick.

    2. I think the VBT solution is a bit beyond me. I guess if it’s really needed the coreboot devs will implement it across the board (or boards if you prefer haha). There was talk to that effect in the Gerrit patch for the X230.

      Just going to stick with the subsystem ID’s for the moment. Is there any particular reason you know of that I couldn’t use the same ID’s across the Haswell boards, so that the Dell 11 (Wolf) ROM will have back-light now?

  6. Kernel parameter “drm.debug=14” adds detail in dmesg:

    This shows the VBT thinks there is no backlight:
    [drm:parse_lfp_backlight] PWM backlight not present in VBT (type 0)

    When the VBT says there’s no backlight but a quirk is applied, this will be logged:
    [drm:intel_panel_setup_backlight] no backlight present per VBT, but present per quirk

  7. My falco has the 2nd rom build on it (when the script was first introduced), and it turns itself on every time it plug it in to charge. Needless to say, this has resulted in opening up to a low battery more than a few times. Is this normal?

  8. Not sure what is affected by the id’s. Also if someone said they had a particular machine but reported id’s for a different machine on a forum or such…

    I wonder if the Dell has a correctly configured VBT because I haven’t heard any complaints.

    1. As opposed to the situation they have now with my ROMs where it comes up as 8086:whatever? If it had caused much of an issue, I’m sure someone would’ve said. It’s only coming up now because people are starting to use 3.15.x kernels.

      Maybe. Or, maybe no one’s noticed/cared to speak up about missing back-light. Or, not many people can see the point of putting Linux on when you’re restricted to the non-upgradeable 16GB SSD.

  9. Wasn’t trying to be negative, just a genuine observation from someone who has heard quite a bit from the owners of the Acer’s and HP’s (without your firmware).

    And not at all an observation about the firmware you provide, I think everyone is grateful for it!

    1. I didn’t think you were being negative, and I realise that most people are grateful. I really appreciate your input too, as I wouldn’t have realised what the backlight issue was about without your input. :)

Leave a Reply