Kodi changing resolution at startup (Kodi + fbcp problem)
I am mainly testing this using Recalbox, but the same issue has been noticed in RetroPie.

Here's some background for anyone that doesn't know what fbcp is.  fbcp is a process that clones the /dev/fb0 to /dev/fb1.  This allows me to run an LCD on /dev/fb1 and also have HDMI output on /dev/fb0 for any time I want to plug into a TV or Monitor.  This works well, EXCEPT when a process tries to change the parameters of /dev/fb0.  Then fbcp will choke and the LCD will freeze (at whatever was on screen before fbcp choked).

In this case, I don't want anything changing my HDMI resolution, even if it "changes" it to what it already was.

If I run 'tvservice -s' before starting Kodi and then again after Kodi is running, I will see the same output.  The resolution is the same, but fbcp will choke when Kodi starts.  If I don't run fbcp until after Kodi is running, fbcp will properly drive the LCD as expected, but I need to run fbcp at system startup.  Kodi isn't the only thing that I run, so it needs to be able to run whatever, then run Kodi, and then back to whatever else.

I found out that I can use tvservice in monitor mode.
# tvservice -M
Starting to monitor for HDMI events
When I run Kodi, I see this output.
[I] HDMI in DVI mode

The other processes I run do not produce any output there (unless they are set to change their resolution which will also break fbcp).

How can I get Kodi to leave the HDMI parameters alone?  It seems to be setting the HDMI to previous setting.  Can I get it to just skip trying to set it?
I'm only familiar with this stuff when using kodi as part of raspbmc (now outmoded) and OSMC.
With these, the boot process checks for a report from HDMI, and adopts defaults if there appears to be no monitor.
You can override this effect in /boot/config.txt to say
1) there is always an HDMI monitor present, despite a report otherwise
2) you can select the TV mode to use

Thanks dandnsmith!

I do set that stuff in the config.txt.  In fact, I want to be able to use this without any HDMI plugged in.  Right now, I have both plugged in for testing, but I would often only be using the small LCD (fb1).

I specifically set the HDMI resolution and force HDMI on in the config.txt, so that I can hotplug the HDMI at any time.  That all works fine.

I just need to figure out how to get Kodi to skip whatever it does to set the HDMI mode.
I'm still trying to dig, so I turned on Kodi debug logging.  I found this output that is trying to "set HDMI mode" on startup.

18:26:05 T:1926246400 NOTICE: Found ([email protected]) at 23, setting to RES_DESKTOP at 16
18:26:05 T:1926246400 NOTICE: Checking resolution 16
18:26:05 T:1926246400 DEBUG: EGL set HDMI mode (2,16)=0
18:26:05 T:1879045088 DEBUG: EGL tv_service_callback (4,2,16)
18:26:05 T:1926246400 DEBUG: EGL set resolution 1024x768 -> 1024x768 @ 60.00 fps (2,16) flags:10020004 aspect:1.00
18:26:05 T:1926246400 DEBUG: CreateWindow: Created surface of size 1024x768
18:26:05 T:1926246400 NOTICE: GL_VENDOR = Broadcom
That seems to happen in https://github.com/xbmc/xbmc/blob/d7aea7...s.cpp#L171 (line 171).

Is there a way to skip this and just use the parameters already established prior to Kodi running?
The simple solution would be to start fbcp slightly after kodi is launched. kodi will only change HDMI mode once (assuming you don't enable "adjust display refresh rate to match video").
Thanks for the suggestion, popcornmix!

Of course that would work well if the only thing I wanted to do was to run Kodi or if I always had HDMI connected.  The problem is that, if I don't run fbcp at bootup, then I can't even navigate to start Kodi.  I may want to do something else and then run Kodi.  I may not want to run Kodi at all.  If the LCD isn't functioning, then I'm pretty much dead in the water.
Ahh, popcornmix, your thought did spark a new idea, though.  I feel like this isn't a great solution, but it might be a stopgap.

If fbcp is running while Kodi starts, it will choke and put the LCD in an unusable state.  If you kill fbcp and start it a second time, it will still be unusable.


If you know that starting Kodi will fubar the LCD/fbcp, then you can gracefully exit fbcp, start Kodi, and then restart fbcp.  This works.

Now, how do I tell Kodi to start fbcp after Kodi is done with it's HDMI SetNativeResolution changes?
Simple solution is launch kodi in background, sleep a few seconds then restart fbcp.
If you wanted something more complicated you could monitor hdmi events (like tvservice -M) and restart fbcp after a change in HDMI state.
I like the idea of monitoring for the event and then restarting it after that (or after a timeout if the event doesn't occur).  The kill fbcp, start Kodi, delay, restart fbcp would also probably work just fine.

Do you happen to know why Kodi does the DestroyDispmanxWindow(); [ https://github.com/xbmc/xbmc/blob/d7aea7...s.cpp#L129 ] and then the vc_tv_hdmi_power_on_explicit_new() when the video mode is already acceptable (or the current will be the same as the new)?  This is more out of curiosity than anything else at this point.

Also out of curiosity, I was also looking at https://github.com/xbmc/xbmc/blob/8cdf25...pi.cpp#L99 which calls the aforementioned code.  In some cases there should be "No need to create a new window," but it seems that m_bWindowCreated would always be NULL on the first call, so it would always create a new window.

Anyway, I think I have enough ideas about how to go about this to work around the problem.  Thank you!
It has been a long time. but some still have the same problem.
I have a good solution to do framebuffer copy within Kodi.
It's a "Service" that starts after GUI set up.

Just see what I have done. Hope you got a clue.

1. sudo nano /etc/systemd/system/fbcp.service
Description=Framebuffer Copy



2. sudo systemctl enable fbcp.service

3. sudo reboot
just tried it with your service idea. systemctl shows fbcp is running. my 3.5" LCD just works fine with a resolution of 800x600 until the kodi splash comes, then freezes.
the fbcp service is still there according to systemctl and ps - the service wasn't started newly do to kodi's stratup as fbcp still has the same process ID
after killing fbcp it'd started again as expected (new process ID) but the LCD screen just turns black.

btw: so far I was never able to see kodi on the LCD (using the driver joy-IT-Display_Driver35a-overlay). the HDMI screen just works fine.
How about check fbcp working properly first?
In my case, I would run fbcp by SSH after all booting process completed.

If it works, next step is finding the timing to strart fbcp service.
Journelctl is useful. And systemctl will show you the name of service.

I think... the list(or order) of services could be different.
Even there may be no graphical.service.
(2019-01-23, 03:04)hs9147 Wrote: graphical.service.

graphical.target (no button for modify or delete? strict buddy...)
There must be graphical.target. maybe different run level changing process.
there is absolutely no problem with fbcp and the timing during boot. when booting, both the HDMI and LCD come up nicely. HDMI with 800x600 (/boot/config.txt) and the LCD with 480x320 resolution.
fbcpt starts as a service as expected and will be restarted if I kill it. stopping/starting fbcp with systemctl works also as expected. With journalctl I was able to proof this (thanks for the hint!)

The LCD show the RPi desktop and I can even lauch a browser or other programs - works fine on HDMI and LCD.
To get Kodi on the LCD I have to stop fbcp, start Kodi and start fbcp. That works as discussed in this thread.

In the journal I could not find any trace what Kodi is doing and when while it starts. So I have no clue where to hook on with fbcp while Kodi starts.
I got a difference of yours. My OS for raspi is OSMC.
So graphical.target calls fbcp.service once, after Kodi GUI sets up.

Another idea is using "~/.kodi/userdata/Autoexec.py". - https://kodi.wiki/view/Autoexec.py
I haven't tried and don't know the details. It was next option.

Logout Mark Read Team Forum Stats Members Help
Kodi changing resolution at startup (Kodi + fbcp problem)0
This forum uses Lukasz Tkacz MyBB addons.