linux-fbdev-devel — linux-fbdev mailing list for project developers

Re: [Linux-fbdev-devel] The future of framebuffer

[Geert U. <ge...@li...>]

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

Re: [Linux-fbdev-devel] Future of Framebuffer

[Paul M. <pm...@mv...>]

On Thu, Oct 04, 2001 at 04:58:53PM -0700, James Simmons wrote:
> > > I have spoken about this before. I like to see both interfaces merge =
in
> > > the future. Especially with the desire to move from traditional device
> > > files to device filesystems. In the future their will be a graphics
> > > frilesystem to replace the two. Well that is my dream. Of course thei=
r are
> > > a few issues on design with DRI which I will not go into here. =20
> > >=20
> > This sounds like a potential Ruby issue to me (well, the FS part anyway=
s)..
> > how about starting a module for it (or hacking it into the existing tre=
e)?
>=20
> We could but it would be a huge job. Alot of devfs tinkering.=20
>=20
Why deal with devfs tinkering? It would make more sense to implement it as =
its
own native virtual fs. As an example.. could have something like /dev/gfx a=
s a
top level mountpoint for the fs, and then just mount on that (wouldn't matt=
er
if it were devfs or not).

As far as general interfaces go.. a drop-in replacement for the ioctl()'s
really wouldn't be that big of a deal.

For each device that registered with the system, things could be done like:

/dev/gfx/
    0/
        fb
	cmap
	...
	mode
    1/
        fb
	cmap
	...
	mode

and so on, and so forth..

/dev/fb{,/}0 would simply be a symlink to /dev/gfx/0/fb.

FBIOGETCMAP/FBIOPUTCMAP can be done away with by doing reads and writes to =
the
/dev/gfx/0/cmap dentry. Just as all other GET/PUT routines can be done away
with.

Instead of trying to do "special" dentry manipulation in the fs itself, I
think it'd make more sense to just provide a few common interfaces.. Devices
only really need to register themselves with the system.. it's up to the
fb layer to deal with creation of the dentrys and dealing with any kind of
special requests. (Just as it would the requirement for any other subsystem
(DRM anyone?) to deal with special files and registering callbacks with
the fs for them).

The fs itself only needs to do a few things.. provide a few routines for
device registration, and for registering callbacks. In the event that no
callback is provided (or no flags like read-only are set on the created
file), generic dcache routines can be utilized instead..

This could all be done with just having a small structure that contained
a pointer to the dentry struct and a pointer to a set of routines that
callbacks can be assigned to. (Then just check for the existance of a provi=
ded
callback registered with the dentry when things were allocated, and either
use those, or fallback on defaults).

Another advantage of this system is that people who have special needs with
the system can simply write a module that sets up the files it wants, and
registers some callbacks and have it either globally applied or limit it
specifically to a specific card.. Reducing the need for adding ioctl()'s.

All in all, this really shouldn't be that big of a deal.. I don't think an
initial implementation should be difficult at all.. laying out the API
would really be the biggest trick.

Comments?

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

Re: [Linux-fbdev-devel] Future of Framebuffer

[James S. <jsi...@tr...>]

On Thu, 4 Oct 2001, Paul Mundt wrote:

> On Thu, Oct 04, 2001 at 03:26:26PM -0700, James Simmons wrote:
> > I have spoken about this before. I like to see both interfaces merge in
> > the future. Especially with the desire to move from traditional device
> > files to device filesystems. In the future their will be a graphics
> > frilesystem to replace the two. Well that is my dream. Of course their are
> > a few issues on design with DRI which I will not go into here.  
> > 
> This sounds like a potential Ruby issue to me (well, the FS part anyways)..
> how about starting a module for it (or hacking it into the existing tree)?

We could but it would be a huge job. Alot of devfs tinkering. 

Re: [Linux-fbdev-devel] Future of Framebuffer

[James S. <jsi...@tr...>]

> Ick. Adding ioctl()'s shouldn't even be considered. Instead of _adding_ more,
> it really would be a lot cleaner to just gut them entirely and move to a
> real namespace system (gfxfs anyone?).. then you can have your direct pointer
> to video memory, colormap, and so on, and so forth..

Yes. This is what I have been advocating. You have to move away from the
one file descriptor to device ideal. We can have several files, each
representing a functionality of device. Plus this allows for network
transprancy and we can use scripts to do things like set a video mode.
This would be really nice.

> Getting fb to interoperate with the DRM code (and vice versa *cough* MTRR
> handling *end cough*) would clean a lot of that sort of stuff.. especially
> with things like DMA resource management. Would certainly make X happier.

Agree. 

Re: [Linux-fbdev-devel] Future of Framebuffer

[Paul M. <le...@Ch...>]

On Thu, Oct 04, 2001 at 03:26:26PM -0700, James Simmons wrote:
> I have spoken about this before. I like to see both interfaces merge in
> the future. Especially with the desire to move from traditional device
> files to device filesystems. In the future their will be a graphics
> frilesystem to replace the two. Well that is my dream. Of course their are
> a few issues on design with DRI which I will not go into here.  
> 
This sounds like a potential Ruby issue to me (well, the FS part anyways)..
how about starting a module for it (or hacking it into the existing tree)?

Regards,

-- 
Paul Mundt <le...@ch...>

Re: [Linux-fbdev-devel] Future of Framebuffer

[Paul M. <le...@Ch...>]

On Thu, Oct 04, 2001 at 03:33:18PM -0400, Chris Wright wrote:
> This is somewhat ironic, but a friend of mine and myself have been
> recently pondering vast extentions into the /dev/fb device.
> Basically, we see it as a great device already.  (a simple pointer to
> screen memory is all a graphics programmer ever wants).  however, most new
> hardware usually supports some form of 2d and 3d acceleration.
> unfortunately, these are seldom/never used in linux unless you have a card
> that is supported, and then, only if you use X, which defeats the purpose
> of /dev/fb.   we are proposing that a standard suite of ioctl's get added
> to aid in acceleration.  of course, the basic driver would be a simple
> vesafb driver plus software accelerations.  as cards are added, and
> drivers are ported, they could be used in the software's place.  This
> would make the hardware usable by anything, not just stuff in X, which
> seems like a Good Thing to me :^)
> 
Ick. Adding ioctl()'s shouldn't even be considered. Instead of _adding_ more,
it really would be a lot cleaner to just gut them entirely and move to a
real namespace system (gfxfs anyone?).. then you can have your direct pointer
to video memory, colormap, and so on, and so forth..

Getting fb to interoperate with the DRM code (and vice versa *cough* MTRR
handling *end cough*) would clean a lot of that sort of stuff.. especially
with things like DMA resource management. Would certainly make X happier.

Regards,

-- 
Paul Mundt <le...@ch...>

Re: [Linux-fbdev-devel] Future of Framebuffer

[James S. <jsi...@tr...>]

> IMO, DRM is best suited for this, except that DRM is currently only used by
> the DRI in X.  I would think this would be the way to go (instead of a new,
> clunky, IOCTL interface), but then the question becomes, do you want to
> duplicate all of the DRI work (since DRM is only concerned with the
> "basics", as it should be) for a fb interface?  Or would a fb-only
> interface independent of DRI (but still a Mesa backend) be better?

I have spoken about this before. I like to see both interfaces merge in
the future. Especially with the desire to move from traditional device
files to device filesystems. In the future their will be a graphics
frilesystem to replace the two. Well that is my dream. Of course their are
a few issues on design with DRI which I will not go into here.  

Re: [Linux-fbdev-devel] Future of Framebuffer

[M. R. B. <mr...@0x...>]

* Chris Wright <cw...@so...> on Thu, Oct 04, 2001:

> This is somewhat ironic, but a friend of mine and myself have been
> recently pondering vast extentions into the /dev/fb device.
> Basically, we see it as a great device already.  (a simple pointer to
> screen memory is all a graphics programmer ever wants).  however, most new
> hardware usually supports some form of 2d and 3d acceleration.
> unfortunately, these are seldom/never used in linux unless you have a card
> that is supported, and then, only if you use X, which defeats the purpose
> of /dev/fb.   we are proposing that a standard suite of ioctl's get added
> to aid in acceleration.  of course, the basic driver would be a simple
> vesafb driver plus software accelerations.  as cards are added, and
> drivers are ported, they could be used in the software's place.  This
> would make the hardware usable by anything, not just stuff in X, which
> seems like a Good Thing to me :^)
> 
> so, is it a completly idiotic idea, or is there some potential here?
> 

IMO, DRM is best suited for this, except that DRM is currently only used by
the DRI in X.  I would think this would be the way to go (instead of a new,
clunky, IOCTL interface), but then the question becomes, do you want to
duplicate all of the DRI work (since DRM is only concerned with the
"basics", as it should be) for a fb interface?  Or would a fb-only
interface independent of DRI (but still a Mesa backend) be better?

M. R.

[Linux-fbdev-devel] Future of Framebuffer

[Chris W. <cw...@so...>]

This is somewhat ironic, but a friend of mine and myself have been
recently pondering vast extentions into the /dev/fb device.
Basically, we see it as a great device already.  (a simple pointer to
screen memory is all a graphics programmer ever wants).  however, most new
hardware usually supports some form of 2d and 3d acceleration.
unfortunately, these are seldom/never used in linux unless you have a card
that is supported, and then, only if you use X, which defeats the purpose
of /dev/fb.   we are proposing that a standard suite of ioctl's get added
to aid in acceleration.  of course, the basic driver would be a simple
vesafb driver plus software accelerations.  as cards are added, and
drivers are ported, they could be used in the software's place.  This
would make the hardware usable by anything, not just stuff in X, which
seems like a Good Thing to me :^)

so, is it a completly idiotic idea, or is there some potential here?

	Computers are useless.  They can only give you answers.
        	        -- Pablo Picasso

Re: [Linux-fbdev-devel] How to output shell on 2 devices

[James S. <jsi...@tr...>]

Read linux/Documentation/serial-console.txt. It has all the info you need.

Re: [Linux-fbdev-devel] The future of framebuffer

[Nick K. <nic...@ma...>]

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

Re: [Linux-fbdev-devel] The future of framebuffer

[Sven <lu...@dp...>]

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

Re: [Linux-fbdev-devel] The future of framebuffer

[Nick K. <nic...@ma...>]

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

Re: [Linux-fbdev-devel] Re: FB, video, FOURCC code

[Sven <lu...@dp...>]

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

Re: [Linux-fbdev-devel] The future of framebuffer

[Sven <lu...@dp...>]

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

[Linux-fbdev-devel] How to output shell on 2 devices

[<chr...@ph...>]

Hello,

We are currently porting ARM Linux 2.4.2 (I know it's an old kernel...) on a board like the Assabet one.
I have written the framebuffer driver based on the sa1100 one.
It seems to work well since I got the Linux pinguin...And Busy Box is starting well...
...but I can't manage to output the shell on boh LCD (fb0) and serial line.

In fact all is output on the serial line (ttyDW4). I want to control the shell with the PC (through the serial line) but I want also things to be output on my LCD.
So in fact I would need to redirected to my LCD (fb0) all the data which come in and come out from the serial line, from where I command the shell.

Can someone explain me how to do that ?

And what about if I want to use the PC keyboard though the serial line without output on the PC itself (ie no characters output to PC but input ones taken into account)

Here my list of devices (ttyDW0-4 are our serial driver):

 crw--w--w-    1 root     root     5,   1 Oct  3 17:21 console
crw-r--r--    1 root     root     29,   0 Oct  3 17:25 fb0
crw-r--r--    1 root     root     1,   3 Oct  3 17:23 null
crw--w--w-    1 root     root     5,   0 Oct  4 10:44 tty
crw--w--w-    1 root     root     4,   0 Oct  3 17:21 tty0
crw-r--r--    1 root     root     204,   5 Oct  3 17:19 ttyDW0
crw-r--r--    1 root     root     204,   6 Oct  3 17:20 ttyDW1
crw-r--r--    1 root     root     204,   7 Oct  3 17:21 ttyDW2
crw-r--r--    1 root     root     204,   8 Oct  3 17:21 ttyDW3
crw-r--r--    1 root     root     204,   9 Oct  3 17:21 ttyDW4

Have a nice day.

Christophe

[Linux-fbdev-devel] vesafb and rdev

[James S. <jsi...@tr...>]

I have built a bootable rescue disk with make bzdisk which I need to use
the vesafb driver on. Unfortunely the vesafb isn't come up. I assume I
need to use rdev. Has anyone done this before so I know that exact command
I need.

Re: [Linux-fbdev-devel] unified accerated interface

[James S. <jsi...@tr...>]

> > They can't be added to 2.2/2.4, because they need the pixel-based
> > functions, 2.2/2.4 accel is cell-based only.
> 
> Do you really have to implement the pixel-based functions for all possible
> values? E.g. for mfb, afb and ilbm it's quite complex, and the console driver
> doesn't really need it. That's why we have the support for width field for the
> cell-based operations.

    Well no. I like to think of the accel functions as being more
functionality oriented. When using the accel engine you are not thinking
draw these pixel. You are thinking fill in or copy this area. Their exist
hardware which is not pixel based so I hope the api is flexiable enough to
handle this. 
    The above examples you gave are such a example of not the usually
pixel. mfb easily fits into the cfb. The code I have written supports it. 
I thought about ilbm. Since it is a bunch of bitmaps (1 to N) being one
after another and each bitmap is a collect of a bit value at position X in
the pixel where X is bitmap N. We could easily write soft accel functions. 
For a rectfill it is a matter of taking a color to fill in with and
reading one bit at a time and filling in a are in the bitmap with a group
of 1's or a whole group of 0's. As you can see this could be really fast.
As for drawing a image that has to be units of 8 fbcon handles that by
ensuring only fonts of size of units of 8 are allowed to be used. It
still has the test to prevent something naugthy from happening. As for
userland doing stuff. The drawimage function really not avaliable for
userland. Sure we can have ioctl to test the draw functions for a driver 
but we should leave it at that. Only for debugging purposes.

Re: [Linux-fbdev-devel] unified accerated interface

[James S. <jsi...@tr...>]

> Well, if you use the latest Ruby they are available :-)
> 
> It's just a standard wrapper around mandatory functions, in fbmem.c
> If the #define exist in the header fb.h, they are there...
> 
> They can't be added to 2.2/2.4, because they need the pixel-based
> functions, 2.2/2.4 accel is cell-based only.

Actaully I have written a wrapper to be used with 2.4.X. I don't like
to think of it as pixel based but more functionality based. You can use
other things to preform something like a triangle fill. Say a texture map
of one color. 

Re: [Linux-fbdev-devel] unified accerated interface

[James S. <jsi...@tr...>]

> You can also extend fbtest to use the ioctl()s when they are available (how to
> find out?).

I added a api_version feild into fb_fix_screeninfo. For the current api
we have this as reserved[3] which means it should have a value of zero
(not implemented). For newer drivers they shoudl set that feild to one.

Re: [Linux-fbdev-devel] unified accerated interface

[Romain D. <do...@ir...>]

Geert Uytterhoeven wrote:

> Do you really have to implement the pixel-based functions for all possible
> values? E.g. for mfb, afb and ilbm it's quite complex, and the console driver
> doesn't really need it. That's why we have the support for width field for the
> cell-based operations.

None of those driver exist in Ruby ;-)

The idea is, the pixel-based functions are _required_ in Ruby. Either
the driver supply them, or there's some generic functions for
the most common pixel type.

The ioctls simply give access to these functions to userland apps. They
don't have to worry on specific hardware, they just say 'copy
area "width*height+sourceX+sourceY" to "destX,destY"', or
'fill area "w*h+x+y" with color C'.

If there's driver where pixel-based stuff is problematic, tell
James or Vojtech, as it might cause worse problems than userland
accelerated drawing...

-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
                             |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian

Re: [Linux-fbdev-devel] unified accerated interface

[Geert U. <ge...@li...>]

On Wed, 3 Oct 2001, Romain Dolbeau wrote:
> Geert Uytterhoeven wrote:
> > You can also extend fbtest to use the ioctl()s when they are available (how to
> > find out?).
> 
> Well, if you use the latest Ruby they are available :-)
> 
> It's just a standard wrapper around mandatory functions, in fbmem.c
> If the #define exist in the header fb.h, they are there...
> 
> They can't be added to 2.2/2.4, because they need the pixel-based
> functions, 2.2/2.4 accel is cell-based only.

Do you really have to implement the pixel-based functions for all possible
values? E.g. for mfb, afb and ilbm it's quite complex, and the console driver
doesn't really need it. That's why we have the support for width field for the
cell-based operations.

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

Re: [Linux-fbdev-devel] unified accerated interface

[Romain D. <do...@ir...>]

Geert Uytterhoeven wrote:

> You can also extend fbtest to use the ioctl()s when they are available (how to
> find out?).

Well, if you use the latest Ruby they are available :-)

It's just a standard wrapper around mandatory functions, in fbmem.c
If the #define exist in the header fb.h, they are there...

They can't be added to 2.2/2.4, because they need the pixel-based
functions, 2.2/2.4 accel is cell-based only.

-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
                             |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian

Re: [Linux-fbdev-devel] unified accerated interface

[Geert U. <ge...@li...>]

On Wed, 3 Oct 2001, Romain Dolbeau wrote:
> James Simmons wrote:
> > Nope. Only thing I have is fb_image. I moved the stuff together for
> > userland to use. I have ROP_X in the kernel section. Now it is useable to
> > userland. We could extend it to support image drawing as well. Draw
> > writers can see if they get the penguin when insmoding.
> 
> I've added a small 'acceltest' app in ruby/utils, it's supposed
> to move a coloured rectangle to the bottom right corner of the
> screen. Not tested...

You can also extend fbtest to use the ioctl()s when they are available (how to
find out?).

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

Re: [Linux-fbdev-devel] unified accerated interface

[Romain D. <do...@ir...>]

James Simmons wrote:

> Nope. Only thing I have is fb_image. I moved the stuff together for
> userland to use. I have ROP_X in the kernel section. Now it is useable to
> userland. We could extend it to support image drawing as well. Draw
> writers can see if they get the penguin when insmoding.

I've added a small 'acceltest' app in ruby/utils, it's supposed
to move a coloured rectangle to the bottom right corner of the
screen. Not tested...

-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
                             |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian