>But, on the other hand, PalmOS doesn't
>officialy support grayscale (yet), so don't complain too much, OK?

I understand the Zen of Palm but its rather funny that Palm doesn't even
support grayscale while CE machines are going 256 color.


-----Original Message-----
From: Bob Ebert <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Tuesday, March 30, 1999 8:09 PM
Subject: Re: Bug in OS 3.1


At 1:54 AM -0800 3/27/99, Tim Smith wrote:
>When switching screen modes using ScrDisplayMode(), the contrast setting
>is lost.
>
>Although man-handling the Dragonball chip direct does not reset the
>contrast setting - but I though we weren�t supposed to do that any more
>;)
>
>Any way round this?

Not cleanly -- this just came up in a thread called "New headers posted
when?"


...I guess it pays to choose descriptive subject lines.


Anyway, here's the scoop:

ScrDisplayMode inits the hardware when it changes the depth.  As part of
reinitializing the hardware, the hardware contrast is set to a default
value.

Clearly that's not right.  (But, on the other hand, PalmOS doesn't
officialy support grayscale (yet), so don't complain too much, OK?)

Anyway, as to how to work around this for the time being... the best
(hacky) way is to use SysLCDContrast twice, once to get the value and then
again to reset the value.

That is: SysLCDContrast(true, SysLCDContrast(false, 0));

This works because SysLCDContrast saves the user's setting--it has to, so
the contrast can be set properly when we turn the display off and back on.
Anyway, it returns the saved setting rather than read the hardware.  So
when you call it to read, you get the old user value, then when you call it
a 2nd time to write, you force the old saved value back into the hardware
setting.

The contrast adjust dialog actually does this when it opens, so if you just
press the contrast button or call ContrastAdjust() the contrast will
immediately re-adjust itself.  ...but then you're left with a dialog on the
screen.

This (hacky) fix should be inconsequential when the OS is eventually fixed.

--Bob






Reply via email to