Menu
▾
▴
linuxconsole-dev
|
From: Romain D. <do...@ir...> - 2001-09-26 08:51:17
Attachments:
fbvid.h
|
Nick Kurshev wrote: > 1. What about adding video extensions to devfb? Well, it would need a standard way of querying the video capability of the chip and using it. Not easy... I've written a draft proposal for that, amd implemented it in pm3fb (my fb driver for the permedia3), but it still needs discussion. If there's interest in it, the likely target would be kernel 2.5.x in Ruby (the new framebuffer layer, see <http://sourceforge.net/projects/linuxconsole/> Appended is the preliminary include file. Any comment/criticism/improvement/advice very much welcome. -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Romain D. <do...@ir...> - 2001-09-28 08:06:57
|
Nick Kurshev wrote: > I'm not sure - but what about having a support of hardware accelerated > decoding? (I mean such things as mpeg1, mpeg2 decoding, de-zigzag and so on) > Unfortunatelly I never saw any opensource project which has implementation > of such things but if you know how it should be implemented then such extensions > are gladly accepted too. I don't know how to, as I don't have knowledge of MPEG decoding, and the card I own can't do it anyway (maybe It can, but I don't have the docs, are Formac redirect me to 3Dlabs and 3Dlabs doesn't answer my mail - I thought things were going well when they suddenly stopped to answer my mail...) Anyway, I'm not sure adding all and every possible features to the FB driver will be seen kindly by those-in-charge (aka Linus T. and maybe Alan C.) I'm not even sure they'll agree on video overlay... -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Nick K. <nic...@ma...> - 2001-09-28 09:12:45
|
Hello, Romain! On Fri, 28 Sep 2001 10:06:48 +0200, you wrote: > Nick Kurshev wrote: > > > I'm not sure - but what about having a support of hardware accelerated > > decoding? (I mean such things as mpeg1, mpeg2 decoding, de-zigzag and so on) > > Unfortunatelly I never saw any opensource project which has implementation > > of such things but if you know how it should be implemented then such extensions > > are gladly accepted too. > > I don't know how to, as I don't have knowledge of MPEG decoding, and > the card I own can't do it anyway (maybe It can, but I don't have > the docs, are Formac redirect me to 3Dlabs and 3Dlabs doesn't > answer my mail - I thought things were going well when they > suddenly stopped to answer my mail...) > > Anyway, I'm not sure adding all and every possible features > to the FB driver will be seen kindly by those-in-charge > (aka Linus T. and maybe Alan C.) I'm not even sure they'll > agree on video overlay... > But in this case fbdev will useless and meaningless toy which was born only for linux-logo :( But Linux-logo could be displayed through vesafb without native drivers and NLS problems. Simply because after displaying logo vesafb should be terminated. > -- > DOLBEAU Romain | l'histoire est entierement vraie, puisque > ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre > do...@ir... | -- Boris Vian > Best regards! Nick |
|
From: Nick K. <nic...@ma...> - 2001-11-18 09:13:05
|
Hello! Some time ago I wrote about the future of framebuffer and video extensions for that. Roman Dolbeau suggested me to use following interface: /* * linux/include/linux/fbvid.h -- linux Framenuffer Video Interface * * Copyright (C) 2001 Romain Dolbeau <do...@ir...> * * This file is subject to the terms and conditions of the GNU General Public * License. See the file COPYING in the main directory of this archive for * more details. * * $Header: /home/pm3fb/pm3fb/Attic/fbvid.h,v 1.1.2.13 2001/09/27 09:22:11 dolbeau Exp $ * */ #ifndef _LINUX_FBVID_H #define LINUX_FBVID_H #include <linux/fb.h> #include <asm/types.h> #include <asm/ioctl.h> /* FOURCC #define, from the MPlayer list (see <http://mplayer.sourceforge.net/> */ /* RGB/BGR Formats */ #define FB_VIDOVERLAY_FOURCC_RGB (('R'<<24)|('G'<<16)|('B'<<8)) #define FB_VIDOVERLAY_FOURCC_BGR (('B'<<24)|('G'<<16)|('R'<<8)) /* Planar YUV Formats */ #define FB_VIDOVERLAY_FOURCC_YVU9 0x39555659 #define FB_VIDOVERLAY_FOURCC_IF09 0x39304649 #define FB_VIDOVERLAY_FOURCC_YV12 0x32315659 #define FB_VIDOVERLAY_FOURCC_I420 0x30323449 #define FB_VIDOVERLAY_FOURCC_IYUV 0x56555949 #define FB_VIDOVERLAY_FOURCC_CLPL 0x4C504C43 /* Packed YUV Formats */ #define FB_VIDOVERLAY_FOURCC_IYU1 0x31555949 #define FB_VIDOVERLAY_FOURCC_IYU2 0x32555949 #define FB_VIDOVERLAY_FOURCC_UYVY 0x59565955 #define FB_VIDOVERLAY_FOURCC_UYNV 0x564E5955 #define FB_VIDOVERLAY_FOURCC_cyuv 0x76757963 #define FB_VIDOVERLAY_FOURCC_YUY2 0x32595559 #define FB_VIDOVERLAY_FOURCC_YUNV 0x564E5559 #define FB_VIDOVERLAY_FOURCC_YVYU 0x55595659 #define FB_VIDOVERLAY_FOURCC_Y41P 0x50313459 #define FB_VIDOVERLAY_FOURCC_Y211 0x31313259 #define FB_VIDOVERLAY_FOURCC_Y41T 0x54313459 #define FB_VIDOVERLAY_FOURCC_Y42T 0x54323459 #define FB_VIDOVERLAY_FOURCC_V422 0x32323456 #define FB_VIDOVERLAY_FOURCC_V655 0x35353656 #define FB_VIDOVERLAY_FOURCC_CLJR 0x524A4C43 #define FB_VIDOVERLAY_FOURCC_YUVP 0x50565559 #define FB_VIDOVERLAY_FOURCC_UYVP 0x50565955 /* for depth_avail */ #define FB_VIDOVERLAY_DEPTH_1BPP 0x0001 #define FB_VIDOVERLAY_DEPTH_2BPP 0x0002 #define FB_VIDOVERLAY_DEPTH_4BPP 0x0004 #define FB_VIDOVERLAY_DEPTH_8BPP 0x0008 #define FB_VIDOVERLAY_DEPTH_12BPP 0x0010 #define FB_VIDOVERLAY_DEPTH_15BPP 0x0020 #define FB_VIDOVERLAY_DEPTH_16BPP 0x0040 #define FB_VIDOVERLAY_DEPTH_24BPP 0x0080 #define FB_VIDOVERLAY_DEPTH_32BPP 0x0100 /* for capability_avail */ #define FB_VIDOVERLAY_CAPABILITY_EXPAND 0x0001 /* if overlay can be bigger than source */ #define FB_VIDOVERLAY_CAPABILITY_SHRINK 0x0002 /* if overlay can be smaller than source */ #define FB_VIDOVERLAY_CAPABILITY_BLEND 0x0004 /* if overlay can be blended with framebuffer */ #define FB_VIDOVERLAY_CAPABILITY_COLORKEY 0x0008 /* if overlay can be restricted to a colorkey */ #define FB_VIDOVERLAY_CAPABILITY_ALPHAKEY 0x0010 /* if overlay can be restricted to an alpha channel */ #define FB_VIDOVERLAY_CAPABILITY_COLORKEY_ISRANGE 0x0020 /* if the colorkey can be a range */ #define FB_VIDOVERLAY_CAPABILITY_ALPHAKEY_ISRANGE 0x0040 /* if the alphakey can be a range */ #define FB_VIDOVERLAY_CAPABILITY_COLORKEY_ISMAIN 0x0080 /* colorkey is checked against framebuffer */ #define FB_VIDOVERLAY_CAPABILITY_COLORKEY_ISOVERLAY 0x0100 /* colorkey is checked against overlay */ #define FB_VIDOVERLAY_CAPABILITY_ALPHAKEY_ISMAIN 0x0200 /* alphakey is checked against framebuffer */ #define FB_VIDOVERLAY_CAPABILITY_ALPHAKEY_ISOVERLAY 0x0400 /* alphakey is checked against overlay */ /* below, for ioctl, <- is driver-to-app, -> is app-to-driver, <-> is bidirectional (*can* be changed by driver) */ struct fb_vidoverlay_avail { __u32 max_buf_size; /* <- maximum size of buffer */ __u32 xmax; /* <- max width of a buffer in _pixels_ */ __u32 ymax; /* <- max height of a buffer in line */ __u8 xalign; /* <- required alignement of width of buffer in _byte_ */ __u8 yalign; /* <- required alignement of height of buffer in line */ __u8 min_n_buf; /* <- minimum number of available buffer */ __u8 num_fourcc; /* <- number of available FOURCC */ }; struct fb_vidoverlay_fourcc { __u32 id; /* <- FOURCC id (see <http://www.webartz.com/fourcc/>) */ __u16 depth_avail; /* <- available depth(s) for this FOURCC */ __u16 capability_avail; /* <- available capability(s) for this FOURCC */ }; struct fb_vidoverlay_buf { unsigned long omem_start; /* <- Start of overlay frame buffer mem (phys add) or 0 (failure) */ __u32 omem_len; /* <- length of overlay frame buffer mem or 0 (failure) */ __u32 xsize; /* <-> X size of buffer */ __u32 ysize; /* <-> Y size of buffer */ __u32 stride; /* <- line lenght in byte (can be longer than X*pixelsize due to hardware restriction */ __u32 fourcc_id; /* -> FOURCC that'll go in the buffer */ __u16 depth; /* -> depth that'll go in the buffer */ __u8 n_buf; /* <-> number of the buffer to use (or -1 for any) */ }; struct fb_vidoverlay_set { __u32 oxsize; /* -> overlay size in pixels */ __u32 oysize; __u32 dxbase; /* -> destination base in pixels */ __u32 dybase; __u32 dxsize; /* -> destination size in pixels */ __u32 dysize; __u32 fourcc_id; /* -> FOURCC to use */ __u16 depth; /* -> depth to use */ __u16 capability; /* -> what capability to use */ __u16 blend_factor; /* -> blending factor */ __u16 r_key[2]; /* -> red component of color key */ __u16 g_key[2]; /* -> green component of color key */ __u16 b_key[2]; /* -> blue component of color key */ /* note: alpha should be put in all component alpha cannot be used if there's no alpha channel, i.e. CI8 in 8Bpp or RGBA5650 in 16bpp [0] is low-end of range [1] is high-end of range for single value, [0] shouldbe equal to [1] */ __u8 n_buf; /* -> number of the buffer to use, must have been allocated before */ }; /* get the hardware capability. get a 'struct fb_vidoverlay_avail' as output from the driver */ #define FBIOGET_VIDOVERLAY_CAP _IOR( 'F', 0xF0, struct fb_vidoverlay_avail) /* get the list of available FOURCC. variable-length data, use FBIOGET_VIDOVERLAY_CAP before */ #define FBIOGET_VIDOVERLAY_FOURCC _IOR( 'F', 0xF1, struct fb_vidoverlay_fourcc) /* get an offscreen memory buffer. 'struct fb_vidoverlay_buf' as input/output */ #define FBIOGET_VIDOVERLAY_ALLOCATEBUF _IOWR('F', 0xF2, struct fb_vidoverlay_buf) /* free the memory buffer. '__u8' number of buffer to free */ #define FBIOGET_VIDOVERLAY_FREEBUF _IOW( 'F', 0xF3, __u8) /* start the overlay. 'struct fb_vidoverlay_set' as input */ #define FBIOPUT_VIDOVERLAY_START _IOW( 'F', 0xFE, struct fb_vidoverlay_set) /* stop the overlay */ #define FBIOPUT_VIDOVERLAY_STOP _IO( 'F', 0xFF) #endif /* LINUX_FBVID_H */ But he was not sure the future of this stuff: >Anyway, I'm not sure adding all and every possible features >to the FB driver will be seen kindly by those-in-charge >(aka Linus T. and maybe Alan C.) I'm not even sure they'll >agree on video overlay... Currently I've implemented the first public release of radeon_vid driver: http://mplayerhq.hu/cgi-bin/cvsweb.cgi/main/drivers/radeon/ In this connexion I have question: Can I use fbvid.h stuff as standard interface for further improvements of my radeon_vid driver or this stuff will never accepted into linux and this interface is meaningless? Best regards! Nick P.S. Please CC me |
|
From: Romain D. <do...@ir...> - 2001-09-28 09:23:15
|
Nick Kurshev wrote: > But in this case fbdev will useless and meaningless toy which was > born only for linux-logo :( No, fbdev is required as a system console on many system ; I _believe_ Geert wrote the original FB code so that some m68k boxes may have a console. It's mandatory at least on linux/mac68k and linux/*ppc... -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Romain D. <do...@ir...> - 2001-11-19 10:01:49
|
Nick Kurshev wrote: > Some time ago I wrote about the future of framebuffer and video extensions for that. > Roman Dolbeau suggested me to use following interface: Please note there's a newer (more documented) version in the linux-console CVS. -- DOLBEAU Romain | Who made you God to say ENS Cachan / Ker Lann | "I'll take your life from you!" Thesard IRISA / CAPS | -- Metallica, dol...@cl... | 'Ride the Lightning' |
|
From: Nick K. <nic...@ma...> - 2001-11-23 08:19:04
|
Hello, Romain!
On Thu, 22 Nov 2001 10:45:29 +0100 you wrote:
> Nick Kurshev wrote:
>
> > Sorry! This part was taken by me from mga_vid driver
> > and this part is still not clear for me :(
> > IMHO if such branch will be in the Linux this problem
> > will disapeared.
>
> I don't think bew /dev/ entry with new major will ever
> get integrated, there's been a lot of discussion in LK.
> The idea in linux-console is to add a new FS that would
> allow for such stuff dynamically. But it won't happen
> tomorrow...
>
As I already wrote - implementing VID driver within framebuffer's one
is not good for me. I need with standalone driver :(
Simply because radeon_vid need with VESA BIOS as graphics server
to get working TV-out.
(radeonfb doesn't enable TV-out and probably will never do that)
> > In the future - it would be better to write into documentation:
> > __u16 depth_avail; /* <- available depth(s) for this FOURCC: FB_VIDEOVERLAY_DEPTH* */
> > simply because AFAIK - there are no driver which were implemented with using
> > this standard and first implementation ( of driver and app ) will cause
> > a lot of questions, like: __u16 capability_avail what should be here and so on.
>
> yes, you're right. It's only a draft :-/
>
> > These "atoms" exist in X11 project for the same lots of stuff ;)
> > IMHO driver can ingnore unknown fields.
>
> but you need a way to tell the app that field so-and-so
> are ignored.
>
It would be better to move such parameters into separate structure
which could be passed into driver through other ioctl (changing
brightness, saturation, ... on the fly). From other side - each
member of this structure is optional for driver.
Maybe it would be even better to pass each such atom as independed
one into driver:
struct hw_video_tuneup
{
char parameter[40]; // or uint32_t
uint32_t value;
uint32_t min_range,max_range;
uint32_t flags;
};
In the future it ould be possible easy expand this by:
#define BRIGHTNESS 1
#define SATURATION 2
#define HUE 3
/* year after 1-st implementation */
#define SGI_SPECIFIC_PARM123 0xFFFF8888 /* vendor specific addition */
> > P.S.: Maybe it would be better to rename fbvid.h to something other
> > like: linux_video_overlay.h or linux_vid.h
> > Because:
> > framebuffers were designed to get linux console on non x86 systems
> > but it's perfectly other technology and is useful for x86 system too.
> > But: my radeon_vid doesn't require any framebuffer to be loaded and
> > can be loaded from text-mode of x86 systems.
> > I use it over VESA's output driver of mplayer. It's trickly but it's
> > only solution to get working TV-out on radeon chips. Simply because
> > ATI will never open TV-out related documentation due macrovision concerns.
> > But after terminating - VESA will switch display back to text-mode
> > (it's radeon specific thing). If someone will use radeon_vid over
> > framebuffer and tried to use VESA then result will be predictable, imho.
>
> The new FB layer in linux-console is not dependant on console code,
> you can have console without FB or FB without console. That's was
> the idea behinf fbvid.h : add the ability to overlay video (or
> still image) on the FB, not in the console. if there's also a
> console, fine.
>
I prefer don't mix framebuffer and video overlay which is useful
on x68 systems too.
> Again, feel free to add this subject to the current discussion
> on the new API in linux-fbdev and linux-console, I think it's
> worth public discussion, as there's obviously interest in
> FB and/or console video. My draft was only a suggestion and
> a way to get the discussion started, not something cast in
> iron that can't be improved/reworked.
>
Done
> Anyway, radeon stuff interest me a lot, I just bought a
> PowerBook G4 with a radeon mobility M6 in it :-) :-)
>
Unfortunately - radeon_vid currently is useless for you
simply because only mplayer works with it and only through
VESA. (Currently mplayer is far from standards in console video
overlay stuff :( But I hope that after implementing such standard
it would be possible to add corresponding stuff to mplayer).
> --
> DOLBEAU Romain | Nothing is real but the way that I feel
> ENS Cachan / Ker Lann | And I feel like going down, down, down
> Thesard IRISA / CAPS | -- Rainbow,
> dol...@cl... | 'Self Portrait'
>
Best regards! Nick
|
|
From: Nick K. <nic...@ma...> - 2001-09-27 06:05:21
|
Hello, Romain! On Wed, 26 Sep 2001 10:51:04 +0200, you wrote: > Nick Kurshev wrote: > > > 1. What about adding video extensions to devfb? > > Well, it would need a standard way of querying the video > capability of the chip and using it. Not easy... > I've written a draft proposal for that, amd implemented > it in pm3fb (my fb driver for the permedia3), but it still > needs discussion. If there's interest in it, the likely > target would be kernel 2.5.x in Ruby (the new framebuffer > layer, see <http://sourceforge.net/projects/linuxconsole/> > > Appended is the preliminary include file. > > Any comment/criticism/improvement/advice very much welcome. > > -- > DOLBEAU Romain | l'histoire est entierement vraie, puisque > ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre > do...@ir... | -- Boris Vian As I've found - mplayer knows much more video image formats: file main/libvo2/img_format.h /* RGB/BGR Formats */ #define IMGFMT_RGB_MASK 0xFFFFFF00 #define IMGFMT_RGB (('R'<<24)|('G'<<16)|('B'<<8)) #define IMGFMT_RGB8 (IMGFMT_RGB|8) #define IMGFMT_RGB15 (IMGFMT_RGB|15) #define IMGFMT_RGB16 (IMGFMT_RGB|16) #define IMGFMT_RGB24 (IMGFMT_RGB|24) #define IMGFMT_RGB32 (IMGFMT_RGB|32) #define IMGFMT_BGR_MASK 0xFFFFFF00 #define IMGFMT_BGR (('B'<<24)|('G'<<16)|('R'<<8)) #define IMGFMT_BGR8 (IMGFMT_BGR|8) #define IMGFMT_BGR15 (IMGFMT_BGR|15) #define IMGFMT_BGR16 (IMGFMT_BGR|16) #define IMGFMT_BGR24 (IMGFMT_BGR|24) #define IMGFMT_BGR32 (IMGFMT_BGR|32) /* Planar YUV Formats */ #define IMGFMT_YVU9 0x39555659 #define IMGFMT_IF09 0x39304649 #define IMGFMT_YV12 0x32315659 #define IMGFMT_I420 0x30323449 #define IMGFMT_IYUV 0x56555949 #define IMGFMT_CLPL 0x4C504C43 /* Packed YUV Formats */ #define IMGFMT_IYU1 0x31555949 #define IMGFMT_IYU2 0x32555949 #define IMGFMT_UYVY 0x59565955 #define IMGFMT_UYNV 0x564E5955 #define IMGFMT_cyuv 0x76757963 #define IMGFMT_YUY2 0x32595559 #define IMGFMT_YUNV 0x564E5559 #define IMGFMT_YVYU 0x55595659 #define IMGFMT_Y41P 0x50313459 #define IMGFMT_Y211 0x31313259 #define IMGFMT_Y41T 0x54313459 #define IMGFMT_Y42T 0x54323459 #define IMGFMT_V422 0x32323456 #define IMGFMT_V655 0x35353656 #define IMGFMT_CLJR 0x524A4C43 #define IMGFMT_YUVP 0x50565559 #define IMGFMT_UYVP 0x50565955 Other things look - ok. Best regards! Nick |
|
From: Romain D. <do...@ir...> - 2001-09-27 08:01:39
|
Nick Kurshev wrote: > As I've found - mplayer knows much more video image formats: > > file main/libvo2/img_format.h Yes, FOURCC code. You're not the first one to mention them... The problem is, there's a bunch of them (see <http://www.webartz.com/fourcc/>, for those who don't know them), and advertising them isn't easy... Still, I guess I should use them ; I think I could add a 'number of FOURCC supported' field in the "struct fb_vidoverlay_avail", and add (yet) another ioctl to get only the variable-length FOURCC list. BTW, what do the linux-console folks think of adding video overlay support to Ruby ? -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Romain D. <do...@ir...> - 2001-09-27 09:31:33
Attachments:
fbvid.h
|
Romain Dolbeau wrote: > Still, I guess I should use them ; I think I could add > a 'number of FOURCC supported' field in the > "struct fb_vidoverlay_avail", and add (yet) another > ioctl to get only the variable-length FOURCC list. F-up myself, here's an updated file. The sample implementation in pm3fb compile (not near thebox, can't test it yet :-) Any comment/criticism/improvement/advice very much welcome. -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Nick K. <nic...@ma...> - 2001-09-28 06:18:13
|
Hello, Romain! On Thu, 27 Sep 2001 11:31:25 +0200, you wrote: > Romain Dolbeau wrote: > > > Still, I guess I should use them ; I think I could add > > a 'number of FOURCC supported' field in the > > "struct fb_vidoverlay_avail", and add (yet) another > > ioctl to get only the variable-length FOURCC list. > > F-up myself, here's an updated file. The sample implementation > in pm3fb compile (not near thebox, can't test it yet :-) > > Any comment/criticism/improvement/advice very much welcome. > > -- > DOLBEAU Romain | l'histoire est entierement vraie, puisque > ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre > do...@ir... | -- Boris Vian Well, it seems - o'k. I'm not sure - but what about having a support of hardware accelerated decoding? (I mean such things as mpeg1, mpeg2 decoding, de-zigzag and so on) Unfortunatelly I never saw any opensource project which has implementation of such things but if you know how it should be implemented then such extensions are gladly accepted too. Best regards! Nick |
|
From: Sven <lu...@dp...> - 2001-09-28 06:43:03
|
On Fri, Sep 28, 2001 at 09:48:52AM +0400, Nick Kurshev wrote: > Hello, Romain! > On Thu, 27 Sep 2001 11:31:25 +0200, you wrote: > > > Romain Dolbeau wrote: > > > > > Still, I guess I should use them ; I think I could add > > > a 'number of FOURCC supported' field in the > > > "struct fb_vidoverlay_avail", and add (yet) another > > > ioctl to get only the variable-length FOURCC list. > > > > F-up myself, here's an updated file. The sample implementation > > in pm3fb compile (not near thebox, can't test it yet :-) > > > > Any comment/criticism/improvement/advice very much welcome. > > > > -- > > DOLBEAU Romain | l'histoire est entierement vraie, puisque > > ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre > > do...@ir... | -- Boris Vian > Well, it seems - o'k. > I'm not sure - but what about having a support of hardware accelerated > decoding? (I mean such things as mpeg1, mpeg2 decoding, de-zigzag and so on) > Unfortunatelly I never saw any opensource project which has implementation > of such things but if you know how it should be implemented then such extensions > are gladly accepted too. mmm, The Xv extension to X does this. That said, i guess the problem here would be the same as for generic accels in the kernel, that is it will not go in. Most probably, a userland library would need to be created which could cooperate with the fbdev driver. Friendly, Sven Luther |
|
From: Michel <mic...@ii...> - 2001-09-28 13:33:37
|
Sven wrote: > > I'm not sure - but what about having a support of hardware accelerated > > decoding? (I mean such things as mpeg1, mpeg2 decoding, de-zigzag and so > > on) > > Unfortunatelly I never saw any opensource project which has implementation > > of such things but if you know how it should be implemented then such > > extensions are gladly accepted too. > > mmm, The Xv extension to X does this. No, all it can do is colorspace conversion and scaling. The brand new XvMC extension does this, the problem is the lack of documentation. There is only one implementation for i81x (done by an Intel employee) and no players support it yet. > That said, i guess the problem here would be the same as for generic accels > in the kernel, that is it will not go in. Most probably, a userland library > would need to be created which could cooperate with the fbdev driver. Like http://directfb.org ? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
|
From: Sven <lu...@dp...> - 2001-10-04 15:39:12
|
On Fri, Sep 28, 2001 at 03:33:17PM +0200, Michel D=E4nzer wrote: > Sven wrote: >=20 > > > I'm not sure - but what about having a support of hardware accelera= ted > > > decoding? (I mean such things as mpeg1, mpeg2 decoding, de-zigzag a= nd so > > > on) > > > Unfortunatelly I never saw any opensource project which has impleme= ntation > > > of such things but if you know how it should be implemented then su= ch > > > extensions are gladly accepted too. > >=20 > > mmm, The Xv extension to X does this. >=20 > No, all it can do is colorspace conversion and scaling. Yes, sure i meant XvMC, ... > The brand new XvMC extension does this, the problem is the lack of > documentation. There is only one implementation for i81x (done by an In= tel > employee) and no players support it yet. Err ? are you sure of it ? There are some new Xv* stuff in the pm3 driver= , altough since pm3 don't support anything fancy beside overlay, this could= not be any help for you. That said, You know about the document describing XvMC, it is not really = all that clear, and i looked at it only once, but it was announced on the xfr= ee list some time ago. Friendly, Sven Luther |
|
From: James S. <jsi...@tr...> - 2001-09-28 23:25:12
|
> That said, i guess the problem here would be the same as for generic accels in > the kernel, that is it will not go in. Most probably, a userland library would > need to be created which could cooperate with the fbdev driver. I agree. I think only support for hardware overlays should be. Most hardware even for embedded devices support overlays. As for mpeg coding that is a userland issue. |
|
From: James S. <jsi...@tr...> - 2001-09-27 16:56:43
|
> BTW, what do the linux-console folks think of adding > video overlay support to Ruby ? I have no problem with it. This way it can evolve a little bit before it becomes part of the main stream. |
|
From: <dol...@cl...> - 2001-09-27 18:32:52
|
> I have no problem with it. This way it can evolve a little bit before it > becomes part of the main stream. I'll try to add some more explanations/comments and I'll commit the stuff to the CVS tree. Then I'll need to port the -vidoverlay stuff from regular pm3fb... and hope other drivers will follow ;-) -- Romain DOLBEAU | Energy derives from both ENS Cachan / Ker Lann | the plus and negative Thesard IRISA / CAPS | -- Metallica dol...@cl... | in 'Eye of the Beholder' |
|
From: James S. <jsi...@tr...> - 2001-09-27 20:54:15
|
> I'll try to add some more explanations/comments and I'll commit the > stuff to the CVS tree. Then I'll need to port the -vidoverlay stuff from > regular pm3fb... and hope other drivers will follow ;-) Great! I look forward to it. |
|
From: Romain D. <do...@ir...> - 2001-09-28 08:31:57
|
James Simmons wrote: > Great! I look forward to it. Done. it's in linux/include/linux/fbvid.h Now, I still need to get pm3fb working in ruby :-( -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: James S. <jsi...@tr...> - 2001-09-28 23:23:42
|
> Now, I still need to get pm3fb working in ruby :-( I will play with it this weekend. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X