2 more fbcon rotation bugs

Hi Antonino,

For rotation values of 1 and 3 in combination with unusual font heights 
there are
serious cursor problems:

    standard 8x16 and arial 22x24: ok
    comic 16x26 and bitstream 16x30: broken as described below.

1: Load e.g. bitstream 16x30 font and switch to rotation 1.
2: At the bash prompt, type "asdf  > qwer" without the quotation marks 
and without
    hitting enter.
3: Try to delete the letters q,w,e,r and reenter them. Everything works 
fine.
4: Now place the cursor immediately behind the letter f and delete it. 
Everything ok.
5. Hit the key f to reenter that letter .... now something breaks:
    a: an f is inserted at the correct position
    b: an f flashes for a short period at the place of the first space, 
then it is overwritten
        by the correct space character and the blinking cursor
    c: the > at the right of the cursor is permanently overwritten with 
a blank and a
        frozen underline of the cursor, the line now reads asdf _ _ qwer.

Deleting and reinserting the other characters before the > gives similar 
results, e.g.
for the letter s the result is "asdd > qwer", the first d switching from 
s to d fast but
visible and with the blinking cursor, the 2nd d (that should be an f) 
permanently
underlined.

No problems are visible if only one string of letters (even a long one) 
is entered and
edited  at the bash prompt.

Any idea where to start? Can you reproduce the odd behaviour? My first 
idea was
to look into ccw_cursor() and cw_cursor(), but as there are no errors 
for long strings
if they do not contain spaces, > or other signs of a special meaning to 
bash, I suppose
that this is not the right/only place to start. My system is slow (Via 
Eden cpu, 533Mhz),
could it be that the bug is invisible on faster machines? ...

cu,
 Knut


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click

Knut Petersen wrote:

Hi Antonino,

For rotation values of 1 and 3 in combination with unusual font heights
there are
serious cursor problems:

   standard 8x16 and arial 22x24: ok
   comic 16x26 and bitstream 16x30: broken as described below.

1: Load e.g. bitstream 16x30 font and switch to rotation 1.
2: At the bash prompt, type "asdf  > qwer" without the quotation marks
and without
   hitting enter.
3: Try to delete the letters q,w,e,r and reenter them. Everything works
fine.
4: Now place the cursor immediately behind the letter f and delete it.
Everything ok.
5. Hit the key f to reenter that letter .... now something breaks:
   a: an f is inserted at the correct position
   b: an f flashes for a short period at the place of the first space,
then it is overwritten
       by the correct space character and the blinking cursor
   c: the > at the right of the cursor is permanently overwritten with a
blank and a
       frozen underline of the cursor, the line now reads asdf _ _ qwer.

Deleting and reinserting the other characters before the > gives similar
results, e.g.
for the letter s the result is "asdd > qwer", the first d switching from
s to d fast but
visible and with the blinking cursor, the 2nd d (that should be an f)
permanently
underlined.

No problems are visible if only one string of letters (even a long one)
is entered and
edited  at the bash prompt.

Any idea where to start? Can you reproduce the odd behaviour?

This one I cannot reproduce. Have you tried reproducing it with vesafb?
Any message in the log, such as a kernel oops?  Your description sounds
like a corruption of cursor->mask and cursor->image.data.

My first
idea was
to look into ccw_cursor() and cw_cursor(), but as there are no errors
for long strings
if they do not contain spaces, > or other signs of a special meaning to
bash, I suppose
that this is not the right/only place to start. My system is slow (Via
Eden cpu, 533Mhz),
could it be that the bug is invisible on faster machines? ...

You can also try enabling a non-blinking block cursor
(Documentation/VGA-softcursor.txt) to isolate the problem. With a
non-blinking block cursor, fbcon's cursor is disabled and vt.c's softcursor
takes over.  

You also said that the cursor becomes fixed.  You can comment out the call
to ops->cursor in fb_flashcursor in fbcon.c so you get a fixed cursor and
eliminate the cursor blink pathway from the debugging.

Tony


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click

Antonino A. Daplas schrieb:

quoted

For rotation values of 1 and 3 in combination with unusual font heights
there are
serious cursor problems:
   

This one I cannot reproduce. Have you tried reproducing it with vesafb?
Any message in the log, such as a kernel oops?  Your description sounds
like a corruption of cursor->mask and cursor->image.data.
 

I tried to reproduce it with vesafb ... vesafb does not show this bug. 
Reproducability with cyblafb
is 100%. But cyblafb does not provide cursor functions, so both really 
should show the same
behaviour, shouldn´t they? No messages in the log, no oops, no side 
effects. Screen is restored
to the correct display if the gpm mouse cursor or the normal cursor is 
moved to the wrong character
cell.

New bug: Vesafb & rotation does show a bug that is not present using 
cyblafb & rotation and the 16x30
bitstream font: When I start my favourite text editor sedt, the top row 
is coloured and contains some
status information. Line two is in a different colour. Those areas of 
line 1 drawn with the bitblit
functions are ok, but those areas drawn with the fillrect function are 
not completely coloured, the last
(maybe the 2 last, don´t know) pixel rows of the area that should be 
coloured are still black.

Additional bug: I am used to compile vesafb into the kernel and to load 
and remove the cyblafb
module during the developement process, switching to and from vesafb 
using con2fb. That´s still
possible with rotation == 0, but it locks the computer if at least one 
framebuffer is set to rotation 1.
I have not tested that for rotation == 2 or 3.

You can also try enabling a non-blinking block cursor
(Documentation/VGA-softcursor.txt) to isolate the problem. With a
non-blinking block cursor, fbcon's cursor is disabled and vt.c's softcursor
takes over.  

You also said that the cursor becomes fixed.  You can comment out the call
to ops->cursor in fb_flashcursor in fbcon.c so you get a fixed cursor and
eliminate the cursor blink pathway from the debugging.

Tony

 

As you cannot reproduce the cursor/delete bug, I´ll try to find the 
cause and to fix it then. Please
have a look at the other bugs.

cu,
 Knut





-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click

Knut Petersen wrote:

Antonino A. Daplas schrieb:

quoted

quoted

For rotation values of 1 and 3 in combination with unusual font heights
there are
serious cursor problems:
  

This one I cannot reproduce. Have you tried reproducing it with vesafb?
Any message in the log, such as a kernel oops?  Your description sounds
like a corruption of cursor->mask and cursor->image.data.
 

I tried to reproduce it with vesafb ... vesafb does not show this bug.
Reproducability with cyblafb
is 100%. But cyblafb does not provide cursor functions, so both really
should show the same
behaviour, shouldn´t they? 

soft_cursor is just a wrapper to fb_imageblit, so behavior will depend
on the drivers implementation.

No messages in the log, no oops, no side

effects. Screen is restored
to the correct display if the gpm mouse cursor or the normal cursor is
moved to the wrong character
cell.

New bug: Vesafb & rotation does show a bug that is not present using
cyblafb & rotation and the 16x30
bitstream font: When I start my favourite text editor sedt, the top row
is coloured and contains some
status information. Line two is in a different colour. Those areas of
line 1 drawn with the bitblit
functions are ok, but those areas drawn with the fillrect function are
not completely coloured, the last
(maybe the 2 last, don´t know) pixel rows of the area that should be
coloured are still black.

Yes, I think I mentioned this in the changelog, that there might be a 
bug in the generic fillrect.  I haven't looked at it yet.

Additional bug: I am used to compile vesafb into the kernel and to load
and remove the cyblafb
module during the developement process, switching to and from vesafb
using con2fb. That´s still
possible with rotation == 0, but it locks the computer if at least one
framebuffer is set to rotation 1.

Okay, will check on this.

Tony


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click

Knut Petersen wrote:

Antonino A. Daplas schrieb:

Additional bug: I am used to compile vesafb into the kernel and to load
and remove the cyblafb
module during the developement process, switching to and from vesafb
using con2fb. That´s still
possible with rotation == 0, but it locks the computer if at least one
framebuffer is set to rotation 1.
I have not tested that for rotation == 2 or 3.

I tried with savagefb and vga16fb.  vga16fb is mapped to all consoles with
fbcon=map:1. Set different tty's at different angles of rotation.  Then
used con2fbmap to make savagefb take over the entire console. I don't
experience any hang, and all the consoles are properly rotated at their
respective angles.

I also tried mapping vga16fb back.  The resulting screen becomes corrupted
of course, but no hang.  I can map savagefb back again without problems.

(The only bad thing that happened is when I tried switching consoles when
vga16fb owns the console and the display is corrupted.  The machine
reboots.)
 
Tony


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click

Knut Petersen wrote:

Antonino A. Daplas schrieb:

New bug: Vesafb & rotation does show a bug that is not present using
cyblafb & rotation and the 16x30
bitstream font: When I start my favourite text editor sedt, the top row
is coloured and contains some
status information. Line two is in a different colour. Those areas of
line 1 drawn with the bitblit
functions are ok, but those areas drawn with the fillrect function are
not completely coloured, the last
(maybe the 2 last, don´t know) pixel rows of the area that should be
coloured are still black.

It seems that cfbfillrect and cfbcopyarea were written in a big-endian
machine (if I'm not mistaken, by Geert on m68k?) as unaligned access in
little endian produces this bug.

Try this patch and let me know if this solves your problem.

Tony

diff --git a/drivers/video/cfbcopyarea.c b/drivers/video/cfbcopyarea.c
index cdc7157..dc7e210 100644
--- a/drivers/video/cfbcopyarea.c
+++ b/drivers/video/cfbcopyarea.c

@@ -64,8 +64,8 @@ bitcpy(unsigned long __iomem *dst, int d
 	int const shift = dst_idx-src_idx;
 	int left, right;
 
-	first = ~0UL >> dst_idx;
-	last = ~(~0UL >> ((dst_idx+n) % bits));
+	first = SHIFT_HIGH(~0UL, dst_idx);
+	last = ~(SHIFT_HIGH(~0UL, (dst_idx+n) % bits));
 
 	if (!shift) {
 		// Same alignment for source and dest

@@ -216,8 +216,8 @@ bitcpy_rev(unsigned long __iomem *dst, i
 
 	shift = dst_idx-src_idx;
 
-	first = ~0UL << (bits - 1 - dst_idx);
-	last = ~(~0UL << (bits - 1 - ((dst_idx-n) % bits)));
+	first = SHIFT_LOW(~0UL, bits - 1 - dst_idx);
+	last = ~(SHIFT_LOW(~0UL, bits - 1 - ((dst_idx-n) % bits)));
 
 	if (!shift) {
 		// Same alignment for source and dest

diff --git a/drivers/video/cfbfillrect.c b/drivers/video/cfbfillrect.c
index 167d931..495cdaf 100644
--- a/drivers/video/cfbfillrect.c
+++ b/drivers/video/cfbfillrect.c

@@ -110,8 +110,8 @@ bitfill_aligned(unsigned long __iomem *d
 	if (!n)
 		return;
 
-	first = ~0UL >> dst_idx;
-	last = ~(~0UL >> ((dst_idx+n) % bits));
+	first = SHIFT_HIGH(~0UL, dst_idx);
+	last = ~(SHIFT_HIGH(~0UL, (dst_idx+n) % bits));
 
 	if (dst_idx+n <= bits) {
 		// Single word

@@ -167,8 +167,8 @@ bitfill_unaligned(unsigned long __iomem 
 	if (!n)
 		return;
 
-	first = ~0UL >> dst_idx;
-	last = ~(~0UL >> ((dst_idx+n) % bits));
+	first = SHIFT_HIGH(~0UL, dst_idx);
+	last = ~(SHIFT_HIGH(~0UL, (dst_idx+n) % bits));
 
 	if (dst_idx+n <= bits) {
 		// Single word

@@ -221,8 +221,8 @@ bitfill_aligned_rev(unsigned long __iome
 	if (!n)
 		return;
 
-	first = ~0UL >> dst_idx;
-	last = ~(~0UL >> ((dst_idx+n) % bits));
+	first = SHIFT_HIGH(~0UL, dst_idx);
+	last = ~(SHIFT_HIGH(~0UL, (dst_idx+n) % bits));
 
 	if (dst_idx+n <= bits) {
 		// Single word

@@ -290,8 +290,8 @@ bitfill_unaligned_rev(unsigned long __io
 	if (!n)
 		return;
 
-	first = ~0UL >> dst_idx;
-	last = ~(~0UL >> ((dst_idx+n) % bits));
+	first = SHIFT_HIGH(~0UL, dst_idx);
+	last = ~(SHIFT_HIGH(~0UL, (dst_idx+n) % bits));
 
 	if (dst_idx+n <= bits) {
 		// Single word

diff --git a/drivers/video/cfbimgblt.c b/drivers/video/cfbimgblt.c
index 7a01742..6a78340 100644
--- a/drivers/video/cfbimgblt.c
+++ b/drivers/video/cfbimgblt.c

@@ -76,18 +76,6 @@ static u32 cfb_tab32[] = {
 #define FB_WRITEL fb_writel
 #define FB_READL  fb_readl
 
-#if defined (__BIG_ENDIAN)
-#define LEFT_POS(bpp)          (32 - bpp)
-#define SHIFT_HIGH(val, bits)  ((val) >> (bits))
-#define SHIFT_LOW(val, bits)   ((val) << (bits))
-#define BIT_NR(b)              (7 - (b))
-#else
-#define LEFT_POS(bpp)          (0)
-#define SHIFT_HIGH(val, bits)  ((val) << (bits))
-#define SHIFT_LOW(val, bits)   ((val) >> (bits))
-#define BIT_NR(b)              (b)
-#endif
-
 static inline void color_imageblit(const struct fb_image *image, 
 				   struct fb_info *p, u8 __iomem *dst1, 
 				   u32 start_index,

diff --git a/include/linux/fb.h b/include/linux/fb.h
index 04a58f3..e44950e 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h

@@ -817,6 +817,18 @@ struct fb_info {
 
 #endif
 
+#if defined (__BIG_ENDIAN)
+#define LEFT_POS(bpp)          (32 - bpp)
+#define SHIFT_HIGH(val, bits)  ((val) >> (bits))
+#define SHIFT_LOW(val, bits)   ((val) << (bits))
+#define BIT_NR(b)              (7 - (b))
+#else
+#define LEFT_POS(bpp)          (0)
+#define SHIFT_HIGH(val, bits)  ((val) << (bits))
+#define SHIFT_LOW(val, bits)   ((val) >> (bits))
+#define BIT_NR(b)              (b)
+#endif
+
     /*
      *  `Generic' versions of the frame buffer device operations
      */


-------------------------------------------------------

This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click

It seems that cfbfillrect and cfbcopyarea were written in a big-endian
machine (if I'm not mistaken, by Geert on m68k?) as unaligned access in
little endian produces this bug.

 

That patch set fixes my problems with vesafb. For the tested subset of 
possible
font dimensions and rotation values everything seems to be ok now. But maybe
someone with a  big-endian machine should also verify the code.

Isn´t it amazing that code as old as this still contains undetected bugs?

Is there anything like a framebuffer test suite that could be used for a 
quick verification
of especially the seldom used features?

btw: my favourite text editor sedt fails if the number of lines exceeds 
an internal
limit hit by rotation == 1 or 3 and small fonts, but it complains that 
it cannot read
its perfectly readable initialization file in that case ...  I wonder if 
there are more
applications like that.

cu,
 Knut



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click

On Sun, 20 Nov 2005, Knut Petersen wrote:

quoted

It seems that cfbfillrect and cfbcopyarea were written in a big-endian
machine (if I'm not mistaken, by Geert on m68k?) as unaligned access in
little endian produces this bug.
 

That patch set fixes my problems with vesafb. For the tested subset of
possible
font dimensions and rotation values everything seems to be ok now. But maybe
someone with a  big-endian machine should also verify the code.

Isn�t it amazing that code as old as this still contains undetected bugs?

It's not _that_ old, it was written in the 2.5 timeframe ;-)
And it's about corner cases. Rotation opens up some parts of the code that were
never used with 8x8, 8x16, and 12x22 fonts.

Is there anything like a framebuffer test suite that could be used for a quick
verification
of especially the seldom used features?

There exists fbtest, but it doesn't test the internal drawing routines.

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

Knut Petersen wrote:

quoted

It seems that cfbfillrect and cfbcopyarea were written in a big-endian
machine (if I'm not mistaken, by Geert on m68k?) as unaligned access in
little endian produces this bug.

 

That patch set fixes my problems with vesafb. For the tested subset of
possible
font dimensions and rotation values everything seems to be ok now. But
maybe
someone with a  big-endian machine should also verify the code.

In big-endian, the original code gets compiled, so there would be no
regressions.  But does the original code work on them? I don't know yet.

Isn´t it amazing that code as old as this still contains undetected bugs?

It's quite hard to trigger this bug in an unrotated display because the
usual combination of fontwidths and bpp's typically results in 32-bit
aligned access. And even if the bug is triggered, it is very difficult to
detect as the result will be random pixels at the end of a row of text
which the cursor will overwrite eventually anyway.

Tony

PS: Someone did report before that cfbcopyarea and cfbfillrect does not work
correctly at bpp of 24, but I did not look into it then as I was too lazy
to create a test :-).




-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click

Hi Antonino,

quoted

Any idea where to start? Can you reproduce the odd behaviour?
   

This one I cannot reproduce. Have you tried reproducing it with vesafb?
Any message in the log, such as a kernel oops?  Your description sounds
like a corruption of cursor->mask and cursor->image.data.
 

I found the bug, it is specific to cyblafb.

 The problem is that the 16x30 font causes the cyblafb imageblit to fall 
back to
cfb_imageblit for rotation 1 and 3 while the accelerated copyarea 
function is
still used. That breaks the private sync mechanism of cyblafb and causes 
the
erroneous behaviour.

 I´ll publish a patch soon.

cu,
 Knut


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click

Knut Petersen wrote:

Hi Antonino,

quoted

quoted

Any idea where to start? Can you reproduce the odd behaviour?
  

This one I cannot reproduce. Have you tried reproducing it with vesafb?
Any message in the log, such as a kernel oops?  Your description sounds
like a corruption of cursor->mask and cursor->image.data.
 

I found the bug, it is specific to cyblafb.

The problem is that the 16x30 font causes the cyblafb imageblit to fall
back to
cfb_imageblit for rotation 1 and 3 while the accelerated copyarea
function is
still used. That breaks the private sync mechanism of cyblafb and causes
the
erroneous behaviour.

Shouldn't the accelerator be intelligent enough to handle bitmaps with
variable widths?  Will something like the one attached work?

Tony

diff --git a/drivers/video/cyblafb.c b/drivers/video/cyblafb.c
index 03fbe83..175f4d4 100644
--- a/drivers/video/cyblafb.c
+++ b/drivers/video/cyblafb.c

@@ -364,17 +364,12 @@ static void cyblafb_imageblit(struct fb_
 			      const struct fb_image *image)
 {
 
-	u32 fgcol, bgcol;
-
-	int i;
+	u32 fgcol, bgcol, *data = (u32 *) image->data;
 	int bpp = info->var.bits_per_pixel;
 	int index = 0;
-	int index_end=image->height * image->width / 8;
-	int width_dds=image->width / 32;
-	int width_dbs=image->width % 32;
 
-	if (image->depth != 1 || bpp < 8 || bpp > 32 || bpp % 8 != 0 ||
-	    image->width % 8 != 0 || image->width == 0 || image->height == 0) {
+	if (image->depth != 1 || bpp < 8 || bpp > 32 ||
+	    image->width == 0 || image->height == 0) {
 		cfb_imageblit(info,image);
 		return;
 	}

@@ -403,32 +398,18 @@ static void cyblafb_imageblit(struct fb_
 
 	cyblafb_sync(info);
 
+	index = (image->width + 31) & ~31;
+	index *= image->height;
+	index >>= 5;
+
 	out32(GE60,fgcol);
 	out32(GE64,bgcol);
 	out32(GE44,0xa0000000 | 1<<20 | 1<<19);
 	out32(GE08,point(image->dx,image->dy));
 	out32(GE0C,point(image->dx+image->width-1,image->dy+image->height-1));
 
-	while(index < index_end) {
-		const char *p = image->data + index;
-		for(i=0;i<width_dds;i++) {
-			out32(GE9C,*(u32*)p);
-			p+=4;
-			index+=4;
-		}
-		switch(width_dbs) {
-		case 0: break;
-		case 8:	out32(GE9C,*(u8*)p);
-			index+=1;
-			break;
-		case 16: out32(GE9C,*(u16*)p);
-			index+=2;
-			break;
-		case 24: out32(GE9C,*(u16*)p | *(u8*)(p+2)<<16);
-			index+=3;
-			break;
-		}
-	}
+	while (index--)
+		out32(GE9C, *data++);
 }
 
 //==========================================================

@@ -1319,6 +1300,17 @@ static int __devinit cybla_pci_probe(str
 
 	fb_alloc_cmap(&info->cmap,256,0);
 
+	info->pixmap.addr = kmalloc(8 * 1024, GFP_KERNEL);
+	
+	if (!info->pixmap.addr)
+		goto errout_pixmap;
+
+	info->pixmap.scan_align = 4;
+	info->pixmap.buf_align = 4;
+	info->pixmap.access_align = 32;
+	info->pixmap.size = 8 * 1024;
+	info->pixmap.flags = FB_PIXMAP_SYSTEM;
+
 	if (register_framebuffer(info)) {
 		output("Could not register CyBla framebuffer\n");
 		goto errout_register;

@@ -1333,6 +1325,8 @@ static int __devinit cybla_pci_probe(str
 	return 0;
 
  errout_register:
+	kfree(info->pixmap.addr);
+ errout_pixmap:
  errout_findmode:
 	iounmap(info->screen_base);
  errout_smem_remap:

@@ -1362,6 +1356,7 @@ static void __devexit cybla_pci_remove(s
 	release_mem_region(info->fix.smem_start,info->fix.smem_len);
 	release_mem_region(info->fix.mmio_start,info->fix.mmio_len);
 	fb_dealloc_cmap(&info->cmap);
+	kfree(info->pixmap.addr);
 	framebuffer_release(info);
 	output("CyblaFB version %s normal exit.\n",VERSION);
 }


-------------------------------------------------------

This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click

Antonino A. Daplas schrieb:

Shouldn't the accelerator be intelligent enough to handle bitmaps with
variable widths?  Will something like the one attached work?

 

Well, the accelerator can handle it, but it needs some precautions. Also 
xres != vxres
is possible, although it is currently disabled as I was too lazy to put 
work in an
unused feature. But now there is the rotation code that can benefit from 
x-panning,
and so it will be included soon.

cu,
 Knut


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click