Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.wildstar.net!newsfeed.direct.ca!hunter.premier.net!news-res.gsl.net!news.gsl.net!usenet.eel.ufl.edu!news.mathworks.com!newsfeed.internetmci.com!in3.uu.net!news.eng.lycos.com!cantaloupe.srv.cs.cmu.edu!jmcc
From: jmcc@m5.vi.ri.cmu.edu (Jason Mcmullan)
Newsgroups: comp.os.linux.development.apps,comp.os.linux.development.system,comp.os.linux.x,comp.os.linux.hardware,comp.os.linux.setup,comp.unix.bsd.386bsd.misc,comp.unix.bsd.bsdi.misc,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc,misc.consumers
Subject: Re: Why not buy Matrox Millennium
Followup-To: comp.os.linux.development.apps,comp.os.linux.development.system,comp.os.linux.x,comp.os.linux.hardware,comp.os.linux.setup,comp.unix.bsd.386bsd.misc,comp.unix.bsd.bsdi.misc,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc,misc.consumers
Date: 13 Aug 1996 02:32:47 GMT
Organization: Carnegie-Mellon University, School of Computer Science
Lines: 54
Message-ID: <4uopgf$si4@cantaloupe.srv.cs.cmu.edu>
References: <4j21ph$crr@slappy.cs.utexas.edu> <873f1tjxf1.fsf@xeno.xinside.com>
NNTP-Posting-Host: m5.vi.ri.cmu.edu
X-Newsreader: TIN [version 1.2 PL2]
Xref: euryale.cc.adfa.oz.au comp.os.linux.development.apps:20278 comp.os.linux.development.system:29653 comp.os.linux.x:37842 comp.os.linux.hardware:47361 comp.os.linux.setup:68404 comp.unix.bsd.386bsd.misc:1036 comp.unix.bsd.bsdi.misc:4597 comp.unix.bsd.netbsd.misc:4376 comp.unix.bsd.freebsd.misc:25386 misc.consumers:94265
Thomas Roell (roell@xinside.com) wrote:
: In article <4ujl2j$2k6@pell.pell.chi.il.us> orc@pell.chi.il.us (Orc) writes:
: > >> it runs; it takes a perfectly normal 80x30 or 80x25x20scanline screen
: > >> and converts it into a 80x25 screen.
: > >
: > >That is not a bug. It is a documented behaviour.
: >
: > Yes, but it's wrong documented behavior; from what I've seen of the
: > xinside server, it looks all nice and good, but I'm certainly not going
: > to spend money on software that mangles all of my text consoles. If
: > there was any assurance that you'd remove this misfeature, I'd be willing
: > to send xinside the $100 or whatever so I could get a copy of the server
: > after you removed that feature and left the text consoles alone.
: Maybe I was not clear in previous postings. So let's get down to the
: technicalities again. It is not possible to read back the state of ALL
: graphics chip related registers. What XF86 does is majorly guesswork
: on registers that cannot be read back. Our experiments have shown that
: trying to guess about those registers leads in a high number of cases
: (read non-standard cases) to screwedup systems and total lockups. As I
: do not consider this apropriate Xaccel forces 80x25. One thing to
: remember is that I originally came up with the approach to read back
: that stuff in X386, which are the roots of XF86. So it might occur to
: you that I have not removed this mis-feature from Xaccel to screw
: users. A future version of Xaccel however might allow restoring of a
: limited set of other textmodes that are safe to be restored.
Hmm... Excuse me, but why don't you have a
'experimental-do-not-use-it-will-kill-your-data' reset-to-text
flag in your config file that does this sequence of events....
* Make sure user has the 'FooBar' chipset like he told me..
* Do the X thang...
- VT Switch TIME!
* What size of screen did the user tell me he used? (XxY)
* Set card to that screen mode if possible, 80x25 otherwise
* ioctl(vt_Device,VT_RESIZEX,..) /* See include/linux/vt.h */
- VT Switchback TIME!
* Exit X time!
- (just like VT switch time)
Unless the video support that you have in you loadable modules
(vgaSetText, from nm(1)) is inadequite to the task of arbitray
resizing, I would say you're all set to support the diehard
115x91 fans...
--
Copyright 1995 Jason McMullan; all rights reserved.
Me: http://www.ul.cs.cmu.edu/~jmcc
Linux GGI: http://www.ul.cs.cmu.edu/~jmcc/ggi.html