Re: Building XFree 4.3.99.9
On Sat, 26 Jul 2003, Andrew Bevitt wrote: > Ive just been trying to build the latest develoment snapshot (4.3.99.9) > and have come across an error in the compiling. > xf86DDC.c: In function `DDCRead_DDC2': > xf86DDC.c:336: error: invalid lvalue in assignment > make[6]: *** [xf86DDC.o] Error 1 > make[6]: Leaving directory > `/var/tmp/portage/xfree-4.3.99.9/work/xc/programs/Xserver/hw/xfree86/ddc' This has already been fixed. Update from CVS. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Building XFree 4.3.99.9
> Pipe it into less and search for I2CDevPtr - see if it is defined weirdly > as a typedef. All I can see is typedef struct _I2CDevRec *I2CDevPtr; Which looks ok to me, even searching back through the _I2CDevRec listings is looking ok aswell. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Building XFree 4.3.99.9
> xf86I2CFindDev is defined in > xc/programs/Xserver/hw/xfree86/i2c/xf86i2c.h > which is included in > xc/programs/Xserver/hw/xfree86/ddc/xf86DDC.h > > The -E output should help determine why > xc/programs/Xserver/hw/xfree86/ddc/xf86DDC.c > is not seening this definition. It does see it. If it didnt not I would be getting unknown declaration errors, not the error that im actually getting which is xf86DDC.c: In function `DDCRead_DDC2': xf86DDC.c:336: error: invalid lvalue in assignment make[6]: *** [xf86DDC.o] Error 1 make[6]: Leaving directory `/var/tmp/portage/xfree-4.3.99.9/work/xc/programs/Xserver/hw/xfree86/ddc' I read the -E output and it does have everything included properly. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Building XFree 4.3.99.9
On Sat, 26 Jul 2003, Andrew Bevitt wrote: > > You can try to substitute cc -c by cc -E and look at the produced code. > > That only prints out a whole load of code and includes to the terminal. Yes :) It runs the preprocessor on the source and nothing else. > From what I can see its no different to the code in the files and doesnt > really give me any clues. Pipe it into less and search for I2CDevPtr - see if it is defined weirdly as a typedef. It might be a #define instead - you'll be able to see that inside the DDCRead_DDC2() function. You search inside less with the '/' command: Type /I2CDevPtr, for example. Use 'n' and 'p' to skip between the matches. -Peter ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Building XFree 4.3.99.9
On Sat, 26 Jul 2003, Andrew Bevitt wrote: > > You can try to substitute cc -c by cc -E and look at the produced code. > > That only prints out a whole load of code and includes to the terminal. > >From what I can see its no different to the code in the files and doesnt > really give me any clues. xf86I2CFindDev is defined in xc/programs/Xserver/hw/xfree86/i2c/xf86i2c.h which is included in xc/programs/Xserver/hw/xfree86/ddc/xf86DDC.h The -E output should help determine why xc/programs/Xserver/hw/xfree86/ddc/xf86DDC.c is not seening this definition. -- Andrew C Aitchison ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Building XFree 4.3.99.9
> You can try to substitute cc -c by cc -E and look at the produced code. That only prints out a whole load of code and includes to the terminal. >From what I can see its no different to the code in the files and doesnt really give me any clues. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Radeon 9000 If (RV250), Mac G4 (Wintunnel) problems withXFree86
On Tue, 2003-07-15 at 16:29, Benjamin Herrenschmidt wrote:
> > > >>> latest CVS build (by myself) as of yesterday (4.3.99...)
> > > >>
>
> When did you try exactly ? I've seen more fixes for TMDS getting
> in the CVS recently. I'm not sure what's up here, definitely not
> something the doc explains. I suspect it's the path of pixel
> data from the framebuffer to the TMDS transmitter that has an
> endian problem, I fail to see why SURFACE_CNTL thing would fail,
> or maybe it's a problem related to surface translation getting in
> our way ?
I suspected that as well. If current CVS still doesn't work (works
perfectly here with an external CRT on an M9 in a TiBook IV), please try
this patch and post the RADEONInitCommonRegisters output.
Or maybe it's something like http://bugs.xfree86.org/show_bug.cgi?id=521
?
--
Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer
Index: programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c
===
RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c,v
retrieving revision 1.103
diff -p -u -r1.103 radeon_driver.c
--- programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 24 Jul 2003 13:50:23 - 1.103
+++ programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 26 Jul 2003 11:02:28 -
@@ -5341,8 +5341,10 @@ static void RADEONRestore(ScrnInfoPtr pS
}
/* Define common registers for requested video mode */
-static void RADEONInitCommonRegisters(RADEONSavePtr save, RADEONInfoPtr info)
+static void RADEONInitCommonRegisters(ScrnInfoPtr pScrn, RADEONSavePtr save)
{
+RADEONInfoPtr info = RADEONPTR(pScrn);
+
save->ovr_clr= 0;
save->ovr_wid_left_right = 0;
save->ovr_wid_top_bottom = 0;
@@ -5360,6 +5362,49 @@ static void RADEONInitCommonRegisters(RA
*/
if (save->bus_cntl & (RADEON_BUS_READ_BURST))
save->bus_cntl |= RADEON_BUS_RD_DISCARD_EN;
+
+save->surface_cntl = 0;
+
+#if X_BYTE_ORDER == X_BIG_ENDIAN
+switch (pScrn->bitsPerPixel) {
+case 16:
+ save->surface_cntl |= RADEON_NONSURF_AP0_SWP_16BPP | RADEON_NONSURF_AP1_SWP_16BPP;
+ break;
+
+case 32:
+ save->surface_cntl |= RADEON_NONSURF_AP0_SWP_32BPP | RADEON_NONSURF_AP1_SWP_32BPP;
+ break;
+}
+
+{
+ unsigned char *RADEONMMIO = info->MMIO;
+
+ ErrorF("%s: Surface 0: info=0x%x, range=0x%x-0x%x\n", __FUNCTION__,
+ INREG(RADEON_SURFACE0_INFO), INREG(RADEON_SURFACE0_LOWER_BOUND),
+ INREG(RADEON_SURFACE0_UPPER_BOUND));
+ ErrorF("%s: Surface 1: info=0x%x, range=0x%x-0x%x\n", __FUNCTION__,
+ INREG(RADEON_SURFACE1_INFO), INREG(RADEON_SURFACE1_LOWER_BOUND),
+ INREG(RADEON_SURFACE1_UPPER_BOUND));
+ ErrorF("%s: Surface 2: info=0x%x, range=0x%x-0x%x\n", __FUNCTION__,
+ INREG(RADEON_SURFACE2_INFO), INREG(RADEON_SURFACE2_LOWER_BOUND),
+ INREG(RADEON_SURFACE2_UPPER_BOUND));
+ ErrorF("%s: Surface 3: info=0x%x, range=0x%x-0x%x\n", __FUNCTION__,
+ INREG(RADEON_SURFACE3_INFO), INREG(RADEON_SURFACE3_LOWER_BOUND),
+ INREG(RADEON_SURFACE3_UPPER_BOUND));
+ ErrorF("%s: Surface 4: info=0x%x, range=0x%x-0x%x\n", __FUNCTION__,
+ INREG(RADEON_SURFACE4_INFO), INREG(RADEON_SURFACE4_LOWER_BOUND),
+ INREG(RADEON_SURFACE4_UPPER_BOUND));
+ ErrorF("%s: Surface 5: info=0x%x, range=0x%x-0x%x\n", __FUNCTION__,
+ INREG(RADEON_SURFACE5_INFO), INREG(RADEON_SURFACE5_LOWER_BOUND),
+ INREG(RADEON_SURFACE5_UPPER_BOUND));
+ ErrorF("%s: Surface 6: info=0x%x, range=0x%x-0x%x\n", __FUNCTION__,
+ INREG(RADEON_SURFACE6_INFO), INREG(RADEON_SURFACE6_LOWER_BOUND),
+ INREG(RADEON_SURFACE6_UPPER_BOUND));
+ ErrorF("%s: Surface 7: info=0x%x, range=0x%x-0x%x\n", __FUNCTION__,
+ INREG(RADEON_SURFACE7_INFO), INREG(RADEON_SURFACE7_LOWER_BOUND),
+ INREG(RADEON_SURFACE7_UPPER_BOUND));
+}
+#endif
}
/* Define CRTC registers for requested video mode */
@@ -5487,22 +5532,9 @@ static Bool RADEONInitCrtcRegisters(Scrn
(pScrn->bitsPerPixel * 8));
save->crtc_pitch |= save->crtc_pitch << 16;
-save->surface_cntl = 0;
save->disp_merge_cntl = info->SavedReg.disp_merge_cntl;
save->disp_merge_cntl &= ~RADEON_DISP_RGB_OFFSET_EN;
-#if X_BYTE_ORDER == X_BIG_ENDIAN
-switch (pScrn->bitsPerPixel) {
-case 16:
- save->surface_cntl |= RADEON_NONSURF_AP0_SWP_16BPP;
- break;
-
-case 32:
- save->surface_cntl |= RADEON_NONSURF_AP0_SWP_32BPP;
- break;
-}
-#endif
-
RADEONTRACE(("Pitch = %d bytes (virtualX = %d, displayWidth = %d)\n",
save->crtc_pitch, pScrn->virtualX,
info->CurrentLayout.displayWidth));
@@ -6066,12 +6098,13 @@ static Bool RADEONInit(ScrnInfoPtr pScrn
info->Flags = mode->Flags;
+RADEONInitCommonRegisters(pScrn, save);
+
if (info->IsSecondary) {
if (!RADEONInitCrtc2Registers(pScrn, save, mode, info))
return FALSE;
RADEONInitPLL2Registers(save,
RE: Hardware overlays (8+24?) on Intel i830
On Fri, 25 Jul 2003, Sottek, Matthew J wrote: > I understand the need for 8bit displays to support legacy apps; > however, RandR (or RENDER? or a combination of the two?) is > (or will be) able to support 8bit visuals on a 24bpp display. > > I am wondering if giving up a guaranteed and constant amount of > memory bandwidth on a platform that shares memory bandwidth is not > a worse solution than just emulating the 8bit using RandR which > only makes the 8bit drawing a greater bandwidth consumer during > drawing operations. At 32bpp the chips which support overlays allow you to chose, for each pixel, whether to push 8bits through the palette, or take the 24bit direct; effectively you have two active colormaps (although one of them is fixed to the identity mapping). This means either no colormap flashing between the 8 and 24bit windows, or at worst, moving the focus turns gamma-correction of the 24bit visual on and off. The chips I'm familiar with only have one palette at 24bpp. Emulating GrayScale and PseudoColor 8bit visuals on a 24bpp display requires a compromise. Either they share the same active colormap and flash, or you implement the 8bit palette in software, which means either redrawing the window whenever the colormap changes. So far the consensus has been that a software palette is not acceptable within XFree86, so the extra 8bits pays to get rid of colormap flashing. It is definitely a price that we can't ask everyone to pay, but it seems reasonable to allow users to configure the server in such a way that they don't get cmf between the two dephs. -- Andrew C Aitchison ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Building XFree 4.3.99.9
> Hey
> Ive just been trying to build the latest develoment snapshot (4.3.99.9)
> and have come across an error in the compiling.
> xf86DDC.c: In function `DDCRead_DDC2':
> xf86DDC.c:336: error: invalid lvalue in assignment
> make[6]: *** [xf86DDC.o] Error 1
> make[6]: Leaving directory
> `/var/tmp/portage/xfree-4.3.99.9/work/xc/programs/Xserver/hw/xfree86/ddc'
> I cant seem to find much on this at all, except the offending code which is
> the line marked with in the following procedure from xf86DDC.c
> static unsigned char *
> DDCRead_DDC2(int scrnIndex, I2CBusPtr pBus, int start, int len)
> {
> I2CDevPtr dev;
> unsigned char W_Buffer[2];
> int w_bytes;
> unsigned char *R_Buffer;
> int i;
>
> xf86LoaderReqSymLists(i2cSymbols, NULL);
>
> if (!dev = xf86I2CFindDev(pBus, 0x00A0)) {
> dev = xf86CreateI2CDevRec();
> dev->DevName = "ddc2";
> dev->SlaveAddr = 0xA0;
> dev->ByteTimeout = 2200; /* VESA DDC spec 3 p. 43 (+10 %) */
> dev->StartTimeout = 550;
> dev->BitTimeout = 40;
> dev->ByteTimeout = 40;
> dev->AcknTimeout = 40;
>
> dev->pI2CBus = pBus;
> if (!xf86I2CDevInit(dev)) {
> xf86DrvMsg(X_PROBED,scrnIndex,"No DDC2 device\n");
> return NULL;
> }
> }
> if (start < 0x100) {
> w_bytes = 1;
> W_Buffer[0] = start;
> } else {
> w_bytes = 2;
> W_Buffer[0] = start & 0xFF;
> W_Buffer[1] = (start & 0xFF00) >> 8;
> }
> R_Buffer = xcalloc(1,sizeof(unsigned char)
> * (len));
> for (i=0; i if (xf86I2CWriteRead(dev, W_Buffer,w_bytes, R_Buffer,len)) {
> if (!DDC_checksum(R_Buffer,len))
> return R_Buffer;
>
> #ifdef DEBUG
> else ErrorF("Checksum error in EDID block\n");
> #endif
> }
> #ifdef DEBUG
> else ErrorF("Error reading EDID block\n");
> #endif
> }
>
> xf86DestroyI2CDevRec(dev,TRUE);
> xfree(R_Buffer);
> return NULL;
> }
>
> Does anyone have any ideas?
You can try to substitute cc -c by cc -E and look at the produced code.
Loïc
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Building XFree 4.3.99.9
Hey
Ive just been trying to build the latest develoment snapshot (4.3.99.9)
and have come across an error in the compiling.
xf86DDC.c: In function `DDCRead_DDC2':
xf86DDC.c:336: error: invalid lvalue in assignment
make[6]: *** [xf86DDC.o] Error 1
make[6]: Leaving directory
`/var/tmp/portage/xfree-4.3.99.9/work/xc/programs/Xserver/hw/xfree86/ddc'
I cant seem to find much on this at all, except the offending code which is
the line marked with in the following procedure from xf86DDC.c
static unsigned char *
DDCRead_DDC2(int scrnIndex, I2CBusPtr pBus, int start, int len)
{
I2CDevPtr dev;
unsigned char W_Buffer[2];
int w_bytes;
unsigned char *R_Buffer;
int i;
xf86LoaderReqSymLists(i2cSymbols, NULL);
if (!dev = xf86I2CFindDev(pBus, 0x00A0)) {
dev = xf86CreateI2CDevRec();
dev->DevName = "ddc2";
dev->SlaveAddr = 0xA0;
dev->ByteTimeout = 2200; /* VESA DDC spec 3 p. 43 (+10 %) */
dev->StartTimeout = 550;
dev->BitTimeout = 40;
dev->ByteTimeout = 40;
dev->AcknTimeout = 40;
dev->pI2CBus = pBus;
if (!xf86I2CDevInit(dev)) {
xf86DrvMsg(X_PROBED,scrnIndex,"No DDC2 device\n");
return NULL;
}
}
if (start < 0x100) {
w_bytes = 1;
W_Buffer[0] = start;
} else {
w_bytes = 2;
W_Buffer[0] = start & 0xFF;
W_Buffer[1] = (start & 0xFF00) >> 8;
}
R_Buffer = xcalloc(1,sizeof(unsigned char)
* (len));
for (i=0; ihttp://www.volutin.net -- re-start coming soon...>
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
