Menu
▾
▴
linux-fbdev-devel
|
From: Petr V. <VAN...@vc...> - 2001-11-23 14:35:06
|
On 23 Nov 01 at 14:44, Benjamin Herrenschmidt wrote:
> >> cmap for regno 32..63, we should ignore R and B and only use
> >> G, or did I miss something ?
> >
> >Yes, that's what I did for atyfb (experimental 565 patch which doesn't work
> >very well yet :-(
>
> Ok, well, it doesn't quite work yet but I suspect some X brokenness here.
> I'll got that fixed in both radeonfb and aty128fb this week-end hopefully.
Export truecolor (with RAMDAC hardwired to 1:1) and be happy... X works
very well in that mode, and setcolreg does not have to program each
RAMDAC register twice even if you reprogram complete palette.
Petr Vandrovec
van...@vc...
|
|
From: Petr V. <VAN...@vc...> - 2001-11-23 18:36:30
|
On 23 Nov 01 at 16:34, Benjamin Herrenschmidt wrote:
> >Except that you can't change gamma, or am I on the wrong track here?
No. But it is much better to provide _global_ gamma correction setting,
so you can then apply this gamma table even to 8bit palettized mode,
and even without app knowledge.
> So for 5:6:5, doing only truecolor (and hard coding a linear ramp
> in the chip's LUT) would do the trick for now. MOL can use gamma too
> but it doesn't do 5:6:5, so it's a non-issue.
Petr
|
|
From: Michel <mic...@ii...> - 2001-11-23 19:33:22
|
On Fri, 2001-11-23 at 20:36, Petr Vandrovec wrote: > On 23 Nov 01 at 16:34, Benjamin Herrenschmidt wrote: >=20 > > >Except that you can't change gamma, or am I on the wrong track here? >=20 > No. But it is much better to provide _global_ gamma correction setting, > so you can then apply this gamma table even to 8bit palettized mode, > and even without app knowledge. That would require a new API, no? Right now, apps use the colormap for this, and I'd hate to prevent them from doing so just because it's hard to get right. --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
|
From: Petr V. <VAN...@vc...> - 2001-11-23 20:10:00
|
On 23 Nov 01 at 20:33, Michel D=E4nzer wrote:
> On Fri, 2001-11-23 at 20:36, Petr Vandrovec wrote:
> > On 23 Nov 01 at 16:34, Benjamin Herrenschmidt wrote:
> >
> > > >Except that you can't change gamma, or am I on the wrong track here=
?
> >
> > No. But it is much better to provide _global_ gamma correction setting=
,
> > so you can then apply this gamma table even to 8bit palettized mode,
> > and even without app knowledge.
>
> That would require a new API, no?
Yes.
> Right now, apps use the colormap for this, and I'd hate to prevent them
> from doing so just because it's hard to get right.
There is no gamma API now. There is just an API to set RAMDAC, which
can be used as gamma in directcolor mode. But just in directcolor,
you cannot use it in palettized modes, although it is possible (as
in palettized mode RAMDAC is used in completely different way and it
cannot be used itself as gamma correction ramp), and also consoles will
not use this gamma - only X can do (if they do...). As I'm using X just
only for VMware, gamma on consoles is much more important to me.
Petr Vandrovec
van...@vc...
|
|
From: Michel <mic...@ii...> - 2001-11-24 02:42:24
|
On Fri, 2001-11-23 at 22:09, Petr Vandrovec wrote: > On 23 Nov 01 at 20:33, Michel D=E4nzer wrote: >=20 > > On Fri, 2001-11-23 at 20:36, Petr Vandrovec wrote: > > >=20 > > > > >Except that you can't change gamma, or am I on the wrong track her= e? > > >=20 > > > No. But it is much better to provide _global_ gamma correction settin= g, > > > so you can then apply this gamma table even to 8bit palettized mode, > > > and even without app knowledge. > >=20 > > That would require a new API, no? >=20 > Yes. > =20 > > Right now, apps use the colormap for this, and I'd hate to prevent them > > from doing so just because it's hard to get right. >=20 > There is no gamma API now. There is just an API to set RAMDAC, which > can be used as gamma in directcolor mode. But just in directcolor, > you cannot use it in palettized modes, although it is possible (as > in palettized mode RAMDAC is used in completely different way and it > cannot be used itself as gamma correction ramp), and also consoles will=20 > not use this gamma - only X can do (if they do...). We do, for both directcolor and pseudocolor. :) --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
|
From: Michel <mic...@ii...> - 2001-11-23 14:56:17
|
On Fri, 2001-11-23 at 16:34, Petr Vandrovec wrote: > On 23 Nov 01 at 14:44, Benjamin Herrenschmidt wrote: > > >> cmap for regno 32..63, we should ignore R and B and only use > > >> G, or did I miss something ? > > > > > >Yes, that's what I did for atyfb (experimental 565 patch which doesn't= work > > >very well yet :-( > >=20 > > Ok, well, it doesn't quite work yet but I suspect some X brokenness her= e. > > I'll got that fixed in both radeonfb and aty128fb this week-end hopeful= ly. >=20 > Export truecolor (with RAMDAC hardwired to 1:1) and be happy... X works > very well in that mode, Except that you can't change gamma, or am I on the wrong track here? --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
|
From: Benjamin H. <be...@ke...> - 2001-11-23 15:34:44
|
>Except that you can't change gamma, or am I on the wrong track here? Well, X fbdev driver can only do truecolor afaik. It does send a linear gamma table to the driver which is required anyway as the fbdev themselves can be directcolor, but for real directcolor support in X, we would probably need some other changes. So for 5:6:5, doing only truecolor (and hard coding a linear ramp in the chip's LUT) would do the trick for now. MOL can use gamma too but it doesn't do 5:6:5, so it's a non-issue. Ben. |
|
From: Michel <mic...@ii...> - 2001-11-23 18:59:28
|
On Fri, 2001-11-23 at 16:34, Benjamin Herrenschmidt wrote: > >Except that you can't change gamma, or am I on the wrong track here? >=20 > Well, X fbdev driver can only do truecolor afaik. It does send a > linear gamma table to the driver which is required anyway as the > fbdev themselves can be directcolor, but for real directcolor > support in X, we would probably need some other changes. So why does xgamma work with it? --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
|
From: Benjamin H. <be...@ke...> - 2001-11-24 12:12:16
|
>On Fri, 2001-11-23 at 16:34, Benjamin Herrenschmidt wrote: >> >Except that you can't change gamma, or am I on the wrong track here? >> >> Well, X fbdev driver can only do truecolor afaik. It does send a >> linear gamma table to the driver which is required anyway as the >> fbdev themselves can be directcolor, but for real directcolor >> support in X, we would probably need some other changes. > >So why does xgamma work with it? I don't know ;) I've looked at the source and it clearly states supporting only truecolor, but well, maybe xgamma is taking some weird path within the X server ? really no idea. BTW, I found my bug and now have 5:6:5 working properly. I'll implement 5:5:5 and backport some of my fixes to aty128fb as in it's current state, I beleive it's gamma setting doesn't work properly neither. You get a clear picture because of the hack that force a linear ramp when setting LUT entry 0, but that hack can be removed if the rest is done properly ;) Ben. |
|
From: Michel <mic...@ii...> - 2001-11-24 16:46:52
|
On Sat, 2001-11-24 at 13:11, Benjamin Herrenschmidt wrote: > >On Fri, 2001-11-23 at 16:34, Benjamin Herrenschmidt wrote: > >> >Except that you can't change gamma, or am I on the wrong track here? > >>=20 > >> Well, X fbdev driver can only do truecolor afaik. It does send a > >> linear gamma table to the driver which is required anyway as the > >> fbdev themselves can be directcolor, but for real directcolor > >> support in X, we would probably need some other changes. > > > >So why does xgamma work with it? >=20 > I don't know ;) I've looked at the source and it clearly states > supporting only truecolor, but well, maybe xgamma is taking some > weird path within the X server ? No, it uses the very general path of calling the driver's LoadPalette() function, fbdevHWLoadPalette() in this case, which uses FBIOPUTCMAP ioctl. The comment apparently only applies to X visuals, I must confess I don't really know the difference there either. :) > BTW, I found my bug and now have 5:6:5 working properly. I'll > implement 5:5:5 and backport some of my fixes to aty128fb as > in it's current state, I beleive it's gamma setting doesn't > work properly neither. You get a clear picture because of the > hack that force a linear ramp when setting LUT entry 0, but > that hack can be removed if the rest is done properly ;) So directcolor works correctly now? Great! --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X