i810fb-user Mailing List for i810 Framebuffer Device Driver

Hi Guys,

I was wondering if anyone could point me in the right direction?
I am currently trying to use the i810fb driver that came with the stock=

2.6.5 kernel.  I have compiled in all the options as specified in the
linux/Documentation/fb/intel810.txt file.  All of the FB relavant drive=
rs
are compiled into the kernel and are not modules.  I am using LILO and =
this
is what I am using as the options:

append=3D"root=3D/dev/hda2
video=3Di810fb:vram:2,xres:640,yres:480,bpp:8,hsync1:30,hsync2:55,vsync=
1:50,vsync2:85,accel,mtrr"

This actually works and we get a 640x480 fb console.  (The cursor does
appear to be porked, but that is not a real concern for me.)  When runn=
ing
fbset --info we get the following:


mode "640x480-85"
    # D: 35.651 MHz, H: 42.849 kHz, V: 84.850 Hz
    geometry 640 480 800 2621 8
    timings 28050 96 32 21 1 64 3
    accel true
    rgba 8/0,8/0,8/0,0/0
endmode

Frame buffer device information:
    Name        : I810
    Address     : 0x81000000
    Size        : 2097152
    Type        : PACKED PIXELS
    Visual      : PSEUDOCOLOR
    XPanStep    : 8
    YPanStep    : 1
    YWrapStep   : 0
    LineLength  : 800
    MMIO Address: 0xc0000000
    MMIO Size   : 524288
    Accelerator : Unknown (39)

This also appears to be fine.  Am I correct?

Now comes the tricky part.  If I change the above kernel options to be
800x600, when the system boots we get a blank screen as soon as the fb
driver kicks in.  This is also replicated by using the fbset -xres 800
-yres 600.  When we run fbset --info during this state we get the
following:


mode "800x600-58"
    # D: 35.651 MHz, H: 35.938 kHz, V: 57.501 Hz
    geometry 800 600 800 2621 8
    timings 28050 96 32 21 1 64 3
    accel true
    rgba 8/0,8/0,8/0,0/0
endmode

Frame buffer device information:
    Name        : I810
    Address     : 0x81000000
    Size        : 2097152
    Type        : PACKED PIXELS
    Visual      : PSEUDOCOLOR
    XPanStep    : 8
    YPanStep    : 1
    YWrapStep   : 0
    LineLength  : 800
    MMIO Address: 0xc0000000
    MMIO Size   : 524288
    Accelerator : Unknown (39)

Again, I can't see anything partuiclarly wrong with this, but I am
relativly new to the 810 and the frame buffer system.

If anyone has any ideas, Or suggestion on where I should go from here,
please let me know.

Regards,
Gra

*************************************
Atronic International GmbH
Am Seering 13-14
8141 Unterpremst=E4tten
Austria

Grahame Falvey
Black Ops.
Phone:  +43 3135 5588 0498
Mobile: +43 6991 2927 866
Fax:    +43 3135 5588 0190
Email:  gf...@at...
Web:    http://www.atronic.com
*************************************


This email may contain confidential / privileged information and is
intended solely for the person or entity to which it is addressed.  Any=

review, dissemination, retransmission, copying, or printing of this mes=
sage
by persons other than the intended recipient is strictly prohibited.  I=
f
you have received this transmission in error please contact the sender =
and
delete this message from your computer.  It is the addressee/recipient =
duty
to virus scan and otherwise test the information provided before loadin=
g
onto any computer system. Atronic does not warrant that the information=
 is
free of a virus or any other defect or error.


=

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

I had the same problem, and I managed to get the splashscreen working by
~ commenting out the section in fbcon-splash.c which produces the error
message.
But the splash has serious side-effects:
~ After launching an application which uses fb (fbxine for instance)
~   the framebuffer does no longer update the text. When switching to
~   silent splash (kernel cmdline splash=silent), nothing I type can be
~   seen on the terminal, the image remains static. Switching to other
~   terminals (ctrl-alt-fx) yields the same results.
When launching the kernel with splash disabled (splash=disabled), the
screen displays some random mess, except for the tux logo in the upper
right corner,

so i suggest you stay away from splash screens, although they do look cool..

br,
~ Manuel Lauss
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQE/WZmjQHN6BNT8ERYRAmh1AJwObyNJra5YUZkEwsyrf4H5GDSRoACdHNRM
mZnQoNuT5AusjKY1N9o4Rbw=
=/0cZ
-----END PGP SIGNATURE-----

On Fri, Sep 05, 2003 at 10:04:55AM +0200, Alexander Goller wrote:
> Looking for splash picture.... silenjpeg size 30406 bytes, found, but framebuffe
> r can't handle it!

fbcon_splash.c is mocking about FBCON_HAS_CFB16, which should be
defined, i don't know why it isn't when the i810-fbdev is in
800x600x16bpp as it obviously is. Maybe you can give me some hint
for an starting point why this isn't defined.

bye, alex
-- 
alexander goller		al...@vi...

Hi,

i've installed the 0.23 and 0.23-0.35 patch on a vanilla 2.4.20
kernel. The framebuffer works like a charm. Thanks for the great work.
Now i wanted to enable some splash screen, attached the splash image to
my initrd and did a reboot.

This is what dmesg says (only relevant lines, or at least what i mean is 
relevant). Are there any known reasons the splash image can't get displayed?

Kernel command line: BOOT_IMAGE=linux-2.4.20-i810 ro root=301 BOOT_FILE=/boot/linux-2.4.20 hdc=ide-scsi splash=silent video=i810fb:vram=4:xres=800:yres=600:bpp=16:hsync1=30:hsync2=55:vsync1=60:vsync2=60:accel:mtrr
bootsplash: silent mode.
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 94M
agpgart: agpgart: Detected an Intel i815 Chipset.
agpgart: AGP aperture is 64M @ 0xe0000000
Looking for splash picture.... silenjpeg size 30406 bytes, found, but framebuffe
r can't handle it!
Console: switching to colour frame buffer device 100x37
fb0: Intel(R) 815 (Internal Graphics with AGP) Framebuffer Device v0.0.35, Tony 
Daplas
     Video RAM      : 4096K
     Mode           : 800x600-16bpp@59Hz
     Acceleration   : disabled
     MTRR           : enabled
     External VGA   : disabled
     Hardware cursor: disabled
     Video Timings  : VESA GTF (US)
     Rotation Code  : not built
     Interface      : enabled
     Memory Tiling  : disabled

bye, alex
-- 
alexander goller		al...@vi...

Hi All,
  I am trying to add framebuffer device support to vanilla kernel 
linux-2.4.20 by applying "linux-2.4.20-i810fb-lite.diff.bz2" patch 
to the relevant kernel source.The patch is applied without any 
hunk error. But while I run "make bzImage" the following error 
occurs.

drivers/video/video.o: In function `i810fb_set_var':
drivers/video/video.o(.text+0x846f): undefined reference to 
`fbcon_cfb8'
make: *** [vmlinux] Error 1

How to rectify this ? I am working in the following 
environment.Red Hat Linux 8.0, kernel 2.4.18-14 and Intel 810E 
chipset with on board graphics controller.

But there is no problem in applying the 
"linux-2.4.19-i810fb-lite.diff.bz2" patch to "2.4.19" vanilla 
kernal source and compiles sucessfully. The problem is only with 
"linux-2.4.20-i810fb-lite.diff.bz2" only.

Expecting u'r reply at the earliest.
Thanks in advance.

With Regards,
S.Suriya Mohan.
___________________________________________________
Meet your old school or college friends from
1 Million + database...
Click here to reunite www.batchmates.com/rediff.asp

Hi All,
  I am trying to add framebuffer device support to vanilla 
kernel
linux-2.4.20 by applying "linux-2.4.20-i810fb-lite.diff.bz2" patch 
to
the relevant kernel source.The patch is applied without any hunk
error. But while I run "make bzImage" the following error 
occurs.

drivers/video/video.o: In function `i810fb_set_var':
drivers/video/video.o(.text+0x846f): undefined reference to
`fbcon_cfb8'
make: *** [vmlinux] Error 1

How to rectify this ? I am working in the following 
environment.Red
Hat Linux 8.0, kernel 2.4.18-14 and Intel 810E chipset with on 
board
graphics controller.

But there is no problem in applying the
"linux-2.4.19-i810fb-lite.diff.bz2" patch to "2.4.19" vanilla 
kernal
source and compiles sucessfully. The problem is only with
"linux-2.4.20-i810fb-lite.diff.bz2" only.

Expecting u'r reply at the earliest.
Thanks in advance.

With Regards,
S.Suriya Mohan.
___________________________________________________
Meet your old school or college friends from
1 Million + database...
Click here to reunite www.batchmates.com/rediff.asp

Hi Joseph,
  Thanks for the info. The Console corresponding to
the 2.6 kernel does switch to Framebuffer mode when
inserting the required things in the .config file as
suggested by you. However, we are facing another issue
in this matter.

 After the booting process is complete with the
comiled image and the login prompt comes in, just
after this we get the following error in the screen:

"[drm:i810-wait-ring] *Error* space:65520 wanted 65528
 [drm:i810-wait-ring] *Error* lockup
  warning:process 'update' used the obsolete bdflush
system call.
  Fix ypur initscripts?"

This above screen remains for some time after which
another screen with the following error comes up:

" I cannot start the X server(your graphical
interface). It is likely that it is not setup
correctly. Would ypu like to view the X server output
to diagnose the problem? "

 On the screen also two "Yes", "No" buttons come up,
but pressing either of the buttons does not yield any
result.

 Any idea about this behaviour of the system...

Thanks,
Monisha.


 












--- Joseph Fannin <jh...@ri...> wrote:
> On Thu, Jul 17, 2003 at 08:09:07AM -0700, Monisha
> Barooah wrote:
> > Hi All,
> > 
> >  We have been trying to get framebuffer support in
> the
> > kernel version 2.4.18-14 for the Intel 82815
> Graphics
> > Controller Chipset.
> >  
> <snip> 
> > Note that: We also tried downloading and compiling
> the
> > linux-2.6.0-test1(considering the fact that the
> i810
> > driver comes built in within it). Here also we
> faced
> > an issue in that the compiled image corresponding
> to
> > this kernel does not display anything in the
> console
> > though it seemed that the booting process was
> > proceeding with some hard disk activity going on.
> > 
> > Can anyone give some pointers and help regarding
> it.
> 
> For 2.6, you must ensure that CONFIG_INPUT,
> CONFIG_VT,
> CONFIG_VT_CONSOLE, and CONFIG_VGA_CONSOLE are all
> set to "y"
> (i.e. these features are built into the kernel image
> and not as
> modules).  To use a framebuffer as the console, you
> must also enable
> CONFIG_FRAMEBUFFER_CONSOLE, but this one can be a
> module.
> 
> The quickest way to set all these is probably to
> edit the file .config
> in the root of the kernel source tree.
> 
> --
> Joseph Fannin
> jh...@ri...
> 
> "Anyone who quotes me in their sig is an idiot." --
> Rusty Russell.
> 

> ATTACHMENT part 2 application/pgp-signature 



=====


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

On Thu, Jul 17, 2003 at 08:09:07AM -0700, Monisha Barooah wrote:
> Hi All,
>=20
>  We have been trying to get framebuffer support in the
> kernel version 2.4.18-14 for the Intel 82815 Graphics
> Controller Chipset.
> =20
<snip>=20
> Note that: We also tried downloading and compiling the
> linux-2.6.0-test1(considering the fact that the i810
> driver comes built in within it). Here also we faced
> an issue in that the compiled image corresponding to
> this kernel does not display anything in the console
> though it seemed that the booting process was
> proceeding with some hard disk activity going on.
>=20
> Can anyone give some pointers and help regarding it.

For 2.6, you must ensure that CONFIG_INPUT, CONFIG_VT,
CONFIG_VT_CONSOLE, and CONFIG_VGA_CONSOLE are all set to "y"
(i.e. these features are built into the kernel image and not as
modules).  To use a framebuffer as the console, you must also enable
CONFIG_FRAMEBUFFER_CONSOLE, but this one can be a module.

The quickest way to set all these is probably to edit the file .config
in the root of the kernel source tree.

--
Joseph Fannin
jh...@ri...

"Anyone who quotes me in their sig is an idiot." -- Rusty Russell.

On Thu, Jul 17, 2003 at 08:09:07AM -0700, Monisha Barooah wrote:
>"i810fb-2.4.18.o: The module you are trying to load
>(i810fb-2.4.18.o) is compiled with a gcc
>version 2 compiler, while the kernel you are running
>is compiled with
>a gcc version 3 compiler. This is known to not work."

Try compiling the driver with gcc version 3 by exporting CC to point to
the gcc3 binary (Example: "export CC=/usr/bin/gcc-3.3").

Bryan

Hi All,

 We have been trying to get framebuffer support in the
kernel version 2.4.18-14 for the Intel 82815 Graphics
Controller Chipset.
 
 As specified in the link
http://support.intel.com/support/graphics/intel810/30483.htm#POS1,the
82815 GCC card does not support the  vesafb module but
does require a native driver.

 We downloaded the file
linux-i810fb-mod-0.0.23.tar.bz2 from the sourceforge
site and tried inserting the module corresponding to
the 2.4.18 kernel by using "insmod". When doing so we
received the following error:

"i810fb-2.4.18.o: The module you are trying to load
(i810fb-2.4.18.o) is compiled with a gcc
version 2 compiler, while the kernel you are running
is compiled with
a gcc version 3 compiler. This is known to not work."

Can anyone suggest how to overcome this problem? Or
specify if there are i810fb drivers corresponding to
the linux version 2.4.18 which are compiled by gcc
version 3 compiler and can be inserted in the 2.4.18
kernel?

Note that: We also tried downloading and compiling the
linux-2.6.0-test1(considering the fact that the i810
driver comes built in within it). Here also we faced
an issue in that the compiled image corresponding to
this kernel does not display anything in the console
though it seemed that the booting process was
proceeding with some hard disk activity going on.

Can anyone give some pointers and help regarding it.

Thanks,
Monisha.



=====


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

Hi All,

 We have been trying to get framebuffer support in the
kernel version 2.4.18-14 for the Intel 82815 Graphics
Controller Chipset.
 
 As specified in the link
http://support.intel.com/support/graphics/intel810/30483.htm#POS1,the
82815 GCC card does not support the  vesafb module but
does require a native driver.

 We downloaded the file
linux-i810fb-mod-0.0.23.tar.bz2 from the sourceforge
site and tried inserting the module corresponding to
the 2.4.18 kernel by using "insmod". When doing so we
received the following error:

"i810fb-2.4.18.o: The module you are trying to load
(i810fb-2.4.18.o) is compiled with a gcc
version 2 compiler, while the kernel you are running
is compiled with
a gcc version 3 compiler. This is known to not work."

Can anyone suggest how to overcome this problem? Or
specify if there are i810fb drivers corresponding to
the linux version 2.4.18 which are compiled by gcc
version 3 compiler and can be inserted in the 2.4.18
kernel?

Note that: We also tried downloading and compiling the
linux-2.6.0-test1(considering the fact that the i810
driver comes built in within it). Here also we faced
an issue in that the compiled image corresponding to
this kernel does not display anything in the console
though it seemed that the booting process was
proceeding with some hard disk activity going on.

Can anyone give some pointers and help regarding it.

Thanks,
Monisha.



=====


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

On Thu, Dec 12, 2002 at 03:10:03AM +0500, Antonino Daplas wrote:
> On Wed, 2002-12-11 at 22:32, Joseph Fannin wrote:
> > On Tue, Dec 10, 2002 at 05:50:51AM +0500, Antonino Daplas wrote:
> > > On Tue, 2002-12-10 at 02:20, Joseph Fannin wrote:
> > > >     Hi,
> > > >=20
> > > >     The i810-lite framebuffer driver isn't working for me on my lap=
top with
> > > > 2.4.20.  I've tried versions 0.0.33, 0.0.34 and 0.0.31 (the version=
 I
> > > > was using with 2.4.19) on top of the patch for 2.4.20.
> > > >=20
> >=20
> >    This did not work -- I even enabled 4bpp support for good measure,
> >    and the resulting .config has stuff set right.
> >=20
> >    Setting bpp=3D16 on the command line makes things work though.  So I
> >    guess it's an 8 bit issue (I haven't tried 24 or 32).
> >=20
> >    The Config.in looks fine to me.  *shrug*.  It's working, I'm happy.=
=20
> >=20
> I'm not happy, it should work :-(.  Support for bpp8 is there, I know
> it, because we are using the same patch.  Once in a while, all those
> dependencies just get whacked, and another recompile, with a make clean,
> make dep might fix those dependencies (fbcon-cfb8 must get compiled and
> linked).  I'll check it on a test kernel and let you know.

    You were right -- a make clean and a rebuild of the same kernel
and .config gives me working 8bpp.  That's great.

    I'll be using 16 bit from now on anyway though now that I've
discovered links2's graphical support for the framebuffer. =20

    I also have i810fb-dev working on a 2.5 kernel with a few
caveats.  I'm going to upgrade my 2.5 kernel today, and I'll send on
anything I've found (unless it's all fixed now) later this afternoon.

    Thank you for all the work you've done on this.

--=20
Joseph Fannin
jh...@ri...

Rothchild's Rule -- "For every phenomenon, however complex, someone will
eventually come up with a simple and elegant theory. This theory will
be wrong."

On Wed, 2002-12-11 at 22:32, Joseph Fannin wrote:
> On Tue, Dec 10, 2002 at 05:50:51AM +0500, Antonino Daplas wrote:
> > On Tue, 2002-12-10 at 02:20, Joseph Fannin wrote:
> > >     Hi,
> > > 
> > >     The i810-lite framebuffer driver isn't working for me on my laptop with
> > > 2.4.20.  I've tried versions 0.0.33, 0.0.34 and 0.0.31 (the version I
> > > was using with 2.4.19) on top of the patch for 2.4.20.
> > > 
> 
>    This did not work -- I even enabled 4bpp support for good measure,
>    and the resulting .config has stuff set right.
> 
>    Setting bpp=16 on the command line makes things work though.  So I
>    guess it's an 8 bit issue (I haven't tried 24 or 32).
> 
>    The Config.in looks fine to me.  *shrug*.  It's working, I'm happy. 
> 
I'm not happy, it should work :-(.  Support for bpp8 is there, I know
it, because we are using the same patch.  Once in a while, all those
dependencies just get whacked, and another recompile, with a make clean,
make dep might fix those dependencies (fbcon-cfb8 must get compiled and
linked).  I'll check it on a test kernel and let you know.

Tony

On Tue, Dec 10, 2002 at 05:50:51AM +0500, Antonino Daplas wrote:
> On Tue, 2002-12-10 at 02:20, Joseph Fannin wrote:
> >     Hi,
> >=20
> >     The i810-lite framebuffer driver isn't working for me on my laptop =
with
> > 2.4.20.  I've tried versions 0.0.33, 0.0.34 and 0.0.31 (the version I
> > was using with 2.4.19) on top of the patch for 2.4.20.
> >=20
> >     My laptop has an i815 chipset with the fb driver compiled into
> > the kernel statically, and I boot with the options:
> >=20
> > video=3Di810fb:vram=3D2:xres=3D1024:yres=3D768:bpp=3D4:accel:hsync1=3D3=
0:hsync2=3D54:vsync1=3D50:vsync2=3D60:hwcur:voffset=3D32
> >=20
>=20
> Hmm. There must be something wrong with the Config.in file in the
> patch.  Anyway, enable 8, 16, 24 and 32 bpp packed pixels support in
> "Advanced Low Level Driver Options" under "Support For Framebuffer
> Device" option when you configure the kernel..

   This did not work -- I even enabled 4bpp support for good measure,
   and the resulting .config has stuff set right.

   Setting bpp=3D16 on the command line makes things work though.  So I
   guess it's an 8 bit issue (I haven't tried 24 or 32).

   The Config.in looks fine to me.  *shrug*.  It's working, I'm happy.=20

--=20
Joseph Fannin
jh...@ri...

"Anyone who quotes me in their sig is an idiot." -- Rusty Russell.

On Tue, 2002-12-10 at 02:20, Joseph Fannin wrote:
>     Hi,
> 
>     The i810-lite framebuffer driver isn't working for me on my laptop with
> 2.4.20.  I've tried versions 0.0.33, 0.0.34 and 0.0.31 (the version I
> was using with 2.4.19) on top of the patch for 2.4.20.
> 
>     My laptop has an i815 chipset with the fb driver compiled into
> the kernel statically, and I boot with the options:
> 
> video=i810fb:vram=2:xres=1024:yres=768:bpp=4:accel:hsync1=30:hsync2=54:vsync1=50:vsync2=60:hwcur:voffset=32
> 

Hmm. There must be something wrong with the Config.in file in the
patch.  Anyway, enable 8, 16, 24 and 32 bpp packed pixels support in
"Advanced Low Level Driver Options" under "Support For Framebuffer
Device" option when you configure the kernel..

Tony

On Mon, 2002-09-09 at 01:23, no...@so... wrote: 
> 
> Read and respond to this message at: 
> http://sourceforge.net/forum/message.php?msg_id=1673500
> By: zacrel
> 
> Hello,
>   first i'm sorry cause i'm beginner in this field, and my questions could be
> wrong in some way.
> I can't install bootsplash for Mandrake 8.2 for my i815 vga.
> I think the problem is than /proc/splash don't exists. But that file is created
> by kernel when it recognise in lilo vga=788, for example.
> I tried it but, cause fb initialize later, happen a vga vesa error : only text
> lines resolution are possible.
True, the i810/i815 chipset does not support a linear framebuffer, thus
all VESA graphics mode are not supported.  The option 'vga=788' is
directed specifically for the VESA framebuffer. 

> My kernel is compiled only with i810 patch and splash ability enabled. (vesa
> and vga16 obviously disabled). Lilo have the line "append= " as describe in
> i810fb doc.
> At the startup framebuffer load in correctly resolution after a while. But only
> showing text instead of graphics image packed in initrd- ....
> Is there a way to give "vga=???", so kernel can create /proc/splash file.
> "vga=???" in "append= " line don't work.
If I'm to guess,  I believe the '/proc/splash' file is just a means of
telling a user-level program that vesafb is enabled, and it may be a
means of controlling the display of the splash.  

I guess the first thing you may want to do is mimic vga=788 (that would
be 800x600-16bpp) by booting with the following append options: 

append="video=i810fb:xres=800:yres=600:vyres=600:bpp=16" 

Then you can try to search your init scripts for the actual command on
how the 'splash image' is actually displayed.  You can try running this
manually. 

If the above works, then search your init scripts again on how to bypass
/proc/splash. 

Of course, I'm probably way off base, so I will need more information on
how this works.  Please direct me to a link. 

> Or is there another way to setup a graphics image in framebuffer during
> startup?
The most direct way is to treat /dev/fb0 as a regular file and do a copy
of an image file to it.  This is demonstrated by doing a 

cat /dev/urandom > /dev/fb0 

However, the image file must be in raw framebuffer format.  There should
be utilities on how to convert/display an image file to the
framebuffer.  I guess  http://linux-fbdev.sourceforge.net is a good page
to start searching. 

The other/faster/preferred way is memory mapping the framebuffer
itself.  This is how most fb-based applications work. 

Also, you can change how the standard penguin logo is displayed, and
change it with one of your own.  Try this site (I haven't visited this
yet): 

http://www.linux-mons.be/projets/framebuffer_logos/

Tony 
                            

On Wed, 2002-06-05 at 01:56, Bryan Stillwell wrote:
> On Sat, Jun 01, 2002 at 08:39:32PM +0800, Antonino Daplas wrote:
> >The main problem is that the XFree86 i810 driver does not invalidate
> >its accel functions when it is out of context.  Empirically, we can see
> >that X is still using accel even when switched to the console.  It's
> >just not correct behavior.
> 
> Ok, that makes sense to me.
> 
> 
> >If you're up to recompiling X, here's a patch that will do just that,
> >invalidate and revalidate the i810 accel engine when switching to and
> >from the console.  The patch is for vanilla XFree86-4.2.0.  If you have
> >a different version, let me know, and I'll send you an appropriate
> >diff.  Tell me also if you used one of my XFree86 patches.
> 
> I'm in the process of my second compile.  The first failed since there
> was a missing a semicolon at the end of one of the lines in the patch.
Oops, sorry about that :)

> I'll mail the list later today on whether or not it succeeded or failed.
> If it does work, would it be alright if I asked the Debian X package
> maintainer (Branden Robinson) to apply it to his Woody packages?  Or
> would one of your other XFree86 patches be better to use?
That patch is fine since the other patches do not fix the problem.  If
Branden (or anyone) is willing to accept the changes, go ahead.

Tony

On Wed, 2002-06-05 at 04:31, Bryan Stillwell wrote:
> I just wanted to mention that I was successful in rebuilding XFree86
> with the updated patch.  My initial stress testing isn't able to crash
> the X server, so it looks to be working great.  Thanks Antonino!
> 
That's great.

> I also wanted to ask if you have plans on incorporating your framebuffer
> driver into the main kernel source code anytime soon?
> 
Yes I am.  I already have a working 2.5 FB driver and I already informed
James Simmons about it.  However, he's still busy rewriting the 2.5 API.

Also, I'm in the process of merging codebases with another developer. 
If the merge takes too long, I'll make my own and start pestering James
soon.

Tony

On Sat, Jun 01, 2002 at 08:39:32PM +0800, Antonino Daplas wrote:
>The main problem is that the XFree86 i810 driver does not invalidate
>its accel functions when it is out of context.  Empirically, we can see
>that X is still using accel even when switched to the console.  It's
>just not correct behavior.

I just wanted to mention that I was successful in rebuilding XFree86
with the updated patch.  My initial stress testing isn't able to crash
the X server, so it looks to be working great.  Thanks Antonino!

I also wanted to ask if you have plans on incorporating your framebuffer
driver into the main kernel source code anytime soon?

Bryan

On Sat, Jun 01, 2002 at 08:39:32PM +0800, Antonino Daplas wrote:
>The main problem is that the XFree86 i810 driver does not invalidate
>its accel functions when it is out of context.  Empirically, we can see
>that X is still using accel even when switched to the console.  It's
>just not correct behavior.

Ok, that makes sense to me.


>If you're up to recompiling X, here's a patch that will do just that,
>invalidate and revalidate the i810 accel engine when switching to and
>from the console.  The patch is for vanilla XFree86-4.2.0.  If you have
>a different version, let me know, and I'll send you an appropriate
>diff.  Tell me also if you used one of my XFree86 patches.

I'm in the process of my second compile.  The first failed since there
was a missing a semicolon at the end of one of the lines in the patch.
I'll mail the list later today on whether or not it succeeded or failed.
If it does work, would it be alright if I asked the Debian X package
maintainer (Branden Robinson) to apply it to his Woody packages?  Or
would one of your other XFree86 patches be better to use?

Thanks,
Bryan

On Sat, 2002-06-01 at 04:30, Bryan Stillwell wrote:
> On Tue, May 21, 2002 at 08:14:42AM +0800, Antonino Daplas wrote:
> >I think you can minimize this problem by letting X finish drawing
> >before switching to the console, (ie, if you have mozilla, let it
> >finish first.  Not all apps do that though, I know for sure mozilla and
> >evolution.  Probably openoffice too). Disabling DRI will also help a
> >lot, since it's not really a very nice player.
> 
> Would using the 'option UseFBDev' in my XF86Config-4 file help fix this
> problem?  Recently on linux-fbdev-devel Geert mentioned that this will
> fix some problems using the aty128fb driver...  (See that message below)
> 

Looking at your previous mail, I see that you're using 4.1.0.1.  I
tested the patch against 4.1, and it applied cleanly, albeit with some
fuzziness.  

Tony

On Sat, 2002-06-01 at 04:30, Bryan Stillwell wrote:
> On Tue, May 21, 2002 at 08:14:42AM +0800, Antonino Daplas wrote:
> >I think you can minimize this problem by letting X finish drawing
> >before switching to the console, (ie, if you have mozilla, let it
> >finish first.  Not all apps do that though, I know for sure mozilla and
> >evolution.  Probably openoffice too). Disabling DRI will also help a
> >lot, since it's not really a very nice player.
> 
> Would using the 'option UseFBDev' in my XF86Config-4 file help fix this
> problem?  Recently on linux-fbdev-devel Geert mentioned that this will
> fix some problems using the aty128fb driver...  (See that message below)
> 
> Thanks,
> Bryan
> 

Not really.  The 'Option UseFBDev' gives the FB driver a chance to
restore it's own register state which has been theoretically destroyed,
or incomplete restored by X.  Otherwise, some FB drivers may be left
with a corrupt display.  It's not necessary of the i810fb driver because
it always restores its register state.

The main problem is that the XFree86 i810 driver does not invalidate its
accel functions when it is out of context.  Empirically, we can see that
X is still using accel even when switched to the console.  It's just not
correct behavior.

If you're up to recompiling X, here's a patch that will do just that,
invalidate and revalidate the i810 accel engine when switching to and
from the console.  The patch is for vanilla XFree86-4.2.0.  If you have
a different version, let me know, and I'll send you an appropriate
diff.  Tell me also if you used one of my XFree86 patches.

Tony 

On Tue, May 21, 2002 at 08:14:42AM +0800, Antonino Daplas wrote:
>I think you can minimize this problem by letting X finish drawing
>before switching to the console, (ie, if you have mozilla, let it
>finish first.  Not all apps do that though, I know for sure mozilla and
>evolution.  Probably openoffice too). Disabling DRI will also help a
>lot, since it's not really a very nice player.

Would using the 'option UseFBDev' in my XF86Config-4 file help fix this
problem?  Recently on linux-fbdev-devel Geert mentioned that this will
fix some problems using the aty128fb driver...  (See that message below)

Thanks,
Bryan

---
 From: Geert Uytterhoeven <ge...@li...> 
 Date: Fri, 31 May 2002 22:10:53 +0200 (MEST)
 To: Chris Howells <ch...@gm...>
 Cc: Linux Frame Buffer Device Development <lin...@li...>
 Subject: Re: [Linux-fbdev-devel] Possible bug: nasty interaction between framebuffer and DRI/DRM

 On Fri, 31 May 2002, Chris Howells wrote:
 > On Friday 31 May 2002 1:08 pm, Geert Uytterhoeven wrote:
 > 
 > > Do you use `option UseFBDev' in your XF86Config?
 > 
 > No I'm not. Should I be?

 Yes. Without that option, the X server will change the graphics chip's
 registers behind the back of aty128fb.

 Gr{oetje,eeting}s,

                                                 Geert
---

On Tue, 2002-05-21 at 04:20, Bryan Stillwell wrote:
> Lately I've been having problems with by X server dying using the
> i810fb-lite driver (v0.23) and XFree86 (v4.1.0.1), and I'm curious if
> anyone else has experienced this problem and is it fixed in the latest
> version?  It seems to only happen after switching back and forth from a
> FB-based application and a X application a number of times.  The last
> few lines of XFree86.0.log on a couple of the crashes give some more
> information:
> 
That problem is a known one. It's not really an fb problem, more of X's.
It's worse before since it also crahed i810fb.  Now, X will just crash
but i810fb will survive.  It's usually some X application that stresses
the graphics device (try loading mozilla, and before it finishes
loading, switch to the console, then wait -- sooner or later X will
crash).

The reason, I think, this happens is because X assumes that it is the
sole owner of the graphics device.  So when you switch to the console,
fb has taken over the graphics device, but X is probably still
processing some graphics request although it is already out of context.
The correct behavior would be for X to finish all requests before
switching, or do the processing in background without touching the
hardware.

I think you can minimize this problem by letting X finish drawing before
switching to the console, (ie, if you have mozilla, let it finish first.
Not all apps do that though, I know for sure mozilla and evolution. 
Probably openoffice too). Disabling DRI will also help a lot, since it's
not really a very nice player.

Tony 


> 
> I imagine this could also be related to the modified kernel that I'm
> running (2.4.19-pre5 with the preemptable kernel patch and the
> low-latency kernel patch applied.)  I just wanted to see if anyone else
> has had this problem before I dig into the problem anymore.
> 
Probably not.  That problem is known to me, and I probably gave some
hints about it in one of the docs I've made.

> Thanks,
> Bryan
> 
> -- 
>   http://www.bokeoa.com/    | br...@bo...
>   GPG fingerprint: 33F7 44F2 8612 E02F 8DE8  97FB 621E 8A36 6DC1 32AF
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> I810fb-user mailing list
> I81...@li...
> https://lists.sourceforge.net/lists/listinfo/i810fb-user

Lately I've been having problems with by X server dying using the
i810fb-lite driver (v0.23) and XFree86 (v4.1.0.1), and I'm curious if
anyone else has experienced this problem and is it fixed in the latest
version?  It seems to only happen after switching back and forth from a
FB-based application and a X application a number of times.  The last
few lines of XFree86.0.log on a couple of the crashes give some more
information:

Crash #1:
---
pgetbl_ctl: 0x13f0001 pgetbl_err: 0xb
ipeir: 1 iphdr: 0
LP ring tail: 8 head: 0 len: 0 start 0
eir: 0 esr: 10 emr: 3d
instdone: ff7b instpm: 0
memmode: 4 instps: 0
hwstam: 0 ier: 3 imr: 0 iir: 0
space: 65520 wanted 65528
(II) I810(0): [drm] removed 1 reserved context for kernel
(II) I810(0): [drm] unmapping 4096 bytes of SAREA 0xd4a41000 at
0x40014000

Fatal server error:
lockup
---

Crash #2:
---
pgetbl_ctl: 0x13f0001 pgetbl_err: 0x4db000b
ipeir: 1 iphdr: 50800006
LP ring tail: 8 head: 0 len: 0 start 0
eir: 0 esr: 10 emr: 3d
instdone: ff7b instpm: 0
memmode: 4 instps: 0
hwstam: 0 ier: 3 imr: 0 iir: 0
space: 65520 wanted 65528
(II) I810(0): [drm] removed 1 reserved context for kernel
(II) I810(0): [drm] unmapping 4096 bytes of SAREA 0xd4a41000 at
0x40014000

Fatal server error:
lockup
---


I imagine this could also be related to the modified kernel that I'm
running (2.4.19-pre5 with the preemptable kernel patch and the
low-latency kernel patch applied.)  I just wanted to see if anyone else
has had this problem before I dig into the problem anymore.

Thanks,
Bryan

-- 
  http://www.bokeoa.com/    | br...@bo...
  GPG fingerprint: 33F7 44F2 8612 E02F 8DE8  97FB 621E 8A36 6DC1 32AF