--Signature_Tue__17_May_2005_22_03_11_-0400_YDGxSMAp3si+yJIR
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hello,

just a few thoughts. In a Sun Ultra 5 or Ultra 10 the case that we have
more than one wsdisplay is pretty common - onboard ATI and an ffb. With
the old drivers that's no problem - /dev/console will point at the right
one. But not so with wscons - both will attach since the firmware nicely
initializes both displays. One will carry the (console) tag, but that's
not necessarily wsdisplay0, and to make things worse ttyE0 may not point
at the console output device - it will point at the first virtual
console on wsdisplay0.=20
On other platforms that's usually not a problem because the firmware
doesn't set up the additional displays ( Apple OpenFirmware for instance
).
So how are we supposed to handle this? wsconsctl and wsconscfg don't
seem to know about more than one output device, or would there be a
/dev/ttyEcfg for each one? Macppc's ofb throws up when you try to
attach and use more than one instance.=20
Multiple text displays produce interesting problems: =20
- how do we tell which display is active? No driver I've seen cares
about that so there's no way to tell. With multiple wsdisplays
'inactive' doesn't imply 'invisible'.=20
- how would we tell wsconscfg on which display we want to create a
virtual console?  =20
- the initially active virtual console should be the 'real' console - as
far as I can tell it's always ttyE0 though.  =20
- drivers don't know the difference between 'inactive but visible' and
'inactive and invisible' ( for instance when some Xserver runs ) - the
former case never occurs with just one active wsdisplay.

The obvious way out is of course not to attach a wsdisplay if the driver
in question isn't the console. But this raises another problem - it
would also keep this device from being usable by XFree86 if it's a PCI
framebuffer. Of course we can attach a /dev/fb* to it but that doesn't
help XFree.

So, I suggest the following for sparc64:
- don't attach a wsdisplay when the device isn't the console. Seems
consistent with other ports, namely macppc.
- attach /dev/fb* when appropriate ( SBus and UPA devices ), no matter
if we're console or not.

This won't allow to use a PCI framebuffer as 2nd head in X but it will
allow any UPA or SBus device. Maybe we should attach /dev/fb*s to PCI
framebuffers too and hack XFree to use them, but that's a hell of a job.
On the other hand - with this a PCI framebuffer has to be the 1st head
and all others must be something else. This leaves onboard framebuffers
usable in most common multihead setups so it's probably an acceptable
limitation ( for now at least ) but it would disable multihead on
PCI-only machines.

Of course we could force the console to be wsdisplay0 but that would
require changes in all display drivers - just postpone attaching
wsdisplay for any non-console devices using config_defer() or something
like that. Seems crude though.

And - why don't wsdisplays have /dev/ entries?

have fun
Michael

--Signature_Tue__17_May_2005_22_03_11_-0400_YDGxSMAp3si+yJIR
Content-Type: application/pgp-signature

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

iQEVAwUBQoqiX8pnzkX8Yg2nAQIlsQgAqFO67MfA3457OHR0KNYON6x+78FJ4ak0
wEUSLIu5a1X9VYKwEQxYTH7kqa+DnOHjoJIPsDdz5rQ9Vz4uhlhBIUN15q/StIDP
7qIyMinEALxx0WEprhxI37iAevyVvzGftYXpofgPRztpTelKG1UXBzOBZq4L+0W9
quynyi3cO03kQgX7j5/vgbyEHNwivnpD2MQQL7qBPTDy1k/cUKp7bpMls5itL+o6
jytsVqNOC4MqQ1spq2LpK6Q5XiMY83otxmm3sYemmnJYmgsaG0eVOcfv8YLRPzuG
xtaXNjY8OPCkjUUHX+TX9OWU5T+YjREkoLw4HZRfEczINL48VdIedQ==
=F2jT
-----END PGP SIGNATURE-----

--Signature_Tue__17_May_2005_22_03_11_-0400_YDGxSMAp3si+yJIR--