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

Nick Kurshev nickols_k at mail.ru
Fri Jan 18 12:34:08 CET 2002 

Hello, Alex!

On Fri, 18 Jan 2002 12:15:28 +0100 you wrote:

> On Fri, Jan 18, 2002 at 02:13:50PM +0300, Nick Kurshev wrote:
> > Hello, Alex!
> > 
> > On Fri, 18 Jan 2002 11:27:41 +0100 you wrote:
> > 
> > > On Fri, Jan 18, 2002 at 01:16:36PM +0300, Nick Kurshev wrote:
> > > > Hello, Alex!
> > > > 
> > > > On Fri, 18 Jan 2002 11:04:10 +0100 you wrote:
> > > > 
> > > > > 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
> > > > > 
> > > > In this case you shouldn't return 0 on vixProbe.
> > > > (Well, I've fixed that).
> > > > Please be carefully in the next time.
> > > I didn't thought that someone uses VIDIX as you said, you will introduce it
> > > later.
> > Please visit main page of mplayer ;)
> Yes, i visited it after i wrote my previos mail, fine ;)
> 
> > 
> > > Btw, sorry for the problems i caused, i will remove genfb_vid and start
> > > working on nvidia_vid.
> > > 
> > Don't remove that - let it be demo driver or skeletion.
> Ok, than do only cosmetic changes on it, i mean, comments and blabla, or
> write howto_write_vidix_driver ;)
> 
main/DOCS/tech/vidix.txt
> > > Anyway, what do you think about vidix_start/stop for resize in xvidix?
> > > 
> > It works fine for me ;)
> > But it would be correctly to stop video before unloading driver - it's right way!
> vidix_term calls vidix_stop before vdlClose (also i replaced
> vdlPlayBackOff() with vidix_stop in vidix_term)
> 
> Or what did you meant?
> 
Currently I don't know what extensions vof xvidix you'll apply but it seems - o'k.
Same as in the future it would be correctly to move vidix_seteq out from vidix_start.

> > 
> > > > > > 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
> > > > > _______________________________________________
> > > > > 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

More information about the MPlayer-dev-eng mailing list