Screen completely black after first reboot

[Melechtna]

After following the instructions for everything, once it reached the login screen, the screen goes black and nothing can be seen.

Edit: seems to be specific to the latest 5.17 kernel
Edit2: it seems to be the custom pixelbook kernel

[jmontleon]

There is no pixelbook specific kernel anymore. If you do a dnf update you should pick up 5.17.5 or later. Ensure you have the latest coreboot version before doing so. I haven't heard of this before. I'll need a lot more information if you want help.

[Melechtna]

There is no pixelbook specific kernel anymore. If you do a dnf update you should pick up 5.17.5 or later. Ensure you have the latest coreboot version before doing so. I haven't heard of this before. I'll need a lot more information if you want help.

The 5.17 kernel has the pixelbook prefix after it, so I assumed it was specifically built. What information would you need? Dmesg is honestly a mess, so I'm not sure which error is relevant and none of them seem specific enough, and I have to boot into an older kernel, as the newer one just hard crashes and reboots the device.

[jmontleon]

Have you updated the firmware recently. There are a few traces in dmesg that are fixed by updating:
https://bugzilla.kernel.org/show_bug.cgi?id=215269

[jmontleon]

#5 is another example where another trace was fixed by a coreboot update.

This is the reason updating is called out specifically:
https://github.com/jmontleon/pixelbook-fedora#update-coreboot

If you have a kernel with .pixelbook in the relase it's old and should be replaced by doing a dnf update. That's definitely the case for Fedora 36 and should be true for Fedora 35 and 34 as well as updates are in stable.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-a0f65397a3
https://bodhi.fedoraproject.org/updates/FEDORA-2022-fd85148be2

[jmontleon]

The last kernel I built was 5.17.4.
https://copr.fedorainfracloud.org/coprs/jmontleon/pixelbook/packages/

This is about the point at which coreboot 4.16 became available, which fixes the typec problem. The only difference for the last several versions was that the pixelbook kernels didn't build the typec module so folks didn't have to blacklist it.
https://mrchromebox.tech/#home

There is supposedly a kernel fix in place as well, but it is not complete as I called out here:
https://bugzilla.kernel.org/show_bug.cgi?id=215269#c8 and others have basically confirmed here:
#28

To summarize:

• Be sure you're using the right hardware and this repo makes sense for you: https://github.com/jmontleon/pixelbook-fedora#required-hardware
• Update the firmware to the latest 4.16 if you haven't: https://mrchromebox.tech/#fwscript
• Run a dnf update to get the latest kernel

[Melechtna]

Have you updated the firmware recently. There are a few traces in dmesg that are fixed by updating: https://bugzilla.kernel.org/show_bug.cgi?id=215269

I set all this up the day I posted this. Meaning I installed Mr. Chromebox's firmware the day of (meaning yes, its' the 4.16). It pulled the 5.17.4-301.pixelbook kernel using your instructions, and the only other kernel it has is the 5.14 kernel. It's not pulling anything else using dnf, and yes it's a Pixelbook EVE.

Also, weirdly enough, the person that's primarily using this machine SOMEHOW got it to boot that kernel once, but can't tell me how, and everything was working, until I tried updating again (still pulled no new kernel) and rebooting, and it's back to a black screen on boot.

[jmontleon]

There is no pixelbook specific kernel anymore. If you do a dnf update you should pick up 5.17.5 or later. Ensure you have the latest coreboot version before doing so. I haven't heard of this before. I'll need a lot more information if you want help.

The 5.17 kernel has the pixelbook prefix after it, so I assumed it was specifically built. What information would you need? Dmesg is honestly a mess, so I'm not sure which error is relevant and none of them seem specific enough, and I have to boot into an older kernel, as the newer one just hard crashes and reboots the device.

Can you share the dmesg output. If you see problems there it's probably the place to start.

[Melechtna]

There is no pixelbook specific kernel anymore. If you do a dnf update you should pick up 5.17.5 or later. Ensure you have the latest coreboot version before doing so. I haven't heard of this before. I'll need a lot more information if you want help.

The 5.17 kernel has the pixelbook prefix after it, so I assumed it was specifically built. What information would you need? Dmesg is honestly a mess, so I'm not sure which error is relevant and none of them seem specific enough, and I have to boot into an older kernel, as the newer one just hard crashes and reboots the device.

Can you share the dmesg output. If you see problems there it's probably the place to start.

How do I get a dmesg from the 5.17 kernel that isn't working (except when I'm not looking)?
dmesg.txt
Here's the one for the 5.14 kernel that is working.

[Melechtna]

There is no pixelbook specific kernel anymore. If you do a dnf update you should pick up 5.17.5 or later. Ensure you have the latest coreboot version before doing so. I haven't heard of this before. I'll need a lot more information if you want help.

The 5.17 kernel has the pixelbook prefix after it, so I assumed it was specifically built. What information would you need? Dmesg is honestly a mess, so I'm not sure which error is relevant and none of them seem specific enough, and I have to boot into an older kernel, as the newer one just hard crashes and reboots the device.

Can you share the dmesg output. If you see problems there it's probably the place to start.

journalctl.txt
from the 5.17 using journalctl

[jmontleon]

Sorry, maybe I misunderstood. You said dmesg was 'a mess'. This implied to me you were seeing traces and problems.

And example of what this would look like:
#5 (comment)

I don't see anything like that in the above. Did you see something in particular?

And a stupid question: The brightness keys don't do anything? The backlight was broken and full on (or off if you set it) until 5.16. https://github.com/jmontleon/pixelbook-fedora#other-distributions / https://gitlab.freedesktop.org/drm/intel/-/issues/3680

If somehow the brightness is turned all the way down that might in part account for why the display is working with 5.14.

If you run sudo dnf clean all && sudo dnf -y update I'd be curious of the output on that too. To be clear there's no reason 5.17.4-301.pixelbook.fc35.x86_64 shouldn't to my knowledge work. The difference in the kernel config amounts to https://github.com/jmontleon/pixelbook-fedora/blob/main/kernel/kernel-config.patch. It is curious that you aren't getting 5.17.5 or 5.17.6 as an update though.

[jmontleon]

If you have doubt about the brightness keys functioning you can cat / echo to /sys/class/backlight/intel_backlight/brightness. For example full brightness appears to be: echo 32767 > /sys/class/backlight/intel_backlight/brightness.

[jmontleon]

For yum contents of /etc/yum.repos.d/_copr\:copr.fedorainfracloud.org\:jmontleon\:pixelbook.repo might be interesting too. Make sure no priority is set that would cause older packages from there to take precedent over new packages. Even sudo dnf clean all && sudo dnf -y update --disablerepo=copr:copr.fedorainfracloud.org:jmontleon:pixelbook just for curiosities sake.

[Melechtna]

For yum contents of /etc/yum.repos.d/_copr\:copr.fedorainfracloud.org\:jmontleon\:pixelbook.repo might be interesting too. Make sure no priority is set that would cause older packages from there to take precedent over new packages.

I normally use Arch, I have no idea how I'd even check that with Fedora, this is just the only project that actually has this device working and I'm tired of trying to get it to work on Arch. I'll try disabling your repo.

The blacklight buttons don't work, it cleaned 68 files and said there was nothing to do, brightness there is set to 1500, I'll try setting it to 32767 and reboot.

Edit: won't let me echo that value into it, says it's an invalid argument.
Edit2: says no repository found, and I know your repo is there, else I wouldn't have the console commands. So I have no idea why it's not finding it.

[jmontleon]

The blacklight buttons don't work, it cleaned 68 files and said there was nothing to do, brightness there is set to 1500, I'll try setting it to 32767 and reboot.

Memory is fuzzy, but 1500 sounds like the value from the 5.14/5.15 kernels. Boot into the 5.17 kernel and try. Same wtih the brightness keys. They won't do anything on 5.14. Brightness was not functional until 5.16.

[jmontleon]

Run this and you should get new kernels. Unfortunately the README instructed to lower the priority. I'll probably end up deleting the kernel package from the repo so folks can get updates like they're supposed to.

sudo dnf config-manager --setopt 'copr:copr.fedorainfracloud.org:jmontleon:pixelbook.priority=99' --save

[Melechtna]

The blacklight buttons don't work, it cleaned 68 files and said there was nothing to do, brightness there is set to 1500, I'll try setting it to 32767 and reboot.

Memory is fuzzy, but 1500 sounds like the value from the 5.14/5.15 kernels. Boot into the 5.17 kernel and try. Same wtih the brightness keys. They won't do anything on 5.14. Brightness was not functional until 5.16.

How do I do that when it doesn't boot? I also said that it doesn't work, I meant in the 5.17 kernel. It STILL claims that repo doesn't exist, even though I've been through and tried re-adding it twice now.

[jmontleon]

Can you ssh into it? The dmesg output suggests it's booting OK.

[Melechtna]

You're going to have to explain this one to me, I have no idea how it claims it doesn't exist, when it clearly exists.

[jmontleon]

You can also just manually edit the file. Change the line priority=98 to priority=99 (or just delete it, default if its not specified is 99).

[Melechtna]

You can also just manually edit the file. Change the line priority=98 to priority=99 (or just delete it, default if its not specified is 99).

I don't know fedoras file structure for it's repositories. Where would that one be? In arch it'd just be, /etc/pacman.conf

[jmontleon]

Same place I suggested looking earlier /etc/yum.repos.d/_copr\:copr.fedorainfracloud.org\:jmontleon\:pixelbook.repo

#29 (comment)

[Melechtna]

That did it. It's now updating to the 5.17.6 kernel, and it's booting with the same issue. Let me try SSHing in.

[Melechtna]

Well, good news, I can SSH in, I can echo the value for brightness, but the screen remains black...just brighter black.

[Melechtna]

dmesg.txt
here's the dmesg from the new kernel. The parts that I'm THINKING are relavent, maybe, are

[ 88.283356] snd_soc_skl 0000:00:1f.3: ASoC: error at soc_dai_trigger on HDMI2 Pin: -32
[ 88.283363] Kbl HDMI Port2: ASoC: trigger FE cmd: 1 failed: -32

[jmontleon]

Those are audio related
https://www.kernel.org/doc/html/latest/sound/soc/index.html#

I have those as well and as far as I know mostly harmless.

$ dmesg | grep ASoC
[    5.472929] snd_soc_skl 0000:00:1f.3: ASoC: no sink widget found for AEC Capture
[    5.472933] snd_soc_skl 0000:00:1f.3: ASoC: Failed to add route echo_ref_out cpr 7 -> direct -> AEC Capture
[    5.472941] kbl_r5514_5663_max kbl_r5514_5663_max: ASoC: Parent card not yet available, widget card binding deferred
[   13.827324] snd_soc_skl 0000:00:1f.3: ASoC: error at soc_dai_trigger on HDMI2 Pin: -32
[   13.827331]  Kbl HDMI Port2: ASoC: trigger FE cmd: 1 failed: -32
[   14.221872] snd_soc_skl 0000:00:1f.3: ASoC: error at soc_dai_trigger on HDMI1 Pin: -32
[   14.221878]  Kbl HDMI Port1: ASoC: trigger FE cmd: 1 failed: -32

[jmontleon]

What's the value in /sys/class/backlight/intel_backlight/brightness

[jmontleon]

/var/log/Xorg.0.log or whatever Wayland logs to could be potentially informative.

[Melechtna]

xorg.txt
Here's that, and in even weirder news, I figured out how he got it working. So, if it's left alone long enough to go to sleep, and woken back up, the screen starts working again.

Edit: Looks like at 10.950 it's failing to find and ignoring the device initially.

[jmontleon]

/sys/class/backlight/intel_backlight/brightness is set to a reasonably high value?

The end of your Xorg.log looks like you attempted to change VT, but otherwise doesn't have any errors.

I have several lines similar to what you're seeing and I think they're just noise:

[    10.471] (II) No input driver specified, ignoring this device.
[    10.471] (II) This device may have been added with another device file.

[jmontleon]

In my Xorg.0.log it finishes up like this. I don't see similar in yours, which is interesting... hard to guage whether it's a difference in Xorg between Fedora 35 and 36 or something more meaningful.

[    12.295] (II) modeset(0): EDID vendor "SHP", prod id 5258
[    12.295] (II) modeset(0): Printing DDC gathered Modelines:
[    12.295] (II) modeset(0): Modeline "2400x1600"x0.0  252.75  2400 2448 2480 2560  1600 1603 1613 1646 -hsync -vsync (98.7 kHz eP)

[Melechtna]

/sys/class/backlight/intel_backlight/brightness is set to a reasonably high value?

The end of your Xorg.log looks like you attempted to change VT, but otherwise doesn't have any errors.

I have several lines similar to what you're seeing and I think they're just noise:

[    10.471] (II) No input driver specified, ignoring this device.
[    10.471] (II) This device may have been added with another device file.

I literally didn't do anything other than wake it up. On boot, there's nothing, so that change in VT must be what's making it work again. As for it's current value it returns 6553, it's set pretty low at the moment.

[jmontleon]

3283 is the lowest it went before I couldnt see anything anymore; 6553 would hopefully be visible.

echo 32767 > /sys/class/backlight/intel_backlight/brightness would probably work now, but if you can't see anything now I'm not hopefully?

Do you know what display manager you're using? If you're not even getting a login prompt maybe a different one would give different result.

sudo dnf -y install lightdm
sudo systemctl --force enable lightdm
sudo reboot

If the systemctl command produces output I'd be interested in seeing it, especially if that gets you a login prompt if you're not getting one now.

[jmontleon]

Looks like you're using sddm with the breeze theme from the journal log you attached above. There's some interesting bugs regarding blank screens with sddm after kernel updates, but nothing I could pinpoint as likely to be your exact situation. And nothing I can reproduce on Fedora 36.

https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&query_format=advanced&short_desc=sddm&short_desc_type=allwordssubstr

Trying lightdm or another as an alternative would be interesting.

[Melechtna]

3283 is the lowest it went before I couldnt see anything anymore; 6553 would hopefully be visible.

echo 32767 > /sys/class/backlight/intel_backlight/brightness would probably work now, but if you can't see anything now I'm not hopefully?

Do you know what display manager you're using? If you're not even getting a login prompt maybe a different one would give different result.

sudo dnf -y install lightdm
sudo systemctl --force enable lightdm
sudo reboot

If the systemctl command produces output I'd be interested in seeing it, especially if that gets you a login prompt if you're not getting one now.

Yeah, I can turn it full bright if I want to, I'll try lightDM and report back. I thought that SDDM thing was a long dead issue. Or is it because Fedora too commits the cardinal sin of keeping it's shit WAY too out of date?

[Melechtna]

Looks like you're using sddm with the breeze theme from the journal log you attached above. There's some interesting bugs regarding blank screens with sddm after kernel updates, but nothing I could pinpoint as likely to be your exact situation. And nothing I can reproduce on Fedora 36.

https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&query_format=advanced&short_desc=sddm&short_desc_type=allwordssubstr

Trying lightdm or another as an alternative would be interesting.

Swapping to lightdm as you describe has seemed to make the issue worse, I can now no longer recover after putting it to sleep and waking it back up.

[Melechtna]

After trying several times, the screen came back up, and lightdm failed with an exit code of 'exit-code', which also prevents it from connecting to wifi, so I can't SSH into it anymore either.

[jmontleon]

Last version of sddm released appears to be 0.19.0.
https://github.com/sddm/sddm/

I was able to reproduce your issue. It's definitely sddm. Specifically sddm 0.19.0 with the sddm-breeze theme.

Fedora 36 has a patched version https://bodhi.fedoraproject.org/updates/FEDORA-2022-cb655b9b47 that fixes https://bugzilla.redhat.com/show_bug.cgi?id=2070130 but it seems it wasn't updated on Fedora 35. I downgraded to the prior version of the package on Fedora 36 and same issue.

Choices:

• You could probably rebuild it for yourself for Fedora 35. Be roughly:

sudo dnf install rpmbuild
rpm -ivh https://kojipkgs.fedoraproject.org//packages/sddm/0.19.0^git20220321.e67307e/2.fc36/src/sddm-0.19.0^git20220321.e67307e-2.fc36.src.rpm
sudo dnf builddep -y ~/rpmbuild/SPECS/sddm.spec
rpmbuild -ba ~/rpmbuild/SPECS/sddm.spec
sudo dnf -y install ~/rpmbuild/RPMS/x86_64/sddm-0.19.0^git20220321.e67307e-2.fc35.x86_64.rpm ~/rpmbuild/RPMS/noarch/sddm-x11-0.19.0^git20220321.e67307e-2.fc35.noarch.rpm

• File a bug and wait for them to fix it.
• Update to Fedora 36. There's a few ways to do this. My typical approach is something like, this but there are other documented approaches.

sudo dnf -y update --releasever=36
sudo reboot
sudo dnf -y distro-sync
sudo dnf -y update

You can switch back to sddm sudo systemctl --force enable sddm

[jmontleon]

If you can't get logged in via lightdm reboot:

• At the grub menu hit e to edit one of the kernel entries (changes aren't persistent)
• At the end of the kernel command line change rhgb quiet to rhgb quiet systemd.unit=rescue.target.
• Ctrl-x to boot.
• Log in with root password at prompt
• run systemctl enable sddm --force
• reboot.

[Melechtna]

Last version of sddm released appears to be 0.19.0. https://github.com/sddm/sddm/

I was able to reproduce your issue. It's definitely sddm. Specifically sddm 0.19.0 with the sddm-breeze theme.

Fedora 36 has a patched version https://bodhi.fedoraproject.org/updates/FEDORA-2022-cb655b9b47 that fixes https://bugzilla.redhat.com/show_bug.cgi?id=2070130 but it seems it wasn't updated on Fedora 35. I downgraded to the prior version of the package on Fedora 36 and same issue.

Choices:

• You could probably rebuild it for yourself for Fedora 35. Be roughly:

sudo dnf install rpmbuild
rpm -ivh https://kojipkgs.fedoraproject.org//packages/sddm/0.19.0^git20220321.e67307e/2.fc36/src/sddm-0.19.0^git20220321.e67307e-2.fc36.src.rpm
sudo dnf builddep -y ~/rpmbuild/SPECS/sddm.spec
rpmbuild -ba ~/rpmbuild/SPECS/sddm.spec
sudo dnf -y install ~/rpmbuild/RPMS/x86_64/sddm-0.19.0^git20220321.e67307e-2.fc35.x86_64.rpm ~/rpmbuild/RPMS/noarch/sddm-x11-0.19.0^git20220321.e67307e-2.fc35.noarch.rpm

• File a bug and wait for them to fix it.
• Update to Fedora 36. There's a few ways to do this. My typical approach is something like, this but there are other documented approaches.

sudo dnf -y update --releasever=36
sudo reboot
sudo dnf -y distro-sync
sudo dnf -y update

You can switch back to sddm sudo systemctl --force enable sddm

I'll try switching over to 36, because lightdm is not only doing the same thing, it NEVER comes up in the first place, making it not connect to the internet. After doing all that, I'm still getting the same issue after a reboot.

[jmontleon]

This isn't Pixelbook related. Looking at the BZ and duplicates it looks like this issue with sddm plagues a lot of hardware (Thinkpad T480, T580, etc.).

If there's something you spot that is specific I can do something about let me know, otherwise the best I can recommend is using Fedora 36 and updating to the latest version of sddm, with which I can't reproduce the issue.

[Melechtna]

This isn't Pixelbook related. Looking at the BZ and duplicates it looks like this issue with sddm plagues a lot of hardware (Thinkpad T480, T580, etc.).

If there's something you spot that is specific I can do something about let me know, otherwise the best I can recommend is using Fedora 36 and updating to the latest version of sddm, with which I can't reproduce the issue.

Then explain why lightdm not only has the SAME issue, but actually crashes irreparably and REFUSES to start period. Because I DID that.

[jmontleon]

I don't know. I use lightdm. It works fine for me. Perhaps it's a bug in Fedora 35 or something is misconfigured on your system. You will need to do some troubleshooting. If lightdm doesn't work for you use gdm, lxdm, kdm, xdm, or one of the myriad other display managers. If you want to use sddm I can confirm the most recent version works on Fedora 36.

I can reproduce your sddm issue with a specific version and point to bugs that show others with other hardware that have experienced the same. I get you're frustrated, but there are several people who have successfully set up Fedora using the instructions here. There is plenty of evidence of that. https://github.com/jmontleon/pixelbook-fedora/issues?q=is%3Aissue

If you dislike or are finding it difficult to troubleshoot on Fedora you can always use Arch or reinstall Chrome OS.

[Melechtna]

I don't know. I use lightdm. It works fine for me. Perhaps it's a bug in Fedora 35 or something is misconfigured on your system. You will need to do some troubleshooting. If lightdm doesn't work for you use gdm, lxdm, kdm, xdm, or one of the myriad other display managers. If you want to use sddm I can confirm the most recent version works on Fedora 36.

I can reproduce your sddm issue with a specific version and point to bugs that show others with other hardware that have experienced the same. I get you're frustrated, but there are several people who have successfully set up Fedora using the instructions here. There is plenty of evidence of that. https://github.com/jmontleon/pixelbook-fedora/issues?q=is%3Aissue

If you dislike or are finding it difficult to troubleshoot on Fedora you can always use Arch or reinstall Chrome OS.

But I'm ON 36

[jmontleon]

If you're using lightdm look in /var/log/lightdm/lightdm.log. Maybe there is something interesting.

If you're on 36 you should have the updated sddm package. It looks like it was in the actual release. I don't have an answer.

rpm -q sddm would confirm.

As I said this version works fine for me.

$ rpm -q sddm
sddm-0.19.0^git20220321.e67307e-2.fc36.x86_64

[jmontleon]

You can also change the default target to multi-user.target and login at the prompt to try and troubleshoot. Start a dm, run startx, and see if your desktop displays...

sudo systemctl set-default multi-user.target

When you're ready to revert sudo systemctl set-default graphical.target

[Melechtna]

If you're using lightdm look in /var/log/lightdm/lightdm.log. Maybe there is something interesting.

If you're on 36 you should have the updated sddm package. It looks like it was in the actual release. I don't have an answer.

rpm -q sddm would confirm.

As I said this version works fine for me.

$ rpm -q sddm
sddm-0.19.0^git20220321.e67307e-2.fc36.x86_64

It's apparently not finding a configuration for Lightdm greeter? And the configuration generation fails.

I have the same version of SDDM you just listed

[Melechtna]

After running it manually, it's apparently an issue with xcb missing, I'm trying to figure out what needs to be installed here, but I'm not sure.

[jmontleon]

dnf install libX11-xcb xcb-util. If it says they're installed maybe dnf reinstall libX11-xcb xcb-util. Removing it wants to remove a lot of packages including sddm so it should be there.

I don't know why you'd have to reinstall. Can be a symptom of corruption, from shutting down/rebooting during an update, bad disk, or anything in between.

[Melechtna]

dnf install libX11-xcb xcb-util. If it says they're installed maybe dnf reinstall libX11-xcb xcb-util. Removing it wants to remove a lot of packages including sddm so it should be there.

I don't know why you'd have to reinstall. Can be a symptom of corruption, from shutting down/rebooting during an update, bad disk, or anything in between.

https://forum.substance3d.com/index.php?topic=29670.0 apparently it's something to do with libpng15, which was actually missing, and, new behaviour, it starts, but it's completely blank, and I still get the black screen issue where I have to close the lid, let it go to sleep, wake it up, where it stays black, but if I then ctrl + alt + "f#", it will take me to a terminal. So, this hasn't solved the issue at all, and lightdm continues to display the exact same behavior. Let me see if skipping the login screen does anything.

[Melechtna]

You can also change the default target to multi-user.target and login at the prompt to try and troubleshoot. Start a dm, run startx, and see if your desktop displays...

sudo systemctl set-default multi-user.target

When you're ready to revert sudo systemctl set-default graphical.target

Exact same behaviour.

[Melechtna]

So, one thing, and I wasn't entirely sure about this because of MrCB's instructions, did I WANT to leave the touchpad not downgraded? I doubt it's relevant, but I'm at the end of my rope here too.

[jmontleon]

The touchpad with 4.16 will almost never work after a reboot unless you install/enable the workaround service. It will work from a clean boot up. Something with i2c compatibility, possibly. It has been suggested downgrading might help with the issue, but I have not tried yet. Either way it shouldn't stop the display from working. The problem existed with old versions, but I don't think it was nearly as bad.
MrChromebox/firmware#344

Perhaps start with a clean Fedora 36 Workstation install using Gnome and see if that works. At least it will give you a baseline if it works. I know sddm can work; I don't know what is different between our two systems. Install Fedora 36 and dnf -y update should give you just about the same thing I have after running the ansible playbook, which I run to test updates pretty regularly.

I have seen people complain tapping the power button causes an instant reboot / suspend doesn't work. That's instant power off isn't relevant for Xfce. For Gnome someone shared the following for acpid: https://github.com/jmontleon/pixelbook-fedora#orientation - for others I have no idea. I honestly don't know about suspend issues off the top of my head. Suspend is terrible on lots of hardware. I always avoid it.

Honestly, first Q in the FAQ spells out what we're all getting into. If you expect perfection, stop now. For many it works well enough with all the bandaids, duct tape, and bubble gum here. https://mrchromebox.tech/#faq

[Melechtna]

The touchpad with 4.16 will almost never work after a reboot unless you install/enable the workaround service. It will work from a clean boot up. Something with i2c compatibility, possibly. It has been suggested downgrading might help with the issue, but I have not tried yet. Either way it shouldn't stop the display from working. The problem existed with old versions, but I don't think it was nearly as bad. MrChromebox/firmware#344

Perhaps start with a clean Fedora 36 Workstation install using Gnome and see if that works. At least it will give you a baseline if it works. I know sddm can work; I don't know what is different between our two systems. Install Fedora 36 and dnf -y update should give you just about the same thing I have after running the ansible playbook, which I run to test updates pretty regularly.

I have seen people complain tapping the power button causes an instant reboot / suspend doesn't work. That's instant power off isn't relevant for Xfce. For Gnome someone shared the following for acpid: https://github.com/jmontleon/pixelbook-fedora#orientation - for others I have no idea. I honestly don't know about suspend issues off the top of my head. Suspend is terrible on lots of hardware. I always avoid it.

Honestly, first Q in the FAQ spells out what we're all getting into. If you expect perfection, stop now. For many it works well enough with all the bandaids, duct tape, and bubble gum here. https://mrchromebox.tech/#faq

I think you misunderstand that phrase, I simply mean I'm running out of ideas. Also, I don't want gnome. I will however state that I never had this issue with other OS', but they also had less working, without an untold amount of time required that I unfortunately don't have right now.

[Melechtna]

Can you do me one final service, I'm looking over your PR, these need to go into grub, correct? I'm actually making remarkably good headway with Arch, and in case you ask, I'm putting a few other things off.

[Melechtna]

Well, I'm not sure if this is because I messed something up, but it's perfectly functional by my reckoning. Touchpad works, keyboard disabling works, auto-rotate doesn't, but I think this is more a KDE issue than anything else, so not worried about that, sound works, wifi works, bluetooth works, right click works on the touchpad, but not the screen, again, no big deal ultimately IMO, brightness works, the keyboard shortcuts work, except for the keyboard brightness and start button for some reason, and the pen works, but it does have an odd behavior with it's button, it opens folders when I press it, so I'm not entirely sure what it's doing there. All in all, perfectly acceptable, and no issues with the screen being black at boot.

[jmontleon]

I was able to reproduce the black screen with lightdm on Fedora 36 screwing around today. lightdm also needs lightdm-settings and lightdm-gtk-greeter-settings