[1672] in Release_7.7_team
X wrapper issues
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Feb 17 00:44:52 1999
Date: Wed, 17 Feb 1999 00:44:45 -0500 (EST)
From: Greg Hudson <ghudson@MIT.EDU>
To: release-team@MIT.EDU
CC: miki@MIT.EDU
I've taken a crack at writing an X wrapper script for Solaris. The
specifics I had in mind were:
* If /var/athena/x-one-time-mode exists, read the mode from there
* If /etc/athena/x-default-mode exists, read the mode from there
* Otherwise, pick a default (8 in 8.2, 24 in 8.3).
* Depending on the frame buffer type and mode, the X wrapper
script runs a frame buffer configuration command and then
execs the actual X server with the command-line options.
* xlogin will unlink /var/athena/x-one-time-mode on startup.
(If the wrapper script deletes it then it won't take effect
if the X server takes multiple tries to start up, so xlogin
should remove it.) A special login option to reset the mode
will just write out the file and exit.
The mode will be "8" or "24" and will determine either the default
visual depth for Ultra 10s (afb, ffb) or the only available depth for
Ultra 5s (m64).
This sounds nice and uncomplicated. Now the snags I ran into:
* You don't actually set a 24-bit visual on afb or ffb by
running {afb,ffb}config -deflinear true. That may work by
coincidence, but what it's actually trying to do is make a
gamma-corrected visual the default, not a 24-bit visual.
What you're supposed to do instead is run something like
"Xsun -dev /dev/fb defdepth 24".
So the way you select the default visual is different from
the way you configure the M64 graphics card. That
complicates the wrapper script a little but not terribly.
* Because we have to switch around the resolution when we
switch around the bit depth, we could run into problems with
monitors which can't do 1280x1024. We can try to probe the
monitor (m64config -res \?), but not all monitors can be
probed. I guess we can have the script verify that the
frame buffer and monitor look like something we can
predictably deal with, and refuse to touch anything if they
don't.
* The documentation for the m64 command is confusing.
First, m64config(1) does not document -depth. Second, it
the commands document a "now" option to program the M64
device immediately in addition to writing to the OWconfig
file, saying, "This is useful for changing the video mode
before starting the window system." But I thought the
window system would read that file on startup anyway, so I
don't see how it's ever useful. Which makes me think I'm
missing something.
* Machines with two frame buffers. They exist. Anything I do
would seem to have a nonzero chance of stomping on them. I
had the idea that the existence of an
/etc/athena/x-bypass-wrapper would make the wrapper script
not get in the way, but we may still bite people until they
touch that file.
* Some machines we won't be able to do much with at all, like
Sparc 5s and Sparc 4s, or perhaps on machines where we
decide the video setup is nonstandard. But there will still
be a special login option hanging around saying, "restart in
24-bit mode" (8.2) or "restart in 8-bit mode" (8.3).
I guess what we can do here is make the wrapper script touch
a file /var/athena/x-no-mode if it doesn't like the hardware
setup. xlogin can look for this file and, if it exists,
respond to an attempt to use that special option with a
message like "Not supported on this hardware".
* Our plans for 8.3 assume that 24-bit mode on M64 machines
will actually work reliably. That might be optimistic. If
we want the default to be different on different hardware
configurations, that will be a minor nightmare for the
xlogin special options.
