From owner-freebsd-hackers Fri Oct 23 11:41:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA28940 for freebsd-hackers-outgoing; Fri, 23 Oct 1998 11:41:44 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA28749 for ; Fri, 23 Oct 1998 11:40:02 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id LAA00564; Fri, 23 Oct 1998 11:40:55 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199810231840.LAA00564@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: David Dawes cc: Mike Smith , Greg Lehey , Jason Thorpe , Nick Hibma , FreeBSD hackers mailing list Subject: Re: multi-user: multiple consoles in FreeBSD In-reply-to: Your message of "Fri, 23 Oct 1998 13:30:06 +1000." <19981023133006.D20302@rf900.physics.usyd.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Oct 1998 11:40:55 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The PCI spec doesn't provide a device-independent way of remapping the > VGA compatibility resources. They are not relocatable in the sense of > normal PCI resources defined through the base address registers. In my > experience, most PCI BIOSs disable memory and I/O access for secondary > VGA-compatible cards by clearing the appropriate bits in the PCI command > register. Hmm, Ok, I'm obvoiusly out of whack here. This would imply that there's not an alternate set of mappings that can be enabled to access the same register sets in any "standard" fashion? > We (XFree86) are currently grappling with these issues for our multi-head > support in 4.0. One thing we're hoping to do is multiplex access to > fixed resources like the VGA-compatiblity registers when needed and when > they can be disabled but not relocated. If on some OSs the video BIOS > could be called by the X server, it may help with initialisation issues. > It might be even better of the OS took care of this at boot time. Hmm. I'm working around this area at the moment, although Kazu is definitely the authority on the matter. I presume you're referring to something like: - Disable primary VGA compatibility mappings - Disable primary VGA BIOS mapping - Foreach non-primary video adapter - Enable VGA compatibility mappings - Enable VGA BIOS mapping - Make BIOS initialisation call(s) - Disable VGA compatibility mappings - Disable VGA BIOS mapping - Ensable primary VGA compatibility mappings - Ensable primary VGA BIOS mapping as well as providing some mechanism for nominating which card of the set should be mapped at any given time? Any ideas as to whether card BIOSses would respond well to having their initialisation code called in v86 mode rather than real mode? I think this sort of approach could be quite viable. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message