On Sat, Mar 06, 2004 at 03:28:09AM +0100, Thomas Winischhofer wrote:
>Mark Vojkovich wrote:
>> On Fri, 5 Mar 2004, Thomas Winischhofer wrote:
>>
>>
>>>David Dawes wrote:
>>>
>>>>On Fri, Mar 05, 2004 at 01:38:06AM +0100, Thomas Winischhofer wrote:
>>>>
>>>>>What exactly does a video driver have to be able to do if the
>>>>>SupportConvert32to24 flag is set at calling xf86SetDepthBpp, provided
>>>>>the hardware supports, for instance, 24bpp (framebuffer depth) only?
>>>>
>>>>
>>>>It has to use a framebuffer layer that can do this conversion. fb
>>>>can, as can xf24_32bpp (if your driver uses cfb). The s3virge
>>>>driver is an example that can still be run with the xf24_32bpp
>>>>method, and it does the following to figure out what to load:
>>>>
>>>> case 24:
>>>> if (pix24bpp == 24) {
>>>> mod = "cfb24";
>>>> reqSym = "cfb24ScreenInit";
>>>> } else {
>>>> mod = "xf24_32bpp";
>>>> reqSym = "cfb24_32ScreenInit";
>>>> }
>>>>
>>>>Most drivers use fb these days, and it has support for this built-in,
>>>>and enabled automatically.
>>>
>>>So it is save just to set these, I assume (since my driver uses fb).
>>>(Just wondered why the *driver* and not the layer taking care of this
>>>has to (not) set these.)
>>
>>
>> Do you mean the flag? The layer above does not know whether
>> or not the driver/HW supports a 24 bpp framebuffer. The "nv" driver,
>> for example, does not.
>
>Whether or not the hardware does support 24bpp (framebuffer depth, not
>talking about color depth) should be determined by setting/clearing
>SupportXXbpp. Why the *driver* needs to set "SupportConvert...." is
>beyond me. My understanding is that the respective fb layer should take
>care of this (if supported) based on SupportXXbpp (especially since the
>*driver* does not need to care about this, as David told me. It just
>depends on what layer I choose for above the driver level).
There are two things here. One, the *fb module isn't loaded at
the point where this information is required. Two, only the driver
knows which (if any) *fb layer(s) it will use. It is the driver's
responsibility to characterise what it can do. The cost, as
currently implemented, of this model is a reasonable amount of
boiler plate in drivers.
>But anyway, my question was answered. Seems to be save to set this
>obsure SupportConvert32to24 flag if using the generic fb layer.
Yes. However, we didn't have today's generic fb layer when this
stuff was first written. Fortunately for its ease of adoption,
the driver model didn't mandate a specific *fb layer or hard code
its expected characteristics :-)
Looking at the xf86SetDepthBpp() code, there appears to be another
wrinkle, because these flags get cleared for
(BITMAP_SCANLINE_UNIT == 64) platforms:
#if BITMAP_SCANLINE_UNIT == 64
/*
* For platforms with 64-bit scanlines, modify the driver's depth24flags
* to remove preferences for packed 24bpp modes, which are not currently
* supported on these platforms.
*/
depth24flags &= ~(SupportConvert32to24 | SupportConvert32to24 |
PreferConvert24to32 | PreferConvert32to24);
#endif
This has been there for a long time (before we had fb). I'm not
sure if it is still valid or not. Anyone with 64-bit scanline platforms
care to comment?
David
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
