Re: [PATCH 2/2] exa: Verify non-null pSrc in mgaDownloadFromScreen()

2015-03-03 Thread Tormod Volden
On Tue, Mar 3, 2015 at 3:18 AM, Michel Dänzer wrote:
 On 03.03.2015 05:01, Tormod Volden wrote:
  mgaDownloadFromScreen(PixmapPtr pSrc, int x, int y, int w, int h,
char *dst, int dst_pitch)
  {
 +if (!pSrc)
 + return FALSE;
 +
  PMGA(pSrc);

  char *src = pMga-ExaDriver-memoryBase + exaGetPixmapOffset(pSrc);


 This isn't necessary. Only pScrPict-pDrawable and pMaskPict-pDrawable
 can be NULL in mgaCheckComposite. EXA never calls driver hooks with NULL
 PixmapPtrs.

Hi Michel,

Thanks for the response. OK, good to know. I was wondering about that,
so I left it in a separate patch.



 About patch 1, since mgaDownloadFromScreen doesn't do anything fancier
 than memcpy, you can just remove it altogether and leave
 pExa-DownloadFromScreen NULL. EXA then does basically the same thing
 mgaDownloadFromScreen does.

Yes, Connor also suggested that. However, I would like in any case to
correct the old code first. Does the general EXA also do the
equivalent to QUIESCE_DMA()?

Regards,
Tormod
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH 2/2] exa: Verify non-null pSrc in mgaDownloadFromScreen()

2015-03-03 Thread Tormod Volden
On Tue, Mar 3, 2015 at 9:21 PM, Alex Deucher wrote:
 On Tue, Mar 3, 2015 at 2:21 PM, Tormod Volden wrote:
 On Tue, Mar 3, 2015 at 3:18 AM, Michel Dänzer wrote:
 About patch 1, since mgaDownloadFromScreen doesn't do anything fancier
 than memcpy, you can just remove it altogether and leave
 pExa-DownloadFromScreen NULL. EXA then does basically the same thing
 mgaDownloadFromScreen does.

 Yes, Connor also suggested that. However, I would like in any case to
 correct the old code first. Does the general EXA also do the
 equivalent to QUIESCE_DMA()?


 It calls waitMarker before doing sw ops if that is what you are asking.

Thanks. I took a look, they do different things, and QUIESCE_DMA()
goes into mga_dri.c and places sprinkled with FIXME what about EXA?.
Anyway, I think I leave further changes to someone who can test :)

Regards,
Tormod
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH 1/2] mga: Fix pixmap pointer in EXA mgaDownloadFromScreen()

2015-03-02 Thread Tormod Volden
From: Tormod Volden debian.tor...@gmail.com

Thanks to Connor Behan for the fix.

This replaces commit e9109a0b which was plain wrong.

Signed-off-by: Tormod Volden debian.tor...@gmail.com
---

Hoping for remedy for old sins. Only compile-tested.

Tormod

 src/mga_exa.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mga_exa.c b/src/mga_exa.c
index 69ffa16..24a7328 100644
--- a/src/mga_exa.c
+++ b/src/mga_exa.c
@@ -729,7 +729,7 @@ mgaDownloadFromScreen(PixmapPtr pSrc, int x, int y, int w, 
int h,
 {
 PMGA(pSrc);
 
-char *src = (char *) exaGetPixmapFirstPixel(pSrc);
+char *src = pMga-ExaDriver-memoryBase + exaGetPixmapOffset(pSrc);
 int src_pitch = exaGetPixmapPitch(pSrc);
 
 int cpp = (pSrc-drawable.bitsPerPixel + 7) / 8;
-- 
1.7.10.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH 2/2] exa: Verify non-null pSrc in mgaDownloadFromScreen()

2015-03-02 Thread Tormod Volden
From: Tormod Volden debian.tor...@gmail.com

Thanks to Connor Behan for the suggestion.

Signed-off-by: Tormod Volden debian.tor...@gmail.com
---

Also not tested on hardware.

Tormod

 src/mga_exa.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/mga_exa.c b/src/mga_exa.c
index 24a7328..cb17ad8 100644
--- a/src/mga_exa.c
+++ b/src/mga_exa.c
@@ -727,6 +727,9 @@ static Bool
 mgaDownloadFromScreen(PixmapPtr pSrc, int x, int y, int w, int h,
   char *dst, int dst_pitch)
 {
+if (!pSrc)
+   return FALSE;
+
 PMGA(pSrc);
 
 char *src = pMga-ExaDriver-memoryBase + exaGetPixmapOffset(pSrc);
-- 
1.7.10.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH:xf86-video-mga] Fix pointer cast warning.

2015-02-25 Thread Tormod Volden
On Wed, Feb 25, 2015 at 2:01 PM, Mark Kettenis wrote:

 That pretty much confirms the code doesn't work (before or after your
 change).  Probably the answer is to revert the
 exaGetPixmapFirstPixel() changes you made (here and in other drivers).

Oops, yes, now I see that using exaGetPixmapFirstPixel() was wrong. I
did that change in the savage driver first, where it seemed to work (I
could smoke test on hardware). I seem to remember I picked this fix
from somewhere else, but it could very well be that I misinterpreted
something.

 And then disable the DownloadFromScreen() implementation, or perhaps
 even disable EXA altogether.

If nobody can find the real problem that is maybe all that can be done.

Tormod
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH 2/8] -pendantic is too pendantic

2013-11-07 Thread Tormod Volden
On Thu, Nov 7, 2013 at 4:45 AM, Keith Packard wrote:
 Many system headers have warnings when compiled with this flag.

 Signed-off-by: Keith Packard kei...@keithp.com

At the risk of sounding pendantic, is your spelling a pun? Or trap :)

Tormod
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


Re: any xserver stable branch nominations?

2013-10-29 Thread Tormod Volden
On Tue, Oct 22, 2013 at 4:51 AM, Matt Dew wrote:
 Hi Tormod,
   I only take cherry-picks or pulls.  Not individual patches.

 Keith,
   Thoughts on applying that to master?

 Matt


 On 10/18/2013 05:05 PM, Tormod Volden wrote:
 Please consider Connor's patch (resent yesterday, Message-Id:
 1382059588-620-1-git-send-email-connor.be...@gmail.com,
 http://lists.x.org/archives/xorg-devel/2013-October/038232.html).

Hi Matt,

Now that Keith has applied this in master, can you please consider it
for the point release? It is a regression fix that would make (at
least) the r128 driver work again, so it would be nice to have this
float into distribution updates.

http://cgit.freedesktop.org/xorg/xserver/commit/?id=04ab07ca19236d6c9a947e065fb69b0dd0d16639

Regards,
Tormod
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


[PATCH r128] Do not use int10 or VBE on powerpc

2013-10-25 Thread Tormod Volden
From: Tormod Volden debian.tor...@gmail.com

VBE was already skipped in the normal path, but not when setting
the PROBE_DETECT flag.

Should avoid bus error seen in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622606 and
http://lists.x.org/archives/xorg/2012-February/053969.html

Signed-off-by: Tormod Volden debian.tor...@gmail.com
---

 src/r128_driver.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/r128_driver.c b/src/r128_driver.c
index 72d9e3c..6acdf2d 100644
--- a/src/r128_driver.c
+++ b/src/r128_driver.c
@@ -1758,8 +1758,8 @@ static Bool R128PreInitCursor(ScrnInfoPtr pScrn)
 static Bool R128PreInitInt10(ScrnInfoPtr pScrn, xf86Int10InfoPtr *ppInt10)
 {
 R128InfoPtr   info = R128PTR(pScrn);
-#if 1  !defined(__alpha__)
-/* int10 is broken on some Alphas */
+#if !defined(__powerpc__)  !defined(__alpha__)
+/* int10 is broken on some Alphas and powerpc */
 if (xf86LoadSubModule(pScrn, int10)) {
xf86DrvMsg(pScrn-scrnIndex,X_INFO,initializing int10\n);
*ppInt10 = xf86InitInt10(info-pEnt-index);
@@ -1890,11 +1890,14 @@ static void
 R128ProbeDDC(ScrnInfoPtr pScrn, int indx)
 {
 vbeInfoPtr pVbe;
+
+#if !defined(__powerpc__)  !defined(__alpha__)  !defined(__sparc__)
 if (xf86LoadSubModule(pScrn, vbe)) {
pVbe = VBEInit(NULL,indx);
ConfiguredMonitor = vbeDoEDID(pVbe, NULL);
vbeFree(pVbe);
 }
+#endif
 }
 
 /* R128PreInit is called once at server startup. */
-- 
1.7.10.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


[PATCH 1/2] Unbreak dual head (xinerama)

2013-10-18 Thread Tormod Volden
From: Andy MacLean andy-...@themacleans.org.uk

This patch has been used in Debian, Ubuntu and Gentoo for years.

https://bugs.freedesktop.org/show_bug.cgi?id=18472
https://launchpad.net/bugs/292214
https://bugs.gentoo.org/show_bug.cgi?id=265100

Signed-off-by: Andy MacLean andy-...@themacleans.org.uk
Reviewed-by: Cyril Brulebois k...@debian.org
Reviewed-by: Robert Jacobs robert.n.jac...@gmail.com
Tested-by: Robert Jacobs robert.n.jac...@gmail.com
---

Hi,

If there are no objections or other suggestions, I intend to commit
these patches next week, together with Egbert's patches from July.

Best regards,
Tormod


 src/mga.h|7 
 src/mga_driver.c |  115 --
 2 files changed, 92 insertions(+), 30 deletions(-)

diff --git a/src/mga.h b/src/mga.h
index 0c5d71d..988ba93 100644
--- a/src/mga.h
+++ b/src/mga.h
@@ -343,6 +343,13 @@ typedef struct {
 intmastervideoRam;
 intslavevideoRam;
 Bool   directRenderingEnabled;
+
+void * mappedIOBase;
+intmappedIOUsage;
+
+void * mappedILOADBase;
+intmappedILOADUsage;
+
 ScrnInfoPtrpScrn_1;
 ScrnInfoPtrpScrn_2;
 } MGAEntRec, *MGAEntPtr;
diff --git a/src/mga_driver.c b/src/mga_driver.c
index 5cce7ac..3bd814e 100644
--- a/src/mga_driver.c
+++ b/src/mga_driver.c
@@ -2687,30 +2687,55 @@ MGAMapMem(ScrnInfoPtr pScrn)
 #ifdef XSERVER_LIBPCIACCESS
 struct pci_device *const dev = pMga-PciInfo;
 struct pci_mem_region *region;
-void **memory[2];
 int i, err;
 #endif
 
 
 if (!pMga-FBDev) {
 #ifdef XSERVER_LIBPCIACCESS
-memory[pMga-io_bar] = pMga-IOBase;
-memory[pMga-framebuffer_bar] = pMga-FbBase;
+   pciaddr_t fbaddr = pMga-FbAddress;
+   pciaddr_t fbsize = pMga-FbMapSize;
+   err = pci_device_map_range(dev,
+  fbaddr, fbsize,
+  PCI_DEV_MAP_FLAG_WRITABLE,
+  (void **)pMga-FbBase);
 
-for (i = 0; i  2; i++) {
-region = dev-regions[i];
-err = pci_device_map_range(dev,
-   region-base_addr, region-size,
-   PCI_DEV_MAP_FLAG_WRITABLE,
-   memory[i]);
+   if (err) {
+   xf86DrvMsg(pScrn-scrnIndex, X_ERROR,
+  Unable to map Framebuffer %08llX %llx.  %s (%d)\n,
+  (long long)fbaddr, (long long)fbsize,
+  strerror(err), err);
+   return FALSE;
+   }
+   else
+   xf86DrvMsg(pScrn-scrnIndex, X_INFO,
+  MAPPED Framebuffer %08llX %llx to %08llX.\n,
+  (long long)fbaddr, (long long)fbsize,
+  (long long)pMga-FbBase);
+
+   if(pMga-entityPrivate == NULL || pMga-entityPrivate-mappedIOUsage == 
0) {
+   region = dev-regions[pMga-io_bar];
+   err = pci_device_map_range(dev,
+  region-base_addr, region-size,
+  PCI_DEV_MAP_FLAG_WRITABLE,
+  pMga-IOBase);
+
+   if (err) {
+ xf86DrvMsg(pScrn-scrnIndex, X_ERROR,
+Unable to map IO Region %i.  %s (%d)\n,
+pMga-io_bar, strerror(err), err);
+ return FALSE;
+   }
+
+   if(pMga-entityPrivate != NULL)
+   pMga-entityPrivate-mappedIOBase = pMga-IOBase;
+   }
+   else
+   pMga-IOBase = pMga-entityPrivate-mappedIOBase;
+
+   if(pMga-entityPrivate != NULL)
+   pMga-entityPrivate-mappedIOUsage ++;
 
-if (err) {
-xf86DrvMsg(pScrn-scrnIndex, X_ERROR,
-   Unable to map BAR %i.  %s (%d)\n,
-   i, strerror(err), err);
-return FALSE;
-}
-}
 #else
/*
 * For Alpha, we need to map SPARSE memory, since we need
@@ -2761,16 +2786,27 @@ MGAMapMem(ScrnInfoPtr pScrn)
 if (pMga-iload_bar != -1) {
 #ifdef XSERVER_LIBPCIACCESS
 region = dev-regions[pMga-iload_bar];
-err = pci_device_map_range(dev,
-   region-base_addr, region-size,
-   PCI_DEV_MAP_FLAG_WRITABLE,
-   (void *) pMga-ILOADBase);
-   if (err) {
-   xf86DrvMsg(pScrn-scrnIndex, X_ERROR,
-  Unable to map BAR 2 (ILOAD region).  %s (%d)\n,
-  strerror(err), err);
-   return FALSE;
+
+   if(pMga-entityPrivate == NULL || pMga-entityPrivate-mappedILOADUsage 
== 0) {
+   err = pci_device_map_range(dev,
+  region-base_addr, region-size,
+

[PATCH 2/2] Fix dual head crash without XAA

2013-10-18 Thread Tormod Volden
From: Tormod Volden debian.tor...@gmail.com

https://launchpad.net/bugs/1180986

Signed-off-by: Tormod Volden debian.tor...@gmail.com
Reviewed-by: Robert Jacobs robert.n.jac...@gmail.com
Tested-by: Robert Jacobs robert.n.jac...@gmail.com

---
 src/mga_driver.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/mga_driver.c b/src/mga_driver.c
index 3bd814e..a5d0bc4 100644
--- a/src/mga_driver.c
+++ b/src/mga_driver.c
@@ -3177,11 +3177,13 @@ MGACrtc2FillStrip(ScrnInfoPtr pScrn)
(pScrn-bitsPerPixel  3) * pScrn-displayWidth * pScrn-virtualY);
 } else {
xf86SetLastScrnFlag(pScrn-entityList[0], pScrn-scrnIndex);
+#ifdef HAVE_XAA_H
pMga-RestoreAccelState(pScrn);
pMga-SetupForSolidFill(pScrn, 0, GXcopy, 0x);
pMga-SubsequentSolidFillRect(pScrn, pScrn-virtualX, 0,
  pScrn-displayWidth - pScrn-virtualX,
  pScrn-virtualY);
+#endif
MGAStormSync(pScrn);
 }
 }
-- 
1.7.10.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


Re: any xserver stable branch nominations?

2013-10-18 Thread Tormod Volden
On Fri, Oct 18, 2013 at 1:29 AM, Matt Dew wrote:
  Today was the nominal 1.14.4-rc2 release.  I've gotten no
 nominations, pull or cherry-pick requests since 1.14.3 was released.

 Can I assume 1.14.3 has been good to folks or that people are
 anxiously awaiting the chocolaty goodness of 1.15? Or did I miss some
 emails.

Please consider Connor's patch (resent yesterday, Message-Id:
1382059588-620-1-git-send-email-connor.be...@gmail.com,
http://lists.x.org/archives/xorg-devel/2013-October/038232.html).

Cheers,
Tormod
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


Re: (Crowd funded) fix for SiS 671/771 video cards

2013-05-18 Thread Tormod Volden
On Sat, May 18, 2013 at 7:52 PM, Pander wrote:
 (manual) patch results in

 [74.465] (II) LoadModule: sisimedia
 [74.465] (II) Loading /usr/lib/xorg/modules/drivers/sisimedia_drv.so
 [74.465] (EE) Failed to load
 /usr/lib/xorg/modules/drivers/sisimedia_drv.so:
 /usr/lib/xorg/modules/drivers/sisimedia_drv.so: undefined symbol:
 SiSUploadToScratch
 [74.465] (II) UnloadModule: sisimedia
 [74.465] (II) Unloading sisimedia
 [74.465] (EE) Failed to load module sisimedia (loader failed, 7)

 I used this file: http://pastebin.com/XkYfxrQy

It would be more useful if you told which file it is and which version
instead of paste-binning it. I assume this is the src/sis310_accel.c
from git://gitorious.org/xf86-video-sis671/sis-671-fix.git


 How can I fix this?


Connor's pastebin patch only removed SiSUploadToScratch() from that
one file. You will have to remove all references to that function.
git grep SiSUploadToScratch will help you.

Regards,
Tormod
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


Re: (Crowd funded) fix for SiS 671/771 video cards

2013-05-10 Thread Tormod Volden
On Fri, May 10, 2013 at 11:04 AM, Pander wrote:
 On 05/07/2013 09:24 PM, Connor Behan wrote:

 SiS drivers support EXA and will probably use that by default when
 you start one of the newer Xservers that lacks XAA. This could
 easily crash if the SiS EXA hooks haven't been updated in awhile so
 that's why I suggested NoAccel to help diagnose the problem.

Connor, first, thanks a lot for caring for these old drivers. A lot of
people are still using their old laptops and run the latest Linux
distributions on them.

Thanks especially for the hint you gave earlier in this thread: EXA
callbacks that use the devPrivate.ptr of a pixmap. I am trying to
keep the savage driver working, but I don't have the capacity to
follow xorg development in detail. Recently an EXA problem came up for
which I had no clue. Reading your hint was enough to guide me in the
right direction and now I believe I have fixed it with a one-liner
change.

 Xorg works but when I press CTRL+ALT+F1 I get a screen with an unusable
 screen. I see a small part of Xorg repeated a lon on the left side and
 on the right side many different colors. This part works with the older
 SiS driver for other cards.

Pander, does console switching work with the vesa driver? It doesn't
on my savage card, so I wonder if it is a more general non-KMS
problem. You say it works with the older SiS driver though, was that
also on the latest xserver?

Regards,
Tormod
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


Re: [PATCH video-modesetting 13/14] config: layout and comment the top portion of configure.ac

2012-02-19 Thread Tormod Volden
On Sun, Feb 19, 2012 at 2:36 PM, Gaetan Nadon mems...@videotron.ca wrote:
 Reorder statements to be consistent with other modules so things
 are easier to find.

...
 +# Initialize X.Org macros 1.8 or later for MAN_SUBSTS set by 
 XORG_MANPAGE_SECTIONS
 +m4_ifndef([XORG_MACROS_VERSION],
 +       [m4_fatal([must install xorg-macros 1.8 or later before runnign 
 autoconf/autogen])])

Maybe you can s/runnign/running at the same time.

Tormod
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


Re: [PATCH savage] Refactor BIOS modes retrieval to only call VBEGetVBEInfo once

2012-02-17 Thread Tormod Volden
On Thu, Feb 16, 2012 at 11:35 PM, Julien Cristau jcris...@debian.org wrote:
 On Wed, Feb 15, 2012 at 23:07:12 +0100, Tormod Volden wrote:

 From: Tormod Volden debian.tor...@gmail.com

 Signed-off-by: Tormod Volden debian.tor...@gmail.com
 ---

 The change should be fine by itself, but the reason I changed this is
 that with the latest stack (upgraded to 1.12RC etc) the second call to
 VBEGetVBEInfo would return corrupted values. There, I fixed it!(TM) :)

 So was the issue due to bugs in the savage driver, or is there something
 more general VBE stuff broken? I also noticed that the vesa driver messes
 up now, the computer hardlocks when I try to change VT. I haven't had time
 to investigate that much further so I don't know if it is related.

 Anyone else seeing strange stuff with VBE-enabled drivers?

 ajax was having fun in vesa-land recently AIUI (by which I mean was
 trying to make it work again with 1.12), so it seems like it's not just
 you.

Julien, thanks! /me googles ajax vesa

Ajax, was that this issue:
libpciaccess-lol-dev-port.patch: Don't use /dev/port since the kernel insists
http://pkgs.fedoraproject.org/gitweb/?p=libpciaccess.git;a=commitdiff;h=c2d89ecd4628ee6953986ee564a0052b34771178

or is there more to it?

That patch does not fix my vesa lock-up. BTW, the vesa lock-up happens
on xserver 1.11.3rc and 1.12rc, kernel 3.0.16 and 3.2.6.

Cheers,
Tormod



 Cheers,
 Julien
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


[PATCH savage] Refactor BIOS modes retrieval to only call VBEGetVBEInfo once

2012-02-15 Thread Tormod Volden
From: Tormod Volden debian.tor...@gmail.com

Signed-off-by: Tormod Volden debian.tor...@gmail.com
---

The change should be fine by itself, but the reason I changed this is
that with the latest stack (upgraded to 1.12RC etc) the second call to
VBEGetVBEInfo would return corrupted values. There, I fixed it!(TM) :)

So was the issue due to bugs in the savage driver, or is there something
more general VBE stuff broken? I also noticed that the vesa driver messes
up now, the computer hardlocks when I try to change VT. I haven't had time
to investigate that much further so I don't know if it is related.

Anyone else seeing strange stuff with VBE-enabled drivers?

Cheers,
Tormod


 src/savage_driver.h |1 +
 src/savage_vbe.c|   25 ++---
 2 files changed, 15 insertions(+), 11 deletions(-)

diff --git a/src/savage_driver.h b/src/savage_driver.h
index 7b7e01d..338cfac 100644
--- a/src/savage_driver.h
+++ b/src/savage_driver.h
@@ -625,6 +625,7 @@ ModeStatus SavageMatchBiosMode(ScrnInfoPtr pScrn,int 
width,int height,int refres
 
 unsigned short SavageGetBIOSModes( 
 SavagePtr psav,
+VbeInfoBlock *vbe,
 int iDepth,
 SavageModeEntryPtr s3vModeTable );
 
diff --git a/src/savage_vbe.c b/src/savage_vbe.c
index d24da24..7dba538 100644
--- a/src/savage_vbe.c
+++ b/src/savage_vbe.c
@@ -242,17 +242,28 @@ SavageFreeBIOSModeTable( SavagePtr psav, 
SavageModeTablePtr* ppTable )
 SavageModeTablePtr
 SavageGetBIOSModeTable( SavagePtr psav, int iDepth )
 {
-int nModes = SavageGetBIOSModes( psav, iDepth, NULL );
+VbeInfoBlock *vbe;
+int nModes;
 SavageModeTablePtr pTable;
 
+if( !psav-pVbe )
+   return 0;
+
+if (!(vbe = VBEGetVBEInfo(psav-pVbe)))
+   return 0;
+
+nModes = SavageGetBIOSModes( psav, vbe, iDepth, NULL );
+
 pTable = (SavageModeTablePtr) 
calloc( 1, sizeof(SavageModeTableRec) + 
(nModes-1) * sizeof(SavageModeEntry) );
 if( pTable ) {
pTable-NumModes = nModes;
-   SavageGetBIOSModes( psav, iDepth, pTable-Modes );
+   SavageGetBIOSModes( psav, vbe, iDepth, pTable-Modes );
 }
 
+VBEFreeVBEInfo(vbe);
+
 return pTable;
 }
 
@@ -260,19 +271,16 @@ SavageGetBIOSModeTable( SavagePtr psav, int iDepth )
 unsigned short
 SavageGetBIOSModes( 
 SavagePtr psav,
+VbeInfoBlock *vbe,
 int iDepth,
 SavageModeEntryPtr s3vModeTable )
 {
 unsigned short iModeCount = 0;
 unsigned short int *mode_list;
 pointer vbeLinear = NULL;
-VbeInfoBlock *vbe;
 int vbeReal;
 struct vbe_mode_info_block * vmib;
 
-if( !psav-pVbe )
-   return 0;
-
 vbeLinear = xf86Int10AllocPages( psav-pVbe-pInt10, 1, vbeReal );
 if( !vbeLinear )
 {
@@ -281,9 +289,6 @@ SavageGetBIOSModes(
 }
 vmib = (struct vbe_mode_info_block *) vbeLinear;
 
-if (!(vbe = VBEGetVBEInfo(psav-pVbe)))
-   return 0;
-
 for (mode_list = vbe-VideoModePtr; *mode_list != 0x; mode_list++) {
 
/*
@@ -377,8 +382,6 @@ SavageGetBIOSModes(
}
 }
 
-VBEFreeVBEInfo(vbe);
-
 xf86Int10FreePages( psav-pVbe-pInt10, vbeLinear, 1 );
 
 return iModeCount;
-- 
1.7.0.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


Re: [PATCH xf86-video-savage] Untangle XF86DRI from the driver-specific DRI define

2012-01-17 Thread Tormod Volden
On Tue, Jan 17, 2012 at 6:35 AM, Peter Hutterer
peter.hutte...@who-t.net wrote:
 XF86DRI is defined by xorg-server.h, so --disable-dri in the driver
 itself does exactly nothing other than not fill in the CFLAGS and thus stop
 the driver from compiling.

 Signed-off-by: Peter Hutterer peter.hutte...@who-t.net

Thanks, pushed.

Tormod
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


Re: [PATCH sis] Untangle XF86DRI from the driver-specific DRI define

2012-01-14 Thread Tormod Volden
 SISDRI
     if(pSiS-directRenderingEnabled) {
        SISDRICloseScreen(pScreen);
        pSiS-directRenderingEnabled = FALSE;
 diff --git a/src/sis_opt.c b/src/sis_opt.c
 index d39ff6e..3fa12c9 100644
 --- a/src/sis_opt.c
 +++ b/src/sis_opt.c
 @@ -480,7 +480,7 @@ SiSOptions(ScrnInfoPtr pScrn)
  #endif
     pSiS-ShadowFB = FALSE;
     pSiS-loadDRI = FALSE;
 -#ifdef XF86DRI
 +#ifdef SISDRI
     pSiS-agpWantedPages = AGP_PAGES;
  #endif
     pSiS-VESA = -1;
 @@ -2034,7 +2034,7 @@ SiSOptions(ScrnInfoPtr pScrn)
        }
     }

 -#ifdef XF86DRI
 +#ifdef SISDRI
     /* DRI */
     from = X_DEFAULT;
     if(xf86GetOptValBool(pSiS-Options, OPTION_DRI, pSiS-loadDRI)) {
 --
 1.7.7.4

 Cheers,
  Peter

Other than those two things,
Reviewed-by: Tormod Volden debian.tor...@gmail.com

Tormod
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


[PATCH xgi] Fix warning: control reaches end of non-void function.

2012-01-13 Thread Tormod Volden
From: Johannes Obermayr johannesoberm...@gmx.de

[Tormod: Remove unnecessary else and fix spelling in messages]
Signed-off-by: Tormod Volden debian.tor...@gmail.com
---

How about this then? For consistency do the same to other functions.

Fixed up some glaring spelling mistakes while I was in there, ugh.

 src/vb_i2c.c |   20 +++-
 1 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/src/vb_i2c.c b/src/vb_i2c.c
index 96e26e3..56ad52e 100755
--- a/src/vb_i2c.c
+++ b/src/vb_i2c.c
@@ -1606,8 +1606,8 @@ VOID vWriteClockLine(PXGI_HW_DEVICE_INFO pHWDE, UCHAR 
data)
vWriteClockLineDVI(pHWDE, data);
else if(pHWDE-crtno == 2)
vWriteClockLineFCNT(pHWDE, data);
-   else
-   ErrorF(Error(XGI) : Unkonwn output device! \n);
+
+   ErrorF(Error(XGI) : Unknown output device!\n);
 }
 
 VOID vWriteDataLine(PXGI_HW_DEVICE_INFO pHWDE, UCHAR data)
@@ -1618,8 +1618,8 @@ VOID vWriteDataLine(PXGI_HW_DEVICE_INFO pHWDE, UCHAR data)
   vWriteDataLineDVI(pHWDE, data);
else if(pHWDE-crtno == 2)
vWriteDataLineFCNT(pHWDE, data);
-   else
-   ErrorF(Error(XGI) : Unkonwn output device! \n);
+
+   ErrorF(Error(XGI) : Unknown output device! \n);
 }
 
 BOOLEAN bReadClockLine(PXGI_HW_DEVICE_INFO pHWDE)
@@ -1630,8 +1630,9 @@ BOOLEAN bReadClockLine(PXGI_HW_DEVICE_INFO pHWDE)
return(bReadClockLineDVI(pHWDE));
else if(pHWDE-crtno == 2)
return(bReadClockLineFCNT(pHWDE));
-   else
-   ErrorF(Error(XGI) : Unkonwn output device! \n);
+
+   ErrorF(Error(XGI) : Unknown output device!\n);
+   return FALSE;
 }
 
 BOOLEAN bReadDataLine(PXGI_HW_DEVICE_INFO pHWDE)
@@ -1642,8 +1643,9 @@ BOOLEAN bReadDataLine(PXGI_HW_DEVICE_INFO pHWDE)
return(bReadDataLineDVI(pHWDE));
else if(pHWDE-crtno == 2)
return(bReadDataLineFCNT(pHWDE));
-   else
-   ErrorF(Error(XGI) : Unkonwn output device! \n);
+
+   ErrorF(Error(XGI) : Unknown output device!\n);
+   return FALSE;
 }
 
 BOOLEAN bEDIDCheckSum(PUCHAR  pjEDIDBuf,ULONG   ulBufSize)
@@ -1890,4 +1892,4 @@ BOOLEAN bGetEDID(
 
PDEBUGI2C(ErrorF(bGetEDID()-return(%d)\n, status == NO_ERROR ? 1:0));
 return (status == NO_ERROR);
-}
\ No newline at end of file
+}
-- 
1.7.8.3

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


Re: [PATCH xgi] Fix warning: control reaches end of non-void function.

2012-01-13 Thread Tormod Volden
On Fri, Jan 13, 2012 at 10:44 PM, Jeremy Huddleston jerem...@apple.com wrote:
 Reviewed-by: Jeremy Huddleston jerem...@apple.com

 On Jan 13, 2012, at 13:18, Tormod Volden wrote:

 From: Johannes Obermayr johannesoberm...@gmx.de

 [Tormod: Remove unnecessary else and fix spelling in messages]
 Signed-off-by: Tormod Volden debian.tor...@gmail.com

Thanks, pushed.

This is however not enough to make it build on 1.12...

Tormod
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


Re: Patches for xf86-video-{tdfx,trident,xgi}

2012-01-13 Thread Tormod Volden
On Fri, Dec 30, 2011 at 12:50 PM, Johannes Obermayr
johannesoberm...@gmx.de wrote:
 Hi,

 following patches are required for building on openSUSE and should be 
 upstreamed.

 To keep actual authors dates I do not send them via 'git send-email', but you 
 can import them also via 'git am'.


The tdfx patch 0001-Fix-RPMLINT-warning-64bit-portability-issue.patch is
Reviewed-by: Tormod Volden debian.tor...@gmail.com

and has been pushed it to git. Thanks.

(To sum up: The trident patch is obsolete, and the xgi patch was
amended and applied.)

Tormod
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


[PATCH s3virge] Do not use deprecated xf86PciInfo.h

2012-01-08 Thread Tormod Volden
From: Tormod Volden debian.tor...@gmail.com

Signed-off-by: Tormod Volden debian.tor...@gmail.com
---
 src/s3v.h|3 ---
 src/s3v_accel.c  |1 +
 src/s3v_dga.c|1 -
 src/s3v_driver.c |5 +++--
 src/s3v_hwcurs.c |1 +
 src/s3v_i2c.c|1 -
 src/s3v_pciids.h |   18 ++
 src/s3v_shadow.c |1 -
 src/s3v_xv.c |5 +++--
 9 files changed, 26 insertions(+), 10 deletions(-)
 create mode 100644 src/s3v_pciids.h

diff --git a/src/s3v.h b/src/s3v.h
index 42b1f83..f4976ca 100644
--- a/src/s3v.h
+++ b/src/s3v.h
@@ -40,9 +40,6 @@ in this Software without prior written authorization from the 
XFree86 Project.
 /* Everything using inb/outb, etc needs compiler.h */
 #include compiler.h
 
-/* Drivers for PCI hardware need this */
-#include xf86PciInfo.h
-
 /* Drivers that need to access the PCI config space directly need this */
 #include xf86Pci.h
 
diff --git a/src/s3v_accel.c b/src/s3v_accel.c
index 2e6d798..7837e4a 100644
--- a/src/s3v_accel.c
+++ b/src/s3v_accel.c
@@ -30,6 +30,7 @@ in this Software without prior written authorization from the 
XFree86 Project.
 
 #include unistd.h
 #include s3v.h
+#include s3v_pciids.h
 
 #include miline.h
/* fb includes are in s3v.h */
diff --git a/src/s3v_dga.c b/src/s3v_dga.c
index 57d05ef..ecf8571 100644
--- a/src/s3v_dga.c
+++ b/src/s3v_dga.c
@@ -62,7 +62,6 @@ in this Software without prior written authorization from the 
XFree86 Project.
 #include xf86.h
 #include xf86_OSproc.h
 #include xf86Pci.h
-#include xf86PciInfo.h
 #include xaa.h
 #include xaalocal.h
 #include s3v.h
diff --git a/src/s3v_driver.c b/src/s3v_driver.c
index 5f64be1..7064b1e 100644
--- a/src/s3v_driver.c
+++ b/src/s3v_driver.c
@@ -57,8 +57,9 @@ in this Software without prior written authorization from the 
XFree86 Project.
  */
 
 
-   /* Most xf86 commons are already in s3v.h */
-#include   s3v.h
+/* Most xf86 commons are already in s3v.h */
+#include s3v.h
+#include s3v_pciids.h

 
 #include globals.h
diff --git a/src/s3v_hwcurs.c b/src/s3v_hwcurs.c
index 53c539f..58e8fd9 100644
--- a/src/s3v_hwcurs.c
+++ b/src/s3v_hwcurs.c
@@ -39,6 +39,7 @@ in this Software without prior written authorization from the 
XFree86 Project.
 
 
 #include s3v.h
+#include s3v_pciids.h
 
 /* protos */
 
diff --git a/src/s3v_i2c.c b/src/s3v_i2c.c
index cbac21f..6bbfd1e 100644
--- a/src/s3v_i2c.c
+++ b/src/s3v_i2c.c
@@ -58,7 +58,6 @@ in this Software without prior written authorization from the 
XFree86 Project.
 #include compiler.h
 
 #include xf86Pci.h
-#include xf86PciInfo.h
 
 #include vgaHW.h
 
diff --git a/src/s3v_pciids.h b/src/s3v_pciids.h
new file mode 100644
index 000..5d11333
--- /dev/null
+++ b/src/s3v_pciids.h
@@ -0,0 +1,18 @@
+#ifndef S3V_PCIIDS_H
+#define S3V_PCIIDS_H
+
+#define PCI_VENDOR_S3  0x5333
+#define PCI_CHIP_VIRGE 0x5631
+#define PCI_CHIP_TRIO  0x8811
+#define PCI_CHIP_TRIO64UVP 0x8814
+#define PCI_CHIP_VIRGE_VX  0x883D
+#define PCI_CHIP_TRIO64V2_DXGX 0x8901
+#define PCI_CHIP_Trio3D0x8904
+#define PCI_CHIP_VIRGE_DXGX0x8A01
+#define PCI_CHIP_VIRGE_GX2 0x8A10
+#define PCI_CHIP_Trio3D_2X 0x8A13
+#define PCI_CHIP_VIRGE_MX  0x8C01
+#define PCI_CHIP_VIRGE_MXPLUS  0x8C02
+#define PCI_CHIP_VIRGE_MXP 0x8C03
+
+#endif /* S3V_PCIIDS_H */
diff --git a/src/s3v_shadow.c b/src/s3v_shadow.c
index e2e1269..82b763f 100644
--- a/src/s3v_shadow.c
+++ b/src/s3v_shadow.c
@@ -60,7 +60,6 @@ in this Software without prior written authorization from the 
XFree86 Project.
 
 #include xf86.h
 #include xf86_OSproc.h
-#include xf86PciInfo.h
 #include xf86Pci.h
 #include shadowfb.h
 #include servermd.h
diff --git a/src/s3v_xv.c b/src/s3v_xv.c
index cc836d4..2466789 100644
--- a/src/s3v_xv.c
+++ b/src/s3v_xv.c
@@ -40,8 +40,9 @@ in this Software without prior written authorization from the 
XFree86 Project.
 #include config.h
 #endif
 
-   /* Most xf86 commons are already in s3v.h */
-#include   s3v.h
+/* Most xf86 commons are already in s3v.h */
+#include s3v.h
+#include s3v_pciids.h
 
 #if 0
 #define OFF_DELAY  250  /* milliseconds */
-- 
1.7.7.3

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


[PATCH s3virge] Add missing VERBLEV argument to xf86DrvMsgVerb()

2011-12-26 Thread Tormod Volden
From: Tormod Volden debian.tor...@gmail.com

Signed-off-by: Tormod Volden debian.tor...@gmail.com
---

Fixes build failure here at least.

 src/s3v_driver.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/s3v_driver.c b/src/s3v_driver.c
index 2cc04ce..0440014 100644
--- a/src/s3v_driver.c
+++ b/src/s3v_driver.c
@@ -1328,7 +1328,7 @@ S3VPreInit(ScrnInfoPtr pScrn, int flags)
 /* Load XAA if needed */
 if (!ps3v-NoAccel || ps3v-hwcursor ) {
if (!xf86LoadSubModule(pScrn, xaa)) {
-   xf86DrvMsgVerb(pScrn-scrnIndex, X_INFO,
+   xf86DrvMsgVerb(pScrn-scrnIndex, X_INFO, VERBLEV,
   Falling back to shadowfb\n);
ps3v-NoAccel = 1;
ps3v-hwcursor = 0;
-- 
1.7.7.3

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


[PATCH s3virge] Replace deprecated x(c/re)alloc/xfree with m/c/realloc/free

2011-12-26 Thread Tormod Volden
From: Tormod Volden debian.tor...@gmail.com

sed -i 's/xalloc/malloc/g; s/xcalloc/calloc/g; s/xrealloc/realloc/g;
 s/xfree(/free(/g'

Also added a missing unistd.h include for usleep().

Signed-off-by: Tormod Volden debian.tor...@gmail.com
---


 src/s3v_accel.c  |1 +
 src/s3v_dga.c|6 +++---
 src/s3v_driver.c |   16 
 src/s3v_xv.c |8 
 4 files changed, 16 insertions(+), 15 deletions(-)

diff --git a/src/s3v_accel.c b/src/s3v_accel.c
index 528ab8a..2e6d798 100644
--- a/src/s3v_accel.c
+++ b/src/s3v_accel.c
@@ -28,6 +28,7 @@ in this Software without prior written authorization from the 
XFree86 Project.
 #include config.h
 #endif
 
+#include unistd.h
 #include s3v.h
 
 #include miline.h
diff --git a/src/s3v_dga.c b/src/s3v_dga.c
index 7ad42db..57d05ef 100644
--- a/src/s3v_dga.c
+++ b/src/s3v_dga.c
@@ -116,15 +116,15 @@ S3VDGAInit(ScreenPtr pScreen)
   to be rewritten to accommodate depth changes in DGA mode */
 
if(0 /*pScrn-displayWidth != pMode-HDisplay*/) {
-   newmodes = xrealloc(modes, (num + 2) * sizeof(DGAModeRec));
+   newmodes = realloc(modes, (num + 2) * sizeof(DGAModeRec));
oneMore = TRUE;
} else {
-   newmodes = xrealloc(modes, (num + 1) * sizeof(DGAModeRec));
+   newmodes = realloc(modes, (num + 1) * sizeof(DGAModeRec));
oneMore = FALSE;
}
 
if(!newmodes) {
-  xfree(modes);
+  free(modes);
   return FALSE;
}
modes = newmodes;
diff --git a/src/s3v_driver.c b/src/s3v_driver.c
index 0440014..5f64be1 100644
--- a/src/s3v_driver.c
+++ b/src/s3v_driver.c
@@ -383,7 +383,7 @@ S3VFreeRec(ScrnInfoPtr pScrn)
 PVERB5(   S3VFreeRec\n);
 if (pScrn-driverPrivate == NULL)
return;
-xfree(pScrn-driverPrivate);
+free(pScrn-driverPrivate);
 pScrn-driverPrivate = NULL;
 }
 
@@ -435,7 +435,7 @@ S3VProbe(DriverPtr drv, int flags)
numDevSections, drv, usedChips);
 
 /* Free it since we don't need that list after this */
-xfree(devSections);
+free(devSections);
 if (numUsed = 0)
return FALSE;
 
@@ -463,7 +463,7 @@ S3VProbe(DriverPtr drv, int flags)
foundScreen = TRUE;
}
 }
-xfree(usedChips);
+free(usedChips);
 PVERB5(   S3VProbe end\n);
 return foundScreen;
 }
@@ -601,7 +601,7 @@ S3VPreInit(ScrnInfoPtr pScrn, int flags)
 }
 
 /* Process the options */
-if (!(ps3v-Options = xalloc(sizeof(S3VOptions
+if (!(ps3v-Options = malloc(sizeof(S3VOptions
return FALSE;
 memcpy(ps3v-Options, S3VOptions, sizeof(S3VOptions));
 xf86ProcessOptions(pScrn-scrnIndex, pScrn-options, ps3v-Options);
@@ -797,7 +797,7 @@ S3VPreInit(ScrnInfoPtr pScrn, int flags)
 
 #ifndef XSERVER_LIBPCIACCESS
 if (pEnt-resources) {
-   xfree(pEnt);
+   free(pEnt);
S3VFreeRec(pScrn);
return FALSE;
 }
@@ -851,7 +851,7 @@ S3VPreInit(ScrnInfoPtr pScrn, int flags)
 } else {
 ps3v-ChipRev = PCI_DEV_REVISION(ps3v-PciInfo);
 }
-xfree(pEnt);
+free(pEnt);
 
 /*
  * This shouldn't happen because such problems should be caught in
@@ -2526,7 +2526,7 @@ S3VInternalScreenInit( int scrnIndex, ScreenPtr pScreen)
   
   if(ps3v-shadowFB) {
   ps3v-ShadowPitch = BitmapBytePad(pScrn-bitsPerPixel * width);
-  ps3v-ShadowPtr = xalloc(ps3v-ShadowPitch * height);
+  ps3v-ShadowPtr = malloc(ps3v-ShadowPitch * height);
   displayWidth = ps3v-ShadowPitch / (pScrn-bitsPerPixel  3);
   FBStart = ps3v-ShadowPtr;
   } else {
@@ -3310,7 +3310,7 @@ S3VCloseScreen(int scrnIndex, ScreenPtr pScreen)
   if (ps3v-AccelInfoRec)
 XAADestroyInfoRec(ps3v-AccelInfoRec);
   if (ps3v-DGAModes)
-   xfree(ps3v-DGAModes);
+   free(ps3v-DGAModes);
 
   pScrn-vtSema = FALSE;
 
diff --git a/src/s3v_xv.c b/src/s3v_xv.c
index 7e7c243..cc836d4 100644
--- a/src/s3v_xv.c
+++ b/src/s3v_xv.c
@@ -137,7 +137,7 @@ void S3VInitVideo(ScreenPtr pScreen)
adaptors = newAdaptor;
} else {
newAdaptors =  /* need to free this someplace */
-   xalloc((num_adaptors + 1) * sizeof(XF86VideoAdaptorPtr*));
+   malloc((num_adaptors + 1) * sizeof(XF86VideoAdaptorPtr*));
if(newAdaptors) {
memcpy(newAdaptors, adaptors, num_adaptors * 
sizeof(XF86VideoAdaptorPtr));
@@ -152,7 +152,7 @@ void S3VInitVideo(ScreenPtr pScreen)
 xf86XVScreenInit(pScreen, adaptors, num_adaptors);
 
 if(newAdaptors)
-   xfree(newAdaptors);
+   free(newAdaptors);
 }
 
 /* client libraries expect an encoding */
@@ -301,10 +301,10 @@ S3VAllocAdaptor(ScrnInfoPtr pScrn)
 if(!(adapt = xf86XVAllocateVideoAdaptorRec(pScrn)))
return NULL;
 
-if(!(pPriv = xcalloc(1, sizeof(S3VPortPrivRec)  + 
+if(!(pPriv = calloc(1, sizeof(S3VPortPrivRec

Re: [PATCH edid-decode 1/3] Do the EDID version parsing before anything else

2011-12-21 Thread Tormod Volden
On Wed, Dec 21, 2011 at 10:23 AM, walter harms wha...@bfs.de wrote:


 Am 20.12.2011 22:17, schrieb Tormod Volden:
 From: Tormod Volden debian.tor...@gmail.com

 So that the version conformance flags can be used in other code.

 Signed-off-by: Tormod Volden debian.tor...@gmail.com
 ---
  edid-decode.c |   38 +++---
  1 files changed, 19 insertions(+), 19 deletions(-)

 diff --git a/edid-decode.c b/edid-decode.c
 index ab4bde8..c3e556f 100644
 --- a/edid-decode.c
 +++ b/edid-decode.c
 @@ -944,6 +944,25 @@ int main(int argc, char **argv)
       // return 1;
      }

 +    printf(EDID version: %hd.%hd\n, edid[0x12], edid[0x13]);
 +    if (edid[0x12] == 1) {
 +     if (edid[0x13]  4) {
 +         printf(Claims  1.4, assuming 1.4 conformance\n);
 +         edid[0x13] = 4;
 +     }

 I have  learned that changing the original data can lead to
 fatal consequences later on. It may not a problem now but could
 you store edid[0x13] in revesion_id or so ?
 That would improve readability and keep the data in the original state.


 +     switch (edid[0x13]) {
 +     case 4:
 +         claims_one_point_four = 1;
 +     case 3:
 +         claims_one_point_three = 1;
 +     case 2:
 +         claims_one_point_two = 1;
 +     default:
 +         break;
 +     }
 +     claims_one_point_oh = 1;
 +    }
 +

 Is the fall thou intended here ? If yes a small comment would help.
 re,
  wh


Hi Walter,

Good points, but I should maybe have been more clear about it: This
patch just moves a block of code, I am not changing it at all.

I will consider your comments for later patches.

Thanks,
Tormod
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


[PATCH edid-decode 1/3] Do the EDID version parsing before anything else

2011-12-20 Thread Tormod Volden
From: Tormod Volden debian.tor...@gmail.com

So that the version conformance flags can be used in other code.

Signed-off-by: Tormod Volden debian.tor...@gmail.com
---
 edid-decode.c |   38 +++---
 1 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/edid-decode.c b/edid-decode.c
index ab4bde8..c3e556f 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -944,6 +944,25 @@ int main(int argc, char **argv)
// return 1;
 }
 
+printf(EDID version: %hd.%hd\n, edid[0x12], edid[0x13]);
+if (edid[0x12] == 1) {
+   if (edid[0x13]  4) {
+   printf(Claims  1.4, assuming 1.4 conformance\n);
+   edid[0x13] = 4;
+   }
+   switch (edid[0x13]) {
+   case 4:
+   claims_one_point_four = 1;
+   case 3:
+   claims_one_point_three = 1;
+   case 2:
+   claims_one_point_two = 1;
+   default:
+   break;
+   }
+   claims_one_point_oh = 1;
+}
+
 printf(Manufacturer: %s Model %x Serial Number %u\n,
manufacturer_name(edid + 0x08),
(unsigned short)(edid[0x0A] + (edid[0x0B]  8)),
@@ -967,25 +986,6 @@ int main(int argc, char **argv)
}
 }
 
-printf(EDID version: %hd.%hd\n, edid[0x12], edid[0x13]);
-if (edid[0x12] == 1) {
-   if (edid[0x13]  4) {
-   printf(Claims  1.4, assuming 1.4 conformance\n);
-   edid[0x13] = 4;
-   }
-   switch (edid[0x13]) {
-   case 4:
-   claims_one_point_four = 1;
-   case 3:
-   claims_one_point_three = 1;
-   case 2:
-   claims_one_point_two = 1;
-   default:
-   break;
-   }
-   claims_one_point_oh = 1;
-}
-
 /* display section */
 
 if (edid[0x14]  0x80) {
-- 
1.7.5.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


[PATCH edid-decode 2/3 v2] Fix manufacture/model week/year parsing

2011-12-20 Thread Tormod Volden
From: Tormod Volden debian.tor...@gmail.com

For instance, the handling of week=0xff or week=0 was not working,
as could be seen from the data/sharp-* examples.

Only EDID version 1.4 requires the year to be 2006 or later.

Actually, data/sharp-aquos-hdmi reports 1.3 but seems to use month
0xff to flag model year, which is a 1.4 feature. In this case
we will display model year, but report non-conformance.

Signed-off-by: Tormod Volden debian.tor...@gmail.com
---
 edid-decode.c |   22 +++---
 1 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/edid-decode.c b/edid-decode.c
index c3e556f..3244ae1 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -972,18 +972,18 @@ int main(int argc, char **argv)
 
 time(the_time);
 ptm = localtime(the_time);
-if (edid[0x10]  55 || edid[0x10] == 0xff) {
+if (edid[0x10]  0x37 || (edid[0x10] == 0xff  claims_one_point_four))
has_valid_week = 1;
-   if (edid[0x11]  0x0f) {
-   if (edid[0x10] == 0xff) {
-   has_valid_year = 1;
-   printf(Made week %hd of model year %hd\n, edid[0x10],
-  edid[0x11]);
-   } else if (edid[0x11] + 90 = ptm-tm_year) {
-   has_valid_year = 1;
-   printf(Made week %hd of %hd\n, edid[0x10], edid[0x11] + 1990);
-   }
-   }
+if (edid[0x11] + 90 = ptm-tm_year) {
+   /* Year must be 2006 or later from EDID version 1.4 */
+   if (edid[0x11]  0x0f || !claims_one_point_four)
+   has_valid_year = 1;
+   if (edid[0x10] == 0xff)
+   printf(Model year %hd\n, edid[0x11] + 1990);
+   else if (edid[0x10] == 0)
+   printf(Manufactured year %hd\n, edid[0x11] + 1990);
+   else
+   printf(Manufactured week %hd of %hd\n, edid[0x10], edid[0x11] + 
1990);
 }
 
 /* display section */
-- 
1.7.5.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


[PATCH edid-decode 3/3] Adjust broken header warning message

2011-12-20 Thread Tormod Volden
From: Tormod Volden debian.tor...@gmail.com

Do not check edid pointer since it was already done.

Remove commented return statement.

Also separate declaration from code, which fixes remaining
gcc -pedantic warnings.

Signed-off-by: Tormod Volden debian.tor...@gmail.com
---
 edid-decode.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/edid-decode.c b/edid-decode.c
index 3244ae1..f2b416e 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -939,9 +939,8 @@ int main(int argc, char **argv)
 
 dump_breakdown(edid);
 
-if (!edid || memcmp(edid, \x00\xFF\xFF\xFF\xFF\xFF\xFF\x00, 8)) {
-   printf(No header found\n);
-   // return 1;
+if (memcmp(edid, \x00\xFF\xFF\xFF\xFF\xFF\xFF\x00, 8)) {
+   printf(No valid header found\n);
 }
 
 printf(EDID version: %hd.%hd\n, edid[0x12], edid[0x13]);
@@ -1021,9 +1020,10 @@ int main(int argc, char **argv)
if (!nonconformant_digital_display)
nonconformant_digital_display = edid[0x14]  conformance_mask;
 } else {
-   analog = 1;
int voltage = (edid[0x14]  0x60)  5;
int sync = (edid[0x14]  0x0F);
+
+   analog = 1;
printf(Analog display, Input voltage level: %s V\n,
   voltage == 3 ? 0.7/0.7 :
   voltage == 2 ? 1.0/0.4 :
-- 
1.7.5.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


Re: [PATCH edid-decode v2] Fix manufacture/model week/year parsing

2011-12-19 Thread Tormod Volden
On Mon, Dec 19, 2011 at 1:45 AM, Jeremy Huddleston jerem...@apple.com wrote:
 lazyCan you please link the EDID specification, I just looked on wikipedia 
 which is not quite authoritative/lazy

Yes, I even edited Wikipedia the last time to correct the year
encoding :) BTW,
http://en.wikipedia.org/wiki/Extended_display_identification_data only
explains 1.3 in detail. I found the 1.3 spec through that wiki page
and the 1.4 verification guide by googling, but I am not sure the
locations are meant/allowed to be public so I will not link to them.
The file names are E-EDID%20Standard.pdf and EEDIDverifGuideRa.pdf


 The changes look logical to me assuming the fields represent the values I 
 think they do (based on wikipedia).  Still, I'm confused about this  2006 
 issue.  Is that somewhere in the spec?

Yes, see section 3.2.4 of the latter document (table 3-4). Values
0-0x0F (1990-2005) are reserved (do not use).

 What if firmware updates cause the display to support EDID v1.4 but it was 
 manufactured in 2005?

I think the authors of the spec did not think about that possibility
:) But in practice, are there any monitors manufactured before 2006
that receive firmware updates?


 To check for 1.4, you should change edid[0x13]  4 to (edid[0x12] == 1  
 edid[0x13]  4) ... your existing check would not work for EDID version 2.0.

Yes, this was sloppy coding. Anyway, to do this properly I think there
is no way around moving the EDID version parsing above the year/week
parsing, and then use the claims_one_point_four that will be defined.
I think it is logic to evaluate the EDID version as soon as possible,
and certainly before any fields which might depend on the version. I
will submit a patch for the rearrangement and hope nobody will
protest, and rebase this patch as a follow-up.

Cheers,
Tormod



 If you change the 1.4 check (and that matches the spec), or if you remove the 
 1.4 check,

 Reviewed-by: Jeremy Huddleston jerem...@apple.com

 On Dec 17, 2011, at 15:24, Tormod Volden wrote:

 From: Tormod Volden debian.tor...@gmail.com

 For instance, the handling of week=0xff or week=0 was not working,
 as could be seen from the data/sharp-* examples.

 Only EDID version 1.4 requires the year to be 2006 or later.

 Signed-off-by: Tormod Volden debian.tor...@gmail.com
 ---

 v2: We should not require year = 2006 if version  1.4.

 This can be made prettier if we do the EDID version
 parsing before the week and year parsing, but I will leave it like
 this for now.

 Tormod


 edid-decode.c |   22 +++---
 1 files changed, 11 insertions(+), 11 deletions(-)

 diff --git a/edid-decode.c b/edid-decode.c
 index ab4bde8..9c89528 100644
 --- a/edid-decode.c
 +++ b/edid-decode.c
 @@ -953,18 +953,18 @@ int main(int argc, char **argv)

     time(the_time);
     ptm = localtime(the_time);
 -    if (edid[0x10]  55 || edid[0x10] == 0xff) {
 +    if (edid[0x10]  0x37 || edid[0x10] == 0xff)
       has_valid_week = 1;
 -     if (edid[0x11]  0x0f) {
 -         if (edid[0x10] == 0xff) {
 -             has_valid_year = 1;
 -             printf(Made week %hd of model year %hd\n, edid[0x10],
 -                    edid[0x11]);
 -         } else if (edid[0x11] + 90 = ptm-tm_year) {
 -             has_valid_year = 1;
 -             printf(Made week %hd of %hd\n, edid[0x10], edid[0x11] + 
 1990);
 -         }
 -     }
 +    if (edid[0x11] + 90 = ptm-tm_year) {
 +     /* Year must be 2006 or later from EDID version 1.4 */
 +     if (edid[0x11]  0x0f || edid[0x13]  4)
 +         has_valid_year = 1;
 +     if (edid[0x10] == 0xff)
 +         printf(Model year %hd\n, edid[0x11] + 1990);
 +     else if (edid[0x10] == 0)
 +         printf(Manufactured year %hd\n, edid[0x11] + 1990);
 +     else
 +         printf(Manufactured week %hd of %hd\n, edid[0x10], edid[0x11] + 
 1990);
     }

     printf(EDID version: %hd.%hd\n, edid[0x12], edid[0x13]);
 --
 1.7.5.4

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel


___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


[PATCH edid-decode] Fix manufacture/model week/year parsing

2011-12-17 Thread Tormod Volden
From: Tormod Volden debian.tor...@gmail.com

For instance, the handling of week=0xff or week=0 was not working,
as could be seen from by the data/sharp-* examples.

Signed-off-by: Tormod Volden debian.tor...@gmail.com
---
 edid-decode.c |   20 +---
 1 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/edid-decode.c b/edid-decode.c
index ab4bde8..fe1f4f5 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -953,18 +953,16 @@ int main(int argc, char **argv)
 
 time(the_time);
 ptm = localtime(the_time);
-if (edid[0x10]  55 || edid[0x10] == 0xff) {
+if (edid[0x10]  0x37 || edid[0x10] == 0xff)
has_valid_week = 1;
-   if (edid[0x11]  0x0f) {
-   if (edid[0x10] == 0xff) {
-   has_valid_year = 1;
-   printf(Made week %hd of model year %hd\n, edid[0x10],
-  edid[0x11]);
-   } else if (edid[0x11] + 90 = ptm-tm_year) {
-   has_valid_year = 1;
-   printf(Made week %hd of %hd\n, edid[0x10], edid[0x11] + 1990);
-   }
-   }
+if (edid[0x11]  0x0f  edid[0x11] + 90 = ptm-tm_year) {
+   has_valid_year = 1;
+   if (edid[0x10] == 0xff)
+   printf(Model year %hd\n, edid[0x11] + 1990);
+   else if (edid[0x10] == 0)
+   printf(Manufactured year %hd\n, edid[0x11] + 1990);
+   else
+   printf(Manufactured week %hd of %hd\n, edid[0x10], edid[0x11] + 
1990);
 }
 
 printf(EDID version: %hd.%hd\n, edid[0x12], edid[0x13]);
-- 
1.7.5.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


[PATCH savage 1/2] Do not use the deprecated xf86PciInfo.h from xserver

2011-12-04 Thread Tormod Volden
From: Tormod Volden debian.tor...@gmail.com

Instead maintain our own list of supported PCI IDs.

Signed-off-by: Tormod Volden debian.tor...@gmail.com
---
 src/savage_dri.c|1 -
 src/savage_driver.c |1 +
 src/savage_driver.h |1 -
 src/savage_hwmc.c   |1 -
 src/savage_i2c.c|5 
 src/savage_pciids.h |   55 +++
 6 files changed, 56 insertions(+), 8 deletions(-)
 create mode 100644 src/savage_pciids.h

diff --git a/src/savage_dri.c b/src/savage_dri.c
index 8750925..d839226 100644
--- a/src/savage_dri.c
+++ b/src/savage_dri.c
@@ -35,7 +35,6 @@
 #include xaalocal.h
 #include xaarop.h
 
-#include xf86PciInfo.h
 #include xf86Pci.h
 #include xf86fbman.h
 
diff --git a/src/savage_driver.c b/src/savage_driver.c
index 2b47c1d..5324fca 100644
--- a/src/savage_driver.c
+++ b/src/savage_driver.c
@@ -56,6 +56,7 @@
 #include xf86xv.h
 
 #include savage_driver.h
+#include savage_pciids.h
 #include savage_regs.h
 #include savage_bci.h
 #include savage_streams.h
diff --git a/src/savage_driver.h b/src/savage_driver.h
index 1737362..6c6dda8 100644
--- a/src/savage_driver.h
+++ b/src/savage_driver.h
@@ -55,7 +55,6 @@
 #include xf86Resources.h
 #endif
 #include xf86Pci.h
-#include xf86PciInfo.h
 #include xf86_OSproc.h
 #include xf86Cursor.h
 #include mipointer.h
diff --git a/src/savage_hwmc.c b/src/savage_hwmc.c
index 905ef87..ed881b4 100644
--- a/src/savage_hwmc.c
+++ b/src/savage_hwmc.c
@@ -29,7 +29,6 @@
 #include xf86.h
 #include xf86_OSproc.h
 #include compiler.h
-#include xf86PciInfo.h
 #include xf86Pci.h
 #include xf86fbman.h
 #include regionstr.h
diff --git a/src/savage_i2c.c b/src/savage_i2c.c
index d8eb46b..b5739a2 100644
--- a/src/savage_i2c.c
+++ b/src/savage_i2c.c
@@ -32,11 +32,6 @@ in this Software without prior written authorization from 
the XFree86 Project.
 #include xf86_OSproc.h
 #include compiler.h
 
-#include xf86Pci.h
-#include xf86PciInfo.h
-
-#include vgaHW.h
-
 #include savage_driver.h
 
 static void
diff --git a/src/savage_pciids.h b/src/savage_pciids.h
new file mode 100644
index 000..cad5172
--- /dev/null
+++ b/src/savage_pciids.h
@@ -0,0 +1,55 @@
+/*
+ * Copyright 2011 X.Org Foundation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL THE
+ * COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Except as contained in this notice, the name of the copyright holder(s)
+ * and author(s) shall not be used in advertising or otherwise to promote
+ * the sale, use or other dealings in this Software without prior written
+ * authorization from the copyright holder(s) and author(s).
+ */
+
+#ifndef SAVAGE_PCIIDS_H
+#define SAVAGE_PCIIDS_H
+
+#define PCI_CHIP_SAVAGE3D  0x8A20
+#define PCI_CHIP_SAVAGE3D_MV   0x8A21
+#define PCI_CHIP_SAVAGE4   0x8A22
+#define PCI_CHIP_PROSAVAGE_PM  0x8A25
+#define PCI_CHIP_PROSAVAGE_KM  0x8A26
+#define PCI_CHIP_SAVAGE_MX_MV  0x8C10
+#define PCI_CHIP_SAVAGE_MX 0x8C11
+#define PCI_CHIP_SAVAGE_IX_MV  0x8C12
+#define PCI_CHIP_SAVAGE_IX 0x8C13
+#define PCI_CHIP_SUPSAV_MX128  0x8C22
+#define PCI_CHIP_SUPSAV_MX64   0x8C24
+#define PCI_CHIP_SUPSAV_MX64C  0x8C26
+#define PCI_CHIP_SUPSAV_IX128SDR   0x8C2A
+#define PCI_CHIP_SUPSAV_IX128DDR   0x8C2B
+#define PCI_CHIP_SUPSAV_IX64SDR0x8C2C
+#define PCI_CHIP_SUPSAV_IX64DDR0x8C2D
+#define PCI_CHIP_SUPSAV_IXCSDR 0x8C2E
+#define PCI_CHIP_SUPSAV_IXCDDR 0x8C2F
+#define PCI_CHIP_S3TWISTER_P   0x8D01
+#define PCI_CHIP_S3TWISTER_K   0x8D02
+#define PCI_CHIP_PROSAVAGE_DDR 0x8D03
+#define PCI_CHIP_PROSAVAGE_DDRK0x8D04
+#define PCI_CHIP_SAVAGE20000x9102
+
+#endif /* SAVAGE_PCIIDS_H */
-- 
1.7.5.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


s3switch maintenance

2011-11-10 Thread Tormod Volden
[s3switch is a tool for switching outputs on S3 Savage cards]

Hi,
Due to popular request, I would like to revive the s3switch tool and
maintain it. It is still shipped in Fedora, based on a patch set from
Debian and a couple of additional patches, but meanwhile it has
ironically been dropped from Debian. To make it easier for everybody,
I would like to set up a new upstream for it. I am also maintaining
the related xorg savage driver*.

So I have set up a git repo and applied the patches I could find in
Debian and Fedora:
 http://cgit.freedesktop.org/~tormod/s3switch
I have faked the git history in order to give due credit as far as I
could, digging through package changelogs and patch descriptions.
Please tell me if there is something you are not happy about, I can
still rebase it.

xorg-devel: Maybe I should directly make an own project/module for it,
to not host it in a private repo? It is a bit like radeontool and
similar.
Guido: I am willing to maintain it in Debian (and host it in
collab-maint or pkg-xorg), maybe you can help with some paperwork?
Tim: Did you think people would ask for this, 10 years after? :)

Best regards,
Tormod

*) Ideally this tools' functionality should be available through
xrandr. But it would require porting the DDX to xrandr 1.2 which I
think nobody wants to do. Patches would be welcome though! So for now
it is easier to keep s3switch alive instead.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


Re: [PATCH sis 00/15] a bunch of cleanups, and a taste of things to come

2011-10-30 Thread Tormod Volden
On Wed, Apr 27, 2011 at 10:59 PM, TImo Aaltonen tjaal...@ubuntu.com wrote:
 On 13.04.2011 18:22, TImo Aaltonen wrote:
 On 06.04.2011 19:50, Timo Aaltonen wrote:
 Here's a first set of patches to xf86-video-sis, hoping to narrow down
 the diff against Thomas Winischofer's 'sisfree' (*) package and the
 forked versions from Intel and SiS (and Mandriva).

 The first 13 are more or less self-explanatory, but the two final ones
 are moving things around to make the code more readable, among other things.

 Every commit is build-tested against xserver 1.10 headers.

 * http://www.winischhofer.net/linuxsispart4.shtml#download

 Timo Aaltonen (15):
   Write out remaining IS_SIS* macros.
   Replace deprecated x(c)alloc/xfree with m/calloc/free
   Fix format not a string literal and no format arguments compile
     warnings
   Fix suggest parentheses around operand of ‘!’ compiler warnings.
   Fix compile warnings of uninitialized variables
   Declare mmioFlags only if XSERVER_LIBPCIACCESS isn't defined
   Purge obsolete and unused SIS_CP checks
   Drop useless checks and relevant code for old XFree86 releases
   Drop unused and non-working XAA trapezoid support for 310 series and
     later
   Remove unused code from sis_video.c
   Remove unused code from SISPutImageBlit()
   Remove unused  non-working Xv deinterlacer code
   Remove deprecated XV SD interface
   Move configurable values from sis.h to sis_config.h
   Move all TV related functions fron sis_driver.c to sis_vb.c

  src/init.c          |   35 +-
  src/init.h          |    3 -
  src/init301.c       |   62 +-
  src/init301.h       |    3 -
  src/initdef.h       |   19 +-
  src/initextx.c      |   18 +-
  src/sis.h           |   86 +--
  src/sis310_accel.c  |  754 ---
  src/sis6326_video.c |   60 +--
  src/sis_accel.c     |  128 ---
  src/sis_config.h    |   71 ++
  src/sis_cursor.c    |    8 +-
  src/sis_dac.h       |    2 +
  src/sis_dga.c       |    6 +-
  src/sis_dri.c       |   38 +-
  src/sis_driver.c    | 2625 
 ---
  src/sis_driver.h    |  813 +
  src/sis_memcpy.c    |   10 +-
  src/sis_opt.c       |   49 +-
  src/sis_utility.c   |  527 +--
  src/sis_vb.c        | 2259 ++--
  src/sis_vb.h        |  931 ++
  src/sis_vga.c       |    7 +-
  src/sis_video.c     |  291 +--
  src/sis_video.h     |  195 
  src/sis_videostr.h  |    3 -
  src/vgatypes.h      |    5 -
  27 files changed, 3490 insertions(+), 5518 deletions(-)
  create mode 100644 src/sis_config.h
  create mode 100644 src/sis_vb.h


 Ping? Patch 04/15 got reviewed, but the rest are still waiting for input.

 And another ping.

 Patch 03 is apparently controversial, I could drop it from the series..


What about this patch series? If no one wants to review it, let's give
Timo free hands on it. Since April, other people have been reinventing
some of these patches, which is kind of stupid.

Timo, you are still interested in having this applied and willing to
fix up any reported regressions, right? Do you have it in a public
tree somewhere?

Regards,
Tormod
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


Re: [PATCH] pci: Add identifier for Cirus Logic GD-7556

2011-10-29 Thread Tormod Volden
On Mon, Oct 17, 2011 at 10:53 AM, Jeremy Huddleston jerem...@apple.com wrote:
 So, what's the point of having all these in common?  Why don't they just live 
 in the drivers?  It seems silly to have these defined in the server's SDK 
 rather than the driver that will consume them, since it means the driver will 
 need to do

 #ifndef PCI_CHIP_GD7556
 #define PCI_CHIP_GD7556 0x004C
 #endif

 if it wants to work on older servers without the change ...

Yes, should we move this to the drivers and make them stop including
xf86PciInfo.h? Are the PCI_CHIP_ macros used by anything else than the
drivers, or can they be taken out as soon as drivers are updated? The
server itself is not using them, according to git grep. I will follow
up with a radeon patch, it currently has a mix of both, and see how
that is received.

The #ifndef dance it not necessary on gcc at least, as long as a
redefine uses the same value.

Tormod



 On Oct 17, 2011, at 1:48 AM, Jeremy Huddleston wrote:


 https://bugs.freedesktop.org/show_bug.cgi?id=1837

 Signed-off-by: Jeremy Huddleston jerem...@apple.com
 ---
 hw/xfree86/common/xf86PciInfo.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

 diff --git a/hw/xfree86/common/xf86PciInfo.h 
 b/hw/xfree86/common/xf86PciInfo.h
 index 356c7db..2825ece 100644
 --- a/hw/xfree86/common/xf86PciInfo.h
 +++ b/hw/xfree86/common/xf86PciInfo.h
 @@ -386,6 +386,7 @@
 /* Cirrus Logic */
 #define PCI_CHIP_GD7548                       0x0038
 #define PCI_CHIP_GD7555                       0x0040
 +#define PCI_CHIP_GD7556                      0x004C
 #define PCI_CHIP_GD5430                       0x00A0
 #define PCI_CHIP_GD5434_4             0x00A4
 #define PCI_CHIP_GD5434_8             0x00A8
 --
 1.7.6.1


 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel



 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


[PATCH] radeon: do not include xf86PciInfo.h

2011-10-29 Thread Tormod Volden
From: Tormod Volden debian.tor...@gmail.com

We already use atipciids.h instead most places.

Signed-off-by: Tormod Volden debian.tor...@gmail.com

---

Actually, the PCI_VENDOR_ macros could better be maintained in a central
location, but I just added the one missing here for now.

Tormod

 src/ati.c |1 +
 src/ati.h |1 -
 src/atipciids.h   |1 +
 src/radeon_bios.c |2 +-
 src/radeon_dri.c  |1 -
 5 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/ati.c b/src/ati.c
index ea71e88..e1c136f 100644
--- a/src/ati.c
+++ b/src/ati.c
@@ -63,6 +63,7 @@
 #include atipcirename.h
 
 #include ati.h
+#include atipciids.h
 #include ativersion.h
 
 /* names duplicated from version headers */
diff --git a/src/ati.h b/src/ati.h
index 86c40a1..b7120d9 100644
--- a/src/ati.h
+++ b/src/ati.h
@@ -26,7 +26,6 @@
 #include unistd.h
 #include stdint.h
 #include xf86Pci.h
-#include xf86PciInfo.h
 
 #include xf86.h
 
diff --git a/src/atipciids.h b/src/atipciids.h
index 5f66aa0..04b5960 100644
--- a/src/atipciids.h
+++ b/src/atipciids.h
@@ -44,6 +44,7 @@
 #ifndef PCI_VENDOR_HP
 #define PCI_VENDOR_HP  0x103c
 #endif
+#define PCI_VENDOR_SONY0x104D
 
 #include ati_pciids_gen.h
 
diff --git a/src/radeon_bios.c b/src/radeon_bios.c
index b53a0ed..5f12534 100644
--- a/src/radeon_bios.c
+++ b/src/radeon_bios.c
@@ -34,7 +34,7 @@
 #include xf86.h
 #include xf86_OSproc.h
 
-#include xf86PciInfo.h
+#include atipciids.h
 #include radeon.h
 #include radeon_reg.h
 #include radeon_macros.h
diff --git a/src/radeon_dri.c b/src/radeon_dri.c
index 07f127c..f1ae65e 100644
--- a/src/radeon_dri.c
+++ b/src/radeon_dri.c
@@ -54,7 +54,6 @@
 
/* X and server generic header files */
 #include xf86.h
-#include xf86PciInfo.h
 #include windowstr.h
 
/* GLX/DRI/DRM definitions */
-- 
1.7.5.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


Re: [PATCH] pci: Add identifier for Cirus Logic GD-7556

2011-10-29 Thread Tormod Volden
On Sun, Oct 30, 2011 at 12:12 AM, Jeremy Huddleston jerem...@apple.com wrote:

 On Oct 29, 2011, at 14:01, Tormod Volden wrote:

 On Mon, Oct 17, 2011 at 10:53 AM, Jeremy Huddleston jerem...@apple.com 
 wrote:
 So, what's the point of having all these in common?  Why don't they just 
 live in the drivers?  It seems silly to have these defined in the server's 
 SDK rather than the driver that will consume them, since it means the 
 driver will need to do

 #ifndef PCI_CHIP_GD7556
 #define PCI_CHIP_GD7556 0x004C
 #endif

 if it wants to work on older servers without the change ...

 Yes, should we move this to the drivers and make them stop including
 xf86PciInfo.h? Are the PCI_CHIP_ macros used by anything else than the
 drivers, or can they be taken out as soon as drivers are updated? The
 server itself is not using them, according to git grep. I will follow
 up with a radeon patch, it currently has a mix of both, and see how
 that is received.

 The #ifndef dance it not necessary on gcc at least, as long as a
 redefine uses the same value.

 This is complicated by the fact that we probably want older drivers to 
 continue to build against the newer server ... so maybe we can put a #warning 
 in xf86PciInfo.h that it will be removed in xorg-server-1.13 or later and 
 start migrating them to the drivers instead.  What do you think about that?


I see it as most important that newer drivers can be built against
older servers. Usually you will have server changes that force driver
updates. But sure, we can leave the macros in the server for a while
after a driver has copied them and the following driver release. You
mean a warning that appears while compiling drivers? Sounds good.
Regarding my comment in the radeon patch, what do you think about the
VENDOR macros?

Cheers,
Tormod
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


Re: PATCH v4 Document -background none option

2011-10-13 Thread Tormod Volden
On Thu, Oct 13, 2011 at 10:55 PM, Michal Suchanek wrote:
 v3: reword based in input from Alan Coopersmith

To nitpick on the nitpicking (at the risk of bikeshedding):
+Asks the driver not to clear the background on startup, if the driver
supports that.

The other option descriptions start with lower case (- asks). I would
also avoid that - it or:
+asks the driver not to clear the background on startup (if supported by driver)

Although asks (as opposed to tells) already implies that the
driver might not honor it.

Cheers,
Tormod
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


Re: [PATCH xserver] check for elevated privileges not uid=0

2011-10-11 Thread Tormod Volden
On Mon, Oct 10, 2011 at 9:04 PM, Antoine Martin wrote:
 And another blooper, sorry for the spam. Correct patch attached.
 Need sleep, will pick this up tomorrow.

Subject: [PATCH xserver] check for elevated privileges not uid=0 (V3)

 Couldn't find any reference to it, so I just removed it.

To avoid confusion, you should version your patches. What I said was
to put the version inside the bracketed part. And if your code changes
are limited to the hw/xfree86 tree, you might add xfree86 as a prefix.
Just as a suggestion, feel free to rephrase:

Subject: [PATCH v3] xfree86: Check for elevated privileges instead of
just uid==0

+  /* XXX ouch, coudn't get back to original uid
+what can we do ??? */

You do not need a comment if you have an explaining error message.
Otherwise, comments should also be properly spelled and reflect the
quality of the code.

Cheers,
Tormod
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


Re: [PATCH xserver] check for elevated privileges not uid=0 (V2)

2011-10-10 Thread Tormod Volden
On Mon, Oct 10, 2011 at 6:43 PM, Antoine Martin wrote:
 I have been using this patch for days without any visible side effects.
 Can I please get some reviewed-by / acks?


Any functional issues aside, your patch will need some style polishing
before it can get any rubber stamps:

 Subject: [PATCH xserver] check for elevated privileges not uid=0 (V3)

First, the V3 in the subject should be inside the []'s to not be
included in the commit message. Check other commits to see if there is
a common practice of capitalization or module or section prefix in
this line if you really want to please.

+static Bool privsTested = FALSE;
+static Bool privsElevated = FALSE;
+Bool xf86PrivsElevated(void)

You must have messed up from V2 to V3 because the variables ended
outside the function again. Note that in V2 there was missing a blank
line after the variable declarations.

+  uid_t ruid, euid, suid;
+  gid_t rgid, egid, sgid;
+  if ((getresuid(ruid, euid, suid) == 0) 

Missing blank line again.

+   */
+  unsigned int oldeuid;
+  oldeuid = geteuid();

And again.

+  (getresgid(rgid, egid, sgid) == 0))
+privsElevated = (euid != suid) || (egid != sgid);
+#else
+  /*
+   * If there are saved ID's the process might still be priviledged

privileged

+   * even though the above test succeeded.  If issetugid() and

I also consider double space after period a typographical mistake, but
I am not gonna run a crusade here :)

+if (seteuid(0) != 0) {
+  privsElevated = FALSE;

You use != 0 to check for failure here...

+} else {
+  if (seteuid(oldeuid) == -1) {

... but == -1 here. Is there any reason for not being consistent?

+/* XXX ouch, coudn't get back to original uid
+   what can we do ??? */

If we get to this point, the code in the patch has failed. It should
apologize deeply and offer your phone number for technical support :)
Seriously, it should print an internal error message of some kind,
maybe including __function__. Just quitting silently and leave a
cryptic 127 that might or not propagate to the user does not cut it.

+_exit(127);

Why do you use _exit() and not exit() here? This is not e.g. a forked
child that should escape normal clean-up?

Best regards,
Tormod
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


Re: [PATCH xserver] check for elevated privileges rather than just euid=0

2011-10-06 Thread Tormod Volden
On Thu, Oct 6, 2011 at 3:05 PM, Antoine Martin wrote:
 This allows us to run the server as a normal user whilst still
 being able to use the -modulepath, -logfile and -config switches
 We define a xf86PrivsElevated which will do the checks and cache
 the result in case it is called more than once.
 Also renamed the paths #defines to match their new meaning.
 Original discussion which led to this patch can be found here:
 http://lists.freedesktop.org/archives/xorg-devel/2011-September/025853.html

 Signed-off-by: antoine anto...@nagafix.co.uk

+static Bool privsTested = FALSE;
+static Bool privsElevated = FALSE;
+Bool xf86PrivsElevated(void)
+{

You probably want to move these variables inside the function since
they are not (and should not be) used outside it.

Regards,
Tormod
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


Re: [PATCH] savage: Fix Xv scaling on non-native resolutions

2011-09-18 Thread Tormod Volden
On Sat, Sep 17, 2011 at 5:52 PM, Matt Turner wrote:

 I don't know the hardware or Xv, but the changes look reasonable.
 There are enough changes in -savage since the last release to warrant
 a new one. Once this lands, let's do a new -savage release.

Yes, that is my plan. There is a couple of useful bug fixes there now.
I am just trying to add a upgrade-your-kernel warning in case of
broken DRI, which I would like to include in the release.

Cheers,
Tormod
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


[PATCH] savage: Warn if broken drm maps are detected

2011-09-18 Thread Tormod Volden
From: Tormod Volden debian.tor...@gmail.com

Linux kernel 2.6.30 - 2.6.39 had broken drm maps which would result
in assorted problems. Leave a message in the log if it looks like
the framebuffer map and the aperture map are mixed up.

https://bugs.freedesktop.org/show_bug.cgi?id=32511

Signed-off-by: Tormod Volden debian.tor...@gmail.com

---
 src/savage_dri.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/src/savage_dri.c b/src/savage_dri.c
index 69563bd..8750925 100644
--- a/src/savage_dri.c
+++ b/src/savage_dri.c
@@ -1070,6 +1070,11 @@ Bool SAVAGEDRIScreenInit( ScreenPtr pScreen )
   return FALSE;
}
 
+   /* Linux kernel DRM broken in 2.6.30 through 2.6.39 */
+   if (pDRIInfo-hFrameBuffer == pSAVAGEDRIServer-aperture.handle)
+   xf86DrvMsg( pScrn-scrnIndex, X_WARNING,
+  [drm] Detected broken drm maps. Please upgrade to linux 
kernel 3.x\n);
+
if ( !SAVAGEDRIBuffersInit( pScreen ) ) {
   SAVAGEDRICloseScreen( pScreen );
   return FALSE;
-- 
1.7.5.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


[PATCH] savage: Fix Xv scaling on non-native resolutions

2011-09-17 Thread Tormod Volden
From: Hans-Juergen Mauser hjmau...@gmx.net

If I set the resolution to 800x600 for example (to be able to use the
TV output in full screen mode), I only can see 800/1024 = 0,78 of the
real video width, no matter if the video is displayed in a small player
window or enlarged to full screen. On the right of the video display,
the remaining width is filled with a black (or sometimes blue) bar.

The problem was mainly that only the drawing starting point was modified
by the scaling factor, but not the size-defining end of the drawing
rectangle.

https://bugs.launchpad.net/bugs/670790

Signed-off-by: Hans-Juergen Mauser hjmau...@gmx.net
Reviewed-by: Tormod Volden debian.tor...@gmail.com
---
 src/savage_video.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/src/savage_video.c b/src/savage_video.c
index 9f860c7..7d571ad 100644
--- a/src/savage_video.c
+++ b/src/savage_video.c
@@ -1508,9 +1508,13 @@ SavageDisplayVideoOld(
 drw_h = (float)(drw_h * psav-YExp1)/(float)psav-YExp2+1;
 dstBox-x1 = (float)(dstBox-x1 * psav-XExp1)/(float)psav-XExp2;
 dstBox-y1 = (float)(dstBox-y1 * psav-YExp1)/(float)psav-YExp2;
+   dstBox-x2 = (dstBox-x2 * psav-XExp1) / psav-XExp2;
+   dstBox-y2 = (dstBox-y2 * psav-YExp1) / psav-YExp2;
 
 dstBox-x1 += psav-displayXoffset;
 dstBox-y1 += psav-displayYoffset;
+   dstBox-x2 += psav-displayXoffset;
+   dstBox-y2 += psav-displayYoffset;
 }
 
 /*
@@ -1668,8 +1672,12 @@ SavageDisplayVideoNew(
drw_h = (drw_h * psav-YExp1)/psav-YExp2 + 1;
dstBox-x1 = (dstBox-x1 * psav-XExp1)/psav-XExp2;
dstBox-y1 = (dstBox-y1 * psav-YExp1)/psav-YExp2;
+   dstBox-x2 = (dstBox-x2 * psav-XExp1) / psav-XExp2;
+   dstBox-y2 = (dstBox-y2 * psav-YExp1) / psav-YExp2;
dstBox-x1 += psav-displayXoffset;
dstBox-y1 += psav-displayYoffset;
+   dstBox-x2 += psav-displayXoffset;
+   dstBox-y2 += psav-displayYoffset;
 }
 
if (psav-IsSecondary) {
-- 
1.7.4.1

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


[PATCH] savage: Avoid unnecessary float calculation in video display

2011-09-17 Thread Tormod Volden
From: Tormod Volden debian.tor...@gmail.com

There is no reason to do the division using floats as long as
the result is an integer and there is no risk of intermediate
overflow.

This is in the code for Old chipsets. Integer division was already
used in the parallel code for New chipsets.

Also fixed up the whitespace in both blocks.

Signed-off-by: Tormod Volden debian.tor...@gmail.com
---
 src/savage_video.c |   23 +++
 1 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/src/savage_video.c b/src/savage_video.c
index 7d571ad..5f08a18 100644
--- a/src/savage_video.c
+++ b/src/savage_video.c
@@ -1503,16 +1503,15 @@ SavageDisplayVideoOld(
   }
 
 if (S3_MOBILE_TWISTER_SERIES(psav-Chipset)
- psav-FPExpansion) {
-drw_w = (((float)(drw_w * psav-XExp1)/(float)psav-XExp2)+1);
-drw_h = (float)(drw_h * psav-YExp1)/(float)psav-YExp2+1;
-dstBox-x1 = (float)(dstBox-x1 * psav-XExp1)/(float)psav-XExp2;
-dstBox-y1 = (float)(dstBox-y1 * psav-YExp1)/(float)psav-YExp2;
+psav-FPExpansion) {
+   drw_w = (drw_w * psav-XExp1) / psav-XExp2 + 1;
+   drw_h = (drw_h * psav-YExp1) / psav-YExp2 + 1;
+   dstBox-x1 = (dstBox-x1 * psav-XExp1) / psav-XExp2;
+   dstBox-y1 = (dstBox-y1 * psav-YExp1) / psav-YExp2;
dstBox-x2 = (dstBox-x2 * psav-XExp1) / psav-XExp2;
dstBox-y2 = (dstBox-y2 * psav-YExp1) / psav-YExp2;
-
-dstBox-x1 += psav-displayXoffset;
-dstBox-y1 += psav-displayYoffset;
+   dstBox-x1 += psav-displayXoffset;
+   dstBox-y1 += psav-displayYoffset;
dstBox-x2 += psav-displayXoffset;
dstBox-y2 += psav-displayYoffset;
 }
@@ -1668,10 +1667,10 @@ SavageDisplayVideoNew(
!psav-CrtOnly 
!psav-TvOn) 
 {
-   drw_w = (drw_w * psav-XExp1)/psav-XExp2 + 1;
-   drw_h = (drw_h * psav-YExp1)/psav-YExp2 + 1;
-   dstBox-x1 = (dstBox-x1 * psav-XExp1)/psav-XExp2;
-   dstBox-y1 = (dstBox-y1 * psav-YExp1)/psav-YExp2;
+   drw_w = (drw_w * psav-XExp1) / psav-XExp2 + 1;
+   drw_h = (drw_h * psav-YExp1) / psav-YExp2 + 1;
+   dstBox-x1 = (dstBox-x1 * psav-XExp1) / psav-XExp2;
+   dstBox-y1 = (dstBox-y1 * psav-YExp1) / psav-YExp2;
dstBox-x2 = (dstBox-x2 * psav-XExp1) / psav-XExp2;
dstBox-y2 = (dstBox-y2 * psav-YExp1) / psav-YExp2;
dstBox-x1 += psav-displayXoffset;
-- 
1.7.4.1

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


Re: [PATCH] savage: Avoid unnecessary float calculation in video display

2011-09-17 Thread Tormod Volden
On Sat, Sep 17, 2011 at 1:03 PM, walter harms wrote:
      if (S3_MOBILE_TWISTER_SERIES(psav-Chipset)
 -         psav-FPExpansion) {
 -        drw_w = (((float)(drw_w * psav-XExp1)/(float)psav-XExp2)+1);
 -        drw_h = (float)(drw_h * psav-YExp1)/(float)psav-YExp2+1;
 -        dstBox-x1 = (float)(dstBox-x1 * psav-XExp1)/(float)psav-XExp2;
 -        dstBox-y1 = (float)(dstBox-y1 * psav-YExp1)/(float)psav-YExp2;
 +      psav-FPExpansion) {
 +     drw_w = (drw_w * psav-XExp1) / psav-XExp2 + 1;
 +     drw_h = (drw_h * psav-YExp1) / psav-YExp2 + 1;

 to improve readability i would suggest a writing like this:

        scale=  psav-XExp1/psav-XExp2;
        drw_w = 1+  drw_w *scale ;
        drw_h = 1+  drw_h *scale ;

Hi Walter,

Thanks for your review and comments. Note that the scale is different
for x and y so it would need two scale variables in your example. I
don't want to put too much effort into beautifying the code, just make
the Old and New chipset code path match.


 the price of float is small these days  ...

This driver is not for today's hardware :) Yes, I guess there is no
visible performance win, but it makes the code more consistent and
readable.

Cheers,
Tormod
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


[PATCH] edid-decode: Be explicit about valid checksums

2011-08-29 Thread Tormod Volden
From: Tormod Volden debian.tor...@gmail.com

Also fix some formatting and typos.
---
 edid-decode.c |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/edid-decode.c b/edid-decode.c
index cb6fec2..923556a 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -219,7 +219,7 @@ detailed_block(unsigned char *x, int in_extension)
strncat((char *)name, (char *)x + 5, 13);
if (strchr((char *)name, '\n')) {
name_descriptor_terminated = 1;
-   printf(Monitor name: %s, name);
+   printf(Monitor name: %s , name);
}
return 1;
case 0xFD:
@@ -271,7 +271,7 @@ detailed_block(unsigned char *x, int in_extension)
has_valid_range_descriptor = 0;
if (x[7] + h_min_offset  x[8] + h_max_offset)
has_valid_range_descriptor = 0;
-   printf(Monitor ranges: %d-%dHZ vertical, %d-%dkHz horizontal,
+   printf(Monitor ranges: %d-%dHz vertical, %d-%dkHz horizontal,
   x[5] + v_min_offset, x[6] + v_max_offset,
   x[7] + h_min_offset, x[8] + h_max_offset);
if (x[9])
@@ -359,15 +359,15 @@ detailed_block(unsigned char *x, int in_extension)
}
case 0xFE:
 /*
- * TODO: Two of these in a row, in the third and fouth slots,
+ * TODO: Two of these in a row, in the third and fourth slots,
  * seems to be specified by SPWG: http://www.spwg.org/
  */
/* XXX check: terminated with 0x0A, padded with 0x20 */
-   printf(ASCII string: %s, x+5);
+   printf(ASCII string: %s\n, x+5);
return 1;
case 0xFF:
/* XXX check: terminated with 0x0A, padded with 0x20 */
-   printf(Serial number: %s, x+5);
+   printf(Serial number: %s\n, x+5);
return 1;
default:
printf(Unknown monitor description type %d\n, x[3]);
@@ -435,7 +435,7 @@ do_checksum(unsigned char *x)
if (sum) {
printf( (should be 0x%hx), (unsigned char)(x[0x7f] - sum));
has_valid_checksum = 0;
-   }
+   } else printf( (valid));
 }
 printf(\n);
 }
-- 
1.7.0.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


[PATCH 1/4] savage: Fix logic in waitHSync

2011-04-20 Thread Tormod Volden
From: Tormod Volden debian.tor...@gmail.com

Bit-masking the result of a boolean negation seems pointless,
so I guess this is what was intended: Only look at bit 0 of the
inStatus result.

Signed-off-by: Tormod Volden debian.tor...@gmail.com
---

Hi,

A few savage patches. Review is appreciated.

This one is similar to 3f18b334812086e5f487a4570a34a3906a67724c
savage: Fix ambiguity in SavageLoadPaletteSavage4.

Probably not a very critical fix, but does not seem to break
anything either. I guess there can be a small timing difference,
as it now will wait (as intended) for the whole pulse.

I have gone through the output of git grep '!.*  ' so this
should be the last of this kind.

 src/savage_cursor.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/savage_cursor.c b/src/savage_cursor.c
index 4d193eb..6364293 100644
--- a/src/savage_cursor.c
+++ b/src/savage_cursor.c
@@ -67,8 +67,8 @@ static void SavageSetCursorColors(ScrnInfoPtr pScrn, int bg, 
int fg);
 #define waitHSync(n) { \
int num = n; \
while (num--) { \
-while ((inStatus1())  0x01){};\
- while (!(inStatus1())  0x01){};\
+while (inStatus1()  0x01){};\
+ while (!(inStatus1()  0x01)){};\
 } \
   } 
 #define MAX_CURS 64
-- 
1.7.0.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


[PATCH 2/4] savage: New SAVAGEDRIResume function

2011-04-20 Thread Tormod Volden
From: Tormod Volden debian.tor...@gmail.com

Move DRI stuff from savage_driver.c to savage_dri.c

Signed-off-by: Tormod Volden debian.tor...@gmail.com
---

This one should not change any behavior, but prepares for the next
patch. It is very much modeled after the function structure of the
radeon driver, which the savage driver once was based on.


 src/savage_dri.c|   14 +-
 src/savage_driver.c |9 ++---
 src/savage_driver.h |2 +-
 3 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/src/savage_dri.c b/src/savage_dri.c
index e0b9f86..b1555e4 100644
--- a/src/savage_dri.c
+++ b/src/savage_dri.c
@@ -1078,7 +1078,7 @@ Bool SAVAGEDRIScreenInit( ScreenPtr pScreen )
return TRUE;
 }
 
-void SAVAGEDRISetupTiledSurfaceRegs( SavagePtr psav )
+static void SAVAGEDRISetupTiledSurfaceRegs( SavagePtr psav )
 {
   SAVAGEDRIPtr pSAVAGEDRI = (SAVAGEDRIPtr)psav-pDRIInfo-devPrivate;
   unsigned int value = 0;
@@ -1287,6 +1287,18 @@ Bool SAVAGEDRIFinishScreenInit( ScreenPtr pScreen )
return TRUE;
 }
 
+void SAVAGEDRIResume(ScreenPtr pScreen)
+{
+   ScrnInfoPtr pScrn = xf86Screens[pScreen-myNum];
+   SavagePtr psav = SAVPTR(pScrn);
+   SAVAGESAREAPrivPtr pSAREAPriv = 
+   (SAVAGESAREAPrivPtr)DRIGetSAREAPrivate(pScreen);
+
+   SAVAGEDRISetupTiledSurfaceRegs(psav);
+   /* Assume that 3D state was clobbered, invalidate it by
+* changing ctxOwner in the sarea. */
+   pSAREAPriv-ctxOwner = DRIGetContext(pScreen);
+}
 
 void SAVAGEDRICloseScreen( ScreenPtr pScreen )
 {
diff --git a/src/savage_driver.c b/src/savage_driver.c
index 3098731..2edd844 100644
--- a/src/savage_driver.c
+++ b/src/savage_driver.c
@@ -2200,9 +2200,8 @@ static Bool SavageEnterVT(int scrnIndex, int flags)
 {
 ScrnInfoPtr pScrn = xf86Screens[scrnIndex];
 #ifdef XF86DRI
-SavagePtr psav= SAVPTR(pScrn);
+SavagePtr psav = SAVPTR(pScrn);
 ScreenPtr pScreen;
-SAVAGESAREAPrivPtr pSAREAPriv;
 #endif
 
 TRACE((SavageEnterVT(%d)\n, flags));
@@ -2213,13 +2212,9 @@ static Bool SavageEnterVT(int scrnIndex, int flags)
 #ifdef XF86DRI
 if (psav-directRenderingEnabled) {
 pScreen = screenInfo.screens[scrnIndex];
-   pSAREAPriv = (SAVAGESAREAPrivPtr)DRIGetSAREAPrivate(pScreen);
-   /* Assume that 3D state was clobbered, invalidate it by
-* changing ctxOwner in the sarea. */
-   pSAREAPriv-ctxOwner = DRIGetContext(pScreen);
+SAVAGEDRIResume(pScreen);
 DRIUnlock(pScreen);
 psav-LockHeld = 0;
-SAVAGEDRISetupTiledSurfaceRegs ( psav );
 }
 #endif
 if (!SAVPTR(pScrn)-IsSecondary)
diff --git a/src/savage_driver.h b/src/savage_driver.h
index 64587fc..fde47ff 100644
--- a/src/savage_driver.h
+++ b/src/savage_driver.h
@@ -559,7 +559,7 @@ Bool SAVAGEDRIScreenInit( ScreenPtr pScreen );
 Bool SAVAGEInitMC(ScreenPtr pScreen);
 void SAVAGEDRICloseScreen( ScreenPtr pScreen );
 Bool SAVAGEDRIFinishScreenInit( ScreenPtr pScreen );
-void SAVAGEDRISetupTiledSurfaceRegs ( SavagePtr psav );
+void SAVAGEDRIResume( ScreenPtr pScreen );
 
 Bool SAVAGELockUpdate( ScrnInfoPtr pScrn, drmLockFlags flags );
 
-- 
1.7.0.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


[PATCH 3/4] savage: Factor out a SAVAGESetAgpMode and call it on resume

2011-04-20 Thread Tormod Volden
From: Tormod Volden debian.tor...@gmail.com

This should fix resume with AGP. After all these years...

https://bugzilla.kernel.org/show_bug.cgi?id=4607

Signed-off-by: Tormod Volden debian.tor...@gmail.com
---

This was always the killer bug for my laptop. Wish I were 5 years earlier...
It turned out the same workaround(?) was used in the radeon driver.

I deliberately left unnecessary braces in the last hunk. Some checks could
probably be added there, to see if enabling is successful, but not sure what
to do if it fails.

 src/savage_dri.c |   56 ++---
 1 files changed, 32 insertions(+), 24 deletions(-)

diff --git a/src/savage_dri.c b/src/savage_dri.c
index b1555e4..c5bffe3 100644
--- a/src/savage_dri.c
+++ b/src/savage_dri.c
@@ -426,29 +426,11 @@ static unsigned int mylog2( unsigned int n )
return log2;
 }
 
-static Bool SAVAGEDRIAgpInit(ScreenPtr pScreen)
+static Bool SAVAGESetAgpMode(SavagePtr psav, ScreenPtr pScreen)
 {
-   ScrnInfoPtr pScrn = xf86Screens[pScreen-myNum];
-   SavagePtr psav = SAVPTR(pScrn);
-   SAVAGEDRIServerPrivatePtr pSAVAGEDRIServer = psav-DRIServerInfo;
-   unsigned long mode;
-   unsigned int vendor, device;
-   unsigned int offset;
-   int ret;
-
-   if (psav-agpSize  2) psav-agpSize = 2; /* at least 2MB for DMA buffers */
-
-   pSAVAGEDRIServer-agp.size = psav-agpSize * 1024 * 1024;
-   pSAVAGEDRIServer-agp.offset = pSAVAGEDRIServer-agp.size; /* ? */
-
-   if ( drmAgpAcquire( psav-drmFD )  0 ) {
-  xf86DrvMsg( pScreen-myNum, X_ERROR, [agp] AGP not available\n );
-  return FALSE;
-   }
-
-   mode   = drmAgpGetMode( psav-drmFD );/* Default mode */
-   vendor = drmAgpVendorId( psav-drmFD );
-   device = drmAgpDeviceId( psav-drmFD );
+   unsigned long mode = drmAgpGetMode( psav-drmFD );/* Default mode */
+   unsigned int vendor = drmAgpVendorId( psav-drmFD );
+   unsigned int device = drmAgpDeviceId( psav-drmFD );
 
mode = ~SAVAGE_AGP_MODE_MASK;
 
@@ -462,8 +444,6 @@ static Bool SAVAGEDRIAgpInit(ScreenPtr pScreen)
   mode |= SAVAGE_AGP_1X_MODE;
}
 
-   /*   mode |= SAVAGE_AGP_1X_MODE;*/
-
xf86DrvMsg( pScreen-myNum, X_INFO,
   [agp] Mode 0x%08lx [AGP 0x%04x/0x%04x; Card 0x%04x/0x%04x]\n,
   mode, vendor, device,
@@ -473,6 +453,31 @@ static Bool SAVAGEDRIAgpInit(ScreenPtr pScreen)
if ( drmAgpEnable( psav-drmFD, mode )  0 ) {
   xf86DrvMsg( pScreen-myNum, X_ERROR, [agp] AGP not enabled\n );
   drmAgpRelease( psav-drmFD );
+  return FALSE;
+   }
+
+   return TRUE;
+}
+
+static Bool SAVAGEDRIAgpInit(ScreenPtr pScreen)
+{
+   ScrnInfoPtr pScrn = xf86Screens[pScreen-myNum];
+   SavagePtr psav = SAVPTR(pScrn);
+   SAVAGEDRIServerPrivatePtr pSAVAGEDRIServer = psav-DRIServerInfo;
+   unsigned int offset;
+   int ret;
+
+   if (psav-agpSize  2) psav-agpSize = 2; /* at least 2MB for DMA buffers */
+
+   pSAVAGEDRIServer-agp.size = psav-agpSize * 1024 * 1024;
+   pSAVAGEDRIServer-agp.offset = pSAVAGEDRIServer-agp.size; /* ? */
+
+   if ( drmAgpAcquire( psav-drmFD )  0 ) {
+  xf86DrvMsg( pScreen-myNum, X_ERROR, [agp] AGP not available\n );
+  return FALSE;
+   }
+
+   if (!SAVAGESetAgpMode(psav, pScreen)) {
   pSAVAGEDRIServer-agp.handle = 0; /* indicate that AGP init failed */
   return FALSE;
}
@@ -1294,6 +1299,9 @@ void SAVAGEDRIResume(ScreenPtr pScreen)
SAVAGESAREAPrivPtr pSAREAPriv = 
(SAVAGESAREAPrivPtr)DRIGetSAREAPrivate(pScreen);
 
+   if (!psav-IsPCI) {
+   SAVAGESetAgpMode(psav, pScreen);
+   }
SAVAGEDRISetupTiledSurfaceRegs(psav);
/* Assume that 3D state was clobbered, invalidate it by
 * changing ctxOwner in the sarea. */
-- 
1.7.0.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


[PATCH 4/4] savage: Make SAVAGESelectBuffer() private (static)

2011-04-20 Thread Tormod Volden
From: Tormod Volden debian.tor...@gmail.com

Also clean out some unused prototypes from savage_driver.h

Signed-off-by: Tormod Volden debian.tor...@gmail.com
---

Cheers,
Tormod

 src/savage_dri.c|2 +-
 src/savage_driver.h |   14 --
 2 files changed, 1 insertions(+), 15 deletions(-)

diff --git a/src/savage_dri.c b/src/savage_dri.c
index c5bffe3..67fa6fe 100644
--- a/src/savage_dri.c
+++ b/src/savage_dri.c
@@ -386,7 +386,7 @@ static void SAVAGEBlockHandler( int screenNum, pointer 
blockData,
psav-pDRIInfo-wrap.BlockHandler = SAVAGEBlockHandler;
 }
 
-void SAVAGESelectBuffer( ScrnInfoPtr pScrn, int which )
+static void SAVAGESelectBuffer( ScrnInfoPtr pScrn, int which )
 {
SavagePtr psav = SAVPTR(pScrn);
SAVAGEDRIServerPrivatePtr pSAVAGEDRIServer = psav-DRIServerInfo;
diff --git a/src/savage_driver.h b/src/savage_driver.h
index fde47ff..1737362 100644
--- a/src/savage_driver.h
+++ b/src/savage_driver.h
@@ -561,20 +561,6 @@ void SAVAGEDRICloseScreen( ScreenPtr pScreen );
 Bool SAVAGEDRIFinishScreenInit( ScreenPtr pScreen );
 void SAVAGEDRIResume( ScreenPtr pScreen );
 
-Bool SAVAGELockUpdate( ScrnInfoPtr pScrn, drmLockFlags flags );
-
-#if 0
-void SAVAGEGetQuiescence( ScrnInfoPtr pScrn );
-void SAVAGEGetQuiescenceShared( ScrnInfoPtr pScrn );
-#endif
-
-void SAVAGESelectBuffer(ScrnInfoPtr pScrn, int which);
-
-#if 0
-Bool SAVAGECleanupDma(ScrnInfoPtr pScrn);
-Bool SAVAGEInitDma(ScrnInfoPtr pScrn, int prim_size);
-#endif
-
 #define SAVAGE_AGP_1X_MODE 0x01
 #define SAVAGE_AGP_2X_MODE 0x02
 #define SAVAGE_AGP_4X_MODE 0x04
-- 
1.7.0.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


Re: [PATCH 1/4] savage: Fix logic in waitHSync

2011-04-20 Thread Tormod Volden
On Wed, Apr 20, 2011 at 11:36 PM, Matt Turner wrote:
 Man, somebody didn't know operator precedence. Probably good that git
 history doesn't go back that far. :)

BTW, I just learned about -Wlogical-op (not part of -Wall) which
unfortunately does not catch this issue. But it found some similar
mix-ups like register  bit-mask... Coming up next.

 For the series:
 Reviewed-by: Matt Turner matts...@gmail.com

Thanks!
Tormod
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


[PATCH] savage: Fix / typo in magical register setup

2011-04-20 Thread Tormod Volden
From: Tormod Volden debian.tor...@gmail.com

Found with CFLAGS=-Wlogical-op

Signed-off-by: Tormod Volden debian.tor...@gmail.com
---

I hope I don't break the magic. BTW, LCD_ACTIVE is 0x02.

 src/savage_driver.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/savage_driver.c b/src/savage_driver.c
index 2edd844..e5b786c 100644
--- a/src/savage_driver.c
+++ b/src/savage_driver.c
@@ -2561,7 +2561,7 @@ static void SavageWriteMode(ScrnInfoPtr pScrn, vgaRegPtr 
vgaSavePtr,
(restore-refresh = 75)
)
{
-   if( cr6d  LCD_ACTIVE )
+   if( cr6d  LCD_ACTIVE )
cr79 = 0x05;
else
cr79 = 0x08;
@@ -2578,7 +2578,7 @@ static void SavageWriteMode(ScrnInfoPtr pScrn, vgaRegPtr 
vgaSavePtr,
  */
if( pScrn-displayWidth == 1024 )
{
-   if( cr6d  LCD_ACTIVE )
+   if( cr6d  LCD_ACTIVE )
cr79 = 0x08;
else
cr79 = 0x0e;
-- 
1.7.0.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


Re: [PATCH] savage: More (intermediate) casts to silence warnings

2011-02-13 Thread Tormod Volden
On Sat, Feb 12, 2011 at 10:43 PM, Mark Kettenis wrote:
 This isn't really the right way to fix things.  At least the casts
 should use uintptr_t instead of int.  That way you won't truncate
 addresses on true 64-bit architectures.  Or just leave these warnings
 there as a reminder of the misdesigned DGA and DRI APIs.  They really
 should not try to store a physical address into a C pointer.

Thanks for the review and explanation. I will change them to
uintptr_t, and look out for similar cases. In practice, we probably
won't see many Savage cards on 64-bit architectures :) For anyone
wondering, the psav-FbRegion.base is a pci_addr_t (uint64_t) from
pciaccess.h.

Tormod
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


Re: [PATCH 2/2] savage: Setup tiled surface registers in SavageEnterVT

2011-01-24 Thread Tormod Volden
On Sun, Jan 23, 2011 at 9:18 PM, Alex Deucher wrote:
 No, this is part of why UMS sucks.  During suspend the card is powered
 down, so on resume, the driver has to re-init everything.  All that
 has to happen in EnterVT.  All of your savage patches look good to me:

 Reviewed-by: Alex Deucher alexdeuc...@gmail.com

Thanks for the fast response and review.


 BTW, I don't think anyone maintains savage anymore, so feel free to
 take over if you like.

 Alex

The MAINTAINER doc says savage is maintained by yourself :) But if it
comes down to committing (my and other people's) patches after they
have been reviewed, and keep it buildable and alive, I would be happy
to free you from that burden. In all cases, I would need you to review
non-trivial stuff since you are the one who knows the innards of the
savage.

Cheers,
Tormod
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


[PATCH] savage: Add casts to silence build warnings

2011-01-23 Thread Tormod Volden
From: Tormod Volden debian.tor...@gmail.com

savage_exa.c: In function ‘SavageUploadToScreen’:
savage_exa.c:545: warning: passing argument 1 of ‘memcpy’ discards qualifiers 
from pointer target type
/usr/include/bits/string3.h:49: note: expected ‘void * restrict’ but argument 
is of type ‘volatile CARD32 *’

savage_video.c: In function ‘SavagePutImage’:
savage_video.c:2007: warning: format ‘%ld’ expects type ‘long int’, but 
argument 4 has type ‘drmSize’
savage_video.c:2007: warning: format ‘%ld’ expects type ‘long int’, but 
argument 5 has type ‘int’
---
 src/savage_exa.c   |2 +-
 src/savage_video.c |4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/savage_exa.c b/src/savage_exa.c
index 8411298..5515f2c 100644
--- a/src/savage_exa.c
+++ b/src/savage_exa.c
@@ -542,7 +542,7 @@ SavageUploadToScreen(PixmapPtr pDst, int x, int y, int w, 
int h, char *src, int
 
if (4 * dwords = queue) {
/* WARNING: breaking BCI_PTR abstraction here */
-   memcpy(bci_ptr, srcp, 4 * dwords);
+   memcpy((CARD32 *)bci_ptr, srcp, 4 * dwords);
bci_ptr += dwords;
queue -= 4 * dwords;
} else {
diff --git a/src/savage_video.c b/src/savage_video.c
index 311f47a..86ae0cd 100644
--- a/src/savage_video.c
+++ b/src/savage_video.c
@@ -2003,8 +2003,8 @@ SavagePutImage(
/* This situation is expected if AGPforXv is disabled, otherwise 
report. */
if (pSAVAGEDRIServer-agpXVideo.size  0) {
xf86DrvMsg( pScreen-myNum, X_ERROR,
-   [agp] XVideo: not enough space in buffer (got %ld bytes, 
required %ld bytes).\n, 
-   pSAVAGEDRIServer-agpXVideo.size, max(new_size, 
planarFrameSize));
+   [agp] XVideo: not enough space in buffer (got %ld bytes, 
required %d bytes).\n, 
+   (long int)pSAVAGEDRIServer-agpXVideo.size, max(new_size, 
planarFrameSize));
}
pPriv-agpBufferMap = NULL;
pPriv-agpBufferOffset = 0;
-- 
1.7.0.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH] savage: Replace deprecated x(c)alloc/xfree with m/calloc/free

2011-01-23 Thread Tormod Volden
From: Tormod Volden debian.tor...@gmail.com

sed -i 's/xalloc/malloc/g; s/xcalloc/calloc/g; s/xfree/free/g'

Also replace xrealloc with realloc.
---
 src/savage_dga.c|6 ++--
 src/savage_dri.c|   70 +-
 src/savage_driver.c |   22 
 src/savage_hwmc.c   |   10 +++---
 src/savage_vbe.c|   10 +++---
 src/savage_video.c  |   26 +-
 6 files changed, 72 insertions(+), 72 deletions(-)

diff --git a/src/savage_dga.c b/src/savage_dga.c
index eb1c5d2..7a9e22c 100644
--- a/src/savage_dga.c
+++ b/src/savage_dga.c
@@ -107,15 +107,15 @@ SavageSetupDGAMode(
otherPitch = secondPitch ? secondPitch : pMode-HDisplay;
 
if(pMode-HDisplay != otherPitch) {
-   newmodes = xrealloc(modes, (*num + 2) * sizeof(DGAModeRec));
+   newmodes = realloc(modes, (*num + 2) * sizeof(DGAModeRec));
oneMore = TRUE;
} else {
-   newmodes = xrealloc(modes, (*num + 1) * sizeof(DGAModeRec));
+   newmodes = realloc(modes, (*num + 1) * sizeof(DGAModeRec));
oneMore = FALSE;
}
 
if(!newmodes) {
-  xfree(modes);
+  free(modes);
   return NULL;
}
modes = newmodes;
diff --git a/src/savage_dri.c b/src/savage_dri.c
index 190e8ee..e4ebf84 100644
--- a/src/savage_dri.c
+++ b/src/savage_dri.c
@@ -105,24 +105,24 @@ static Bool SAVAGEInitVisualConfigs( ScreenPtr pScreen )
case 16:
   numConfigs = 8;
 
-  pConfigs = (__GLXvisualConfig*)xcalloc( sizeof(__GLXvisualConfig),
+  pConfigs = (__GLXvisualConfig*)calloc( sizeof(__GLXvisualConfig),
numConfigs );
   if ( !pConfigs ) {
 return FALSE;
   }
 
-  pSAVAGEConfigs = (SAVAGEConfigPrivPtr)xcalloc( 
sizeof(SAVAGEConfigPrivRec),
+  pSAVAGEConfigs = (SAVAGEConfigPrivPtr)calloc( 
sizeof(SAVAGEConfigPrivRec),
 numConfigs );
   if ( !pSAVAGEConfigs ) {
-xfree( pConfigs );
+free( pConfigs );
 return FALSE;
   }
 
-  pSAVAGEConfigPtrs = (SAVAGEConfigPrivPtr*)xcalloc( 
sizeof(SAVAGEConfigPrivPtr),
+  pSAVAGEConfigPtrs = (SAVAGEConfigPrivPtr*)calloc( 
sizeof(SAVAGEConfigPrivPtr),
 numConfigs );
   if ( !pSAVAGEConfigPtrs ) {
-xfree( pConfigs );
-xfree( pSAVAGEConfigs );
+free( pConfigs );
+free( pSAVAGEConfigs );
 return FALSE;
   }
 
@@ -201,24 +201,24 @@ static Bool SAVAGEInitVisualConfigs( ScreenPtr pScreen )
case 32:
   numConfigs = 8;
 
-  pConfigs = (__GLXvisualConfig*)xcalloc( sizeof(__GLXvisualConfig),
+  pConfigs = (__GLXvisualConfig*)calloc( sizeof(__GLXvisualConfig),
numConfigs );
   if ( !pConfigs ) {
 return FALSE;
   }
 
-  pSAVAGEConfigs = (SAVAGEConfigPrivPtr)xcalloc( 
sizeof(SAVAGEConfigPrivRec),
+  pSAVAGEConfigs = (SAVAGEConfigPrivPtr)calloc( 
sizeof(SAVAGEConfigPrivRec),
 numConfigs );
   if ( !pSAVAGEConfigs ) {
-xfree( pConfigs );
+free( pConfigs );
 return FALSE;
   }
 
-  pSAVAGEConfigPtrs = (SAVAGEConfigPrivPtr*)xcalloc( 
sizeof(SAVAGEConfigPrivPtr),
+  pSAVAGEConfigPtrs = (SAVAGEConfigPrivPtr*)calloc( 
sizeof(SAVAGEConfigPrivPtr),
 numConfigs );
   if ( !pSAVAGEConfigPtrs ) {
-xfree( pConfigs );
-xfree( pSAVAGEConfigs );
+free( pConfigs );
+free( pSAVAGEConfigs );
 return FALSE;
   }
 
@@ -906,7 +906,7 @@ Bool SAVAGEDRIScreenInit( ScreenPtr pScreen )
if (xf86LoaderCheckSymbol(DRICreatePCIBusID)) {
   pDRIInfo-busIdString = DRICreatePCIBusID(psav-PciInfo);
} else {
-  pDRIInfo-busIdString= xalloc(64);
+  pDRIInfo-busIdString= malloc(64);
   sprintf(pDRIInfo-busIdString,
   PCI:%d:%d:%d,
   psav-PciInfo-bus,
@@ -960,7 +960,7 @@ Bool SAVAGEDRIScreenInit( ScreenPtr pScreen )
 
pDRIInfo-SAREASize = SAREA_MAX;
 
-   pSAVAGEDRI = (SAVAGEDRIPtr)xcalloc( sizeof(SAVAGEDRIRec), 1 );
+   pSAVAGEDRI = (SAVAGEDRIPtr)calloc( sizeof(SAVAGEDRIRec), 1 );
if ( !pSAVAGEDRI ) {
   DRIDestroyInfoRec( psav-pDRIInfo );
   psav-pDRIInfo = 0;
@@ -970,9 +970,9 @@ Bool SAVAGEDRIScreenInit( ScreenPtr pScreen )
}
 
pSAVAGEDRIServer = (SAVAGEDRIServerPrivatePtr)
-  xcalloc( sizeof(SAVAGEDRIServerPrivateRec), 1 );
+  calloc( sizeof(SAVAGEDRIServerPrivateRec), 1 );
if ( !pSAVAGEDRIServer ) {
-  xfree( pSAVAGEDRI );
+  free( pSAVAGEDRI );
   DRIDestroyInfoRec( psav-pDRIInfo );
   psav-pDRIInfo = 0;
   xf86DrvMsg( pScrn-scrnIndex, X_ERROR,
@@ -998,9 +998,9 @@ Bool SAVAGEDRIScreenInit( ScreenPtr pScreen )
pDRIInfo-bufferRequests

[PATCH] savage: More (intermediate) casts to silence warnings

2011-01-23 Thread Tormod Volden
From: Tormod Volden debian.tor...@gmail.com

savage_dga.c: In function ‘Savage_OpenFramebuffer’:
savage_dga.c:393: warning: cast to pointer from integer of different size

savage_dri.c: In function ‘SAVAGEDRIScreenInit’:
savage_dri.c:924: warning: cast to pointer from integer of different size
---

Not sure if this is really the way to go, but I have seen similar
commits and it works for me.

The remaining warnings that I see are more tricky, since the drm_handle_t
type in question is different on Linux and BSD:

savage_dri.c:490: warning: format ‘%08lx’ expects type ‘long unsigned int’,
but argument 5 has type ‘drm_handle_t’

I guess we just have to live with those?

Best regards,
Tormod

 src/savage_dga.c |2 +-
 src/savage_dri.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/savage_dga.c b/src/savage_dga.c
index 7a9e22c..92a179e 100644
--- a/src/savage_dga.c
+++ b/src/savage_dga.c
@@ -390,7 +390,7 @@ Savage_OpenFramebuffer(
 SavagePtr psav = SAVPTR(pScrn);
 
 *name = NULL;   /* no special device */
-*mem = (unsigned char*)psav-FbRegion.base;
+*mem = (unsigned char*)(int) psav-FbRegion.base;
 *size = psav-videoRambytes;
 *offset = 0;
 *flags = DGA_NEED_ROOT;
diff --git a/src/savage_dri.c b/src/savage_dri.c
index e4ebf84..90d3442 100644
--- a/src/savage_dri.c
+++ b/src/savage_dri.c
@@ -921,7 +921,7 @@ Bool SAVAGEDRIScreenInit( ScreenPtr pScreen )
pDRIInfo-ddxDriverMinorVersion = SAVAGE_VERSION_MINOR;
pDRIInfo-ddxDriverPatchVersion = SAVAGE_PATCHLEVEL;
 
-   pDRIInfo-frameBufferPhysicalAddress = (pointer) psav-FbRegion.base;
+   pDRIInfo-frameBufferPhysicalAddress = (pointer)(int) psav-FbRegion.base;
pDRIInfo-frameBufferSize = psav-videoRambytes;
pDRIInfo-frameBufferStride = pScrn-displayWidth*(pScrn-bitsPerPixel/8);
pDRIInfo-ddxDrawableTableEntry = SAVAGE_MAX_DRAWABLES;
-- 
1.7.0.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH] savage: Drop unused variables and functions

2011-01-23 Thread Tormod Volden
From: Tormod Volden debian.tor...@gmail.com

Silence -Wall warnings.

The functions are just #if'ed out, to be left for inspiration.
---
 src/savage_accel.c  |3 ++-
 src/savage_cursor.c |2 ++
 src/savage_exa.c|1 -
 src/savage_video.c  |5 +
 4 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/src/savage_accel.c b/src/savage_accel.c
index 73c2d90..24e0a22 100644
--- a/src/savage_accel.c
+++ b/src/savage_accel.c
@@ -1257,6 +1257,7 @@ void SavageSetGBD_2000(ScrnInfoPtr pScrn)
 OUTREG8(SEQ_DATA_REG,byte);
 }
 
+#if 0
 static
 void SavageRestoreAccelState(ScrnInfoPtr pScrn)
 {
@@ -1266,6 +1267,7 @@ void SavageRestoreAccelState(ScrnInfoPtr pScrn)
 
 return;
 }
+#endif
 
 /* Acceleration init function, sets up pointers to our accelerated functions */
 
@@ -1278,7 +1280,6 @@ SavageInitAccel(ScreenPtr pScreen)
 #ifdef XF86DRI
 if (psav-directRenderingEnabled) {
 SAVAGEDRIServerPrivatePtr pSAVAGEDRIServer = psav-DRIServerInfo;
-BoxRec MemBox;
 int cpp = pScrn-bitsPerPixel / 8;
 int widthBytes = psav-lDelta;
 int bufferSize = ((pScrn-virtualY * widthBytes + SAVAGE_BUFFER_ALIGN)
diff --git a/src/savage_cursor.c b/src/savage_cursor.c
index 1af2449..4d193eb 100644
--- a/src/savage_cursor.c
+++ b/src/savage_cursor.c
@@ -79,6 +79,7 @@ static void SavageSetCursorColors(ScrnInfoPtr pScrn, int bg, 
int fg);
  * the HW cursor position.
  */
 
+#if 0
 static Bool
 SavageUseHWCursor(ScreenPtr pScr, CursorPtr pCurs)
 {
@@ -94,6 +95,7 @@ SavageUseHWCursor(ScreenPtr pScr, CursorPtr pCurs)
 }
 return TRUE;
 }
+#endif
 
 Bool 
 SavageHWCursorInit(ScreenPtr pScreen)
diff --git a/src/savage_exa.c b/src/savage_exa.c
index 5515f2c..4fe43e5 100644
--- a/src/savage_exa.c
+++ b/src/savage_exa.c
@@ -567,7 +567,6 @@ SavageUploadToScreen(PixmapPtr pDst, int x, int y, int w, 
int h, char *src, int
 Bool
 SavageDownloadFromScreen(PixmapPtr pSrc, int x, int y, int w, int h, char 
*dst, int dst_pitch)
 {
-ScrnInfoPtr pScrn = xf86Screens[pSrc-drawable.pScreen-myNum];
 unsigned char *src = pSrc-devPrivate.ptr;
 intsrc_pitch = exaGetPixmapPitch(pSrc);
 intbpp = pSrc-drawable.bitsPerPixel;
diff --git a/src/savage_video.c b/src/savage_video.c
index 86ae0cd..9f860c7 100644
--- a/src/savage_video.c
+++ b/src/savage_video.c
@@ -1038,7 +1038,6 @@ SavageStopVideo(ScrnInfoPtr pScrn, pointer data, Bool 
shutdown)
 {
 SavagePortPrivPtr pPriv = (SavagePortPrivPtr)data;
 SavagePtr psav = SAVPTR(pScrn);
-ScreenPtr pScreen = screenInfo.screens[pScrn-scrnIndex];
 
 xf86ErrorFVerb(XVTRACE,SavageStopVideo\n);
 
@@ -1214,7 +1213,6 @@ SavageCopyPlanarDataBCI(
 unsigned long offsetV = offsetY +  srcPitch * h;
 unsigned long offsetU = offsetV +  srcPitch2 * (h1);
 unsigned long dstOffset  = (unsigned long)dst - (unsigned 
long)psav-FBBase;
-int i;
 unsigned char memType;
 
 BCI_GET_PTR;
@@ -1975,7 +1973,6 @@ SavagePutImage(
upload to framebuffer (slower) */
 #ifdef XF86DRI
 if (!pPriv-tried_agp  !psav-IsPCI  psav-drmFD  0  
psav-DRIServerInfo != NULL) {
-int ret;
SAVAGEDRIServerPrivatePtr pSAVAGEDRIServer = psav-DRIServerInfo;
 
pPriv-tried_agp = TRUE;
@@ -2335,7 +2332,7 @@ SavageDisplaySurface(
 surface-width, surface-height, surface-pitches[0],
 x1, y1, x2, y2, dstBox, src_w, src_h, drw_w, drw_h);
 
-xf86XVFillKeyHelper(pScrn-pScreen, portPriv-colorKey, clipBoxes);
+xf86XVFillKeyHelper(pScreen, portPriv-colorKey, clipBoxes);
 
 pPriv-isOn = TRUE;
 #if 0
-- 
1.7.0.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


[PATCH] savage: Cast all handles before printing them

2011-01-23 Thread Tormod Volden
From: Tormod Volden debian.tor...@gmail.com

Removes the last bunch of -Wall build warnings.

savage_dri.c:490: warning: format ‘%08lx’ expects type ‘long unsigned 
int’,
but argument 5 has type ‘drm_handle_t’
...

---

 The remaining warnings that I see are more tricky, since the drm_handle_t
 type in question is different on Linux and BSD:

 I guess we just have to live with those?

I don't know what I was talking about. Just cast and everybody should be
happy. Such casts were already done other places.

Tormod


 src/savage_dri.c |   33 +
 1 files changed, 17 insertions(+), 16 deletions(-)

diff --git a/src/savage_dri.c b/src/savage_dri.c
index 90d3442..088c4b2 100644
--- a/src/savage_dri.c
+++ b/src/savage_dri.c
@@ -487,7 +487,8 @@ static Bool SAVAGEDRIAgpInit(ScreenPtr pScreen)
}
xf86DrvMsg( pScreen-myNum, X_INFO,
   [agp] %d kB allocated with handle 0x%08lx\n,
-  pSAVAGEDRIServer-agp.size/1024, pSAVAGEDRIServer-agp.handle );
+  pSAVAGEDRIServer-agp.size/1024,
+  (unsigned long)pSAVAGEDRIServer-agp.handle );
 
if ( drmAgpBind( psav-drmFD, pSAVAGEDRIServer-agp.handle, 0 )  0 ) {
   xf86DrvMsg( pScreen-myNum, X_ERROR, [agp] Could not bind memory\n );
@@ -547,7 +548,7 @@ static Bool SAVAGEDRIAgpInit(ScreenPtr pScreen)
   }
   xf86DrvMsg( pScreen-myNum, X_INFO,
   [agp] command DMA handle = 0x%08lx\n,
-  pSAVAGEDRIServer-cmdDma.handle );
+  (unsigned long)pSAVAGEDRIServer-cmdDma.handle );
   /* not needed in the server
   if ( drmMap( psav-drmFD,
pSAVAGEDRIServer-cmdDma.handle,
@@ -573,7 +574,7 @@ static Bool SAVAGEDRIAgpInit(ScreenPtr pScreen)
   }
   xf86DrvMsg( pScreen-myNum, X_INFO,
   [agp] DMA buffers handle = 0x%08lx\n,
-  pSAVAGEDRIServer-buffers.handle );
+  (unsigned long)pSAVAGEDRIServer-buffers.handle );
   /* not needed in the server
   if ( drmMap( psav-drmFD,
pSAVAGEDRIServer-buffers.handle,
@@ -605,7 +606,7 @@ static Bool SAVAGEDRIAgpInit(ScreenPtr pScreen)
} else {
xf86DrvMsg( pScreen-myNum, X_INFO,
   [agp] agpXVideo handle = 0x%08lx\n,
-  pSAVAGEDRIServer-agpXVideo.handle );
+  (unsigned long)pSAVAGEDRIServer-agpXVideo.handle );
}
}
 
@@ -623,7 +624,7 @@ static Bool SAVAGEDRIAgpInit(ScreenPtr pScreen)
/*   pSAVAGEDRIServer-agp_offset=pSAVAGEDRIServer-agpTexture.size;*/
xf86DrvMsg( pScreen-myNum, X_INFO,
   [agp] agpTextures handle = 0x%08lx\n,
-  pSAVAGEDRIServer-agpTextures.handle );
+  (unsigned long)pSAVAGEDRIServer-agpTextures.handle );
 
/* not needed in the server
if ( drmMap( psav-drmFD,
@@ -675,7 +676,7 @@ static Bool SAVAGEDRIMapInit( ScreenPtr pScreen )

xf86DrvMsg( pScreen-myNum, X_INFO,
   [drm] aperture handle = 0x%08lx\n,
-  pSAVAGEDRIServer-aperture.handle );
+  (unsigned long)pSAVAGEDRIServer-aperture.handle );
 
/*if(drmMap(psav-drmFD,
   pSAVAGEDRIServer-registers.handle,
@@ -700,7 +701,7 @@ static Bool SAVAGEDRIMapInit( ScreenPtr pScreen )
} else
   xf86DrvMsg( pScreen-myNum, X_INFO,
   [drm] PCI command DMA handle = 0x%08lx\n,
-  pSAVAGEDRIServer-cmdDma.handle );
+  (unsigned long)pSAVAGEDRIServer-cmdDma.handle );
}
 
/* Enable ShadowStatus by default for direct rendering. */
@@ -724,7 +725,7 @@ static Bool SAVAGEDRIMapInit( ScreenPtr pScreen )
}
xf86DrvMsg( pScreen-myNum, X_INFO,
   [drm] Status handle = 0x%08lx\n,
-  pSAVAGEDRIServer-status.handle );
+  (unsigned long)pSAVAGEDRIServer-status.handle );
 
if ( drmMap( psav-drmFD,
pSAVAGEDRIServer-status.handle,
@@ -1216,29 +1217,29 @@ Bool SAVAGEDRIFinishScreenInit( ScreenPtr pScreen )
xf86DrvMsg( pScrn-scrnIndex, X_INFO, [junkers]
textureSize:0x%08x\n,pSAVAGEDRIServer-textureSize);
xf86DrvMsg( pScrn-scrnIndex, X_INFO, [junkers]
logTextureGranularity:0x%08x\n,pSAVAGEDRIServer-logTextureGranularity);
 
-   xf86DrvMsg( pScrn-scrnIndex, X_INFO, [junkers]
agp:handle:0x%08lx\n,pSAVAGEDRIServer-agp.handle);
+   xf86DrvMsg( pScrn-scrnIndex, X_INFO, [junkers]
agp:handle:0x%08lx\n,(unsigned long)pSAVAGEDRIServer-agp.handle);
xf86DrvMsg( pScrn-scrnIndex, X_INFO, [junkers]
agp:offset:0x%08x\n,pSAVAGEDRIServer-agp.offset);
xf86DrvMsg( pScrn-scrnIndex, X_INFO, [junkers]
agp:size:0x%08x\n,pSAVAGEDRIServer-agp.size);
xf86DrvMsg( pScrn-scrnIndex, X_INFO, [junkers]
agp:map:0x%08lx\n,(unsigned long)pSAVAGEDRIServer-agp.map);

-   xf86DrvMsg( pScrn-scrnIndex, X_INFO, [junkers]
registers:handle:0x%08lx

[PATCH 2/2] savage: Setup tiled surface registers in SavageEnterVT

2011-01-23 Thread Tormod Volden
From: Tormod Volden debian.tor...@gmail.com

These registers are cleared after suspend/resume, so set them
up again in EnterVT.
---

Is there any other suitable function that is called on resume,
where this can be placed?

Similar things (registers) are set up in SavageInitialize2DEngine,
but that function is called quite often.

Finally, is there something else to blame for clearing out these
registers? Is pm-utils doing to much?

Cheers,
Tormod

 src/savage_driver.c |1 +
 src/savage_driver.h |1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/src/savage_driver.c b/src/savage_driver.c
index 38db9f6..1a76c77 100644
--- a/src/savage_driver.c
+++ b/src/savage_driver.c
@@ -2219,6 +2219,7 @@ static Bool SavageEnterVT(int scrnIndex, int flags)
pSAREAPriv-ctxOwner = DRIGetContext(pScreen);
 DRIUnlock(pScreen);
 psav-LockHeld = 0;
+SAVAGEDRISetupTiledSurfaceRegs ( psav );
 }
 #endif
 if (!SAVPTR(pScrn)-IsSecondary)
diff --git a/src/savage_driver.h b/src/savage_driver.h
index 9c0ba58..64587fc 100644
--- a/src/savage_driver.h
+++ b/src/savage_driver.h
@@ -559,6 +559,7 @@ Bool SAVAGEDRIScreenInit( ScreenPtr pScreen );
 Bool SAVAGEInitMC(ScreenPtr pScreen);
 void SAVAGEDRICloseScreen( ScreenPtr pScreen );
 Bool SAVAGEDRIFinishScreenInit( ScreenPtr pScreen );
+void SAVAGEDRISetupTiledSurfaceRegs ( SavagePtr psav );
 
 Bool SAVAGELockUpdate( ScrnInfoPtr pScrn, drmLockFlags flags );
 
-- 
1.7.0.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


[PATCH 1/2] savage: Factor out a SAVAGEDRISetupTiledSurfaceRegs function

2011-01-23 Thread Tormod Volden
From: Tormod Volden debian.tor...@gmail.com

The tiled surface registers were only setup in SAVAGEDRIScreenInit,
however, after suspend/resume these registers must be set up again.
So factor it out in a new function so it can be reused.
---

The follow-up patch will call this new function in EnterVT.


 src/savage_dri.c |   86 +++--
 1 files changed, 44 insertions(+), 42 deletions(-)

diff --git a/src/savage_dri.c b/src/savage_dri.c
index 088c4b2..2c7a077 100644
--- a/src/savage_dri.c
+++ b/src/savage_dri.c
@@ -1078,6 +1078,49 @@ Bool SAVAGEDRIScreenInit( ScreenPtr pScreen )
return TRUE;
 }
 
+void SAVAGEDRISetupTiledSurfaceRegs( SavagePtr psav )
+{
+  SAVAGEDRIPtr pSAVAGEDRI = (SAVAGEDRIPtr)psav-pDRIInfo-devPrivate;
+  unsigned int value = 0;
+  
+  OUTREG(0x850C,(INREG(0x850C) | 0x8000)); /* AGD: I don't think this 
does anything on 3D/MX/IX */
+  /* maybe savage4 too... */
+  /* we don't use Y range flag,so comment it */
+  /*
+if(pSAVAGEDRI-width = 1024)
+value |= (129);
+  */
+  if ((psav-Chipset == S3_SAVAGE_MX) /* 3D/MX/IX seem to set up the tile 
stride differently */
+   || (psav-Chipset == S3_SAVAGE3D)) {
+   if(pSAVAGEDRI-cpp == 2)
+   {
+   value |=  ((psav-lDelta / 4)  5)  24;
+   value |= 230;
+   } else {
+   value |=  ((psav-lDelta / 4)  5)  24;
+   value |= 330;
+   }
+
+   OUTREG(TILED_SURFACE_REGISTER_0, value|(pSAVAGEDRI-frontOffset) ); 
/* front */ 
+   OUTREG(TILED_SURFACE_REGISTER_1, value|(pSAVAGEDRI-backOffset) ); 
/* back  */
+   OUTREG(TILED_SURFACE_REGISTER_2, value|(pSAVAGEDRI-depthOffset) ); 
/* depth */
+  } else {
+   int offset_shift = 5;
+   if(pSAVAGEDRI-cpp == 2)
+   {
+   value |=  (((pSAVAGEDRI-width + 0x3F)  0xFFC0)  6)  20;
+   value |= 230;
+   } else {
+   value |=  (((pSAVAGEDRI-width + 0x1F)  0xFFE0)  5)  20;
+   value |= 330;
+   }
+   if (psav-Chipset == S3_SUPERSAVAGE) /* supersavages have a 
different shift */
+   offset_shift = 6;
+   OUTREG(TILED_SURFACE_REGISTER_0, value|(pSAVAGEDRI-frontOffset  
offset_shift) ); /* front */
+   OUTREG(TILED_SURFACE_REGISTER_1, value|(pSAVAGEDRI-backOffset  
offset_shift) ); /* back  */
+   OUTREG(TILED_SURFACE_REGISTER_2, value|(pSAVAGEDRI-depthOffset  
offset_shift) ); /* depth */
+  }
+}
 
 Bool SAVAGEDRIFinishScreenInit( ScreenPtr pScreen )
 {
@@ -1149,48 +1192,6 @@ Bool SAVAGEDRIFinishScreenInit( ScreenPtr pScreen )
pSAVAGEDRI-apertureHandle  = pSAVAGEDRIServer-aperture.handle;
pSAVAGEDRI-apertureSize= pSAVAGEDRIServer-aperture.size;
pSAVAGEDRI-aperturePitch= psav-ulAperturePitch;
-
-   {
-  unsigned int value = 0;
-  
-  OUTREG(0x850C,(INREG(0x850C) | 0x8000)); /* AGD: I don't think this 
does anything on 3D/MX/IX */
-  /* maybe savage4 too... */
-  /* we don't use Y range flag,so comment it */
-  /*
-if(pSAVAGEDRI-width = 1024)
-value |= (129);
-  */
-  if ((psav-Chipset == S3_SAVAGE_MX) /* 3D/MX/IX seem to set up the tile 
stride differently */
-   || (psav-Chipset == S3_SAVAGE3D)) {
-   if(pSAVAGEDRI-cpp == 2)
-   {
-   value |=  ((psav-lDelta / 4)  5)  24;
-   value |= 230;
-   } else {
-   value |=  ((psav-lDelta / 4)  5)  24;
-   value |= 330;
-   }
-
-   OUTREG(TILED_SURFACE_REGISTER_0, value|(pSAVAGEDRI-frontOffset) ); 
/* front */ 
-   OUTREG(TILED_SURFACE_REGISTER_1, value|(pSAVAGEDRI-backOffset) ); 
/* back  */
-   OUTREG(TILED_SURFACE_REGISTER_2, value|(pSAVAGEDRI-depthOffset) ); 
/* depth */
-  } else {
-   int offset_shift = 5;
-   if(pSAVAGEDRI-cpp == 2)
-   {
-   value |=  (((pSAVAGEDRI-width + 0x3F)  0xFFC0)  6)  20;
-   value |= 230;
-   } else {
-   value |=  (((pSAVAGEDRI-width + 0x1F)  0xFFE0)  5)  20;
-   value |= 330;
-   }
-   if (psav-Chipset == S3_SUPERSAVAGE) /* supersavages have a 
different shift */
-   offset_shift = 6;
-   OUTREG(TILED_SURFACE_REGISTER_0, value|(pSAVAGEDRI-frontOffset  
offset_shift) ); /* front */
-   OUTREG(TILED_SURFACE_REGISTER_1, value|(pSAVAGEDRI-backOffset  
offset_shift) ); /* back  */
-   OUTREG(TILED_SURFACE_REGISTER_2, value|(pSAVAGEDRI-depthOffset  
offset_shift) ); /* depth */
-  }
-   }

pSAVAGEDRI-statusHandle= pSAVAGEDRIServer-status.handle;
pSAVAGEDRI-statusSize  = pSAVAGEDRIServer-status.size;
@@ -1282,6 +1283,7 @@ Bool SAVAGEDRIFinishScreenInit( ScreenPtr pScreen

Re: [PATCH build 2/2] Clean up all conditional statements.

2010-09-15 Thread Tormod Volden
On Wed, Sep 15, 2010 at 7:56 AM, Trevor Woerner wrote:

 -if [ $1 = lib ]  [ $2 = libX11 ]  [ x$USE_XCB = xNO ]; then
 +if [ $1 = lib ]  [ $2 = libX11 ]  [ x${USE_XCB} = xNO ]; 
 then
MOD_SPECIFIC=--with-xcb=no
 fi

Any reason to not write just [ $USE_XCB = NO ] ? Then we could get
of all these x$checks, they are sooo 70's :)

 ${MAKE} $MAKEFLAGS || failed make $1 $2

(and many other places)

For consistency, maybe get rid of unnecessary braces? Sometimes they
can make code more readable but most places here I think it is just
contamination from Makefile syntax.

Trevor, thanks for this initiative, it makes the code much nicer to read.

Tormod
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


Re: [PATCH build 2/2] Clean up all conditional statements.

2010-09-15 Thread Tormod Volden
On Wed, Sep 15, 2010 at 1:56 PM, Mikhail Gusarov wrote:

 $ echo $a

 $ [ zz = $a ]

No problem with quotes, you can even put it the intuitive way with the
variable first:

$ [ $a = zz ]
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


Re: [PATCH build 2/2] Clean up all conditional statements.

2010-09-15 Thread Tormod Volden
On Wed, Sep 15, 2010 at 2:36 PM, Trevor Woerner wrote:
 From: Trevor Woerner twoer...@gmail.com

 - use '-z' or '-n' instead of x$VAR
 - compare strings to strings and numbers to numbers
 - use ${variable:=word} to set default variable values

 Signed-off-by: Trevor Woerner twoer...@gmail.com
 ---
  build.sh |   65 ++---
  1 files changed, 28 insertions(+), 37 deletions(-)

 diff --git a/build.sh b/build.sh
 index fa6a321..20aee43 100755

Reviewed-by: Tormod Volden lists.tor...@gmail.com

On Wed, Sep 15, 2010 at 2:09 PM, Trevor Woerner wrote:
 Forcing the type to string using the 'x' works (which is what I assume
 to be the purpose of this notation), but so does:

BTW, in Bourne shell there is no notion of types, it is all
(substituted) strings. But beware of lack of string :) For instance,
[ -n $a ] returns true and [ -n $a ] returns false if a is not set.
The [ function applies after parsing and string substitution, and
sees just [ -n ] in the first case. Which it does not handle well IMO.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


Re: Screen clearing issue when X starts

2009-04-22 Thread Tormod Volden
On Tue, Apr 21, 2009 at 9:36 AM, umang gupta umang@gmail.com wrote:
 X clears the contents of the framebuffer when it starts, so the
 display is briefly all black
 while X starts.

Not so in recent xserver AFAICT, for instance the radeon driver was
recently fixed to do the above:
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=6532aeddacdeda3aa534264741c8648e1c449e76

Tormod
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel