On Tue, Oct 22, 2002 at 01:25:40AM +0200, Olivier Chapuis wrote:
>On Mon, Oct 21, 2002 at 04:54:26PM -0400, David Dawes wrote:
>> On Fri, Oct 18, 2002 at 02:12:30PM -0700, Mark Vojkovich wrote:
>> >On Fri, 18 Oct 2002, Wojciech Kasprzak wrote:
>> >
>> >> The application used to work under Linux 7.1. Has something
>> >> changed in 7.3 with regard to colormap cell (pre?)allocations
>> >> or locking it by some X clients? How can I find which clinets
>> >> are allocating all the colors? On my laptop (Linux 7.1) I was
>> >> able to test-allocate around 130 colors before running out of
>> >> resources...
>> >>
>> >
>> > Yes, we should put this in a faq or something. The render
>> >extension preallocates a large chunk of the default colormap
>> >in depth 8 in 4.2.0 (maybe in 4.2.1 too, I don't know). This
>> >behavior was removed in XFree86 CVS.
>> >
>> > You mentioned you were using the "nvidia" driver. If so,
>> >you can add the option "NoRenderExtension" to the XF86Config file
>> >to disable the render extension. This option is only supported
>> >by the "nvidia" driver. For other drivers you'll need to use
>> >XFree86 CVS (or maybe 4.2.1 if the fix made it in there).
>>
>> Since this bites a lot of people wanting to use legacy apps (probably
>> one of the most common reasons for using depth 8 anyway), I think we
>> need an option to allow this preallocation of colormap entries to be
>> turned off. At least then people can choose what they need most --
>> Render support at 8-bit, or an untouched colormap.
>>
>
>I just write a patch which does this today. I think also that it is a
>good idea to have an option which allows to control the colours that
>Render preallocate.
>
>I've added command lines / XF86Config options:
>
> -no-render-extension / NoRenderExtension
> -render-extension (for cancelling a NoRenderExtension option in
> XF86Config)
> -render-color-limit (int)cl / RenderColorLimit (int)cl
>
>I do not know if the naming is good.
>
>About the color limit arg cl it is a simple integer which replaces the
>default "num" of render/miindex.c which is equal to map_entries/(3 or
>2). It is maybe better to allow only a few integers 0,1, ..., 6:
>
>cl GreyScale PseudoColor
>--------------------------------------------
>0 : default default
>1 : 8 grey 8 grey
>2 : 16 grey 2x2x2 cc + 4 grey (or 8?)
>3 : 32 grey 3x3x3 cc + 8 grey (or 16?)
>4 : 64 grey 4x4x4 cc + 16 grey (or 23?)
>5 : 128 grey 5x5x5 cc + 16 grey (or 32?)
>6 : 256 grey 6x6x6 cc + 32 grey (or 30)
>
>
>It is the first time I really read the code under Xserver so I am not
>sure I do the right things. Here what I do:
>
>I've added two new members to "the" ScreenRec structure: disableRender
>and renderColorLimit. In common/xf86Helper I've added a new function
>xf86SetRenderOptions(ScreenPtr) which setups these two members
>accordingly to the cmd line or config file option. Then, the driver
>should call xf86SetRenderOptions before it calls fbPictureInit.
Is this implemented in a way that allows render to be enabled/disabled
on a per-screen basis? If so, it's probably OK to put that stuff into
the ScreenRec.
>Render is disabled in fbPictureInit: if disableRender, then
>fbPictureInit do nothing and return TRUE. It seems to me that this is
>ok: the driver should works as if it has no Render support (?). At
>least this works with the vesa and neomagic drivers.
Your description sounds reasonable to me.
>One thing I am not really happy with is that we should add one
>line per driver. Maybe the two new members should be set in
>common/xf86Config.c (xf86HandleConfigFile). On the other hands,
>maybe some drivers will do not like to be compiled with RENDER,
>but run with renderDisabled?
The way you're doing it the same as the way we currently handle
enabling/disabling backing store on a per-screen basis.
If it was a global option (like the "Xinerama" option) that affects all
screens, it would be appropriate to handle it in common/xf86Config.c
along with other ServerFlags options.
As a per-screen option, the full set of collected options that will be
applied to a screen isn't known in common/xf86Config.c. For example,
it would be reasonable to have something like:
Section "Screen"
Identifier "X"
Device "ABC Device"
Monitor "XYZ Monitor"
Subsection "Display"
Depth 8
Option "NoRenderExtension"
EndSubsection
Subsection "Display"
Depth 24
EndSubsection
EndSection
It isn't known until inside the driver's PreInit() function, where the
screen's root depth is determined, which of the "Display" SubSection's
will be used.
>Or you interested? Some comments?
I'd be interested to see the patch.
I don't know if anyone else has comments. Keith? Mark?
David
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
