On Fri, Mar 05, 2004 at 09:36:19PM -0800, Mark Vojkovich wrote:
>On Fri, 5 Mar 2004, David Dawes wrote:
>
>> 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?
>>
>
> I thought we stopped using 64 bit scanlines altogether.
Hmm, yes it looks that way. I guess we can remove that then, and the
related code in xf86Init.c.
David
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
