--6iXXu7NwgEt9u5a7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, May 22, 2006 at 04:29:16PM -0700, Garrett D'Amore wrote:
> I now have a Radeon framebuffer driver that supports multiple output
> ports, and can detect the supported resolutions (and preferred) of
> monitors connected to it.  (No, this driver isn't open source -- YET,
> I'm still trying to make that happen.)

Cool.

> But when the display is acting as a text console, you don't have a
> pointer, and it isn't clear how to drive panning.   So the lower
> resolution display just loses.

Given that the fundamental here is a text console, could you render
the same text at lower font resolution?  Or SIGWINCH it each time it
attaches to either output?

Way, way back when, a friend of mine developed some hacks for the
primordial linux kernel (around 0.10 or 0.11, shortly before there was
NetBSD and I stopped using it) that allowed VT's to move between
simultaneous [CEV]GA and MDA heads (because they lived at different
ISA addresses).  The tty just changed size and got SIGWINCH as it
moved between displays, and that worked quite well (it forbade the
same VT being on both heads simultaneously).

The same infrastructure would be needed to support other kinds of user
changes, even on a single head: changes of graphic resolution, or
changes of font-rendering resolution, producing a different size
character grid result. =20

I guess it comes down to getting the user model right: between the
three variables of pixel/screen resolution, font resolution, and
character-grid resolution/tty size you probably want something that
allows a "pick any two" and derives the third, within a set of various
constraints (inlcuding, as you note, preferred resolutions for LCDs).

> Should I just force a VGA resolution by default, rather than trying to
> be friendly to larger displays.

No, though perhaps this might be an idea if it helps move some of this
decision logic out to userland, given the ability to change
resolutions (both pixel and character) as above.

> Should we have a common method to support panning (hot keys?) of text
> screens?  Perhaps also panning based on a mouse position in a text
> console?  (Though not all h/w will have mice available.)

screen does a reasonable job of this when multiple tty's are attached
to the same virtual screen, panning the smaller one(s) on the basis of
the cursor position.  Perhaps that's also a clue that there's no point
trying to support this in two places, and that one of the above
methods is more suitable to kernel use (if at all).

> How much do folks hate panning?  To what lengths should I go to avoid it?

If there's a graphics app running on the display, it needs a way to
discover properties and control the display.  If the underlying
hardware includes a viewport for panning, and exposing that is less
work and cruft than all the other machinations to avoid it, fine.  If
you need to do work to emulate this panning on lesser hardware, that's
probably much less desirable, but it depends whose desires are driving
the design.

But for plain kernel use without the rest of the toolkit stack, KISS.

--
Dan.

--6iXXu7NwgEt9u5a7
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFEcl/cEAVxvV4N66cRAg4cAJ9yA1ybvCdZNSZoJWqLDwbOhYIdJQCgzkDb
IHA6LQhW8aRLbrGr52HCHQY=
=SHeC
-----END PGP SIGNATURE-----

--6iXXu7NwgEt9u5a7--