[Libdlo] 1. udlfb doesn't choose 1920x1200 and 2. mplayer shows no video on framebuffer

[Thomas Siedlich]

Hi Bernie,
 
On Wed, 6/22/11, Bernie Thompson <bernie at berniethompson.com> wrote:
> On Mon, Jun 20, 2011 at 1:23 PM, Thomas Siedlich
> <thomas.siedlich at yahoo.com> wrote:
> > You can see in syslog that 1920x1200 is a valid mode. But why chooses udlfb 1600x1200 instead?
>
> Bill Katsak just submitted a patch for this today [...]
 
It's quite funny that at the same time two people try to fix
a bug introduced more than a year ago :-).
 
I investigated further after my last mail and found indeed
the same bug as Bill.
 
> [...] if you grab the latest udlfb from git.plugable.com and test,
> it'd be great to get an email from you, if the patch resolves
> your issue.
 
Yes this patch works for me but I'm not sure if the matching
if (i == 0)
is save to use.
Shouldn't we better match the modeline flag FB_MODE_IS_FIRST instead?
 
Something like that:
if((&info->monspecs.modedb[i])->flag & FB_MODE_IS_FIRST)
 
This is also working in case of someone is mixing/sorting
the list befor we check it.
 
I tested this, too and it works for me, too.
 
> > The next problem is:
> > mplayer -vo fbdev:/dev/fb1 Sintel.2010.Theora-VODO.mp4
> >
> > mplayer plays the video (better: I see status messages and
> > hear the audio) but nothing happens on the framebuffer.
> > It stays green.
>
> To run an app that doesn't know about udlfb's changed pixels/damage
> ioctl, you'll need to enable fb_defio support (which is off by
> default).
 
Thanks. I was not aware that mplayer is such a program.
 
[...]
> Let us know if this gets mplayer working (the other common problem is
> fbdev apps is many require a full VT, not just a framebuffer).
 
Yes, indeed. After activating fb_defio mplayer works.
 
 
My framebuffer works now so it's time to try to use it with X.org.
 
Thanks a lot!
 
Thomas