[PATCH] atyfb: vblank irq support

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/

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?

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

On Sun, Jul 25, 2004 at 01:12:18AM +0200, Alexander Kern wrote:

Am Donnerstag, 22. Juli 2004 20:49 schrieb Ville Syrjälä:

quoted

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_id040&op=click

Am Sonntag, 25. Juli 2004 12:16 schrieb Ville Syrjälä:

On Sun, Jul 25, 2004 at 01:12:18AM +0200, Alexander Kern wrote:

quoted

Am Donnerstag, 22. Juli 2004 20:49 schrieb Ville Syrjälä:

quoted

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.

quoted

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_id040&op=click

Am Sonntag, 25. Juli 2004 02:03 schrieb Antonino A. Daplas:

On Sunday 25 July 2004 07:12, Alexander Kern wrote:

quoted

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?

quoted

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

On Monday 26 July 2004 02:36, Alexander Kern wrote:

Am Sonntag, 25. Juli 2004 02:03 schrieb Antonino A. Daplas:

quoted

On Sunday 25 July 2004 07:12, Alexander Kern wrote:

quoted

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().

quoted

quoted

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

On Sun, Jul 25, 2004 at 08:29:10PM +0200, Alexander Kern wrote:

Am Sonntag, 25. Juli 2004 12:16 schrieb Ville Syrjälä:

quoted

On Sun, Jul 25, 2004 at 01:12:18AM +0200, Alexander Kern wrote:

quoted

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_id040&op=click

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

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

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

On Saturday 31 July 2004 21:31, Ville Syrjälä wrote:

quoted

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

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/

On Sat, Jul 31, 2004 at 06:26:27PM +0800, Antonino A. Daplas wrote:

On Saturday 31 July 2004 02:12, Alexander Kern wrote:

quoted

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

Am Samstag, 31. Juli 2004 23:19 schrieb Antonino A. Daplas:

On Saturday 31 July 2004 21:31, Ville Syrjälä wrote:

quoted

quoted

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.

quoted

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?

On Sunday 01 August 2004 06:19, Alexander Kern wrote:

Am Samstag, 31. Juli 2004 23:19 schrieb Antonino A. Daplas:

quoted

On Saturday 31 July 2004 21:31, Ville Syrjälä wrote:

quoted

quoted

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.

quoted

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

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:

quoted

On Saturday 31 July 2004 02:12, Alexander Kern wrote:

quoted

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

On Sunday 01 August 2004 06:10, Ville Syrjälä wrote:

On Fri, Jul 30, 2004 at 08:12:36PM +0200, Alexander Kern wrote:

quoted

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