[MPlayer-dev-eng] fbdev:vidix / vidix bug

[Alex Beregszaszi]

On Fri, Jan 18, 2002 at 10:52:26AM +0300, Nick Kurshev wrote:
> Hello, Alex!
> 
> On Thu, 17 Jan 2002 14:19:35 +0100 you wrote:
> 
> > On Thu, Jan 17, 2002 at 11:33:11AM +0300, Nick Kurshev wrote:
> > > Hello, Alex!
> > > 
> > > On Wed, 16 Jan 2002 15:49:33 +0100 you wrote:
> > > 
> > > > On Wed, Jan 16, 2002 at 10:36:30AM +0300, Nick Kurshev wrote:
> > > > > Hello, Felix!
> > > > > 
> > > > > On Tue, 15 Jan 2002 23:37:11 +0100 you wrote:
> > > > > 
> > > > > > On Tuesday, 15. January 2002 18:34, you wrote:
> > > > > > > It's the Question that drives us, Felix Buenemann :
> > > > > > > > Things I did that far was compiling mplayer current-cvs with vidix and
> > > > > > > > installing libdha.so into /usr/lib/ and running ldconfig.
> > > > > > >
> > > > > > > ;)
> > > > > > > Also copy *_vid*.so to $prefix/lib/mplayer/vidix
> > > > > > yea, but shouldn't fsck the system if I don't do :)
> > > > > > 
> > > > > > argh my 44days uptime on the laptop are gone with the wind (or better reboot) 
> > > > > > :(
> > > > > We should 1000L to Alex for genfb driver - remove it.
> > > > 
> > > > genfb isn't completed, don't use it.
> > > > 
> > > It' impossible :(
> > > Did you even try to study vidixlib logic?
> > > It probes all drivers and load first which was probed without errors.
> > > I said and say: This driver MUST be NEVER finished.
> > > It violates ideology of VIDIX.
> > > Since if user has loaded linux's framebuffer driver then this driver will be
> > > always successfully probed. But who need it? dev/fb0 doesn't provide any HW
> > > acceleration as VIDIX should do.
> > It provides hw accel.... read linux/fb.h
> What? Are you sure? Finely what HW accel do you mean?
> I write radeonfb driver - I know what it provides and what
> it can provide. Please don't mix 2D acceleration with VIDEO
> one. There were introduced only several functions for 2D acceleration:
> 	bmove:		matrox_cfbX_bmove,
> 	clear:		matrox_cfb32_clear,
> 	putc:		matrox_cfb32_putc,
> 	putcs:		matrox_cfb32_putcs,
> 	revc:		matrox_cfb32_revc,
> 	clear_margins:	matrox_cfbX_clear_margins,
> As you can see there no video related things.
> Please think it again! What you've developed:
> mplayer -vo fbdev:vidix:genfb_vid
> it's fully equal to
> mplayer -vo fbdev
> and what we need to have the same things?
> How do you think - why vo_fbdev doesn't support -zoom key?
> (It supports this key only for VIDIX).
> And the last - from linux/Documentation/fb/framebuffer.txt:
> #All this hardware abstraction makes the implementation of application programs
> #easier and more portable. E.g. the X server works completely on /dev/fb* and
> #thus doesn't need to know, for example, how the color registers of the concrete
> #hardware are organized. XF68_FBDev is a general X server for bitmapped,
> #unaccelerated video hardware. The only thing that has to be built into
> ^^^^^^^^^^^^^^
> #application programs is the screen organization (bitplanes or chunky pixels
> #etc.), because it works on the frame buffer image data directly.
> 
> Anyway - genfb is bad driver for VIDIX.

btw, i developed genfb only for me, to test xvidix, until nvidia_vid isn't
finished

> Even if linux-2.6 will have such extension for example from RUBY
> tree of linuxconsole.sf.net (FBVID.H) or from V4L2 project then
> it will not cause to implement such driver for VIDIX.
> 
> Please, REMEMBER:
>  NEVER GENERIC DRIVERS FOR VIDIX ONLY NATIVE ONES (VENDOR_ID DEPENDED).
> 
> > > VIDIX should provide native support but not generic.
> > > (Even vga_vid is not good for VIDIX).
> > > In short: Driver MUST be depended from VENDOR_ID.
> > > OTOH - if you want something implement there are some ineteresting tasks:
> > > 1. Should we support multihead card by one driver (I mean should we remove mga_crtc2_vid)
> > > 2. How we can handle situation when computer has installed two identical video card?
> > > 3. Should we pass FPS info into driver?
> > > > > > -- 
> > > > > > Best Regards,
> > > > > > 	Atmos
> > > > > > ____________________________________________
> > > > > > - MPlayer Developer - http://mplayerhq.hu/ -
> > > > > > ____________________________________________
> > > > > > _______________________________________________
> > > > > > MPlayer-dev-eng mailing list
> > > > > > MPlayer-dev-eng at mplayerhq.hu
> > > > > > http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
> > > > > > 
> > > > > 
> > > > > 
> > > > > Best regards! Nick
> > > > > _______________________________________________
> > > > > MPlayer-dev-eng mailing list
> > > > > MPlayer-dev-eng at mplayerhq.hu
> > > > > http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
> > > > _______________________________________________
> > > > MPlayer-dev-eng mailing list
> > > > MPlayer-dev-eng at mplayerhq.hu
> > > > http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
> > > > 
> > > 
> > > 
> > > Best regards! Nick
> > > _______________________________________________
> > > MPlayer-dev-eng mailing list
> > > MPlayer-dev-eng at mplayerhq.hu
> > > http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
> > _______________________________________________
> > MPlayer-dev-eng mailing list
> > MPlayer-dev-eng at mplayerhq.hu
> > http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
> > 
> 
> 
> Best regards! Nick
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng