linux-fbdev-users — Generic mailing list for users of frame buffers

Re: [Linux-fbdev-users] Setting colors on atyfb framebuffer console.

[Antonino A. D. <ad...@gm...>]

On Sat, 2007-10-20 at 00:26 -0400, cga2000 wrote:
> On Tue, Oct 16, 2007 at 04:35:25AM EDT, Antonino A. Daplas wrote:
> > On Mon, 2007-10-15 at 19:04 -0400, cga2000 wrote:
> > > On Mon, Oct 15, 2007 at 10:51:20AM EDT, Antonino A. Daplas wrote:
> 
> [..]
> 
> Hello Tony,
> 
> I have finally gotten around to building a 2.6.23 kernel.  I tried to
> change my foreground/background colors via setterm without any effect.
> 
> > > > /sys/module/vt/parameters/default_blu|default_grn|default_red
> 
> I do have this directory now that I have upgraded to a the more recent
> kernel, but I am unsure how I should use these files.
> 

Each has 16 entries in decimal format standing for the red
(default_red), green (default_grn) and blue (default_blu) part of the
color. I'll be using hexadecimal from here on, since that is easier to
understand.

So the first entry (index 0) is 0x00 for red, 0x00 for green and 0x00
for blue. If you combine them as RGB, you get 0x000000 (black). Index 0
(which is black by default) is the default bacground color. Entry 8
(index 7), which is RGB 0xaaaaaa (light gray) is the default foreground
color.

If you want to change the background color from black to blue:

1. cat /sys/module/vt/parameters/default_blu > blue.txt
2. change the first entry from 0 to 255,
3. echo blue.txt > /sys/module/vt/parameters/default_blu
4. Type 'reset' to reset the terminal.
6. You should not have a light gray text on a blue background.

Tony

Re: [Linux-fbdev-users] Setting colors on atyfb framebuffer console.

[cga2000 <cg...@op...>]

On Tue, Oct 16, 2007 at 04:35:25AM EDT, Antonino A. Daplas wrote:
> On Mon, 2007-10-15 at 19:04 -0400, cga2000 wrote:
> > On Mon, Oct 15, 2007 at 10:51:20AM EDT, Antonino A. Daplas wrote:

[..]

Hello Tony,

I have finally gotten around to building a 2.6.23 kernel.  I tried to
change my foreground/background colors via setterm without any effect.

> > > /sys/module/vt/parameters/default_blu|default_grn|default_red

I do have this directory now that I have upgraded to a the more recent
kernel, but I am unsure how I should use these files.

Thanks,
cga

[Linux-fbdev-users] radeonfb support for Sapphire X550 Silent

[Jakub Z. <dar...@da...>]

Hi,

I've got Sapphire X550 Silent (RV370) graphic card (1002:5b63)
This card is not supported by radeonfb (but xf86-video-ati has got
no problems with this card)
radeonfb support many other RV370 card so I tried some
kernel-hacking.
There is already entry for this card in ati_ids.h (PCI_CHIP_RV370_5B63)
So I've just add entry in radeon_base.c
        CHIP_DEF(PCI_CHIP_RV370_5B63,   RV380,  CHIP_HAS_CRTC2),

I've checked also xf86-video-ati sources if my card is handled in any
special way.
#v+
    case PCI_CHIP_RV370_5B60:
    case PCI_CHIP_RV370_5B62:
    case PCI_CHIP_RV370_5B63:
    case PCI_CHIP_RV370_5B64:
    case PCI_CHIP_RV370_5B65:
        info->ChipFamily = CHIP_FAMILY_RV380;
        break;
#v-
I've found only these, so I assumed than no, 
I recompiled kernel, rebooted, and framebuffer works.

However kernel is unstable, my machine especially running vim (Huh!)
restarts. I see some deadlock before reboot, it last for about 3-4s.
However if I don't run vim it works pretty good (read: it won't reboot)
(And please don't write about changing my $EDITOR ;>)
Yep I know it's strange (or maybe I just incorrectly test it)
Several running of dmesg won't reboot machine.

I really don't know how to debug, because I think it's reboot generated
by hardware and not by kernel (kernel.panic sysctl value is set to 0) 
and I'd also commented out emergency_restart() code.

If you have idea what cause restarts, or how I can debug it.  I'd be pleased.

In attachment log of radeonfb_pci_register.
(I don't have more logs connected with radeonfb from kernel log)

Also I include some linse from my .config 
(I think most important lines, if you want whole I'll send it)

#v+
# Linux kernel version: 2.6.23
CONFIG_X86_64=y
CONFIG_MTRR=y
CONFIG_FB_RADEON=y
CONFIG_FB_RADEON_I2C=y
CONFIG_FB_RADEON_DEBUG=y
#v-

Re: [Linux-fbdev-users] Setting colors on atyfb framebuffer console.

[cga2000 <cg...@op...>]

On Tue, Oct 16, 2007 at 04:35:25AM EDT, Antonino A. Daplas wrote:

[..]

> It's a 2.6.21 or 2.6.22 feature.

OK.

Will upgrade asap.  

Here's dmesg just in case:

[07:52:11][gavron@turki:~]$ dmesg | g atyfb
(standard input):atyfb: using auxiliary register aperture
(standard input):atyfb: 3D RAGE Mobility P/M (Mach64 LM, AGP 2x) [0x4c4d rev 0x64]
(standard input):atyfb: Mach64 BIOS is located at c0000, mapped at c00c0000.
(standard input):atyfb: BIOS frequency table:
(standard input):atyfb: PCLK_min_freq 984, PCLK_max_freq 23600, ref_freq 2950, ref_divider 64
(standard input):atyfb: MCLK_pwd 4200, MCLK_max_freq 8300, XCLK_max_freq 12500, SCLK_freq 5000
(standard input):atyfb: BIOS contains driver information table.
(standard input):atyfb: colour active matrix monitor detected: IBM ITSX93
(standard input):atyfb:        id=6, 1400x1050 pixels, 262144 colours (LT mode)
(standard input):atyfb:        supports refresh rates [60], default 60 Hz
(standard input):atyfb:        LCD CRTC parameters: 108.28  1400 1448 1560 1688  1050 1050 1053 1066
(standard input):atyfb:                           : 9259 128 1400 48 112 13 1050 0 3
(standard input):atyfb: 8M SGRAM (1:1), 29.498928 MHz XTAL, 236 MHz PLL, 83 Mhz MCLK, 125 MHz XCLK
(standard input):atyfb: fb0: ATY Mach64 frame buffer device on PCI

Thanks,
cga

Re: [Linux-fbdev-users] Setting colors on atyfb framebuffer console.

[Antonino A. D. <ad...@gm...>]

On Mon, 2007-10-15 at 19:04 -0400, cga2000 wrote:
> On Mon, Oct 15, 2007 at 10:51:20AM EDT, Antonino A. Daplas wrote:
> > On Mon, 2007-10-15 at 07:53 -0400, cga2000 wrote:
> > > On Mon, Oct 15, 2007 at 12:43:35AM EDT, Antonino A. Daplas wrote:
> > > > On Sun, 2007-10-14 at 19:24 -0400, cga2000 wrote:
> > 
> > > > And let us know what kind of driver you are using.
> > > 
> > > I have video=atyfb:1400x1050 in my grub boot command.
> > > 
> > > The card is a mach64.
> > > 
> > 
> > This has to be a bug if your atyfb can't even show the console colors
> > properly. I'll CC some people.
> 
> Thank you for your interest.
> 
> > Can you post your dmesg and fbset -i?
> 
> Here's the output of fbset -i:
> 
> mode "1400x1050-60"
>     # D: 107.701 MHz, H: 63.804 kHz, V: 59.853 Hz
>     geometry 1400 1050 1400 5980 8
>     timings 9285 128 48 13 0 112 3
>     accel true
>     rgba 8/0,8/0,8/0,0/0
> endmode
> 
> Frame buffer device information:
>     Name        : ATY Mach64
>     Address     : 0xfd000000
>     Size        : 8384512
>     Type        : PACKED PIXELS
>     Visual      : PSEUDOCOLOR
>     XPanStep    : 8
>     YPanStep    : 1
>     YWrapStep   : 0
>     LineLength  : 1400
>     MMIO Address: 0xfc000000
>     MMIO Size   : 2048
>     Accelerator : ATI Mach64GT
> 
> What does the rgba line mean?
> 

red|green|blue|alpha length/offset


> As to dmesg, could you be a bit more specific?
> 

Just the atyfb messages.

> I don't want to spam the list with unrelated material.
> 
> Would you want the dmesg log immediately after a (re)boot?

Anytime, doesn't matter.

> 
> If you need the entire dmesg, I'll put it up some place on the web,
> hopefully tomorrow.
> 
> > If you're using a recent kernel, try tinkering with
> 
> linux 2.6.20 .. which is pretty recent?
> 
> > /sys/module/vt/parameters/default_blu|default_grn|default_red
> 
> Hmm .. I don't seem to have anything called default_blu on this machine
> and no vt directory in the /sys/module tree.
> 
> Would this be a clue?
> 
> > The above will show you the colors of the console palette, which you can
> > also customize anytime.
> 
> Interesting.  When I have the time I would like to change the default
> colors to something a bit more interesting -- both in the console and
> in xterm for the sake of applications that do not support 256 colors.
> 

It's a 2.6,21 or 2.6.22 feature.

Tony

Re: [Linux-fbdev-users] Setting colors on atyfb framebuffer console.

[cga2000 <cg...@op...>]

On Mon, Oct 15, 2007 at 10:51:20AM EDT, Antonino A. Daplas wrote:
> On Mon, 2007-10-15 at 07:53 -0400, cga2000 wrote:
> > On Mon, Oct 15, 2007 at 12:43:35AM EDT, Antonino A. Daplas wrote:
> > > On Sun, 2007-10-14 at 19:24 -0400, cga2000 wrote:
> 
> > > And let us know what kind of driver you are using.
> > 
> > I have video=atyfb:1400x1050 in my grub boot command.
> > 
> > The card is a mach64.
> > 
> 
> This has to be a bug if your atyfb can't even show the console colors
> properly. I'll CC some people.

Thank you for your interest.

> Can you post your dmesg and fbset -i?

Here's the output of fbset -i:

mode "1400x1050-60"
    # D: 107.701 MHz, H: 63.804 kHz, V: 59.853 Hz
    geometry 1400 1050 1400 5980 8
    timings 9285 128 48 13 0 112 3
    accel true
    rgba 8/0,8/0,8/0,0/0
endmode

Frame buffer device information:
    Name        : ATY Mach64
    Address     : 0xfd000000
    Size        : 8384512
    Type        : PACKED PIXELS
    Visual      : PSEUDOCOLOR
    XPanStep    : 8
    YPanStep    : 1
    YWrapStep   : 0
    LineLength  : 1400
    MMIO Address: 0xfc000000
    MMIO Size   : 2048
    Accelerator : ATI Mach64GT

What does the rgba line mean?

As to dmesg, could you be a bit more specific?

I don't want to spam the list with unrelated material.

Would you want the dmesg log immediately after a (re)boot?

If you need the entire dmesg, I'll put it up some place on the web,
hopefully tomorrow.

> If you're using a recent kernel, try tinkering with

linux 2.6.20 .. which is pretty recent?

> /sys/module/vt/parameters/default_blu|default_grn|default_red

Hmm .. I don't seem to have anything called default_blu on this machine
and no vt directory in the /sys/module tree.

Would this be a clue?

> The above will show you the colors of the console palette, which you can
> also customize anytime.

Interesting.  When I have the time I would like to change the default
colors to something a bit more interesting -- both in the console and
in xterm for the sake of applications that do not support 256 colors.

Thanks,
cga

Re: [Linux-fbdev-users] Setting colors on atyfb framebuffer console.

[Antonino A. D. <ad...@gm...>]

On Mon, 2007-10-15 at 07:53 -0400, cga2000 wrote:
> On Mon, Oct 15, 2007 at 12:43:35AM EDT, Antonino A. Daplas wrote:
> > On Sun, 2007-10-14 at 19:24 -0400, cga2000 wrote:

> > And let us know what kind of driver you are using.
> 
> I have video=atyfb:1400x1050 in my grub boot command.
> 
> The card is a mach64.
> 

This has to be a bug if your atyfb can't even show the console colors
properly. I'll CC some people.

Can you post your dmesg and fbset -i?

If you're using a recent kernel, try tinkering with

/sys/module/vt/parameters/default_blu|default_grn|default_red

The above will show you the colors of the console palette, which you can
also customize anytime.

Tony

Re: [Linux-fbdev-users] Setting colors on atyfb framebuffer console.

[cga2000 <cg...@op...>]

On Mon, Oct 15, 2007 at 12:43:35AM EDT, Antonino A. Daplas wrote:
> On Sun, 2007-10-14 at 19:24 -0400, cga2000 wrote:
> > I just had to replace the display on an old laptop and I'm trying to
> > figure out if color rendering is correct.
> > 
> > I tried setterm to set the background to black and foreground to white
> > on the linux console but this doesn't seem to be doing anything.
> > 
> > I still have what looks to be pale gray text on a dark gray background.
> > 
> > Is there any way I can permanently change this to black & white?
> > 
> 
> Try setterm -blink on | off

I spent some time with setterm. 

The -blink on|off flag does not do anything that I could see.

I also tried setterm ulcolor bright blue followed by man setterm.

Sure enough the underlined parts of the man page became a nice bright
blue.

I also tried escape sequences such as echo "this text is a
nice whatever color" and "this text .." did come out the requested
color.

But this last method only changed the colors for the duration of the
"echo".

Looks like the display of the bash prompt resets my display to the
default drab grey on black (or dark grey .. I'm not sure".

OTOH -inversescreen on does change the display to black over pale grey.

What I can't figure out is how to set the foreground and background to
something else than the default permanently.  A bit like "xterm -fg
color -bg othercolor".

Not sure this is possible.

> And let us know what kind of driver you are using.

I have video=atyfb:1400x1050 in my grub boot command.

The card is a mach64.

> Tony

Thanks,
cga

Re: [Linux-fbdev-users] Setting colors on atyfb framebuffer console.

[Antonino A. D. <ad...@gm...>]

On Sun, 2007-10-14 at 19:24 -0400, cga2000 wrote:
> I just had to replace the display on an old laptop and I'm trying to
> figure out if color rendering is correct.
> 
> I tried setterm to set the background to black and foreground to white
> on the linux console but this doesn't seem to be doing anything.
> 
> I still have what looks to be pale gray text on a dark gray background.
> 
> Is there any way I can permanently change this to black & white?
> 

Try setterm -blink on | off

And let us know what kind of driver you are using.

Tony

[Linux-fbdev-users] Setting colors on atyfb framebuffer console.

[cga2000 <cg...@op...>]

I just had to replace the display on an old laptop and I'm trying to
figure out if color rendering is correct.

I tried setterm to set the background to black and foreground to white
on the linux console but this doesn't seem to be doing anything.

I still have what looks to be pale gray text on a dark gray background.

Is there any way I can permanently change this to black & white?

Thanks,
cga

Re: [Linux-fbdev-users] [PATCH] Framebuffer copyarea function taught to fully support swapped pixel order in bytes

[Antonino A. D. <ad...@gm...>]

On Tue, 2007-10-09 at 13:12 +0200, Pavel Pisa wrote:
> This correct case, when source and destination X coordinates difference is not
> multiple of pixels in byte. This is probably rare case, but this case should be
> supported for completeness.
> 
> Reorganization of FB_READL and FB_WRITEL calls results in code size decrease
> for normal build without swapping support and size with support enabled
> is reasonable too.
> 
> Signed-off-by: Pavel Pisa <pi...@cm...>
> 
> --
> 
> Hello Tony,
> 
> thanks for forwarding two patches to MM tree.
>   fbdev-support-for-byte-reversed-framebuffer-formats.patch
>   imxfb-fast-read-flag-and-nonstandard-field-configurable.patch
> 
> What are yours plans with the third one. Do you think, that it
> can fit in 2.6.24 merge window or you want to push changes
> incremental and delay it for 2.6.25.

I can push this for 2.6.24.

>  Have you found time to test
> it on your setup?

Yes, I did. I haven't encountered any bugs yet, nor any significant
slowdown with my setup. 

>  I have planed to prepare some in kernel test
> with rectangles and copying, because functions are hard to test
> from userspace, but I have not found time for that. The code works 
> right on our HW, but the real range of FB devices is much much
> more variable.

That's okay. As long as a patch does not produce a regression, I'm fine
with it.

Tony

[Linux-fbdev-users] [PATCH] Framebuffer copyarea function taught to fully support swapped pixel order in bytes

[Pavel P. <pi...@cm...>]

This correct case, when source and destination X coordinates difference is not
multiple of pixels in byte. This is probably rare case, but this case should be
supported for completeness.

Reorganization of FB_READL and FB_WRITEL calls results in code size decrease
for normal build without swapping support and size with support enabled
is reasonable too.

Signed-off-by: Pavel Pisa <pi...@cm...>

--

Hello Tony,

thanks for forwarding two patches to MM tree.
  fbdev-support-for-byte-reversed-framebuffer-formats.patch
  imxfb-fast-read-flag-and-nonstandard-field-configurable.patch

What are yours plans with the third one. Do you think, that it
can fit in 2.6.24 merge window or you want to push changes
incremental and delay it for 2.6.25. Have you found time to test
it on your setup? I have planed to prepare some in kernel test
with rectangles and copying, because functions are hard to test
from userspace, but I have not found time for that. The code works 
right on our HW, but the real range of FB devices is much much
more variable.

Thanks for care

                Pavel

 drivers/video/cfbcopyarea.c |   84 ++++++++++++++++++++++++++++++--------------
 1 file changed, 59 insertions(+), 25 deletions(-)

Index: linux-2.6.23/drivers/video/cfbcopyarea.c
===================================================================
--- linux-2.6.23.orig/drivers/video/cfbcopyarea.c
+++ linux-2.6.23/drivers/video/cfbcopyarea.c
@@ -94,29 +94,34 @@ bitcpy(unsigned long __iomem *dst, int d
 				FB_WRITEL( comp( FB_READL(src), FB_READL(dst), last), dst);
 		}
 	} else {
+		// Different alignment for source and dest
 		unsigned long d0, d1;
 		int m;
-		// Different alignment for source and dest
 
 		right = shift & (bits - 1);
 		left = -shift & (bits - 1);
+		bswapmask &= shift;
 
 		if (dst_idx+n <= bits) {
 			// Single destination word
 			if (last)
 				first &= last;
+			d0 = FB_READL(src);
+			d0 = fb_rev_pixels_in_long(d0, bswapmask);
 			if (shift > 0) {
 				// Single source word
-				FB_WRITEL( comp( FB_READL(src) >> right, FB_READL(dst), first), dst);
+				d0 >>= right;
 			} else if (src_idx+n <= bits) {
 				// Single source word
-				FB_WRITEL( comp(FB_READL(src) << left, FB_READL(dst), first), dst);
+				d0 <<= left;;
 			} else {
 				// 2 source words
-				d0 = FB_READL(src++);
-				d1 = FB_READL(src);
-				FB_WRITEL( comp(d0<<left | d1>>right, FB_READL(dst), first), dst);
+				d1 = FB_READL(src + 1);
+				d1 = fb_rev_pixels_in_long(d1, bswapmask);
+				d0 = d0<<left | d1>>right;
 			}
+			d0 = fb_rev_pixels_in_long(d0, bswapmask);
+			FB_WRITEL( comp(d0, FB_READL(dst), first), dst);
 		} else {
 			// Multiple destination words
 			/** We must always remember the last value read, because in case
@@ -125,25 +130,31 @@ bitcpy(unsigned long __iomem *dst, int d
 			overlap with the current long from SRC. We store this value in
 			'd0'. */
 			d0 = FB_READL(src++);
+			d0 = fb_rev_pixels_in_long(d0, bswapmask);
 			// Leading bits
 			if (shift > 0) {
 				// Single source word
-				FB_WRITEL( comp(d0 >> right, FB_READL(dst), first), dst);
+				d1 = d0;
+				d0 >>= right;
 				dst++;
 				n -= bits - dst_idx;
 			} else {
 				// 2 source words
 				d1 = FB_READL(src++);
-				FB_WRITEL( comp(d0<<left | d1>>right, FB_READL(dst), first), dst);
-				d0 = d1;
+				d1 = fb_rev_pixels_in_long(d1, bswapmask);
+
+				d0 = d0<<left | d1>>right;
 				dst++;
 				n -= bits - dst_idx;
 			}
+			d0 = fb_rev_pixels_in_long(d0, bswapmask);
+			FB_WRITEL( comp(d0, FB_READL(dst), first), dst);
+			d0 = d1;
 
 			// Main chunk
 			m = n % bits;
 			n /= bits;
-			while (n >= 4) {
+			while ((n >= 4) && !bswapmask) {
 				d1 = FB_READL(src++);
 				FB_WRITEL(d0 << left | d1 >> right, dst++);
 				d0 = d1;
@@ -160,7 +171,10 @@ bitcpy(unsigned long __iomem *dst, int d
 			}
 			while (n--) {
 				d1 = FB_READL(src++);
-				FB_WRITEL(d0 << left | d1 >> right, dst++);
+				d1 = fb_rev_pixels_in_long(d1, bswapmask);
+				d0 = d0 << left | d1 >> right;
+				d0 = fb_rev_pixels_in_long(d0, bswapmask);
+				FB_WRITEL(d0, dst++);
 				d0 = d1;
 			}
 
@@ -168,12 +182,15 @@ bitcpy(unsigned long __iomem *dst, int d
 			if (last) {
 				if (m <= right) {
 					// Single source word
-					FB_WRITEL( comp(d0 << left, FB_READL(dst), last), dst);
+					d0 <<= left;
 				} else {
 					// 2 source words
 					d1 = FB_READL(src);
-					FB_WRITEL( comp(d0<<left | d1>>right, FB_READL(dst), last), dst);
+					d1 = fb_rev_pixels_in_long(d1, bswapmask);
+					d0 = d0<<left | d1>>right;
 				}
+				d0 = fb_rev_pixels_in_long(d0, bswapmask);
+				FB_WRITEL( comp(d0, FB_READL(dst), last), dst);
 			}
 		}
 	}
@@ -247,24 +264,32 @@ bitcpy_rev(unsigned long __iomem *dst, i
 		}
 	} else {
 		// Different alignment for source and dest
+		unsigned long d0, d1;
+		int m;
 
 		int const left = -shift & (bits-1);
 		int const right = shift & (bits-1);
+		bswapmask &= shift;
 
 		if ((unsigned long)dst_idx+1 >= n) {
 			// Single destination word
 			if (last)
 				first &= last;
+			d0 = FB_READL(src);
 			if (shift < 0) {
 				// Single source word
-				FB_WRITEL( comp( FB_READL(src)<<left, FB_READL(dst), first), dst);
+				d0 <<= left;
 			} else if (1+(unsigned long)src_idx >= n) {
 				// Single source word
-				FB_WRITEL( comp( FB_READL(src)>>right, FB_READL(dst), first), dst);
+				d0 >>= right;
 			} else {
 				// 2 source words
-				FB_WRITEL( comp( (FB_READL(src)>>right | FB_READL(src-1)<<left), FB_READL(dst), first), dst);
+				d1 = FB_READL(src - 1);
+				d1 = fb_rev_pixels_in_long(d1, bswapmask);
+				d0 = d0>>right | d1<<left;
 			}
+			d0 = fb_rev_pixels_in_long(d0, bswapmask);
+			FB_WRITEL( comp(d0, FB_READL(dst), first), dst);
 		} else {
 			// Multiple destination words
 			/** We must always remember the last value read, because in case
@@ -272,27 +297,30 @@ bitcpy_rev(unsigned long __iomem *dst, i
 			1bpp), we always collect one full long for DST and that might
 			overlap with the current long from SRC. We store this value in
 			'd0'. */
-			unsigned long d0, d1;
-			int m;
 
 			d0 = FB_READL(src--);
+			d0 = fb_rev_pixels_in_long(d0, bswapmask);
 			// Leading bits
 			if (shift < 0) {
 				// Single source word
-				FB_WRITEL( comp( (d0 << left), FB_READL(dst), first), dst);
+				d1 = d0;
+				d0 <<= left;
 			} else {
 				// 2 source words
 				d1 = FB_READL(src--);
-				FB_WRITEL( comp( (d0>>right | d1<<left), FB_READL(dst), first), dst);
-				d0 = d1;
+				d1 = fb_rev_pixels_in_long(d1, bswapmask);
+				d0 = d0>>right | d1<<left;
 			}
+			d0 = fb_rev_pixels_in_long(d0, bswapmask);
+			FB_WRITEL( comp(d0, FB_READL(dst), first), dst);
+			d0 = d1;
 			dst--;
 			n -= dst_idx+1;
 
 			// Main chunk
 			m = n % bits;
 			n /= bits;
-			while (n >= 4) {
+			while ((n >= 4) && !bswapmask) {
 				d1 = FB_READL(src--);
 				FB_WRITEL(d0 >> right | d1 << left, dst--);
 				d0 = d1;
@@ -309,7 +337,10 @@ bitcpy_rev(unsigned long __iomem *dst, i
 			}
 			while (n--) {
 				d1 = FB_READL(src--);
-				FB_WRITEL(d0 >> right | d1 << left, dst--);
+				d1 = fb_rev_pixels_in_long(d1, bswapmask);
+				d0 = d0 >> right | d1 << left;
+				d0 = fb_rev_pixels_in_long(d0, bswapmask);
+				FB_WRITEL(d0, dst--);
 				d0 = d1;
 			}
 
@@ -317,12 +348,15 @@ bitcpy_rev(unsigned long __iomem *dst, i
 			if (last) {
 				if (m <= left) {
 					// Single source word
-					FB_WRITEL( comp(d0 >> right, FB_READL(dst), last), dst);
+					d0 >>= right;
 				} else {
 					// 2 source words
 					d1 = FB_READL(src);
-					FB_WRITEL( comp(d0>>right | d1<<left, FB_READL(dst), last), dst);
+					d1 = fb_rev_pixels_in_long(d1, bswapmask);
+					d0 = d0>>right | d1<<left;
 				}
+				d0 = fb_rev_pixels_in_long(d0, bswapmask);
+				FB_WRITEL( comp(d0, FB_READL(dst), last), dst);
 			}
 		}
 	}

Re: [Linux-fbdev-users] How to mmap multiple pages?

[Geert U. <ge...@li...>]

On Mon, 8 Oct 2007, Oliver Zander wrote:
> I wrote a framebuffer driver for an Atmel AVR32 microcontroller with a
> simple monochrome LCD wired to GPIO. The fb uses system RAM.
> My problem is that I need 8 PAGES of mem (256*64*16 bpp) and cannot find
> code which is able to mmap more than 1 PAGE.

You can use remap_pfn_range() (cfr. ps3fb_mmap() in
drivers/video/ps3fb.c).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

[Linux-fbdev-users] How to mmap multiple pages?

[Oliver Z. <oz...@co...>]

Hi all,
I wrote a framebuffer driver for an Atmel AVR32 microcontroller with a
simple monochrome LCD wired to GPIO. The fb uses system RAM.
My problem is that I need 8 PAGES of mem (256*64*16 bpp) and cannot find
code which is able to mmap more than 1 PAGE.

Here's my code:
-------------------------------------------------------------------------------
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
#include <linux/string.h>
#include <linux/mm.h>
#include <linux/slab.h>
#include <linux/vmalloc.h>
#include <linux/delay.h>
#include <linux/interrupt.h>
#include <linux/platform_device.h>

#include <asm/uaccess.h>
#include <linux/fb.h>
#include <linux/init.h>
#include <linux/types.h>

#define MEM_SIZE    (256*64*2)
#define SCREEN_SIZE (256*64*2)
#define LINE_LEN    (256*2)

u8 *lm6800_buffer;
EXPORT_SYMBOL_GPL(lm6800_buffer);

static struct fb_var_screeninfo meinfb_var __initdata = {
	.xres =		256,
	.yres =		64,
	.xres_virtual =	256,
	.yres_virtual =	64,
	.bits_per_pixel = 16,
	.red =		{ 11,5, 0 },
      	.green =	{ 5, 6, 0 },
      	.blue =		{ 0, 5, 0 },
      	.left_margin =	0,
      	.right_margin =	0,
      	.upper_margin =	0,
      	.lower_margin =	0,
      	.vmode =	FB_VMODE_NONINTERLACED,
};

static struct fb_fix_screeninfo meinfb_fix __initdata = {
	.id =		"LM6800 COLOR FB",
	.type =		FB_TYPE_PACKED_PIXELS,
	.smem_len =     MEM_SIZE,
	.visual =	FB_VISUAL_TRUECOLOR,
	.xpanstep =	0,
	.ypanstep =	0,
	.ywrapstep =	0,
	.line_length =  LINE_LEN,
	.accel =	FB_ACCEL_NONE,
};

//do I need this at all?
static int meinfb_setcolreg(unsigned regno, unsigned red, unsigned
green,
			   unsigned blue, unsigned transp,
			   struct fb_info *info)
{
	info->cmap = *fb_default_cmap(16);
	return 0;
}

static int meinfb_mmap(struct fb_info *info, struct vm_area_struct *vma)
{
	return vm_insert_page(vma, vma->vm_start,
		virt_to_page(lm6800_buffer));

}

static struct fb_ops meinfb_ops = {
	.owner          = THIS_MODULE,
	.fb_read        = fb_sys_read,
	.fb_write       = fb_sys_write,
	.fb_setcolreg   = meinfb_setcolreg,
	.fb_fillrect	= sys_fillrect,
	.fb_copyarea	= sys_copyarea,
	.fb_imageblit	= sys_imageblit,
	.fb_mmap        = meinfb_mmap,
};

static int __init meinfb_probe(struct platform_device *dev)
{
	struct fb_info *info;
	int retval = -ENOMEM;

	// allocate in lcd driver?
	// PAGE_SIZE is 4096 so I need 8 pages (256*64*2 / 4096 = 8)
	if (!(lm6800_buffer = (u8 *) __get_free_pages(GFP_KERNEL, 3)))
		return retval;
	memset(lm6800_buffer, 0, MEM_SIZE);

	info = framebuffer_alloc(0, &dev->dev);
	if (!info)
		goto err;

	info->screen_base = (char __iomem *)lm6800_buffer;
	info->screen_size = SCREEN_SIZE;
	info->fbops = &meinfb_ops;
	info->var = meinfb_var;
	info->fix = meinfb_fix;
	info->pseudo_palette = NULL;
	info->par = NULL;
	info->flags = FBINFO_FLAG_DEFAULT;

	fb_alloc_cmap(&info->cmap, 16, 0);
	info->cmap = *fb_default_cmap(16);

	retval = register_framebuffer(info);
	if (retval < 0)
		goto err1;
	platform_set_drvdata(dev, info);

	return 0;

err1:
	framebuffer_release(info);
err:
	free_pages((unsigned long) lm6800_buffer, 3);
	return retval;
}

static int meinfb_remove(struct platform_device *dev)
{
	struct fb_info *info = platform_get_drvdata(dev);

	if (info) {
		unregister_framebuffer(info);
		free_pages((unsigned long) lm6800_buffer, 3);
		framebuffer_release(info);
	}
	return 0;
}

static struct platform_driver meinfb_driver = {
	.probe	= meinfb_probe,
	.remove = meinfb_remove,
	.driver = {
		.name	= "meinfb",
	},
};

static struct platform_device *meinfb_device;

static int __init meinfb_init(void)
{
	int ret = 0;

	ret = platform_driver_register(&meinfb_driver);

	if (!ret) {
		meinfb_device = platform_device_alloc("meinfb", 0);

		if (meinfb_device)
			ret = platform_device_add(meinfb_device);
		else
			ret = -ENOMEM;

		if (ret) {
			platform_device_put(meinfb_device);
			platform_driver_unregister(&meinfb_driver);
		}
	}

	return ret;
}

static void __exit meinfb_exit(void)
{
	platform_device_unregister(meinfb_device);
	platform_driver_unregister(&meinfb_driver);
}

module_init(meinfb_init);
module_exit(meinfb_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Oliver Zander");
MODULE_DESCRIPTION("LM6800 framebuffer driver with color support");
-------------------------------------------------------------------------------

I'm very new to Linux and driver development so please be forgiving :)
TIA
O.Zander

[Linux-fbdev-users] [PATCH] imacfb: Try to autodetect, but allow forcing model if autodetect fails.

[Jamey S. <ja...@mi...>]

If dmi_check_system fails to detect the variety of Intel Mac that it's
running on, the user should still be allowed to specify the model using
the "video=imacfb:..." kernel command-line option.

Signed-off-by: Jamey Sharp <ja...@mi...>
---
 drivers/video/imacfb.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/video/imacfb.c b/drivers/video/imacfb.c
index 18ea4a5..065a0cd 100644
--- a/drivers/video/imacfb.c
+++ b/drivers/video/imacfb.c
@@ -357,15 +357,15 @@ static int __init imacfb_init(void)
 
 	if (!efi_enabled)
 		return -ENODEV;
-	if (!dmi_check_system(dmi_system_table))
-		return -ENODEV;
-	if (model == M_UNKNOWN)
-		return -ENODEV;
+	dmi_check_system(dmi_system_table);
 
 	if (fb_get_options("imacfb", &option))
 		return -ENODEV;
 
 	imacfb_setup(option);
+	if (model == M_UNKNOWN)
+		return -ENODEV;
+
 	ret = platform_driver_register(&imacfb_driver);
 
 	if (!ret) {
-- 
1.5.2.4

Re: [Linux-fbdev-users] How many colors?

[Witold F. <wi...@po...>]

Hi!
I modified the iterm library and its fbiterm program.
New fbiterm displays 256 colors on the framebuffer.
Original iterm-0.5-mbt.tar.gz you could get from:
http://republika.pl/rkd/iterm-0.5-mbt.tar.gz

The bunch of patches:
http://republika.pl/rkd/iterm.tar.bz2

Apply patches in the order shown in the iterm.sh.
iterm.sh is included in the tarball.

fbiterm uses PCF fonts used by the X Window.
Usage:
$ fbiterm -a normal_font -b bold_font, eg.
$ fbiterm -a /usr/share/fonts/misc/9x18.pcf.gz -b /usr/share/fonts/misc/9x18B.pcf.gz

Unfortunately scrolling is slow.
It could be faster if the kernel provides ioctl for copyarea. Something like this,
drivers/video/fbmem.c (fb_ioctl):

	struct fb_copyarea copy;

	case FBIO_COPYAREA:
		argp = (void __user *)arg;
		if (copy_from_user(&copy, argp, sizeof(copy)))
			return -EINVAL;
		fb->fb_copyarea(info, &copy);
		return 0;

I use kernel 2.6.19, so this snippet may be obsolete.

Is it possible to add such ioctl to the kernel?

Re: [Linux-fbdev-users] How many colors?

[Antonino A. D. <ad...@gm...>]

On Wed, 2007-09-12 at 18:56 -0400, cga2000 wrote:
> On Wed, Sep 12, 2007 at 03:58:35PM EDT, James Lehman wrote:

> 
> What I understand from Antonino's reply is that contrary to xterm and
> a couple other X terminal emulators, the linux console does not have
> the "physical" capability to display more than 16 colors.
> 

The main limitation of the linux console is that it is patterned from
VGA, each character is described in 16 bits only. At least 8-bits are
already assigned for the character map.  That leaves at most 8-bits for
the attributes, 4-bits for the background color and 4-bits for the
foreground color. With 4 bits apiece, you can only get 16 colors.

I haven't looked at xterm, but to preserve 16-bits/character, my guess
is that xterm set a fixed background color and assigned the full 8-bits
for the foreground color.

Tony

Re: [Linux-fbdev-users] How many colors?

[cga2000 <cg...@op...>]

On Wed, Sep 12, 2007 at 03:58:35PM EDT, James Lehman wrote:
> Cool!
> 
> I'm glad you like it.
> 
> I'll have to get my stuff together and release version 10.0.

Definitely worth it.

> It uses function pointers that get set only once whenever a change is made
> to the frame buffer resolution. That way the right function gets called
> automatically with no time wasted on a switch statement. It is WAY faster
> than the version that is on the web now. 

Quite surprising.  I ran ./demo and the other stuff and I had a distinct
feeling that my ancient mach64 was a lot friskier than usual.

> It is written in C, but it acts like C++.
> 
> I guess I don't really understand your first question. You can't get
> more than 16 colors out of any terminal because the program that runs
> to display in the terminal has no way to ask for more than the 16
> usual colors. 

Not sure I follow you.  I've been running mutt and vim in an xterm with
256 colors for over a year.  By "terminal" do you mean a hardware
device (as opposed to an emulator) ..?

> The colors are set with escape sequences; a coded string of
> characters. These can also set absolute cursor position anywhere on
> the screen and do other things like reverse the text foreground and
> background or make it blink.  It's not really graphics at all. You
> have no pixels; only character cells; 

Yes. In a 256-color xterm you can display a succession of 256 cells
with the background or foreground set set to 256 colors chosen between
the 16 system colors, the 216 extended colors, and 24 shades of grey.

Which means you could simultaneously display a 256-character snippet of
text with each letter a different color.  But each letter would be
displayed in one single/solid color.  You would not be able to display
an O that changes color clockwise from slategrey, to teal, to cadetblue,
to hotpink .. etc. because the smallest addressable display area is the
cell and each character occupies an entire cell.

What I understand from Antonino's reply is that contrary to xterm and
a couple other X terminal emulators, the linux console does not have
the "physical" capability to display more than 16 colors.

So if I wanted to use the 256-color feature of mutt, vim, ELinks,
I would have to run an emulator that has this capability.

Unfortunately, there does not seem to be one available.

Hope this clarifies my earlier post.

cga

Re: [Linux-fbdev-users] How many colors?

[James L. <ja...@ak...>]

Cool!

I'm glad you like it.

I'll have to get my stuff together and release version 10.0.
It uses function pointers that get set only once whenever a change is made
to the frame buffer resolution. That way the right function gets called
automatically with no time wasted on a switch statement. It is WAY faster
than the version that is on the web now. It is written in C, but it acts
like C++.

I guess I don't really understand your first question. You can't get more
than 16 colors out of any terminal because the program that runs to display
in the terminal has no way to ask for more than the 16 usual colors. The
colors are set with escape sequences; a coded string of characters. These
can also set absolute cursor position anywhere on the screen and do other
things like reverse the text foreground and background or make it blink.
It's not really graphics at all. You have no pixels; only character cells;
and it is (supposed to be) OS independent.

James.   :o)




----- Original Message ----- 
From: "cga2000" <cg...@op...>
To: <lin...@li...>
Sent: Tuesday, September 11, 2007 9:30 PM
Subject: Re: [Linux-fbdev-users] How many colors?


> On Fri, Aug 31, 2007 at 11:16:44PM EDT, James Lehman wrote:
> > The colors that you see in an ncurses application are based on an (any
OS)
> > ANSI color terminal. There is a specific set of 16 colors and their
> > associated escape sequences that set any ANSI compliant terminal's
> > foreground and background colors for each character cell. BUT, there is
> > nothing that says that you couldn't write your own layer of abstraction
/
> > interpretation that could render its own bitmapped fonts in either high
or
> > true color.
> >
> > Take a look at this...
> > http://www.akrobiz.com/ezfb
> >
> > EZFB version 10.0 is done and awaiting release. It's WAY faster than any
> > previous version.
> >
> > James.   :o)
>
> Great stuff!
>
> And a screen capture utility that actually works on the fb console in
> the bargain.  Years I'd been looking for one!
>
> I'm not sure how all this relates to my original post but downloading
> your stuff and having fun running it sure wasn't a waste of my time.
>
> Thank You!
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Linux-fbdev-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-users
>

Re: [Linux-fbdev-users] How many colors?

[cga2000 <cg...@op...>]

On Fri, Aug 31, 2007 at 11:16:44PM EDT, James Lehman wrote:
> The colors that you see in an ncurses application are based on an (any OS)
> ANSI color terminal. There is a specific set of 16 colors and their
> associated escape sequences that set any ANSI compliant terminal's
> foreground and background colors for each character cell. BUT, there is
> nothing that says that you couldn't write your own layer of abstraction /
> interpretation that could render its own bitmapped fonts in either high or
> true color.
> 
> Take a look at this...
> http://www.akrobiz.com/ezfb
> 
> EZFB version 10.0 is done and awaiting release. It's WAY faster than any
> previous version.
> 
> James.   :o)

Great stuff!

And a screen capture utility that actually works on the fb console in
the bargain.  Years I'd been looking for one!

I'm not sure how all this relates to my original post but downloading
your stuff and having fun running it sure wasn't a waste of my time.

Thank You!

Re: [Linux-fbdev-users] How many colors?

[gavron <cg...@op...>]

On Fri, Aug 31, 2007 at 08:57:50PM EDT, Antonino A. Daplas wrote:
> On Fri, 2007-08-31 at 19:47 -0400, gavron wrote:
> > I was wondering if there was any way I could get 256 colors - or more ..
> > when running ncurses applications on a linux console with the frame
> > buffer enabled.  There are a few applications that greatly benefit from
> > this enhancement such as mutt, vim, ELinks .. and I was wondering if
> > this is possible when not running in an xterm under xorg. 
> 
> No it's not possible under the linux console.  The linux console
> supports 16-colors only and changing this to support 256-colors will
> entail a massive rewrite of the console code.
> 
> Even a 32bpp framebuffer is stuck with a 16-color console.
> 
> > 
> > Maybe I need to run a terminal emulator that supports more than 16
> > colors rather than the standard linux console?
> > 
> 
> Yes, you will basically need a new terminal emulator, one that basically
> re-implements the kernel console code.

Thanks for your comments and sorry about the delay.

I think I tried a couple of terminal emulators in the past and I think
neither supported more than the usual 8-16 colors.

I guess I'll just have to maintain separate configurations depending on
whether I'm running on a 256-color xterm or the console.

Thanks,
cga.

Re: [Linux-fbdev-users] probably an FAQ - g450 vs g400 tv out?

[Ville <sy...@sc...>]

On Tue, Sep 11, 2007 at 09:06:28AM +0930, davidm wrote:
> Umm. X on the tv-out doesn't seem to present any useful Xvideo
> extension, and I was assuming that the reason for that was that it
> required stuff on crtc1. Is that a false assumption?

I know the Xorg mga driver supports using the texture engine for Xv but
I don't know if it still has some limits on what it supports on CRTC2.
When I last used that driver years ago it didn't support any acceleration
on CRTC2. Also I don't know if the driver supports vsync or triple
buffering for Xv.

> Would a g400
> (instead of a 450) change this? Without the xvideo layer my p3@1GHz
> seems to not be fast enough to do anything useful under X.

With a G400 you might be able to swap the heads like you intended and
overcome the driver limitations by using the BES. I won't guarantee that
it will be succesful though since the X driver might revert whatever
changes you make via matroxfb, and since it's using the binary HAL (or has
that changed?) changing it's behavior might not be easy.

> Actually it occurs to me now that even if X did present a nice Xv
> extension on the tv-out, would mythtv (or any other player for that
> matter) have any mechanism for playing interlaced video with the correct
> synchronization? (Using mplayer's dfbmga output layer I need to set
> fieldparity=top and vsync=1, and I'm not sure there would be any way to
> do the equivalent? It would be rather sad to have to deinterlace the
> video in software only to display it on an interlaced TV!).

I think the driver could have an Xv attribute for field parity.

-- 
Ville Syrjälä
sy...@sc...
http://www.sci.fi/~syrjala/

Re: [Linux-fbdev-users] probably an FAQ - g450 vs g400 tv out?

[davidm <dav...@da...>]

Umm. X on the tv-out doesn't seem to present any useful Xvideo
extension, and I was assuming that the reason for that was that it
required stuff on crtc1. Is that a false assumption? Would a g400
(instead of a 450) change this? Without the xvideo layer my p3@1GHz
seems to not be fast enough to do anything useful under X.

Actually it occurs to me now that even if X did present a nice Xv
extension on the tv-out, would mythtv (or any other player for that
matter) have any mechanism for playing interlaced video with the correct
synchronization? (Using mplayer's dfbmga output layer I need to set
fieldparity=top and vsync=1, and I'm not sure there would be any way to
do the equivalent? It would be rather sad to have to deinterlace the
video in software only to display it on an interlaced TV!).

Cheers,


David

Ville Syrjälä wrote:
> On Mon, Sep 10, 2007 at 11:01:29PM +0930, davidm wrote:
>> Hi,
>>
>> I suspect this ought to be an FAQ, but I can't find anything definitive
>> easily...
>>
>> I have a g450. I cannot get my tv to sync to the tvout if I attach the
>> primary crtc to that output (eg, taken from
>> http://www.rockhopper.dk/linux/hardware/graphics_cards.html:
> 
> G450/G550 hardware doesn't support what you want. Only CRTC2 can drive
> the TV-encoder.
> 
>> (obviously it would be nice to be able to get the goodies from the
>> primary crtc through the tv, rather than effectively having a dumb fb).
> 
> Well, the only goodie CRTC1 has over CRTC2 is the BES so you're not missing
> that much.
> 

Re: [Linux-fbdev-users] probably an FAQ - g450 vs g400 tv out?

[Ville <sy...@sc...>]

On Mon, Sep 10, 2007 at 11:01:29PM +0930, davidm wrote:
> Hi,
> 
> I suspect this ought to be an FAQ, but I can't find anything definitive
> easily...
> 
> I have a g450. I cannot get my tv to sync to the tvout if I attach the
> primary crtc to that output (eg, taken from
> http://www.rockhopper.dk/linux/hardware/graphics_cards.html:

G450/G550 hardware doesn't support what you want. Only CRTC2 can drive
the TV-encoder.

> (obviously it would be nice to be able to get the goodies from the
> primary crtc through the tv, rather than effectively having a dumb fb).

Well, the only goodie CRTC1 has over CRTC2 is the BES so you're not missing
that much.

-- 
Ville Syrjälä
sy...@sc...
http://www.sci.fi/~syrjala/

[Linux-fbdev-users] probably an FAQ - g450 vs g400 tv out?

[davidm <dav...@da...>]

Hi,

I suspect this ought to be an FAQ, but I can't find anything definitive
easily...

I have a g450. I cannot get my tv to sync to the tvout if I attach the
primary crtc to that output (eg, taken from
http://www.rockhopper.dk/linux/hardware/graphics_cards.html:

#!/bin/bash
modprobe i2c-matroxfb
modprobe matroxfb_maven

matroxset -f /dev/fb1 -m 0
matroxset -f /dev/fb0 -m 0
matroxset -f /dev/fb0 -m 3

matroxset -o 1 1 # Sets the output to pal, ntsc users should use -o 1 2

# Set the resolution to 720x576
fbset -fb /dev/fb0 -left 18 -right 0 -upper 39 -lower 10 -hslen 46 \
-vslen 4 -xres 720 -yres 576 -vxres 720 -vyres 576 -depth 32 \
-laced false -bcast true

 - I just get rubbish).

That page is referring to a G400, not a G450 - is that why I can't make
it work as expected?

(obviously it would be nice to be able to get the goodies from the
primary crtc through the tv, rather than effectively having a dumb fb).

Cheers,

	David