Date: Fri, 23 Oct 1998 10:53:52 +0900 From: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp> To: Mike Smith <mike@smith.net.au> Cc: Greg Lehey <grog@lemis.com>, Jason Thorpe <thorpej@nas.nasa.gov>, Nick Hibma <nick.hibma@jrc.it>, FreeBSD hackers mailing list <hackers@FreeBSD.ORG>, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: multi-user: multiple consoles in FreeBSD Message-ID: <199810230153.KAA18749@zodiac.mech.utsunomiya-u.ac.jp> In-Reply-To: Your message of "Thu, 22 Oct 1998 16:35:05 MST." <199810222335.QAA01865@dingo.cdrom.com> References: <199810222335.QAA01865@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> > Some display controllers (notably, 3D accellerators) have a jumper >> > to disable VGA mode completely, but then you only get a memory >> > mapped frame buffer (if you're lucky :-) >> >> Hmm. I think this is your proviso. You specifically mean VGA >> compatibility. Well, yes, if you want a graphics board to conform to >> a standard which only allows one board, then you can only use one >> board. But there's more than just a frame buffer if you disable this >> feature. > >Jason's gripe was that you con't have more than one video card because >the second wants its VGA-compatibility registers mapped in the same >place as the first. Unless there's something really odd going on, it's >relatively trivial to simply map the I/O ranges for display cards other >than the first somewhere else; you just need the smarts in your system >to do this. I think that's basically what the multi-headed X servers are doing. Therefore, that can be done in the kernel as well, theoretically. But, I think we will be facing another, nasty problem. Because the second PCI video card has not been mapped to the I/O and memory space until someone explicitly does so, the video hardware has not been initialized. For the first (primary) PCI video card, this won't be the problem, because the motherboard BIOS will map the video BIOS ROM of the first video card to the CPU memory space (at 0xc0000) and calls the ROM entry point and the video BIOS will do the rest. (This is done during POST, long before the FreeBSD kernel is loaded, of cource :-) If we are to use the second (or third) video card, we do this sort of initialization by ourselves and I guess we cannot expect to use the video BIOS on this video card; the BIOS expects the card and the BIOS itself is mapped to the usual, standard VGA I/O and memory space! Unless we know exactly which video chip set and card we are dealing with, initialization will be most difficult. Even if we figure out how we do this, we also have to know how to manipulate the card after initialization. If we are content with using only stadnard VGA video modes with this card, we may be OK. But, if we want to go beyond that, again we need to know quite a lot about the chip set and card. One exception will be the case that the VESA BIOS video extention on the first video card is able to handle the second card as well. The VESA specification mentions multiple video card support. But, this isn't a required feature and there doesn't appear to be detailed specification about this. I don't know if this is ever implemented by video card vendors. I also think this will apparently be possible only for the video cards from the same vendor. X servers will be relatively in good position to do this sort of thing. It has chip-specific knowledge and code anyway. (But I still suspect it's not always straightforward and easy. Some video cards may require slightly different way of initialization than others, even if they all use the same chipset.) Anyway, along with the VESA BIOS support, the `videoio' module was introduced to 3.0-CURRENT. It is intended to act as absract interface between syscons and video hardware. It is not yet perfect, but it will be just possible to write a driver module which will hook to videoio and provide support for the second, and third, fourth..., video cards. (The VESA BIOS support in 3.0 is implemented just like that.) As I pointed out above, such modules will be chip-set/card specific and you need to know quite much about video cards you want to support in order to write the driver modules. Kazu >Video chipsets not supporting this would be in violation of the PCI >spec. I wouldn't expect this to be too common. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810230153.KAA18749>