I have an Ultra 2 with Creator (FFB) frame buffer, running under Solaris
10.

Xdpyinfo shows that it has four visuals for TrueColor and another four for
PseudoColor. I gather that one (maybe two) of these puts the FFB into
"linear" mode, and the other(s) into "gamma" mode. It seems (on my system
at least) that the Visual_ID for the "linear" visual is 0x2C.

Normally, color values are "corrected" by raising them to the power 2.2,
because that is what CRTs require to give a linearly increasing level of
brightness, and LCD displays are also constructed to handle that for the
sake of compatibility (whether they actually require it internally, or
not).

The usual custom (arising from the earliest days of television) is to
store color values in already "corrected" form. So of 0xFF0000 gives you
bright Red, and you now want exactly half-bright Red, you actually store,
and give it, 0xBA0000 so that the Frame Buffer just passes that on (as a
voltage level) to the device.

But sometimes is is convenient to work internally with "linear" colors,
where half-bright Red is 0x7F0000. In that case you want to put your FFB
into "linear" mode, so that it applies the necessary correction itself.

You can use ffbconfig(1M) to set it to either mode (effective the next
time you start Xsun), but the default mode is "gamma", and if you set it
to "linear" all your colors from normal programs appear "washed out"
(except for a program that deliberately uses linear colors). I find it
useful to set my FFB to linear when playing around with colors in Gimp,
for example.

Now, if you set your system to "linear", there are certain programs
(Staroffice is the chief offender) that switch it back to "gamma" mode,
and leave it that way until you next start Xsun (i.e. at your next login).
My question is:
"HOW DOES IT DO IT?"

It is clear that user programs are capable of doing this (no root
privilege needed). I read somewhere (I wish I could remember where) that
there is some IOCTL which will set the FFB into the desired mode. But
truss reveals that Staroffice is not issuing any such IOCTL (and I doubt
it has the privilege to do it). Moreover, the Default Visual after the
change still has Visual_ID=0x2C. So it is more likely that it is sending
some message to the Display, and that it is actually Xsun that issues the
IOCTL. So the next question is
"WHAT MESSAGE DO YOU SEND TO THE DISPLAY TO CAUSE THIS?"

Next question then is
"WHAT IS THEN IOCTL THAT DOES IT?"

Man ffb(7D) gives a list of supported IOCTLs, but none of them
seems relevant for the purpose. Man ffbio(7I) gives details of them all,
but again none of them seems to do it.

Using truss on the running Xsun reveals that it makes many calls of
ioctl(('F'<<8)|28,...) (aka FBIOGCURMAX), which does not seem relevant,
but there is also one mysterious call on ioctl(('F'<<8)|96, ...) which I
cannot find documented in any #include file whatsoever.

So is that the culprit, and what is IOCTL "('F'<<8)|96" anyway?

All I want to be able to do is to switch between linear and gamma modes
without logging out. If Staroffice can do it, then it ought to be possible
for me. But how?

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5