Hi folks!!
Here is the latest fbdev BK drop. It is against 2.6.0-test3. Test it out
and tell me your results. I like to do a code drop soon.
http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
bk pull http://fbdev.bkbits.net/fbdev-2.6
This will update the following files:
Documentation/fb/neofb.txt | 27
MAINTAINERS | 5
drivers/char/vt_ioctl.c | 12
drivers/video/Kconfig | 100
drivers/video/Makefile | 9
drivers/video/asiliantfb.c | 619 +++
drivers/video/aty/Makefile | 1
drivers/video/cfbimgblt.c | 2
drivers/video/chipsfb.c | 4
drivers/video/console/Makefile | 29
drivers/video/console/fbcon.c | 369 -
drivers/video/console/fbcon.h | 2
drivers/video/controlfb.c | 10
drivers/video/epson1355fb.c | 967 ++--
drivers/video/fbmem.c | 116
drivers/video/g364fb.c | 78
drivers/video/i810/Makefile | 7
drivers/video/imsttfb.c | 2
drivers/video/logo/Makefile | 15
drivers/video/logo/logo.c | 5
drivers/video/macfb.c | 34
drivers/video/neofb.c | 338 +
drivers/video/platinumfb.c | 10
drivers/video/pvr2fb.c | 846 +---
drivers/video/riva/fbdev.c | 75
drivers/video/riva/nv_type.h | 12
drivers/video/sis/300vtbl.h | 2437 ++----------
drivers/video/sis/310vtbl.h | 2574 ++----------
drivers/video/sis/init.c | 1882 +++++----
drivers/video/sis/init.h | 2435 +++++++++++-
drivers/video/sis/init301.c | 8208 +++++++++++++++++++++--------------------
drivers/video/sis/init301.h | 222 -
drivers/video/sis/initdef.h | 185
drivers/video/sis/oem300.h | 502 --
drivers/video/sis/oem310.h | 88
drivers/video/sis/osdef.h | 122
drivers/video/sis/sis_accel.c | 68
drivers/video/sis/sis_accel.h | 27
drivers/video/sis/sis_main.c | 3752 ++++++++++--------
drivers/video/sis/sis_main.h | 575 +-
drivers/video/sis/vgatypes.h | 81
drivers/video/sis/vstruct.h | 138
drivers/video/skeletonfb.c | 74
drivers/video/softcursor.c | 72
drivers/video/tdfxfb.c | 47
drivers/video/valkyriefb.c | 548 --
drivers/video/vesafb.c | 17
drivers/video/vgastate.c | 1
include/linux/fb.h | 88
include/linux/linux_logo.h | 4
include/linux/pci_ids.h | 11
include/video/epson1355.h | 64
include/video/neomagic.h | 261 -
include/video/sisfb.h | 91
54 files changed, 14922 insertions(+), 13346 deletions(-)
through these ChangeSets:
<jsimmons@bohr.(none)> (03/08/11 1.1151)
[NEOMAGIC FBDEV] Add going between graphics and VGA text mode.
<[email protected]> (03/07/21 1.1046.1.225)
[TDFX FBDEV] Fixes to make the image blitter work. Also the color handling code was fixed.
<[email protected]> (03/07/15 1.1046.1.221)
[FBCON] Always turn off the cursor in fbcon_cursor. The reason is that cursor might try to blink while we are reprogramming the hardware.
<[email protected]> (03/07/11 1.1046.1.218)
[IMSTT FBDEV] Free up resources when it fails.
<[email protected]> (03/07/11 1.1046.1.217)
[FBDEV] Makefiel cleanups.
<[email protected]> (03/07/11 1.1046.1.216)
[ASILIANT FBDEV] Added support for the asiliant graphics chipset.
<[email protected]> (03/07/09 1.1046.1.211)
[RIVA FBDEV] Support for more versions of GEFORCE 4. Also some cursor cleanup to allow it to compile.
<[email protected]> (03/07/08 1.1046.1.208)
[SIS FBDEV] Updates to the SiS framebuffer driver. Add support for 760 chipset, LCD scaling.
<jsimmons@kozmo.(none)> (03/07/03 1.1046.1.205)
[NEOMAGIC FBDEV] Fixed a nasty bug in the copyarea function. It wasn't testing for the condition when both regions have the same y coordinates but are over lapping. This casued a corrpution of data. Also started ot used the macros in vga.h.
<jsimmons@kozmo.(none)> (03/06/30 1.1046.1.200)
[LOGO] Display the correct logo for MIPS DEC workstations.
<jsimmons@kozmo.(none)> (03/06/25 1.1046.1.194)
[FBCON] Removed the crappy ROP_COPY/ROP_XOR test for flashing the cursor. Now we disable and enable the cursor timer instead.
<jsimmons@kozmo.(none)> (03/06/24 1.1046.1.192)
[FBDEV] Now we can use a specific hardware mapper for different hardware functionality.
<jsimmons@kozmo.(none)> (03/06/23 1.1046.1.188)
[VGA CORE] Added needed vmalloc header.
<jsimmons@kozmo.(none)> (03/06/23 1.1046.1.185)
[FBCON] When using 512 characters, the mouse pointer starts using the wrong complement_mask after a console reset.
<jsimmons@kozmo.(none)> (03/06/23 1.1046.1.184)
[FBDEV] Made chipsfb/controlfb/platinumfb use the xxfb kernel command line string.
<[email protected]> (03/06/18 1.1046.1.180)
[MAC FBDEV] Bug fixes.
<[email protected]> (03/06/15 1.1046.1.176)
[SIS FBDEV] More updates for the SIS driver.
<[email protected]> (03/06/14 1.1046.1.174)
[CONTROL/PLATINUM FBDEV] Fix to match change in fb_set_var.
<[email protected]> (03/06/10 1.1046.1.170)
[FBDEV] Fixed a issue with soft_cursor. It only worked with drivers with a pixmap.scan_align of 1. Now it will work with any.
<jsimmons@kozmo.(none)> (03/06/07 1.1046.1.164)
[SIS FBDEV] Fixed sysnc issue.
<jsimmons@kozmo.(none)> (03/06/05 1.1046.1.160)
[FBCON] Cleared out the struct fb_cursor we passed in. Other wise we get random data being used.
<jsimmons@kozmo.(none)> (03/05/30 1.1046.1.155)
[FBDEV GENERIC ACCEL] Fixed why logo was not displayed for some.
<[email protected]> (03/05/24 1.1046.155.3)
[VALKYRUE FBDEV] Ported to new api.
<[email protected]> (03/05/23 1.1046.155.1)
[FBDEV] Updates to explain the new cursor api.
<[email protected]> (03/05/23 1.1046.1.142)
[EPSON FRAMEBUFFER] Ported to the new api. Added support for the arm platform.
<[email protected]> (03/05/15 1.1046.84.18)
[SIS FBDEV] SIS Framebuffer updates.
- Added preliminary and untested support for SiS660
- Added DDC support
- Enhanced proprietary programming API for compatibility with X driver
and upcoming SDL updates and upcoming vidix driver for mplayer
- Fixes for video bridge output on various HW combinations
- Fixes in TV detection
- Reduced source size by removing duplicated data
- Updated Kconfig descriptions
<[email protected]> (03/05/14 1.1046.73.2)
[PVR2 FBDEV] Port of the Dreamcast Frambuffer to the new api.
<[email protected]> (03/05/12 1.1046.7.19)
[FBCON] set_con2fb_map wasn't testing to see the VC we where mapping to actually exist. Now it does.
I add code to fbcon_cursor to reset the hotspot if it was changed by userland.
<[email protected]> (03/05/12 1.1046.7.17)
[RIVA FBDEV] Removal of exccess variable. Kills off a few warnings.
<[email protected]> (03/05/12 1.1046.7.16)
[VESA FBDEV] Removed the EDID code. The results where mixed. It worked for some but not for others.
<[email protected]> (03/05/12 1.1046.7.15)
[CONSOLE] This patch fixes the problem of not being able to set the fonts on VCs other than the first one. This also was the bug that was casuing dual head (vga and mda) to lock up.
<jsimmons@kozmo.(none)> (03/05/02 1.1042.122.2)
[FBDEV] Synced to kdev_t change.
<jsimmons@kozmo.(none)> (03/04/22 1.1042.37.2)
[FBDEV] Moved pixmap to the kernel side of the header. Will not be needed for ioctl calls at the present time.
[FBCON] Lots more optimizations.
<jsimmons@kozmo.(none)> (03/04/21 1.1042.37.1)
[LOGO] Removed fb_ prefix. Wil be used by other drivers such as the newport driver.
[G354 FBDEV] Now use the final cursor api.
On Thu, Aug 14, 2003 at 08:54:21PM +0100, James Simmons wrote:
>
> Hi folks!!
>
> Here is the latest fbdev BK drop. It is against 2.6.0-test3. Test it out
> and tell me your results. I like to do a code drop soon.
James:
what is the current state of PM in fb drivers?
does modedb is being used on 2.6 drivers?
Is there an API (or lib) to use framebuffers devices without
worring about differents visuals?, to quering, setting or
disabling EDID support? will these drivers export sysfs
entries instead of control via ioctl's?
thanks for your work on fb.
-solca
> what is the current state of PM in fb drivers?
Experinmental patch from Ben is in the works.
> does modedb is being used on 2.6 drivers?
Yes.
> Is there an API (or lib) to use framebuffers devices without
> worring about differents visuals?,
???
> to quering, setting or
> disabling EDID support?
Yes. That is the fbmon.c stuff. Still needs work.
> will these drivers export sysfs
> entries instead of control via ioctl's?
Needs to be done. I'm not familiar with sysfs so it hasn't been done.
> thanks for your work on fb.
Your welcome.
On Thu, Aug 14, 2003 at 02:36:58PM -0600, Otto Solares wrote:
>
> Is there an API (or lib) to use framebuffers devices without
> worring about differents visuals?, to quering, setting or
> disabling EDID support? will these drivers export sysfs
> entries instead of control via ioctl's?
I have some initial sysfs patches for the fb code that I've been sitting
on in my trees. I was waiting for these patches to hit the mainline
before bothering James and the rest of the world with them.
But they don't export any of the ioctl stuff through the sysfs
interface, but that would not be very hard to do at all if you want to.
They just basically show the major/minor of the fb device, and point
back to the proper place in the device tree where the fb device lives,
which is all udev really needs right now.
thanks,
greg k-h
On Thu, 2003-08-14 at 22:52, James Simmons wrote:
> > what is the current state of PM in fb drivers?
>
> Experinmental patch from Ben is in the works.
That patch actually works here and I'm more/less waiting for it
to be merged so I can send you the driver updates based on it.
(It's becoming rather urgent. My pending PowerMac updates that
port things to the new model are causing PM to break on PowerBook
laptops now because fbdev has incorrect PM and the "old style" thing
isn't properly ordered).
The only thing you may probably want to fix (because you know
that code better than I do) are:
- the "resume" callback in fbcon where I currently just refresh
the foreground console, while you may actually want to refresh the
one on this fb since I suppose that with mutiple heads, we may have
consoles on more than one head ?
- the suspend callback where you probably want to disable the
cursor timer
Ben.
> That patch actually works here and I'm more/less waiting for it
> to be merged so I can send you the driver updates based on it.
> (It's becoming rather urgent. My pending PowerMac updates that
> port things to the new model are causing PM to break on PowerBook
> laptops now because fbdev has incorrect PM and the "old style" thing
> isn't properly ordered).
>
> The only thing you may probably want to fix (because you know
> that code better than I do) are:
>
> - the "resume" callback in fbcon where I currently just refresh
> the foreground console, while you may actually want to refresh the
> one on this fb since I suppose that with mutiple heads, we may have
> consoles on more than one head ?
>
> - the suspend callback where you probably want to disable the
> cursor timer
Will do. I like to also handle Video mode change. Even userland will like
to know when a mode change happened. For userland a signal can be sent.
This would be useful for someone in X that runs fbset in a Xterm. This
hoses the X server. It would be nice if the X server would see the signal
change and adapt to it. Fbset could in theory be used again to change a VC
size. Yuck!!!! But it is what people want.
> > Is there an API (or lib) to use framebuffers devices without
> > worring about differents visuals?, to quering, setting or
> > disabling EDID support? will these drivers export sysfs
> > entries instead of control via ioctl's?
>
> I have some initial sysfs patches for the fb code that I've been sitting
> on in my trees. I was waiting for these patches to hit the mainline
> before bothering James and the rest of the world with them.
>
> But they don't export any of the ioctl stuff through the sysfs
> interface, but that would not be very hard to do at all if you want to.
> They just basically show the major/minor of the fb device, and point
> back to the proper place in the device tree where the fb device lives,
> which is all udev really needs right now.
Could you send me those patches :-)
>
> Will do. I like to also handle Video mode change. Even userland will like
> to know when a mode change happened. For userland a signal can be sent.
> This would be useful for someone in X that runs fbset in a Xterm. This
> hoses the X server. It would be nice if the X server would see the signal
> change and adapt to it. Fbset could in theory be used again to change a VC
> size. Yuck!!!! But it is what people want.
And for good reasons as we still have to deal with cases
where neither the driver nor modedb knows what the monitor supports...
Ben.
On Fri, Aug 15, 2003 at 11:37:21PM +0100, James Simmons wrote:
>
> > > Is there an API (or lib) to use framebuffers devices without
> > > worring about differents visuals?, to quering, setting or
> > > disabling EDID support? will these drivers export sysfs
> > > entries instead of control via ioctl's?
> >
> > I have some initial sysfs patches for the fb code that I've been sitting
> > on in my trees. I was waiting for these patches to hit the mainline
> > before bothering James and the rest of the world with them.
> >
> > But they don't export any of the ioctl stuff through the sysfs
> > interface, but that would not be very hard to do at all if you want to.
> > They just basically show the major/minor of the fb device, and point
> > back to the proper place in the device tree where the fb device lives,
> > which is all udev really needs right now.
>
> Could you send me those patches :-)
I'll clean them up, and port all fb drivers to them (I only did the ones
that I had hardware too), and send them to you next week. Do not let
them hold anything up that you can send to Linus though, they are not
that important at all right now.
thanks,
greg k-h
On Sat, Aug 16, 2003 at 01:42:32AM +0200, Benjamin Herrenschmidt wrote:
>
> >
> > Will do. I like to also handle Video mode change. Even userland will like
> > to know when a mode change happened. For userland a signal can be sent.
> > This would be useful for someone in X that runs fbset in a Xterm. This
> > hoses the X server. It would be nice if the X server would see the signal
> > change and adapt to it. Fbset could in theory be used again to change a VC
> > size. Yuck!!!! But it is what people want.
>
> And for good reasons as we still have to deal with cases
> where neither the driver nor modedb knows what the monitor supports...
It could be really cool if in sysfs be a file with
video modes, something like this:
1024x768x24@80
1024x768x24@60
800x600x24@60
600x400x16@75
and other file named current_mode (or something) with the
current setting, you just echo a value there and bingo,
a video mode change with the desired refresh rate, is that
hard? EDID and modedb can help us here.
Don't you think?
-solca
Hello,
James Simmons <[email protected]> wrote:
> Here is the latest fbdev BK drop. It is against 2.6.0-test3. Test it out
> and tell me your results. I like to do a code drop soon.
Thanks for this patch, it runs now quite nice on a RIVA TNT2. Is there
any special reason why you use soft_cursor in rivafb? I changed the
rivafb_cursor to the new code, maybe you have a look ;-)
-------------------------------------8<----------------------------------------------------------------
diff -Naur linux-2.6.0-test3/drivers/video/riva/fbdev.c linux-2.6.0-test3-sv/drivers/video/riva/fbdev.c
--- linux-2.6.0-test3/drivers/video/riva/fbdev.c 2003-08-16 07:47:20.000000000 +0200
+++ linux-2.6.0-test3-sv/drivers/video/riva/fbdev.c 2003-08-16 07:39:39.000000000 +0200
@@ -460,48 +460,11 @@
return (VGA_RD08(par->riva.PVIO, 0x3cc));
}
-static u8 byte_rev[256] = {
- 0x00, 0x80, 0x40, 0xc0, 0x20, 0xa0, 0x60, 0xe0,
- 0x10, 0x90, 0x50, 0xd0, 0x30, 0xb0, 0x70, 0xf0,
- 0x08, 0x88, 0x48, 0xc8, 0x28, 0xa8, 0x68, 0xe8,
- 0x18, 0x98, 0x58, 0xd8, 0x38, 0xb8, 0x78, 0xf8,
- 0x04, 0x84, 0x44, 0xc4, 0x24, 0xa4, 0x64, 0xe4,
- 0x14, 0x94, 0x54, 0xd4, 0x34, 0xb4, 0x74, 0xf4,
- 0x0c, 0x8c, 0x4c, 0xcc, 0x2c, 0xac, 0x6c, 0xec,
- 0x1c, 0x9c, 0x5c, 0xdc, 0x3c, 0xbc, 0x7c, 0xfc,
- 0x02, 0x82, 0x42, 0xc2, 0x22, 0xa2, 0x62, 0xe2,
- 0x12, 0x92, 0x52, 0xd2, 0x32, 0xb2, 0x72, 0xf2,
- 0x0a, 0x8a, 0x4a, 0xca, 0x2a, 0xaa, 0x6a, 0xea,
- 0x1a, 0x9a, 0x5a, 0xda, 0x3a, 0xba, 0x7a, 0xfa,
- 0x06, 0x86, 0x46, 0xc6, 0x26, 0xa6, 0x66, 0xe6,
- 0x16, 0x96, 0x56, 0xd6, 0x36, 0xb6, 0x76, 0xf6,
- 0x0e, 0x8e, 0x4e, 0xce, 0x2e, 0xae, 0x6e, 0xee,
- 0x1e, 0x9e, 0x5e, 0xde, 0x3e, 0xbe, 0x7e, 0xfe,
- 0x01, 0x81, 0x41, 0xc1, 0x21, 0xa1, 0x61, 0xe1,
- 0x11, 0x91, 0x51, 0xd1, 0x31, 0xb1, 0x71, 0xf1,
- 0x09, 0x89, 0x49, 0xc9, 0x29, 0xa9, 0x69, 0xe9,
- 0x19, 0x99, 0x59, 0xd9, 0x39, 0xb9, 0x79, 0xf9,
- 0x05, 0x85, 0x45, 0xc5, 0x25, 0xa5, 0x65, 0xe5,
- 0x15, 0x95, 0x55, 0xd5, 0x35, 0xb5, 0x75, 0xf5,
- 0x0d, 0x8d, 0x4d, 0xcd, 0x2d, 0xad, 0x6d, 0xed,
- 0x1d, 0x9d, 0x5d, 0xdd, 0x3d, 0xbd, 0x7d, 0xfd,
- 0x03, 0x83, 0x43, 0xc3, 0x23, 0xa3, 0x63, 0xe3,
- 0x13, 0x93, 0x53, 0xd3, 0x33, 0xb3, 0x73, 0xf3,
- 0x0b, 0x8b, 0x4b, 0xcb, 0x2b, 0xab, 0x6b, 0xeb,
- 0x1b, 0x9b, 0x5b, 0xdb, 0x3b, 0xbb, 0x7b, 0xfb,
- 0x07, 0x87, 0x47, 0xc7, 0x27, 0xa7, 0x67, 0xe7,
- 0x17, 0x97, 0x57, 0xd7, 0x37, 0xb7, 0x77, 0xf7,
- 0x0f, 0x8f, 0x4f, 0xcf, 0x2f, 0xaf, 0x6f, 0xef,
- 0x1f, 0x9f, 0x5f, 0xdf, 0x3f, 0xbf, 0x7f, 0xff,
-};
-
-static inline void reverse_order(u32 *l)
+static inline u32 reverse_order(u32 val)
{
- u8 *a = (u8 *)l;
- *a = byte_rev[*a], a++;
- *a = byte_rev[*a], a++;
- *a = byte_rev[*a], a++;
- *a = byte_rev[*a];
+return((val & 0x80808080) >> 7 | (val & 0x40404040) >> 5 | (val & 0x20202020) >> 3 | \
+ (val & 0x10101010) >> 1 | (val & 0x08080808) << 1 | (val & 0x04040404) << 3 | \
+ (val & 0x02020202) << 5 | (val & 0x01010101) << 7);
}
/* ------------------------------------------------------------------------- *
@@ -534,13 +497,14 @@
int i, j, k = 0;
u32 b, m, tmp;
+
for (i = 0; i < h; i++) {
- b = *((u32 *)data)++;
+
+ b = reverse_order(*((u32 *)data)++);
m = *((u32 *)mask)++;
- reverse_order(&b);
-
+
for (j = 0; j < w/2; j++) {
- tmp = 0;
+ tmp = 0;
#if defined (__BIG_ENDIAN)
if (m & (1 << 31)) {
fg |= 1 << 15;
@@ -565,7 +529,7 @@
tmp = (b & 1) ? fg : bg;
b >>= 1;
m >>= 1;
-
+
if (m & 1) {
fg |= 1 << 15;
bg |= 1 << 15;
@@ -573,10 +537,11 @@
tmp |= (b & 1) ? fg << 16 : bg << 16;
b >>= 1;
m >>= 1;
+
#endif
- writel(tmp, par->riva.CURSOR + k++);
- }
- k += (MAX_CURS - w)/2;
+ writel(tmp, par->riva.CURSOR + k++);
+ }
+ k += (MAX_CURS - w)/2;
}
}
@@ -1428,7 +1393,7 @@
const struct fb_image *image)
{
struct riva_par *par = (struct riva_par *) info->par;
- u32 fgx = 0, bgx = 0, width, tmp;
+ u32 fgx = 0, bgx = 0, width;
u8 *cdat = (u8 *) image->data;
volatile u32 *d;
int i, size;
@@ -1474,23 +1439,20 @@
width = (image->width + 31)/32;
size = width * image->height;
+
while (size >= 16) {
RIVA_FIFO_FREE(par->riva, Bitmap, 16);
- for (i = 0; i < 16; i++) {
- tmp = *((u32 *)cdat)++;
- reverse_order(&tmp);
- d[i] = tmp;
- }
+ for (i = 0; i < 16; i++)
+ d[i] = reverse_order(*((u32 *)cdat)++);
size -= 16;
- }
+ }
+
if (size) {
RIVA_FIFO_FREE(par->riva, Bitmap, size);
- for (i = 0; i < size; i++) {
- tmp = *((u32 *) cdat)++;
- reverse_order(&tmp);
- d[i] = tmp;
+ for (i = 0; i < size; i++)
+ d[i] = reverse_order(*((u32 *) cdat)++);
+
}
- }
}
/**
@@ -1509,9 +1471,17 @@
static int rivafb_cursor(struct fb_info *info, struct fb_cursor *cursor)
{
struct riva_par *par = (struct riva_par *) info->par;
+ unsigned int scan_align = info->pixmap.scan_align - 1;
+ unsigned int buf_align = info->pixmap.buf_align - 1;
+ u8 *dst = (u8 *) info->cursor.image.data;
+ unsigned int i, size, pitch;
u16 fg, bg;
- int i;
+ pitch = ((info->cursor.image.width + 7) >> 3) + scan_align;
+ pitch &= ~scan_align;
+ size = pitch * info->cursor.image.height + buf_align;
+ size &= ~buf_align;
+
par->riva.ShowHideCursor(&par->riva, 0);
if (cursor->set & FB_CUR_SETPOS) {
@@ -1540,36 +1510,37 @@
if (cursor->set & (FB_CUR_SETSHAPE | FB_CUR_SETCMAP)) {
u32 bg_idx = info->cursor.image.bg_color;
u32 fg_idx = info->cursor.image.fg_color;
- u8 *dat = (u8 *) info->cursor.image.data;
- u8 *msk = (u8 *) info->cursor.mask;
- u8 src[64];
-
switch (info->cursor.rop) {
case ROP_XOR:
- for (i = 0; i < info->sprite.size; i++)
- src[i] = dat[i] ^ msk[i];
+ for (i = 0; i < size; i++)
+ dst[i] ^= info->cursor.mask[i];
break;
case ROP_COPY:
default:
- for (i = 0; i < info->sprite.size; i++)
- src[i] = dat[i] & msk[i];
+ for (i = 0; i < size; i++)
+ dst[i] &= info->cursor.mask[i];
break;
}
bg = ((info->cmap.red[bg_idx] & 0xf8) << 7) |
((info->cmap.green[bg_idx] & 0xf8) << 2) |
- ((info->cmap.blue[bg_idx] & 0xf8) >> 3);
+ ((info->cmap.blue[bg_idx] & 0xf8) >> 3) | 0x8000;
fg = ((info->cmap.red[fg_idx] & 0xf8) << 7) |
((info->cmap.green[fg_idx] & 0xf8) << 2) |
- ((info->cmap.blue[fg_idx] & 0xf8) >> 3);
+ ((info->cmap.blue[fg_idx] & 0xf8) >> 3) | 0x8000;
par->riva.LockUnlock(&par->riva, 0);
- rivafb_load_cursor_image(par, dat, msk, bg, fg,
- info->cursor.image.width,
+
+ memset_io(par->riva.CURSOR, 0, MAX_CURS * MAX_CURS*2);
+
+ if(info->cursor.image.data)
+ rivafb_load_cursor_image(par, dst, info->cursor.mask, bg, fg, \
+ info->cursor.image.width, \
info->cursor.image.height);
- }
+ }
+
if (info->cursor.enable)
par->riva.ShowHideCursor(&par->riva, 1);
return 0;
@@ -1602,7 +1573,7 @@
.fb_fillrect = rivafb_fillrect,
.fb_copyarea = rivafb_copyarea,
.fb_imageblit = rivafb_imageblit,
- .fb_cursor = soft_cursor,
+ .fb_cursor = rivafb_cursor,
.fb_sync = rivafb_sync,
};
-----------------------------------------8<-----------------------------------------
--
Sven Schnelle, <[email protected]>
-----------------------------------------
James,
I am still seeing a lot of cursors being left behind. It is not a race
condition or anything -- in the TTY line editor, it happens about 50% of
the time when you press backspace.
What appears to be happening is the cursor is flashing twice as slowly
as the driver thinks it is, so of course it's wrong half the time when
it comes to erase the cursor.
The patch below fixes it for me.
Chris
--- a/drivers/video/softcursor.c 2003-08-16 11:39:51.000000000 -0400
+++ b/drivers/video/softcursor.c 2003-08-16 11:29:43.000000000 -0400
@@ -74,6 +74,12 @@
if (info->cursor.image.data)
info->fbops->fb_imageblit(info, &info->cursor.image);
+
+ if (!info->cursor.enable) {
+ for (i = 0; i < size; i++)
+ dst[i] ^= info->cursor.mask[i];
+ }
+
return 0;
}