Date: Mon, 17 May 1999 15:58:38 -0400 (EDT) From: Kelly Yancey <kbyanc@alcnet.com> To: Dag-Erling Smorgrav <des@flood.ping.uio.no> Cc: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp>, freebsd-hackers@freebsd.org Subject: Re: modex support (again) Message-ID: <Pine.BSF.4.05.9905171511140.24408-100000@kronos.alcnet.com> In-Reply-To: <xzpso8vr0er.fsf@localhost.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On 17 May 1999, Dag-Erling Smorgrav wrote: > Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp> writes: > > In that sense, the support for 320x240 mode-X is minimal too. The > > driver can set up this mode, but has no knowledge or code to write to > > it. It is entirely up to the userland program to update the video > > buffer. (And it is true that there is very little use to this mode at > > the moment as we haven't seen anybody using it...) > > I believe the video_info_t etc. structures aren't able to accurately > describe how to address mode X. The graphics code in the graphical > screen savers and the splash screen decoders is written in such a way > that it does not care if the current mode is linear or windowed (a > linear frame buffer is a windowed frame buffer with a window size > large enough to hold the entire screen). Extending this code to work > with mode X is not trivial; you either have to write a separate > drawing function for mode X, or put so much magic in your drawing > function that it will bog down to something like 3 fps. And you can't > just look at your video_info_t and see that mode X is interlaced; you > have to *know* that you're running in mode X and that mode X is > interlaced. > > DES > -- > Dag-Erling Smorgrav - des@flood.ping.uio.no > I think you just nailed the problem here. It requires a prohibitive amount of effort to support modex video modes given the return. What I am thinking about is removing the 320x240 mode (since it is impossibly difficult to deal with)...no one is using it now so no one would be affected. I would also like to add a comment into one of the source files indicating why we have chosen not to support unchained VGA modes (ie. "modex" modes) so that we can prevent this question from arising again in the future. On a slightly related note, I am currently in the process of developing patches to add more useful "tweaked" modes to the video driver: graphics 720x480, 16 colors (90x30 8x16 character cells) graphics 256x256, 256 colors (32x32 8x8 character cells) graphics 296x220, 256 colors (37x27 8x8 character cells) text 90x25, 90x30, 90x43, 90x50, 90x60 The patches will also update vidcontrol to allow selecting any of the modes. I listed the character cell sizes I picked for the graphics modes...which brings me to an interesting question: how come we pick a single character cell size for video modes? For video modes 640x480 or more it would be nice to select what size the character cells are (for example, selecting an 8x8 cell size rather than 8x16 to double the number of characters which could be written). I'm not really sure what practical use there is for using graphics modes to render text (and hence why character cell sizes for graphics modes would even be used). But currently syscons can do it from VESA 800x600 (syscons renders the text). Presumably, though, if it is useful, there isn't anything preventing the implementation from being extended to all graphics modes (except for modex that is...but I'm now of the impression that should be axed). Finally, with syscons having the ability to render text fonts in graphics modes, shouldn't we be able to redefine the notion of character cell size for graphics modes to be the default character cell size and allow any available text font be used to render text in graphics modes? Just a thought, Kelly ~kbyanc@alcnet.com~ FreeBSD - The Power To Serve - http://www.freebsd.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9905171511140.24408-100000>