linux-fbdev-devel — linux-fbdev mailing list for project developers

Re: [Linux-fbdev-devel] pm3fb driver is ok in 2.5.24

[Romain D. <do...@ir...>]

Sven Luther wrote:

> > api. I'm going to removal the old fbgen code soon.
> 
> how soon, and is there documentation or sample code for the changed api
> ?

According from a recent message by James Simmons on LKML:

>        Note I removed the old fbgen stuff so some drivers are going to
> break. Well with time running out I need to push ahead. Sorry but I have
> to choose.

So pm3fb won't work anymore I guess (due to the ultimate brokenness
of linux on PowerPC I haven't yet ported pm3fb to the new API).

-- 
DOLBEAU Romain               | Nothing is real but the way that I feel  
ENS Cachan / Ker Lann        | And I feel like going down, down, down   
Thesard IRISA / CAPS         |   -- Rainbow,                            
dol...@cl...    |                 'Self Portrait'

Re: [Linux-fbdev-devel] pm3fb driver is ok in 2.5.24

[Sven L. <lu...@la...>]

On Mon, Jul 01, 2002 at 09:59:16AM -0700, James Simmons wrote:
> 
> > > still is problem with the copying of the text console data at bootup,
> > > but apart from that everything is fine.
> > >
> > > Should i send over a patch for adding it to the Config.xxx files ?
> >
> > Please send me the patch, I'll submit them for inclusion
> 
> Good news. I already included Config.help and Config.in entries for the
> PM3 driver. As a note please consider porting it over to the new fbgen

nice :)))

> api. I'm going to removal the old fbgen code soon.

how soon, and is there documentation or sample code for the changed api
?

BTW, i suppose now it will be easier to implement dual head with a dual
output board ?

Friendly,

Sven Luther
> 

Re: [Linux-fbdev-devel] pm3fb driver is ok in 2.5.24

[Sven L. <lu...@la...>]

On Mon, Jul 01, 2002 at 09:57:49AM +0200, Romain Dolbeau wrote:
> Sven Luther wrote:
> 
> > I have compiled a 2.5.24 kernel and added the few things needed to make
> > the pm3fb work (basically, i had to patch Config.in and Config.help so i
> > could enable it in the configuration process).
> 
> Could you send me the patch please ?

Ok, but they are triviel (attached here ...)

> > Is there a reason why it was not enabled previously, or is it just
> > forgetting the these two files (which probably did not patch correctly
> > due to the Config.in and Config.help location and format change).
> 
> I though the old-format drivers wouldn't work so I never bothered
> submitting for inclusion.

:)))

> > Anyway, it works fine (well as good as with the 2.4.x kernel), there
> > still is problem with the copying of the text console data at bootup,
> > but apart from that everything is fine.
> > 
> > Should i send over a patch for adding it to the Config.xxx files ?
> 
> Please send me the patch, I'll submit them for inclusion

Ok, ...

Friendly,

Sven Luther

[Linux-fbdev-devel] Re: [PATCH] New Console system BK

[Skip F. <ski...@ve...>]

James Simmons wrote:
> 
> Since 2.5.1 I have placed into the kernel part of the new console system
> code into the DJ tree. So it has been well tested. I was hoping to have
> all the keyboard devices ported over to the input api and the fbdev
> drivers over to the new api. Unfortunely due to time restraints this will
> not be the case. So here goes the first installment of the new console
> system. Please test it yourselves and I will push it to Linus soon.
> 
>  http://www.transvirtual.com/~jsimmons/console.diff.gz

With your patch, I have to release the alt key between Fx keys to change
VTs.  Is that intentional?

Without the patch, I can hold down alt and hit F1, F2, F3, F4, then
release the alt key and I will have switched to each of the VTs.
With this patch, I have to press/release alt for each Fx key.

-- 
Skip

[Linux-fbdev-devel] [PATCH] New Console system BK

[James S. <jsi...@tr...>]

Since 2.5.1 I have placed into the kernel part of the new console system
code into the DJ tree. So it has been well tested. I was hoping to have
all the keyboard devices ported over to the input api and the fbdev
drivers over to the new api. Unfortunely due to time restraints this will
not be the case. So here goes the first installment of the new console
system. Please test it yourselves and I will push it to Linus soon.

The goal is to create a system we can use keyboards without the console
system and the same true for framebuffer devices. This is most helpful on
embedded devices. The other goals to make the VT console system more
modular and lighter weight. The other goal is to make the VT tty system
multi-desktop.

Here are the changes so far:

I) Removal of struct kbd_struct from the sysrq handler. Why drag itr along
   when only two sysrq functions actually use it.

II) Massive rewrite and cleanup of keybaord.c.

III) Place struct tty_struct into struct vc_data. This sets up a one to
     one relationship. Avoids the nasty tricks of playing with fields from
     console_driver.

IV) Cleanup of VT tty/console initialization. A vty_init function to make
    it cleaner.

diffstat:

 arch/i386/kernel/apm.c         |    2
 arch/ppc/xmon/start.c          |    2
 arch/ppc64/xmon/start.c        |    2
 drivers/acpi/system.c          |    2
 drivers/char/console.c         |   82 ++--
 drivers/char/keyboard.c        |  779 +++++++++++++++++++++--------------------
 drivers/char/sysrq.c           |   46 +-
 drivers/char/tty_io.c          |   15
 include/linux/console_struct.h |    1
 include/linux/sysrq.h          |   13
 11 files changed, 485 insertions(+), 459 deletions(-)


The BK patch is at:

 http://linuxconsole.bkbits.net/dev

diff:

 http://www.transvirtual.com/~jsimmons/console.diff.gz

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'\_   _/`\
 \___)=(___/

[Linux-fbdev-devel] [PATCH] fbdev updates.

[James S. <jsi...@tr...>]

Here are the latest updates to the framebuffer layer. Please test it outso
I can push it as soon as possible to Linus. Here is what has changes. The
* are tested drivers. As a note there are a few issues with a few of the
drivers but time is running out so I need to push the changes then fix any
remaining bugs. Links to the chnages are:

BK:            http://www.fbdev.bkbits.net/fbdev-2.5

diff:		http://www.transvirtual.com/~jsimmons/fbdev.diff.gz


P.S
       Note I removed the old fbgen stuff so some drivers are going to
break. Well with time running out I need to push ahead. Sorry but I have
to choose.


 Documentation/fb/README-sstfb.txt     |   87
 arch/i386/boot/video.S                |    4    *
 arch/ppc/Config.help                  |    6
 arch/ppc/config.in                    |    3
 drivers/char/vt.c                     |   66    *
 drivers/video/Config.help             |   22    *
 drivers/video/Config.in               |   80    *
 drivers/video/Makefile                |   15    *
 drivers/video/S3triofb.c              |   19
 drivers/video/acornfb.c               |    3
 drivers/video/amifb.c                 |   81
 drivers/video/atafb.c                 |  376 ++-
 drivers/video/aty/atyfb.h             |   18               *
 drivers/video/aty/atyfb_base.c        |  348 +--           *
 drivers/video/aty/mach64.h            | 1158 ------------  *
 drivers/video/aty/mach64_accel.c      |    2               *
 drivers/video/aty/mach64_ct.c         |    4 		    *
 drivers/video/aty/mach64_cursor.c     |   12               *
 drivers/video/aty/mach64_gx.c         |    2 		    *
 drivers/video/aty128.h                |  352 ---	    *
 drivers/video/aty128fb.c              | 3272
++++++++++++++-------------------- *
 drivers/video/chipsfb.c               |   29
 drivers/video/controlfb.c             |   21
 drivers/video/dnfb.c                  |   19
 drivers/video/fbcon-mac.c             |  483 -----
 drivers/video/fbcon-vga.c             |  213 --
 drivers/video/fbcon.c                 |    2                	*
 drivers/video/fbgen.c                 |  347 ---		*
 drivers/video/fbmem.c                 |    2 			*
 drivers/video/fm2fb.c                 |    3
 drivers/video/fonts.c                 |    4
 drivers/video/hpfb.c                  |    3
 drivers/video/imsttfb.c               |   56
 drivers/video/macfb.c                 |  463 +---
 drivers/video/macmodes.c              |  171 -
 drivers/video/matrox/matroxfb_base.c  |   43
 drivers/video/matrox/matroxfb_base.h  |    6
 drivers/video/matrox/matroxfb_crtc2.c |   19
 drivers/video/modedb.c                |    4
 drivers/video/neofb.c                 |    7 			*
 drivers/video/offb.c                  | 1130 ++++-------
 drivers/video/platinumfb.c            |   26
 drivers/video/q40fb.c                 |    8
 drivers/video/retz3fb.c               |    4
 drivers/video/riva/Makefile           |    2 			*
 drivers/video/riva/accel.c            |  427 ----		*
 drivers/video/riva/fbdev.c            | 1531 ++++++---------	*
 drivers/video/riva/riva_hw.c          |   38 			*
 drivers/video/riva/riva_hw.h          |    2 			*
 drivers/video/riva/rivafb.h           |   60 			*
 drivers/video/sa1100fb.c              |  813 ++------		*
 drivers/video/sa1100fb.h              |   17 			*
 drivers/video/sgivwfb.c               | 1432 ++++++--------
 drivers/video/sgivwfb.h               |  660 ------
 drivers/video/sstfb.c                 |  958 +++++----
 drivers/video/sstfb.h                 |   73
 drivers/video/tdfxfb.c                |   55 			*
 drivers/video/tx3912fb.c              |    2
 drivers/video/valkyriefb.c            |   26
 drivers/video/vesafb.c                |   12 			*
 drivers/video/vfb.c                   |    4
 include/asm-ppc/vc_ioctl.h            |   46
 include/asm-ppc64/vc_ioctl.h          |   50
 include/linux/fb.h                    |   52
 include/linux/pci_ids.h               |    1
 include/linux/tty.h                   |    3
 include/video/aty128.h                |  419 ++++
 include/video/mach64.h                | 1158 ++++++++++++
 include/video/sgivw.h                 |  660 ++++++
 70 files changed, 6886 insertions(+), 10608 deletions(-)

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'\_   _/`\
 \___)=(___/

[Linux-fbdev-devel] Re: [PATCH] 2.5.24 matroxfb memory corruption

[James S. <jsi...@tr...>]

> do_install_cmap(), he blindly changed also matroxfb, which happily
> uses fbcon.currcon == -1. This caused memory corruption because of
> memory before fb_display[] array was overwritten.
>   Default do_install_cmap() also installed invalid default color map
> in some matroxfb resolutions. Not all world have >= 4bpp.

Applied to BK tree.

[Linux-fbdev-devel] Re: [PATCH] 2.5.24 matroxfb off by one error

[James S. <jsi...@tr...>]

Applyed to the fbdev BK tree.

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'\_   _/`\
 \___)=(___/

On Sun, 30 Jun 2002, Petr Vandrovec wrote:

> Hi Linus,
>    please apply patch below.
>
>    It fixes off by one error in getcolreg/setcolreg in matroxfb's
> secondary head driver.
> 					Thanks,
> 						Petr Vandrovec
> 						van...@vc...
>
>
> diff -urdN linux/drivers/video/matrox/matroxfb_crtc2.c linux/drivers/video/matrox/matroxfb_crtc2.c
> --- linux/drivers/video/matrox/matroxfb_crtc2.c	Fri Jun 21 00:53:48 2002
> +++ linux/drivers/video/matrox/matroxfb_crtc2.c	Sat Jun 29 00:09:09 2002
> @@ -29,7 +29,7 @@
>  static int matroxfb_dh_getcolreg(unsigned regno, unsigned *red, unsigned *green,
>  		unsigned *blue, unsigned *transp, struct fb_info* info) {
>  #define m2info ((struct matroxfb_dh_fb_info*)info)
> -	if (regno > 16)
> +	if (regno >= 16)
>  		return 1;
>  	*red = m2info->palette[regno].red;
>  	*blue = m2info->palette[regno].blue;
> @@ -44,7 +44,7 @@
>  #define m2info ((struct matroxfb_dh_fb_info*)info)
>  	struct display* p;
>
> -	if (regno > 16)
> +	if (regno >= 16)
>  		return 1;
>  	m2info->palette[regno].red = red;
>  	m2info->palette[regno].blue = blue;
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to maj...@vg...
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: [Linux-fbdev-devel] pm3fb driver is ok in 2.5.24

[Romain D. <do...@ir...>]

James Simmons wrote:

> Good news. I already included Config.help and Config.in entries for the
> PM3 driver. As a note please consider porting it over to the new fbgen
> api. I'm going to removal the old fbgen code soon.

It's on my TODO list, and has been for months.
But I still can't get 2.5.x to compile, much less work,
on my PPC box. So there's not much I can do ATM.

-- 
DOLBEAU Romain               | Who'd believe we'd spend more            
ENS Cachan / Ker Lann        | Shippin' drugs and guns                  
Thesard IRISA / CAPS         | Than to educate our sons?                
dol...@cl...    |   -- Megadeth, 'Youthanasia'

Re: [Linux-fbdev-devel] pm3fb driver is ok in 2.5.24

[James S. <jsi...@tr...>]

> > still is problem with the copying of the text console data at bootup,
> > but apart from that everything is fine.
> >
> > Should i send over a patch for adding it to the Config.xxx files ?
>
> Please send me the patch, I'll submit them for inclusion

Good news. I already included Config.help and Config.in entries for the
PM3 driver. As a note please consider porting it over to the new fbgen
api. I'm going to removal the old fbgen code soon.

Re: [Linux-fbdev-devel] pm3fb driver is ok in 2.5.24

[Romain D. <do...@ir...>]

Sven Luther wrote:

> I have compiled a 2.5.24 kernel and added the few things needed to make
> the pm3fb work (basically, i had to patch Config.in and Config.help so i
> could enable it in the configuration process).

Could you send me the patch please ?

> Is there a reason why it was not enabled previously, or is it just
> forgetting the these two files (which probably did not patch correctly
> due to the Config.in and Config.help location and format change).

I though the old-format drivers wouldn't work so I never bothered
submitting for inclusion.

> Anyway, it works fine (well as good as with the 2.4.x kernel), there
> still is problem with the copying of the text console data at bootup,
> but apart from that everything is fine.
> 
> Should i send over a patch for adding it to the Config.xxx files ?

Please send me the patch, I'll submit them for inclusion

Thanks for the help,

-- 
DOLBEAU Romain           | I witness a time and a place that never dies,
ENS Cachan / Ker Lann    | still frozen in time, this darkness the only 
Thesard IRISA / CAPS     | place that I can hide. I witness, a dream.   
dol...@cl...|  -- Black Sabbath, 'I Witness'

[Linux-fbdev-devel] pm3fb driver is ok in 2.5.24

[Sven L. <lu...@la...>]

Hello, ...

I have compiled a 2.5.24 kernel and added the few things needed to make
the pm3fb work (basically, i had to patch Config.in and Config.help so i
could enable it in the configuration process).

Is there a reason why it was not enabled previously, or is it just
forgetting the these two files (which probably did not patch correctly
due to the Config.in and Config.help location and format change).

Anyway, it works fine (well as good as with the 2.4.x kernel), there
still is problem with the copying of the text console data at bootup,
but apart from that everything is fine.

Should i send over a patch for adding it to the Config.xxx files ?

Friendly,

Sven Luther

[Linux-fbdev-devel] [PATCH] 2.5.24 matroxfb memory corruption

[Petr V. <van...@vc...>]

Hi,
  Linus, please apply this. When James converted all drivers to unified
do_install_cmap(), he blindly changed also matroxfb, which happily
uses fbcon.currcon == -1. This caused memory corruption because of
memory before fb_display[] array was overwritten.
  Default do_install_cmap() also installed invalid default color map
in some matroxfb resolutions. Not all world have >= 4bpp.
					Thanks,
						Petr Vandrovec
						van...@vc...


diff -urdN linux/drivers/video/matrox/matroxfb_base.c linux/drivers/video/matrox/matroxfb_base.c
--- linux/drivers/video/matrox/matroxfb_base.c	Fri Jun 21 00:53:55 2002
+++ linux/drivers/video/matrox/matroxfb_base.c	Sun Jun 30 02:19:15 2002
@@ -141,6 +141,19 @@
 
 
 /* --------------------------------------------------------------------- */
+static inline void my_install_cmap(WPMINFO2)
+{
+	/* Do not touch this code if you do not understand what it does! */
+	/* Never try to use do_install_cmap() instead. It is crap. */
+	struct fb_cmap* cmap = &ACCESS_FBINFO(currcon_display)->cmap;
+
+	if (cmap->len)
+		fb_set_cmap(cmap, 1, &ACCESS_FBINFO(fbcon));
+	else
+		fb_set_cmap(fb_default_cmap(ACCESS_FBINFO(curr.cmap_len)),
+			    1, &ACCESS_FBINFO(fbcon));
+}
+
 
 static void matrox_pan_var(WPMINFO struct fb_var_screeninfo *var) {
 	unsigned int pos;
@@ -869,7 +882,7 @@
 				up_read(&ACCESS_FBINFO(altout.lock));
 			}
 			matrox_cfbX_init(PMINFO display);
-			do_install_cmap(ACCESS_FBINFO(fbcon.currcon),&ACCESS_FBINFO(fbcon));
+			my_install_cmap(PMINFO2);
 #if defined(CONFIG_FB_COMPAT_XPMAC)
 			if (console_fb_info == &ACCESS_FBINFO(fbcon)) {
 				int vmode, cmode;
diff -urdN linux/drivers/video/matrox/matroxfb_crtc2.c linux/drivers/video/matrox/matroxfb_crtc2.c
--- linux/drivers/video/matrox/matroxfb_crtc2.c	Fri Jun 21 00:53:48 2002
+++ linux/drivers/video/matrox/matroxfb_crtc2.c	Sun Jun 30 02:19:15 2002
@@ -84,6 +84,19 @@
 #undef m2info
 }
 
+static inline void my_install_cmap(struct matroxfb_dh_fb_info* m2info)
+{
+	/* Do not touch this code if you do not understand what it does! */
+	/* Never try to use do_install_cmap() instead. It is crap. */
+	struct fb_cmap* cmap = &m2info->currcon_display->cmap;
+	
+	if (cmap->len)
+		fb_set_cmap(cmap, 1, &m2info->fbcon);
+	else
+		fb_set_cmap(fb_default_cmap(16), 1, &m2info->fbcon);
+}
+
+
 static void matroxfb_dh_restore(struct matroxfb_dh_fb_info* m2info,
 		struct my_timming* mt,
 		struct display* p,
@@ -439,7 +452,7 @@
 			up_read(&ACCESS_FBINFO(altout.lock));
 		}
 		matroxfb_dh_cfbX_init(m2info, p);
-		do_install_cmap(ACCESS_FBINFO(fbcon.currcon), &ACCESS_FBINFO(fbcon));
+		my_install_cmap(m2info);
 	}
 	return 0;
 #undef m2info

[Linux-fbdev-devel] [PATCH] 2.5.24 matroxfb off by one error

[Petr V. <van...@vc...>]

Hi Linus,
   please apply patch below.

   It fixes off by one error in getcolreg/setcolreg in matroxfb's 
secondary head driver.
					Thanks,
						Petr Vandrovec
						van...@vc...


diff -urdN linux/drivers/video/matrox/matroxfb_crtc2.c linux/drivers/video/matrox/matroxfb_crtc2.c
--- linux/drivers/video/matrox/matroxfb_crtc2.c	Fri Jun 21 00:53:48 2002
+++ linux/drivers/video/matrox/matroxfb_crtc2.c	Sat Jun 29 00:09:09 2002
@@ -29,7 +29,7 @@
 static int matroxfb_dh_getcolreg(unsigned regno, unsigned *red, unsigned *green,
 		unsigned *blue, unsigned *transp, struct fb_info* info) {
 #define m2info ((struct matroxfb_dh_fb_info*)info)
-	if (regno > 16)
+	if (regno >= 16)
 		return 1;
 	*red = m2info->palette[regno].red;
 	*blue = m2info->palette[regno].blue;
@@ -44,7 +44,7 @@
 #define m2info ((struct matroxfb_dh_fb_info*)info)
 	struct display* p;
 
-	if (regno > 16)
+	if (regno >= 16)
 		return 1;
 	m2info->palette[regno].red = red;
 	m2info->palette[regno].blue = blue;

[Linux-fbdev-devel] Re: rivafb problems with 2.5.24 + latest fbdev.diff patch

[Miles L. <mi...@me...>]

On Thu, 2002-06-27 at 13:24, James Simmons wrote:

<snip>

> > 2)  After booting, running the command "fbset -a 1600x1200-76"
> > causes the machine to lock up.  This same command worked fine
> > with 2.5.22.
> 
> I noticed. The mode did change for me but it locked up. Nothing was
> recorded either. Since you are using serial console can you define
> RIVAFBDEBUG in fbdev.c and send me your output.

I tried this, but nothing got emitted on the serial console.
The system locked up, as before.

<snip>

> > 4)  Lastly, I have not yet figured out how to get rivafb
> > in the 2.5 series to boot directly into 1600x1200x16 @ 76Hz.
> [snip]..
> 
> > I was then informed that I should use "video=riva:1600x1200@75-16",
> > since there is no 76Hz entry in linux/drivers/video/modedb.c.
> 
> I attempted that one as well. It didn't work for me either.

Hmm. So you don't know what the correct method to do this is?
Or this is the correct way and it simply is not working.

[Linux-fbdev-devel] Re: rivafb problems with 2.5.24 + latest fbdev.diff patch

[James S. <jsi...@tr...>]

> 1)  When I boot, when the rivafb is activated, I don't see Tux.
> Instead, where Tux should be, there are about four or five text
> rows that are completely white.  The scrolling boot information
> does appear below the white rectangle.

Normal for now. No tux until I write the code. The white is due to a bug
in the upper framebuffer console system. I plan to fix that in the near
future. First I have port everything over.

> 2)  After booting, running the command "fbset -a 1600x1200-76"
> causes the machine to lock up.  This same command worked fine
> with 2.5.22.

I noticed. The mode did change for me but it locked up. Nothing was
recorded either. Since you are using serial console can you define
RIVAFBDEBUG in fbdev.c and send me your output.

> 3)  After starting up XFree86, when I switch to one of the
> VTs, all characters are reversed!  The lines are not reversed,
> but each character is displayed flipped on its vertical axis.

My fault. I set the new RIVA driver to MSB mode for dealing with images.
The X server uses the opposite. I did that to reduce the amount of code in
the kernel driver. Unfortunely X is broken so I have to add back the extra
code again.

> 4)  Lastly, I have not yet figured out how to get rivafb
> in the 2.5 series to boot directly into 1600x1200x16 @ 76Hz.
[snip]..

> I was then informed that I should use "video=riva:1600x1200@75-16",
> since there is no 76Hz entry in linux/drivers/video/modedb.c.

I attempted that one as well. It didn't work for me either.

[Linux-fbdev-devel] My own frame buffer:-)

[D M <mic...@ho...>]

Grüezi!

Id like to build a small linux computer. I have a small industrial 486 board 
with some I/O's. Id like to connect a graphic LCD (mabe 128x64 pixel, 
monochrome) display to this IO port.

My question:
I would like to use a GUI (like picogui). Picogui is supporting the 
framebuffer. Now i would like to writing a kernel module that i can insert 
in runtime. After i can start picogui on this framebuffer. I don't need to 
have all the kernel messages/console on the display, just that, what picogui 
is writing to the framebuffer.
The kernel module has to get the data from picogui, to prepare for LCD and 
send it over the I/O port.

What do you think, is it easy, or is it a lot of work? Is it possible? Do i 
need to implement some ioctrl() routines? (Or better: Does a framebuffer 
application use ioctrl() commands?)

Thank you

David

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

[Linux-fbdev-devel] video mode selection for monochrome

[Manoj S. <man...@wi...>]

Hi,

I am trying to use framebuffer with a monochrome display (1bpp).  I need
to specify a suitable video mode at the boot time. I tried to use 'scan'
on the video mode prompt but didn't find anything for the monochrome.  
There is vesa mode for 640x480x8, Is there anything for 640x480x1 ?

The video card is S3 Trio 3D/2X.

Thanks,
Manoj.

Re: [Linux-fbdev-devel] radeonfb and 16bit color problem

[Benjamin H. <be...@ke...>]

>I thought that piece of code looked weird because it's setting green
>equal to rinfo->palette[regno<<1].green, but doesn't seem to ever use
>green during the rest of the function...

It should about 2 lines below ... at least in my tree.

>BTW, don't you mean 64 palette entries for green (being that it's 6
>bits)? 

Yah, sorry, typing too fast ;)

>Anyways, I took some time this weekend to look over the code
>some more, and I really doubt my problems originates in that function.
>As I understand it, the palette (colormap?) will only be used when
>displaying colors in text mode.

Hrm... there HW colormap is used in all modes in recent drivers, thus
you can actually set a gamma table. The driver should set it to a
linear ramp by default though that may be broken.

>My problem seems to affect many more colors (practically all 65536 of
>them), but I've yet to track it down.  I put in a request on ATI's
>website to get access to the specs (hoping that'll help me), but I
>haven't heard anything back from them yet.

Ben.

Re: [Linux-fbdev-devel] radeonfb and 16bit color problem

[Bryan S. <br...@bo...>]

On Mon, Jun 24, 2002 at 05:24:11AM +0200, Benjamin Herrenschmidt wrote:
>>Any ideas would be helpful.  I tried looking at the code myself, but I'm
>>still quite new to the framebuffer code.  However, this part looked kind
>>of strange to me:
>>
>>   /* For 565, the green component is mixed one order below */
>>   if (rinfo->depth == 16) {
>>      OUTREG(PALETTE_INDEX, pindex>>1);
>>      OUTREG(PALETTE_DATA, (rinfo->palette[regno>>1].red << 16) |
>>             (green << 8) | (rinfo->palette[regno>>1].blue));
>>      green = rinfo->palette[regno<<1].green;
>>   }
>>
>>
>>BTW, I have a Radeon 8500 (QL).
>
>I wrote that part and it works just fine on my powerbook... at least
>with the radeonfb version that is in my tree, but I don't think it
>differs from the official one in this regard. You can try making sure
>it's properly setting 32 palette entries for green when using that
>mode.

I thought that piece of code looked weird because it's setting green
equal to rinfo->palette[regno<<1].green, but doesn't seem to ever use
green during the rest of the function...

BTW, don't you mean 64 palette entries for green (being that it's 6
bits)?  Anyways, I took some time this weekend to look over the code
some more, and I really doubt my problems originates in that function.
As I understand it, the palette (colormap?) will only be used when
displaying colors in text mode.

My problem seems to affect many more colors (practically all 65536 of
them), but I've yet to track it down.  I put in a request on ATI's
website to get access to the specs (hoping that'll help me), but I
haven't heard anything back from them yet.

Thanks,
Bryan

PS I'll try checking out your tree the next time I get a chance and see
if I still see the problem.

Re: [Linux-fbdev-devel] radeonfb and 16bit color problem

[Benjamin H. <be...@ke...>]

>Any ideas would be helpful.  I tried looking at the code myself, but I'm
>still quite new to the framebuffer code.  However, this part looked kind
>of strange to me:
>
>   /* For 565, the green component is mixed one order below */
>   if (rinfo->depth == 16) {
>      OUTREG(PALETTE_INDEX, pindex>>1);
>      OUTREG(PALETTE_DATA, (rinfo->palette[regno>>1].red << 16) |
>             (green << 8) | (rinfo->palette[regno>>1].blue));
>      green = rinfo->palette[regno<<1].green;
>   }
>
>
>BTW, I have a Radeon 8500 (QL).

I wrote that part and it works just fine on my powerbook... at least with
the radeonfb version that is in my tree, but I don't think it differs
from the official one in this regard. You can try making sure it's properly
setting 32 palette entries for green when using that mode.

Ben.

[Linux-fbdev-devel] frame buffer -- 1024x768 logo -- Kernel Panic (fwd)

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

---------- Forwarded message ----------
Date: Mon, 24 Jun 2002 16:25:47 -0700
From: Dan Boals <Dan...@Ph...>
To: "'lin...@vg...'" <lin...@vg...>
Subject: frame buffer -- 1024x768 logo --  Kernel Panic

Not exactly sure who to email this to so,  to whomever cares -

	hopefully this isn't old news, I tried a 1024x768 logo and got a
kernel panic.   

	I traced it down to one line of code in /drivers/video/fbcon.c

	Attached is a patch file that seems to fix the problem.  I am not
sure if this fix is absolutely correct.

	NOTE: The patch does NOT include changing the LOGO_W and LOGO_H
lines to 1024 and 768,  nor does it include a linux_logo.h file with a
1024x768 logo.


Daniel Boals
Principal Engineer
Phoenix Technologies, ltd.

[Linux-fbdev-devel] rivafb problems with 2.5.24 + latest fbdev.diff patch

[Miles L. <mi...@me...>]

Problems:

1)  When I boot, when the rivafb is activated, I don't see Tux.  
Instead, where Tux should be, there are about four or five text 
rows that are completely white.  The scrolling boot information
does appear below the white rectangle.

2)  After booting, running the command "fbset -a 1600x1200-76"
causes the machine to lock up.  This same command worked fine
with 2.5.22.

3)  After starting up XFree86, when I switch to one of the 
VTs, all characters are reversed!  The lines are not reversed,
but each character is displayed flipped on its vertical axis.

4)  Lastly, I have not yet figured out how to get rivafb
in the 2.5 series to boot directly into 1600x1200x16 @ 76Hz.
Thus far, running "fbset -a 1600x1200-76" has worked.
I tried  using video=riva:1600x1200-76 and that partly worked.
It got me the resolution I wanted, but the colors were wrong
and the frequency was off:

mode "1600x1200-60"
    # D: 162.022 MHz, H: 75.010 kHz, V: 60.008 Hz
    geometry 1600 1200 1600 1200 16
    timings 6172 304 64 46 1 192 3
    hsync high
    vsync high
    accel true
    rgba 5/11,6/5,5/0,0/0
endmode

Running "fbset -a 1600x1200-76" has been giving me:

mode "1600x1200-76"
    # D: 197.981 MHz, H: 95.183 kHz, V: 76.146 Hz
    geometry 1600 1200 1600 1200 8
    timings 5051 304 40 42 3 136 5
    accel true
    rgba 8/0,8/0,8/0,0/0
endmode

I was then informed that I should use "video=riva:1600x1200@75-16",
since there is no 76Hz entry in linux/drivers/video/modedb.c.

Here's the modedb.c entry I am trying to use:
	/* 1600x1200 @ 75 Hz, 93.75 kHz hsync */
	NULL, 75, 1600, 1200, 4938, 304, 64, 46, 1, 192, 3,
	FB_SYNC_HOR_HIGH_ACT|FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED

Boot command:
kernel /vmlinuz ro root=/dev/hda6 hdd=ide-scsi console=ttyS0,38400 console=tty0 pci=noacpi video=riva:1600x1200@75-16

Kernel log section showing console setup:
Jun 21 00:03:48 turbulence kernel: rivafb: RIVA MTRR set to ON
Jun 21 00:03:48 turbulence kernel: Console: switching to colour frame buffer device 80x25
Jun 21 00:03:48 turbulence kernel: rivafb: PCI nVidia NV10 framebuffer ver 0.9.3 (nVidiaGeForce-DD, 32MB @ 0xE8000000)

Portions of lspci output that may pertain:

01:05.0 VGA compatible controller: nVidia Corporation GeForce 256 DDR (rev 10) (prog-if 00 [VGA])
	Subsystem: VISIONTEK: Unknown device 000b
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64 (1250ns min, 250ns max)
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
	Region 1: Memory at e8000000 (32-bit, prefetchable) [size=128M]
	Expansion ROM at feaf0000 [disabled] [size=64K]
	Capabilities: [60] Power Management version 1
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [44] AGP version 2.0
		Status: RQ=31 SBA- 64bit- FW+ Rate=x1,x2
		Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>

00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-751 [Irongate] System Controller (rev 25)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
	Latency: 64
	Region 0: Memory at f8000000 (32-bit, prefetchable) [size=64M]
	Region 1: Memory at fc9ff000 (32-bit, prefetchable) [size=4K]
	Region 2: I/O ports at ffe4 [disabled] [size=4]
	Capabilities: [a0] AGP version 1.0
		Status: RQ=15 SBA+ 64bit- FW- Rate=x1,x2
		Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>

00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-751 [Irongate] AGP Bridge (rev 01) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
	I/O behind bridge: 0000e000-0000efff
	Memory behind bridge: fca00000-feafffff
	Prefetchable memory behind bridge: e4800000-f48fffff
	BridgeCtl: Parity- SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B-

00:07.3 Bridge: Advanced Micro Devices [AMD] AMD-756 [Viper] ACPI (rev 03)
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-

.config info:

CONFIG_MK7=y
CONFIG_VGA_CONSOLE=y
CONFIG_VIDEO_SELECT=y
CONFIG_FB=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_VIDEO_SELECT=y
CONFIG_FB_RIVA=y
CONFIG_FBCON_ACCEL=y

[Linux-fbdev-devel] radeonfb and 16bit color problem

[Bryan S. <br...@bo...>]

I'm using version 0.1.5 of the radeonfb driver that Ani Joshi posted on
this list earlier this month with kernel 2.4.19pre10, and I've run into
a problem with the colors not being right in 16bit color mode.  In 15bit
color mode, everything seems to look good...

Since running `fbset 800x600-75 -depth 16` seems to want to switch to
15bit color and not 16bit color, I had to use `fbset 800x600-75 -depth
16 -rgba 5,6,5,0` to get into 16bit color mode.  However, once I'm in
16bit color and try to view some jpegs using fbi, the colors are messed
up.

Based of of how the colors in the images are changing, I'm guessing
that the video card is only using the lower 5 bits of green instead of
all 6 bits (chopping off the most significant bit.)  This causes colors
that were only 50% green before to become 100% green (and 25% green
before to become 50%.)

Any ideas would be helpful.  I tried looking at the code myself, but I'm
still quite new to the framebuffer code.  However, this part looked kind
of strange to me:

   /* For 565, the green component is mixed one order below */
   if (rinfo->depth == 16) {
      OUTREG(PALETTE_INDEX, pindex>>1);
      OUTREG(PALETTE_DATA, (rinfo->palette[regno>>1].red << 16) |
             (green << 8) | (rinfo->palette[regno>>1].blue));
      green = rinfo->palette[regno<<1].green;
   }


BTW, I have a Radeon 8500 (QL).

Thanks,
Bryan

[Linux-fbdev-devel] [UPDATES] fbdev ports and fixes

[James S. <jsi...@tr...>]

Hi!

  I managed to port over the RIVA framebuffer driver to the new api as
well as the Macintosh one. The RIVA driver has been tested on my system.
I also placed in BK the newest Voodoo1 driver. Another big change from
Franz Sirl and approved by BenH is the removal of the VC_IOCTL stuff on
the PPC platform. Please test these patches before I submit them.

Thank you.

Here is a diffstat of the changes:

 drivers/video/riva/accel.c                     |  427 -------
 fbdev-2.5/arch/i386/boot/video.S               |    4
 fbdev-2.5/drivers/char/vt.c                    |   66 -
 fbdev-2.5/drivers/video/Config.help            |   17
 fbdev-2.5/drivers/video/Config.in              |   68 -
 fbdev-2.5/drivers/video/Makefile               |    4
 fbdev-2.5/drivers/video/S3triofb.c             |   19
 fbdev-2.5/drivers/video/aty/atyfb_base.c       |   28
 fbdev-2.5/drivers/video/aty128fb.c             |   33
 fbdev-2.5/drivers/video/chipsfb.c              |   29
 fbdev-2.5/drivers/video/controlfb.c            |   21
 fbdev-2.5/drivers/video/fbcon-mac.c            |  483 --------
 fbdev-2.5/drivers/video/imsttfb.c              |   56
 fbdev-2.5/drivers/video/macfb.c                |  463 ++-----
 fbdev-2.5/drivers/video/macmodes.c             |  171 --
 fbdev-2.5/drivers/video/matrox/matroxfb_base.c |   27
 fbdev-2.5/drivers/video/matrox/matroxfb_base.h |    6
 fbdev-2.5/drivers/video/modedb.c               |    4
 fbdev-2.5/drivers/video/neofb.c                |    7
 fbdev-2.5/drivers/video/offb.c                 |   26
 fbdev-2.5/drivers/video/platinumfb.c           |   26
 fbdev-2.5/drivers/video/riva/Makefile          |    2
 fbdev-2.5/drivers/video/riva/fbdev.c           | 1500 +++++++++----------------
 fbdev-2.5/drivers/video/riva/riva_hw.c         |   38
 fbdev-2.5/drivers/video/riva/riva_hw.h         |    2
 fbdev-2.5/drivers/video/riva/riva_tbl.h        |  203 +--
 fbdev-2.5/drivers/video/riva/rivafb.h          |   60 -
 fbdev-2.5/drivers/video/sstfb.c                |  958 +++++++++------
 fbdev-2.5/drivers/video/sstfb.h                |   73 -
 fbdev-2.5/drivers/video/tdfxfb.c               |   55
 fbdev-2.5/drivers/video/valkyriefb.c           |   26
 fbdev-2.5/drivers/video/vesafb.c               |    8
 fbdev-2.5/include/asm-ppc/vc_ioctl.h           |   46
 fbdev-2.5/include/asm-ppc64/vc_ioctl.h         |   50
 fbdev-2.5/include/linux/pci_ids.h              |    1
 fbdev-2.5/include/linux/tty.h                  |    3
 36 files changed, 1516 insertions(+), 3494 deletions(-)

The URL to grab the diff is

http://www.transvirtual.com/~jsimmons/fbdev.diff.gz

and the BK link is

http://fbdev.bkbits.net:8080/fbdev-2.5

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'\_   _/`\
 \___)=(___/