From: Nick K. <nic...@ma...> - 2001-09-26 08:42:22
|
Hello! I have some questions about future of framebuffer. I'm wroting to this mailing list simply because I don't know where I can discuss further development of framebuffer technology. 1. What about adding video extensions to devfb? Many modern chips can accelerate video decoding. Since fbdev technology lacks such extensions in inet exist drivers which are fbdev based and were specially designed to speedup video decoding. They work through ioctls. Since framebuffer supports ioctls IMHO it would be better to standardize this feature to have possibility to expand existing drivers in this way. Samples: http://mplayerhq.hu/cgi-bin/cvsweb.cgi/main/drivers At least linux-kernel will contain them and people will not need to compile them independetly and install them manually. 2. What about NLS support? Since I have localized linux distribution - I can not read any messages which is written not in English. 3. Does exist any way to unload framebuffer module? I get only dead console when I try execute rmmod radeonfb. I ask other people which have non radeon frame buffers and they reported me about the same problems. Best regards! Nick P.S.: Please CC me - I'm not subscribed. |
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-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:11
|
> 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: GOTO M. <go...@de...> - 2001-09-27 01:40:13
|
At Wed, 26 Sep 2001 12:40:47 +0400, Nick Kurshev <nic...@ma...> wrote: > 2. What about NLS support? > Since I have localized linux distribution - I can not read > any messages which is written not in English. 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 |
From: Nick K. <nic...@ma...> - 2001-09-27 06:05:15
|
Hello, GOTO! On Thu, 27 Sep 2001 10:40:08 +0900, you wrote: > At Wed, 26 Sep 2001 12:40:47 +0400, > Nick Kurshev <nic...@ma...> wrote: > > 2. What about NLS support? > > Since I have localized linux distribution - I can not read > > any messages which is written not in English. > > 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. Best regards! Nick |
From: GOTO M. <go...@de...> - 2001-09-27 09:25:26
|
Hi, At Thu, 27 Sep 2001 09:59:52 +0400, Nick Kurshev <nic...@ma...> wrote: > > At Wed, 26 Sep 2001 12:40:47 +0400, > > Nick Kurshev <nic...@ma...> wrote: > > > 2. What about NLS support? > > > Since I have localized linux distribution - I can not read > > > any messages which is written not in English. > > > > 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... -- gotom |
From: Nick K. <nic...@ma...> - 2001-09-27 10:05:14
|
Hello, GOTO! On Thu, 27 Sep 2001 18:25:19 +0900, you wrote: > Hi, > > At Thu, 27 Sep 2001 09:59:52 +0400, > Nick Kurshev <nic...@ma...> wrote: > > > At Wed, 26 Sep 2001 12:40:47 +0400, > > > Nick Kurshev <nic...@ma...> wrote: > > > > 2. What about NLS support? > > > > Since I have localized linux distribution - I can not read > > > > any messages which is written not in English. > > > > > > 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... > > -- gotom > I guess - it's big problem. Indeed linux should has full collections of different fonts. But it will make distributive too huge. IMHO it would be better to move out such packages (like fbdev) from kernel and have it as 3-rd addons (plugins) for kernel. In this case the site (for example linux-fbdev) should contain the full collection of fonts. Each font should be downloadable independedly. But it will possible if linux presidents will want to add link on 3rd drivers from /lib/modules/kernel-ver (for example /lib/modules/kernel-ver/3rd-drivers) which should point to permanent location. Otherwise people will copy such drivers manually after each kernel updating. Best regards! Nick |
From: Sven <lu...@dp...> - 2001-09-27 13:47:23
|
On Thu, Sep 27, 2001 at 02:09:56PM +0400, Nick Kurshev wrote: > Hello, GOTO! > On Thu, 27 Sep 2001 18:25:19 +0900, you wrote: > > > Hi, > > > > At Thu, 27 Sep 2001 09:59:52 +0400, > > Nick Kurshev <nic...@ma...> wrote: > > > > At Wed, 26 Sep 2001 12:40:47 +0400, > > > > Nick Kurshev <nic...@ma...> wrote: > > > > > 2. What about NLS support? > > > > > Since I have localized linux distribution - I can not read > > > > > any messages which is written not in English. > > > > > > > > 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... > > > > -- gotom > > > I guess - it's big problem. Indeed linux should has full collections > of different fonts. But it will make distributive too huge. > IMHO it would be better to move out such packages (like fbdev) from kernel Huh, why move all the fbdev out, the only thing you need to modularize is the fonts used, not the fbdev. BTW, can't we generate the fonts from the ones used by vgacon ? Friendly, Sven Luther |
From: Nick K. <nic...@ma...> - 2001-09-28 06:18:24
|
Hello, Sven! On Thu, 27 Sep 2001 15:47:20 +0200, you wrote: > On Thu, Sep 27, 2001 at 02:09:56PM +0400, Nick Kurshev wrote: > > Hello, GOTO! > > On Thu, 27 Sep 2001 18:25:19 +0900, you wrote: > > > > > Hi, > > > > > > At Thu, 27 Sep 2001 09:59:52 +0400, > > > Nick Kurshev <nic...@ma...> wrote: > > > > > At Wed, 26 Sep 2001 12:40:47 +0400, > > > > > Nick Kurshev <nic...@ma...> wrote: > > > > > > 2. What about NLS support? > > > > > > Since I have localized linux distribution - I can not read > > > > > > any messages which is written not in English. > > > > > > > > > > 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... > > > > > > -- gotom > > > > > I guess - it's big problem. Indeed linux should has full collections > > of different fonts. But it will make distributive too huge. > > IMHO it would be better to move out such packages (like fbdev) from kernel > > Huh, why move all the fbdev out, the only thing you need to modularize is the > fonts used, not the fbdev. > Because it can be compiled independedly from kernel. Because it is like mini-X. IMHO kernel should have only minimal part of drivers. (finely only set of drivers which should be compiled into kernel for normal working) but such thing as framebuffer, audio drivers and many other things could be safety moved from kernel out and be as satellite projects. > BTW, can't we generate the fonts from the ones used by vgacon ? > As I've found that linux doesn't contain character images except framebuffer's font files. But we can use fs/nls to convert DOS .cpi files to linux fonts. (Since on russian system DOS uses 866 codepage but Linux koi8-r). But in this case linux package will large of X package :( But IMHO it would be better th hove possibility to use dos.cpi files directly from Linux with iconv functionallity. > Friendly, > > Sven Luther > Best regards! Nick |
From: Sven <lu...@dp...> - 2001-09-28 06:28:53
|
On Fri, Sep 28, 2001 at 10:20:33AM +0400, Nick Kurshev wrote: > > Huh, why move all the fbdev out, the only thing you need to modularize is the > > fonts used, not the fbdev. > > > Because it can be compiled independedly from kernel. Because it is like mini-X. > IMHO kernel should have only minimal part of drivers. (finely only set of drivers which > should be compiled into kernel for normal working) but such thing as framebuffer, audio > drivers and many other things could be safety moved from kernel out and be as satellite > projects. Ah, but if you remove the fbdev from the kernel, many arches have no more console, in particular all those laking vga hardware. Also you loose the hability to get the penguin logo at boot time, or any other graphic that is, which would be a shame. Finally, removing many dirvers from the kernel and having them as external projects is only asking for problems, incompatibilities and bugs. It is not a nice thing to do. > > BTW, can't we generate the fonts from the ones used by vgacon ? > > > As I've found that linux doesn't contain character images except framebuffer's font files. > But we can use fs/nls to convert DOS .cpi files to linux fonts. (Since on russian system > DOS uses 866 codepage but Linux koi8-r). But in this case linux package will large of > X package :( But IMHO it would be better th hove possibility to use dos.cpi files directly > from Linux with iconv functionallity. Err, not sure i follow you here, but were are the dos.cpi info stored, in the vga card rom ? on the vfat filesystem ? in the bios ? Friendly, Sven Luther |
From: Nick K. <nic...@ma...> - 2001-09-28 08:50:06
|
Hello, Sven! On Fri, 28 Sep 2001 08:28:50 +0200, you wrote: > On Fri, Sep 28, 2001 at 10:20:33AM +0400, Nick Kurshev wrote: > > > Huh, why move all the fbdev out, the only thing you need to modularize is the > > > fonts used, not the fbdev. > > > > > Because it can be compiled independedly from kernel. Because it is like mini-X. > > IMHO kernel should have only minimal part of drivers. (finely only set of drivers which > > should be compiled into kernel for normal working) but such thing as framebuffer, audio > > drivers and many other things could be safety moved from kernel out and be as satellite > > projects. > > Ah, but if you remove the fbdev from the kernel, many arches have no more > console, in particular all those laking vga hardware. > > Also you loose the hability to get the penguin logo at boot time, or any other > graphic that is, which would be a shame. > 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. > Finally, removing many dirvers from the kernel and having them as external > projects is only asking for problems, incompatibilities and bugs. It is not a > nice thing to do. > There may be incompatibility but only if linux internal interface is changed but independed projects will not depend on it. Except case when major version of linux will changed but this situation is similar to having different drivers for Win95 and Win2000. In addition it will give possibility to update such drivers without updating the kernel and vice versa. > > > BTW, can't we generate the fonts from the ones used by vgacon ? > > > > > As I've found that linux doesn't contain character images except framebuffer's font files. > > But we can use fs/nls to convert DOS .cpi files to linux fonts. (Since on russian system > > DOS uses 866 codepage but Linux koi8-r). But in this case linux package will large of > > X package :( But IMHO it would be better th hove possibility to use dos.cpi files directly > > from Linux with iconv functionallity. > > Err, not sure i follow you here, but were are the dos.cpi info stored, in the > vga card rom ? on the vfat filesystem ? in the bios ? > On vfat. But IMHO each computer had preinstalled DOS as they have preinstalled Win9x now. Anyway exist FreeDOS and other similar systems where such files could be taken. > Friendly, > > Sven Luther > Best regards! Nick |
From: Sven <lu...@dp...> - 2001-10-04 11:40:49
|
On Fri, Sep 28, 2001 at 12:45:24PM +0400, Nick Kurshev wrote: > Hello, Sven! > On Fri, 28 Sep 2001 08:28:50 +0200, you wrote: >=20 > > On Fri, Sep 28, 2001 at 10:20:33AM +0400, Nick Kurshev wrote: > > > > Huh, why move all the fbdev out, the only thing you need to modul= arize is the > > > > fonts used, not the fbdev. > > > >=20 > > > Because it can be compiled independedly from kernel. Because it is = like mini-X. > > > IMHO kernel should have only minimal part of drivers. (finely only = set of drivers which > > > should be compiled into kernel for normal working) but such thing a= s framebuffer, audio > > > drivers and many other things could be safety moved from kernel out= and be as satellite > > > projects. > >=20 > > Ah, but if you remove the fbdev from the kernel, many arches have no = more > > console, in particular all those laking vga hardware. > >=20 > > Also you loose the hability to get the penguin logo at boot time, or = any other > > graphic that is, which would be a shame. > >=20 > These things could be handled by vesafb which can't be compiled as modu= le. > AFAIK VBE3.0 already have standardized such things as DGA, video extens= ions > and even audio interface. Althrough exist cards which don't support VES= A > but such cards may not support graphics modes too. 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 compa= tible. Also you plainly forget all those where VESA support is somewhat broken. and if you use vesafb, you already have most of the fbdve infrastructure = in anyway, so why not use decent drivers ? You problem here is only with the fonts, why not use modular fonts that c= an be loaded, or even fonts provided by a userland app ? > > Finally, removing many dirvers from the kernel and having them as ext= ernal > > projects is only asking for problems, incompatibilities and bugs. It = is not a > > nice thing to do.=20 > >=20 > There may be incompatibility but only if linux internal interface is ch= anged > but independed projects will not depend on it. Except case when major v= ersion of Sure, but this has not been the case in the past, so ... > linux will changed but this situation is similar to having different dr= ivers > for Win95 and Win2000. And is the main reason for all those crashes you get in windows : badly written or plain incompatible drivers. > In addition it will give possibility to update such drivers without upd= ating > 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 ? > > > > BTW, can't we generate the fonts from the ones used by vgacon ? > > > >=20 > > > As I've found that linux doesn't contain character images except fr= amebuffer's font files. > > > But we can use fs/nls to convert DOS .cpi files to linux fonts. (Si= nce on russian system > > > DOS uses 866 codepage but Linux koi8-r). But in this case linux pac= kage will large of > > > X package :( But IMHO it would be better th hove possibility to use= dos.cpi files directly > > > from Linux with iconv functionallity. > >=20 > > Err, not sure i follow you here, but were are the dos.cpi info stored= , in the > > vga card rom ? on the vfat filesystem ? in the bios ? > >=20 > On vfat. But IMHO each computer had preinstalled DOS as they have prein= stalled Win9x now. Sure, again, you are i386 centric, i doubt you will get WIn9x preinstalle= d on those sparc boxed, or maybe on some older m68k one, or ... ? > Anyway exist FreeDOS and other similar systems where such files could b= e taken. Sure, but there is surely a better solution available ? Friendly, Sven Luther |
From: Nick K. <nic...@ma...> - 2001-10-04 15:55:41
|
Hello, Sven! On Thu, 4 Oct 2001 13:40:27 +0200, you wrote: > On Fri, Sep 28, 2001 at 12:45:24PM +0400, Nick Kurshev wrote: > > Hello, Sven! > > On Fri, 28 Sep 2001 08:28:50 +0200, you wrote: > > > > > On Fri, Sep 28, 2001 at 10:20:33AM +0400, Nick Kurshev wrote: > > > > > Huh, why move all the fbdev out, the only thing you need to modularize is the > > > > > fonts used, not the fbdev. > > > > > > > > > Because it can be compiled independedly from kernel. Because it is like mini-X. > > > > IMHO kernel should have only minimal part of drivers. (finely only set of drivers which > > > > should be compiled into kernel for normal working) but such thing as framebuffer, audio > > > > drivers and many other things could be safety moved from kernel out and be as satellite > > > > projects. > > > > > > Ah, but if you remove the fbdev from the kernel, many arches have no more > > > console, in particular all those laking vga hardware. > > > > > > Also you loose the hability to get the penguin logo at boot time, or any other > > > graphic that is, which would be a shame. > > > > > 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. > > 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.Ю or later compatible. > > Also you plainly forget all those where VESA support is somewhat broken. > > and if you use vesafb, you already have most of the fbdve infrastructure in > anyway, so why not use decent drivers ? > I'm sorry - I didn't know about non-x86 architectures. > 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? > > > Finally, removing many dirvers from the kernel and having them as external > > > projects is only asking for problems, incompatibilities and bugs. It is not a > > > nice thing to do. > > > > > There may be incompatibility but only if linux internal interface is changed > > but independed projects will not depend on it. Except case when major version of > > Sure, but this has not been the case in the past, so ... > > > linux will changed but this situation is similar to having different drivers > > for Win95 and Win2000. > > And is the main reason for all those crashes you get in windows : badly > written or plain incompatible drivers. > Windows (NT series) have only badly written kernel which crashes too frequently ;) > > 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. AFAIK - main problems of fbdev will be fixed only in 2.5 kernels (I hope not in 2.7;) (I mean - at least correct unloading fbdev by 'rmmod fbdev' althrough it's meaningless on non-x86) Thus mainstream of x86-users will wait until Linux-2.6 will be introduced. > > > > > BTW, can't we generate the fonts from the ones used by vgacon ? > > > > > > > > > As I've found that linux doesn't contain character images except framebuffer's font files. > > > > But we can use fs/nls to convert DOS .cpi files to linux fonts. (Since on russian system > > > > DOS uses 866 codepage but Linux koi8-r). But in this case linux package will large of > > > > X package :( But IMHO it would be better th hove possibility to use dos.cpi files directly > > > > from Linux with iconv functionallity. > > > > > > Err, not sure i follow you here, but were are the dos.cpi info stored, in the > > > vga card rom ? on the vfat filesystem ? in the bios ? > > > > > On vfat. But IMHO each computer had preinstalled DOS as they have preinstalled Win9x now. > > Sure, again, you are i386 centric, i doubt you will get WIn9x preinstalled on > those sparc boxed, or maybe on some older m68k one, or ... ? > > > Anyway exist FreeDOS and other similar systems where such files could be taken. > > Sure, but there is surely a better solution available ? > Yes - having of independedly downloadable fbdev modules and NLS font files. > Friendly, > > Sven Luther > Best regards! Nick |
From: Sven <lu...@dp...> - 2001-10-04 16:08:05
|
On Thu, Oct 04, 2001 at 07:58:51PM +0400, Nick Kurshev wrote: > Hello, Sven! > > Sure, but you aren't listening, you just plainly ignore all the non-i= 386 > > hardware out there, as well as all the older vide ocards. And there a= re a lot > > of graphic cards that are supported but are not VESA 2.=E0 or later c= ompatible. > >=20 > > Also you plainly forget all those where VESA support is somewhat brok= en. > >=20 > > and if you use vesafb, you already have most of the fbdve infrastruct= ure in > > anyway, so why not use decent drivers ? > >=20 > I'm sorry - I didn't know about non-x86 architectures. Remember, fbdev was first developped by Geert on amiga hardware for linux/m68k, if i am not mistaken. These hardware don't have text consoles= , and thus fbdev is a must have on those. vesafb is simply a nice way to have X running on cards which are not supp= orted by XFree86, as well as providing a penguin logo, and a place for some oth= er kind of experimentation. > > You problem here is only with the fonts, why not use modular fonts th= at can be > > loaded, or even fonts provided by a userland app ? > >=20 > Unfortunately - linux documentations lacks (or hides) such information. > Could you send me URL, please? There is the fbdev web site, i think, as well as the linux source code naturally, for something else, you would have to search ... > > > > Finally, removing many dirvers from the kernel and having them as= external > > > > projects is only asking for problems, incompatibilities and bugs.= It is not a > > > > nice thing to do.=20 > > > >=20 > > > There may be incompatibility but only if linux internal interface i= s changed > > > but independed projects will not depend on it. Except case when maj= or version of > >=20 > > Sure, but this has not been the case in the past, so ... > >=20 > > > linux will changed but this situation is similar to having differen= t drivers > > > for Win95 and Win2000. > >=20 > > And is the main reason for all those crashes you get in windows : bad= ly > > written or plain incompatible drivers. > >=20 > Windows (NT series) have only badly written kernel which crashes too fr= equently ;) I heard that many of those crashes came from drivers from non reliable th= ird parties. > > > In addition it will give possibility to update such drivers without= updating > > > the kernel and vice versa. > >=20 > > I can already do that, Or do you think i need to rebuild the kernel e= ach time > > i change a line in some fbdev driver code ? > >=20 > When I'd write a little Makefile for my tiny driver then I'd got such p= ossibility 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 kerne= l on their computers. > AFAIK - main problems of fbdev will be fixed only in 2.5 kernels (I hop= e not in 2.7;) > (I mean - at least correct unloading fbdev by 'rmmod fbdev' althrough i= t's meaningless on non-x86) > Thus mainstream of x86-users will wait until Linux-2.6 will be introduc= ed. Well, i hear it is well possible, the real problem is that you need anoth= er fbdev to put the console on in the meantime. if you have 2 fbdve, it can = be done. I think it really is a bug of the vgacon layer or whatever, ... Friendly, Sven Luther |
From: Nick K. <nic...@ma...> - 2001-10-04 16:50:10
|
Hello, Sven! On Thu, 4 Oct 2001 18:07:51 +0200, you wrote: > On Thu, Oct 04, 2001 at 07:58:51PM +0400, Nick Kurshev wrote: > > Hello, Sven! > > > 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.Ю or later compatible. > > > > > > Also you plainly forget all those where VESA support is somewhat broken. > > > > > > and if you use vesafb, you already have most of the fbdve infrastructure in > > > anyway, so why not use decent drivers ? > > > > > I'm sorry - I didn't know about non-x86 architectures. > > Remember, fbdev was first developped by Geert on amiga hardware for > linux/m68k, if i am not mistaken. These hardware don't have text consoles, and > thus fbdev is a must have on those. > > vesafb is simply a nice way to have X running on cards which are not supported > by XFree86, as well as providing a penguin logo, and a place for some other > kind of experimentation. > Main plus of fbdev which I've found it's the fact that fbdev is running at CPL 0 (on x86 cpus) i.e. have kernel level of priviledges agains X11 which is running on CPL - user level. Therefore it's best way to have top fast video drivers but not only graphics console. > > > 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? > > There is the fbdev web site, i think, as well as the linux source code > naturally, for something else, you would have to search ... > From linux-kernel mailing list: On Sat, 25 Jul 1998, J. Patrick Avery Junior wrote: > 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 ;) > > > > > Finally, removing many dirvers from the kernel and having them as external > > > > > projects is only asking for problems, incompatibilities and bugs. It is not a > > > > > nice thing to do. > > > > > > > > > There may be incompatibility but only if linux internal interface is changed > > > > but independed projects will not depend on it. Except case when major version of > > > > > > Sure, but this has not been the case in the past, so ... > > > > > > > linux will changed but this situation is similar to having different drivers > > > > for Win95 and Win2000. > > > > > > And is the main reason for all those crashes you get in windows : badly > > > written or plain incompatible drivers. > > > > > Windows (NT series) have only badly written kernel which crashes too frequently ;) > > I heard that many of those crashes came from drivers from non reliable third > parties. > But I have a big practice in using of Windows OSes and know that blue screen of dead can be caused by simplest DOS program and such crashes rather occur inside of kernel than in drivers. At least after upgrading nvidia drivers from inet - all video problems were disapeared but kernel's problem are still living. > > > > 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. > > AFAIK - main problems of fbdev will be fixed only in 2.5 kernels (I hope not in 2.7;) > > (I mean - at least correct unloading fbdev by 'rmmod fbdev' althrough it's meaningless on non-x86) > > Thus mainstream of x86-users will wait until Linux-2.6 will be introduced. > > Well, i hear it is well possible, the real problem is that you need another > fbdev to put the console on in the meantime. if you have 2 fbdve, it can be > done. > > I think it really is a bug of the vgacon layer or whatever, ... > Anyway - it would be better to move drivers like fbdev, audio and other out from kernel. But kernel should have mechanism to handle the 3rd party drivers. As for me - I already tired to reinstall alsa and lm_sensor drivers after each kernel updating. > Friendly, > > Sven Luther > Best regards! Nick |
From: Geert U. <ge...@li...> - 2001-10-05 05:38:10
|
On Thu, 4 Oct 2001, Nick Kurshev wrote: > Anyway - it would be better to move drivers like fbdev, audio and other out from kernel. > But kernel should have mechanism to handle the 3rd party drivers. > As for me - I already tired to reinstall alsa and lm_sensor drivers after each kernel updating. So you're suggesting to move more drivers out of the kernel, while you complain that you're tired of the drivers that are already out of the kernel? 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 |