[MPlayer-dev-eng] [PATCH] fbdev changes

D Richard Felker III dalias at aerifal.cx
Fri Aug 1 03:15:52 CEST 2003

On Thu, Jul 31, 2003 at 07:04:56PM -0500, Joey Parrish wrote:
> On Thu, Jul 31, 2003 at 07:51:47PM -0400, D Richard Felker III wrote:
> > Please commit. Even if there are problems, it's 1000x less broken than
> > the old code, and once you commit, users will find any problems that
> > might be there. BTW, could you also add support for direct rendering,
> > i.e. get_image? In the old system, fbdev faked that it supported yuv
> > colorspaces, then converted yuv2rgb directly into the framebuffer, so
> > it was fairly fast. But now fbdev is very very slow, since it does:
> > 
> > 1) codec gets yuv buffers, sends them to vf_scale
> > 2) vf_scale gets rgb buffer, performs conversion into this buffer
> > 3) vo_fbdev gets rgb buffer from vf_scale, copies it to screen
> > 
> > Slices are helping it a little, but having vf_scale draw directly into
> > video memory would help a lot!
> I see.  Good point.  I'll try to do that in a bit, then commit.
> I'll probably find some more bugs along the way.  Speaking of which,
> I've discovered that I actually like it better when certain /dev/tty
> stuff is going on... so I'm going to change the way that stuff is all
> structured, probably.  Bah.  Anyhow, you'll see new stuff in fbdev soon
> enough.  (Hint, still time to object...)

Please make any /dev/tty stuff *optional*, and disabled by default.
It's really annoying in dual-head type setups where /dev/tty has
nothing to do with the framebuffer the movie display is on. You might
also see if you could backport the vsync/pageflip stuff Arpi did in
G2's vo_fbdev to G1.

BTW, thanks for fixing up the fb code! :)


More information about the MPlayer-dev-eng mailing list