Date: Tue, 18 May 1999 04:17:47 +0900 From: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp> To: Dag-Erling Smorgrav <des@flood.ping.uio.no> Cc: Kelly Yancey <kbyanc@alcnet.com>, freebsd-hackers@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: modex support (again) Message-ID: <199905171917.EAA04418@zodiac.mech.utsunomiya-u.ac.jp> In-Reply-To: Your message of "17 May 1999 20:55:40 %2B0200." <xzpso8vr0er.fsf@localhost.ping.uio.no> References: <Pine.BSF.4.05.9905140930300.52692-100000@kronos.alcnet.com> <xzpso8z3fxt.fsf@localhost.ping.uio.no> <199905171637.BAA01434@zodiac.mech.utsunomiya-u.ac.jp> <xzpso8vr0er.fsf@localhost.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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. That's correct for the current code. But, we can always extend it if at all necessary. >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 I am not asking you to do so :-) Splash screen decoders, screen savers, or any other graphics programs may choose whichever video mode they like to support. If they don't want the complexity of the mode X, they don't need to support it. >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. Well, how about this. If we are to add a way to describe the frame buffer organization, then graphics programs can identify interlaced video mode X among available video modes. As it is the program which will request the video mode change, the programs that don't like interlaced modes can decide to ignore those modes and use other, simpler video modes. Noboby is forcing you to use the interlaced modes... Anyway, I am not adovocating all those wacky mode X. I am perfectly happy if everybody can agree in dropping these modes. Kazu 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?199905171917.EAA04418>