display_default_lcd=0 has no effect when using DPI LCD

[acidtech]

I am using firmware version a59fb7a74180be0111dbc5c18a37ec6df86f14a3

Setting display_default_lcd=0 in config.txt appears to make no difference. The Pi always displays to the DPI screen. I have to comment out the enable_dpi_lcd=1 line to get HDMI working again.

[6by9]

What model of Pi are you using? Are you using the legacy drivers or FKMS?

[acidtech]

Thank you for getting back to me.

I am using a model 3B. I am not using X(no desktop). My understanding was FKMS was for OpenGL, so I dont see how I could be using it but if you know how I can check let me know. Kernel is 4.19.50-v7+

Nathan Scherdin

On Mon, Jul 8, 2019 at 12:16 AM 6by9 notifications@github.com wrote:

What model of Pi are you using? Are you using the legacy drivers or FKMS?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/raspberrypi/firmware/issues/1180?email_source=notifications&email_token=AE3QXKPZI6YICTX7YPGEOTDP6LSWJA5CNFSM4H6XDYT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZMGDIA#issuecomment-509108640, or mute the thread https://github.com/notifications/unsubscribe-auth/AE3QXKIUJPU2XUN76ZYHRY3P6LSWJANCNFSM4H6XDYTQ .

[6by9]

No, KMS/DRM is an alternative to the framebuffer driver, and indeed the framebuffer API is emulated on top of KMS/DRM for compatibility reasons. Yes it also enables the ARM side GL driver, but the two go in tandem. It is the default for Pi4, hence model is critical information.

[acidtech]

I've not started work on 4B testing. That will probably be several months from now. For now I just need the 3B/B+ working. It appears it did work in 2017 but I cant find anything newer than that, referencing "display_default_lcd=0" working as expected since then.

What are the ramifications of using KFMS on 3B/B+? How do I switch to it to test? Note I can not switch to a newer kernel(yet).

Nathan Scherdin

On Mon, Jul 8, 2019 at 12:57 PM 6by9 notifications@github.com wrote:

No, KMS/DRM is an alternative to the framebuffer driver, and indeed the framebuffer API is emulated on top of KMS/DRM for compatibility reasons. Yes it also enables the ARM side GL driver, but the two go in tandem. It is the default for Pi4, hence model is critical information.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/raspberrypi/firmware/issues/1180?email_source=notifications&email_token=AE3QXKOQZ4KSIZD676UUQQ3P6OL4FA5CNFSM4H6XDYT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZOFV5A#issuecomment-509369076, or mute the thread https://github.com/notifications/unsubscribe-auth/AE3QXKMTDLVLN65IYMOCFV3P6OL4FANCNFSM4H6XDYTQ .

[6by9]

Now that we have information to work with, we can investigate.

It will be impossible to fix without updating firmware and/or kernel. How come you have updated to 4.19.50 but are stuck there? You haven't provided your firmware version (vcgencmd version).

I'm assuming you want the framebuffer on /dev/fb0 to shift from DPI to HDMI, but leave the other display available for use via DispmanX/MMAL? You should be able to add max_framebuffers=2 to /boot/config.txt to get both displays showing up simultaneously, one as /dev/fb0 and the other as /dev/fb1. Whether they switch roles using display_default_lcd=[0|1] I couldn't say without testing it.

[acidtech]

I am using Retropie. Retropie only works up to 4.19.50 currently. They are working on a Pi4/Buster port but I dont expect that to be ready for months.

I put my firmware version in the original issue post: "I am using firmware version a59fb7a74180be0111dbc5c18a37ec6df86f14a3"

Correct. I want to be able to switch between HDMI on FB0 and DPI on FB0 depending on the setting of display_default_lcd config setting. According to what I found online display_default_lcd=0 should force the HDMI display to be primary(eg on FB0).

I did add max_frambuffers=2 before I talked with you but it still wouldn't let me switch which display was on which framebuffer.

I dont actually need the second framebuffer anyway since the second is always going to be a copy of the first(using dispmanx commands to snapshot the first display to the second display). Howeverr I need the first display to always be the HDMI display.

I have already gotten mirroring the image between both displays to work, just from the LCD to HDMI, but that is going from a 320x240 display to a 1280x960 display. As you can imagine it doesn't look good.

Nathan Scherdin

On Mon, Jul 8, 2019 at 1:12 PM 6by9 notifications@github.com wrote:

Now that we have information to work with, we can investigate.

It will be impossible to fix without updating firmware and/or kernel. How come you have updated to 4.19.50 but are stuck there? You haven't provided your firmware version (vcgencmd version).

I'm assuming you want the framebuffer on /dev/fb0 to shift from DPI to HDMI, but leave the other display available for use via DispmanX/MMAL? You should be able to add max_framebuffers=2 to /boot/config.txt to get both displays showing up simultaneously, one as /dev/fb0 and the other as /dev/fb1. Whether they switch roles using display_default_lcd=[0|1] I couldn't say without testing it.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/raspberrypi/firmware/issues/1180?email_source=notifications&email_token=AE3QXKODDPGDMBE763EJ263P6ONSZA5CNFSM4H6XDYT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZOG2LQ#issuecomment-509373742, or mute the thread https://github.com/notifications/unsubscribe-auth/AE3QXKIDNHQOWJ7EANJSAM3P6ONSZANCNFSM4H6XDYTQ .

[JamesH65]

You could try the "framebuffer_priority" config.txt flag. Set that to the framebuffer you to come first.

In you case you want HDMI0, so use framebuffer_priority=2

I've just realised that this command is currently undocumented, so will endeavour to fix that.

[acidtech]

Thank you for the information. That has made some progress. Boot screen and Retropie splash screen show up on the HDMI now but emulationstation still starts on the LCD. I am looking it how to change the emulationstation default display now.

Note I tried the new setting with and without setting the max_framebuffers=2 and with and without ignore_lcd=1.

Nathan Scherdin

On Wed, Jul 24, 2019 at 4:25 AM James Hughes notifications@github.com wrote:

You could try the "framebuffer_priority" config.txt flag. Set that to the framebuffer you to come first.

In you case you want HDMI0, so use framebuffer_priority=2

I've just realised that this command is currently undocumented, so will endeavour to fix that.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/raspberrypi/firmware/issues/1180?email_source=notifications&email_token=AE3QXKOC2MCBLRP77WCCXRDQBA33BA5CNFSM4H6XDYT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2WBAEA#issuecomment-514592784, or mute the thread https://github.com/notifications/unsubscribe-auth/AE3QXKPXIU3SNRUHKZEYX43QBA33BANCNFSM4H6XDYTQ .

[JamesH65]

I suspect Emulation Station is using the dispmanx api directly, writing to a specific device, which bypasses the Linux framebuffer entirely. There may well be a flag in ES that enables you to specify which device is used. See the (just added!) docs to determine which device number writes to which display. \https://www.raspberrypi.org/documentation/configuration/config-txt/video.md, look for the framebuffer_priority section.

[acidtech]

Yes, that is my suspicion as well. I am looking through the code now. Thank you for your help.

Nathan Scherdin

On Wed, Jul 24, 2019 at 12:42 PM James Hughes notifications@github.com wrote:

I suspect Emulation Station is using the dispmanx api directly, writing to a specific device, which bypasses the Linux framebuffer entirely. There may well be a flag in ES that enables you to specify which device is used. See the (just added!) docs to determine which device number writes to which display. \ https://www.raspberrypi.org/documentation/configuration/config-txt/video.md, look for the framebuffer_priority section.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/raspberrypi/firmware/issues/1180?email_source=notifications&email_token=AE3QXKMX7AVU3SUMIK23IOLQBCWB3A5CNFSM4H6XDYT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2XMYUA#issuecomment-514772048, or mute the thread https://github.com/notifications/unsubscribe-auth/AE3QXKLXJI33QYUEE7UGLC3QBCWB3ANCNFSM4H6XDYTQ .

[acidtech]

Before I dig further can you confirm display_default_lcd=0 should still force HDMI as the default display when using a DPI LCD(eg enable_dpi_lcd=1) and when an HDMI monitor is attached, when using the legacy driver(not fKMS or KMS). Or has display_default_lcd been deprecated?

Note, my next workaround will be to try to create an SDL window and use the SDL_WINDOWID env var to force emulation station to use my window which I can create on the appropriate display but that I think is a longshot(the env var may not even be supported).

[JamesH65]

Checked the code, display_default_lcd is still there so should work as before. If you see any issues, let us know.

[acidtech]

Currently it isn't making any difference what I set it to. 1 or 0, the DPI LCD is always primary. I'm using the Jun 20th Firmware release(the one Retropie 4.5 is shipping with).

Nathan Scherdin

On Fri, Jul 26, 2019 at 1:31 AM James Hughes notifications@github.com wrote:

Checked the code, display_default_lcd is still there so should work as before. If you see any issues, let us know.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/raspberrypi/firmware/issues/1180?email_source=notifications&email_token=AE3QXKNF6ZLZ6OIVAV4OAXTQBKY4ZA5CNFSM4H6XDYT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD234T6Q#issuecomment-515361274, or mute the thread https://github.com/notifications/unsubscribe-auth/AE3QXKK7CH7UFTBWI4ELZBDQBKY4ZANCNFSM4H6XDYTQ .

[JamesH65]

Got some time to look at this again. By primary do you mean fb0? What functionality are you specifically expecting?

[acidtech]

Basically, I want to enable the DPI LCD but not have it as the primary display. I will then clone the hdmi display to the DPI display. I can already do this in the other direction(DPI cloned to hdmi) but that is upscaling from 320x240 to HDMI which looks pretty horrible. Downscaling from HDMI will look much better.

Currently, the display_default_lcd has no effect on Retropie 4.5. This appears to be using the latest RPi firmware at the time of release(see my earlier posts with the firmware information).

However, Retropie released a 4.5.1 update where they reverted back to an older kernel(4.14.98-v7+)/firmware(Mar 27 2019 15:45:53, 2e98b31d18547962e564bdf88e57b3df7085c29b) and I've been able to get that version working. But eventually(a couple months I expect) they will update back to the latest kernel/firmware and I will still need this functionality.

Thanks for any help you can give me.

Nathan Scherdin

On Mon, Aug 5, 2019 at 3:02 AM James Hughes notifications@github.com wrote:

Got some time to look at this again. By primary do you mean fb0? What functionality are you specifically expecting?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/raspberrypi/firmware/issues/1180?email_source=notifications&email_token=AE3QXKMIGIFLEVXU2BB35I3QC73D3A5CNFSM4H6XDYT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3RKT3Y#issuecomment-518171119, or mute the thread https://github.com/notifications/unsubscribe-auth/AE3QXKIAIPABGYDDY2IZY4DQC73D3ANCNFSM4H6XDYTQ .

[sylvanoMTL]

I have the same need, but unfortunately I cannot find any supporting ressources

[acidtech]

For now I don't know of any workaround.

Nathan Scherdin

On Mon, Feb 10, 2020 at 2:24 PM sylvanoMTL notifications@github.com wrote:

I have the same need, but unfortunately I cannot find any supporting ressources

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/raspberrypi/firmware/issues/1180?email_source=notifications&email_token=AE3QXKI2SAVGMIMGYACK7MDRCHHYFA5CNFSM4H6XDYT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELKQY4I#issuecomment-584387697, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE3QXKNF3SJVWTFNJWANUMTRCHHYFANCNFSM4H6XDYTQ .

[acidtech]

Got some time to look at this again. By primary do you mean fb0? What functionality are you specifically expecting?

By primary I meant it booted to the LCD whether I set this to 1 or 0 if DPI was enabled. Only by disabling DPI could I get HDMI to display the bootscreen. The point of this whole thing was I want to be able to copy the higher resolution HDMI screen to the lower resolution LCD(640x480). Instead of copying the LCD screen to the HDMI screen, which is all I could get working previously. This results in a fuzzy HDMI screen, hence the desire to boot to the HDMI and be able to copy the HDMI screen to the LCD. Note I use dispmanx for this so there isnt a need for a second framebuffer(fb1).

Note I have not updated to the latest release yet. I am just getting back on to this project. Once I've caught up I'll let update this thread with the current status.

[erys]

I am also hitting this same issue with display_default_lcd=0 having no effect. The framebuffer_priority workaround changes the boot screen but not the screen for other programs that use the default.

[rodrigo455]

disable the lcd driver in config.tx and try adding it after boot up with dtoverlay command. something like: sudo dtoverlay dpi24 the issue sounds like a display order provided by linux. The first one would be the first used by the applications.

edit: this dtoverlay command won't work. the order might come from the linux driver itself

edit: another idea: change the order that the drm connectors get initialized: https://github.com/raspberrypi/linux/blob/rpi-5.4.y/drivers/gpu/drm/vc4/vc4_firmware_kms.c#L1652

@acidtech can you share the dispmanx code to clone the display? or any detail regarding the vcdispmanx* api you used.

[acidtech]

We edded up using HDMI1(not HDMI0) in our case so in the end I didn't bother finishing the code to duplicate the HDMI to the LCD. Only HDMI0 and DPI can be active at the same time.

This is the best source for information on dispmanx that I found. https://github.com/AndrewFromMelbourne/raspidmx

Nathan Scherdin

On Wed, Mar 16, 2022 at 2:43 PM Rodrigo Alencar @.***> wrote:

disable the lcd driver in config.tx and try adding it after boot up with dtoverlay command. something like: sudo dtoverlay dpi24 the issue sounds like a display order provided by linux. The first one would be the first used by the applications.

@acidtech https://github.com/acidtech can you share the dispmanx code to clone the display? or any detail regarding the vcdispmanx* api you used.

— Reply to this email directly, view it on GitHub https://github.com/raspberrypi/firmware/issues/1180#issuecomment-1069665172, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE3QXKPBV3DMX5JSNXZIMR3VAJIZFANCNFSM4H6XDYTQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[rodrigo455]

Thanks for the lead @acidtech. Here's the project that fits perfectly: https://github.com/AndrewFromMelbourne/raspi2raspi from Andrew as well.