Date: Thu, 7 Mar 1996 17:14:21 -0700 (MST) From: Terry Lambert <lambert.org!terry@VexedVox.stud.pu.ru> To: root@VexedVox.stud.pu.ru (Alexey Pialkin) 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 Subject: Re: direct access to video card Message-ID: <199603080014.RAA15166@phaeton.artisoft.com> In-Reply-To: <199603072212.BAA10146@localhost> from "Alexey Pialkin" at Mar 8, 96 01:12:35 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603080014.RAA15166>