2 more fbcon rotation bugs

2 more fbcon rotation bugs

[Knut Petersen]

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

Re: 2 more fbcon rotation bugs

[Antonino A. Daplas]

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

Re: 2 more fbcon rotation bugs

[Knut Petersen]

Antonino A. Daplas schrieb:

>>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

Re: 2 more fbcon rotation bugs

[Antonino A. Daplas]

Knut Petersen wrote:
> Antonino A. Daplas schrieb:
> 
>>> 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

Re: 2 more fbcon rotation bugs

[Antonino A. Daplas]

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

Re: 2 more fbcon rotation bugs

[Antonino A. Daplas]

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

Re: 2 more fbcon rotation bugs

[Knut Petersen]

>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

Re: Re: 2 more fbcon rotation bugs

[Geert Uytterhoeven]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=UTF-8, Size: 1276 bytes --]

On Sun, 20 Nov 2005, Knut Petersen wrote:
> > 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

Re: 2 more fbcon rotation bugs

[Antonino A. Daplas]

Knut Petersen wrote:
> 
>> 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

Re: 2 more fbcon rotation bugs

[Knut Petersen]

Hi Antonino,

>>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

Re: 2 more fbcon rotation bugs

[Antonino A. Daplas]

Knut Petersen wrote:
> Hi Antonino,
> 
>>> 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

Re: 2 more fbcon rotation bugs

[Knut Petersen]

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