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

Re: [Linux-fbdev-devel] Linux fbcon.c

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

> >   Rotation is starting to appear in hardware on different device. Perhaps
> > a ioctl call?
> 
> Another great idea, especially for the various embedded devices.  

Yep. Just how to implement it? 

Re: [Linux-fbdev-devel] Linux fbcon.c

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

> > That would be most excellent if we could get that set up.
> 
> Make sure they have a SourceForge account and the linux-fbdev administrators

I believe you are one of the admins. Brad being the other.

Re: [Linux-fbdev-devel] Linux fbcon.c

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

On Mon, 11 Jun 2001, Jordan Crouse wrote:
> On Monday 11 June 2001 11:40, James Simmons mentioned:
> > What would be nice if we could give them CVS access to linux-fbdev and
> > they could work out of a common area.
> 
> That would be most excellent if we could get that set up.

Make sure they have a SourceForge account and the linux-fbdev administrators
can add them to the project.

Gr{oetje,eeting}s,

						Geert

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

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [Linux-fbdev-devel] Linux fbcon.c

[Jordan C. <jo...@Ce...>]

On Monday 11 June 2001 11:40, James Simmons mentioned:
> What would be nice if we could give them CVS access to linux-fbdev and
> they could work out of a common area.

That would be most excellent if we could get that set up.

>   Rotation is starting to appear in hardware on different device. Perhaps
> a ioctl call?

Another great idea, especially for the various embedded devices.  

Jordan
 

Re: [Linux-fbdev-devel] Linux fbcon.c

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

What would be nice if we could give them CVS access to linux-fbdev and
they could work out of a common area.

> If you end up making any C&T 65550 specific changes, would you mind sending 
> them to Adrian Cox <ad...@hu...> and myself?  We are working on 
> drivers for the 69XXX chips and I would love to include any rotating code if 
> I could.

P.S

  Rotation is starting to appear in hardware on different device. Perhaps
a ioctl call?

Re: [Linux-fbdev-devel] DMA/IRQ based hardware support.

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

> > The ruby tree has finished the moved away from using spinlocks to a
> > sempahore for the console lock.
> 
> Has this issue been discussed on this list?

Yes. Especially with the i810 fbdev driver. It can only work as a DMA/irq
based device. The console spinlock was preventing this. Turning off IRQs
prevented the hardware from working.

> The sempahore gives better support for threads/tasks?

?? Do you from a userland prespective?
 
> When/why would you want to use DMA? Do all the drawing on CPU memory and
> then DMA
> the block to graphics memory? It seems that approach would get in the
> way of acceleration.

Because one this is the only way some devices work. Second DMA often gives
better performance and it usually is much easier to program. For most
hardware you can send accel commands threw the DMA engine to draw things.
 
> Using DMA inside the acceleration routines? It seems on average you
> would spend more time making the tests to decide to use DMA and
> programming the DMA then it would be to write the pixels directly.

No. Fbcon needs only one DMA buffer. Allocate a chunck of memory and mark
it for DMA use. Then feed data into it. We do have to make sure that we
don't flood the DMA engine with to many commands. This can be controled
by the size of the buffer and with some conditional scheduling code. We do
the same thing for FIFOs and we also do a busy loop polling the accel
engine to see if it is busy. Often with DMA hardware you can feed it data
while the accel engine is busy and it gets processed as soon as the accel
engine is done with the previous command. 
 
> It seems most operations on fb would involve "small" rectangles that do
> not use large contigous blocks of memory. Console scrolling would be
> able to take advantage of it...

Correct. The new fbdev api is based around this idea.

Re: [Linux-fbdev-devel] DMA/IRQ based hardware support.

[Scott A M. <sam...@co...>]

James Simmons wrote:
> 
> The ruby tree has finished the moved away from using spinlocks to a
> sempahore for the console lock.

Has this issue been discussed on this list?

The sempahore gives better support for threads/tasks?


> This means we can now have fbdev drivers
> that use DMA :-) We can now write fbdev drivers using DMA. Thank you.

Please pardon my ignorance...

When/why would you want to use DMA? Do all the drawing on CPU memory and
then DMA
the block to graphics memory? It seems that approach would get in the
way of acceleration.

Using DMA inside the acceleration routines? It seems on average you
would spend more time making the tests to decide to use DMA and
programming the DMA then it would be to write the pixels directly.

It seems most operations on fb would involve "small" rectangles that do
not use large contigous blocks of memory. Console scrolling would be
able to take advantage of it...

Thanks for any comments.


-- 
Scott A. McConnell

Re: [Linux-fbdev-devel] Linux fbcon.c

[Jordan C. <jo...@Ce...>]

If you end up making any C&T 65550 specific changes, would you mind sendi=
ng=20
them to Adrian Cox <ad...@hu...> and myself?  We are working on=
=20
drivers for the 69XXX chips and I would love to include any rotating code=
 if=20
I could.

Jordan

On Friday 08 June 2001 07:04, Florian Lechner mentioned:
> ANYBODY OUT there to help me?
>
> So my Question:
>
> 	I'm trying to rotate the fb by 180=B0.
>
> Reason:
> 	I have an embedded board ElanSC400, C&T 65550, etc.
>
> I'm reading the driver/video code for a couple of days now, and pinned
> down myself to three points where I have to do changes to rotate the
> display.
>
> 	fbcon.c --> fbcon_putc
> 	fbcon.c --> fbcon_putcs
> 	fbmem.c	--> fb_write
>
> Is that correct?
>
> Kind regards Florian
>
> ANYBODY OUT there to help me?
>
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> http://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

[Linux-fbdev-devel] FB for IBM Walnut (405GP)

[<phi...@ac...>]

We are using an IBM Walnut board with mvista distribution (Linux version
2.4.2-mvista_010412)
We try to use a Matrox (Mystique) PCI graphic card, but it failed during
the initialization. Does anyone succeded in using such a graphic card or an
other one
with a Walnut board ?

Thanks. PV

==============================================
Philippe VILLET
R & D Engineer
Software and Digital Hardware Group
Tel : +33 (0) 4 77 47 89 55
Fax : +33 (0) 4 77 47 89 70
email : phi...@ac...

ACTERNA
34, rue Necker
42028 SAINT-ETIENNE Cedex 1
FRANCE
==============================================

[Linux-fbdev-devel] Re: Aty128fb as a module with options support

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

On  8 Jun 01 at 21:34, Otto Wyss wrote:
> 
> Since the driver compiled into the kernel (2.4.3, i386) only supports
> options "noaccel" and "nomtrr" I tried to test these options first. But
> it seems I'm not successful. While I'm not sure of the "noaccel" option
> (no visible effect), even when specifying "nomtrr" the syslog showed
> "aty128fb: Rage128 MTRR set to on".

You can decide for two ways:
(1) use different options name and leave parsing on insmod/modprobe
    (this is what matroxfb does) or
(2) use one string option and leave fbdev driver to parse it yourself

> After MODULE_DESCRIPTION I added the following line:
>  static const char *option __initdata = NULL;
>  MODULE_PARM(noaccel, "i");
>  MODULE_PARM_DESC(noaccel, "Disables hardware acceleration (0 or
> 1=disabled)  (default=0)");

So 'insmod aty128fb noaccel=1' should work.

>  #ifdef CONFIG_MTRR
>  MODULE_PARM(mtrr, "i");
>  MODULE_PARM_DESC(mtrr, "Disables MTRR support (0 or 1=disabled) (default=0)");
>  #endif

And 'insmod aty128fb mtrr=0' ... How you tried to pass options to aty128fb?
If you type 'insmod aty128fb nomtrr', insmod should loudly complain
that it does not know what to do with 'nomtrr'.
These both options are attempt to use way (1) as described above.

> After init_module(void) { I added the following line:
>     aty128fb_setup(option);

And here you are trying to use method (2). But to get this to work
you must do:

(a) add 

char* option = NULL;
MODULE_PARM(option, "s");
MODULE_PARM_DESC(option, "Use option=nomtrr to disable mtrr...");

(b) make sure that you are passing this global variable as argument
to aty128fb_setup. As there is no 'option' variable, you should receive
an error from compiler...

(c) then use 'insmod aty128fb option="nomtrr,noaccel"' - make sure
that you are using quotes around option=... (maybe you have to type
\" in shell), otherwise insmod will treat it as two values assigned
to option variable - which is not possible.

But in any of these cases kernel boot command line (video=aty128fb:...)
cannot have any effect on modularized aty128fb behavior!
                                                Petr Vandrovec
                                                van...@vc...
                                                
                                                

[Linux-fbdev-devel] Aty128fb as a module with options support

[Otto W. <ott...@bl...>]

As a non kernel and non kernel driver developer I tried to follow Petr
Vandrovec guidelines to change the aty128fb driver, that it supports
options if compiled as a module. I also looked at the matrox and the
riva drivers.

Since the driver compiled into the kernel (2.4.3, i386) only supports
options "noaccel" and "nomtrr" I tried to test these options first. But
it seems I'm not successful. While I'm not sure of the "noaccel" option
(no visible effect), even when specifying "nomtrr" the syslog showed
"aty128fb: Rage128 MTRR set to on".

Besides it seems I'm not to be able to figure out how to create a
correct diff, I tried "diff -U3 aty128fb.c.orig aty128fb.c" but this
doesn't produce a small diff. I'll give now a hand made diff, a correct
will follow later.

Removed all lines:
 #if[n]def MODULE

After MODULE_DESCRIPTION I added the following line:
 static const char *option __initdata = NULL;
 MODULE_PARM(noaccel, "i");
 MODULE_PARM_DESC(noaccel, "Disables hardware acceleration (0 or
1=disabled)  (default=0)");
 MODULE_PARM(fontname, "s");
 MODULE_PARM_DESC(fontname, "Specifies one of the compiled-in fonts
(max. 40chars, default=none)");
 #ifdef CONFIG_MTRR
 MODULE_PARM(mtrr, "i");
 MODULE_PARM_DESC(mtrr, "Disables MTRR support (0 or 1=disabled) (default=0)");
 #endif

After init_module(void) { I added the following line:
    aty128fb_setup(option);

Does anyone see what I'm doing wrong? Is there any way to reliable check
my change? How is a kernel driver debugged?

O. Wyss

Re: [Linux-fbdev-devel] Linux fbcon.c

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

On Fri, 8 Jun 2001, Florian Lechner wrote:
> 	Would you mind sending me your code, cos at the moment my screen is
> pretty much screwed up, but not rotated.=20

I don't ave code for it.

> I just tried to rotate the *s on putcs. last to first and mirrored ever=
y
> byte.=20
> Result--> mixed up screen color and chars.=20
>=20
> As far as I figured, the *s holds a bunch of bytes for the video_mem.=20

Yes, the string contains both characters and attributes.

But you don't have to change the fbcon_putcs() routine, you have to chang=
e the
drawing routines in one of fbcon-*.c.

> Geert Uytterhoeven wrote:
> > On Fri, 8 Jun 2001, Florian Lechner wrote:
> > > ANYBODY OUT there to help me?
> > >
> > > So my Question:
> > >
> > >       I'm trying to rotate the fb by 180=B0.
> >=20
> > In the console, or in X?
> >=20
> > > Reason:
> > >       I have an embedded board ElanSC400, C&T 65550, etc.
> > >
> > > I'm reading the driver/video code for a couple of days now, and pin=
ned
> > > down myself to three points where I have to do changes to rotate th=
e
> > > display.
> > >
> > >       fbcon.c --> fbcon_putc
> > >       fbcon.c --> fbcon_putcs
> > >       fbmem.c --> fb_write
> > >
> > > Is that correct?
> >=20
> > For the console, I'd just write my own fbcon-*.c replacement (e.g.
> > fbcon-cfb8-r180.c, cloned from fbcon-cfb8.c) where you take the rotat=
ion in
> > mind in the following functions:
> >=20
> >   - bmove
> >   - clear
> >   - putc
> >   - putcs
> >   - revc
> >   - clear_margins

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m6=
8k.org

In personal conversations with technical people, I call myself a hacker. =
But
when I'm talking to journalists I just say "programmer" or something like=
 that.
							    -- Linus Torvalds

Re: [Linux-fbdev-devel] Linux fbcon.c

[Florian L. <f.l...@ti...>]

Thanks a lot for your fast answer!!!

	Would you mind sending me your code, cos at the moment my screen is
pretty much screwed up, but not rotated. 

I just tried to rotate the *s on putcs. last to first and mirrored every
byte. 
Result--> mixed up screen color and chars. 

As far as I figured, the *s holds a bunch of bytes for the video_mem. 

Regards Florian

Geert Uytterhoeven wrote:
> 
> On Fri, 8 Jun 2001, Florian Lechner wrote:
> > ANYBODY OUT there to help me?
> >
> > So my Question:
> >
> >       I'm trying to rotate the fb by 180°.
> 
> In the console, or in X?
> 
> > Reason:
> >       I have an embedded board ElanSC400, C&T 65550, etc.
> >
> > I'm reading the driver/video code for a couple of days now, and pinned
> > down myself to three points where I have to do changes to rotate the
> > display.
> >
> >       fbcon.c --> fbcon_putc
> >       fbcon.c --> fbcon_putcs
> >       fbmem.c --> fb_write
> >
> > Is that correct?
> 
> For the console, I'd just write my own fbcon-*.c replacement (e.g.
> fbcon-cfb8-r180.c, cloned from fbcon-cfb8.c) where you take the rotation in
> mind in the following functions:
> 
>   - bmove
>   - clear
>   - putc
>   - putcs
>   - revc
>   - clear_margins
> 
> Gr{oetje,eeting}s,
> 
>                                                 Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                                             -- Linus Torvalds
> 
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> http://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: [Linux-fbdev-devel] Linux fbcon.c

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

On Fri, 8 Jun 2001, Florian Lechner wrote:
> ANYBODY OUT there to help me?
>=20
> So my Question:
>=20
> 	I'm trying to rotate the fb by 180=B0.=20

In the console, or in X?

> Reason:
> 	I have an embedded board ElanSC400, C&T 65550, etc.=20
>=20
> I'm reading the driver/video code for a couple of days now, and pinned
> down myself to three points where I have to do changes to rotate the
> display.
>=20
> 	fbcon.c --> fbcon_putc
> 	fbcon.c --> fbcon_putcs
> 	fbmem.c	--> fb_write
>=20
> Is that correct?

For the console, I'd just write my own fbcon-*.c replacement (e.g.
fbcon-cfb8-r180.c, cloned from fbcon-cfb8.c) where you take the rotation =
in
mind in the following functions:

  - bmove
  - clear
  - putc
  - putcs
  - revc
  - clear_margins
   =20
Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m6=
8k.org

In personal conversations with technical people, I call myself a hacker. =
But
when I'm talking to journalists I just say "programmer" or something like=
 that.
							    -- Linus Torvalds

[Linux-fbdev-devel] Linux fbcon.c

[Florian L. <f.l...@ti...>]

ANYBODY OUT there to help me?

So my Question:

	I'm trying to rotate the fb by 180°. 

Reason:
	I have an embedded board ElanSC400, C&T 65550, etc. 

I'm reading the driver/video code for a couple of days now, and pinned
down myself to three points where I have to do changes to rotate the
display.

	fbcon.c --> fbcon_putc
	fbcon.c --> fbcon_putcs
	fbmem.c	--> fb_write

Is that correct?

Kind regards Florian

ANYBODY OUT there to help me?

[Linux-fbdev-devel] framebuffer driver patch in fbcon-cfb8.c

[Niklaus H. <nik...@mi...>]

Added support for fontwidth 10.
Check for /* 01.06.01 hersche */

[Linux-fbdev-devel] Help with finding vertical refresh strobe

[Jeff R. <je...@mi...>]

Hi All,

I'd like to get hard real-time frame-by-frame control of video.

I have RTLinux working and would like it to poll (in real-time) for either the

current horizontal scanline position, a horizontal refresh or a vertical

refresh.  I realize this is probably in the structure 'display' somewhere

but havent found it or references to it.  Any help would be appreciated.

Please cc a copy of replies to me as I do not subscribe to this list.

Thanks,

Jeff Rouder

--
-------------------------------- :)
Jeff Rouder
Department of Psychology
University of Missouri - Columbia
je...@ba...
(573) 884-4679

[Linux-fbdev-devel] Re: FBCon invert_region is endian unsafe, same with generic invert_region

[Olaf H. <ol...@su...>]

On Sat, Jun 02, Geert Uytterhoeven wrote:

> 	Hi Daniel,
> 
> > I'm not quite sure who the maintainer is, fbcon.c lists 5 people, and
> > no one is listed in the MAINTAINERS file (i searched on fbcon).
> > 
> > This one has been bothering me for a long time.
> > It causes text selection to fail on fbcon devices for big endian
> > platforms (Because, obviously, it gets big endian data on big endian
> > machines, sinceit neglects to use scr_readw/scr_writew. Dumb. You end
> > up inverting, pasting each byte reversed without fixing this, so where
> > you would normally have pasted/see a background inverted 'u' (0x75),
> > you get a 'W' (0x57)).
> 
>     [...]
> 
> > However, it's important to note that console.c has the same damn bug
> > in it's generic inversion routine.
> > 
> > Changing the code to the right way makes text selection work perfectly
> > again, which it hasn't since 2.2.x, at least for me.
> 
> So this patch (untested) fixes it?
> 
> Olaf: is this the missing piece for you as well?

Yes, I didnt try the gpm selection. argh :) It works now on the ibook
with atyfb.
vga_console was disabled in the release so I didnt notice.
However, my asm-ppc/vga.h patch is still needed for real VGA text mode.

Btw, there is a syntax error, see below.


Gruss Olaf

> --- console-2.4.5/drivers/char/console.c.orig	Mon Feb 19 10:36:47 2001
> +++ console-2.4.5/drivers/char/console.c	Sat Jun  2 21:15:10 2001
> @@ -390,20 +390,28 @@
>  	else {
>  		u16 *q = p;
>  		int cnt = count;
> +		u16 a;
>  
>  		if (!can_do_color) {
> -			while (cnt--) *q++ ^= 0x0800;
> +			while (cnt--) {
> +			    a = scr_readw(q);
> +			    a ^= 0x0800;
> +			    scr_writew(a, q);
> +			    q++;
> +			}
>  		} else if (hi_font_mask == 0x100) {
>  			while (cnt--) {
> -				u16 a = *q;
> +				a = scr_readw(q);
>  				a = ((a) & 0x11ff) | (((a) & 0xe000) >> 4) | (((a) & 0x0e00) << 4);
> -				*q++ = a;
> +				scr_writew(a, q);
> +				q++;
>  			}
>  		} else {
>  			while (cnt--) {
> -				u16 a = *q;
> +				a = scr_readw(q);
>  				a = ((a) & 0x88ff) | (((a) & 0x7000) >> 4) | (((a) & 0x0700) << 4);
> -				*q++ = a;
> +				scr_writew(a, q);
> +				q++

                                   ^;

>  			}
>  		}
>  	}
> --- console-2.4.5/drivers/video/fbcon.c.orig	Mon Feb 19 10:37:00 2001
> +++ console-2.4.5/drivers/video/fbcon.c	Sat Jun  2 21:07:38 2001
> @@ -1934,17 +1934,15 @@
>  static void fbcon_invert_region(struct vc_data *conp, u16 *p, int cnt)
>  {
>      while (cnt--) {
> +	u16 a = scr_readw(p);
>  	if (!conp->vc_can_do_color)
> -	    *p++ ^= 0x0800;
> -	else if (conp->vc_hi_font_mask == 0x100) {
> -	    u16 a = *p;
> +	    a ^= 0x0800;
> +	else if (conp->vc_hi_font_mask == 0x100)
>  	    a = ((a) & 0x11ff) | (((a) & 0xe000) >> 4) | (((a) & 0x0e00) << 4);
> -	    *p++ = a;
> -	} else {
> -	    u16 a = *p;
> +	else
>  	    a = ((a) & 0x88ff) | (((a) & 0x7000) >> 4) | (((a) & 0x0700) << 4);
> -	    *p++ = a;
> -	}
> +	scr_writew(a, p);
> +	p++;
>  	if (p == (u16 *)softback_end)
>  	    p = (u16 *)softback_buf;
>  	if (p == (u16 *)softback_in)


Gruss Olaf

-- 
 $ man clone

BUGS
       Main feature not yet implemented...

[Linux-fbdev-devel] Re: FBCon invert_region is endian unsafe, same with generic invert_region

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

	Hi Daniel,

> I'm not quite sure who the maintainer is, fbcon.c lists 5 people, and
> no one is listed in the MAINTAINERS file (i searched on fbcon).
> 
> This one has been bothering me for a long time.
> It causes text selection to fail on fbcon devices for big endian
> platforms (Because, obviously, it gets big endian data on big endian
> machines, sinceit neglects to use scr_readw/scr_writew. Dumb. You end
> up inverting, pasting each byte reversed without fixing this, so where
> you would normally have pasted/see a background inverted 'u' (0x75),
> you get a 'W' (0x57)).

    [...]

> However, it's important to note that console.c has the same damn bug
> in it's generic inversion routine.
> 
> Changing the code to the right way makes text selection work perfectly
> again, which it hasn't since 2.2.x, at least for me.

So this patch (untested) fixes it?

Olaf: is this the missing piece for you as well?

--- console-2.4.5/drivers/char/console.c.orig	Mon Feb 19 10:36:47 2001
+++ console-2.4.5/drivers/char/console.c	Sat Jun  2 21:15:10 2001
@@ -390,20 +390,28 @@
 	else {
 		u16 *q = p;
 		int cnt = count;
+		u16 a;
 
 		if (!can_do_color) {
-			while (cnt--) *q++ ^= 0x0800;
+			while (cnt--) {
+			    a = scr_readw(q);
+			    a ^= 0x0800;
+			    scr_writew(a, q);
+			    q++;
+			}
 		} else if (hi_font_mask == 0x100) {
 			while (cnt--) {
-				u16 a = *q;
+				a = scr_readw(q);
 				a = ((a) & 0x11ff) | (((a) & 0xe000) >> 4) | (((a) & 0x0e00) << 4);
-				*q++ = a;
+				scr_writew(a, q);
+				q++;
 			}
 		} else {
 			while (cnt--) {
-				u16 a = *q;
+				a = scr_readw(q);
 				a = ((a) & 0x88ff) | (((a) & 0x7000) >> 4) | (((a) & 0x0700) << 4);
-				*q++ = a;
+				scr_writew(a, q);
+				q++
 			}
 		}
 	}
--- console-2.4.5/drivers/video/fbcon.c.orig	Mon Feb 19 10:37:00 2001
+++ console-2.4.5/drivers/video/fbcon.c	Sat Jun  2 21:07:38 2001
@@ -1934,17 +1934,15 @@
 static void fbcon_invert_region(struct vc_data *conp, u16 *p, int cnt)
 {
     while (cnt--) {
+	u16 a = scr_readw(p);
 	if (!conp->vc_can_do_color)
-	    *p++ ^= 0x0800;
-	else if (conp->vc_hi_font_mask == 0x100) {
-	    u16 a = *p;
+	    a ^= 0x0800;
+	else if (conp->vc_hi_font_mask == 0x100)
 	    a = ((a) & 0x11ff) | (((a) & 0xe000) >> 4) | (((a) & 0x0e00) << 4);
-	    *p++ = a;
-	} else {
-	    u16 a = *p;
+	else
 	    a = ((a) & 0x88ff) | (((a) & 0x7000) >> 4) | (((a) & 0x0700) << 4);
-	    *p++ = a;
-	}
+	scr_writew(a, p);
+	p++;
 	if (p == (u16 *)softback_end)
 	    p = (u16 *)softback_buf;
 	if (p == (u16 *)softback_in)

Gr{oetje,eeting}s,

						Geert

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

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

[Linux-fbdev-devel] DMA/IRQ based hardware support.

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

The ruby tree has finished the moved away from using spinlocks to a
sempahore for the console lock. This means we can now have fbdev drivers
that use DMA :-) We can now write fbdev drivers using DMA. Thank you.

[Linux-fbdev-devel] TV-OUT on ATI Rage 3D Pro?!

[Henning H. <hh...@ho...>]

Hello all,

I'm desperately trying to get my ATI Rage Pro VGA card to work with my TV 
set via the card's  built-in TV-OUT connector. The standard Linux text mode 
works fine but if I use the frame buffer driver, the screen will just 
flicker. I think this is due to a wrong mode configuration in /etc/fb.modes 
(if I understand thing correctly, I have to know at least the dot clock of 
my TV?!). I live in Germany, so my TV supports only PAL mode and runs at 50 
Hz (compared to 60 Hz for NTSC). The card supports 50 Hz because it works 
fine in text mode but I haven't been able to figure out the correct 
settings for /etc/fb.modes. Can anyone help me? Is PAL mode supported by 
the atyfb driver at all?

Regards,
hh

Re: [Linux-fbdev-devel] g450 pci

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

On  1 Jun 01 at 9:12, Ralph Blach wrote:

> I have a g450 pci card and was wondering if anybody had any patches to
> get this going under linux?

Which PCI ID it has? I heard nothing about G450 PCIs, only G450 AGP...

If you are trying to get G450AGP to work in non-PC machine, I'm afraid
that you have to find x86 emulator somewhere, as G450 core is still
undocumented, so I have no idea how to setup their DDRAM interface...

If you can boot G450 in an emulator and then dump (MM)IO and PCI accesses 
it does...
                                                        Petr
                                                        

[Linux-fbdev-devel] g450 pci

[Ralph B. <rc...@ra...>]

I have a g450 pci card and was wondering if anybody had any patches to
get this going under linux?

Thanks

Chip

[Linux-fbdev-devel] atyfb and RGB565

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

	Hi,

I managed to make atyfb work in RGB565 (depth 15, bpp 16) mode.
As expected, the most hairy part turned out to be the palette DAC handling.

The patch (relative to the `new' atyfb at SourceForge, project linux-fbdev,
module atyfb) is included below. With some minor changes it can be made to work
with the old atyfb as well.

I haven't checked it in yet because of two reasons:

  - XF68_FBDev (from 3.3.x) stops working in depth 15, and the new depth 16
    doesn't work neither. I guess I'm too fascist with the bitfield tests,
    although that's fbdev standard policy.

    I haven't tried XFree86 4.x yet.

  - Although it works fine in the console, my directcolor test from the fbtest
    package (module fbtest) fails miserably.

Index: src/atyfb_base.c
===================================================================
RCS file: /cvsroot/linux-fbdev/atyfb/src/atyfb_base.c,v
retrieving revision 1.7
diff -u -r1.7 atyfb_base.c
--- src/atyfb_base.c	2001/05/31 17:31:54	1.7
+++ src/atyfb_base.c	2001/05/31 17:57:01
@@ -117,14 +117,6 @@
      *  The Hardware parameters for each card
      */
 
-struct aty_cmap_regs {
-    u8 windex;
-    u8 lut;
-    u8 mask;
-    u8 rindex;
-    u8 cntl;
-};
-
 struct pci_mmap_map {
     unsigned long voff;
     unsigned long poff;
@@ -423,6 +415,11 @@
 #endif /* defined(CONFIG_PPC) */
 
 #if defined(CONFIG_PMAC_PBOOK) || defined(CONFIG_PMAC_BACKLIGHT)
+
+    /*
+     *  LCD register access
+     */
+
 static void aty_st_lcd(int index, u32 val, const struct fb_info_aty *info)
 {
     unsigned long temp;
@@ -446,6 +443,32 @@
 }
 #endif /* CONFIG_PMAC_PBOOK || CONFIG_PMAC_BACKLIGHT */
 
+
+    /*
+     *  DAC register access
+     */
+
+#ifdef __sparc__
+static void aty_ld_dac(int index, u8 *red, u8 *green, u8 *blue,
+		       const struct fb_info_aty *info)
+{
+    aty_st_8(DAC_R_INDEX, index, info);
+    *red = aty_ld_8(DAC_DATA, info) << 16;
+    *green = aty_ld_8(DAC_DATA, info) << 8;
+    *blue = aty_ld_8(DAC_DATA, info);
+}
+#endif
+
+static void aty_st_dac(int index, u8 red, u8 green, u8 blue,
+		       const struct fb_info_aty *info)
+{
+    aty_st_8(DAC_W_INDEX, index, info);
+    aty_st_8(DAC_DATA, red, info);
+    aty_st_8(DAC_DATA, green, info);
+    aty_st_8(DAC_DATA, blue, info);
+}
+
+
 /* ------------------------------------------------------------------------- */
 
     /*
@@ -464,6 +487,36 @@
     aty_st_le32(CRTC_GEN_CNTL, crtc->gen_cntl, info);
 }
 
+static const struct {
+    u32 bpp;
+    u32 rlen, glen, blen, alen;
+    int integrated_only;
+    u32 pix_width;
+    u32 dp_pix_width;
+    u32 dp_chain_mask;
+} formats[] = {
+    {
+	8, 8, 8, 8, 8, 0, CRTC_PIX_WIDTH_8BPP,
+	HOST_8BPP | SRC_8BPP | DST_8BPP | BYTE_ORDER_LSB_TO_MSB, 0x8080
+    }, {
+	16, 5, 5, 5, 0, 0, CRTC_PIX_WIDTH_15BPP,
+	HOST_15BPP | SRC_15BPP | DST_15BPP | BYTE_ORDER_LSB_TO_MSB, 0x4210
+    },
+#ifdef CONFIG_FB_ATY_CT
+    {
+	16, 5, 6, 5, 0, 1, CRTC_PIX_WIDTH_16BPP,
+	HOST_16BPP | SRC_16BPP | DST_16BPP | BYTE_ORDER_LSB_TO_MSB, 0x8410
+    }, {
+	24, 8, 8, 8, 0, 1, CRTC_PIX_WIDTH_24BPP,
+	HOST_8BPP | SRC_8BPP | DST_8BPP | BYTE_ORDER_LSB_TO_MSB, 0x8080
+    },
+#endif /* CONFIG_FB_ATY_CT */
+    {
+	32, 8, 8, 8, 8, 0, CRTC_PIX_WIDTH_32BPP,
+	HOST_32BPP | SRC_32BPP | DST_32BPP | BYTE_ORDER_LSB_TO_MSB, 0x8080
+    }
+};
+
 static int aty_var_to_crtc(const struct fb_info_aty *info,
 			   const struct fb_var_screeninfo *var,
 			   struct crtc *crtc)
@@ -473,6 +526,8 @@
     u32 h_total, h_disp, h_sync_strt, h_sync_dly, h_sync_wid, h_sync_pol;
     u32 v_total, v_disp, v_sync_strt, v_sync_wid, v_sync_pol, c_sync;
     u32 pix_width, dp_pix_width, dp_chain_mask;
+    u32 rlen, glen, blen, alen;
+    int i;
 
     /* input */
     xres = var->xres;
@@ -490,6 +545,10 @@
     vslen = var->vsync_len;
     sync = var->sync;
     vmode = var->vmode;
+    rlen = var->red.length;
+    glen = var->green.length;
+    blen = var->blue.length;
+    alen = var->transp.length;
 
     /* convert (and round up) and validate */
     xres = (xres+7) & ~7;
@@ -530,36 +589,25 @@
 
     c_sync = sync & FB_SYNC_COMP_HIGH_ACT ? CRTC_CSYNC_EN : 0;
 
-    if (bpp <= 8) {
-	bpp = 8;
-	pix_width = CRTC_PIX_WIDTH_8BPP;
-	dp_pix_width = HOST_8BPP | SRC_8BPP | DST_8BPP | BYTE_ORDER_LSB_TO_MSB;
-	dp_chain_mask = 0x8080;
-    } else if (bpp <= 16) {
-	bpp = 16;
-	pix_width = CRTC_PIX_WIDTH_15BPP;
-	dp_pix_width = HOST_15BPP | SRC_15BPP | DST_15BPP |
-		       BYTE_ORDER_LSB_TO_MSB;
-	dp_chain_mask = 0x4210;
-    } else if (bpp <= 24 && M64_HAS(INTEGRATED)) {
-	bpp = 24;
-	pix_width = CRTC_PIX_WIDTH_24BPP;
-	dp_pix_width = HOST_8BPP | SRC_8BPP | DST_8BPP | BYTE_ORDER_LSB_TO_MSB;
-	dp_chain_mask = 0x8080;
-    } else if (bpp <= 32) {
-	bpp = 32;
-	pix_width = CRTC_PIX_WIDTH_32BPP;
-	dp_pix_width = HOST_32BPP | SRC_32BPP | DST_32BPP |
-		       BYTE_ORDER_LSB_TO_MSB;
-	dp_chain_mask = 0x8080;
-    } else
-	FAIL("invalid bpp");
+    for (i = 0; i < sizeof(formats)/sizeof(*formats); i++)
+	if (bpp <= formats[i].bpp && rlen <= formats[i].rlen &&
+	    glen <= formats[i].glen && blen <= formats[i].blen &&
+	    alen <= formats[i].alen &&
+	    (M64_HAS(INTEGRATED) || !formats[i].integrated_only)) {
+	    bpp = formats[i].bpp;
+	    pix_width = formats[i].pix_width;
+	    dp_pix_width = formats[i].dp_pix_width;
+	    dp_chain_mask = formats[i].dp_chain_mask;
+	    break;
+	}
+    if (i == sizeof(formats)/sizeof(*formats))
+	FAIL("invalid pixel format");
 
     if (vxres*vyres*bpp/8 > info->total_vram)
 	FAIL("not enough video RAM");
 
     if ((vmode & FB_VMODE_MASK) != FB_VMODE_NONINTERLACED)
-	FAIL("invalid vmode");
+	FAIL("invalid format");
 
     /* output */
     crtc->vxres = vxres;
@@ -660,7 +708,7 @@
 	    var->transp.offset = 0;
 	    var->transp.length = 0;
 	    break;
-#if 0
+#ifdef CONFIG_FB_ATY_CT
 	case CRTC_PIX_WIDTH_16BPP:	/* RGB 565 */
 	    bpp = 16;
 	    var->red.offset = 11;
@@ -672,7 +720,6 @@
 	    var->transp.offset = 0;
 	    var->transp.length = 0;
 	    break;
-#endif
 	case CRTC_PIX_WIDTH_24BPP:	/* RGB 888 */
 	    bpp = 24;
 	    var->red.offset = 16;
@@ -684,6 +731,7 @@
 	    var->transp.offset = 0;
 	    var->transp.length = 0;
 	    break;
+#endif /* CONFIG_FB_ATY_CT */
 	case CRTC_PIX_WIDTH_32BPP:	/* ARGB 8888 */
 	    bpp = 32;
 	    var->red.offset = 16;
@@ -1089,6 +1137,7 @@
     struct atyfb_par par;
     struct display *display;
     int oldxres, oldyres, oldvxres, oldvyres, oldbpp, oldaccel, accel, err;
+    int oldgreenlen;
     int activate = var->activate;
 
     if (con >= 0)
@@ -1107,12 +1156,14 @@
 	oldvxres = display->var.xres_virtual;
 	oldvyres = display->var.yres_virtual;
 	oldbpp = display->var.bits_per_pixel;
+	oldgreenlen = display->var.green.length;
 	oldaccel = display->var.accel_flags;
 	display->var = *var;
 	accel = var->accel_flags & FB_ACCELF_TEXT;
 	if (oldxres != var->xres || oldyres != var->yres ||
 	    oldvxres != var->xres_virtual || oldvyres != var->yres_virtual ||
-	    oldbpp != var->bits_per_pixel || oldaccel != var->accel_flags) {
+	    oldbpp != var->bits_per_pixel || oldaccel != var->accel_flags ||
+	    oldgreenlen != var->green.length) {
 	    struct fb_fix_screeninfo fix;
 
 	    encode_fix(&fix, &par, info);
@@ -1137,7 +1188,8 @@
 	    atyfb_set_par(&par, info);
 	    atyfb_set_dispsw(display, info, par.crtc.bpp, accel);
 	}
-	if (oldbpp != var->bits_per_pixel) {
+	if (oldbpp != var->bits_per_pixel || 
+	    oldgreenlen != var->green.length) {
 	    if ((err = fb_alloc_cmap(&display->cmap, 0, 0)))
 		return err;
 	    do_install_cmap(con, &info->fb_info);
@@ -1438,14 +1490,11 @@
 		aty_st_8(DAC_CNTL, tmp, info);
 		aty_st_8(DAC_MASK, 0xff, info);
 
-		writeb(i, &info->aty_cmap_regs->rindex);
-		atyfb_save.r[enter][i] = readb(&info->aty_cmap_regs->lut);
-		atyfb_save.g[enter][i] = readb(&info->aty_cmap_regs->lut);
-		atyfb_save.b[enter][i] = readb(&info->aty_cmap_regs->lut);
-		writeb(i, &info->aty_cmap_regs->windex);
-		writeb(atyfb_save.r[1-enter][i], &info->aty_cmap_regs->lut);
-		writeb(atyfb_save.g[1-enter][i], &info->aty_cmap_regs->lut);
-		writeb(atyfb_save.b[1-enter][i], &info->aty_cmap_regs->lut);
+		aty_ld_dac(i, &atyfb_save.r[enter][i], &atyfb_save.g[enter][i],
+			   &atyfb_save.b[enter][i], info);
+		aty_st_dac(i, atyfb_save.r[1-enter][i],
+			   atyfb_save.g[1-enter][i], atyfb_save.b[1-enter][i],
+			   info);
 	}
 }
 
@@ -1745,7 +1794,6 @@
 #endif
     u8 pll_ref_div;
 
-    info->aty_cmap_regs = (struct aty_cmap_regs *)(info->ati_regbase+0xc0);
     chip_id = aty_ld_le32(CONFIG_CHIP_ID, info);
     type = chip_id & CFG_CHIP_TYPE;
     rev = (chip_id & CFG_CHIP_REV)>>24;
@@ -2744,7 +2792,7 @@
 			   u_int transp, struct fb_info *fb)
 {
     struct fb_info_aty *info = (struct fb_info_aty *)fb;
-    int i, scale;
+    int i, scale = 0;
 
     if (regno > 255)
 	return 1;
@@ -2759,32 +2807,53 @@
 	i |= 0x2;	/*DAC_CNTL|0x2 turns off the extra brightness for gt*/
     aty_st_8(DAC_CNTL, i, info);
     aty_st_8(DAC_MASK, 0xff, info);
-    scale = (M64_HAS(INTEGRATED) && info->current_par.crtc.bpp == 16) ? 3 : 0;
-    writeb(regno << scale, &info->aty_cmap_regs->windex);
-    writeb(red, &info->aty_cmap_regs->lut);
-    writeb(green, &info->aty_cmap_regs->lut);
-    writeb(blue, &info->aty_cmap_regs->lut);
-    if (regno < 16)
-	switch (info->current_par.crtc.bpp) {
+    switch (info->current_par.crtc.gen_cntl & CRTC_PIX_WIDTH_MASK) {
+	case CRTC_PIX_WIDTH_15BPP:
+	    if (M64_HAS(INTEGRATED))
+		scale = 3;
 #ifdef FBCON_HAS_CFB16
-	    case 16:
+	    if (regno < 16)
 		info->fbcon_cmap.cfb16[regno] = (regno << 10) | (regno << 5) |
 						regno;
-		break;
 #endif
+	    break;
+
+#ifdef CONFIG_FB_ATY_CT
+	case CRTC_PIX_WIDTH_16BPP:
+	    /*
+	     *  Green has 6 bits and is stored every 4 entries
+	     *  Red and blue have only 5 bits and are stored every 8 entries
+	     */
+	    aty_st_dac(regno << 2, info->palette[regno/2].red, green,
+		       info->palette[regno/2].blue, info);
+	    green = info->palette[(2*regno) & 0xff].green;
+	    scale = 3;
+#ifdef FBCON_HAS_CFB16
+	    if (regno < 16)
+		info->fbcon_cmap.cfb16[regno] = (regno << 11) | (regno << 5) |
+						regno;
+#endif
+	    break;
+
 #ifdef FBCON_HAS_CFB24
-	    case 24:
+	case CRTC_PIX_WIDTH_24BPP:
+	    if (regno < 16)
 		info->fbcon_cmap.cfb24[regno] = (regno << 16) | (regno << 8) |
 						regno;
-		break;
+	    break;
 #endif
+#endif /* CONFIG_FB_ATY_CT */
+
 #ifdef FBCON_HAS_CFB32
-	    case 32:
+	case CRTC_PIX_WIDTH_32BPP:
+	    if (regno < 16) {
 		i = (regno << 8) | regno;
 		info->fbcon_cmap.cfb32[regno] = (i << 16) | i;
-		break;
-#endif
 	    }
+	    break;
+#endif
+    }
+    aty_st_dac(regno << scale, red, green, blue, info);
     return 0;
 }
 

Gr{oetje,eeting}s,

						Geert

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

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [Linux-fbdev-devel] using fbdev

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

For those dying to know.

You have to open /dev/tty and send a do a

write(fd, "\33[25;1H", 7);

This clears the screen if the cursor is in the top row. 

> How do I make the the text contents of the console redraw at the end of
> a fb using program?
> 
> The following program works as expected (on PPC, aty128fb) - paints the
> top of the screen blue. When it exits the screen remains blue. A console
> switch to another VC and back clears the blue and draws the text that
> was there. What I want is to have this happen automatically at program's
> exit.