Date: Mon, 17 Feb 1997 12:02:40 -0700 From: Jeremy Chatfield <jdc@xinside.com> To: Chris Csanady <ccsanady@nyx.pr.mcs.net> Cc: FreeBSD-hackers@FreeBSD.org, FreeBSD-current@FreeBSD.org Subject: Re: pcvt/132 columns Message-ID: <3308AB50.16DC6A2D@xinside.com> References: <199702170127.TAA02237@nyx.pr.mcs.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Chris Csanady wrote: > > Just a thought, but what about using some sort of generic frame buffer driver > in the kernel. I dont think it should be the responsibility of the Xserver or > anything else to twiddle with the cards settings directly. The kernel would > just need to know a few card specific things about setting timings, etc. The > VT system, and X would both be a consumer of this interface. They would > issue ioctls or such requesting certain resolutions(the default vga, > resolutions > specified by the user in the kernel config, etc), or possibly to test/set > timings. This would also allow the creation of a machine independant console > driver--something that may not be immediately useful, but would be nice in the > future. There would hopefully be no more problems having different X/vt > resolutions. I've personally always wanted to have them identical, using a > nice tiny font, and not having to wait for the monitor to re-sync, or the card > to reset its timings upon switches. > > I'm not sure, but I think that netbsd has something like this for sun and some > other architectures, and also a generic console that uses it. I suppose X must > also have some of the necessary code as will if they work together. > > For what its worth, > chris I'll answer this one first, because it is easiest... Then I'll consider and reply to Soren and Terry's comments. I have this Internet system to fix up first though, so it may be a day before I get back on this. Unless I think of something amazing ;-) Framebuffers typically achieve a maximum of around 50-80,000 xStones on current PC hardware. Using the graphics accelerator chip will yield up to 1,000,000 xStone on commonly available PC hardware. Most people will notice a twenty fold performance drop. Many will even notice 10%. While we are aware of a couple of chips that are slower in accelerated mode than a plain frame buffer (only a couple of percent slower, admittedly), most graphics accelerators will at least triple the speed of display. The NetBSD usage for Sun's comes from standard X Consortium/The Open Group source code for the X Window System, with drivers delivered by Sun. The Sun drivers deliberately do not include their accelerated drivers for their high performance boards. The delay in switching is caused by several factors. Here's a few: 1/ saving and restoring graphics memory. If you have a 4MB graphics board, under X, and you want to switch to a different VT (X or text, no difference), the 4MB should be saved, and a different image switched in (that'll be handled by the switched-to X Server). There's a possible 16MB of copying to be done, switching between two X Server VT's, if I remember this code correctly. 2/ Depending upon the X Server and its' configuration, and the graphics board, probes to detect clocks on the graphics board may be used to determine the best clock. No one, to my knowledge, really caches this information, once found. So far it looks as though everyne just reruns the initialisation code for the grahics board, including probes. 3/ Keeping the clocks the same for text and graphics modes still doesn't help. There's still stuff that the X Server has to do, that is not desirable for text mode. 4/ Font formats for X and VT's have wildly different characteristics. One of the most important is that most X fonts are proportional. To see why this is a bad idea for the text mode, look at what a botch an xterm makes, when using a proportional font. It has no idea how wide the characters are; under some conditions they get spaced miles apart and under others they can overlap. 'ls' listings become amazingly warped... You could certainly choose a default face for both modes, such as Times Roman or Lucida or something, and used fixed width versions on the console... But I think that's rather overkill for the amount of work involved versus the aesthetics. Either you use text mode because you have to (don't want to run X, fear the security implications of X, memory use, etc), or you want a pretty face and so you run X with its' access to fonts and resolution... Thanks for the suggestions though. It would certainly make our lives simpler if everyone was happy with plain framebuffer performance! Cheers, JeremyC. -- Jeremy Chatfield, Phone: +1 303/298-7478 FAX:+1 303/298-1406 Commercial X Products - for sales/support/information please try: http://www.xinside.com mailto:info@xinside.com ftp://ftp.xinside.com/ Xi Graphics, 1801 Broadway, 17th Floor, Denver, CO 80202
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3308AB50.16DC6A2D>