Forum

Full Version: disable_overscan=1 not working
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I've just installed a fresh XBian 1.0 alpha 4, with my TV connected over HDMI. The default config.sys appears to disable overscan, but I still have it present on boot. The Raspberry logo and kernel output are clipped, as is XBMC once it starts.

I've also been testing Rasbmc with a different SD card on the same setup, and it has no problem disabling overscan. If I remove the option I get a similar amount of clipped image to XBian.

I've not read any other reports of similar issues. I'm considering just copying the FAT partition contents from the working setup, but wasn't sure if the XBian files included specific settings.

Is there something simple I'm missing, or could try?
We don't have any influence on the config.txt option, that's all raspberry pi firmware. So i doubt there would be any difference in behavior in OE, Raspbmc and XBian.
I had a bit of a hack, and found that using start.elf from Raspbmc and everything else from XBian gave the correct (lack of) overscan on the earliest kernel boot display. Though it ran into trouble later during bootup. Using almost all the Raspbmc boot binaries got further, but still gave a black screen on starting XBMC.

Reverting back to the original XBian files, I tried forcing CEA resolutions in config.txt but the overscan was still bad. Though an accidental hdmi_group=2 gave me 640x480, and overscan was correct there. The only trouble was that XBMC was also stuck at that resolution, with no other video modes available for selection.

I guess I need to learn a bit more about the boot file difference between the two distros. I also don't understand why a seemingly successful boot would give a black screen on starting XBMC (a known issue with earlier builds I believe?).

It could also be a quirk with my TV (Panasonic TH-37PX80B), but it seems odd it's only XBian affected.
Probably because we use the very latest firmware and kernel versions possible. So, when it comes to those files, it mostly are issues caused by the Raspberry Pi foundation, so you need to file your issues there as well. Not much we can do.
just out of con a bit
I have Pana TV and I never needed to use any overscan or any other extra video settings as all works out of box
Have you tried on your TV to force 16:9 aspect mode ? Dont use auto but force it manually.
Thats the way how I have it here and never had any issue with resolution
Cool
(16th Jan, 2013 10:34 AM)CurlyMo Wrote: [ -> ]We don't have any influence on the config.txt option, that's all raspberry pi firmware. So i doubt there would be any difference in behavior in OE, Raspbmc and XBian.

Could you clarify please. Are you saying that XBian no longer makes changes to the config.txt file? AFAIK it has in the past. For example, to set the initial overclocking to 840 MHz.

(16th Jan, 2013 10:17 AM)obo Wrote: [ -> ]I've just installed a fresh XBian 1.0 alpha 4, with my TV connected over HDMI. The default config.sys appears to disable overscan, but I still have it present on boot. The Raspberry logo and kernel output are clipped, as is XBMC once it starts.

I've also been testing Rasbmc with a different SD card on the same setup, and it has no problem disabling overscan. If I remove the option I get a similar amount of clipped image to XBian.

I've not read any other reports of similar issues. I'm considering just copying the FAT partition contents from the working setup, but wasn't sure if the XBian files included specific settings.

Is there something simple I'm missing, or could try?

To be honest, the term overscan doesn't mean much to me in practicality terms. However I notice that when running in 720p mode on my Sony Bravia, the on-screen display elements such as audio volume and the control buttons at the bottom of the screen, display partially beyond the visible part of the screen. I suspect this is what most people refer to as overscan but at the same time I think a lot of people may use the term incorrectly.

Anyway, I suspect this issue may be more related to the following Playback setting

Quote:
  • Sync playback to display
    • This setting enables syncing the video to the refresh rate of the monitor.

and/or

Quote:
  • Adjust display refresh rate to match video
    • Defines when the refresh rate adjustments should take place.

Although the term "refresh rate" is used, I strongly suspect this actually refers to display mode or resolution, colour depth AND refresh rate. My suspicions are based on watching smaller resolution video and having the monitor drop into 720p mode (which the Bravia helpfully informs the user it is doing this by an OSD message that I suspect other displays don't show you). Then when I play higher resolution video, or the low-res video stops and the XBMC screens appear again, the display switches back to 1080p mode.

Do you have the same symptoms?

I'd like to test this theory of mine through the tvservice utility and I'll add some instructions in here on how to do that if anyone is interested.
We can't influence what setting you can or cannot set through the config.txt and if they work, that's determined by the Raspberry Pi firmware. However, that does not mean we don't use and/or set the settings.
I do use the "Adjust display refresh rate to match video" option, and find it does switch from the 720p UI to 1080p video as required. That was a relief as my TV panel is 720p but for some reason only supports 24Hz with a 1080p input.

I'd be surprised if the Wide setting makes a difference, as I'm using it fine with other Pi distros. It's easy to check though, so worth a go. As it happens I did have a look through the other TV settings for mentions of overscan, as I think the 42" model has additional options controlling SD/HD content. I couldn't find anything controlling it on mine though.

I can probably manage for now using the video adjustment to fix the overscan within XBMC. Though I would still like to get to the bottom of the issue, if only so I can use the console after exiting XBMC — I'm currently missing a text row from top/bottom, and 4 characters left/right, which makes editing on the device a bit awkward. I can ssh in, but it either means doing it on my phone or going upstairs to my PC.

It does look like it's a firmware issue, so I'll see if I can narrow down the revision it was introduced to report it. I give the latest development XBian a try to, to check if it's the same as 1.0a4.
if you have the 720p telly than for you would be best to set 1366*768 resolution under settings
The native panel is 1024x720, with EDID showing 1280x720 as native. What's the benefit in setting 1366x768? Wouldn't that just make both GPU and TV scale for playback?
(18th Jan, 2013 02:00 AM)obo Wrote: [ -> ]The native panel is 1024x720, with EDID showing 1280x720 as native. What's the benefit in setting 1366x768? Wouldn't that just make both GPU and TV scale for playback?

I see
I thought you may have one of the screens with the resolution mentioned above as most of the 720p screens I worked on had that .
But I can see your native is different. You can still try if that would help.
But also I had experience from few weeks ago when I was setting up XBMC for my m8 and he has LG with same resolution as you and he had same issue as you.
I found that the best results was when I set his resolution to full HD 1920*1080. With this settings there was no problems with GUI nor the movie playback.
Maybe worth to try Wink
I've run a bunch of tests with different boot configurations from the official Pi firmware repository, and am now sure it'll all sort itself out with XBian 1.0a5.

Raspbmc is using firmware from Dec 28, which works fine. XBian 1.0a4 uses firmware from Nov 22, which has a problem. I've narrowed it down to the commit between Nov 26 (not working) and Dec 27 (working). The change log just says "Update master branch to next", which sounds like it could include many changes.

To be sure I've also tested the latest Jan 16 commit (working), and also whatever is in the /boot from the current XBian repository (also working).

I'll wait for 1.0a5 to include the fixed version. Thanks all for your input Smile
Reference URL's