-
Notifications
You must be signed in to change notification settings - Fork 21
Blank screen before reaching login prompt #231
Comments
Possibly something to do with the EDID in your particular monitor, and the way that (AIUI) the EDID gets parsed differently in the 32-bit (by firmware-code) and 64-bit (by userland-code) OSes? |
Kernel version being used for your 32 bit and 64 bit installs please. |
I've found a few posts on that and they're talking about editing »config.txt« & as one comment to that; |
32bit = 5.10.103-v7l+ But both SD-cards I've used since February have upgraded from previously kernel-versions several times. and btw; THX to the both of you responding to this ! :))))) |
There should be no difference in 32-bit vs 64-bit. Obviously there may be differences between 5.10 and 5.15 kernels (especially as 5.10 is likely buster and so fkms, and 5.15 is likely bullseye and kms). |
Right, I think the difference between fkms and kms is probably what I meant, but I wasn't aware that the split was along 5.10 / 5.15 and not 32-bit / 64-bit. Please excuse my ignorance 😉 |
eehmm ok IDK if I can help with the following addendum; I know it's not related to this thread but; In hoping all above is received as being meant with only good intentions ! :) |
There are constant changes to the software in this area (because even major monitor manufacturers seem unable to get EDID's correct in some cases), so have you tried the latest Raspberry Pi OS to see if this has been fixed? For the phone thing, please use the forums where it will get a much bigger audience. |
This is almost certainly unrelated, and should be reported in a separate issue. As said earlier this is almost certainly not a 32-bit vs 64-bit issue but a buster vs bullseye issue, and my guess would be a fkms (the default on buster) vs kms (the default on bullseye) issue. If you want to progress this issue, I'd suggest you find a spare sdcard, and try installing the latest bullseye image, first 32-bit and then 64-bit and without changing anything, report the behaviour (e.g. does boot end with a blank screen, and does powering display off and on again fix it?) |
I have run the latest (64bit) since July & I update it every week
I have no idea where to go with that - as I said; I know it's not related - now I add; maybe it helps to understand the issue ? |
Maybe I explained to poorly ? :)
and I started out in my very first post here stating it is NOT an issue with the 32bit version ! :)))
So it seems the 32bit thing by now is off the table ? :) |
and you posted:
which means you are testing a much older (likely buster) 32-bit image compared to the newer (likely bullseye) 64-bit image. I believe the age of the image is more significant than it being 32-bit or 64-bit.
Correct. If you want to get support you need to follow the requests. An image you have been running since the summer has likely had numerous settings changes and packages installed that may be contributing to your issue. We want to know if a clean, new image has the issue. And in addition is the issue present on a 32-bit image and/or a 64-bit image. |
ehmm not likely ? :) Currently my kernel is 5.15.76-v8+ I really don't grasp your request - I started this thread based on a clean new 64bit image & a VERY 'used' older 32bit image So will above change your request to me ? |
Not necessarily. A 32-bit image can be either Buster or Bullseye, a 64-bit image will be Bullseye. See https://www.raspberrypi.com/software/operating-systems/ for all the different download options. (32-bit Buster images are now Legacy)
64-bit, so likely to be a Bullseye image.
An old 32-bit install, so likely to be a Buster image. Note that an old "upgraded" 32-bit Buster image (Debian 10) is still very different from a 32-bit Bullseye image (Debian 11). This is why people have been asking you to test a new install (of 32-bit Bullseye) on a spare SD card, as this will help narrow down whether the problem is due to a difference in Buster vs. Bullseye, or due to a difference in 32-bit Bullseye vs. 64-bit Bullseye. |
.. ok ... I'm gonna volunteer for that approach then ... and basically 'ignore' everything else in this thread except;
I really fail to see HOW I should have seen/known/'guessed' I were expected to do that testing ! :( |
The way github issues work is they pop up in notifications when someone creates one or comments, and they usually get a response from a dev here. Usually that triggers a response from original reporter and they appear back in notifications for another cycle. There is also a lower priority task for us to trawl through older issue seeing if they have been resolved and can be closed or if additional information is needed to progress them. But time is limited. This issue ended with comments from a couple of devs with no response, so fell into the low priority task. In future, if an issue is still affecting you, and the issue seems stalled, then a "I'm still getting this issue, anything I can do to help?" message is fine. Even better if you have discovered any additional information that will help narrow it down. In addition to testing a clean 32/64-bit image, I would be curious if changing: It's just a guess, but that switches back one of the main changes that occurred between buster and bullseye. |
and I figured that to be; they're on to this now and eventually it will yell a end result ;O
THX :) - I would've if you'd asked me to back then ! :)
That's what I 'attempted' ? :)
Jaer and that's the phone apparently tricking an USB-event ?
It is described in various fora among the one @ Raspberrypi.com on 64bit issues |
That's what I 'attempted' ? 🤷♂️
I think it's fair to assume that if there was anything that would "annul" the testing request, @popcornmix wouldn't be asking you to do these tests... |
Not in respect to the fact I failed to see back in July that I had misunderstood a lot ?
But Popcornmix asked BEFORE I made it clear ? (or not ? ;O) that switching |
It would be nice to hear @popcornmix say if he read that switching from |
It's not that difficult. @popcornmix said:
Notice that "In addition", which means that the fkms test is secondary. If that was a gating test then it would have come first. |
Yes, the test I suggested (switch kms to fkms) is still a very useful data point. I suspect your issue may be fixed by raspberrypi/linux#5317, but only if a few experiments have certain values. One of which is if a switch from kms to fkms avoids the issue. Other useful tests are when the screen is blank does it return when you: If most of the results of these tests get the display back, then I have a good idea what the issue is and there's hopefully an upcoming fix. |
sorry for not being fluent in English ;O |
test(s) done now I've used the 2022-09-22 Bullseye 32bit & 64bit images
|
No, I'm sorry - thanks for the reminder. |
Okay, this is reasonably convincing that your issue could be fixed by raspberrypi/linux#5317 It is also likely that running latest rpi-update firmware and adding to config.txt
will work around the problem (by preventing the firmware from setting up HDMI). There will be a proper fix based on the linked PR once further testing has been done. |
:) I guess I'm a wee frustrated about all this by now |
As per my 2nd post in this thread; I'd like to await the real fix
|
You may wait for the update. It may fix your issue. If you choose, you can follow my previous suggestion which, assuming it works will provide more evidence your issue is the same as the one the PR targets. That will also provide a workaround for your issue until the fix is released. |
Longer = within a few months ! :)))))
With my system 'untouched' (no rpi-update)
I have back in January 2022 tried out various work-around suggestions to modifying »config.txt« but stopped because some »apt« updates kept changing my changes in »config.txt« |
The instructions were to run |
oh well ... so far I've experienced none ;O Would be nice if what I did could 'just' be taken in as information to add to the case - I think |
Upgrading to the 20230306 kernel update is not a fix - is it supposed to be that ? |
It contains a fix for displays that remain blank when they don't see a AVMUTE clear packet (as described here). I said:
but you seemed reluctant to run the experiments that would help narrow it down, so it was never clear whether your issue was the same. |
And I just said;
[that is working (on my sys)] :)
And you seem 'reluctant' to read what I write & have written ! :)))))
I VERY much DO appreciate you and anyone else helping & working on loads of stuff What experiments have I 'failed' to read I'm asked (and reluctant) to do ? I'm VERY keen on helping to solve this issue ! - but please be ... better ? at asking/guiding what will be the next step THX in advance for all your time & help ! :) Addendum |
Still - since release in February so about time to report it ?
Booting (or rebooting) ends with a black screen & a solution that works is;
turn the screen off & back on again by pulling the power-plug. (long live »the IT-crowd« ;O)
then the login-screen appears as 'expected'.
I have a Samsung s22e391h - if I take the RaspBerry Pi over to my brother it boots just fine and dandy on his screen ...
It have never been an issue with 32bit RaspBerry Pi OS so I still run the 32 bit version :(
The text was updated successfully, but these errors were encountered: