raspberrypi
Blank screen before reaching login prompt
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 :(
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? ping @popcornmix and @6by9
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? ping @popcornmix and @6by9
I've found a few posts on that and they're talking about editing »config.txt« & as one comment to that; It's not a solution - it's a workaround (and adding to that; not a 'beautifull' one ;P)
Kernel version being used for your 32 bit and 64 bit installs please.
32bit = 5.10.103-v7l+ 64bit = 5.15.32-v8+
But both SD-cards I've used since February have upgraded from previously kernel-versions several times. As I said; I run daily on the 32bit and I try the 64bit at least on monthly basis now (weekly to begin with ;O) to see if an update 'fix' it ...
and btw; THX to the both of you responding to this ! :)))))
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?
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 :wink:
eehmm ok ... I know it's not the most important issue in the Raspi-world ... so would I have to go buy myself a new screen ? and how would I know which one to buy to ensure not having the same issue ? :) In short; please give a 'hint' to; if this issue will ever be looked into & will it be 2023 or 2024 ? :) (it is SO MUCH easier to be 'patient' if getting a wee information ;P) OR do I need to answer any above posts in this thread ?
IDK if I can help with the following addendum; I use my phone as a modem (USB tethering) It doesn't matter if it's connected before turning the Raspi on or not what seems to matter is; I need to hit »dismiss« to the pop-up message on the phone asking to grant access at a VERY specific time during startup I'm NOT able to recreate it 'at-will' - it is a VERY small window that 'works' ... or magically random ? ;O (it's like 1 out of 20 times I do it right) and really rare I instead get the brown screen mentioned in various other places
I know it's not related to this thread but; if I want to access the phone via the USB cable it needs to be connected to the Raspi before turning the Raspi on AND not to be used for tethering beforehand.
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.
I use my phone as a modem (USB tethering) It doesn't matter if it's connected before turning the Raspi on or not what seems to matter is; I need to hit »dismiss« to the pop-up message on the phone asking to grant access at a VERY specific time during startup
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?)
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?
I have run the latest (64bit) since July & I update it every week And the screen is somewhat ancient by now (I believe I bought it in 2015) And per below; »and I started out in my very first post here stating it is NOT an issue with the 32bit version ! :)))« thus the EDID did ok ?
For the phone thing, please use the forums where it will get a much bigger audience.
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 ? (the phone/USB - maybe - being able to 'cancel-out' the issue)
This is almost certainly unrelated, and should be reported in a separate issue.
Maybe I explained to poorly ? :) The issue is NOT an issue now-and-then AND the only thing I can point to - besides random - is hitting dismiss at the 'right' time (I'm an Asperger & believe me; I've spend A LOT of time trying to figure out what cause the issue to be present and what do not)
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.
and I started out in my very first post here stating it is NOT an issue with the 32bit version ! :)))
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?)
So it seems the 32bit thing by now is off the table ? :) Are you're saying it's not 'enough' I've run the (64bit) image from back in the summer with ALL upgrades pos ?
and I started out in my very first post here stating it is NOT an issue with the 32bit version ! :)))
and you posted:
32bit = 5.10.103-v7l+ 64bit = 5.15.32-v8+
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.
Are you're saying it's not 'enough' I've run the image from back in the summer with ALL upgrades pos ?
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 ? :) For sure 32bit is Buster & 64bit is Bullseye ?
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 Used meaning added packages Where the 32bit (older) had no issues but the 64bit (brand new) had -- and had have from back in November 2021 constantly testing new images as they were released
So will above change your request to me ? -- and could you PLEASE tell me how I should have 'guessed' that request based on the writings from July ! :)
For sure 32bit is Buster & 64bit is Bullseye ?
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)
I started this thread based on a clean new 64bit image
64-bit, so likely to be a Bullseye image.
a VERY 'used' older 32bit 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. Trying to compare 32-bit Buster to 64-bit Bullseye simply involves too many different factors.
Trying to compare 32-bit Buster to 64-bit Bullseye simply involves too many different factors.
.. ok ... I'm gonna volunteer for that approach then ... and basically 'ignore' everything else in this thread except;
could you PLEASE tell me how I should have 'guessed' that request based on the writings from July ! :)
I really fail to see HOW I should have seen/known/'guessed' I were expected to do that testing ! :( I merely point this out in order for people to learn ? :) (I have now spend a LOT of energy trying to see how I could learn & failed so far thus if anyone likes to teach me; please go ahead ;O)
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. I accept it wasn't clear that you running additional tests was desired.
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:
dtoverlay=vc4-kms-v3d
to
dtoverlay=vc4-fkms-v3d
in /boot/config.txt on your failing (bullseye/64-bit) image avoids the problem.
It's just a guess, but that switches back one of the main changes that occurred between buster and bullseye.
This issue ended with comments from a couple of devs with no response, so fell into the low priority task.
and I figured that to be; they're on to this now and eventually it will yell a end result ;O
I accept it wasn't clear that you running additional tests was desired.
THX :) - I would've if you'd asked me to back then ! :)
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.
That's what I 'attempted' ? :)
Even better if you have discovered any additional information that will help narrow it down.
Jaer and that's the phone apparently tricking an USB-event ?
In addition to testing a clean 32/64-bit image, I would be curious if changing:
dtoverlay=vc4-kms-v3dtodtoverlay=vc4-fkms-v3din /boot/config.txt on your failing (bullseye/64-bit) image avoids the problem.It's just a guess, but that switches back one of the main changes that occurred between buster and bullseye.
It is described in various fora among the one @ Raspberrypi.com on 64bit issues & I failed to write that out properly in my July 2. post SORRY It do give a work-a-round (even someone claimed one can't do that as it is ignored during boot-up) ... so will that information annul the request for testing fresh images ?
thus if anyone likes to teach me; please go ahead ;O)
That's what I 'attempted' ? :man_shrugging:
so will that information annul the request for testing fresh images ?
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...
thus if anyone likes to teach me; please go ahead ;O)
That's what I 'attempted' ? man_shrugging
Not in respect to the fact I failed to see back in July that I had misunderstood a lot ?
so will that information annul the request for testing fresh images ?
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...
But Popcornmix asked BEFORE I made it clear ? (or not ? ;O) that switching kms to fkms is a workaround
thus it is a changed situation by now ? :) ... (or not ? ;O)
It would be nice to hear @popcornmix say if he read that switching from
kms
to
fkms
is a work-around that 'fix' the issue & if he still want a test between a new clean 32bit image versus a ditto 64bit ?
THANKS in advance for help/reply ! :)
It's not that difficult. @popcornmix said:
In addition to testing a clean 32/64-bit image, I would be curious if changing: dtoverlay=vc4-kms-v3d to dtoverlay=vc4-fkms-v3d in /boot/config.txt on your failing (bullseye/64-bit) image avoids the problem.
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 https://github.com/raspberrypi/linux/pull/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: unplug/replug the hdmi cable switch display into standby and back on switch av input on display to a different source and then back again
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 As per what is written in various posts in this thread I were lead to believe that I'd be in for; First test images and then not coming closer to what the issue were then switch from kms to fkms ... oh well
test(s) done now
I've used the 2022-09-22 Bullseye 32bit & 64bit images Both images act identically ! :)
- They have the issue
- Switching to
fkmsis a work-around though after the desktop screen appears there is a flash into brown screen & then back to the desktop screen - Switching source on the screen have no result
- Pulling out the HDMI-cable & putting it back in have no result
- Pulling the power plug to the screen and turning power back on works
sorry for not being fluent in English ;O
No, I'm sorry - thanks for the reminder.
Switching to fkms is a work-around Pulling the power plug to the screen and turning power back on works
Okay, this is reasonably convincing that your issue could be fixed by https://github.com/raspberrypi/linux/pull/5317
It is also likely that running latest rpi-update firmware and adding to config.txt
hdmi_ignore_hotplug:0=1
hdmi_ignore_hotplug:1=1
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.
No, I'm sorry - thanks for the reminder.
:)
I guess I'm a wee frustrated about all this by now
I see it as obviously being about kms from what is responded to me in this thread & what I've read elsewhere
(and on top of that there's some USB thingie now with my Raspi so I have to unplug/plug the keyboard all the time)
There will be a proper fix based on the linked PR once further testing has been done.
As per my 2nd post in this thread; I'd like to await the real fix
- so that'll be in a few months time from now ? :)
- am I 'expected' to do more for now ? :)
You may wait for the update. It may fix your issue. It will likely appear in rpi-update in next week or two. It will take longer for an apt release.
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.
You may wait for the update. It may fix your issue. It will likely appear in rpi-update in next week or two. It will take longer for an apt release.
Longer = within a few months ! :)))))
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.
With my system 'untouched' (no rpi-update)
-
hdmi_ignore_hotplug:1=1doesn't work -
hdmi_ignore_hotplug:0=1works - but can give brown desktop which a reboot 'fix' (idk yet how often aprox. it's brown )
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«