* Tomi Valkeinen <tomi.valkeinen@xxxxxx> [121009 06:08]: > On Fri, 2012-10-05 at 09:43 -0700, Tony Lindgren wrote: > > > Looks like somehow also output_size won't change when changing > > display output from DVI to HDMI. > > > > If I boot with DVI panel at 1600x1200, then try to switch to the > > HDMI monitor with the following script: > > > > #!/bin/sh > > > > export dvi=display0 > > export hdmi=display1 > > export overlay=overlay0 > > > > echo 0 > /sys/devices/platform/omapdss/$dvi/enabled > > echo 1 > /sys/devices/platform/omapdss/$hdmi/enabled > > echo "85500,1366/70/213/143,768/3/24/3" > /sys/devices/platform/omapdss/$hdmi/timings > > echo 0 > /sys/devices/platform/omapdss/$overlay/enabled > > echo tv > /sys/devices/platform/omapdss/$overlay/manager > > #echo "1366,768" > /sys/devices/platform/omapdss/$overlay/output_size > > echo 1 > /sys/devices/platform/omapdss/$overlay/enabled > > cat /sys/devices/platform/omapdss/$hdmi/timings > > cat /sys/devices/platform/omapdss/$overlay/output_size > > > > I get the following which may provide more clues: > > > > [64370.820312] omapdss DISPC error: SYNC_LOST on channel tv, restarting the output with video overlays dd > > [64370.831024] omapdss OVERLAY error: overlay 0 horizontally not inside the display area (0 + 1600 >= 13) > > [64370.840972] omapdss APPLY error: failed to enable manager 1: check_settings failed > > [64370.849670] omapdss HDMI error: failed to power on device > > [64370.855407] omapdss error: failed to power on > > [64370.862487] omapdss OVERLAY error: overlay 0 horizontally not inside the display area (0 + 1600 >= 13) > > [64370.872436] omapdss APPLY error: failed to enable manager 1: check_settings failed > > [64370.880798] omapdss HDMI error: failed to power on device > > [64370.886505] omapdss error: failed to power on > > 85500,1366/70/213/143,768/3/24/3 > > 1600,1200 > > Well, it's not that simple =). There are three things to consider: > > - Framebuffer in the sdram. It has xres and yres parameters. > - Overlay, and it's input size (from fb) and output sizes (must fit into > the display). > - Display, which has certain size depending on video mode. > > Only VID overlays can have different input and output sizes, GFX overlay > does not support scaling. > > In the script above you don't change the fb at all. You can do that with > when the overlay is disabled, for example: > > fbset -xres 1366 -vxres 1366 -yres 768 -vyres 768 > > But that only works if there's enough memory allocated for the > framebuffer, but that is the case for you if the fb was bigger > initially. Otherwise you need to set the new size > with /sys/class/graphics/fb0/size before resizing the fb. > > And, of course, the framebuffer cannot be in use at that time by, for > example, X. Thanks for the explanation, I'll give that a try at some point. > Yes, it's complex! I hope omapdrm will make all things simple, and we > can forget omapfb. In hindsight, I should've designed omapfb to be much > simpler, and only use gfx overlay. Making it support all overlays is a > never ending source for problems and complexity. Heh oh well it works reasonably for most cases I guess. > > FYI, I'm also seeing the DVI monitor blank out on it's own for > > about a second or so on regular basis every 10 minutes or so. > > No idea what's causing that, maybe it's a reminder to take > > a short break :) > > Well that's something different. I've recently done some testing with > using DSI PLL for generating pixel clock, and I've seen unstabilities > with that. But perhaps there's something else wrong also, even when > using the PRCM for pix clock as in your case. > > Does your monitor ever report something like bad signal or such? Yes I've seen that too, but that seems to be different issue and I may have passed wrong timings in that case. I guess the random blanking for a second or so could also be an occastional bad timing. No warnings in that case on the monitor though. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
