Re: [patch] VRAM detection in controlfb

On Sat, Jun 03, 2000 at 08:28:25AM +0200, Michel Lanners wrote:

For those with multiple display adapters, do you think an option
controlfb:off might make sense? As there is no way to control which card
gets assigned which framebuffer device, that might help in certain
situations...

Yes, sounds like a great idea.

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Sat, Jun 03, 2000 at 08:28:25AM +0200, Michel Lanners wrote:

For those with multiple display adapters, do you think an option
controlfb:off might make sense? As there is no way to control which card
gets assigned which framebuffer device, that might help in certain
situations...

I believe you can set which driver gets init'ed first by using the args:

video=foo:blah video=bar:blah

foo's _init will be called first, and bar's next, (therefore being fb0 and
fb1 respectively).


ani


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Hi all,

On   3 Jun, this message from Ani Joshi echoed through cyberspace:

quoted

For those with multiple display adapters, do you think an option
controlfb:off might make sense?

Silly me; that's already taken care of in fbmem.c.

quoted

As there is no way to control which card
gets assigned which framebuffer device, that might help in certain
situations...

I believe you can set which driver gets init'ed first by using the args:

video=foo:blah video=bar:blah

Right, that's handles in fbmem.c. Unfortunately, I've never seen it
documented anywhere... So, I've started to write up a doc about
framebuffer kernel command line options. I've come across a few
oddities; among others the format of options:

1. What do the vc: and map: options do?
2. Why can you specify more options after 'scrollback:', separated with
   a ',', but not after the 'map:' option (no other options possible),
   whereas you can have more options following 'vc:', but without a
   separator?

Thanks

Michel

BTW, anybody have the fbutils compiled for 2k and recent kernels? I
can't seem to get it to compile....

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Michel Lanners wrote:

1. What do the vc: and map: options do?

map: maps framebuffer devices to VCs. E.g. I use

	video=pm2fb:... video=amifb:... video=map:000011

So pm2fb is fb0 and amifb fb1, and VCs 1-4 are handled by pm2fb while 5 and
six are handled by amifb. Hope you get the idea.

2. Why can you specify more options after 'scrollback:', separated with
   a ',', but not after the 'map:' option (no other options possible),

I guess it doesn't make sense to mix map: with device specific options because
it affects all devices.

   whereas you can have more options following 'vc:', but without a
   separator?

If only I knew what vc: is for :)


Michel


--
...and that is how we know the Earth to be banana-shaped.
______________________________________________________________________________
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86, Team *AMIGA*, AUGS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/