Menu
▾
▴
linux-fbdev-devel
|
From: Nick K. <nic...@ma...> - 2001-10-05 18:15:19
|
Hello, Sven!
On Fri, 5 Oct 2001 10:16:36 +0200, you wrote:
> On Thu, Oct 04, 2001 at 09:29:18PM +0400, Nick Kurshev wrote:
> > Hello, Sven!
> > > > > does anyone know where I can find the program 'cpi2fnt' referenced in
> > > > > linux/drivers/video/font_8x16.c?
> > > >
> > > > `cpi2fnt' is a very old AmigaOS program.
> > > >
> > > > Greetings,
> > > >
> > > > Geert
> > > >
> > > > So it seems that it's still big problem ;)
> > >
> > > Sure, you could look at it, you still need to have access to the cpi files
> > > though.
> > >
> > Only once to get linux compatible fonts. Anyway exist people who has dos.cpi files
> > and can do that.
>
> Well, but what is the licensing of those files ?
>
> Do we have a legal right to use them without someone claiming copyrigth and
> suing us over them ?
>
IMHO - these files were purchased, and their owners have rights to convert them
to any form. As extremal case - I'm able to make it by hand but it's stupid work
and currently linux has no fbdev-NLS to accept them.
> > > Err, because the drivers were loaded in the kernel and were run unprotected at
> > > CPL 0 or whatever you call it. It may be not the case with NVIdia, but try
> > > running older drivers for older video cards with a newer NT kernel or vice
> > > versa.
> > >
> > It's so understandable that I can't use nt4.0 drivers for 2000 same as linux-2.2 drivers
> > for linux-2.4 but I never told about such usage.
>
> Well, certain 2.4 drivers were backported for 2.2, and most 2.2 drivers still
> work for 2.4 kernels.
>
> Look at Romain Dolbeau's pm3fb drivers, there is only one source for both
> 2.2.x and 2.4.x kernels.
>
Do you mean a character devices?:
#if LINUX_VERSION_CODE >= 0x020400
static struct file_operations xxx_fops =
{
llseek: xxx_lseek,
read: xxx_read,
write: xxx_write,
ioctl: xxx_ioctl,
mmap: xxx_mmap,
open: xxx_open,
release: xxx_release
};
#else
static struct file_operations xxx_fops =
{
xxx_lseek,
xxx_read,
xxx_write,
NULL,
NULL,
xxx_ioctl,
xxx_mmap,
xxx_open,
NULL,
xxx_release
};
#endif
> > > This is typically the problem whcih are avoided by running the exact same
> > > version of linux and its drivers, built with the same compiler and same
> > > binutils.
> > >
> > But it is justly for any opensource drivers even if they are 3-rd party ones.
>
> No, you will get the kernel, build with redhat's broken gcc or whatever they
> released with version M.m, and build the modules with the currently fixed
> incompatible gcc.
>
IMHO you mean binary form but I mean source form. gcc version don't matter in this case.
> Only problems will come of it.
>
Let users use suggested gcc - and no problems.
> > > > Anyway - it would be better to move drivers like fbdev, audio and other out from kernel.
> > >
> > > And to where ?
> > >
> > > and for what real gain ?
> > >
> > Simply because I need only one audio driver but not full collection for every audio card.
>
> Just build yourself a custom kernel config, and after unpacking a new kernel,
> run make oldconfig on it, and build your kernel.
>
> If you worry about additional patches, debian kernel-package program together
> with an appropriate kernel-patch package will build the kernel for you without
> problem. It will even build a nice debian package containing it.
>
> > >From other side - kernel don't require them for normal working but they will enlarge kernel
> > sources up to infinity in the nearest future. (It's impossible to have support for
> > any hardware in one package)
>
> Well, why not, linux kernel is many many times smaller than NTs code.
>
But I never download NT through my modem as Linux.
> > > You can already build most of them as modules, isn't that what you want ?
> > >
> > > > But kernel should have mechanism to handle the 3rd party drivers.
> > >
> > > Well, i suppose you mean closed source i386 only commercial 3rd party drivers.
> > > No, you will not get much support about these kind of stuff.
> > >
> > There exist many firms which don't want to open sources or documenation on their hardware
>
> Just boycott them, ...
>
It's possible for HomePC only.
> Unless they release drivers for all arches supported by linux, and not just
> only i386.
>
> Also you can have no guarantee that a bug is not present, and if found that it
> may be closed some day.
>
> Closed source drivers are _BAD_, it should not be encouraged.
>
But they are better than nothing.
> > simply because it will give possibility to avoid some hardware features (like copy protection
> > mechanism of tv-out chips and so on) but as result linux world have no support for such hardware
> > or its parts.
>
> There is no way copy protectioncan be implemented in hardware, there are even
> closed source windows program that allow you to patch the corresponding
> windows code to extract the DVD data while visualising.
>
But it is illegal and privacy software.
Anyway such programs can't be by legal stuff.
> Anyway, if i buy a DVD or a CD, i expect to be able to use it, in any way that
> it pleases me, and we already pay a tax on blank videos tapes, tapes or even
> CDRs, so ...
>
Agree. But when you buy DVD you meet these problems everywhere.
If someone have purchase DVD in America then why he can't use it in Europe?
Since DVD has too many limitations of its usage may be we should to boycott them too? ;)
> > > > As for me - I already tired to reinstall alsa and lm_sensor drivers after each kernel updating.
> > >
> > > Mmm, aren't alsa in the kernel ? And what does it really offer more than the
> > > standard kernel sound drivers ?
> > >
> > Alsa it's disputable sample but lm_sensors offer really inuque features which currently
> > don't exist in the kernel.
>
> And do you know why that is ? What is the reason for it not being accepted by
> linus ? If you really feel like it, you could look at it, fix anything that
> needs fixing, and have that functionality included in the official kernel.
>
AFAIK - Linus has around 100-500 patches avery single day.
Do you guess that he is able to process every of them?
From other point - if Linus has XXX hardware but have received patch (or driver)
for YYY hardware then how he can be sure that accepted patch is workable?
He can do that only from compilation point.
> > > Remember, what is in the stable kernels is considered as stable, you have no
> > > such guarantee about random third parties drivers.
> > >
> > What I'm losing if I'll get broken sensor driver? IMHO - nothing.
> > (It's truth for fbdev on x86 platforms)
>
> Well, apart from possible random bad code. If it is not in the official
> kernel, then it can only be that nobody cares enough about it, or that the big
> guys (linus and co) feel that there is a problem with it, be it techincal or
> licence. In any way, i would have more confidence in them than in any third
> party driver writer.
>
From hipotetical point - if I get broken driver of file system then it will be tragedy
personally for me.
But for what Linux should has these unsignificand from stability point drivers (audio, fbdev, sensors)?
IMHO they are unnecessary pressing on kernel and on its author. Moving such drivers
from kernel only will give possibility to build more qualitative Linux and attract
much more people for building Linux infrastructure.
> Friendly,
>
> Sven Luther
>
Best regards! Nick
|
|
From: Paul M. <le...@Ch...> - 2001-10-05 20:04:29
|
On Fri, Oct 05, 2001 at 10:20:04PM +0400, Nick Kurshev wrote:
> Do you mean a character devices?:
>
> #if LINUX_VERSION_CODE >= 0x020400
> static struct file_operations xxx_fops =
> {
> llseek: xxx_lseek,
> read: xxx_read,
> write: xxx_write,
> ioctl: xxx_ioctl,
> mmap: xxx_mmap,
> open: xxx_open,
> release: xxx_release
> };
> #else
> static struct file_operations xxx_fops =
> {
> xxx_lseek,
> xxx_read,
> xxx_write,
> NULL,
> NULL,
> xxx_ioctl,
> xxx_mmap,
> xxx_open,
> NULL,
> xxx_release
> };
> #endif
>
Er.. this is utterly useless by the way. the above notation is not a 2.4
specific thing.
static struct file_operations xxx_fops = {
llseek: xxx_llseek,
read: xxx_read,
write: xxx_write,
ioctl: xxx_ioctl,
mmap: xxx_mmap,
open: xxx_open,
release: xxx_release,
};
works just fine the way it is. strict ansi C doesn't like it.. but it's a
standard anyways. c99 notation for the same thing is:
static struct file_operations xxx_fops = {
.llseek = &xxx_llseek,
.read = &xxx_read,
.write = &xxx_write,
.ioctl = &xxx_ioctl,
.mmap = &xxx_mmap,
.open = &xxx_open,
.release = &xxx_release,
};
though I don't care for c99 in general.
Anything that still does the "let's fill in all function pointers with NULL if
we don't have a function, and list everything in order" thing is broken and
needs to be fixed.
Regards,
--
Paul Mundt <le...@ch...>
|
|
From: Geert U. <ge...@li...> - 2001-10-05 05:37:03
|
On Thu, 4 Oct 2001, Sven wrote:
> On Thu, Oct 04, 2001 at 07:58:51PM +0400, Nick Kurshev wrote:
> > > Sure, but you aren't listening, you just plainly ignore all the non=
-i386
> > > hardware out there, as well as all the older vide ocards. And there=
are a lot
> > > of graphic cards that are supported but are not VESA 2.=E0 or later=
compatible.
> > >=20
> > > Also you plainly forget all those where VESA support is somewhat br=
oken.
> > >=20
> > > and if you use vesafb, you already have most of the fbdve infrastru=
cture in
> > > anyway, so why not use decent drivers ?
> > >=20
> > I'm sorry - I didn't know about non-x86 architectures.
>=20
> Remember, fbdev was first developped by Geert on amiga hardware for
> linux/m68k, if i am not mistaken. These hardware don't have text consol=
es, and
Slight correction: by Martin Schaller on Atari. But he disappeared from t=
he
scene and I took over.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m6=
8k.org
In personal conversations with technical people, I call myself a hacker. =
But
when I'm talking to journalists I just say "programmer" or something like=
that.
-- Linus Torvalds
|
|
From: Sven <lu...@dp...> - 2001-10-05 08:18:22
|
On Fri, Oct 05, 2001 at 07:36:38AM +0200, Geert Uytterhoeven wrote: > On Thu, 4 Oct 2001, Sven wrote: > > On Thu, Oct 04, 2001 at 07:58:51PM +0400, Nick Kurshev wrote: > > > > Sure, but you aren't listening, you just plainly ignore all the n= on-i386 > > > > hardware out there, as well as all the older vide ocards. And the= re are a lot > > > > of graphic cards that are supported but are not VESA 2.=E0 or lat= er compatible. > > > >=20 > > > > Also you plainly forget all those where VESA support is somewhat = broken. > > > >=20 > > > > and if you use vesafb, you already have most of the fbdve infrast= ructure in > > > > anyway, so why not use decent drivers ? > > > >=20 > > > I'm sorry - I didn't know about non-x86 architectures. > >=20 > > Remember, fbdev was first developped by Geert on amiga hardware for > > linux/m68k, if i am not mistaken. These hardware don't have text cons= oles, and >=20 > Slight correction: by Martin Schaller on Atari. But he disappeared from= the > scene and I took over. Yes, i remembered something such, but wasn't really sure about it. Friendly, Sven Luther |
|
From: Geert U. <ge...@li...> - 2001-10-05 05:35:58
|
On Thu, 4 Oct 2001, Nick Kurshev wrote:
> On Thu, 4 Oct 2001 13:40:27 +0200, you wrote:
> > On Fri, Sep 28, 2001 at 12:45:24PM +0400, Nick Kurshev wrote:
> > You problem here is only with the fonts, why not use modular fonts that can be
> > loaded, or even fonts provided by a userland app ?
> >
> Unfortunately - linux documentations lacks (or hides) such information.
> Could you send me URL, please?
Font loading behaves the same with or witout fbdev. So look up the generic
console documentation.
> > > In addition it will give possibility to update such drivers without updating
> > > the kernel and vice versa.
> >
> > I can already do that, Or do you think i need to rebuild the kernel each time
> > i change a line in some fbdev driver code ?
> >
> When I'd write a little Makefile for my tiny driver then I'd got such possibility too.
> If you are developer therefore you have no such problems but many users use
> only stable Linus kernels and they will never install even -pre.X kernel on their computers.
What has this to do with -pre.X kernels? It's been working since ages.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: James S. <jsi...@tr...> - 2001-09-27 17:12:46
|
> > > Is this console program or kernel issue? > > > fbcon is ready for single byte characters, and > > > jfbterm is ready for more complex language like UTF, EUC, ISO-2022. > > > Also console-tools is becoming ready for single byte characters and > > > UTF-8. But I've never seen multibyte characters with default > > > terminal (with console-tools). > > > > > > -- gotom > > > > > As I see NLS depends on drivers/video/font_8x??.c which were generated by cpi2font. > > Curently Linux has only english version of these files. > > Right. Currently there is only ISO-8859-1 characters. > Is it useful to add more characters for ISO-8859-x or > KOI-8 people ? > I'm interesting, but I don't know whether there are some demands or not. > > But, adding more complex characters like EUC and ISO-2022 > is more difficult, because they are multibyte characters. > Handling them is some more hack. > Their character file is very big because their font have > more than 30000. Full or partial UTF-8 support invites > this problem. These days linux has large nls file in fs/nls, > so I think it's ok, but someone complain about this issue... The linux console is based VGA text hardware which can only do 8 bit fonts and only display at most 512 different fonts. So the very backbone of the console system is limited. I like to see this expanded for 2.5.X. The framebuffer system could handle it very nicely. Just systems like MDA and VGA couldn't. Now I don't advocate placing 10,000 characters in the kernel. I do support have support for them and then having userland tools that can load such font sets for use. |
|
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:46
|
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 08:58:47
|
Nick Kurshev wrote: > These things could be handled by vesafb which can't be compiled as module. > AFAIK VBE3.0 already have standardized such things as DGA, video extensions > and even audio interface. Althrough exist cards which don't support VESA > but such cards may not support graphics modes too. Nope. All video card on Mac (m68k or PPC) are purely graphics (no text mode), and none of them support directly VGA/VESA/ whatever from the x86 world. I'm sure there's similar situation on other architecture. -- 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 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:48
|
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:05
|
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
|
×
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