Re: RPi4 Workstation edition - Dsplay goes to sleep -logged or unlogged- and won't wake up!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > Thank you for the great work on an unofficially supported platform -yet.
> >
> > Before filling a bug, I was wondering if you were aware of this issue/workaround.

Please ensure all bugs are linked against the ARMTracker as a blocker bug.

> > A quick search on BZ yield nothing...
> > Luckily, SSH access wireless or not still possible.
> > FWIW, a few weeks ago, I was able to blindly switch to a virtual console, login and initiate reboot/shutdown, but that doesn't seem to do the trick anymore.
>
> I have the same problem on Pinebook (not the pro).  I'm not sure
> what module is the problem.
>
> It used to work on f32.  Similar problems on older Intel laptops since
> upgrading to f34 as well, so maybe something about systemd or Xorg
> server (not the drivers)?

It's extremely unlikely to be the same problem. These problems tend to
be HW/driver specific and and even be affected by the model of screen
and the quirks of it's EDID and other such things.

Without the hardware in front of someone the bug reports need to be
extremely accurate with lots of details, things like "It used to work
on f32" are like trying to hunt for needles in a haystack.

The work I do is extremely limited to my personal time these days and
I tend to focus that limited time on feature enablement, like making
the Pinebook Pro work. I try to dig into regressions where ever
possible but they need to have a reasonable amount of information so
that I can begin to even know where to start. The bare minimum would
be to the likes of "it worked with 5.21.4 but stopped with 5.12.5" or
"worked with mesa 21.0 and not with 21.0.3", exact make/models of
screens etc. Elsewhere with the little time that the few of us that do
HW enablement have to deal with these things are better spent on
enhancements.

Sorry for being a little blunt here but mostly trying to set
expectations. There's very few people that actively work on the cheap
Arm HW enablement in Fedora and those that do primarily do it in our
spare time. When we do we do it upstream so the entire ecosystem can
benefit. So unfortunately unless it's HW we can actively reproduce
with, and while I have RPi HW I don't actively test graphics because
the fully accelerated graphics stack isn't upstream (#1 reason why
it's not officially supported in Fedora) and I have 2 screens which
don't seem to exhibit the issue.

Peter
_______________________________________________
arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/arm@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux ARM (Vger)]     [Linux ARM]     [ARM Kernel]     [Fedora User Discussion]     [Older Fedora Users Discussion]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Maintainers]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Tux]     [Yosemite News]     [Linux Apps]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]

Powered by Linux