Re: [PATCH] Add support for RENDER BGRA formats.
From: Adam Jackson a...@nwnk.net Date: Thu, 29 Oct 2009 18:33:20 -0400 To make the card work properly I still have to solve two issues: =20 1. It seems the ACNTRL register doesn't exist on the i128v2 chip. Writes to this register result in a PCI bus error. This was probably never noticed, since on standard PC hardware writes to non-existent registers silently fail. Do the docs contain some hints suggesting this is indeed the case? Kind of? It's the alpha blender setup register, and described as the Imagine 3 blending unit, which sort of implies it didn't exist on Imagine 2. I'm pretty sure Imagine 1 and 2 didn't even have a triangle unit, let alone an alpha blender. Enough evidence for me to assume that register should not be written to on the i128 and i128v2. I'll generate a diff to implement this. 2. Does the hardware by any chance map the VGA legacy I/O ports within one of its BARs? It might. BAR 5 is the I/O map, and it's 256 bytes. They're all defined right up to 0xBC, which smells a little suspicious since the VGA ports it claims to decode are 3C[0-5ACEF] and 3[BD][45A]. So while it doesn't _say_ the VGA ports are aliased there starting at 0xC0, I'd be utterly unsurprised. I guess I don't see how it matters though, you can already get to the colormap and mode, and you won't be using VGA fonts. (Unless you do VGA console even on non-x86 machines? That would be vile.) You're right of course. I already disabled the VGA font save/restore because that required mapping the legacy VGA memory area and on the Sun Blade 1000 that I stuck this card in, that area is in use by other devices. Still struggling a bit with how to map BAR 5 though. I have a hack to make things work, but I'll need to discuss the implications for the OpenBSD kernel and libpciaccess. Thanks, Mark ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Add support for RENDER BGRA formats.
Hello,
On Oct 31, 2009, at 11:17 AM, Mark Kettenis wrote:
Still struggling a bit with how to map BAR 5 though. I have a hack to
make things work, but I'll need to discuss the implications for the
OpenBSD kernel and libpciaccess.
Assuming that OpenBSD is still more or less NetBSD-ish here :
in whateverfb_mmap():
#ifdef PCI_MAGIC_IO_RANGE
/* allow mapping of IO space */
if ((offset = PCI_MAGIC_IO_RANGE)
(offset PCI_MAGIC_IO_RANGE + 0x1)) {
pa = bus_space_mmap(sc-sc_iot, offset - PCI_MAGIC_IO_RANGE,
0, prot, BUS_SPACE_MAP_LINEAR);
return pa;
}
#endif
IO space on sparc64 is memory mapped, you can just hand the IO tag
from pci_attach_args to bus_space_mmap(), pick a region that's safe
for your architecture and map it at that offset through the wsdisplay
file handle ( on sparc64 you'll probably want to pick something above
4GB. On macppc for example we use 0xf200 because that's
traditionally where the first PCI bridge puts its IO space. ). That
way you also automatically get the right IO space if you have more
than one. Yes, most PCI Suns implement considerably more than 64kB IO
space but the firmware tries to cram everything into the lower 64KB
anyway and you won't have many PCI devices with IO enabled either.
Or, to be more in line with libpciaccess, you can do that in
pci_mmap() so each /dev/pci* entry would return the right IO space.
have fun
Michael
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Add support for RENDER BGRA formats.
From: Adam Jackson a...@nwnk.net Date: Wed, 28 Oct 2009 10:39:29 -0400 (--) PCI: (0:0:3:0) 105d:2339:105d:000b Number 9 Imagine-128 II rev 2, Mem @ 0x0200/8388608, 0x0280/8388608, 0x0300/8388608, 0x0380/8388608, 0x0016/65536, I/O @ 0x0600/256, BIOS @ 0x/32768 BARs 0 and 1 are memory windows 0 and 1. We map MW0 for the framebuffer, but they're both just views onto the device's VRAM iirc, so you should be able to map either one. (--) I128(0): Memory Windows Registers (--) I128(0): MW0_CTRL 0x0100 (--) I128(0): AMV 0 MP 0 AMD 0 SEN 0 BSY 1 MDM 0 DEN 0 PSZ 0 Hm. Bits 18 through 16 (mask 0x0007) define the host data format for the memory window. If set, bit 16 swaps bits within each byte (whatever that means); bit 17 swaps bytes within each word; and bit 18 swaps words within each dword. Excellent! After initializing MW0_CTRL to 0x0006, it seems things just work. I'll prepare a proper diff to do that on big-endian machines. To make the card work properly I still have to solve two issues: 1. It seems the ACNTRL register doesn't exist on the i128v2 chip. Writes to this register result in a PCI bus error. This was probably never noticed, since on standard PC hardware writes to non-existent registers silently fail. Do the docs contain some hints suggesting this is indeed the case? 2. Does the hardware by any chance map the VGA legacy I/O ports within one of its BARs? Thanks, Mark ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Add support for RENDER BGRA formats.
On Thu, 2009-10-29 at 22:26 +0100, Mark Kettenis wrote: Excellent! After initializing MW0_CTRL to 0x0006, it seems things just work. I'll prepare a proper diff to do that on big-endian machines. Very cool. To make the card work properly I still have to solve two issues: 1. It seems the ACNTRL register doesn't exist on the i128v2 chip. Writes to this register result in a PCI bus error. This was probably never noticed, since on standard PC hardware writes to non-existent registers silently fail. Do the docs contain some hints suggesting this is indeed the case? Kind of? It's the alpha blender setup register, and described as the Imagine 3 blending unit, which sort of implies it didn't exist on Imagine 2. I'm pretty sure Imagine 1 and 2 didn't even have a triangle unit, let alone an alpha blender. 2. Does the hardware by any chance map the VGA legacy I/O ports within one of its BARs? It might. BAR 5 is the I/O map, and it's 256 bytes. They're all defined right up to 0xBC, which smells a little suspicious since the VGA ports it claims to decode are 3C[0-5ACEF] and 3[BD][45A]. So while it doesn't _say_ the VGA ports are aliased there starting at 0xC0, I'd be utterly unsurprised. I guess I don't see how it matters though, you can already get to the colormap and mode, and you won't be using VGA fonts. (Unless you do VGA console even on non-x86 machines? That would be vile.) - ajax signature.asc Description: This is a digitally signed message part ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Add support for RENDER BGRA formats.
On Tue, 2009-10-27 at 22:54 +0100, Mark Kettenis wrote: Hi Adam, See the log below. This is the Xorg version that's currently in the OpenBSD tree, with some modifications to the xf86-video-i128 driver such that it doesn't blow up. (--) PCI: (0:0:3:0) 105d:2339:105d:000b Number 9 Imagine-128 II rev 2, Mem @ 0x0200/8388608, 0x0280/8388608, 0x0300/8388608, 0x0380/8388608, 0x0016/65536, I/O @ 0x0600/256, BIOS @ 0x/32768 Technically the docs I have are for the two chips after this, but let's hope it didn't change too much. Also, very lame that the subvendor and subdevice IDs are generic Number Nine numbers and not Tech Source. BARs 0 and 1 are memory windows 0 and 1. We map MW0 for the framebuffer, but they're both just views onto the device's VRAM iirc, so you should be able to map either one. (--) I128(0): Memory Windows Registers (--) I128(0): MW0_CTRL 0x0100 (--) I128(0): AMV 0 MP 0 AMD 0 SEN 0 BSY 1 MDM 0 DEN 0 PSZ 0 Hm. Bits 18 through 16 (mask 0x0007) define the host data format for the memory window. If set, bit 16 swaps bits within each byte (whatever that means); bit 17 swaps bytes within each word; and bit 18 swaps words within each dword. (--) I128(0): M/V/DSE 0/0/0 (--) I128(0): MW0_AD0x0200 MW0_SZ0x000a MW0_PGE 0x (--) I128(0): MW0_ORG10 0x MW0_ORG14 0x MW0_MSRC 0x0000 (--) I128(0): MW0_WKEY 0xff00 MW0_KYDAT 0x MW0_MASK 0x (--) I128(0): MW1_CTRL 0x0100 (--) I128(0): AMV 0 MP 0 AMD 0 SEN 0 BSY 1 MDM 0 DEN 0 PSZ 0 (--) I128(0): M/V/DSE 0/0/0 (--) I128(0): MW1_AD0x0280 MW1_SZ0x MW1_PGE 0x000f001b (--) I128(0): MW1_ORG10 0x00fff000 MW1_ORG14 0x00fff000 MW1_MSRC 0x0000 (--) I128(0): MW1_WKEY 0xff00 MW1_KYDAT 0x MW1_MASK 0x MWn_SZ defines the logical size of the memory window, up to the size allocated by PCI. 0x0 is 4k, 0x1 is 8k, etc. up to 0xd for 32M. MWn_AD is the base address in host memory; MWn_ORG (ORG10 or ORG14, they appear to be aliased) defines the offset from that to the start of the memory window. So you can set up eg a 4k view onto anywhere in VRAM. MWn_PGE is mentioned as Memory Window 1 Page, and (to the extent it's documented) seems to be added to MWn_ORG to determine the offset within device memory. The rest is all to do with write masking, not terribly interesting. So, first thing to try would be to bang the swap bits in MW0_AD and see if you at least get different colors. (--) I128(0): CMD 0x00010c00 (--) I128(0): OPC 0x00 ROP 0x0c STYLE 0x01 CLP 0x0 PATRN 0x0 HDF 0 (--) I128(0): CMD_SHADE 0x00 (--) I128(0): CMD_OPC 0x00 (--) I128(0): CMD_ROP 0x0c (--) I128(0): CMD_STYLE 0x01 (--) I128(0): CMD_PATRN 0x00 (--) I128(0): CMD_CLP 0x00 (--) I128(0): CMD_HDF 0x00 HDF here is the same as the host data format bits in MWn_CTRL; lowest bit is bit swap, etc. Presumably only applies to data send through the command stream. - ajax signature.asc Description: This is a digitally signed message part ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Add support for RENDER BGRA formats.
From: Michael macal...@netbsd.org Date: Tue, 13 Oct 2009 15:22:55 -0400 Hello, Hi Michael, Sorry for the late reply; I just returned from a trip to India. ... which reminds me - I have an SBus card with ( among others ) an I128. I wrote an accelerated kernel driver for NetBSD using the X driver as reference, but the X driver doesn't support any mono-to- colour expansion. Does anyone have any I128 docs? Or does the chip simply not support colour expansion? I have never heard of any i128 PCI cards for Suns - do you have a model name or something? It's a Tech Source Raptor GFX-8M. Most PCI graphics chips have their (framebuffer) apertures split into a big endian and a little endian half, some have programmable byte twiddling, some have both. It would be a strange choice to pick one of the few chips that don't support big endian mode for a big endian machine. So, it's probably there somewhere. Yeah, that's what I figured as well. I didn't manage to find the right bits to do this though. Hopefully Adam can provide some hints though once I mail him the Xorg.log output. Also, it might give you a hint or two if you ran the OF console in 24 bit ( output-device=screen:r1152x900x76x24 works on at least some Sun graphics boards ) and then check if the address property agrees with the framebuffer BAR ( there should be an entry for it in /memory/ translations, 'address' is an OF virtual address after all ) Or, just check what's halfway up the framebuffer aperture. As far as I could determine, the OF console driver only supports 8-bit graphics. Anyway, thanks for the hints so far. Mark ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Add support for RENDER BGRA formats.
From: Adam Jackson a...@nwnk.net Date: Tue, 13 Oct 2009 14:51:26 -0400 On Fri, 2009-10-09 at 11:26 +0200, Mark Kettenis wrote: Hmm, right. The two hunks above were aimed towards my first approach f= or fixing radeon KMS on big endian machines, by making the root window visual BGRA. I've since abandoned that approach for a different one, s= o those hunks are not needed anymore and obviously even harmful. I'll submit a patch to revert them. =20 Well, it would be nice if a solution to support BGRA properly would be found. I have an i128-based card designed for Sun UltraSPARC workstation= s that can't do the byteswaps in hardware like the radeons can. Not that you're wrong (about proper BGRA support), but I think you may be wrong (about i128). I'd like to see an X log from that chip with Option Debug on in xorg.conf, I suspect CMD_HDF and MWn_CTRL will be interesting. Hi Adam, See the log below. This is the Xorg version that's currently in the OpenBSD tree, with some modifications to the xf86-video-i128 driver such that it doesn't blow up. Any hints would be appreciated. (--) Using wscons driver This is a pre-release version of the X server from The X.Org Foundation. It is not supported in any way. Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. Select the xorg product for bugs you find in this release. Before reporting bugs in pre-release versions please check the latest version in the X.Org Foundation git repository. See http://wiki.x.org/wiki/GitPage for git access instructions. X.Org X Server 1.6.3.901 (1.6.4 RC 1) Release Date: 2009-8-25 X Protocol Version 11, Revision 0 Build Operating System: OpenBSD 4.6 sparc64 Current Operating System: OpenBSD bruckner.sibelius.xs4all.nl 4.6 GENERIC.MP#3 sparc64 Build Date: 25 October 2009 05:24:38PM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Sun Oct 25 22:29:25 2009 (==) Using config file: /etc/X11/xorg.conf (==) No Layout section. Using the first Screen section. (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (==) No device specified for screen Screen0. Using the first device section listed. (**) | |--Device Card0 (**) Option NoTrapSignals true (==) Not automatically adding devices (==) Not automatically enabling devices (==) FontPath set to: /usr/X11R6/lib/X11/fonts/misc/, /usr/X11R6/lib/X11/fonts/TTF/, /usr/X11R6/lib/X11/fonts/OTF, /usr/X11R6/lib/X11/fonts/Type1/, /usr/X11R6/lib/X11/fonts/100dpi/, /usr/X11R6/lib/X11/fonts/75dpi/, built-ins (==) ModulePath set to /usr/X11R6/lib/modules (==) |--Input Device default pointer (==) |--Input Device default keyboard (==) No Layout section. Using the default mouse configuration. (==) No Layout section. Using the default keyboard configuration. (II) Loader magic: 0x1720 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 5.0 X.Org XInput driver : 4.0 X.Org Server Extension : 2.0 (II) Loader running on openbsd (!!) More than one possible primary device found (--) PCI: (0:0:1:0) 1002:5159:1002:0908 ATI Radeon VE rev 0, Mem @ 0x0800/134217728, 0x0013/65536, I/O @ 0x0500/256, BIOS @ 0x/131072 (--) PCI: (0:0:3:0) 105d:2339:105d:000b Number 9 Imagine-128 II rev 2, Mem @ 0x0200/8388608, 0x0280/8388608, 0x0300/8388608, 0x0380/8388608, 0x0016/65536, I/O @ 0x0600/256, BIOS @ 0x/32768 (II) System resource ranges: (II) LoadModule: extmod (II) Loading /usr/X11R6/lib/modules/extensions//libextmod.so (II) Module extmod: vendor=X.Org Foundation compiled for 1.6.3.901, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: dbe (II) Loading /usr/X11R6/lib/modules/extensions//libdbe.so (II) Module dbe: vendor=X.Org Foundation compiled for 1.6.3.901, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: glx (II) Loading /usr/X11R6/lib/modules/extensions//libglx.so (II) Module glx: vendor=X.Org Foundation compiled for 1.6.3.901, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (==) AIGLX enabled (II) Loading extension GLX (II) LoadModule: dri (II) Loading
Re: [PATCH] Add support for RENDER BGRA formats.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On Oct 27, 2009, at 5:54 PM, Mark Kettenis wrote: (--) PCI: (0:0:3:0) 105d:2339:105d:000b Number 9 Imagine-128 II rev 2, Mem @ 0x0200/8388608, 0x0280/8388608, 0x0300/8388608, 0x0380/8388608, 0x0016/65536, I/O @ 0x0600/256, BIOS @ 0x/32768 Four apertures, 8MB each? Very suspicious, wouldn't be the only chip that sticks different view on video memory into different BARs. I'd almost bet two of them are framebuffer views with different endianness. (--) I128(0): Linear framebuffer at 0x200 (--) I128(0): MMIO registers at 0x600 (--) I128(0): VideoRAM: 8192 kByte Try to map the other aperture at 0x280. have fun Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQEVAwUBSueW58pnzkX8Yg2nAQJC1Qf/cvltRKpkib03rWjyYEZcEJmmKpMYLJ60 GPxcWvtKFF/fVd7Kf/0Z++NUKFYTw5T3V8UaGGSyW0iUi3LwJxAFoePIxSltjbdK DRMpm1gMhyEbSCSSFrAKhpeBp9XP0peyBQw10dC0yruYBl+xxx/WMEU37/G9MqkQ mCxAon/UfGoYdkslPVa6OFGyRwUYtdP38yYhaT7LYsJzaKM5/fTkhlCH4zU6KZkk 99QP2WU+fw4pIz0o2Chz4czHFwvzK6FTkrmUCC2JnKItPK5CMJndeKu66M2YdmAZ mKKAkLExIq1/z7SbhADcdG5o0hor5QAoFDC+uyaka43mjXGdyinjLQ== =1P49 -END PGP SIGNATURE- ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Add support for RENDER BGRA formats.
On Tue, 2009-10-13 at 15:22 -0400, Michael wrote: On Oct 13, 2009, at 2:51 PM, Adam Jackson wrote: Not that you're wrong (about proper BGRA support), but I think you may be wrong (about i128). I'd like to see an X log from that chip with Option Debug on in xorg.conf, I suspect CMD_HDF and MWn_CTRL will be interesting. ... which reminds me - I have an SBus card with ( among others ) an I128. I wrote an accelerated kernel driver for NetBSD using the X driver as reference, but the X driver doesn't support any mono-to- colour expansion. Does anyone have any I128 docs? Or does the chip simply not support colour expansion? I have the docs for the T2R and T2R4, though the NDA politely asks that I not distribute them and I'm inclined to obey it. It does have stipple color expansion. The 3D engine also has a pile of palettized texture formats, listed of the form 1 bpt 0565, which I take to mean one bit of index into a palette of r5g6b5 colors. There is also a display list processor on the chip (not implemented in the X driver), which appears to have a mode for hardware acceleration of aliased glyphs, which for a console driver might be all you need. - ajax signature.asc Description: This is a digitally signed message part ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Add support for RENDER BGRA formats.
On Fri, 2009-10-09 at 11:26 +0200, Mark Kettenis wrote: Hmm, right. The two hunks above were aimed towards my first approach for fixing radeon KMS on big endian machines, by making the root window visual BGRA. I've since abandoned that approach for a different one, so those hunks are not needed anymore and obviously even harmful. I'll submit a patch to revert them. Well, it would be nice if a solution to support BGRA properly would be found. I have an i128-based card designed for Sun UltraSPARC workstations that can't do the byteswaps in hardware like the radeons can. Not that you're wrong (about proper BGRA support), but I think you may be wrong (about i128). I'd like to see an X log from that chip with Option Debug on in xorg.conf, I suspect CMD_HDF and MWn_CTRL will be interesting. - ajax signature.asc Description: This is a digitally signed message part ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Add support for RENDER BGRA formats.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On Oct 13, 2009, at 2:51 PM, Adam Jackson wrote: On Fri, 2009-10-09 at 11:26 +0200, Mark Kettenis wrote: Hmm, right. The two hunks above were aimed towards my first approach for fixing radeon KMS on big endian machines, by making the root window visual BGRA. I've since abandoned that approach for a different one, so those hunks are not needed anymore and obviously even harmful. I'll submit a patch to revert them. Well, it would be nice if a solution to support BGRA properly would be found. I have an i128-based card designed for Sun UltraSPARC workstations that can't do the byteswaps in hardware like the radeons can. Not that you're wrong (about proper BGRA support), but I think you may be wrong (about i128). I'd like to see an X log from that chip with Option Debug on in xorg.conf, I suspect CMD_HDF and MWn_CTRL will be interesting. ... which reminds me - I have an SBus card with ( among others ) an I128. I wrote an accelerated kernel driver for NetBSD using the X driver as reference, but the X driver doesn't support any mono-to- colour expansion. Does anyone have any I128 docs? Or does the chip simply not support colour expansion? I have never heard of any i128 PCI cards for Suns - do you have a model name or something? Most PCI graphics chips have their (framebuffer) apertures split into a big endian and a little endian half, some have programmable byte twiddling, some have both. It would be a strange choice to pick one of the few chips that don't support big endian mode for a big endian machine. So, it's probably there somewhere. Also, it might give you a hint or two if you ran the OF console in 24 bit ( output-device=screen:r1152x900x76x24 works on at least some Sun graphics boards ) and then check if the address property agrees with the framebuffer BAR ( there should be an entry for it in /memory/ translations, 'address' is an OF virtual address after all ) Or, just check what's halfway up the framebuffer aperture. have fun Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQEVAwUBStTTkMpnzkX8Yg2nAQIQKQgAkdzuuwxcFON4cPxYtMsePDIjzUXAkZhQ H55snPB5COunbiwvD2qgq9P4H+eFw3sS675wWKDVtlWht5aKRP+PpF5oZiSSVp8z b5LScg7CCGHGsD8LZXn6U8WmHAA/gdZGKU9EBpneJjQwzIzgFRqrVzYUt+3DyhMu nl6+8yeKtqq+shheai1zApglDtPwD9yiAMOQUObLsE+LiN4S1zlDZfy9pp5jsNcy FmQe99F/AaqiUdmV9O6iZ7nhgAY/rus4bR/UYmc7RnfJINZsNcYvHtCLJq9ynxGE kIHeWOUmB03D/rKykg1Y4q67oWizjXW/ouQRA+jTE7rOilPXKa9Bsw== =1Vw3 -END PGP SIGNATURE- ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Add support for RENDER BGRA formats.
On Thu, 2009-10-08 at 19:11 -0700, Aaron Plattner wrote:
On Sun, Aug 02, 2009 at 08:00:01AM -0700, wrote:
diff --git a/composite/compinit.c b/composite/compinit.c
index dfc3929..6159e4e 100644
--- a/composite/compinit.c
+++ b/composite/compinit.c
@@ -238,6 +238,7 @@ static CompAlternateVisual altVisuals[] = {
{ 24, PICT_r8g8b8 },
#endif
{ 32, PICT_a8r8g8b8 },
+{ 32, PICT_b8g8r8a8 },
};
static const int NUM_COMP_ALTERNATE_VISUALS = sizeof(altVisuals) /
@@ -272,7 +273,8 @@ compAddAlternateVisual(ScreenPtr pScreen, CompScreenPtr
cs,
return TRUE;
pPictFormat = PictureMatchFormat (pScreen, alt-depth, alt-format);
-if (!pPictFormat)
+if (!pPictFormat ||
+ pPictFormat-direct.red != pScreen-visuals[0].offsetRed)
return FALSE;
vid = xalloc(sizeof(VisualID));
This breaks Composite at depth 16:
[formatted for clarity]
(gdb) p pPictFormat-direct
$7 = {red = 16, redMask = 255, green = 8, greenMask = 255, blue = 0,
blueMask = 255, alpha = 24, alphaMask = 255}
(gdb) p *pPictFormat
$8 = {id = 180, format = 166024, type = 1 '\001', depth = 32 ' ',
direct = {red = 16, redMask = 255, green = 8, greenMask = 255,
blue = 0, blueMask = 255, alpha = 24,
alphaMask = 255},
index = {vid = 0, pColormap = 0x0, nvalues = 0, pValues = 0x0,
devPrivate = 0x0}}
(gdb) p pScreen-visuals[0]
$9 = {vid = 33, class = 4, bitsPerRGBValue = 8, ColormapEntries = 64,
nplanes = 16, redMask = 63488, greenMask = 2016, blueMask = 31,
offsetRed = 11, offsetGreen = 5, offsetBlue = 0}
Since pPictFormat-direct.red is 16 and pScreen-visuals[0].offsetRed is 11,
it
returns FALSE and compScreenInit bails out.
Hmm, right. The two hunks above were aimed towards my first approach for
fixing radeon KMS on big endian machines, by making the root window
visual BGRA. I've since abandoned that approach for a different one, so
those hunks are not needed anymore and obviously even harmful. I'll
submit a patch to revert them.
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Add support for RENDER BGRA formats.
On Thu, 2009-10-08 at 19:11 -0700, Aaron Plattner wrote:
On Sun, Aug 02, 2009 at 08:00:01AM -0700, wrote:
diff --git a/composite/compinit.c b/composite/compinit.c
index dfc3929..6159e4e 100644
--- a/composite/compinit.c
+++ b/composite/compinit.c
@@ -238,6 +238,7 @@ static CompAlternateVisual altVisuals[] = {
{24, PICT_r8g8b8 },
#endif
{32, PICT_a8r8g8b8 },
+{32, PICT_b8g8r8a8 },
};
static const int NUM_COMP_ALTERNATE_VISUALS = sizeof(altVisuals) /
@@ -272,7 +273,8 @@ compAddAlternateVisual(ScreenPtr pScreen,
CompScreenPtr cs,
return TRUE;
pPictFormat = PictureMatchFormat (pScreen, alt-depth,
alt-format);
-if (!pPictFormat)
+if (!pPictFormat ||
+ pPictFormat-direct.red != pScreen-visuals[0].offsetRed)
return FALSE;
vid = xalloc(sizeof(VisualID));
This breaks Composite at depth 16:
[formatted for clarity]
(gdb) p pPictFormat-direct
$7 = {red = 16, redMask = 255, green = 8, greenMask = 255, blue = 0,
blueMask = 255, alpha = 24, alphaMask = 255}
(gdb) p *pPictFormat
$8 = {id = 180, format = 166024, type = 1 '\001', depth = 32 ' ',
direct = {red = 16, redMask = 255, green = 8, greenMask = 255,
blue = 0, blueMask = 255, alpha = 24,
alphaMask = 255},
index = {vid = 0, pColormap = 0x0, nvalues = 0, pValues = 0x0,
devPrivate = 0x0}}
(gdb) p pScreen-visuals[0]
$9 = {vid = 33, class = 4, bitsPerRGBValue = 8, ColormapEntries = 64,
nplanes = 16, redMask = 63488, greenMask = 2016, blueMask = 31,
offsetRed = 11, offsetGreen = 5, offsetBlue = 0}
Since pPictFormat-direct.red is 16 and pScreen-visuals[0].offsetRed is
11, it
returns FALSE and compScreenInit bails out.
Hmm, right. The two hunks above were aimed towards my first approach for
fixing radeon KMS on big endian machines, by making the root window
visual BGRA. I've since abandoned that approach for a different one, so
those hunks are not needed anymore and obviously even harmful. I'll
submit a patch to revert them.
Well, it would be nice if a solution to support BGRA properly would be
found. I have an i128-based card designed for Sun UltraSPARC workstations
that can't do the byteswaps in hardware like the radeons can.
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Add support for RENDER BGRA formats.
On Sun, Aug 02, 2009 at 08:00:01AM -0700, wrote:
From: Michel Dänzer daen...@vmware.com
---
composite/compinit.c |4 +++-
exa/exa_render.c | 30 +-
fb/fbpict.h |2 ++
hw/xfree86/xaa/xaaPict.c | 20
render/picture.c | 36 +++-
render/picture.h |3 +++
6 files changed, 84 insertions(+), 11 deletions(-)
diff --git a/composite/compinit.c b/composite/compinit.c
index dfc3929..6159e4e 100644
--- a/composite/compinit.c
+++ b/composite/compinit.c
@@ -238,6 +238,7 @@ static CompAlternateVisual altVisuals[] = {
{24, PICT_r8g8b8 },
#endif
{32, PICT_a8r8g8b8 },
+{32, PICT_b8g8r8a8 },
};
static const int NUM_COMP_ALTERNATE_VISUALS = sizeof(altVisuals) /
@@ -272,7 +273,8 @@ compAddAlternateVisual(ScreenPtr pScreen, CompScreenPtr
cs,
return TRUE;
pPictFormat = PictureMatchFormat (pScreen, alt-depth, alt-format);
-if (!pPictFormat)
+if (!pPictFormat ||
+ pPictFormat-direct.red != pScreen-visuals[0].offsetRed)
return FALSE;
vid = xalloc(sizeof(VisualID));
This breaks Composite at depth 16:
[formatted for clarity]
(gdb) p pPictFormat-direct
$7 = {red = 16, redMask = 255, green = 8, greenMask = 255, blue = 0,
blueMask = 255, alpha = 24, alphaMask = 255}
(gdb) p *pPictFormat
$8 = {id = 180, format = 166024, type = 1 '\001', depth = 32 ' ',
direct = {red = 16, redMask = 255, green = 8, greenMask = 255,
blue = 0, blueMask = 255, alpha = 24,
alphaMask = 255},
index = {vid = 0, pColormap = 0x0, nvalues = 0, pValues = 0x0,
devPrivate = 0x0}}
(gdb) p pScreen-visuals[0]
$9 = {vid = 33, class = 4, bitsPerRGBValue = 8, ColormapEntries = 64,
nplanes = 16, redMask = 63488, greenMask = 2016, blueMask = 31,
offsetRed = 11, offsetGreen = 5, offsetBlue = 0}
Since pPictFormat-direct.red is 16 and pScreen-visuals[0].offsetRed is 11, it
returns FALSE and compScreenInit bails out.
-- Aaron
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
