2.6.28rc3 with s-video testing uImage
Koen Kooi
Could the s-video crowd please test
http://dominion.thruhere.net/koen/OE/uImage-2.6.27+2.6.28-rc3+r0+gitrf7429fd378a29cf6947c2613e0fd6e6e36165167-r0-beagleboard.bin
And report back about any issues they have. The new DSS lib has some
initialization problems that need to get hunted down and fixed.
regards,
Koen
Robert Kuhn
> http://dominion.thruhere.net/koen/OE/uImage-2.6.27+2.6.28-rc3+r0+gitrf7429fd378a29cf6947c2613e0fd6e6e36165167-r0-beagleboard.bin
>
> And report back about any issues they have. The new DSS lib has some
I tested it and activated s-video with
tvline=`cat /sys/devices/platform/omapfb/displays |grep tv`
w=`echo $tvline | cut -d " " -f 2 | cut -d ":" -f 2`
h=`echo $tvline | cut -d " " -f 3 | cut -d ":" -f 2`
echo "1 t:none" > omapfb/framebuffers
echo "0 t:gfx,vid1" > omapfb/framebuffers
echo "gfx e:1" > omapfb/overlays
echo "vid1 t:tv w:$w h:$h e:1" > omapfb/overlays
echo "tv e:1" > omapfb/displays
and got the same display on DVI and s-video. The only issue is that
the dvi has 1024x768@51Hz! So the pixel clock values seems to be
wrong. I attach the bootlog.
Robert
Robert Kuhn
>> and got the same display on DVI and s-video. The only issue is that
>> the dvi has 1024x768@51Hz! So the pixel clock values seems to be
>> wrong. I attach the bootlog.
>
> Unfortunately it is not possible to get exact pixel clocks with normal DSS
...
> However, you can get much more accurate pixel clocks when using the DSI DPLL
> to create the DSS function clock. You can try that kernel option also, but
> it's a bit experimental at the moment (but works for me).
Sorry for asking the perhaps stupid question: Which kernel option (or
where can I find the documentation about it)?
Robert
Robert Kuhn
> I tested it and activated s-video with
Sorry for asking but I do have problems to understand the
documentation. How can I direct fb0 to dvi and fb1 to s-video?
Robert
Tomi Valkeinen
>
> >>> http://dominion.thruhere.net/koen/OE/uImage-2.6.27+2.6.28-rc3+r0
> +gitrf7429fd378a29cf6947c2613e0fd6e6e36165167-r0-beagleboard.bin
>
> >> and got the same display on DVI and s-video. The only issue is that
> >> the dvi has 1024x768@51Hz! So the pixel clock values seems to be
> >> wrong. I attach the bootlog.
> >
> > Unfortunately it is not possible to get exact pixel clocks with
> normal DSS
> ...
> > However, you can get much more accurate pixel clocks when using the
> DSI DPLL
> > to create the DSS function clock. You can try that kernel option
> also, but
> > it's a bit experimental at the moment (but works for me).
>
> Sorry for asking the perhaps stupid question: Which kernel option (or
> where can I find the documentation about it)?
In kernel compilation options, under OMAP2/3 Display subsystem support:
OMAP2_DSS_DSI
OMAP2_DSS_USE_DSI_PLL
Tomi
Robert Kuhn
>> where can I find the documentation about it)?
>
> In kernel compilation options, under OMAP2/3 Display subsystem support:
Ah, okay, sorry. I thought you meant a kernel command line option.
Okay, I got it.
Robert.
Tomi Valkeinen
Try this:
tvline=`cat /sys/devices/platform/omapfb/displays |grep tv`
w=`echo $tvline | cut -d " " -f 2 | cut -d ":" -f 2`
h=`echo $tvline | cut -d " " -f 3 | cut -d ":" -f 2`
echo "vid1 t:none" > /sys/devices/platform/omapfb/overlays
fbset -fb /dev/fb1 -xres $w -vxres $w -yres $h -vyres $h
echo "vid1 t:tv w:$w h:$h e:1" > /sys/devices/platform/omapfb/overlays
echo "tv e:1" > /sys/devices/platform/omapfb/displays
What it does is:
1. disconnect vid1 overlay, so that we can change it freely
2. set the framebuffer fb1 to correct size (it is already connected to
vid1, by default, so we don't need to connect it)
3. set vid1 output to tv overlay manager, and set output size to tv's
size
4. enable tv display
Tomi
Tomi Valkeinen
Unfortunately it is not possible to get exact pixel clocks with normal DSS
clocking, especially for higher pixel clocks. The code tries to find a
pixel clock that would produce 60Hz refresh rate, but the closest it can
find is 51Hz.
However, you can get much more accurate pixel clocks when using the DSI
DPLL to create the DSS function clock. You can try that kernel option
also, but it's a bit experimental at the moment (but works for me).
> Robert
Tomi
Koen Kooi
>
> >>http://dominion.thruhere.net/koen/OE/uImage-2.6.27+2.6.28-rc3+r0+gitr...
> >> And report back about any issues they have. The new DSS lib has some
>
> > I tested it and activated s-video with
>
> > tvline=`cat /sys/devices/platform/omapfb/displays |grep tv`
> > w=`echo $tvline | cut -d " " -f 2 | cut -d ":" -f 2`
> > h=`echo $tvline | cut -d " " -f 3 | cut -d ":" -f 2`
>
> > echo "1 t:none" > omapfb/framebuffers
> > echo "0 t:gfx,vid1" > omapfb/framebuffers
> > echo "gfx e:1" > omapfb/overlays
> > echo "vid1 t:tv w:$w h:$h e:1" > omapfb/overlays
> > echo "tv e:1" > omapfb/displays
>
> > and got the same display on DVI and s-video. The only issue is that
> > the dvi has 1024x768@51Hz! So the pixel clock values seems to be
> > wrong. I attach the bootlog.
>
> Unfortunately it is not possible to get exact pixel clocks with normal DSS
> clocking, especially for higher pixel clocks. The code tries to find a
> pixel clock that would produce 60Hz refresh rate, but the closest it can
> find is 51Hz.
>
> However, you can get much more accurate pixel clocks when using the DSI
> DPLL to create the DSS function clock. You can try that kernel option
> also, but it's a bit experimental at the moment (but works for me).
http://dominion.thruhere.net/koen/OE/uImage-2.6.27+2.6.28-rc3+r2+gitrf7429fd378a29cf6947c2613e0fd6e6e36165167-r2-beagleboard.bin
regards,
Koen
Tomi Valkeinen
>
> Hi,
>
> On Mon, 10 Nov 2008, Robert Kuhn wrote:
>
>> and got the same display on DVI and s-video. The only issue is that
>> the dvi has 1024x768@51Hz! So the pixel clock values seems to be
>> wrong. I attach the bootlog.
>
> Unfortunately it is not possible to get exact pixel clocks with normal DSS
> clocking, especially for higher pixel clocks. The code tries to find a
> pixel clock that would produce 60Hz refresh rate, but the closest it can
> find is 51Hz.
Actually, this was not quite right. You can't get exact pixel clocks, but
you can get better than that 51Hz. The MIN_FCK_PER_PCK Kconfig option
causes this behavior and the current version didn't try disabling that
option, if it couldn't find a good match with it. I'm fixing this problem
for the next release.
Tomi
Robert Kuhn
> This kernel should have DSI_PLL enabled:
>
> http://dominion.thruhere.net/koen/OE/uImage-2.6.27+2.6.28-rc3+r2+gitrf7429fd378a29cf6947c2613e0fd6e6e36165167-r2-beagleboard.bin
Unfortuneatly it panics. Log is attached.
Robert
Robert Kuhn
> Try this:
>
> tvline=`cat /sys/devices/platform/omapfb/displays |grep tv`
> w=`echo $tvline | cut -d " " -f 2 | cut -d ":" -f 2`
> h=`echo $tvline | cut -d " " -f 3 | cut -d ":" -f 2`
>
> echo "vid1 t:none" > /sys/devices/platform/omapfb/overlays
> fbset -fb /dev/fb1 -xres $w -vxres $w -yres $h -vyres $h
> echo "vid1 t:tv w:$w h:$h e:1" > /sys/devices/platform/omapfb/overlays
> echo "tv e:1" > /sys/devices/platform/omapfb/displays
>
> What it does is:
> 1. disconnect vid1 overlay, so that we can change it freely
> 2. set the framebuffer fb1 to correct size (it is already connected to
> vid1, by default, so we don't need to connect it)
> 3. set vid1 output to tv overlay manager, and set output size to tv's
> size
> 4. enable tv display
Just to give a feedback: it works great, thank you very much!
I will write an entry for the wiki.
Robert
Robert Kuhn
> Just to give a feedback: it works great, thank you very much!
I just realised: It is possible to have a 32bpp with the
"s-video-framebuffer". Great! As far as I see this was not possible
with the v4l-interface.
Robert
Tomi Valkeinen
Yep, the new DSS supports currently:
RGB565 (fbset -depth 16)
RGB24 packed (fbset -depth 24)
RGB24 unpacked (fbset -depth 32)
YUV422 (fbset -nonstd 1) (only for video overlays)
YUY422 (fbset -nonstd 8) (only for video overlays)
Tomi
Dan
After typing in all the suggested commands, if I type $tvline, the
console reads out:
dvi w:1024 h:768 e:1 u:1 t:0
tv w:720 h:574 e:1 u:-1 t:0
cat: can't open '|grep': No such file or directory
cat: can't open 'tv': No such file or directory
Also, when I try the "fbset -fb /dev/fb1 -xres $w -vxres $w -yres $h
-vyres $h", it says:
fbset: invalid number 'echo'
Any ideas?
Dan
Tomi Valkeinen
On Thu, 13 Nov 2008, Dan wrote:
>
> I tried this and just get static on my s-video display.
>
> After typing in all the suggested commands, if I type $tvline, the
> console reads out:
>
> dvi w:1024 h:768 e:1 u:1 t:0
> tv w:720 h:574 e:1 u:-1 t:0
> cat: can't open '|grep': No such file or directory
> cat: can't open 'tv': No such file or directory
>
> Also, when I try the "fbset -fb /dev/fb1 -xres $w -vxres $w -yres $h
> -vyres $h", it says:
> fbset: invalid number 'echo'
>
> Any ideas?
alternatively you have some very strange shell.
But the whole point of those first three lines is to find out the
dimensions is tv out. You can get that data manually and fill the numbers
in the fbset line.
Tomi
Kiran Murari
I am unable hear audio along with video using this kernel.
Able to view the video with appropriate /sys settings
In 2.6.22 kernel from the Beagle Source Code page, I could see sound related kernel conf options.
CONFIG_SND_OMAP3EVM, CONFIG_SND_OMAP3EVM_TWL4030
Are there any such kernel config options available in this kernel?
Or should I have to merge those changes to get audio out?
Any help regarding the same is highly appreciated.
TIA,
Kiran
lia...@gmail.com
i test it and its OK!
Can you tell me how to make the uImage?
Thanks a lot.
Liahoo
> > >>> Try this:
>
> > >>> tvline=`cat /sys/devices/platform/omapfb/displays |grep tv`
> > >>> w=`echo $tvline | cut -d " " -f 2 | cut -d ":" -f 2`
> > >>> h=`echo $tvline | cut -d " " -f 3 | cut -d ":" -f 2`
>
> > >>> echo "vid1 t:none" > /sys/devices/platform/omapfb/overlays
> > >>> fbset -fb /dev/fb1 -xres $w -vxres $w -yres $h -vyres $h
> > >>> echo "vid1 t:tv w:$w h:$h e:1" > /sys/devices/platform/omapfb/overlays
> > >>> echo "tv e:1" > /sys/devices/platform/omapfb/displays
>
> > >>> What it does is:
> > >>> 1. disconnect vid1 overlay, so that we can change it freely
> > >>> 2. set the framebuffer fb1 to correct size (it is already connected to
> > >>> vid1, by default, so we don't need to connect it)
> > >>> 3. set vid1 output to tv overlay manager, and set output size to tv's
> > >>> size
> > >>> 4. enable tv display
>
> > >> Just to give a feedback: it works great, thank you very much!
> > >> I will write an entry for the wiki.
>
>
> - 引用テキストを表示 -
Hu Liang
I am trying to get the S-video output with the Android Rootfs in BB.
But I cant patch S-VIDEO to the recent Linux kernel.
Can someone tell me which kernel the S-VIDEO "diff" file should patch
into?
Thanks a lot!
Hu Liang.
> > >>> Try this:
>
> > >>> tvline=`cat /sys/devices/platform/omapfb/displays |grep tv`
> > >>> w=`echo $tvline | cut -d " " -f 2 | cut -d ":" -f 2`
> > >>> h=`echo $tvline | cut -d " " -f 3 | cut -d ":" -f 2`
>
> > >>> echo "vid1 t:none" > /sys/devices/platform/omapfb/overlays
> > >>> fbset -fb /dev/fb1 -xres $w -vxres $w -yres $h -vyres $h
> > >>> echo "vid1 t:tv w:$w h:$h e:1" > /sys/devices/platform/omapfb/overlays
> > >>> echo "tv e:1" > /sys/devices/platform/omapfb/displays
>
> > >>> What it does is:
> > >>> 1. disconnect vid1 overlay, so that we can change it freely
> > >>> 2. set the framebuffer fb1 to correct size (it is already connected to
> > >>> vid1, by default, so we don't need to connect it)
> > >>> 3. set vid1 output to tv overlay manager, and set output size to tv's
> > >>> size
> > >>> 4. enable tv display
>
> > >> Just to give a feedback: it works great, thank you very much!
> > >> I will write an entry for the wiki.
>