Sorry about not producing a regular diff. The final changes really did a
number on the framebuffer console code in fbcon.c so I had some massive
work to do. I still have a massive amount of cleaning up to do. Also a lot
of drivers stil haven't been ported.
So here is the regular diff against 2.5.45
http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
James,
The diff you posted is still not the right one.
Tony
From: James Simmons <hidden> Date: 2002-10-31 23:44:29
quoted
Sorry about not producing a regular diff. The final changes really did a
number on the framebuffer console code in fbcon.c so I had some massive
work to do. I still have a massive amount of cleaning up to do. Also a lot
of drivers stil haven't been ported.
So here is the regular diff against 2.5.45
http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
James,
The diff you posted is still not the right one.
From: Sven Luther <hidden> Date: 2002-11-01 08:59:19
On Thu, Oct 31, 2002 at 01:03:54PM -0800, James Simmons wrote:
Sorry about not producing a regular diff. The final changes really did a
number on the framebuffer console code in fbcon.c so I had some massive
work to do. I still have a massive amount of cleaning up to do. Also a lot
of drivers stil haven't been ported.
So here is the regular diff against 2.5.45
http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
Doesn't apply, seems to be a diff against 2.5.2.
Friendly,
Sven Luther
From: James Simmons <hidden> Date: 2002-11-01 16:12:24
quoted
Sorry about not producing a regular diff. The final changes really did a
number on the framebuffer console code in fbcon.c so I had some massive
work to do. I still have a massive amount of cleaning up to do. Also a lot
of drivers stil haven't been ported.
So here is the regular diff against 2.5.45
http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
Sorry about not producing a regular diff. The final changes really did a
number on the framebuffer console code in fbcon.c so I had some massive
work to do. I still have a massive amount of cleaning up to do. Also a lot
of drivers stil haven't been ported.
So here is the regular diff against 2.5.45
http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
James,
I tried the patch, and it does produce a cleaner and smaller driver.
Overall, I like it. Some observations:
1. Without the fb_set_var() hook, switching from X messes up the
console. I would guess this will be addressed by the console?
2. Console panning/wrapping does not work. updatevar includes a check
"if (con == info->currcon)", and my guess is info->currcon is obsoleted
so the check always fails.
3. fbdev can be loaded without taking over the console. After running
an fb-based application, exiting fbdev messes up the vga console
(actually hangs the system). Should the fbdev driver provide the
capability to restore the VGA state then, ie at info->fb_release?
4. The initial font loaded is 8x8. It seems that 8x16 fonts are limited
for the SGI console console only. Any reason why?
5. The cfb_* drawing functions still behave erratically, especially in
emacs. Geert has made some versions that work correctly for me. This
was discussed in a thread sometimes ago.
Some of the above problems may be from the driver side (ie. #3).
Tony
Attached is a diff that will allow the logo to be drawn at 8-bpp
pseudocolor:
diff -Naur linux-2.4.45-fbdev/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c
--- linux-2.4.45-fbdev/drivers/video/console/fbcon.c Fri Nov 1 19:19:13 2002+++ linux/drivers/video/console/fbcon.c Fri Nov 1 19:20:00 2002
From: James Simmons <hidden> Date: 2002-11-01 22:29:24
James,
I tried the patch, and it does produce a cleaner and smaller driver.
Overall, I like it. Some observations:
1. Without the fb_set_var() hook, switching from X messes up the
console. I would guess this will be addressed by the console?
fbcon_switch has to be rewritten. I'm going threw the process of cleaning
up the upper fbcon layer. Its such a mess. Yuck!!!
2. Console panning/wrapping does not work. updatevar includes a check
"if (con == info->currcon)", and my guess is info->currcon is obsoleted
so the check always fails.
It worked before. Strange. Do you mean for you console panning doesn't
work on the visiable VC or a non visible VC?
3. fbdev can be loaded without taking over the console. After running
an fb-based application, exiting fbdev messes up the vga console
(actually hangs the system). Should the fbdev driver provide the
capability to restore the VGA state then, ie at info->fb_release?
Yes!!! Of course there is the issue is the framebuffer that actual one
used for vgacon or is it independent, thinking multihead here.
4. The initial font loaded is 8x8. It seems that 8x16 fonts are limited
for the SGI console console only. Any reason why?
I have no idea why that is. You can select a differnt font.
5. The cfb_* drawing functions still behave erratically, especially in
emacs. Geert has made some versions that work correctly for me. This
was discussed in a thread sometimes ago.
Where are the patchs. I like to incorporate them into BK.
Attached is a diff that will allow the logo to be drawn at 8-bpp
pseudocolor:
James,
I tried the patch, and it does produce a cleaner and smaller driver.
Overall, I like it. Some observations:
1. Without the fb_set_var() hook, switching from X messes up the
console. I would guess this will be addressed by the console?
fbcon_switch has to be rewritten. I'm going threw the process of cleaning
up the upper fbcon layer. Its such a mess. Yuck!!!
Thank goodness for this :) I was already thinking of adding an 'Option
Usefbdev' for the xfree86 driver.
quoted
2. Console panning/wrapping does not work. updatevar includes a check
"if (con == info->currcon)", and my guess is info->currcon is obsoleted
so the check always fails.
It worked before. Strange. Do you mean for you console panning doesn't
work on the visiable VC or a non visible VC?
I grepped the source for currcon, and did not see any instances where
it's being updated. So, I removed the "if (con == info->currcon)" line
and panning worked again for the current console. However, switching to
another console screws up the viewport again. The viewport will be
restored if I scrolled past yres_virtual.
Perhaps, I should apply your console patches? I haven't done that yet.
quoted
3. fbdev can be loaded without taking over the console. After running
an fb-based application, exiting fbdev messes up the vga console
(actually hangs the system). Should the fbdev driver provide the
capability to restore the VGA state then, ie at info->fb_release?
Yes!!! Of course there is the issue is the framebuffer that actual one
used for vgacon or is it independent, thinking multihead here.
I was trying to confirm if vgacon should restore its own state or not.
But this one is neat :) I added VGA save/restore state routines to
fb_open() and fb_release(). I was able to boot to a VGA console, fired
up XFBDev and DirectFB and exited back again to a VGA console. DirectFB
came back without problems, XFBDev needed a console reset.
I guess the save/restore state routines will only be needed for graphics
card with a VGA core. I think multiple graphics card or multi-head
systems will not be affected since the driver will only be
saving/restoring its own hardware anyway.
quoted
4. The initial font loaded is 8x8. It seems that 8x16 fonts are limited
for the SGI console console only. Any reason why?
I have no idea why that is. You can select a differnt font.
You have this in Kconfig in the 'console' directory.
config FONT_8x16
bool "VGA 8x16 font" if FBCON_FONTS
depends on FB && SGI_NEWPORT_CONSOLE=y
I changed the '&&' operator to '||' in my case.
quoted
5. The cfb_* drawing functions still behave erratically, especially in
emacs. Geert has made some versions that work correctly for me. This
was discussed in a thread sometimes ago.
Where are the patchs. I like to incorporate them into BK.
James,
I tried the patch, and it does produce a cleaner and smaller driver.
Overall, I like it. Some observations:
1. Without the fb_set_var() hook, switching from X messes up the
console. I would guess this will be addressed by the console?
fbcon_switch has to be rewritten. I'm going threw the process of cleaning
up the upper fbcon layer. Its such a mess. Yuck!!!
quoted
2. Console panning/wrapping does not work. updatevar includes a check
"if (con == info->currcon)", and my guess is info->currcon is obsoleted
so the check always fails.
It worked before. Strange. Do you mean for you console panning doesn't
work on the visiable VC or a non visible VC?
Adding update_var to fbcon_switch fixes #1 and #2 for me. Attached is a
diff.
Also, using fbset to change video modes corrupts the console. Looking
at the code, the flow of control is from the console to fbdev only? Is
this correct? I agree with this, it's saner.
Tony
diff -Naur linux/drivers/video/console/fbcon.c linux-2.5.45-fbdev/drivers/video/console/fbcon.c
--- linux/drivers/video/console/fbcon.c Sun Nov 3 08:19:32 2002+++ linux-2.5.45-fbdev/drivers/video/console/fbcon.c Sun Nov 3 08:18:56 2002
From: James Simmons <hidden> Date: 2002-11-07 21:18:31
Adding update_var to fbcon_switch fixes #1 and #2 for me. Attached is a
diff.
Patch applied :-)
Also, using fbset to change video modes corrupts the console. Looking
at the code, the flow of control is from the console to fbdev only? Is
this correct? I agree with this, it's saner.
Yes this is correct. In the next set of changes you will be able to set
the VC size via stty. You can change the resolution of the display via
/dev/fb but ideally after a close it will reset the VC original mode.
From: James Simmons <hidden> Date: 2002-11-07 23:08:00
quoted
fbcon_switch has to be rewritten. I'm going threw the process of cleaning
up the upper fbcon layer. Its such a mess. Yuck!!!
Thank goodness for this :) I was already thinking of adding an 'Option
Usefbdev' for the xfree86 driver.
There is already a option like that for XFree86.
quoted
Yes!!! Of course there is the issue is the framebuffer that actual one
used for vgacon or is it independent, thinking multihead here.
I was trying to confirm if vgacon should restore its own state or not.
But this one is neat :) I added VGA save/restore state routines to
fb_open() and fb_release(). I was able to boot to a VGA console, fired
up XFBDev and DirectFB and exited back again to a VGA console. DirectFB
came back without problems, XFBDev needed a console reset.
WOW!!! That is way to awesome. I have always wanted to see that actually
work.
I guess the save/restore state routines will only be needed for graphics
card with a VGA core. I think multiple graphics card or multi-head
systems will not be affected since the driver will only be
saving/restoring its own hardware anyway.
Correct. One thing I do like is when you insmod a driver it doesn't change
the mode. For example for the neomagic fbdev driver I compiled as a module
and then insmod while using vgacon. Its didn't change the graphics mode so
I was able to find a nasty bug. I could change the video mode once I did a
set_var via userland.
config FONT_8x16
bool "VGA 8x16 font" if FBCON_FONTS
depends on FB && SGI_NEWPORT_CONSOLE=y
I changed the '&&' operator to '||' in my case.
Applied.
quoted
quoted
5. The cfb_* drawing functions still behave erratically, especially in
emacs. Geert has made some versions that work correctly for me. This
was discussed in a thread sometimes ago.
Where are the patchs. I like to incorporate them into BK.
It didn't work. Can you send me those files direct. I like to apply them.
-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en