From owner-freebsd-hackers Thu Mar 7 19:15:08 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA02769 for hackers-outgoing; Thu, 7 Mar 1996 19:15:08 -0800 (PST) Received: from gw.pu.ru (slip-0.pu.ru [193.124.85.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA02757 for ; Thu, 7 Mar 1996 19:15:00 -0800 (PST) Received: from VexedVox.stud.pu.ru (root@localhost) by gw.pu.ru (8.6.10/8.6.6) with UUCP id GAA02421 for freebsd.org!hackers; Fri, 8 Mar 1996 06:12:43 +0300 Received: from freefall.FreeBSD.ORG (uucp@localhost) by localhost (8.6.12/8.6.12) with UUCP id GAA29874; Fri, 8 Mar 1996 06:11:19 +0300 Received: from ns.okbmei.msk.su (ns.okbmei.msk.su [194.190.170.40]) by gw.pu.ru (8.6.10/8.6.6) with SMTP id GAA02358; Fri, 8 Mar 1996 06:04:18 +0300 Received: from kiae.UUCP by ns.okbmei.msk.su with UUCP id AA01526 (5.67c8/IDA-1.5); Fri, 8 Mar 1996 05:43:26 +0300 Received: from freefall.FreeBSD.ORG by sovcom.kiae.su with SMTP id AA22298 (5.65.kiae-1 for ); Fri, 8 Mar 1996 05:14:31 +0300 Received: from localhost (daemon@localhost) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA21435 Thu, 7 Mar 1996 16:56:36 -0800 (PST) Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA21341 for hackers-outgoing; Thu, 7 Mar 1996 16:55:42 -0800 (PST) Received: from gw.pu.ru (slip-0.pu.ru [193.124.85.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA21335 for ; Thu, 7 Mar 1996 16:55:31 -0800 (PST) Received: from VexedVox.stud.pu.ru (root@localhost) by gw.pu.ru (8.6.10/8.6.6) with UUCP id DAA01236 for freebsd.org!hackers; Fri, 8 Mar 1996 03:51:42 +0300 Received: from lambert.org (uucp@localhost) by localhost (8.6.12/8.6.12) with UUCP id DAA29135; Fri, 8 Mar 1996 03:38:18 +0300 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by gw.pu.ru (8.6.10/8.6.6) with ESMTP id DAA00870; Fri, 8 Mar 1996 03:19:16 +0300 Organization: SPb State University Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA15166; Thu, 7 Mar 1996 17:14:21 -0700 From: Terry Lambert Message-Id: <199603080014.RAA15166@phaeton.artisoft.com> Subject: Re: direct access to video card To: root@VexedVox.stud.pu.ru (Alexey Pialkin) Date: Thu, 7 Mar 1996 17:14:21 -0700 (MST) Cc: infinet.com!macgyver@VexedVox.stud.pu.ru, freebsd.org!hackers@VexedVox.stud.pu.ru, uriah.heep.sax.de!joerg_wunsch@VexedVox.stud.pu.ru In-Reply-To: <199603072212.BAA10146@localhost> from "Alexey Pialkin" at Mar 8, 96 01:12:35 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Charset: KOI8-R X-Char-Esc: 29 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > For example, what funication call would I make to say, set the > > videocard to various mode? I suppose I could use inline asm > > within GCC. Though I rather not do that. > > BTW, i am interesting in this too. I would like to use FreeBSD for some > experiments in graphics and i _really_ don't whant to use 'X'.. > 'X' are really slow on my 486/8... > > Now i know how to setup some video mode : > ioctl(0,SW_VGA13,(char*)0); > > but ^^^^^^^^^^^^^^^^^^^^ doesn't solve some problems :((( After such mode switch > doesn't work Alt+Fx switching - and so i can't debug program :((((( > and the second - does anybody work on VESA(2.x will be great !) support ? > i think it will be great ... The console drive can only support generic video modes, short of a VM86() mechanism to enable calls to the video BIOS INT 10 mode switch. Note that many DRAM implementations "cheap out" on vertical blank interrupts, and so if you use the INT 10 calls, all interrupts are disabled until the INT 10 call completes (the correct way would be to use the local-to-the-card vertical blank interrupt as a clock and not disable other cards ability to generate interrupts). Paradise and older ATI cards are known offenders. Really, you want to move the X DDX into the kernel and build a generic VGS/SVGA/other mode set on top of that (and then make X use it). That way, the console driver would never find itself in a mode it couldn't switch out of or back into. It's the X server's use of promiscuous mode changes (ie: without informing the console driver host to get out or back) that prevents you from debugging kernel panics that occur while you are running X. Because the mode switch requires sending a command to the X server to restore the console state, and the kernel is panic'ed so the X server can't run and therefore can't respond to the request, you are pretty much screwed. If you wanted to do this yourself, you'd have to do the message handling the X server does for console mode switch, which would fix your virtual console switch problems (at least until the first time your machine got a panic). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.