[PATCH] atyfb: vblank irq support

[PATCH] atyfb: vblank irq support

[Ville Syrjälä]

[-- Attachment #1: Type: text/plain, Size: 323 bytes --]

This patch adds vblank interrupt support to atyfb. The added features are 
FB_ACTIVATE_VBL flag for panning and FBIO_WAITFORVSYNC ioctl.

The code is basically copied from matroxfb. I've tested it on two laptops 
(Mobility and LT Pro) using DirectFB.

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

[-- Attachment #2: atyfb-2.6-vblank_irq.patch --]
[-- Type: text/plain, Size: 9700 bytes --]

diff -urN linux/drivers/video/aty/atyfb.h linux/drivers/video/aty/atyfb.h
--- linux/drivers/video/aty/atyfb.h	2004-06-18 01:14:39.000000000 +0300
+++ linux/drivers/video/aty/atyfb.h	2004-07-22 21:08:19.000000000 +0300
@@ -3,6 +3,8 @@
  */
 
 #include <linux/config.h>
+#include <linux/spinlock.h>
+#include <linux/wait.h>
     /*
      *  Elements of the hardware specific atyfb_par structure
      */
@@ -33,6 +35,12 @@
 #endif
 };
 
+struct aty_interrupt {
+	wait_queue_head_t wait;
+	unsigned int count;
+	int pan_display;
+};
+
 struct pll_info {
 	int pll_max;
 	int pll_min;
@@ -142,8 +150,8 @@
 #ifdef __sparc__
 	struct pci_mmap_map *mmap_map;
 	u8 mmaped;
-	int open;
 #endif
+	int open;
 #ifdef CONFIG_FB_ATY_GENERIC_LCD
 	unsigned long bios_base_phys;
 	unsigned long bios_base;
@@ -166,6 +174,10 @@
 #endif
 	unsigned long aux_start; /* auxiliary aperture */
 	unsigned long aux_size;
+	struct aty_interrupt vblank;
+	unsigned long irq_flags;
+	unsigned int irq;
+	spinlock_t int_lock;
 };
 
     /*
diff -urN linux/drivers/video/aty/atyfb_base.c linux/drivers/video/aty/atyfb_base.c
--- linux/drivers/video/aty/atyfb_base.c	2004-06-18 01:14:39.000000000 +0300
+++ linux/drivers/video/aty/atyfb_base.c	2004-07-22 21:26:36.633215432 +0300
@@ -62,6 +62,9 @@
 #include <linux/fb.h>
 #include <linux/init.h>
 #include <linux/pci.h>
+#include <linux/interrupt.h>
+#include <linux/spinlock.h>
+#include <linux/wait.h>
 
 #include <asm/io.h>
 #include <asm/uaccess.h>
@@ -1441,7 +1444,6 @@
 	u32 bpp = info->var.bits_per_pixel;
 
 	par->crtc.off_pitch = ((yoffset * vxres + xoffset) * bpp / 64) | (vxres << 19);
-	aty_st_le32(CRTC_OFF_PITCH, par->crtc.off_pitch, par);
 }
 
 
@@ -1451,26 +1453,103 @@
 
 static int atyfb_open(struct fb_info *info, int user)
 {
-#ifdef __sparc__
 	struct atyfb_par *par = (struct atyfb_par *) info->par;
 
 	if (user) {
 		par->open++;
+#ifdef __sparc__
 		par->mmaped = 0;
-	}
 #endif
+	}
 	return (0);
 }
 
+static irqreturn_t aty_irq(int irq, void *dev_id, struct pt_regs *fp)
+{
+	struct atyfb_par *par = dev_id;
+	int handled = 0;
+	u32 int_cntl;
+
+	spin_lock(&par->int_lock);
+
+	int_cntl = aty_ld_le32(CRTC_INT_CNTL, par);
+
+	if (int_cntl & CRTC_VBLANK_INT) {
+		/* clear interrupt */
+		aty_st_le32(CRTC_INT_CNTL, (int_cntl & CRTC_INT_EN_MASK) | CRTC_VBLANK_INT_AK, par);
+		par->vblank.count++;
+		if (par->vblank.pan_display) {
+			par->vblank.pan_display = 0;
+			aty_st_le32(CRTC_OFF_PITCH, par->crtc.off_pitch, par);
+		}
+		wake_up_interruptible(&par->vblank.wait);
+		handled = 1;
+	}
+
+	spin_unlock(&par->int_lock);
+
+	return IRQ_RETVAL(handled);
+}
+
+static int aty_enable_irq(struct atyfb_par *par, int reenable)
+{
+	u32 int_cntl;
+
+	if (!test_and_set_bit(0, &par->irq_flags)) {
+		if (request_irq(par->irq, aty_irq, SA_SHIRQ, "atyfb", par)) {
+			clear_bit(0, &par->irq_flags);
+			return -EINVAL;
+		}
+		spin_lock_irq(&par->int_lock);
+		int_cntl = aty_ld_le32(CRTC_INT_CNTL, par) & CRTC_INT_EN_MASK;
+		/* clear interrupt */
+		aty_st_le32(CRTC_INT_CNTL, int_cntl | CRTC_VBLANK_INT_AK, par);
+		/* enable interrupt */
+		aty_st_le32(CRTC_INT_CNTL, int_cntl | CRTC_VBLANK_INT_EN, par);
+		spin_unlock_irq(&par->int_lock);
+	} else if (reenable) {
+		spin_lock_irq(&par->int_lock);
+		int_cntl = aty_ld_le32(CRTC_INT_CNTL, par) & CRTC_INT_EN_MASK;
+		if (!(int_cntl & CRTC_VBLANK_INT_EN)) {
+			printk("atyfb: someone disabled IRQ [%08x]\n", int_cntl);
+			/* re-enable interrupt */
+			aty_st_le32(CRTC_INT_CNTL, int_cntl | CRTC_VBLANK_INT_EN, par );
+		}
+		spin_unlock_irq(&par->int_lock);
+	}
+
+	return 0;
+}
+
+static int aty_disable_irq(struct atyfb_par *par)
+{
+	u32 int_cntl;
+
+	if (test_and_clear_bit(0, &par->irq_flags)) {
+		if (par->vblank.pan_display) {
+			par->vblank.pan_display = 0;
+			aty_st_le32(CRTC_OFF_PITCH, par->crtc.off_pitch, par);
+		}
+		spin_lock_irq(&par->int_lock);
+		int_cntl = aty_ld_le32(CRTC_INT_CNTL, par) & CRTC_INT_EN_MASK;
+		/* disable interrupt */
+		aty_st_le32(CRTC_INT_CNTL, int_cntl & ~CRTC_VBLANK_INT_EN, par );
+		spin_unlock_irq(&par->int_lock);
+		free_irq(par->irq, par);
+	}
+
+	return 0;
+}
+
 static int atyfb_release(struct fb_info *info, int user)
 {
-#ifdef __sparc__
 	struct atyfb_par *par = (struct atyfb_par *) info->par;
 	if (user) {
 		par->open--;
 		mdelay(1);
 		wait_for_idle(par);
 		if (!par->open) {
+#ifdef __sparc__
 			int was_mmaped = par->mmaped;
 
 			par->mmaped = 0;
@@ -1495,9 +1574,10 @@
 						var.yres_virtual = var.yres;
 				}
 			}
+#endif
+			aty_disable_irq(par);
 		}
 	}
-#endif
 	return (0);
 }
 
@@ -1524,10 +1604,50 @@
 	info->var.yoffset = yoffset;
 	if (par->asleep)
 		return 0;
+
 	set_off_pitch(par, info);
+	if ((var->activate & FB_ACTIVATE_VBL) && !aty_enable_irq(par, 0)) {
+		par->vblank.pan_display = 1;
+	} else {
+		par->vblank.pan_display = 0;
+		aty_st_le32(CRTC_OFF_PITCH, par->crtc.off_pitch, par);
+	}
+
+	return 0;
+}
+
+static int aty_waitforvblank(struct atyfb_par *par, u32 crtc)
+{
+	struct aty_interrupt *vbl;
+	unsigned int count;
+	int ret;
+
+	switch (crtc) {
+	case 0:
+		vbl = &par->vblank;
+		break;
+	default:
+		return -ENODEV;
+	}
+
+	ret = aty_enable_irq(par, 0);
+	if (ret)
+		return ret;
+
+	count = vbl->count;
+	ret = wait_event_interruptible_timeout(vbl->wait, count != vbl->count, HZ/10);
+	if (ret < 0) {
+		return ret;
+	}
+	if (ret == 0) {
+		aty_enable_irq(par, 1);
+		return -ETIMEDOUT;
+	}
+
 	return 0;
 }
 
+
 #ifdef DEBUG
 #define ATYIO_CLKR		0x41545900	/* ATY\00 */
 #define ATYIO_CLKW		0x41545901	/* ATY\01 */
@@ -1552,12 +1672,14 @@
 #define ATYIO_FEATW		0x41545903	/* ATY\03 */
 #endif
 
+#ifndef FBIO_WAITFORVSYNC
+#define FBIO_WAITFORVSYNC _IOW('F', 0x20, __u32)
+#endif
+
 static int atyfb_ioctl(struct inode *inode, struct file *file, u_int cmd,
 	u_long arg, struct fb_info *info)
 {
-#if defined(__sparc__) || (defined(DEBUG) && defined(CONFIG_FB_ATY_CT))
 	struct atyfb_par *par = (struct atyfb_par *) info->par;
-#endif /* __sparc__ || DEBUG */
 #ifdef __sparc__
 	struct fbtype fbtyp;
 #endif
@@ -1575,6 +1697,18 @@
 			return -EFAULT;
 		break;
 #endif /* __sparc__ */
+
+	case FBIO_WAITFORVSYNC:
+		{
+			u32 crtc;
+
+			if (get_user(crtc, (__u32 *) arg))
+				return -EFAULT;
+
+			return aty_waitforvblank(par, crtc);
+		}
+		break;
+
 #if defined(DEBUG) && defined(CONFIG_FB_ATY_CT)
 	case ATYIO_CLKR:
 		if (M64_HAS(INTEGRATED)) {
@@ -1771,6 +1905,7 @@
 				info->var.yoffset = atyfb_save.yoffset;
 				set_off_pitch(par, info);
 			}
+			aty_st_le32(CRTC_OFF_PITCH, par->crtc.off_pitch, par);
 			break;
 		}
 	}
@@ -2005,6 +2140,9 @@
 	int sense;
 #endif
 
+	init_waitqueue_head(&par->vblank.wait);
+	spin_lock_init(&par->int_lock);
+
 	par->aty_cmap_regs =
 	    (struct aty_cmap_regs *) (par->ati_regbase + 0xc0);
 
@@ -3207,6 +3345,8 @@
 	info->fix = atyfb_fix;
 	par->pci_id = aty_chips[i].pci_id;
 
+	par->irq = pdev->irq;
+
 	/* Reserve space */
 	par->res_start = rp->start;
 	par->res_size = rp->end - rp->start + 1;
@@ -3300,6 +3440,8 @@
 
 		info->fix = atyfb_fix;
 
+		par->irq = (unsigned int) -1; /* something invalid */
+
 		/*
 		 *  Map the video memory (physical address given) to somewhere in the
 		 *  kernel address space.
diff -urN linux/include/video/mach64.h linux/include/video/mach64.h
--- linux/include/video/mach64.h	2004-06-18 01:14:39.000000000 +0300
+++ linux/include/video/mach64.h	2004-07-13 19:52:39.000000000 +0300
@@ -630,10 +630,70 @@
 #define CRTC_CUR_B_TEST		0x80000000
 
 #define CRTC_CRNT_VLINE		0x07f00000
-#define CRTC_VBLANK		0x00000001
 
 #define CRTC_PRESERVED_MASK	0x0001f000
 
+#define CRTC_VBLANK		0x00000001
+#define CRTC_VBLANK_INT_EN	0x00000002
+#define CRTC_VBLANK_INT		0x00000004
+#define CRTC_VBLANK_INT_AK	CRTC_VBLANK_INT
+#define CRTC_VLINE_INT_EN	0x00000008
+#define CRTC_VLINE_INT		0x00000010
+#define CRTC_VLINE_INT_AK	CRTC_VLINE_INT
+#define CRTC_VLINE_SYNC		0x00000020
+#define CRTC_FRAME		0x00000040
+#define SNAPSHOT_INT_EN		0x00000080
+#define SNAPSHOT_INT		0x00000100
+#define SNAPSHOT_INT_AK		SNAPSHOT_INT
+#define I2C_INT_EN		0x00000200
+#define I2C_INT			0x00000400
+#define I2C_INT_AK		I2C_INT
+#define CRTC2_VBLANK		0x00000800
+#define CRTC2_VBLANK_INT_EN	0x00001000
+#define CRTC2_VBLANK_INT	0x00002000
+#define CRTC2_VBLANK_INT_AK	CRTC2_VBLANK_INT
+#define CRTC2_VLINE_INT_EN	0x00004000
+#define CRTC2_VLINE_INT		0x00008000
+#define CRTC2_VLINE_INT_AK	CRTC2_VLINE_INT
+#define CAPBUF0_INT_EN		0x00010000
+#define CAPBUF0_INT		0x00020000
+#define CAPBUF0_INT_AK		CAPBUF0_INT
+#define CAPBUF1_INT_EN		0x00040000
+#define CAPBUF1_INT		0x00080000
+#define CAPBUF1_INT_AK		CAPBUF1_INT
+#define OVERLAY_EOF_INT_EN	0x00100000
+#define OVERLAY_EOF_INT		0x00200000
+#define OVERLAY_EOF_INT_AK	OVERLAY_EOF_INT
+#define ONESHOT_CAP_INT_EN	0x00400000
+#define ONESHOT_CAP_INT		0x00800000
+#define ONESHOT_CAP_INT_AK	ONESHOT_CAP_INT
+#define BUSMASTER_EOL_INT_EN	0x01000000
+#define BUSMASTER_EOL_INT	0x02000000
+#define BUSMASTER_EOL_INT_AK	BUSMASTER_EOL_INT
+#define GP_INT_EN		0x04000000
+#define GP_INT			0x08000000
+#define GP_INT_AK		GP_INT
+#define CRTC2_VLINE_SYNC	0x10000000
+#define SNAPSHOT2_INT_EN	0x20000000
+#define SNAPSHOT2_INT		0x40000000
+#define SNAPSHOT2_INT_AK	SNAPSHOT2_INT
+#define VBLANK_BIT2_INT		0x80000000
+#define VBLANK_BIT2_INT_AK	VBLANK_BIT2_INT
+
+#define CRTC_INT_EN_MASK	(CRTC_VBLANK_INT_EN |	\
+				 CRTC_VLINE_INT_EN |	\
+				 SNAPSHOT_INT_EN |	\
+				 I2C_INT_EN |		\
+				 CRTC2_VBLANK_INT_EN |	\
+				 CRTC2_VLINE_INT_EN |	\
+				 CAPBUF0_INT_EN |	\
+				 CAPBUF1_INT_EN |	\
+				 OVERLAY_EOF_INT_EN |	\
+				 ONESHOT_CAP_INT_EN |	\
+				 BUSMASTER_EOL_INT_EN |	\
+				 GP_INT_EN |		\
+				 SNAPSHOT2_INT_EN)
+
 /* DAC control values */
 
 #define DAC_EXT_SEL_RS2		0x01

Re: [PATCH] atyfb: vblank irq support

[Alexander Kern]

[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]

Am Donnerstag, 22. Juli 2004 20:49 schrieb Ville Syrjälä:
> This patch adds vblank interrupt support to atyfb. The added features are
> FB_ACTIVATE_VBL flag for panning and FBIO_WAITFORVSYNC ioctl.
>
> The code is basically copied from matroxfb. I've tested it on two laptops
> (Mobility and LT Pro) using DirectFB.
Thanks Ville,

I had added last three patches to my tree.
atyfb: Rage LT LCD register access.
atyfb: Blank LCD by turning off backlight voltage
atyfb: vblank irq support

atyfb: Add option to disable hardware cursor. <----This one I add in another 
way. Option noaccel deactivate hwcursor too.
The reason is, that I redone hwcursor part and it works now for me, please 
test it.

Here is a patch again vanilla 2.6.7 + latest known JSimmons patch

P.S. Now the last consumer from fb_load_cursor_image is neo driver.
Should we drop this function, it's buggy!

Steel on my TODO list:

Issue with 16bpp mode, brocken boot logo, fbi has problems too.
Issue with 24bpp mode and fbtest, yellow parts of pinguin image are blue!!! 
Hey on the list, any clue?



[-- Attachment #2: mach64-js3-ak6.diff.gz --]
[-- Type: application/x-gzip, Size: 20499 bytes --]

Re: [PATCH] atyfb: vblank irq support

[Antonino A. Daplas]

On Sunday 25 July 2004 07:12, Alexander Kern wrote:
>
> P.S. Now the last consumer from fb_load_cursor_image is neo driver.
> Should we drop this function, it's buggy!

We should.  fb_load_cursor_image() cannot be generic.

>
> Steel on my TODO list:
>
> Issue with 16bpp mode, brocken boot logo, fbi has problems too.

1. aty128fb_setcolreg has this lines:

		case 16:
			pal[regno] = (regno << 11) | (regno << 6) | regno;
			break;

Shouldn't it be?

		pal[regno] = (regno << 11) | (regno << 5) | regno;

2. In RGB555, isn't it better to fill up all the 8 slots per index per channel (256/32),
instead of just (regno * 8)? For RGB565, that will be 8 slots per red and blue,
4 slots per green (256/64).

So something like this for RGB555, ie:

	for  (i = 0; i < 8; i++) {
		aty128_st_pal((regno * 8) + i, red, green, blue, par);

RGB565 is a bit more complicated because green is deeper, but is doable.

Tony

DISCLAIMER: I know nothing about this hardware, I'm probably shooting
blanks :-)




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click

Re: [PATCH] atyfb: vblank irq support

[Ville Syrjälä]

On Sun, Jul 25, 2004 at 01:12:18AM +0200, Alexander Kern wrote:
> Am Donnerstag, 22. Juli 2004 20:49 schrieb Ville Syrjälä:
> > This patch adds vblank interrupt support to atyfb. The added features are
> > FB_ACTIVATE_VBL flag for panning and FBIO_WAITFORVSYNC ioctl.
> >
> > The code is basically copied from matroxfb. I've tested it on two laptops
> > (Mobility and LT Pro) using DirectFB.
> Thanks Ville,
> 
> I had added last three patches to my tree.
> atyfb: Rage LT LCD register access.
> atyfb: Blank LCD by turning off backlight voltage
> atyfb: vblank irq support
> 
> atyfb: Add option to disable hardware cursor. <----This one I add in another 
> way. Option noaccel deactivate hwcursor too.
> The reason is, that I redone hwcursor part and it works now for me, please 
> test it.

Great. I'll test it later today.

> Here is a patch again vanilla 2.6.7 + latest known JSimmons patch
> 
> P.S. Now the last consumer from fb_load_cursor_image is neo driver.
> Should we drop this function, it's buggy!
> 
> Steel on my TODO list:
> 
> Issue with 16bpp mode, brocken boot logo, fbi has problems too.
> Issue with 24bpp mode and fbtest, yellow parts of pinguin image are blue!!! 

I've never tried 24bpp because of limited acceleration support. I haven't 
even bothered implenenting 24bpp acceleration in the DirectFB driver.

My only todo item is mtrr support. I have a patch which simply tries to 
add fix.smem_len sized wrcomb mtrr. But that will only work with 
power-of-two memory size. Also it won't work with a 8MB card when the 
auxiliary aperture isn't used. Maybe an 8MB wrcomb mtrr + an overlapping 
uncachable mtrr covering the register page might be better. Will that sort 
of thing work on all systems?

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


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id\x10040&op=click

Re: [PATCH] atyfb: vblank irq support

[Alexander Kern]

Am Sonntag, 25. Juli 2004 12:16 schrieb Ville Syrjälä:
> On Sun, Jul 25, 2004 at 01:12:18AM +0200, Alexander Kern wrote:
> > Am Donnerstag, 22. Juli 2004 20:49 schrieb Ville Syrjälä:
> > > This patch adds vblank interrupt support to atyfb. The added features
> > > are FB_ACTIVATE_VBL flag for panning and FBIO_WAITFORVSYNC ioctl.
> > >
> > > The code is basically copied from matroxfb. I've tested it on two
> > > laptops (Mobility and LT Pro) using DirectFB.
> >
> > Thanks Ville,
> >
> > I had added last three patches to my tree.
> > atyfb: Rage LT LCD register access.
> > atyfb: Blank LCD by turning off backlight voltage
> > atyfb: vblank irq support
> >
> > atyfb: Add option to disable hardware cursor. <----This one I add in
> > another way. Option noaccel deactivate hwcursor too.
> > The reason is, that I redone hwcursor part and it works now for me,
> > please test it.
>
> Great. I'll test it later today.
>
> > Here is a patch again vanilla 2.6.7 + latest known JSimmons patch
> >
> > P.S. Now the last consumer from fb_load_cursor_image is neo driver.
> > Should we drop this function, it's buggy!
> >
> > Steel on my TODO list:
> >
> > Issue with 16bpp mode, brocken boot logo, fbi has problems too.
> > Issue with 24bpp mode and fbtest, yellow parts of pinguin image are
> > blue!!!
>
> I've never tried 24bpp because of limited acceleration support. I haven't
> even bothered implenenting 24bpp acceleration in the DirectFB driver.
Interesting, I thought 24bpp hardware acceleration is complete? What is 
missed?
>
> My only todo item is mtrr support. I have a patch which simply tries to
> add fix.smem_len sized wrcomb mtrr. But that will only work with
> power-of-two memory size. Also it won't work with a 8MB card when the
> auxiliary aperture isn't used. Maybe an 8MB wrcomb mtrr + an overlapping
> uncachable mtrr covering the register page might be better. Will that sort
> of thing work on all systems?


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id\x10040&op=click

Re: [PATCH] atyfb: vblank irq support

[Alexander Kern]

Am Sonntag, 25. Juli 2004 02:03 schrieb Antonino A. Daplas:
> On Sunday 25 July 2004 07:12, Alexander Kern wrote:
> > P.S. Now the last consumer from fb_load_cursor_image is neo driver.
> > Should we drop this function, it's buggy!
>
> We should.  fb_load_cursor_image() cannot be generic.
fine, do you make it for neo driver?
>
> > Steel on my TODO list:
> >
> > Issue with 16bpp mode, brocken boot logo, fbi has problems too.
>
> 1. aty128fb_setcolreg has this lines:
>
> 		case 16:
> 			pal[regno] = (regno << 11) | (regno << 6) | regno;
> 			break;
>
> Shouldn't it be?
>
> 		pal[regno] = (regno << 11) | (regno << 5) | regno;
>
Maybe, but I work on mach64 driver. In atyfb_base.c#2671 it is really
pal[regno] = (regno << 11) | (regno << 5) | regno;
> 2. In RGB555, isn't it better to fill up all the 8 slots per index per
> channel (256/32), instead of just (regno * 8)? For RGB565, that will be 8
> slots per red and blue, 4 slots per green (256/64).
>
> So something like this for RGB555, ie:
>
> 	for  (i = 0; i < 8; i++) {
> 		aty128_st_pal((regno * 8) + i, red, green, blue, par);
>
> RGB565 is a bit more complicated because green is deeper, but is doable.
>
> Tony
>
> DISCLAIMER: I know nothing about this hardware, I'm probably shooting
> blanks :-)


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click

Re: [PATCH] atyfb: vblank irq support

[Antonino A. Daplas]

On Monday 26 July 2004 02:36, Alexander Kern wrote:
> Am Sonntag, 25. Juli 2004 02:03 schrieb Antonino A. Daplas:
> > On Sunday 25 July 2004 07:12, Alexander Kern wrote:
> > > P.S. Now the last consumer from fb_load_cursor_image is neo driver.
> > > Should we drop this function, it's buggy!
> >
> > We should.  fb_load_cursor_image() cannot be generic.
>
> fine, do you make it for neo driver?

I think James did it for neofb. 

We can just move it to one of neofb's file and rename it 
neofb_load_cursor_image().

>
> > > Steel on my TODO list:
> > >
> > > Issue with 16bpp mode, brocken boot logo, fbi has problems too.
> >
> > 1. aty128fb_setcolreg has this lines:
> >
> > 		case 16:
> > 			pal[regno] = (regno << 11) | (regno << 6) | regno;
> > 			break;
> >
> > Shouldn't it be?
> >
> > 		pal[regno] = (regno << 11) | (regno << 5) | regno;
>
> Maybe, but I work on mach64 driver. In atyfb_base.c#2671 it is really
> pal[regno] = (regno << 11) | (regno << 5) | regno;

Ok, I got confused since I was looking at a different patchset. 

Tony




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click

Re: [PATCH] atyfb: vblank irq support

[Ville Syrjälä]

On Sun, Jul 25, 2004 at 08:29:10PM +0200, Alexander Kern wrote:
> Am Sonntag, 25. Juli 2004 12:16 schrieb Ville Syrjälä:
> > On Sun, Jul 25, 2004 at 01:12:18AM +0200, Alexander Kern wrote:
> > > Issue with 24bpp mode and fbtest, yellow parts of pinguin image are
> > > blue!!!
> >
> > I've never tried 24bpp because of limited acceleration support. I haven't
> > even bothered implenenting 24bpp acceleration in the DirectFB driver.
> Interesting, I thought 24bpp hardware acceleration is complete? What is 
> missed?

For fbcon probably nothing. But I think mach64 can't draw besenham lines 
or use the front end scaler/3D pipe with 24bpp. Those two are enough to 
keep me from using it and maybe there were some additional limitations as 
well.

PS.
The cursor code appears to be working quite well. One small problem: The 
cursor is invisble it's while moving. But that's probably a problem with 
the generic cursor code. And it may have been fixed already (I'm still 
running 2.6.5-mm6 + quite a bit of patches).

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


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id\x10040&op=click

[Question] Colour management

[Alexander Kern]

Hallo Tony,

can you explain the deep mining of fb_setcolreg. Background, I observe wrong 
palette using in 15 and 16 bpp modes, but can not understand, what is 
the right approach. In both cases from penguin logo I can see only contour in 
honey yellow and blue vertical string jsimmons, pretty scury ;-) The rest is 
black! The simple text or ncurses applications have always right colours.
Additionally and only by 16bpp fbi shows blurry images. In 15bpp fbi works 
fine. fbtest works fine and his penguins look good in all resolutions ?!

Regards Alex

P.S. where is our current tree of fbdev changes?


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: [Question] Colour management

[Antonino A. Daplas]

On Saturday 31 July 2004 02:12, Alexander Kern wrote:
> Hallo Tony,
>
> can you explain the deep mining of fb_setcolreg. Background, I observe
> wrong palette using in 15 and 16 bpp modes, but can not understand, what is
> the right approach. In both cases from penguin logo I can see only contour
> in honey yellow and blue vertical string jsimmons, pretty scury ;-) The
> rest is black! The simple text or ncurses applications have always right
> colours. Additionally and only by 16bpp fbi shows blurry images. In 15bpp
> fbi works fine. fbtest works fine and his penguins look good in all
> resolutions ?!

This will need a long answer. (For mistakes or ommisions, please let me know)

fb_setcolreg has 2 functions, initialize info->pseudopalette (if needed) and
initialize the hardware CLUT (if needed).  To do this properly, the driver
must set several variables and correctly advertise these variables using
various fields in struct fb_info.  These fields are:

1. info->var.bits_per_pixel
This is self-explanatory.  bits_per_pixel is _not_ the color depth.  

2. info->fix.visual
The field 'visual' has information on the following:

	a. if the hardware CLUT can be set or not

	If the CLUT can be set, then visual is either DIRECTCOLOR or
PSEUDOCOLOR. Otherwise, use TRUECOLOR, STATIC_PSEUDOCOLOR or MONO01/MONO02.

	b. If the pixel has separate information for all channels
	 (red, green, blue)

	Pseudocolor type visuals can only control a set of R, G, and
B.  Truecolor or directcolor have bitfields assigned for each color channel. 
Monocolor is assumed to be static pseudocolor where color depth == 1.

3. info->var.{red|green|blue|transp}
	These fields determine the depth and arrangement of each channel.  For
pseudocolor type visuals, all offsets are equal to zero and all lengths are
set to the same value (6 for 64-color EGA type framebuffer, 8 for 256-color
framebuffer)

	For truecolor or directcolor, the offsets are assigned different values.
So for RGB555, all lengths are assigned a value of 5 and offsets are at 0, 5 
and 10 respectiviely.

	This is where the color depth can be determined.  The color depth is not
necessarily equal to bits_per_pixel.  So for RGB555, the color depth is 15
(sum of all offsets) but bits_per_pixel is 16. For pseudocolor type, the
color depth == length of any of the channels.  (This is the reason I submitted a
patch that differentiates between color depth and bits_per_pixel).

4. info->cmap
	The struct cmap is the software representation of the hardware ClUT.  This 
is important to user apps.  Note, setting the cmap is important only for visuals where
the hardware CLUT is settable.  If the hardware CLUT is not settable (truecolor, etc),
then the app must get a copy of the cmap and only use the entries there.  However, most
user app probably ignore this and just attempt to pass its own copy of the cmap to
the driver.  Most of the time it works, but can break for some weird hardware.  For,
example, some mono framebuffer use 0 for white and 1 for black.  Fortunately, we have
a simple way of checking this by using info->fix.visuals.

Finally, we go to fb_setcolreg.  I mentioned the above because they are all needed
for fb_setcolreg to function properly. Its 2 main functions are:

1. initialize info->pseudopalette.

The pseudopalette is only used by the console, and is not even seen by userspace.
Furthermore, the pseudopalette is used only when in truecolor or directcolor mode
and is only 16 entries long (to match console palette).

Setting the pseudopalette depends on the visual.  In truecolor mode, the pseudocode
is something like this:

pseudopalette[index] = (red & redmask) << offset | (green & greenmask) << offset |
			(blue & bluemask) << offset;

*The mask is determined by the {red|green|blue}.length and offset by 
{red|green|blue}.offset.

In directcolor, it's easier:

pseudopalette[index] = (index << red.offset) | (index << green.offset) |
			 (index << blue.offset);

2. Setting the hardware ClUT.
	This is very driver dependent, but most drivers will follow
the description below.

	(This is needed only on pseudocolor and directcolor mode, since
they are the only visuals where the hardware CLUT can be set.  However,
some drivers still set the CLUT even in truecolor.  This does not really
matter since the hardware will probably just ignore those commands).

	Setting the CLUT is easy when in pseudocolor, or in directcolor
where channel size == CLUT register size. Basically:

red_reg[index] = red;
green_reg[index] = green;
blue_reg[index] = blue;

	In directcolor mode where the channel size != CLUT register size, setting
the CLUT is a bit tricky. 

Take for example, RGB555. Assuming an 8-bit CLUT size, each channel can only
accept a total of 32 entries (2 power of 5).  Since an 8-bit CLUT has 256 entries,
then the driver needs to step by 8 (256/32).  The code is like this then:

red_reg[index * 8] = red
green_reg[index * 8] = green
blue_reg[index * 8] = blue

Some hardware require that all 8 entries needs to be filled up.  Visually
this will look something like this:

reg	R G B
--------------
0	0 0 0 << (index * step) 
1	0 0 0
2  	0 0 0
3	0 0 0
4	0 0 0
5	0 0 0
6	0 0 0 
7	0 0 0
8	1 1 1 
9	1 1 1
10	1 1 1
11	1 1 1	
12	1 1 1
13	1 1 1
14	1 1 1
15	1 1 1

This even gets trickier in RGB565 since red and blue has 32 entries
with stepping 8 and green has 64 with a stepping 4. 

red_reg[index * 8] = red
green_reg[index * 4] = green
blue_reg[index * 8] = blue

Reg 	R G B
--------------
0	0 0 0
1	0 0 0
2  	0 0 0
3	0 0 0
4	0 1 0 << index * 4 for green
5	0 1 0
6	0 1 0 
7	0 1 0
8	1 2 1 << index * 8 for red and blue
9	1 2 1
10	1 2 1
11	1 2 1	
12	1 3 1
13	1 3 1
14	1 3 1
15	1 3 1

As you can see from the above, greens are interspersed with the reds and 
blues.

(For actual code examples, see i810fb)

So how to diagnose:

1. wrong console colors, correct colors in userspace apps:

This is easy.  Basically, the driver sets almost everything correctly.
If the console colors are wrong then most probably this is due to 
setting the pseudopalette incorrectly:

	a. Hardware is in truecolor, but pseudopalette is set
	directcolor style, or vice versa. This is actually a very common
	error.

	b, Driver uses software functions (cfb_*) but pseudopalette
	is set at (u16 *).  All cfb_* functions assume a pseudopalette
	to be (u32*) whatever the value of color depth or bits_per_pixel is.

	c. Driver uses it's own broken drawing functions.

2. correct console colors, incorrect colors with userspace apps:

Driver side:
	a. Is info->visuals set correctly? (Do not set DIRECTCOLOR if
	hardware can only due TRUECOLOR)

	b. Are the fields info->var.{red|green|blue} set correctly?  This
	is what the app uses to differentiate between RGB565 vs RGB555,
	for example.

	c. Is info->var.bits_per_pixel set correctly?  RGB555 is still 16,
	not 15.

	d. Is the driver setting the hardware CLUT correctly?  Very common
	error, especially with directcolor RGB565 or RGB555. See above how
	the CLUT should be set.

Client side:
	a. Does the application know the difference between directcolor and
	truecolor?  Drawing truecolor pixels in a directcolor framebuffer will
	usually produce wrong colors.

	b. Does the application know how to derive the information from the
	fields in info->var.{red|green|blue}?

	c. Is the cmap set properly by the driver when in directcolor or pseudocolor?
	Not setting the cmap means hardware might use 'stale' values in its table.

	d. Does the application's rasterizing function work correctly?  Drawing
	in 24 bits per pixel is a little difficult compared to 16 or 32 bits.

3. wrong colors everywhere

	Basically just check everything.

>
> P.S. where is our current tree of fbdev changes?

James is the maintainer of fbdev.  However, the tree has not been updated
for a long time.  Most developers also submit changes to Andrew, so just 
check the mm tree for now until James can get enough time to fix the fbdev
tree.

Tony




-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: [Question] Colour management

[Ville Syrjälä]

On Sat, Jul 31, 2004 at 06:26:27PM +0800, Antonino A. Daplas wrote:
> 	In directcolor mode where the channel size != CLUT register size, setting
> the CLUT is a bit tricky. 
> 
> Take for example, RGB555. Assuming an 8-bit CLUT size, each channel can only
> accept a total of 32 entries (2 power of 5).  Since an 8-bit CLUT has 256 entries,
> then the driver needs to step by 8 (256/32).  The code is like this then:
> 
> red_reg[index * 8] = red
> green_reg[index * 8] = green
> blue_reg[index * 8] = blue
> 
> Some hardware require that all 8 entries needs to be filled up.

I noticed you do this in i810fb. What happens if you don't do this?

AFAIK mach64 doesn't need this.

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


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: Re: [Question] Colour management

[Antonino A. Daplas]

On Saturday 31 July 2004 21:31, Ville Syrjälä wrote:
> >
> > red_reg[index * 8] = red
> > green_reg[index * 8] = green
> > blue_reg[index * 8] = blue
> >
> > Some hardware require that all 8 entries needs to be filled up.
>
> I noticed you do this in i810fb. What happens if you don't do this?
 
Wrong colors.  

>
> AFAIK mach64 doesn't need this.

Yes, it's hardware dependent. When I decided to add directcolor support,
I initially copied the mach64's setcolreg function but I got wrong
colors at bpp16.  Found out by experimentation that I need to set all
256 entries of the CLUT.

Tony  




-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: [Question] Colour management

[Ville Syrjälä]

[-- Attachment #1: Type: text/plain, Size: 893 bytes --]

On Fri, Jul 30, 2004 at 08:12:36PM +0200, Alexander Kern wrote:
> 
> Hallo Tony,
> 
> can you explain the deep mining of fb_setcolreg. Background, I observe wrong 
> palette using in 15 and 16 bpp modes, but can not understand, what is 
> the right approach. In both cases from penguin logo I can see only contour in 
> honey yellow and blue vertical string jsimmons, pretty scury ;-) The rest is 
> black! The simple text or ncurses applications have always right colours.
> Additionally and only by 16bpp fbi shows blurry images.

I just had a look at the fbi code and it's wrong. It was initializing the 
clut to 555. The attached patch fixes the problem.

I think the boot logo code is broken. No, I haven't actually looked at it 
but everything else works... Or does it work on some other directcolor hw?

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

[-- Attachment #2: fbi_directcolor_565_fix.patch --]
[-- Type: text/plain, Size: 1345 bytes --]

--- fbi-1.31/fbi.c	2004-02-22 14:24:29.000000000 +0200
+++ fbi-1.31/fbi.c	2004-08-01 00:57:45.375251160 +0300
@@ -760,12 +760,19 @@
 }
 
 static void
-linear_palette(int bit)
+linear_palette(int r, int g, int b)
 {
-    int i, size = 256 >> (8 - bit);
-    
+    int i, size;
+
+    size = 256 >> (8 - r);
+    for (i = 0; i < size; i++)
+	red[i] = calc_gamma(i,size);
+    size = 256 >> (8 - g);
     for (i = 0; i < size; i++)
-        red[i] = green[i] = blue[i] = calc_gamma(i,size);
+	green[i] = calc_gamma(i,size);
+    size = 256 >> (8 - b);
+    for (i = 0; i < size; i++)
+	blue[i] = calc_gamma(i,size);
 }
 
 static void
@@ -1391,21 +1398,23 @@
 	break;
     case 15:
     case 16:
-        if (fb_fix.visual == FB_VISUAL_DIRECTCOLOR)
-            linear_palette(5);
 	if (fb_var.green.length == 5) {
+	    if (fb_fix.visual == FB_VISUAL_DIRECTCOLOR)
+		linear_palette(5,5,5);
 	    lut_init(15);
 	} else {
+	    if (fb_fix.visual == FB_VISUAL_DIRECTCOLOR)
+		linear_palette(5,6,5);
 	    lut_init(16);
 	}
 	break;
     case 24:
         if (fb_fix.visual == FB_VISUAL_DIRECTCOLOR)
-            linear_palette(8);
+            linear_palette(8,8,8);
 	break;
     case 32:
         if (fb_fix.visual == FB_VISUAL_DIRECTCOLOR)
-            linear_palette(8);
+            linear_palette(8,8,8);
 	lut_init(24);
 	break;
     default:

Re: [Question] Colour management

[Ville Syrjälä]

On Sat, Jul 31, 2004 at 06:26:27PM +0800, Antonino A. Daplas wrote:
> On Saturday 31 July 2004 02:12, Alexander Kern wrote:
> > Hallo Tony,
> >
> > can you explain the deep mining of fb_setcolreg. Background, I observe
> > wrong palette using in 15 and 16 bpp modes, but can not understand, what is
> > the right approach. In both cases from penguin logo I can see only contour
> > in honey yellow and blue vertical string jsimmons, pretty scury ;-) The
> > rest is black! The simple text or ncurses applications have always right
> > colours. Additionally and only by 16bpp fbi shows blurry images. In 15bpp
> > fbi works fine. fbtest works fine and his penguins look good in all
> > resolutions ?!
> 
> This will need a long answer. (For mistakes or ommisions, please let me know)
> 
> fb_setcolreg has 2 functions, initialize info->pseudopalette (if needed) and
> initialize the hardware CLUT (if needed).

BTW fb_setcolreg ends up writing half of the registers twice (more if you 
have to fill all slots). It might be better to have two functions. The 
first one would be the current fb_setcolreg except it wouldn't actually 
write anything. It would only fill in the correct register values. And the 
second one would write the clut to hardware. That would avoid the multiple 
writes.

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


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: Re: [Question] Colour management

[Alexander Kern]

[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]

Am Samstag, 31. Juli 2004 23:19 schrieb Antonino A. Daplas:
> On Saturday 31 July 2004 21:31, Ville Syrjälä wrote:
> > > red_reg[index * 8] = red
> > > green_reg[index * 8] = green
> > > blue_reg[index * 8] = blue
> > >
> > > Some hardware require that all 8 entries needs to be filled up.
> >
> > I noticed you do this in i810fb. What happens if you don't do this?
>
>  
> Wrong colors.
>
> > AFAIK mach64 doesn't need this.
>
> Yes, it's hardware dependent. When I decided to add directcolor support,
> I initially copied the mach64's setcolreg function but I got wrong
> colors at bpp16.  Found out by experimentation that I need to set all
> 256 entries of the CLUT.
>
> Tony
Very scurry, even mach64 give wrong colors for me ;-))

Here are the pics, that demonstrate my errors.

empty-penguin.jpg shows how looks my boot logo at 15 and 16bpp
Sorry for wrong description in previous mail. Text string is not JSimmons but 
simple Simmons.

fbi-shows-wrongcolors.jpg shows fbi gives wrong colors at 16bpp, must be 
yellow, got red.

Regards Alex

P.S. maybe boot logo function is not too good client?

[-- Attachment #2: empty-penguin.jpg --]
[-- Type: image/jpeg, Size: 35642 bytes --]

[-- Attachment #3: fbi-shows-wrongcolors.jpg --]
[-- Type: image/jpeg, Size: 71923 bytes --]

Re: Re: [Question] Colour management

[Antonino A. Daplas]

On Sunday 01 August 2004 06:19, Alexander Kern wrote:
> Am Samstag, 31. Juli 2004 23:19 schrieb Antonino A. Daplas:
> > On Saturday 31 July 2004 21:31, Ville Syrjälä wrote:
> > > > red_reg[index * 8] = red
> > > > green_reg[index * 8] = green
> > > > blue_reg[index * 8] = blue
> > > >
> > > > Some hardware require that all 8 entries needs to be filled up.
> > >
> > > I noticed you do this in i810fb. What happens if you don't do this?
> >
> >  
> > Wrong colors.
> >
> > > AFAIK mach64 doesn't need this.
> >
> > Yes, it's hardware dependent. When I decided to add directcolor support,
> > I initially copied the mach64's setcolreg function but I got wrong
> > colors at bpp16.  Found out by experimentation that I need to set all
> > 256 entries of the CLUT.
> >
> > Tony
>
> Very scurry, even mach64 give wrong colors for me ;-))
>
> Here are the pics, that demonstrate my errors.

Actually, this is one of the nuances that affect DirectColor at < 24 bpp.
Since RGB565 has only at the most 64 entries (based on the depth of
the green channel), a 224-color logo will be drawn incorrectly. 16-bit
Directcolor actually needs a 16-color logo. Unfortuanately, the logo
drawing code will choose a 224-color logo for Directcolor 16-bit.  This is
problem that I pointed out to James a long time ago when he rewrote the 
logo drawing code. 

It's a little bit surprising that 8-bit pseudocolor can actually draw a
224-color logo correctly, while 16-bit directcolor cannot :-)

Workaround:
	Force fbdev to use 16-color linux logo in the "Boot Logo" option
	of your kernel config.

I'll see if I can find a way for a more definitive fix.

Tony

P.S. This problem might be unique to the logo drawing code.




-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: Re: [Question] Colour management

[Antonino A. Daplas]

On Sunday 01 August 2004 06:18, Ville Syrjälä wrote:
> On Sat, Jul 31, 2004 at 06:26:27PM +0800, Antonino A. Daplas wrote:
> > On Saturday 31 July 2004 02:12, Alexander Kern wrote:
> > > Hallo Tony,
> > >
> > > can you explain the deep mining of fb_setcolreg. Background, I observe
> > > wrong palette using in 15 and 16 bpp modes, but can not understand,
> > > what is the right approach. In both cases from penguin logo I can see
> > > only contour in honey yellow and blue vertical string jsimmons, pretty
> > > scury ;-) The rest is black! The simple text or ncurses applications
> > > have always right colours. Additionally and only by 16bpp fbi shows
> > > blurry images. In 15bpp fbi works fine. fbtest works fine and his
> > > penguins look good in all resolutions ?!
> >
> > This will need a long answer. (For mistakes or ommisions, please let me
> > know)
> >
> > fb_setcolreg has 2 functions, initialize info->pseudopalette (if needed)
> > and initialize the hardware CLUT (if needed).
>
> BTW fb_setcolreg ends up writing half of the registers twice (more if you
> have to fill all slots). It might be better to have two functions. The
> first one would be the current fb_setcolreg except it wouldn't actually
> write anything. It would only fill in the correct register values. And the
> second one would write the clut to hardware. That would avoid the multiple
> writes.

Yes, we also need to separate the imageblit into a mono_src_color_expand
(for text drawing) and an 8_bit_src_color_expand (for the logo).  Both proposals
will affect all drivers so let's leave it as is for now (unless you want to risk
the ire again of the fbdev driver maintainers, they're a bit touchy from the
numerous breakages of the API :-)

Tony




-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: Re: [Question] Colour management

[Antonino A. Daplas]

On Sunday 01 August 2004 06:10, Ville Syrjälä wrote:
> On Fri, Jul 30, 2004 at 08:12:36PM +0200, Alexander Kern wrote:
> > Hallo Tony,
> >
> > can you explain the deep mining of fb_setcolreg. Background, I observe
> > wrong palette using in 15 and 16 bpp modes, but can not understand, what
> > is the right approach. In both cases from penguin logo I can see only
> > contour in honey yellow and blue vertical string jsimmons, pretty scury
> > ;-) The rest is black! The simple text or ncurses applications have
> > always right colours. Additionally and only by 16bpp fbi shows blurry
> > images.
>
> I just had a look at the fbi code and it's wrong. It was initializing the
> clut to 555. The attached patch fixes the problem.

I know that this is just a test patch but instead of hardwiring the parameters 
of linear_palette, why not do:

linear_palette(var.red.length, var.green.length, var.blue.length)

This way you can catch unusual RGB combinations (ie, RGB484, if there is such 
a thing) and still get correct colors.  You can also eliminate the switch() 
statement, and makes it easier to catch fbdev bugs.

>
> I think the boot logo code is broken. No, I haven't actually looked at it
> but everything else works... Or does it work on some other directcolor hw?

Yes, the logo code is broken, not the drawing code itself, but the logo 
choosing code. As I've mentioned in another thread, 16-bit directcolor cannot 
draw 224-color logos.

Tony




-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com