From: Ulrich Eckhardt <eckhardt@satorlaser.com>
To: linux-mips@linux-mips.org
Subject: Re: [PATCH] au1100fb.c ported from 2.4 to 2.6
Date: Fri, 4 Feb 2005 14:18:47 +0100 [thread overview]
Message-ID: <200502041418.47589.eckhardt@satorlaser.com> (raw)
In-Reply-To: <1107511003.5266.11.camel@absolute.ascensit.com>
Christian wrote:
> First you have to modify the function au1100fb_setcolreg, add the switch
> case for 4bpp. Look in the Alchemy manual for the format of the palette
> in the 4 bpp case. Then look for my comment "TODO: 8bbp", put a switch
> and for pseudocolor like visual ... I think this is not even necessary.
Thanks, will look.
> More important is that you change the monitor type.
Yep, finding working parameters without real knowledge of what the registers
mean was the hardest part, but I have it working now.
> If you want I can
> send you privately a patch this weekend, but I just cannot assure it
> works, you have to test it and eventually contribute.
I'd appreciate that, thank you.
Currently I'm facing a different problem though, look at this code and the
bitmap it generates (4bpp):
unsigned long* fb = my_fb_info->fb_virt_start;
fb[0] = 0x0000000f; // *.......
fb[40] = 0x000000f0; // .*......
fb[80] = 0x000000ff; // **......
fb[120] = 0xf0000f00; // ..*....*
fb[160] = 0xff000f0f; // *.*...**
fb[200] = 0xfff00ff0; // .**..***
fb[240] = 0xffff0fff; // ***.****
To me, expecting the LSB to be part of the leftmost pixel is not really
surprising, but functions like cfb_fillrect() (or rather bitfill32() etc)
expect the order to be the other way around. I'm afraid that other
framebuffer functions also expect that, but I haven't gotten far enough to
test those. I only tested cfb_fillrect() and, seeing it fail, started looking
for answers... any idea?
I stumbled across another .. err .. 'feature': take a look at the appended
patch, in particular the handling of the mask for the first long, am I
dreaming or is this in fact handled wrongly in the current FB code? I'm a bit
confused, because the same mistake is made in pretty much every FB driver I
looked at.
Thanks
Uli
---
Index: cfbcopyarea.c
===================================================================
RCS file: /home/cvs/linux/drivers/video/cfbcopyarea.c,v
retrieving revision 1.10
diff -u -w -r1.10 cfbcopyarea.c
--- cfbcopyarea.c 12 Oct 2004 01:45:47 -0000 1.10
+++ cfbcopyarea.c 4 Feb 2005 13:11:16 -0000
@@ -70,7 +70,7 @@
} else {
// Multiple destination words
// Leading bits
- if (first) {
+ if (first != ~0UL) {
FB_WRITEL((FB_READL(src) & first) |
(FB_READL(dst) & ~first), dst);
@@ -223,7 +223,7 @@
} else {
// Multiple destination words
// Leading bits
- if (first) {
+ if (first != ~0UL) {
FB_WRITEL((FB_READL(src) & first) | (FB_READL(dst) & ~first), dst);
dst--;
src--;
Index: cfbfillrect.c
===================================================================
RCS file: /home/cvs/linux/drivers/video/cfbfillrect.c,v
retrieving revision 1.8
diff -u -w -r1.8 cfbfillrect.c
--- cfbfillrect.c 12 Oct 2004 01:45:47 -0000 1.8
+++ cfbfillrect.c 4 Feb 2005 13:11:16 -0000
@@ -142,7 +142,7 @@
} else {
// Multiple destination words
// Leading bits
- if (first) {
+ if (first != ~0UL) {
FB_WRITEL(comp(val, FB_READL(dst), first), dst);
dst++;
n -= BITS_PER_LONG-dst_idx;
@@ -166,7 +166,7 @@
// Trailing bits
if (last)
- FB_WRITEL(comp(val, FB_READL(dst), first), dst);
+ FB_WRITEL(comp(val, FB_READL(dst), last), dst);
}
}
@@ -197,7 +197,7 @@
} else {
// Multiple destination words
// Leading bits
- if (first) {
+ if (first != ~0UL) {
FB_WRITEL(comp(pat, FB_READL(dst), first), dst);
dst++;
pat = pat << left | pat >> right;
@@ -224,7 +224,7 @@
// Trailing bits
if (last)
- FB_WRITEL(comp(pat, FB_READL(dst), first), dst);
+ FB_WRITEL(comp(pat, FB_READL(dst), last), dst);
}
}
@@ -252,7 +252,7 @@
} else {
// Multiple destination words
// Leading bits
- if (first) {
+ if (first != ~0UL) {
dat = FB_READL(dst);
FB_WRITEL(comp(dat ^ val, dat, first), dst);
dst++;
@@ -287,7 +287,7 @@
// Trailing bits
if (last) {
dat = FB_READL(dst);
- FB_WRITEL(comp(dat ^ val, dat, first), dst);
+ FB_WRITEL(comp(dat ^ val, dat, last), dst);
}
}
}
@@ -320,7 +320,7 @@
} else {
// Multiple destination words
// Leading bits
- if (first) {
+ if (first != ~0UL) {
dat = FB_READL(dst);
FB_WRITEL(comp(dat ^ pat, dat, first), dst);
dst++;
@@ -354,7 +354,7 @@
// Trailing bits
if (last) {
dat = FB_READL(dst);
- FB_WRITEL(comp(dat ^ pat, dat, first), dst);
+ FB_WRITEL(comp(dat ^ pat, dat, last), dst);
}
}
}
next prev parent reply other threads:[~2005-02-04 13:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-12 9:50 [PATCH] au1100fb.c ported from 2.4 to 2.6 Christian
2005-02-02 9:05 ` Ulrich Eckhardt
2005-02-04 9:56 ` Christian
2005-02-04 13:18 ` Ulrich Eckhardt [this message]
2005-02-08 14:14 ` Ulrich Eckhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200502041418.47589.eckhardt@satorlaser.com \
--to=eckhardt@satorlaser.com \
--cc=linux-mips@linux-mips.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox