[PATCH] fbdev currcon

[PATCH] fbdev currcon

[James Simmons]

This patch only applies for the -dj tree since the new fbdev api is going
in there for now. This patch makes every fbdev driver uses the currcon
that I have placed in struct fb_info. Currently most drivers have currcon,
not the one for the console system, global. This is a problem if you have
more than one card. I have tested to see if this compiles on ix86 but
this patch is extensive so I like people to apply this patch to test it
out against the dj14 tree. The patch is to big to post so it is avalibale
at the following link:

NOTE: The setcolreg patch has to be applied first.

http://www.transvirtual.com/~jsimmons/setcolreg.diff
http://www.transvirtual.com/~jsimmons/fbcurrcon.diff

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'_   _/`\
 ___)=(___/

Re: [PATCH] fbdev currcon

[Russell King]

On Mon, Jan 14, 2002 at 04:39:43PM -0800, James Simmons wrote:
> [stuff about currcon]

I've killed currcon completely in the cyber2000fb driver in favour of
tracking which struct display is current.  Tracking 'currcon', doing
a whole pile of special cases, and copying 'var' stuff to/from fb.var
didn't make sense anymore.  I'm expecting the same thing will happen
with the other stuff in the struct fb_info.

(Think about the current cyber2000fb code, and what happens to other
consoles when you fbset 800x600-60 -a and then switch to them to
discover you only have a 640x480 window where the characters appear).

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [PATCH] fbdev currcon

[James Simmons]

> On Mon, Jan 14, 2002 at 04:39:43PM -0800, James Simmons wrote:
> > [stuff about currcon]
> 
> I've killed currcon completely in the cyber2000fb driver in favour of
> tracking which struct display is current.  Tracking 'currcon', doing
> a whole pile of special cases, and copying 'var' stuff to/from fb.var
> didn't make sense anymore.  I'm expecting the same thing will happen
> with the other stuff in the struct fb_info.

But struct display is going to go away!!!!!! You haven't seen the complete
new fbdev api. How much cleaner and superior to the current stuff. 

http://linuxconsole.sf.net

   The whole point was to make the fbdev layer independent of the VT tty
system. It makes no sense to have a tty on something like a iPAQ. This way
you can a /dev/fb interface with no VT. You can also do other nice
things like have a vga console on one display and still have a fbdev
driver. Think about how much easier it would be to debug a fbdev driver
that way. BTW that is how I was testing the new fbdev api. Having printk 
on a vga terminal will looking at printks while testing the fbdev driver.
It was so nice. Plus the amount of code reduction will be huge. I mean
huge. 
   Over the years the lower level console drivers have been building crude
to make up for the limitations of the upper console layer. This will be
cleaned up for 2.5.X. So now fbcon will be a wrapper around the fbdev
layer if we do want to use a VT. It will make a very nice small footprint
for embedded systems. BTW this was my goal. Another bonus will be I will
make the VT system modular. So if we do want a VT we can :-) I haven't had
the time to do this but I plan to. I wanted to test it on a iPAQ with a
stowaway keyboard. Think about the power of insmod a keyboard driver,
fbcon.o and then insmod vt.o. Talk about having a even smaller kernel
image to put in a partition. Some devices only have 512K of space to
place a bootable kernel. As time goes on it is becoming harder and
harder to do this. Now we can!!!!!!

It just makes me excited thinking about it:-)

> (Think about the current cyber2000fb code, and what happens to other
> consoles when you fbset 800x600-60 -a and then switch to them to
> discover you only have a 640x480 window where the characters appear).

This will be fixed and very soon. Trust me. 

P.S
   currcon is a temporary step to deal with the issue of only one foreground 
console. It will also GO AWAY as the console system is truly fixed to
support multiple desktops. Yes I have such a system at home so it is
possible. The only reason I'm doing it this way is so when I start
changing the console layer I don't have to rewrite ever single fbdev
driver. Or do you think I should rework the console layer first.  

Re: [PATCH] fbdev currcon

[Geert Uytterhoeven]

On Mon, 14 Jan 2002, James Simmons wrote:
> This patch only applies for the -dj tree since the new fbdev api is going
> in there for now. This patch makes every fbdev driver uses the currcon
> that I have placed in struct fb_info. Currently most drivers have currcon,
> not the one for the console system, global. This is a problem if you have
> more than one card. I have tested to see if this compiles on ix86 but
> this patch is extensive so I like people to apply this patch to test it
> out against the dj14 tree. The patch is to big to post so it is avalibale
> at the following link:
> 
> NOTE: The setcolreg patch has to be applied first.
> 
> http://www.transvirtual.com/~jsimmons/setcolreg.diff
> http://www.transvirtual.com/~jsimmons/fbcurrcon.diff

You forgot the part that adds currcon to <linux/fb.h>.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.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: [PATCH] fbdev currcon

[James Simmons]

> > NOTE: The setcolreg patch has to be applied first.
> > 
> > http://www.transvirtual.com/~jsimmons/setcolreg.diff
> > http://www.transvirtual.com/~jsimmons/fbcurrcon.diff
> 
> You forgot the part that adds currcon to <linux/fb.h>.

That is already in the -dj branch :-)