vesafb and *fb

vesafb and *fb

[Geert Uytterhoeven]

Yesterday I noticed on a box at work that if you compile in both vesafb and
atyfb (the box has an ATI 3D RAGE PRO), you get both fb0 (atyfb) and fb1
(vesafb). That's not supposed to happen.

Vesafb did print that the frame buffer was already in use, but it just
continued, cfr. this code:

    if (!request_mem_region(vesafb_fix.smem_start, vesafb_fix.smem_len, "vesafb")) {
	    printk(KERN_WARNING
		   "vesafb: abort, cannot reserve video memory at 0x%lx\n",
		    vesafb_fix.smem_start);
	    /* We cannot make this fatal. Sometimes this comes from magic
	       spaces our resource handlers simply don't know about */
    }

That was on plain 2.6.5. But to my surprise the latest 2.4 behaves the same.
This seems to have been changed in 2.4.15.
Does anyone know why this was changed?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.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


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: vesafb and *fb

[James Simmons]

I don't know why it is that way. I would think it should fail at this 
point. Anyone know why this is?


> Yesterday I noticed on a box at work that if you compile in both vesafb and
> atyfb (the box has an ATI 3D RAGE PRO), you get both fb0 (atyfb) and fb1
> (vesafb). That's not supposed to happen.
> 
> Vesafb did print that the frame buffer was already in use, but it just
> continued, cfr. this code:
> 
>     if (!request_mem_region(vesafb_fix.smem_start, vesafb_fix.smem_len, "vesafb")) {
> 	    printk(KERN_WARNING
> 		   "vesafb: abort, cannot reserve video memory at 0x%lx\n",
> 		    vesafb_fix.smem_start);
> 	    /* We cannot make this fatal. Sometimes this comes from magic
> 	       spaces our resource handlers simply don't know about */
>     }
> 
> That was on plain 2.6.5. But to my surprise the latest 2.4 behaves the same.
> This seems to have been changed in 2.4.15.
> Does anyone know why this was changed?
> 
> Gr{oetje,eeting}s,
> 
> 						Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.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
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
> 



-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Re: [Linux-fbdev-devel] vesafb and *fb

[Geert Uytterhoeven]

On Sat, 24 Apr 2004, James Simmons wrote:
> I don't know why it is that way. I would think it should fail at this
> point. Anyone know why this is?

I searched through my mailing list archives of lkml and fbdev in 2001, but
couldn't find who submitted the original patch. I guess it came from Alan.

Anyway, if this really is a problem for some people, we can always add a
`video=vesafb:force' flag for the unhappy few.

> > Yesterday I noticed on a box at work that if you compile in both vesafb and
> > atyfb (the box has an ATI 3D RAGE PRO), you get both fb0 (atyfb) and fb1
> > (vesafb). That's not supposed to happen.
> >
> > Vesafb did print that the frame buffer was already in use, but it just
> > continued, cfr. this code:
> >
> >     if (!request_mem_region(vesafb_fix.smem_start, vesafb_fix.smem_len, "vesafb")) {
> > 	    printk(KERN_WARNING
> > 		   "vesafb: abort, cannot reserve video memory at 0x%lx\n",
> > 		    vesafb_fix.smem_start);
> > 	    /* We cannot make this fatal. Sometimes this comes from magic
> > 	       spaces our resource handlers simply don't know about */
> >     }
> >
> > That was on plain 2.6.5. But to my surprise the latest 2.4 behaves the same.
> > This seems to have been changed in 2.4.15.
> > Does anyone know why this was changed?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.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] vesafb and *fb

[Alan Cox]

On Sul, 2004-04-25 at 14:13, Geert Uytterhoeven wrote:
> > >     if (!request_mem_region(vesafb_fix.smem_start, vesafb_fix.smem_len, "vesafb")) {
> > > 	    printk(KERN_WARNING
> > > 		   "vesafb: abort, cannot reserve video memory at 0x%lx\n",
> > > 		    vesafb_fix.smem_start);
> > > 	    /* We cannot make this fatal. Sometimes this comes from magic
> > > 	       spaces our resource handlers simply don't know about */

Various built-in video systems broke on that test because we didnt
have resources for them so the resources couldnt be allocated. Probably
if vesafb is enabled we should skip any primary video device (ie the one
with VGA_EN at boot)

Re: vesafb and *fb

[Geert Uytterhoeven]

On Sun, 25 Apr 2004, Alan Cox wrote:
> On Sul, 2004-04-25 at 14:13, Geert Uytterhoeven wrote:
> > > >     if (!request_mem_region(vesafb_fix.smem_start, vesafb_fix.smem_len, "vesafb")) {
> > > > 	    printk(KERN_WARNING
> > > > 		   "vesafb: abort, cannot reserve video memory at 0x%lx\n",
> > > > 		    vesafb_fix.smem_start);
> > > > 	    /* We cannot make this fatal. Sometimes this comes from magic
> > > > 	       spaces our resource handlers simply don't know about */
>
> Various built-in video systems broke on that test because we didnt
> have resources for them so the resources couldnt be allocated. Probably
> if vesafb is enabled we should skip any primary video device (ie the one
> with VGA_EN at boot)

But vesafb is meant to be used as a fallback, if no chipset-specific driver is
found.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.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


-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297