From: James Simmons <hidden> Date: 2003-03-26 19:45:59
Okay. Here you go. This patch is against 2.5.66 vanialla. I tested to see
if it applied. It does. Basically I added back in the static buffers in
accel_cursor in fbcon.c. Now the cursor will work just like it did before.
The draw back is that if you have more than one framebuffer then the
cursors will be messed up. So for single headed frmaebuffer systems it
will work perfectly. It is not that big of a deal since the console layer
is broken for multi-head and pre-emptive support anyways. Plus fbcon has
issues as well. The proper fix would require a huge amount of work.
I have a few updated drivers as well. Please test.
http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
drivers/video/aty/aty128fb.c | 16 +-
drivers/video/cfbimgblt.c | 4
drivers/video/console/fbcon.c | 246 +++++++++++++++++++++-------------------
drivers/video/controlfb.c | 18 --
drivers/video/fbmem.c | 42 ++----
drivers/video/i810/i810.h | 6
drivers/video/i810/i810_accel.c | 140 +++++++++++-----------
drivers/video/i810/i810_dvt.c | 3
drivers/video/i810/i810_gtf.c | 7 -
drivers/video/i810/i810_main.c | 135 +++++++++------------
drivers/video/i810/i810_main.h | 4
drivers/video/logo/logo.c | 69 +++++------
drivers/video/platinumfb.c | 28 +---
drivers/video/radeonfb.c | 10 +
drivers/video/riva/fbdev.c | 2
drivers/video/softcursor.c | 95 ++++-----------
drivers/video/tdfxfb.c | 18 +-
drivers/video/tgafb.c | 2
drivers/video/vga16fb.c | 4
include/linux/fb.h | 4
include/linux/linux_logo.h | 2
21 files changed, 393 insertions(+), 462 deletions(-)
-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
Okay. Here you go. This patch is against 2.5.66 vanialla. I tested to see
if it applied. It does. Basically I added back in the static buffers in
accel_cursor in fbcon.c. Now the cursor will work just like it did before.
The draw back is that if you have more than one framebuffer then the
cursors will be messed up. So for single headed frmaebuffer systems it
will work perfectly. It is not that big of a deal since the console layer
is broken for multi-head and pre-emptive support anyways. Plus fbcon has
issues as well. The proper fix would require a huge amount of work.
I have a few updated drivers as well. Please test.
James,
1 The patch still has the atomic_dec(...) in fb_show_logo(). It's not
needed and is actually disruptive.
2. You can still avoid static buffers by just pre-allocating them per
device during fbcon_startup(). We therefore avoid multiple devices
using the same buffers.
3. We can now use a more "lightweight" lock (spin_lock/unlock, instead
of spin_lock_irqsave/unlock_irqrestore) in fb_get_buffer_offset.
4 A new bit definition, FB_CUR_SETFLASH for fb_cursor.set to mean that
the command came from fb_callback/fb_vbl_handler. Drivers can test this
flag and if set, can ignore the entire command if it has support for
hardware cursor blinking.
5. logo fixes
- forgotten case statement for FB_VISUAL_PSEUDOCOLOR.
- image->depth should be representative of the data depth
(currently, either 8 or 1). If image->depth == 1, color expansion can
now be used to draw the logo, thus there's no need to differentiate
between mono logo drawing and monochrome expansion.
The patch is against 2.5.66 + fbdev.diff.gz.
Tony
diff -Naur linux-2.5.66-orig/drivers/video/cfbimgblt.c linux-2.5.66/drivers/video/cfbimgblt.c
@@ -530,6 +530,7 @@*LowLevelOperations*//* NOTE: fbcon cannot be __init: it may be called from take_over_console later */+staticconstchar*fbcon_startup(void){constchar*display_desc="frame buffer device";
@@ -593,9 +594,16 @@returnNULL;}+/* Allocate private data */+info->fbcon_priv=kmalloc(sizeof(structfbcon_private),GFP_KERNEL);+if(info->fbcon_priv==NULL){+kfree(vc);+returnNULL;+}+/* Initialize the work queue */INIT_WORK(&info->queue,fb_callback,info);-+/* Setup default font */vc->vc_font.data=font->data;vc->vc_font.width=font->width;
@@ -342,8 +342,7 @@__u32flags;/* see FB_PIXMAP_* */void(*outbuf)(u8dst,u8*addr);/* access methods */u8(*inbuf)(u8*addr);-unsignedlonglock_flags;/* flags for locking */-spinlock_tlock;/* spinlock */+spinlock_tlock;atomic_tcount;};#ifdef __KERNEL__
@@ -406,15 +405,15 @@structfb_var_screeninfovar;/* Current var */structfb_fix_screeninfofix;/* Current fix */structfb_monspecsmonspecs;/* Current Monitor specs */-structfb_cursorcursor;/* Current cursor */-structwork_structqueue;/* Framebuffer event queue */-structfb_pixmappixmap;/* Current pixmap */structfb_cmapcmap;/* Current cmap */+structwork_structqueue;/* Framebuffer event queue */+structfb_pixmappixmap;/* Current pixmap */structfb_ops*fbops;char*screen_base;/* Virtual address */structvc_data*display_fg;/* Console visible on this display */intcurrcon;/* Current VC. */void*pseudo_palette;/* Fake palette of 16 colors */+void*fbcon_priv;/* console-related private structure *//* From here on everything is device dependent */void*par;};-------------------------------------------------------
- image->depth should be representative of the data depth
(currently, either 8 or 1). If image->depth == 1, color expansion can
now be used to draw the logo, thus there's no need to differentiate
between mono logo drawing and monochrome expansion.
+ /*
+ * Monochrome expansion and logo drawing functions are the same if
+ * fb_logo.needs_logo == 1.
+ */
+ switch (info->fix.visual) {
+ case FB_VISUAL_MONO10:
+ image.fg_color = (u32) (~(~0UL << fb_logo.depth));
Shouldn't these be info->var.bits_per_pixel instead of fb_logo.depth?
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
-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
On Thu, 2003-03-27 at 17:09, Geert Uytterhoeven wrote:
On 27 Mar 2003, Antonino Daplas wrote:
quoted
- image->depth should be representative of the data depth
(currently, either 8 or 1). If image->depth == 1, color expansion can
now be used to draw the logo, thus there's no need to differentiate
between mono logo drawing and monochrome expansion.
quoted
+ /*
+ * Monochrome expansion and logo drawing functions are the same if
+ * fb_logo.needs_logo == 1.
+ */
+ switch (info->fix.visual) {
+ case FB_VISUAL_MONO10:
+ image.fg_color = (u32) (~(~0UL << fb_logo.depth));
Shouldn't these be info->var.bits_per_pixel instead of fb_logo.depth?
Yes, fb_logo.depth == info->var.bits_per_pixel.
Tony
-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
On Thu, 2003-03-27 at 17:09, Geert Uytterhoeven wrote:
quoted
On 27 Mar 2003, Antonino Daplas wrote:
quoted
- image->depth should be representative of the data depth
(currently, either 8 or 1). If image->depth == 1, color expansion can
now be used to draw the logo, thus there's no need to differentiate
between mono logo drawing and monochrome expansion.
quoted
+ /*
+ * Monochrome expansion and logo drawing functions are the same if
+ * fb_logo.needs_logo == 1.
+ */
+ switch (info->fix.visual) {
+ case FB_VISUAL_MONO10:
+ image.fg_color = (u32) (~(~0UL << fb_logo.depth));
Shouldn't these be info->var.bits_per_pixel instead of fb_logo.depth?
Yes, fb_logo.depth == info->var.bits_per_pixel.
Euh, now I get confused... Do you mean
`Yes, it should be replaced by info->var.bits_per_pixel' or
`No, logo.depth is always equal to info->var.bits_per_pixel'?
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
-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
On Fri, 2003-03-28 at 04:49, Geert Uytterhoeven wrote:
quoted
quoted
Shouldn't these be info->var.bits_per_pixel instead of fb_logo.depth?
Yes, fb_logo.depth == info->var.bits_per_pixel.
Euh, now I get confused... Do you mean
`Yes, it should be replaced by info->var.bits_per_pixel' or
`No, logo.depth is always equal to info->var.bits_per_pixel'?
:) Sorry about that. I meant:
`No, fb_logo.depth is always equal to info->var.bits_per_pixel'
Tony
-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
From: James Simmons <hidden> Date: 2003-03-28 04:37:43
quoted
quoted
quoted
Shouldn't these be info->var.bits_per_pixel instead of fb_logo.depth?
Yes, fb_logo.depth == info->var.bits_per_pixel.
Euh, now I get confused... Do you mean
`Yes, it should be replaced by info->var.bits_per_pixel' or
`No, logo.depth is always equal to info->var.bits_per_pixel'?
:) Sorry about that. I meant:
`No, fb_logo.depth is always equal to info->var.bits_per_pixel'
No this is no longer true. For example last night I displayed the 16 color
logo perfectly fine on a 16 bpp display!!!! The mono display still has
bugs tho. The new logo tries to pick the best image to display. Say for
example we have two video cards. One running VESA fbdev at 16 bpp and a
another at vga 4 planar via vga16fb. This way we can have the both the 16
color and 224 color logo compiled in. The correct logo will be displayed
then on the correct display. Now say we only have a mono display but all
the cards support 8 bpp or better. That logo still gets displayed.
-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
Shouldn't these be info->var.bits_per_pixel instead of fb_logo.depth?
Yes, fb_logo.depth == info->var.bits_per_pixel.
Euh, now I get confused... Do you mean
`Yes, it should be replaced by info->var.bits_per_pixel' or
`No, logo.depth is always equal to info->var.bits_per_pixel'?
:) Sorry about that. I meant:
`No, fb_logo.depth is always equal to info->var.bits_per_pixel'
No this is no longer true. For example last night I displayed the 16 color
logo perfectly fine on a 16 bpp display!!!! The mono display still has
bugs tho. The new logo tries to pick the best image to display. Say for
example we have two video cards. One running VESA fbdev at 16 bpp and a
another at vga 4 planar via vga16fb. This way we can have the both the 16
color and 224 color logo compiled in. The correct logo will be displayed
then on the correct display. Now say we only have a mono display but all
Didn't it always work like that? You got the 16 color logo on vga16fb and the
224 color logo on displays with more than 256 colors (except for directcolor).
the cards support 8 bpp or better. That logo still gets displayed.
^^^^
Which logo do you mean with `that'? On a monochrome display, it should be the
monochrome logo.
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
On Fri, 2003-03-28 at 16:00, Geert Uytterhoeven wrote:
On Fri, 28 Mar 2003, James Simmons wrote:
quoted
quoted
quoted
quoted
quoted
Shouldn't these be info->var.bits_per_pixel instead of fb_logo.depth?
Yes, fb_logo.depth == info->var.bits_per_pixel.
Euh, now I get confused... Do you mean
`Yes, it should be replaced by info->var.bits_per_pixel' or
`No, logo.depth is always equal to info->var.bits_per_pixel'?
:) Sorry about that. I meant:
`No, fb_logo.depth is always equal to info->var.bits_per_pixel'
No this is no longer true. For example last night I displayed the 16 color
logo perfectly fine on a 16 bpp display!!!! The mono display still has
bugs tho. The new logo tries to pick the best image to display. Say for
example we have two video cards. One running VESA fbdev at 16 bpp and a
another at vga 4 planar via vga16fb. This way we can have the both the 16
color and 224 color logo compiled in. The correct logo will be displayed
then on the correct display. Now say we only have a mono display but all
Didn't it always work like that? You got the 16 color logo on vga16fb and the
224 color logo on displays with more than 256 colors (except for directcolor).
If I'm not mistaken, I think what James meant was that the new code has
the capability of choosing an appropriate logo even if it does not
maximize the color range of the display. Ie if only 4bpp logo is
compiled, but display is set at 8bpp-pseudocolor, it would still
display a 4bpp logo correctly.
Personally, I think it's really a simple matter of choosing the
appropriate logo type for the correct display device, instead of the
code trying to outthink the intention of the user.
However, that was never my point. What I see is a problem with the new
code. What if the display is set at 16-bpp DirectColor? The code will
choose clut224 for it, but that is not correct and may even crash due to
an "out of bounds" error in the pseudo_palette. Directcolor 565, for
instance, will only have 32 entries for red and blue, and 64 entries for
green, greatly exceeding 224. Similarly, Directcolor < 12bpp, will
actually need monochrome, not even 4bpp, and definitely not clut224.
There are other obvious and non-obvious examples that I can enumerate.
quoted
the cards support 8 bpp or better. That logo still gets displayed.
^^^^
Which logo do you mean with `that'? On a monochrome display, it should be the
monochrome logo.
The patch I submitted was tested by simulating monochrome on an 8-bit
display. It used monochrome logo, drawn using monochrome expansion, and
it works for me.
Tony
-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-03-28 13:06:58
Hi James !
Why did you move the driver includes to include/video ? What is
the reasoning here ?
For example, drivers/video/radeon.h moved to include/video/radeon.h
Is this to be able to share register definitions with the DRM drivers ?
(I doubt this will ever happen as the DRM is rather self contained)
I would have preferred those includes to stay next to their respective
drivers (though renaming radeon.h to radeonfb.h might have made some
sense).
Regards,
Ben.
-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
From: James Simmons <hidden> Date: 2003-04-02 22:45:23
Hi James !
Why did you move the driver includes to include/video ? What is
the reasoning here ?
For example, drivers/video/radeon.h moved to include/video/radeon.h
Is this to be able to share register definitions with the DRM drivers ?
(I doubt this will ever happen as the DRM is rather self contained)
Yes. You never know. The other big reason was so userland could have a
standard set of hardware header files to program graphics hardware. Now
SDL and directfb etc can use the same header files.
On Thu, 2003-03-27 at 11:01, Antonino Daplas wrote:
5. logo fixes
- forgotten case statement for FB_VISUAL_PSEUDOCOLOR.
- image->depth should be representative of the data depth
(currently, either 8 or 1). If image->depth == 1, color expansion can
now be used to draw the logo, thus there's no need to differentiate
between mono logo drawing and monochrome expansion.
The patch is against 2.5.66 + fbdev.diff.gz.
Grr. The patch has a few problems...
Tony
diff -Naur linux-2.5.66-orig/drivers/video/console/fbcon.c linux-2.5.66/drivers/video/console/fbcon.c