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

[Linux-fbdev-devel] Re: [PATCH?] Crash in 2.4.17/ptrace

[Andrew M. <ak...@zi...>]

Andrew Morton wrote:
> 
> Daniel Jacobowitz wrote:
> >
> > Frame buffers aren't reliable marked VM_IO when mapped, currently.  Ben
> > H. said he was going to push a fix for this at least to the PPC trees
> > today or tomorrow.
> 
> They are now, I hope.  I fixed that in 2.4.18-pre2.
>  drivers/video/fbmem.c:fb_mmap() marks the vma as
> VM_IO for all architectures.  But perhaps I missed some;
> an audit is needed in there, which I'll do.

I lied.  Linus applied it, but not, it seems, Marcelo.

So.  Here's a patch.

It marks all framebuffer mappings as VM_IO.  This prevents
kernel deadlocks which can occur when a program which
has a framebuffer mapping attempts to dump core.

It also allows get_user_pages() to detect and skip these
IO mappings, so ptrace, O_DIRECT, etc will not permit
I/O against these mappings.

I've Cc'ed linux-fbdev-devel.  Could someone please
review?



--- linux-2.4.18-pre7/drivers/video/acornfb.c	Thu Nov 22 23:02:58 2001
+++ linux-akpm/drivers/video/acornfb.c	Mon Jan 28 14:00:21 2002
@@ -1139,9 +1139,6 @@ acornfb_mmap(struct fb_info *info, struc
 	off += start;
 	vma->vm_pgoff = off >> PAGE_SHIFT;
 
-	/* This is an IO map - tell maydump to skip this VMA */
-	vma->vm_flags |= VM_IO;
-
 #ifdef CONFIG_CPU_32
 	pgprot_val(vma->vm_page_prot) &= ~L_PTE_CACHEABLE;
 #endif
--- linux-2.4.18-pre7/drivers/video/igafb.c	Thu Nov 22 23:02:58 2001
+++ linux-akpm/drivers/video/igafb.c	Mon Jan 28 14:02:10 2002
@@ -293,8 +293,6 @@ static int igafb_mmap(struct fb_info *in
 	if (!map_size)
 		return -EINVAL;
 
-	vma->vm_flags |= VM_IO;
-
 	if (!fb->mmaped) {
 		int lastconsole = 0;
 
--- linux-2.4.18-pre7/drivers/video/sgivwfb.c	Thu Nov 22 23:02:58 2001
+++ linux-akpm/drivers/video/sgivwfb.c	Mon Jan 28 14:02:49 2002
@@ -846,7 +846,6 @@ static int sgivwfb_mmap(struct fb_info *
     return -EINVAL;
   offset += sgivwfb_mem_phys;
   pgprot_val(vma->vm_page_prot) = pgprot_val(vma->vm_page_prot) | _PAGE_PCD;
-  vma->vm_flags |= VM_IO;
   if (remap_page_range(vma->vm_start, offset, size, vma->vm_page_prot))
     return -EAGAIN;
   vma->vm_file = file;
--- linux-2.4.18-pre7/drivers/video/fbmem.c	Fri Dec 21 11:19:14 2001
+++ linux-akpm/drivers/video/fbmem.c	Mon Jan 28 14:07:08 2002
@@ -543,6 +543,8 @@ fb_mmap(struct file *file, struct vm_are
 		lock_kernel();
 		res = fb->fb_mmap(info, file, vma);
 		unlock_kernel();
+		/* This is an IO map - tell maydump to skip this VMA */
+		vma->vm_flags |= VM_IO;
 		return res;
 	}
 
@@ -576,12 +578,13 @@ fb_mmap(struct file *file, struct vm_are
 		return -EINVAL;
 	off += start;
 	vma->vm_pgoff = off >> PAGE_SHIFT;
+	/* This is an IO map - tell maydump to skip this VMA */
+	vma->vm_flags |= VM_IO;
 #if defined(__sparc_v9__)
 	vma->vm_flags |= (VM_SHM | VM_LOCKED);
 	if (io_remap_page_range(vma->vm_start, off,
 				vma->vm_end - vma->vm_start, vma->vm_page_prot, 0))
 		return -EAGAIN;
-	vma->vm_flags |= VM_IO;
 #else
 #if defined(__mc68000__)
 #if defined(CONFIG_SUN3)
@@ -607,8 +610,6 @@ fb_mmap(struct file *file, struct vm_are
 	pgprot_val(vma->vm_page_prot) |= _CACHE_UNCACHED;
 #elif defined(__arm__)
 	vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
-	/* This is an IO map - tell maydump to skip this VMA */
-	vma->vm_flags |= VM_IO;
 #elif defined(__sh__)
 	pgprot_val(vma->vm_page_prot) &= ~_PAGE_CACHABLE;
 #else

Re: [Linux-fbdev-devel] HOWTO, FAQ, and Pennsylvania tacos

[Jimmy R. <jr...@ce...>]

Frederick Lefebvre wrote:

>     I am in the same postion as you are rigth now... could you forward me 
> any interresting answers you get from the list?  On my part, I found some 
> up-to-date documentation about the frame buffer api on kernelnewbies.org 
> in the documents section.  As for  device driver programming, I am using 
> "Linux device driver" from Oreilly.  The second edition offers really good 
> information on the 2.4.x kernel.


Heh... maybe you're the contractor our vendor is hiring to do this for us (but 
in a few more weeks than we can afford)?

I found an updated HOWTO at linuxdoc.org.
http://www.linuxdoc.org/HOWTO/Framebuffer-HOWTO.html

Looks like it has a lot more information than the one at linux-fbdev.org.

-- 
---------------------------------------------------------------------------
	      "I've always been a bit ahead of myself."
                                                              --Traci Lords

[Linux-fbdev-devel] HOWTO, FAQ, and Pennsylvania tacos

[Jimmy R. <jr...@ce...>]

Howdy, folks.

I find myself in a position where I need to write a framebuffer driver for a 
small (but very beautiful) LCD display for a PDA we're working on here, and we 
need it working yesterday.

If someone could point me in the direction of...

* 
A FAQ for the list, or something similar
* 
An up-to-date HOWTO (the version at www.linux-fbdev.org is for 2.2 kernels; 
I'm working with 2.4.16+)
* 
The name of a good taco shop in Pittsburgh
* 
And anything else that would be useful for a first-time linux-driver writer 
and framebuffer developer.

...I would greatly appreciate the assistance.

-- 
-------------------------------------------------------------------------
   "First they tell you you're wrong and they can prove it; then they
   tell you you're right but it isn't important; then they tell you it's
   important but they knew it all along."            (Charles Kettering)

[Linux-fbdev-devel] fbgen changes coming

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

Hi folks!!
 
   As you know changes to the fbdev api having been going into the dj
tree whcih eventually will go into Linus tree. One of the big changes
will soon be to fbgen.c. It will be reworked. Because of this I need all
people who maintain fbgen based fbdev drivers to work with me to push
forth these changes. I haven't finished the new fbgen just yet. I will be
doing some testing using a the 3Dfx fbdev driver which I have ported over 
to use the new fbdev api. So I also like Hannu Mallat to talk to me as
well. Thank you.  

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

[Linux-fbdev-devel] [PATCH] screen_base now in struct fb_info

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

I moved screen_base from struct display to struct fb_info. This is for teh
further seperation of the fbdev layer from fbcon to make the code smaller
and cleaner. The patch is pretty big. It is against Dave jones 2.5.2-dj5
tree. Please try it out. I like to submit a patch that works perfect. 


http://www.transvirtual.com/~jsimmons/screen_base.diff

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

Re: [Linux-fbdev-devel] atyfb has always failed here

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

> Since I have tryied to use atyfb (2.4.x) I've never been able to make it
> work. Even on the new 2.5 and the dj4 one it fails.
> 
> This is my card:
> ATI Technologies Inc Rage Mobility P/M AGP 2x (rev 100)

Can you use vga text and run lspci then post the results. You might be
using the framebuffer driver. 

Re: [Linux-fbdev-devel] The promised code for my newbie question

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

> >         if (ioctl(fbfd, FBIOGET_FCURSORINFO, &fcinfo)) {
> >                 printf("Error reading Fixed Cursor information.\n");
> >         } else {


Actually I think these are in fb.h. Does the driver actually implement
them?

Re: [Linux-fbdev-devel] Newbie needs help with application code

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

> I can draw stuff on the screen easily enough, but several of my ioctl calls
> are failing. (I'll enclose code below.) 

From looking at the code I assume it is the cursor stuff. THose are not
standard ioctl calls. Did they provide you with a driver specific header
file will those defined ioctl calls? 

> If cou could point me to a relevant
> document I'll gladly read it. What is not clear is if the things I'm trying
> to do, and how to do them, is legal. Right now, my two biggest questions
> are:
> 
> Can the linux framebuffer switch resolutions and color depth at runtime? 

If the driver supports it then yes. Try the program fbset to change the
depth or resolution.

> How do I overlay text on a graphics image in the frame buffer? 

With a draw character image function. Their are several tricks for this.
The most common and easiest way is to draw the image first then draw the
text now. This is know as the painters method.

> How do I put text on the screen? 

Same as above.

> Must I draw the pixels manually?

Depends. Is the driver hardware accelerated? IF it is then you mmap the
mmio region and program it. 

Re: [Linux-fbdev-devel] [PATCH] fbdev fbgen cleanup

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

> > The correct fix is to do something like fb_info.node = NODEV;
> 
> And not B_FREE ?
> 
> I am unsure about this, but i notice that in the 2.4.17 kernel + pm3fb, the
> value assigned to .node was -1, which correspond to B_FREE and not NODEV
> (which is 0).

Looking at it your right. It should be B_FREE.

> That said, since it is almost never used, it would maybe be best to move it
> out of the fbdevs and into some of the more generic layers.

I agree. In fact it is already does set it. Form rgeister_framebuffer

fb_info->node = mk_kdev(FB_MAJOR, i);

So why does any fbdev driver touch it?

> Also, since when does the B_FREE or NODEV exists ? I did put the changes into
> a #ifdef kernel 2.5, and kept the -1 for kernels 2.4, but i guess i could
> remove this check altogether if the NODEV was present from the begining. And
> what about 2.2 kernels ?

It is a 2.5.X thing. 

Re: [Linux-fbdev-devel] atyfb has always failed here

[Allan S. J. <sno...@on...>]

On Thursday 24 January 2002 07:28, Felipe Contreras wrote:
> Hi,
>
> Since I have tryied to use atyfb (2.4.x) I've never been able to make it
> work. Even on the new 2.5 and the dj4 one it fails.
>
> This is my card:
> ATI Technologies Inc Rage Mobility P/M AGP 2x (rev 100)
>
> I don't know if it's supported but at least I know someone that has the
> same card and it doesn't work neither.
>
> Should I stop waiting for atyfb to work on my chip?

I can confirm I have same problem with (rev 64). Although it works on one of 
my collegues _almost_ identical slightly older Thinkpad.

[Linux-fbdev-devel] Re: RFC: vesafb

[Geert U. <Gee...@so...>]

On Wed, 23 Jan 2002 ho...@au... wrote:
> The attached patch allows vesafb to work on PPC. vesafb does surprisingly

Nice!

> little with the BIOS (which I thought was the whole point of VESA). With some
> ifdef's I'm able to use it as sort of a VGA offb -- the firmware initializes
> the card, and the driver just uses it and never mucks with it.

Well, vesafb assumes the VESA BIOS initialized the card to some linear graphics
mode _before_ the real kernel code was started. Once the kernel is started, no
VESA calls are made, and the video mode is fixed.

So in theory (and you proved the practical side on PReP) it can be used on any
platform that initializes a more-or-less VGA card to a linear graphics mode.

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] RFC: vesafb (fwd)

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

---------- Forwarded message ----------
Date: Wed, 23 Jan 2002 13:20:10 -0600
From: ho...@au...
To: lin...@li...
Cc: sd...@re...
Subject: RFC: vesafb

The attached patch allows vesafb to work on PPC. vesafb does surprisingly
little with the BIOS (which I thought was the whole point of VESA). With some
ifdef's I'm able to use it as sort of a VGA offb -- the firmware initializes
the card, and the driver just uses it and never mucks with it.

This patch allows me to get an 800x600x8 console on the Thinkpad 850, and
640x480x8 on the Carolina machines. More interestingly it allows X to work on
the Thinkpad, which currently doesn't work and has never worked in >16 colors.
It should also work on the 7020 (Sven?), which uses the Weitek 9100 card and
currently is driverless.

This patch is only for PReP, which is probably the only place it's really
useful (since CHRP and PMac have offb), but would be easy enough to add to.

Comments?

-Hollis

Re: [Linux-fbdev-devel] [PATCH] fbdev fbgen cleanup

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

On Wed, 23 Jan 2002, Sven wrote:
> On Wed, Jan 23, 2002 at 11:57:34AM -0600, Carl Wilhelm Soderstrom wrote:
> > we just used SGI's X server for any GUI stuff.
> 
> Under IRIX i guess ...

I _think_ Linux/MIPS provides an IRIX-compatible /dev/graphics...

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] atyfb has always failed here

[Felipe C. <al5...@ma...>]

Hi,

Since I have tryied to use atyfb (2.4.x) I've never been able to make it
work. Even on the new 2.5 and the dj4 one it fails.

This is my card:
ATI Technologies Inc Rage Mobility P/M AGP 2x (rev 100)

I don't know if it's supported but at least I know someone that has the
same card and it doesn't work neither.

Should I stop waiting for atyfb to work on my chip?

-- 
Felipe Contreras

Re: [Linux-fbdev-devel] [PATCH] fbdev fbgen cleanup

[Sven <lu...@dp...>]

On Wed, Jan 23, 2002 at 11:57:34AM -0600, Carl Wilhelm Soderstrom wrote:
> > > I know there's some sort of framebuffer support for it; since it doesn't
> > > have a VGA mode. dunno anything more about it than that.
> > > the Indy also has the distinction of being the only SGI to have an XFree86
> > > driver for its video (newport).
> > 
> > Is this newport the same as indy 8-bit ? I had the impressoion that there were
> > multiple possibilities about it.
> 
> maybe. the two video board models I know about, are the 8-bit, and the
> 24-bit. dunno which is supported, or how well. we had one of each kind of

Ok, ...

> board, but I don't remember ever actually running linux/X on the Indy we
> had; tho we did use the console. 

if fbdev works, then it is fine with me. altough X would have been nice, i
suppose X with the fbdev driver would work on such a setup anyway, but may be
real slow, but not slower than on my 68030 amiga back then.

> we just used SGI's X server for any GUI stuff.

Under IRIX i guess ...

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] [PATCH] fbdev fbgen cleanup

[Carl W. S. <ch...@re...>]

> > I know there's some sort of framebuffer support for it; since it doesn't
> > have a VGA mode. dunno anything more about it than that.
> > the Indy also has the distinction of being the only SGI to have an XFree86
> > driver for its video (newport).
> 
> Is this newport the same as indy 8-bit ? I had the impressoion that there were
> multiple possibilities about it.

maybe. the two video board models I know about, are the 8-bit, and the
24-bit. dunno which is supported, or how well. we had one of each kind of
board, but I don't remember ever actually running linux/X on the Indy we
had; tho we did use the console. 
we just used SGI's X server for any GUI stuff.

Carl Sodertstrom.
-- 
Network Engineer
Real-Time Enterprises
(952) 943-8700

Re: [Linux-fbdev-devel] [PATCH] fbdev fbgen cleanup

[Sven <lu...@dp...>]

On Wed, Jan 23, 2002 at 11:42:50AM -0600, Carl Wilhelm Soderstrom wrote:
> > BTW, does someone know how i can get information about the hardware on a SGI
> > indy runing IRIX, i plan to do a linux install on it next week, but would like
> > to inspectr the box some before doing that. Is there any kind of fbdev working
> > for this kind of hardware ?
> 
> 'hinv' (Hardware INVentory) is the irix command you're looking for.

Yes, that is what i am looking for, as a result, i now know it has a r4600
processor, and an 'indy 8-bit' graphic board :)))

> I know there's some sort of framebuffer support for it; since it doesn't
> have a VGA mode. dunno anything more about it than that.
> the Indy also has the distinction of being the only SGI to have an XFree86
> driver for its video (newport).

Is this newport the same as indy 8-bit ? I had the impressoion that there were
multiple possibilities about it.

> we had one here for a while; and I saw it boot linux; but don't know any
> more than that.

Anyway, thanks for the info ...

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] [PATCH] fbdev fbgen cleanup

[Sven <lu...@dp...>]

On Wed, Jan 23, 2002 at 06:41:38PM +0100, Geert Uytterhoeven wrote:
> On Wed, 23 Jan 2002, Sven wrote:
> > On Wed, Jan 23, 2002 at 06:34:03PM +0100, Geert Uytterhoeven wrote:
> > > On Wed, 23 Jan 2002, Sven wrote:
> > > > Also, since when does the B_FREE or NODEV exists ? I did put the changes into
> > > > a #ifdef kernel 2.5, and kept the -1 for kernels 2.4, but i guess i could
> > > > remove this check altogether if the NODEV was present from the begining. And
> > > 
> > > IIRC, Marcelo added NODEV to 2.4.x in one of his latest releases, just to solve
> > > this problem.
> > > 
> > > > what about 2.2 kernels ?
> > > 
> > > No idea. Ask Alan :-)
> > 
> > Ok, so the best thing would be to keep the #ifdef then.
> > 
> > or maybe i could try an :
> > 
> > #ifdef NODEV
> > 	..node = NODEV
> > #else
> > 	..node = -1
> > #endif
> > 
> > ?
> 
> Or even shorter (and cleaner, IMHO):
> 
> #ifndef NODEV
> #define NODEV	-1
> #endif

yes, ...

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] [PATCH] fbdev fbgen cleanup

[Carl W. S. <ch...@re...>]

> BTW, does someone know how i can get information about the hardware on a SGI
> indy runing IRIX, i plan to do a linux install on it next week, but would like
> to inspectr the box some before doing that. Is there any kind of fbdev working
> for this kind of hardware ?

'hinv' (Hardware INVentory) is the irix command you're looking for.
I know there's some sort of framebuffer support for it; since it doesn't
have a VGA mode. dunno anything more about it than that.
the Indy also has the distinction of being the only SGI to have an XFree86
driver for its video (newport).

we had one here for a while; and I saw it boot linux; but don't know any
more than that.

Carl Soderstrom.
-- 
Network Engineer
Real-Time Enterprises
(952) 943-8700

Re: [Linux-fbdev-devel] [PATCH] fbdev fbgen cleanup

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

On Wed, 23 Jan 2002, Sven wrote:
> On Wed, Jan 23, 2002 at 06:34:03PM +0100, Geert Uytterhoeven wrote:
> > On Wed, 23 Jan 2002, Sven wrote:
> > > Also, since when does the B_FREE or NODEV exists ? I did put the changes into
> > > a #ifdef kernel 2.5, and kept the -1 for kernels 2.4, but i guess i could
> > > remove this check altogether if the NODEV was present from the begining. And
> > 
> > IIRC, Marcelo added NODEV to 2.4.x in one of his latest releases, just to solve
> > this problem.
> > 
> > > what about 2.2 kernels ?
> > 
> > No idea. Ask Alan :-)
> 
> Ok, so the best thing would be to keep the #ifdef then.
> 
> or maybe i could try an :
> 
> #ifdef NODEV
> 	..node = NODEV
> #else
> 	..node = -1
> #endif
> 
> ?

Or even shorter (and cleaner, IMHO):

#ifndef NODEV
#define NODEV	-1
#endif

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] [PATCH] fbdev fbgen cleanup

[Sven <lu...@dp...>]

On Wed, Jan 23, 2002 at 06:34:03PM +0100, Geert Uytterhoeven wrote:
> On Wed, 23 Jan 2002, Sven wrote:
> > On Mon, Jan 21, 2002 at 09:03:25AM -0800, James Simmons wrote:
> > > 
> > > > BTW, romain, i have built pm3fb with 2.5.2, there were some modifications
> > > > needed, the major of them was the testing for 2.2 or 2.4 kernels that needed
> > > > changing, and the new info.node, which needed to be changed to
> > > > info.node.values.
> > > 
> > > The correct fix is to do something like fb_info.node = NODEV;
> > 
> > And not B_FREE ?
> > 
> > I am unsure about this, but i notice that in the 2.4.17 kernel + pm3fb, the
> > value assigned to .node was -1, which correspond to B_FREE and not NODEV
> > (which is 0).
> > 
> > That said, since it is almost never used, it would maybe be best to move it
> > out of the fbdevs and into some of the more generic layers.
> > 
> > Also, since when does the B_FREE or NODEV exists ? I did put the changes into
> > a #ifdef kernel 2.5, and kept the -1 for kernels 2.4, but i guess i could
> > remove this check altogether if the NODEV was present from the begining. And
> 
> IIRC, Marcelo added NODEV to 2.4.x in one of his latest releases, just to solve
> this problem.
> 
> > what about 2.2 kernels ?
> 
> No idea. Ask Alan :-)

Ok, so the best thing would be to keep the #ifdef then.

or maybe i could try an :

#ifdef NODEV
	..node = NODEV
#else
	..node = -1
#endif

?

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] [PATCH] fbdev fbgen cleanup

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

On Wed, 23 Jan 2002, Sven wrote:
> On Mon, Jan 21, 2002 at 09:03:25AM -0800, James Simmons wrote:
> > 
> > > BTW, romain, i have built pm3fb with 2.5.2, there were some modifications
> > > needed, the major of them was the testing for 2.2 or 2.4 kernels that needed
> > > changing, and the new info.node, which needed to be changed to
> > > info.node.values.
> > 
> > The correct fix is to do something like fb_info.node = NODEV;
> 
> And not B_FREE ?
> 
> I am unsure about this, but i notice that in the 2.4.17 kernel + pm3fb, the
> value assigned to .node was -1, which correspond to B_FREE and not NODEV
> (which is 0).
> 
> That said, since it is almost never used, it would maybe be best to move it
> out of the fbdevs and into some of the more generic layers.
> 
> Also, since when does the B_FREE or NODEV exists ? I did put the changes into
> a #ifdef kernel 2.5, and kept the -1 for kernels 2.4, but i guess i could
> remove this check altogether if the NODEV was present from the begining. And

IIRC, Marcelo added NODEV to 2.4.x in one of his latest releases, just to solve
this problem.

> what about 2.2 kernels ?

No idea. Ask Alan :-)

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] [PATCH] fbdev fbgen cleanup

[Sven <lu...@dp...>]

On Mon, Jan 21, 2002 at 09:03:25AM -0800, James Simmons wrote:
> 
> > BTW, romain, i have built pm3fb with 2.5.2, there were some modifications
> > needed, the major of them was the testing for 2.2 or 2.4 kernels that needed
> > changing, and the new info.node, which needed to be changed to
> > info.node.values.
> 
> The correct fix is to do something like fb_info.node = NODEV;

And not B_FREE ?

I am unsure about this, but i notice that in the 2.4.17 kernel + pm3fb, the
value assigned to .node was -1, which correspond to B_FREE and not NODEV
(which is 0).

That said, since it is almost never used, it would maybe be best to move it
out of the fbdevs and into some of the more generic layers.

Also, since when does the B_FREE or NODEV exists ? I did put the changes into
a #ifdef kernel 2.5, and kept the -1 for kernels 2.4, but i guess i could
remove this check altogether if the NODEV was present from the begining. And
what about 2.2 kernels ?

Mmm, maybe i would have to check myself, will do that tomorrow, when i get
access to my work box again.

Romain, what is the earliest kernel you think pm3fb is able to run on, so i
can check it out.

BTW, does someone know how i can get information about the hardware on a SGI
indy runing IRIX, i plan to do a linux install on it next week, but would like
to inspectr the box some before doing that. Is there any kind of fbdev working
for this kind of hardware ?

Friendly,

Sven Luther

[Linux-fbdev-devel] The promised code for my newbie question

[Hihn J. <Jas...@DA...>]

> Whoops, I hit send accidentally.
> 
> #include <unistd.h>
> #include <stdio.h>
> #include <fcntl.h>
> #include <linux/fb.h>
> #include <sys/mman.h> 
> 
> int main()
> {
>         int fbfd = 0;
>         struct fb_var_screeninfo vinfo;
>         struct fb_fix_screeninfo finfo;
> 	struct fb_var_cursorinfo  vcinfo;
> 	struct fb_fix_cursorinfo  fcinfo;
> 	struct fb_cursorstate cstate;
> 
>         long int screensize = 0;
>         char *fbp = 0;
>         int x = 0, y = 0, bit, pow,c;
>         long int location = 0;         /* Open the file for reading and
> writing */
>         fbfd = open("/dev/fb0", O_RDWR);
>         if (!fbfd) {
>                 printf("Error: cannot open framebuffer device.\n");
>                 exit(1);
>         }
>         printf("The framebuffer device was opened successfully.\n");
> /* Get fixed screen information */
>         if (ioctl(fbfd, FBIOGET_FSCREENINFO, &finfo)) {
>             printf("Error reading fixed information.\n");
>         } else {
> 	    printf("fixed screen
> info(%s):\n\ttype=%d\n\tvis=%d\n\tll=%d\n\taccel=%d\n",
>                    finfo.id, finfo.type, finfo.visual, finfo.line_length,
> finfo.accel);
>         }
>         
>         /* Get variable screen information */
>         if (ioctl(fbfd, FBIOGET_VSCREENINFO, &vinfo)) {
>                 printf("Error reading variable information.\n");
>         } else {
>           printf("variable screen
> info:\n\txres=%d\n\tyres=%d\n\tbpp=%d\n\tgrey=%d\n\tnonstd=%d\n\taccel_fla
> gs
> =%d\n",
>                  vinfo.xres, vinfo.yres, vinfo.bits_per_pixel,
> vinfo.grayscale, vinfo.nonstd, vinfo.accel_flags);	
> 
>          /* Figure out the size of the screen in bytes */
>         screensize = vinfo.xres * vinfo.yres * vinfo.bits_per_pixel / 8;
>         }       
>         if (ioctl(fbfd, FBIOGET_FCURSORINFO, &fcinfo)) {
>                 printf("Error reading Fixed Cursor information.\n");
>         } else {
> 	printf("fcinfo:\tw=%d\n\th=%d\n\txs=%d\n\tys=%d\n\tc1=%dc2=%d\n",
>                 fcinfo.crsr_width,
>                 fcinfo.crsr_height,
>                 fcinfo.crsr_xsize,
>                 fcinfo.crsr_ysize,
>                 fcinfo.crsr_color1,
>                 fcinfo.crsr_color2);
> 	}
>         if (ioctl(fbfd, FBIOGET_VCURSORINFO, &vcinfo)) {
>                 printf("Error reading Variable Cursor information.\n");
>         } else {
> 	printf("vcinfo:\tx=%d\n\ty=%d\n", vcinfo.xspot, vcinfo.yspot);
> 	}
> 
>         if (ioctl(fbfd, FBIOGET_CURSORSTATE, &cstate)) {
>                 printf("Error reading Cursor State information.\n");
>         }else {   
> 	printf("vcinfo:\tx=%d\n\ty=%d\n\ts=%d\n", cstate.xoffset, 
>                cstate.yoffset, cstate.mode);
> 	}
> 
>         /* Map the device to memory */
>         fbp = (char *)mmap(0, screensize, PROT_READ | PROT_WRITE,
> MAP_SHARED,
>                 fbfd, 0);      
>         if ((int)fbp == -1) { 
>            printf("Error: failed to map framebuffer device to memory.\n");
> exit(4);
>         }
>         printf("The framebuffer device was mapped to memory
> successfully.\n");
> 
> 
>         /* Set variable screen information */
> vinfo.xres=320; vinfo.yres=240;
> vinfo.xres_virtual=320; vinfo.yres_virtual=240;
> vinfo.xoffset=0; vinfo.yoffset=0;
> vinfo.bits_per_pixel=1;
> 
>         if (ioctl(fbfd, FBIOPUT_VSCREENINFO, &vinfo)) {
>                 printf("Error setting variable information.\n");
>         }       
>    
>         /* Get variable screen information */
>         if (ioctl(fbfd, FBIOGET_VSCREENINFO, &vinfo)) {
>                 printf("Error reading variable information.\n");
>         } else {
>           printf("variable screen
> info:\n\txres=%d\n\tyres=%d\n\tbpp=%d\n\tgrey=%d\n\tnonstd=%d\n\taccel_fla
> gs
> =%d\n",
>                  vinfo.xres, vinfo.yres, vinfo.bits_per_pixel,
> vinfo.grayscale, vinfo.nonstd, vinfo.accel_flags);	
> 
>          /* Figure out the size of the screen in bytes */
>         screensize = vinfo.xres * vinfo.yres * vinfo.bits_per_pixel / 8;
>         }       
> 
> 
> 
> 	memset(fbp, time(NULL)%256, screensize);
>   
> 
> 
> 	munmap(fbp, screensize);
>         close(fbfd);
>         return 0;
> }
> 

[Linux-fbdev-devel] Newbie needs help with application code

[Hihn J. <Jas...@DA...>]

I'm trying to write a application to use the framebuffer interface. I am
running kernel 2.2 on a 832 PPC. I'm using a vendor provided driver for the
lcd interface.

There is no documentation on what I want to do. All the docs are on writing
a driver or getting software to work with the driver, but nothing on writing
software to work with the driver. What brings me here is the lack of docs
and my current problems.

I can draw stuff on the screen easily enough, but several of my ioctl calls
are failing. (I'll enclose code below.) If cou could point me to a relevant
document I'll gladly read it. What is not clear is if the things I'm trying
to do, and how to do them, is legal. Right now, my two biggest questions
are:

Can the linux framebuffer switch resolutions and color depth at runtime? and
How do I overlay text on a graphics image in the frame buffer? How do I put
text on the screen? Must I draw the pixels manually?

Many thanks in advance!