diff options
| author | Daniel Drake <dsd@laptop.org> | 2010-11-30 20:31:49 +0000 |
|---|---|---|
| committer | Martin-Éric Racine <martin-eric.racine@iki.fi> | 2010-12-12 17:22:40 +0200 |
| commit | bae443bb46c81702a57d4914b7e56f17e5aa1f3a (patch) | |
| tree | a4559089a426ff814121222de5d12a06b55a53cb /src/cim | |
| parent | 5873bfa48f1c090d224adbc7ca7df3ebea0b198f (diff) | |
Improve handling of gamma correction in video vs graphics
The LX is a bit odd in that the palette can be used for gamma correction
of graphics data, or video data, but not both at the same time.
Right now, during X startup, X sets gamma correction (but without any
actual correction) causing the Geode driver to start using the palette
for graphics gamma correction. (this is just momentary)
Later on during startup, vg_set_custom_mode() switches to using the
palette for video gamma correction, and this is the end result.
If you later use xrandr to change the gamma, the palette starts being used
for graphics again.
If you VT switch, vg_set_custom_mode (momentarily) starts using the palette
for video, but then X jumps in with a gamma callback causing it to be used
for graphics again.
End result: no user visible bug, but this is inconsistent.
As there is no exposed mechanism for changing video gamma I suggest
we just drop that bit from vg_set_custom_mode(). Then the inconsistency
goes away.
Downside: this now becomes dependent on X setting gamma during startup.
I don't know when this was introduced but I think it is recent.
Aditionally, I think I found a (harmless) bug in
df_set_video_palette_entry, it doesn't do what the comments say.
Diffstat (limited to 'src/cim')
| -rw-r--r-- | src/cim/cim_df.c | 8 | ||||
| -rw-r--r-- | src/cim/cim_vg.c | 3 |
2 files changed, 7 insertions, 4 deletions
diff --git a/src/cim/cim_df.c b/src/cim/cim_df.c index 676ef3c..f81b740 100644 --- a/src/cim/cim_df.c +++ b/src/cim/cim_df.c @@ -983,11 +983,15 @@ df_set_video_palette_entry(unsigned long index, unsigned long palette) /* Ensure that the Graphic data passes through the Gamma * Correction RAM + * + * XXX is this a bug? perhaps it should be setting the bit so that video + * data is routed, according to the description above. + * it also mismatches df_set_video_palette(). */ dcfg &= ~DF_DCFG_GV_PAL_BYP; - /* The graphics and video data are passed through gamma - * correction RAM + /* Unset the "bypass both" bit to make sure the above selection (gfx/video + * data through gamma correction RAM) takes effect. */ misc &= ~DF_GAMMA_BYPASS_BOTH; diff --git a/src/cim/cim_vg.c b/src/cim/cim_vg.c index 6a8ea49..ff24221 100644 --- a/src/cim/cim_vg.c +++ b/src/cim/cim_vg.c @@ -1002,8 +1002,7 @@ vg_set_custom_mode(VG_DISPLAY_MODE * mode_params, int bpp) temp &= ~(DF_DCFG_CRT_SYNC_SKW_MASK | DF_DCFG_PWR_SEQ_DLY_MASK | DF_DCFG_CRT_HSYNC_POL | DF_DCFG_CRT_VSYNC_POL); - temp |= (DF_DCFG_CRT_SYNC_SKW_INIT | - DF_DCFG_PWR_SEQ_DLY_INIT | DF_DCFG_GV_PAL_BYP); + temp |= DF_DCFG_CRT_SYNC_SKW_INIT | DF_DCFG_PWR_SEQ_DLY_INIT; if (mode_params->flags & VG_MODEFLAG_NEG_HSYNC) temp |= DF_DCFG_CRT_HSYNC_POL; |