Re: SupportConvertXXtoXX
On Fri, 5 Mar 2004, Thomas Winischhofer wrote: > Mark Vojkovich wrote: > > On Fri, 5 Mar 2004, 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's expected to support a 24bpp framebuffer. > > So far, so good. > > > Depth 24/32 bpp will get translated to depth 24/24 bpp. > > By whom (ie what layer)? Does the video driver in any way need to take > care of this? Not that I can remember. XAA and fb should take care of it. This used to be the default mode for the MGA driver, but 3D wasn't usable in 24 bpp so I think the DRI folks changed the default. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: SupportConvertXXtoXX
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.
>(SupportConvert24to32 vice versa)
This was never implemented, although there is nothing from stopping
a driver from doing so. Clients usually prefer 24-bit pixmaps with
the pixels padded to 32 bits, so there isn't really much of a need
for going the other way (pixmap bpp 24 -> hardware bpp 32).
David
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: SupportConvertXXtoXX
Mark Vojkovich wrote: On Fri, 5 Mar 2004, 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's expected to support a 24bpp framebuffer. So far, so good. > Depth 24/32 bpp will get translated to depth 24/24 bpp. By whom (ie what layer)? Does the video driver in any way need to take care of this? Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: SupportConvertXXtoXX
On Fri, 5 Mar 2004, 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's expected to support a 24bpp framebuffer. Depth 24/32 bpp will get translated to depth 24/24 bpp. > (SupportConvert24to32 vice versa) I don't think that's actually implemented. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
SupportConvertXXtoXX
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? (SupportConvert24to32 vice versa) Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Multimon failure with two identical PCI cards and driver.
THE PROBLEM: When running a dual head configuration, the primary head is not drawn, while the secondary head works correctly. Failing system notes and observations: 1. The video hardware does not have a BIOS or VGA core of any kind. 2. The video driver functions properly when using a single head configuration on either head. 3. The video driver and hardware are 8 bit only, one 1200x1600 mode, with no accelerations. 4. The primary head is lit and will respond to framebuffer writes after memory mapping in the driver and the written data remains unmolested through the entire XServer session. 5. The cursor appears to move into the drawing area of the primary head, but is not visible there. 6. Running Xinerama has no effect on the failure to draw on the primary head. 7. Multimon function is correct when configured to run only one head with any DIFFERENT PCI/AGP card. 8. There are no global variables in the driver that are not required by display drivers. 9. OS is Red Hat 9.0... 2.4.x kernel. Has anyone seen this before and how was it fixed? ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: ibm526 ramdac support for s3 968
Please create a bug on xfree86 bugzilla and add this patch to it.
http://bugs.xfree86.org/
Alex
--- John Hay <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have two old Diamond Stealth 64 VRAM cards that use the IBM 526
> RAMDAC.
> This patch makes XFree86 work on it again. The relevant pieces of the
> log
> file look like this:
>
> (II) s3(0): VESA VBE OEM: Diamond Stealth 64 Video VRAM
> (--) s3(0): Attached RAMDAC is IBM 526
> (--) s3(0): MCLK 74.286 MHz
>
> John
> --
> John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
>
>
> diff -ur org/xc/programs/Xserver/hw/xfree86/drivers/s3/s3_driver.c
> xc/programs/Xserver/hw/xfree86/drivers/s3/s3_driver.c
> --- org/xc/programs/Xserver/hw/xfree86/drivers/s3/s3_driver.c Thu Sep
> 25 13:05:02 2003
> +++ xc/programs/Xserver/hw/xfree86/drivers/s3/s3_driver.c Sat Jan 24
> 16:50:37 2004
> @@ -171,6 +171,8 @@
> RamDacSupportedInfoRec S3IBMRamdacs[] = {
> { IBM524_RAMDAC },
> { IBM524A_RAMDAC },
> + { IBM526_RAMDAC },
> + { IBM526DB_RAMDAC },
> { -1 }
> };
>
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel
__
Do you Yahoo!?
Yahoo! Search - Find what youre looking for faster
http://search.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
ibm526 ramdac support for s3 968
Hi,
I have two old Diamond Stealth 64 VRAM cards that use the IBM 526 RAMDAC.
This patch makes XFree86 work on it again. The relevant pieces of the log
file look like this:
(II) s3(0): VESA VBE OEM: Diamond Stealth 64 Video VRAM
(--) s3(0): Attached RAMDAC is IBM 526
(--) s3(0): MCLK 74.286 MHz
John
--
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
diff -ur org/xc/programs/Xserver/hw/xfree86/drivers/s3/s3_driver.c
xc/programs/Xserver/hw/xfree86/drivers/s3/s3_driver.c
--- org/xc/programs/Xserver/hw/xfree86/drivers/s3/s3_driver.c Thu Sep 25 13:05:02
2003
+++ xc/programs/Xserver/hw/xfree86/drivers/s3/s3_driver.c Sat Jan 24 16:50:37
2004
@@ -171,6 +171,8 @@
RamDacSupportedInfoRec S3IBMRamdacs[] = {
{ IBM524_RAMDAC },
{ IBM524A_RAMDAC },
+ { IBM526_RAMDAC },
+ { IBM526DB_RAMDAC },
{ -1 }
};
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: XAA2 namespace?
On Tue, Mar 02, 2004 at 12:06:53PM -0800, Mark Vojkovich wrote: >On Tue, 2 Mar 2004, David Dawes wrote: > >> On Tue, Mar 02, 2004 at 10:57:04AM -0800, Mark Vojkovich wrote: >> >On Tue, 2 Mar 2004, [ISO-8859-1] Frank Gießler wrote: >> > >> >> Mark Vojkovich wrote: >> >> >We don't care what the filenames are except for the header files. >> >> > The only reason why we care about header files is that a driver >> >> > might include support for both and may need both include paths. >> >> > There's only one exported header file. I'd like to name it Xaa.h >> >> > to match the namespace. Is it really going to be relevant on >> >> > case-unaware systems? Which ones are those BTW? >> >> >> >> There is already xaa.h. Having Xaa.h included at the same time is a >> >> no-op for OS/2, for which there are already binaries for 4.4.0 available >> >> (I would therefore consider this a well supported platform). >> >> >> > >> > Well, then I guess I could call the header file xaa2.h >> >> Not to be too picky, but won't this be the third version of XAA, not the >> second? > > Yes, it's actually the third. Harm's was the first. I think we >even advertised XFree86 4.x's XAA as 2.0. Would you prefer xaa3.h ? I was just being picky. The main thing is that the file names and the module name don't clash on case-insensitive systems. David ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Halted progress on XFree86 ffb driver for Solaris/SPARC
--- "Mike A. Harris" <[EMAIL PROTECTED]> wrote: > On Wed, 3 Mar 2004, Matt Prazak wrote: > > >driver to themselves. This is fair enough, but custom kernel drivers are a bit > >over my head at this point in time (it would require porting a Linux-based ffb > >driver to the Solaris kernel driver architecture) > > Which would also violate the GPL unless you got the author's to > relicense it. There are BSD ffb drivers, too, in OpenBSD and FreeBSD (and probably NetBSD). The main point is that, as far as I can tell, a new Solaris kernel driver would be required for XFree86 to work with the Creator graphics cards. Licensing is also the main reason I chose not to reverse-engineer Sun's driver to get what I needed, because Sun's Solaris 9 Binary License Agreement is very clear about reverse-engineering. Matt __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: __AMD64__ or __amd64__ ?
On Thu, 4 Mar 2004, Mike A. Harris wrote: > There is really no need to be a troll when someone is trying to ;-) > provide useful helpful advice. If you do not know what > __arch64__ is, then by all means read ISO C99 and/or the gcc > or other documentation. "or other" appears to be the accurate portion of this. For example: http://gcc.gnu.org/ml/gcc-patches/2002-05/msg01394.html -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: __AMD64__ or __amd64__ ?
MH> If you do not know what __arch64__ is, then by all means read ISO MH> C99 and/or the gcc or other documentation. There is no mention of __arch64__ in the 18 January 1999 committee draft of C99, in the gcc-3.2 manual or in the CPP-3.2 manual. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: __AMD64__ or __amd64__ ?
On Thu, 4 Mar 2004, Juliusz Chroboczek wrote: >MH> If the test is just to determine wether or not a 64bit >MH> architecture is being built for, then __arch64__ is a better >MH> test. > >What is a 64 bit architecture? > >Is it about address bus size? (The MC68020 is a 34-bit architecture?) >About data bus size? About register size? (The MC68040 is an 80-bit >architecture?) About the size that instructions operate on? (The P6 >is a 128-bit architecture?) > >LP64 has a well-defined technical meaning (it's about the size of data >types exported by the C compiler.) I have no idea what ``64-bit >architecture'' may mean. There is really no need to be a troll when someone is trying to provide useful helpful advice. If you do not know what __arch64__ is, then by all means read ISO C99 and/or the gcc or other documentation. This mailing list is getting more sickening and useless every day with useless commentary like yours in response to a helpful message. I guess when the ship sinks however, the whole thing goes down, not just part of it. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: __AMD64__ or __amd64__ ?
MH> If the test is just to determine wether or not a 64bit MH> architecture is being built for, then __arch64__ is a better MH> test. What is a 64 bit architecture? Is it about address bus size? (The MC68020 is a 34-bit architecture?) About data bus size? About register size? (The MC68040 is an 80-bit architecture?) About the size that instructions operate on? (The P6 is a 128-bit architecture?) LP64 has a well-defined technical meaning (it's about the size of data types exported by the C compiler.) I have no idea what ``64-bit architecture'' may mean. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
