linux-fbdev-devel Mailing List for Linux Frame Buffer Device Development (Page 594)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Applied to my tree. Thanks for the patch.

Look in your /etc/inittab and see if the flag --noclear is passed to
minigetty. Remove that flag to get ride of this behavior.

> I insmod my fb and messages appear on the console but the login prompt
> does not appear. I have to hit enter to get it to show up.
> 
> Can anyone explain this behavior?

Gerd Knorr wrote:
> That's IMHO no excuse.  The old ones can't be changed without breaking
> compatibility of course, but for new ones it should be done the
> RightWay[tm].

You're right, but then you need to know what prefix you can
use. I asked for pm3fb and got no response. I don't know
what to use for adding IOCTL to generic FB stuff...

And as long as it's a draft it's easy to change :-)

> And please add some comments saying which is planar/packed.

will do.

> There still would be image data in the buffer, and the image has some
> width / height.  Even if you are going to use that image buffer for
> something else than overlay (texture, bitblit or whatever).
> 
> IMHO it is important to let the driver pick the buffer size to avoid
> trouble due to hardware limitations / alignment issues / ...
> which the application doesn't know about.

My current idea was the app was told about alignement issue
in _CAP, and could require the size it needs by computing
(pixelsize*paddedX*paddedY), and require that size or more.
The driver return the base adress of the buffer (or 0 for
failure) and the actual size of the buffer (>= required
or 0 for failure). Also, it returns the number of the buffer
if it was (-1) as you suggested.

I agree the driver can do the size computing by itself,
but I still thinks it's better to keep the actual
data size in the _START call to allow for larger-than-
image buffer.

> Hmm, is this _really_ a problem?  Do you want to mix that with
> console?  I'd expect graphic applications whould use that only,
> like fbtv, dvd players (there is a fb-based one IIRC), ...

Yes, if you want to be able to use the text console while
displaying stuff like video or a still image. One could
use `fbi' (:-) to display a background picture or `fbtv'
for background movie/video stream. It's an overlay,
it should behave nicely toward the foreground app,
even fbcon. IMHO :-)

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

On Wed, Jul 11, 2001 at 04:35:07PM +0200, Romain Dolbeau wrote:
> Gerd Knorr wrote:
> 
> > Better use the _IOR / _IOW / _IOWR macros.
> 
> ATM FB doesn't use them, so I picked up a bunch of value
> in sequence.

That's IMHO no excuse.  The old ones can't be changed without breaking
compatibility of course, but for new ones it should be done the
RightWay[tm].

> Packed Pixel was in my mind. I'll add the other.
> (the pm3 doesn't have YUV420 :-( )

And please add some comments saying which is planar/packed.

> > I'd pass pixeltype + width + height here and let the driver calculate +
> > return the image size and scanline length.  The driver can easily take
> > care about alignment and related issues then.
> 
> The idea was the App could allow an arbitrary buffer and
> do whatever it pleases in it, including somthing entirely
> different from overlay. It might be useful if one
> add a in-FB-memory copy IOCTL or API.

There still would be image data in the buffer, and the image has some
width / height.  Even if you are going to use that image buffer for
something else than overlay (texture, bitblit or whatever).

> Also I though that the only overlay-related info
> would be put in FBIOPUT_VIDOVERLAY_START, and
> never stored in the driver (except for buffer
> data), only in the app.

IMHO it is important to let the driver pick the buffer size to avoid
trouble due to hardware limitations / alignment issues / ...
which the application doesn't know about.

> > >       __u16 blend_factor;             /* blending factor */
> > 
> > add chroma key (rage) here ?
> 
> The problem is, how to handle the mix between the overlay
> and the console layer.

Hmm, is this _really_ a problem?  Do you want to mix that with
console?  I'd expect graphic applications whould use that only,
like fbtv, dvd players (there is a fb-based one IIRC), ...

  Gerd

-- 
Damn lot people confuse usability and eye-candy.

Gerd Knorr wrote:

> Better use the _IOR / _IOW / _IOWR macros.

ATM FB doesn't use them, so I picked up a bunch of value
in sequence.

> > #define FB_VIDOVERLAY_PIXELTYPE_CI8     0x0020
> 
> What is this one?

ColorIndexed 8bpp. Could be used for still overlay
(i.e. a big Penguin as background picture :-)

> > #define FB_VIDOVERLAY_PIXELTYPE_YUV422  0x0040
> > #define FB_VIDOVERLAY_PIXELTYPE_YUV444  0x0080
> 
> packed pixel or planar?  yuv420 should be there too, mpeg decompressed
> gives you planar yuv420.

Packed Pixel was in my mind. I'll add the other.
(the pm3 doesn't have YUV420 :-( )

> I'd pass pixeltype + width + height here and let the driver calculate +
> return the image size and scanline length.  The driver can easily take
> care about alignment and related issues then.

The idea was the App could allow an arbitrary buffer and
do whatever it pleases in it, including somthing entirely
different from overlay. It might be useful if one
add a in-FB-memory copy IOCTL or API.

Also I though that the only overlay-related info
would be put in FBIOPUT_VIDOVERLAY_START, and
never stored in the driver (except for buffer
data), only in the app.

> n_over == -1  =>  "give me any free one" ?

good idea.

> >       __u16 blend_factor;             /* blending factor */
> 
> add chroma key (rage) here ?

The problem is, how to handle the mix between the overlay
and the console layer. If the FB doesn't have an alpha
channel (CI8, RGB565), one must use a color key. So one
must be able to know which color this is for FBCON.
If there _is_ an alpha channel and we wish to use it,
we must define how to handle the alpha in the fbcon
layer: if it is cleared or not when clearing the screen,
what happen when FBCON draw a character (cleared,
set, set only on the background...) ans so on.

So I simply dodged the problem by saying, we display
the overlay in its area blended (0 to 100%) with
the current display. But we need a better way,
obviously.

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

> /* get the hardware capability. get a 'struct fb_vidoverlay_avail' as output from the driver */ 
> #define FBIOGET_VIDOVERLAY_CAP        0x4620

Better use the _IOR / _IOW / _IOWR macros.

> /* pixel type that can be overlaid */
> #define FB_VIDOVERLAY_PIXELTYPE_CI8     0x0020

What is this one?

> #define FB_VIDOVERLAY_PIXELTYPE_YUV422  0x0040
> #define FB_VIDOVERLAY_PIXELTYPE_YUV444  0x0080

packed pixel or planar?  yuv420 should be there too, mpeg decompressed
gives you planar yuv420.

> struct fb_vidoverlay_mem {
> 	unsigned long omem_start;       /* Start of overlay frame buffer mem (phys add) */
>         __u32 omem_len;                 /* (required) length of overlay frame buffer mem */
> 	__u8  n_over;                   /* number of the overlay buffer to use */
> };

I'd pass pixeltype + width + height here and let the driver calculate +
return the image size and scanline length.  The driver can easily take
care about alignment and related issues then.

n_over == -1  =>  "give me any free one" ?

> struct fb_vidoverlay_set {
> 	__u32 oxsize;                   /* overlay size in pixels */
> 	__u32 oysize;
> 	__u16 pixel_type;               /* pixeltype to use */

obviously not needed if every allocated memory area has a width and height
as suggested above.

> 	__u16 blend_factor;             /* blending factor */

add chroma key (rage) here ?

  Gerd

-- 
Damn lot people confuse usability and eye-candy.

On Wed, 11 Jul 2001, Romain Dolbeau wrote:
> Geert Uytterhoeven wrote:
> > Not to mention separation of even/odd scanlines and luminance/chrominance on
> > some chipsets.

On some chipsets you have not one buffer containing all pixel data, but two
buffers: one for the even scanlines, and one for the odd scanlines.

It's also possible that the luminance and chrominance data are separated.
For YUV 4:2:2 (i.e. one Y value for each pixel, but only one U and one V for
each two pixels: YUYV), that means
  - one buffer for the Y data for the even scanlines
  - one buffer for the Y data for the odd scanlines
  - one buffer for the UV data for the even scanlines
  - one buffer for the UV data for the odd scanlines

I don't know whether this is done in any PC chipset, but it happens in chipsets
for set-top boxes.

> > Or better: a chroma key range ([YUV]{min,max}). Some hardware supports that.
> 
> Could you elaborate on those 2 ? I haven't seen that yet (not
> surprising,
> I'm for from an expert on the subject :-)

    pixel_is_transparent if (Ymin <= Y <= Ymax) && (Umin <= U <= Umax) &&
			    (Vmin <= V <= Vmax)

compare this to the single chroma key value:

    pixel_is_transparent if Y == Ykey && U == Ukey && V == Vkey

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

Geert Uytterhoeven wrote:

> Not to mention separation of even/odd scanlines and luminance/chrominance on
> some chipsets.
> 
> Or better: a chroma key range ([YUV]{min,max}). Some hardware supports that.

Could you elaborate on those 2 ? I haven't seen that yet (not
surprising,
I'm for from an expert on the subject :-)

TIA

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

Gerd Knorr wrote:

> When adding such ioctls to the kernel fbdev drivers I'd try to avoid
> limiting it to one overlay, which in turn means that just two ioctls are
> not enougth.  IMHO it should look like this:
> 
>   (1) A ioctl to allocate a piece of offscreen memory for overlay
>       (with size foo and format bar).
>   (2) A ioctl to ask the driver to start overlay at x,y,w,h.
>   (3) A ioctl to stop overlay
>   (4) A ioctl to free the memory.

I've reworked my current draft proposal for 2.4.x, appended below.
Heavily based on what's available in the Permedia3. Any add-on
(particulary data type) and comments welcome.

> BTW: What is ruby?

The reworked console layer for 2.5.x.

<http://sourceforge.net/projects/linuxconsole/>

-- 
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
On Wed, 11 Jul 2001, Gerd Knorr wrote:
> When adding such ioctls to the kernel fbdev drivers I'd try to avoid
> limiting it to one overlay, which in turn means that just two ioctls are
> not enougth.  IMHO it should look like this:
> 
>   (1) A ioctl to allocate a piece of offscreen memory for overlay
>       (with size foo and format bar).

Can be used for allocating a Z-buffer, too.

>   (2) A ioctl to ask the driver to start overlay at x,y,w,h.

And scaling hs, vs.

>   (3) A ioctl to stop overlay
>   (4) A ioctl to free the memory.
> 
> There also should be some way to figure out the supported formats.
> Either a fixed list of formats and ioctl (1) returning -EINVAL for
> unsupported ones or yet another ioctl to list the available ones.  It

You can have lots of formats:
  - YUV 4:4:4
  - YUV 4:2:2
  - YUV 4:2:0

Not to mention separation of even/odd scanlines and luminance/chrominance on
some chipsets.

> needs to be clear what happens on console switches.  Some way to set
> the chroma key color would be useful too (maybe in ioctl (2) ?).

Or better: a chroma key range ([YUV]{min,max}). Some hardware supports that.

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

> It's done. Hello Mr. Knorr :-)
> 
> The idea would be to add (video?) overlay support to the fbdev
> layer.  [ ... ]

> Would that be enough for fbtv (and similar app) ? would
> that be useful ?

fbtv does not need very much: just some piece of memory where it can ask
the bt848 to dma stuff to, and some way to enable the overlay for that.
You can have a look at the code, it already can do that on matrox cards
(by mmaping the mmio area and programming the hardware itself), see
matrox.c.

When adding such ioctls to the kernel fbdev drivers I'd try to avoid
limiting it to one overlay, which in turn means that just two ioctls are
not enougth.  IMHO it should look like this:

  (1) A ioctl to allocate a piece of offscreen memory for overlay
      (with size foo and format bar).
  (2) A ioctl to ask the driver to start overlay at x,y,w,h.
  (3) A ioctl to stop overlay
  (4) A ioctl to free the memory.

There also should be some way to figure out the supported formats.
Either a fixed list of formats and ioctl (1) returning -EINVAL for
unsupported ones or yet another ioctl to list the available ones.  It
needs to be clear what happens on console switches.  Some way to set
the chroma key color would be useful too (maybe in ioctl (2) ?).

> Could such an interface be added to ruby or should we wait
> after ruby is integrated in 2.5.x ?

BTW: What is ruby?

  Gerd

-- 
Damn lot people confuse usability and eye-candy.

On Tue, 10 Jul 2001, Sottek, Matthew J wrote:
> This is a patch for the i810e. I didn't even compile it
> so there might be an error. I'm taking a look making a
> light weight version that has no acceleration, but will
> work with XFree and I had already added the i810e part.

Why not using the PCI device ID defines in <linux/pci.h>?

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

Hi everyone!

Thanks for every bit of help getting my framebuffer on i810e going. Now, =
normally I use my system with two displays. The i810e is my primary vga =
display (on 17" monitor) and my secondary display is a Tseng Labs ET6000 =
(on a 14" monitor).

Normally I use X to use both displays which work well, but I also like to =
most of the time work at the command line. Especially when I do a lot of =
compiling (and don't want X to use my memory, we all know how gcc eats =
memory!)

Now, how can I setup the ET6000 to work alongside the i810e framebuffer. =
Firstly, is it possible? I know the ET6000 works with the VESA vga driver.
Can somebody point me to a document, or give advise on setting this up. Or =
do I need a specialised driver for the ET6000? If so, I would like to try =
to write one. But I need some help.

Thanks for all the support!
Herman

****************************************
Herman Theron
Hermanus Magnetic Observatory
CSIR
PO Box 32
Hermanus
7200
South Africa
E-mail: het...@cs...
Phone: +27 28 3121196
Fax: +27 28 3122039
Cel: +27 82 697 8546

"Sottek, Matthew J" wrote:
> BTW: Everyone who has contributed to this code needs to
> agree on a license and put one in the code. I expect
> either GPL or BSD, but there currently isn't one. I need
> to know which license this is under so that I can take
> the proper actions when working on this code.

It needs to be both or just GPL, if it is to be linked with the kernel.

-- 
Jeff Garzik      | A recent study has shown that too much soup
Building 1024    | can cause malaise in laboratory mice.
MandrakeSoft     |

> BTW: Everyone who has contributed to this code needs to
> agree on a license and put one in the code. I expect
> either GPL or BSD, but there currently isn't one. I need
> to know which license this is under so that I can take
> the proper actions when working on this code.

GPL please. Otherwise you can't link it directly into the kernel.

This is a patch for the i810e. I didn't even compile it
so there might be an error. I'm taking a look making a
light weight version that has no acceleration, but will
work with XFree and I had already added the i810e part.

BTW: Everyone who has contributed to this code needs to
agree on a license and put one in the code. I expect
either GPL or BSD, but there currently isn't one. I need
to know which license this is under so that I can take
the proper actions when working on this code.

 -Matt

You could have a problem with the device id.
Do
"cat /proc/pci"
and check the device id's
May be you will not have one of

#define     PCI_I810_DID_0                0x7120
#define     PCI_I810_DC100_DID_0    0x7122
#define     PCI_I815_DID_0                0x1130

Than add your ID to the driver code
and extend function the part of sI810_detect
.....
    /*  Find the pci_dev0 representing the I815 or I810 or I810-DC100 device 
*/
        if ((p810_dev0 = pci_find_device (PCI_I810_VID, PCI_I815_DID_0, 
NULL)) == NULL)
        {
        if ((p810_dev0 = pci_find_device (PCI_I810_VID, PCI_I810_DID_0, 
NULL)) == NULL)
        {
                if ((p810_dev0 = pci_find_device (PCI_I810_VID, 
PCI_I810_DC100_DID_0, NULL)) == NULL)
                {
                return 2;
                }
        }
        }
....
After you have successfully tested plese mail me the patch.

Thomas

Am Tuesday 10 July 2001 13:37, schrieb Herman Theron: / On Tuesday 10 July 
2001 13:37, Herman Theron wrote:
> Hi all
>
> Thanks for all the help I have received so far. I got the kernel to compile
> and can boot, but i810fb does not detect any i810 chipset.
>
> agpgart does detect it: (from dmesg)
>
> Linux agpgart interface v0.99 (c) Jeff Hartmann
> agpgart: Maximum main memory to use for agp memory: 93M
> agpgart: Detected an Intel i810 E Chipset.
> agpgart: detected 4MB dedicated video ram.
> agpgart: AGP aperture is 64M @ 0xf4000000
>
> Then the next message is from i810fb:
>
> Intel 810 Not detected - exiting 2
>
> Any ideas? If agpgart can pick it up, why doesn't i810fb recognise tihe
> i810 E?
>
> Thanks for the help
> Herman
>
>
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> http://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

James Simmons wrote:
> 
> Romain Dolbeau wrote:
> > 
> > Maybe we should involve the author of fbtv, he could tell us the kind of
> > stuff that would be needed for efficient hardware YUV->RGB and/or
> > zooming in fbtv. I guess other app would have similar requirements.
> 
> Good idea.

It's done. Hello Mr. Knorr :-)

The idea would be to add (video?) overlay support to the fbdev
layer. That could be used for adding a background picture
(full-size color penguin :-) or more seriously for video
app like `fbtv'. I believe the interface, being in the kernel,
should be kept simple even if not complete. The HW driver
could supply for instance the base address of the offscreen
memory area where data (RGB or YUV, depending on available
hardware) can be put and the capability (shrink/expand,
opaque or translucent/blended overlay...), and the app
could ask to overlay said memory area to a specific
offset in the FB area. Such a model would be simple
(2 ioctls) and be within reach of many chip with
vid-overlay capability (it would work on the Permedia3
I believe :-)

Would that be enough for fbtv (and similar app) ? would
that be useful ? (assuming HW YUV->RGB conversion is
available) No point in adding cruft that would
slow things down :-) Is there anything else that would
help `fbtv' ?

Could such an interface be added to ruby or should we wait
after ruby is integrated in 2.5.x ?

Any comments 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

Hi all

Thanks for all the help I have received so far. I got the kernel to =
compile and can boot, but i810fb does not detect any i810 chipset.

agpgart does detect it: (from dmesg)

Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 93M
agpgart: Detected an Intel i810 E Chipset.
agpgart: detected 4MB dedicated video ram.
agpgart: AGP aperture is 64M @ 0xf4000000

Then the next message is from i810fb:

Intel 810 Not detected - exiting 2

Any ideas? If agpgart can pick it up, why doesn't i810fb recognise tihe =
i810 E?

Thanks for the help
Herman

> Hmmm,
> 
> agpgart_be.c was copied to linux/drivers/char instead of linux/drivers/char/agp.
> 
> But now, i8018fb.c stops the compile with errors similar to the following:
> 
> warning: pasting "." and "vmode" does not give valid preprocessing token.
> 
> 
> gcc --version on my Mandrake 8.0 system gives 2.96
> 
> Any ideas?
> Herman
> 
	I got the same warnings as you did but it compiles after all ... 
	Put all the files in the kernel sources (Config.in,Makefile etc.)
	See if you compile with -Werror ... 

-- 
......:: Nicu Pavel - np...@ea... - http://panic.eu.org/ ::......
                  - iMedia Linux Senior Developer -
         --    My favorite music : tcpdump > /dev/dsp   --

> Hi Nico,
> 
> I could not reproduce the compiler error you described. I deleted ctfb.o and 
> deselected it in config. All compiled fine. I use a SuSE-patched kernel 
> version 2.4.4. 
> 
> Maybe "make dep" before building the kernel will help?
> 
> Did somebody else run in such a problem?
> 
> Thomas
> 

From what I remember I did a make dep ... I will test again ... 
I also tested the i810fb with fbtest and worked ok.
If is needed I can post the results from fbtest -v -d.

Also I couldn't change the resolution with fbset the screen remain blank
whatever resolution-refresh I choose.
Another problem is when changing the consoles some lines apear for a short
amount of time - 1 sec or less.

My kernel is a 2.4.6 - and the chipset is i815.

-- 
......:: Nicu Pavel - np...@ea... - http://panic.eu.org/ ::......
                  - iMedia Linux Senior Developer -
         --    My favorite music : tcpdump > /dev/dsp   --

Thanks Matthew for your statement!

First I have to correct a link I yesterday sent. This should work now:

http://www.visuelle-maschinen.de/ctfb/i810/i810fb_XFree_Issue

It contains answers to this problem given by Jeff Hartmann, Sottek, Matthew J 
and Anda MuniReddy.

The main issue from my point of view was mentioned by Anda MuniReddy:

"Agpgart doesn't have a interface so that any driver can ask for X amount of 
graphics memory. It assumes that only one client is using and he knows where 
he binded the memory."

From my point of view we need to solve that. All other thinks are just 
workarounds. 

I use XF86_FBDev on top of i810fb as a temporary solution.

By the way: i810fb seems to have a problem with 8 bpp. I guess it is caused 
by wrong values in the first 16 colors in cmap in that mode.

Thomas

Am Tuesday 10 July 2001 03:03, schrieb Sottek, Matthew J: / On Tuesday 10 
July 2001 03:03, Sottek, Matthew J wrote:
> I've read over some of the discussion of the i810/i815
> framebuffer discussion, and given the code a cursory look. I
> currently work for an embedded development group at Intel
> and I've been doing X work for quite a while on these
> chipsets, so I thought I would jump into the conversation.
>
> First, looking at the code it seems the main reason this
> fb driver hasn't received more support is due to the
> competition between X and the fb driver for the gart
> resources. Why don't we just make a version of this driver
> that makes use of stolen memory only (1MB) and does not use
> the ringbuffer. This would give us all modes under 1MB in
> size (10x7 at 8bit, 8x6 at 16bit) which is the way the
> chipset is supported in all non AGP environments. (OS2, Dos
> etc.) This would remove all competition between X and the
> fb driver for resources...makes everyone's life easier.
>
> The major need for a framebuffer driver that my customers have
> is for graphical booting, and very basic embedded output like
> near-static displays. Almost all embedded devices that need
> acceleration are doing so via X and only need the framebuffer
> during bootup.
>
> Other applications that wish to allocate a ringbuffer and
> a larger framebuffer could do so with a (not default) option
> such that the vast majority of users can have their boot
> penguin and X too.  I think we could even get blits working
> without the ringbuffer by programming the part directly, but
> that has limited use anyway.
>
>  I don't want to discourage use of the acceleration for the
> devices that may need it, but I don't really want to see
> lots of problems arise from people trying to use fbdev and
> X at the same time to no avail.
>
> please cc me on replies,
> -Matt
>
>
>
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> http://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Hi Nico,

I could not reproduce the compiler error you described. I deleted ctfb.o and 
deselected it in config. All compiled fine. I use a SuSE-patched kernel 
version 2.4.4. 

Maybe "make dep" before building the kernel will help?

Did somebody else run in such a problem?

Thomas

Am Monday 09 July 2001 14:21 schrieben Sie: / On Monday 09 July 2001 14:21, 
you wrote:
> Am Saturday 07 July 2001 06:09, schrieb pa...@ra...: / On Saturday 07
>
> July 2001 06:09, pa...@ra... wrote:
> > Hi,
> >
> > I downloaded the drivers from :
> >
> > http://www.visuelle-maschinen.de/ctfb/fb/drivers/i810.kernelmerges/
> >
> > I put everything on a 2.4.6 kernel, compiled in kernel.
> > Everything worked ok , I have a Intel 815 Desktop Board .I didn't have
> > time yet to test more so if a standart test procedure exist tell me so I
> > can send you the results (fbtest ?).
> >
> > The only problem that I see is that when I didn't select the ctfb drivers
> > in configure the compile failed telling that a union named ctfb cannot be
> > found.After selecting ctfb worked.I think there is a dependency between
> > i810fb and ctfb and I am not sure that this should be.
> >
> > Regards,
> >
> >  --
> > ......:: Nicu Pavel - np...@ea... - http://panic.eu.org/ ::......
> >                   - iMedia Linux Senior Developer -
> >          --    My favorite music : tcpdump > /dev/dsp   --

I've read over some of the discussion of the i810/i815
framebuffer discussion, and given the code a cursory look. I
currently work for an embedded development group at Intel
and I've been doing X work for quite a while on these
chipsets, so I thought I would jump into the conversation.

First, looking at the code it seems the main reason this
fb driver hasn't received more support is due to the
competition between X and the fb driver for the gart
resources. Why don't we just make a version of this driver
that makes use of stolen memory only (1MB) and does not use
the ringbuffer. This would give us all modes under 1MB in
size (10x7 at 8bit, 8x6 at 16bit) which is the way the
chipset is supported in all non AGP environments. (OS2, Dos
etc.) This would remove all competition between X and the
fb driver for resources...makes everyone's life easier.

The major need for a framebuffer driver that my customers have
is for graphical booting, and very basic embedded output like
near-static displays. Almost all embedded devices that need
acceleration are doing so via X and only need the framebuffer
during bootup.

Other applications that wish to allocate a ringbuffer and
a larger framebuffer could do so with a (not default) option
such that the vast majority of users can have their boot
penguin and X too.  I think we could even get blits working
without the ringbuffer by programming the part directly, but
that has limited use anyway.

 I don't want to discourage use of the acceleration for the
devices that may need it, but I don't really want to see
lots of problems arise from people trying to use fbdev and
X at the same time to no avail.

please cc me on replies,
-Matt

I insmod my fb and messages appear on the console but the login prompt
does not appear. I have to hit enter to get it to show up.

Can anyone explain this behavior?

-- 
Scott A. McConnell

2001	Jan	Feb	Mar (1)	Apr (104)	May (81)	Jun (248)	Jul (133)	Aug (33)	Sep (53)	Oct (82)	Nov (166)	Dec (71)
2002	Jan (121)	Feb (42)	Mar (39)	Apr (84)	May (87)	Jun (58)	Jul (97)	Aug (130)	Sep (32)	Oct (139)	Nov (108)	Dec (216)
2003	Jan (299)	Feb (136)	Mar (392)	Apr (141)	May (137)	Jun (107)	Jul (94)	Aug (262)	Sep (300)	Oct (216)	Nov (72)	Dec (94)
2004	Jan (174)	Feb (192)	Mar (215)	Apr (314)	May (319)	Jun (293)	Jul (205)	Aug (161)	Sep (192)	Oct (226)	Nov (308)	Dec (89)
2005	Jan (127)	Feb (269)	Mar (588)	Apr (106)	May (77)	Jun (77)	Jul (161)	Aug (239)	Sep (86)	Oct (112)	Nov (153)	Dec (145)
2006	Jan (87)	Feb (57)	Mar (129)	Apr (109)	May (102)	Jun (232)	Jul (97)	Aug (69)	Sep (67)	Oct (69)	Nov (214)	Dec (82)
2007	Jan (133)	Feb (307)	Mar (121)	Apr (171)	May (229)	Jun (156)	Jul (185)	Aug (160)	Sep (122)	Oct (130)	Nov (78)	Dec (27)
2008	Jan (105)	Feb (137)	Mar (146)	Apr (148)	May (239)	Jun (208)	Jul (157)	Aug (244)	Sep (119)	Oct (125)	Nov (189)	Dec (225)
2009	Jan (157)	Feb (139)	Mar (106)	Apr (130)	May (246)	Jun (189)	Jul (128)	Aug (127)	Sep (88)	Oct (86)	Nov (216)	Dec (9)
2010	Jan (5)	Feb	Mar (11)	Apr (31)	May (3)	Jun	Jul (7)	Aug	Sep (1)	Oct	Nov (1)	Dec
2012	Jan	Feb	Mar (3)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2013	Jan (1)	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

linux-fbdev-devel Mailing List for Linux Frame Buffer Device Development (Page 594)

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