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

[Linux-fbdev-devel] Mirrored characters

[<sti...@gm...>]

Hello,

i have some problems with a framebuffer. I´m using a PXA Processor and 
using a moncrom display.

If I want to write something the charakters are mirrored and isn´t 
displayed correctly, only parts. My display runs at bpp=4. If I swap the 
  definitions at the beginning of fbcon-cfb4.c for the ENDIANS the 
characters are display correctly, but the contrast between the backgrund 
and the charakters are not good. What can I do?

Andre

[Linux-fbdev-devel] Re: console_struct.h:97: `MAX_NR_CONSOLES' undeclared here

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

> I applied the patch from tonight to 2.5.50 and got this build error:
> http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
> <http://phoenix.infradead.org/%7Ejsimmons/fbdev.diff.gz>

Okay. I found the problem. tty.h was missing in this file. I will post
another patch soon.

Re: [Linux-fbdev-devel] [PATCH] FBDev: vga16fb port

[Antonino D. <ad...@po...>]

On Wed, 2002-12-04 at 15:28, Sven Luther wrote:
> > 
> > Most cards with a VGA core needs to disable the VGA output before going
> > to graphics mode.  Disabling VGA output is hardware specific, and is
> > usually automatic when you go to graphics mode.
> 
> So there is no common zqy of doing this, my docs say something about a
> vga control register zhich is accesses trough the sequencer regs. Does
> vgafb (or textmode or whatever) not call this when giving the hand to
> the fbdev ?
No, when a video card goes to graphics mode, it's up to the driver to
program the registers.  vgacon/vga16fb only touches the standard VGA
registers (crtc[25], attr[21], seq[5], gfx[9], misc[1]). Usage is pretty
much uniform across all hardware. Any registers past those indices are
considered extended registers and usage is hardware specific.  In
graphics mode, you will probably use both the standard and the extended
registers, and disabling the VGA mode/enabling graphics mode is most
probably in one of the extended registers.
> 
> > Because James wrote the fb framework to be very modular, then you must
> > be careful to save/restore the initial video state  when loading or
> > unloading.  Theoretically, a driver should load, but not go to graphics
> > mode immediately.  Only upon a call to xxxfb_set_par() should the driver
> > do so.  Before going to graphics mode, that's were you save the initial
> > state.  Have a reference count or something to keep track of the number
> > of users, and when this reference count becomes zero, restore the
> > initial state.  You should be able to do this by hooking these routines
> > in fb_open() and fb_release().
> 
> Mmm, what about interaction with X ? X also does a save/restore of the
> previous (text) mode, when a X driver is _not_ fbdev aware, it will
> save/restore the things twice, right ?
> 
Not twice just the current mode it was in when X launched, although it
always assumes text mode.  Same thing for fbdev, it should only restore
the state when reference count becomes zero. If the framebuffer console
is loaded, the reference count will never be zero unless it is
unloaded.  If the framebuffer console is not loaded, the only time you
will save and restore the state is when some fb-based application
attempts to open/close /dev/fbx.

> > The one I submitted (and a revised one I'm going to submit soon) should
> > be able to restore the VGA text/graphics mode.  Complement this with
> > your hardware's extended state save and restore routines and you should
> > be able to load/use/unload your driver repeatedly :-).
> 
> Ok, i will try.

This is optional though.  You can still adopt the 2.4 method of always
setting the video mode.  Just take note that fbdev can be loaded without
fbcon, and if you get into graphics mode without fbcon, you just messed
up your user's console.  I think this can be avoided by munging the
configuration file (ie, always depend on fbcon and make your module
unsafe to unload).

Tony

[Linux-fbdev-devel] [PATCH 2/3] FBDEV: vga16fb + save/restore state

[Antonino D. <ad...@po...>]

Hi,

Attached is a patch against linux-2.5.50 + James Simmons' fbdev.diff.

Added support to save and restore VGA text mode.

Tony

[Linux-fbdev-devel] [PATCH 1/3: FBDEV: VGA State Save/Restore module

[Antonino D. <ad...@po...>]

Hi,

Attached is a patch against linux-2.5.50 + James Simmons fbdev.diff to
save and restore the VGA state. This includes character maps (plane
0-3), the colormap, and the video mode.  This can be used in fb_open()
and fb_release() to go back to VGA text/graphics mode.

Usage:

struct fb_vgastate state;

/* To save VGA state */
state.flags = VGA_SAVE_MODE | VGA_SAVE_CMAP | VGA_SAVE_FONTS;
fb_save_vga(&state);

/* To restore VGA state */
fb_restore_vga(&state);

Limitations:
1.  Restoring the VGA state from high-resolution graphics mode may
result in a corrupt display which can be corrected by switching
consoles.  May need a screen redraw at this point.  Restoring from VGA
graphics mode to text mode and vice versa is okay.

2. Assumes some things about the hardware which is not universally
correct:  VGA memory base is at 0xA0000, memory size is 64KB, the
hardware palette is readable, etc. 

Any comments welcome.

Tony

PS:  Please reverse the early patch I submitted if it was applied --
vgastate.diff

[Linux-fbdev-devel] [PATCH 3/3] FBDEV: rivafb + save/restore state

[Antonino D. <ad...@po...>]

Hi,

Attached is a patch against linux-2.5.50 + James Simmons fbdev.diff.

Added support to save and restore vgacon's text mode.  Can also restore
VGA graphics mode.

Tony

Re: [OT] Re: [Linux-fbdev-devel] [PATCH] FBDev: vga16fb port

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

On Wed, 4 Dec 2002, Petr Vandrovec wrote:
> FYI, I'm going to unsubscribe myself from linux-fbdev-devel.
> I'm not interested in reading messages on list which is not public:
> I get again an error that my message is waiting for moderator approval,
> and as such list is unsuitable for any realtime discussion.

Yes, I know it's annoying :-(

But, AFAIK we don't know yet
  1. who changed the list to a moderated list
  2. who is actually moderating it

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] [PATCH] FBDev: vga16fb port

[Petr V. <VAN...@vc...>]

On  4 Dec 02 at 17:08, Antonino Daplas wrote:
> On Wed, 2002-12-04 at 12:32, Sven Luther wrote:
> > On Tue, Dec 03, 2002 at 05:22:35PM +0500, Antonino Daplas wrote:
> > > >   2) The ability to go back to vga text mode on close of /dev/fb. 
> > > >      Yes fbdev/fbcon supports that now. 
> > > 
> > > I'll take a stab at writing VGA save/restore routines which hopefully is
> > > generic enough to be used by various hardware.  No promises though, VGA
> > > programming gives me a headache :(
> > 
> > BTW, i am writing a fbdev for a card where the docs tell me to disable
> > vga output before enabling graphical output. Does i need to do this in
> > the fbdev i write, or is it already handled by the vga layer, or
> > whatever ?
> 
> Most cards with a VGA core needs to disable the VGA output before going
> to graphics mode.  Disabling VGA output is hardware specific, and is
> usually automatic when you go to graphics mode.
> 
> Because James wrote the fb framework to be very modular, then you must
> be careful to save/restore the initial video state  when loading or
> unloading.  Theoretically, a driver should load, but not go to graphics
> mode immediately.  Only upon a call to xxxfb_set_par() should the driver
> do so.  Before going to graphics mode, that's were you save the initial
> state.  Have a reference count or something to keep track of the number
> of users, and when this reference count becomes zero, restore the
> initial state.  You should be able to do this by hooking these routines
> in fb_open() and fb_release().

FYI, I'm not going to support any hardware restoration on last fb_release,
nor hardware init only after first fb_open in matroxfb. Either you want
this driver, or not. Besides that I do not see any reason to have such 
code, matroxfb provides multiple framebuffers, and to get them
all work, hardware must be in known state, it is impossible to program
only half of chip and expect that it will somehow work. It will crash,
lock your PCI bus, or even commits suicide.

And I'm sure that other possible solution, that opening /dev/fb1 
(or /dev/videoX or /dev/dri/mga) will cause your vgacon picture to 
disappear, violates principle of least surprise.
                                            Best regards,
                                                Petr Vandrovec
                                                van...@vc...
                                                

Re: [Linux-fbdev-devel] [PATCH] FBDev: vga16fb port

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

On Wed, Dec 04, 2002 at 05:08:53PM +0500, Antonino Daplas wrote:
> On Wed, 2002-12-04 at 12:32, Sven Luther wrote:
> > On Tue, Dec 03, 2002 at 05:22:35PM +0500, Antonino Daplas wrote:
> > > >   2) The ability to go back to vga text mode on close of /dev/fb. 
> > > >      Yes fbdev/fbcon supports that now. 
> > > 
> > > I'll take a stab at writing VGA save/restore routines which hopefully is
> > > generic enough to be used by various hardware.  No promises though, VGA
> > > programming gives me a headache :(
> > 
> > BTW, i am writing a fbdev for a card where the docs tell me to disable
> > vga output before enabling graphical output. Does i need to do this in
> > the fbdev i write, or is it already handled by the vga layer, or
> > whatever ?
> 
> Most cards with a VGA core needs to disable the VGA output before going
> to graphics mode.  Disabling VGA output is hardware specific, and is
> usually automatic when you go to graphics mode.

So there is no common zqy of doing this, my docs say something about a
vga control register zhich is accesses trough the sequencer regs. Does
vgafb (or textmode or whatever) not call this when giving the hand to
the fbdev ?

> Because James wrote the fb framework to be very modular, then you must
> be careful to save/restore the initial video state  when loading or
> unloading.  Theoretically, a driver should load, but not go to graphics
> mode immediately.  Only upon a call to xxxfb_set_par() should the driver
> do so.  Before going to graphics mode, that's were you save the initial
> state.  Have a reference count or something to keep track of the number
> of users, and when this reference count becomes zero, restore the
> initial state.  You should be able to do this by hooking these routines
> in fb_open() and fb_release().

Mmm, what about interaction with X ? X also does a save/restore of the
previous (text) mode, when a X driver is _not_ fbdev aware, it will
save/restore the things twice, right ?

> The one I submitted (and a revised one I'm going to submit soon) should
> be able to restore the VGA text/graphics mode.  Complement this with
> your hardware's extended state save and restore routines and you should
> be able to load/use/unload your driver repeatedly :-).

Ok, i will try.

Friendlmy

Sven Luther

Re: [Linux-fbdev-devel] [PATCH] FBDev: vga16fb port

[Antonino D. <ad...@po...>]

On Wed, 2002-12-04 at 12:32, Sven Luther wrote:
> On Tue, Dec 03, 2002 at 05:22:35PM +0500, Antonino Daplas wrote:
> > >   2) The ability to go back to vga text mode on close of /dev/fb. 
> > >      Yes fbdev/fbcon supports that now. 
> > 
> > I'll take a stab at writing VGA save/restore routines which hopefully is
> > generic enough to be used by various hardware.  No promises though, VGA
> > programming gives me a headache :(
> 
> BTW, i am writing a fbdev for a card where the docs tell me to disable
> vga output before enabling graphical output. Does i need to do this in
> the fbdev i write, or is it already handled by the vga layer, or
> whatever ?

Most cards with a VGA core needs to disable the VGA output before going
to graphics mode.  Disabling VGA output is hardware specific, and is
usually automatic when you go to graphics mode.

Because James wrote the fb framework to be very modular, then you must
be careful to save/restore the initial video state  when loading or
unloading.  Theoretically, a driver should load, but not go to graphics
mode immediately.  Only upon a call to xxxfb_set_par() should the driver
do so.  Before going to graphics mode, that's were you save the initial
state.  Have a reference count or something to keep track of the number
of users, and when this reference count becomes zero, restore the
initial state.  You should be able to do this by hooking these routines
in fb_open() and fb_release().

The one I submitted (and a revised one I'm going to submit soon) should
be able to restore the VGA text/graphics mode.  Complement this with
your hardware's extended state save and restore routines and you should
be able to load/use/unload your driver repeatedly :-).

Tony

Tony

Re: [Linux-fbdev-devel] aty support

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

On Sun, 1 Dec 2002, Nico Schottelius wrote:
> I tried to get my notebook running with a framebuffer device,but
> after hours trying around I got only vesa-fb running.

    [...]

> 01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage P/M Mob=
ility AGP 2x (rev 64)
> 01:00.0 Class 0300: 1002:4c4d (rev 64)

You may want to try the atyfb patches from Dani=EBl Mantione
<da...@de...>,

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m6=
8k.org

In personal conversations with technical people, I call myself a hacker. =
But
when I'm talking to journalists I just say "programmer" or something like=
 that.
							    -- Linus Torvalds

Re: [Linux-fbdev-devel] [PATCH] FBDev: vga16fb port

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

On Tue, Dec 03, 2002 at 05:22:35PM +0500, Antonino Daplas wrote:
> >   2) The ability to go back to vga text mode on close of /dev/fb. 
> >      Yes fbdev/fbcon supports that now. 
> 
> I'll take a stab at writing VGA save/restore routines which hopefully is
> generic enough to be used by various hardware.  No promises though, VGA
> programming gives me a headache :(

BTW, i am writing a fbdev for a card where the docs tell me to disable
vga output before enabling graphical output. Does i need to do this in
the fbdev i write, or is it already handled by the vga layer, or
whatever ?

Friendly,

Sven Luther

[Linux-fbdev-devel] console_struct.h:97: `MAX_NR_CONSOLES' undeclared here

[Miles L. <mil...@at...>]

I applied the patch from tonight to 2.5.50 and got this build error:
http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz 
<http://phoenix.infradead.org/%7Ejsimmons/fbdev.diff.gz> 

gcc -Wp,-MD,kernel/.suspend.o.d -D__KERNEL__ -Iinclude -Wall 
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common 
-fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=athlon 
-Iarch/i386/mach-generic -nostdinc -iwithprefix include    
-DKBUILD_BASENAME=suspend -DKBUILD_MODNAME=suspend -DEXPORT_SYMTAB  -c 
-o kernel/suspend.o kernel/suspend.c
In file included from include/linux/vt_kern.h:12,
                 from kernel/suspend.c:46:
include/linux/console_struct.h:97: `MAX_NR_CONSOLES' undeclared here 
(not in a function)
kernel/suspend.c:294:2: warning: #warning This might be broken. We need 
to somehow wait for data to reach the disk
kernel/suspend.c: In function `count_and_copy_data_pages':
kernel/suspend.c:516: warning: passing arg 1 of `mmx_copy_page' makes 
pointer from integer without a cast
kernel/suspend.c:516: warning: passing arg 2 of `mmx_copy_page' makes 
pointer from integer without a cast
make[2]: *** [kernel/suspend.o] Error 1

CONFIG_MK7=y

#
# Graphics support
#
CONFIG_FB=y
# CONFIG_FB_CLGEN is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
CONFIG_FB_VESA=y
CONFIG_VIDEO_SELECT=y
# CONFIG_FB_HGA is not set
CONFIG_FB_RIVA=y

CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_PCI_CONSOLE=y
# CONFIG_FBCON_ADVANCED is not set
# CONFIG_FONTWIDTH8_ONLY is not set
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y

Re: [Linux-fbdev-devel] [PATCH] FBDev: vga16fb port

[Tomas S. <sz...@pi...>]

> 
> > I question whether thats something that belongs anywhere near the
> > kernel. Ben Pfaff wrote a fine library for vga16 hackery (BOGL) and it
> > combines very nicely with the fb driver.
> 
> Out of curiousity where is this library.

http://packages.qa.debian.org/b/bogl.html
http://http.us.debian.org/debian/pool/main/b/bogl/bogl_0.1.10-3.tar.gz

-- 
Tomas Szepe <sz...@pi...>

[Linux-fbdev-devel] Re: [STATUS] fbdev api.

[Antonino D. <ad...@po...>]

On Wed, 2002-12-04 at 03:18, James Simmons wrote:
> 
> > Attached is a patch against linux-2.5.50 + your fbdev.diff.
> 
> Applied :-)
> 
> > b.  Another rewrite of fbcon_show_logo() so it's more understandable
> > (hopefully).  I also added support for the rest of the visuals, but
> > untested yet.
> > Not tested:
> > static psuedocolor, mono01, and mono10.
> 
> I have a mono hga card.
> 
Can you apply the following patch to include logo drawing support for all formats :-)?

diff -Naur linux-2.5.50-js/drivers/video/cfbimgblt.c linux/drivers/video/cfbimgblt.c
--- linux-2.5.50-js/drivers/video/cfbimgblt.c	2002-12-04 03:14:19.000000000 +0000
+++ linux/drivers/video/cfbimgblt.c	2002-12-04 03:13:57.000000000 +0000
@@ -123,11 +123,11 @@
 			shift = start_index;
 		}
 		while (n--) {
-			if (p->fix.visual == FB_VISUAL_PSEUDOCOLOR)
-				color = *src & bitmask; 
 			if (p->fix.visual == FB_VISUAL_TRUECOLOR ||
 			    p->fix.visual == FB_VISUAL_DIRECTCOLOR )
 				color = palette[*src] & bitmask;
+			else
+				color = *src & bitmask; 
 			val |= SHIFT_HIGH(color, shift);
 			if (shift >= null_bits) {
 				FB_WRITEL(val, dst++);

> > c.  prevent fbcon module from loading if no fbdev is registered.  Also
> > made fbcon module unsafe to unload (for now).  This is optional, of course.
> 
> It is a good idea until we have the ability to switch back to text mode.
> 
It's not the switch back to text mode, that's very doable (see my other
reply).  It's during give_up_console() at fbcon module exit.  At this
point, the console suddenly disappears and freezes the system.  Maybe we
can save the global "conswitchp" during fbcon module init, then
something like this at fbcon module exit:

void __exit fb_console_exit(void)
{	
	give_up_console(&fbcon);
	take_over_console(saved_conswitchp, ...);	
}

Is this feasible?

Tony

[Linux-fbdev-devel] Re: [STATUS] fbdev api.

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

> Attached is a patch against linux-2.5.50 + your fbdev.diff.

Applied :-)

> b.  Another rewrite of fbcon_show_logo() so it's more understandable
> (hopefully).  I also added support for the rest of the visuals, but
> untested yet.
> Not tested:
> static psuedocolor, mono01, and mono10.

I have a mono hga card.

> c.  prevent fbcon module from loading if no fbdev is registered.  Also
> made fbcon module unsafe to unload (for now).  This is optional, of course.

It is a good idea until we have the ability to switch back to text mode.

Re: [Linux-fbdev-devel] [PATCH] FBDev: vga16fb port

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

> I question whether thats something that belongs anywhere near the
> kernel. Ben Pfaff wrote a fine library for vga16 hackery (BOGL) and it
> combines very nicely with the fb driver.

Out of curiousity where is this library.

Re: [Linux-fbdev-devel] [PATCH] FBDev: vga16fb port

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

> > I question whether thats something that belongs anywhere near the
> > kernel. Ben Pfaff wrote a fine library for vga16 hackery (BOGL) and it
> > combines very nicely with the fb driver.
> I kinda agree with this.  Most fb apps use mmap to access the
> framebuffer, so it's almost impossible to fake a linear framebuffer from
> a planar one.

Okay. Then that idea is scrapped.

Re: [Linux-fbdev-devel] [PATCH] FBDev: vga16fb port

[Antonino D. <ad...@po...>]

On Tue, 2002-12-03 at 20:47, Alan Cox wrote:
> On Tue, 2002-12-03 at 12:22, Antonino Daplas wrote:
> > >   Things I like to get done for the vga16fb driver. 
> > > 
> > >   1) Its own read and write functions to fake a linear framebuffer.
> > Should be doable with fb_write and fb_read, but with mmap, the app still
> > needs to know the VGA format.
> 
> I question whether thats something that belongs anywhere near the
> kernel. Ben Pfaff wrote a fine library for vga16 hackery (BOGL) and it
> combines very nicely with the fb driver.
I kinda agree with this.  Most fb apps use mmap to access the
framebuffer, so it's almost impossible to fake a linear framebuffer from
a planar one.  

> 
> > >   2) The ability to go back to vga text mode on close of /dev/fb. 
> > >      Yes fbdev/fbcon supports that now. 
> > 
> > I'll take a stab at writing VGA save/restore routines which hopefully is
> > generic enough to be used by various hardware.  No promises though, VGA
> > programming gives me a headache :(
> 
> You can pull the code out of the old svgalib library. Since its not
> doing any card specific stuff the generic vga->text restore ought to do
> the right thing.
> 
Thanks for the info.  I think I'll review this one to see what I missed.

Tony

Re: [Linux-fbdev-devel] [PATCH] FBDev: vga16fb port

[Antonino D. <ad...@po...>]

On Tue, 2002-12-03 at 01:31, James Simmons wrote:
James,

>   2) The ability to go back to vga text mode on close of /dev/fb. 
>      Yes fbdev/fbcon supports that now. 
>  

Here's a preliminary and highly unpolished patch for saving and
restoring the initial vga state.  The module allows saving/restoring of
specific hardware states (vga fonts/character maps, color map, and/or
video mode) by specifying different flags. Most hardware probably will
just need restoring of the initial video mode though.  Hopefully, it
should be generic enough to complement device specific state save and
restore routines. 

For testing purposes, I also patched vga16fb.c to use the module during
fb_open and fb_release.  Try loading vga16fb, and when opened, the video
mode will change.  On close, the state of vgacon should be restored. I
have tested this with two different VGA cards, and both seems to work
quite well. However, color map and character map state restores are still untested.  

Note that the module still makes assumptions that may not be necessarily
correct for all hardware (ie vga base is at 0xa0000). Secondly, there's
no check if the card is in VGA mode, EGA mode, or graphics mode. Please
review.

Tony

Re: [Linux-fbdev-devel] [PATCH] FBDev: vga16fb port

[Alan C. <al...@lx...>]

On Tue, 2002-12-03 at 12:22, Antonino Daplas wrote:
> >   Things I like to get done for the vga16fb driver. 
> > 
> >   1) Its own read and write functions to fake a linear framebuffer.
> Should be doable with fb_write and fb_read, but with mmap, the app still
> needs to know the VGA format.

I question whether thats something that belongs anywhere near the
kernel. Ben Pfaff wrote a fine library for vga16 hackery (BOGL) and it
combines very nicely with the fb driver.

> >   2) The ability to go back to vga text mode on close of /dev/fb. 
> >      Yes fbdev/fbcon supports that now. 
> 
> I'll take a stab at writing VGA save/restore routines which hopefully is
> generic enough to be used by various hardware.  No promises though, VGA
> programming gives me a headache :(

You can pull the code out of the old svgalib library. Since its not
doing any card specific stuff the generic vga->text restore ought to do
the right thing.

[Linux-fbdev-devel] Re: [STATUS] fbdev api.

[Antonino D. <ad...@po...>]

On Tue, 2002-12-03 at 02:07, James Simmons wrote:
> 
> Hi!
> 
>   I have a new patch avaiable. It is against 2.5.50. The patch is at 
> 
> http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
> 
> Have fun!!!!
> 
> Drivers ported are: (Give them a try)
> 
>     ATI Mach 64
>     ATI 128
>     VESA 
>     VGA16
>     HGA
>     NIVIDA
>     NEOMAGIC
>      
> The BIG changes are:
> 
> 1) The seperation of the console code out of the fbdev drivers. 
> 
> 2) Total modularity of the frmaebuffer console system. Yes that is 
>    right. You can build it has modules. Great for testing.
> 
> The following are results of the new changes which I have tested.
> 
>    With my VIA laptop with my neomagic card I was able to build it with 
> vgacon and no fbcon. Then I insmod neofb and the soft accel (cfb*.c) 
> needed. It loading and did NOT change the video hardware state. At this 
> point I could run fbdev apps including a X server using /dev/fb solely. 
> On opening /dev/fb0 the graphics hardware state changed. In theory I could 
> exit X and get vgacon back. In order to do this I have to reset the 
> hardware back to vga text mode in the fb_release function. It can be done 
> but I haven't done it yet.
>    With the second experiment I was able to insmod the fonts and fbcon.o.
> Then it switched from vgacon to fbcon. In theory I could again call the 
> release function and reset the hardware back to a text mode state. All 
> that is needed is the hardware specific code to do this.
> 
> Things to be done:
> 
>     1) A few bugs in fbcon to hammer out. 
>  
>     2) Fbcon to support changing resolution via the console layer. 
> 
>     3) Move the logo code out of fbcon.c to fbmem.c. With pure fbdev 
>        you need something to let you know things worked.
> 
>     4) Software rotation.
> 

Attached is a patch against linux-2.5.50 + your fbdev.diff.

a.  changed __MOD_INC_USE_COUNT and __MOD_DEC_USE_COUNT to
try_module_get() and module_put() respectively.  This will allow modules
to be safely unloaded.

b.  Another rewrite of fbcon_show_logo() so it's more understandable
(hopefully).  I also added support for the rest of the visuals, but
untested yet.  

Tested with different hardware (little endian):
truecolor, directcolor, pseudocolor, vga 4-bit pseudocolor.  

Not tested:
static psuedocolor, mono01, and mono10.

c.  prevent fbcon module from loading if no fbdev is registered.  Also
made fbcon module unsafe to unload (for now).  This is optional, of course.

Re: [Linux-fbdev-devel] [PATCH] FBDev: vga16fb port

[Antonino D. <ad...@po...>]

On Tue, 2002-12-03 at 01:31, James Simmons wrote:
> 
> > Attached is a patch against 2.5.49 + James Simmons' latest fbdev.diff.
> > 
> > Added support for logo drawing.
> > Fixed vga16fb_imageblit() limitation of 8-pixel wide bitmap blitting
> > only.
> 
> Applied and tested :-=) The only weird thing is it drew the logo twice 
> when I don't have a SMP laptop. It works other than that. 
> 
Should be expected if the fbcon_show_logo() patch did not take.  I'm
resubmitting another patch in one of my replies.

> P.S
>   Things I like to get done for the vga16fb driver. 
> 
>   1) Its own read and write functions to fake a linear framebuffer.
Should be doable with fb_write and fb_read, but with mmap, the app still
needs to know the VGA format.

>   2) The ability to go back to vga text mode on close of /dev/fb. 
>      Yes fbdev/fbcon supports that now. 

I'll take a stab at writing VGA save/restore routines which hopefully is
generic enough to be used by various hardware.  No promises though, VGA
programming gives me a headache :(

Tony

Re: [Linux-fbdev-devel] CGsix docs

[Al. A. <ee...@ee...>]

> > Uzi is the guy for this. I assume you are looking to port the sun
> > fbdev drivers to the new api?
>
> Actually, I never had any docs on the CG6... I can prod around and see
> if I can get my hands on 'em (with no promises).  You might wanna check
> with davem or jakub and see if they have the docs.

Thanks to both.

I am generally fiddling with the fb device (the original reason was
writing a fb gfx library to make MGR work). I'll search some more.

--
Al. Andreou <ee...@ee...> | http://nemesis.ee.teiath.gr/~ee4299/
Give me Linux, gcc and a six-pack | http://hydra.hellug.gr/
    and I will move the world

Re: [Linux-fbdev-devel] [PATCH] FBDev: fix for fbcon Oops

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

> This fixes fbcon oopsing at load time which is due to the fb_cursor's
> palette index entries being improperly updated.

Fixed.

> A new kind of 'emacs glitch'  appeared, though. This can be described as
> a block of text that is incompletely  copied, ie when "tabbing" a line
> of text.  This is present with all hardware I tested, soft accel and
> hardware accel, which indicates a problem in the higher layers (probably
> fbcon). vgacon works okay.  

Its is fbcon. If you play with the low level driver to draw things you 
noticed everything is okay. I have to track it down.
 
> Other changes:
> 
> 1. optimization of fbcon_accel_putcs()

Applied. If you look at my patch I attempted to make fbcon_pixmap dynamic 
instead of a static memeory area. It oops so I have that code commented 
out for now. Actually I applied it when the fix came out rigth away.

> 2. enabling logo displays at all packed pixel formats (as long as
> fb_imageblit is supported)

This didn't apply well. Only thing missing.

> 3. Various fbcon_accel_cursor() fixes which would have resulted in
> wrong cursor colors or an invisible cursor.

Applied. Worked now :-)