Re: MGA fixes don't compile

2003-07-03 Thread Andrew C Aitchison
On Wed, 2 Jul 2003, Alex Deucher wrote:

 Actually you could probably replace the HAL functionality by using the
 linux matrox framebuffer driver or directfb driver as a reference.  it
 exposes just about all the functionality of the Gxxx driver (tv out,
 flatpanel, YUV modes on the second crtc).

Are we allowed to go grabbing chunks of code from those drivers ?

I've never looked at them because I've been afraid that if I did
pinch code, we could end up with a court case.
Problem is we would be taking code with a GNU copyright and
presenting it with an XFree86 copyright.

Since I've never been taught how to do clean-room development,
and don't have any guidelines, I'd rather not go reading the matroxfb
code.

-- 
Andrew C Aitchison


___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel


Re: MGA fixes don't compile

2003-07-03 Thread Alex Deucher
I believe someone asked Petr once and he said he didn't mind if we used
his driver as a reference.  IANAL, but as long as you didn't just
blatantly cut and paste the code, couldn't you use it as a reference? 
Still, probably better to get Petr's (and possibly directfb's) ok.

Alex

--- Andrew C Aitchison [EMAIL PROTECTED] wrote:
 On Wed, 2 Jul 2003, Alex Deucher wrote:
 
  Actually you could probably replace the HAL functionality by using
 the
  linux matrox framebuffer driver or directfb driver as a reference. 
 it
  exposes just about all the functionality of the Gxxx driver (tv
 out,
  flatpanel, YUV modes on the second crtc).
 
 Are we allowed to go grabbing chunks of code from those drivers ?
 
 I've never looked at them because I've been afraid that if I did
 pinch code, we could end up with a court case.
 Problem is we would be taking code with a GNU copyright and
 presenting it with an XFree86 copyright.
 
 Since I've never been taught how to do clean-room development,
 and don't have any guidelines, I'd rather not go reading the matroxfb
 code.
 
 -- 
 Andrew C Aitchison
 
 
 ___
 Devel mailing list
 [EMAIL PROTECTED]
 http://XFree86.Org/mailman/listinfo/devel


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel


Re: MGA fixes don't compile

2003-07-02 Thread Egbert Eich
David Dawes writes:
  
  Maybe the situation would be better if the mga_hal module was limited
  to doing just those initialisations that can't, for whatever reasons,
  be done in open source.  If I recall correctly, the original reason for
  not having this in open source was that enabling the second display on
  the G400 couldn't be done without exposing how macrovision could be
  disabled (or something like that).

The truth is that we don't know what MGA HAL does exactly.
It does a lot of initialization stuff when it is called in PreInit()(!)
and it sets up video modes differently than the OpenSource code does.
In some cases it does the wrong thing so I had to add a lot of
workarounds. In some other cases it does a better job - for example
when setting up a video mode for flat panels.
We could try to make the OpenSource driver better so we didn't have
to use the HAL library any more - this however isn't really feasable
without detailed docs on the chipsets and I don't think anybody is
into register dumping and comparing.

  
  I get the impression that the mga_hal module went beyond what was
  originally intended, and it definitely makes a mess of the mga driver,
  as Egbert noted.

Yes, it does a lot more than just enable the secondary display on a
G400.

  
  I believe that the /tmp/mgaDriverIn/Out stuff is only used by the
  MGA PowerDesktop, and I can live without that, but please don't remove 
  the HAL.
  
  When the PowerDesktop stuff was originally discussed a while back, it
  was recommended that it be implemented via a server extension.  That
  recommendation was obviously ignored.  What Matrox puts in their own
  driver is their business, but it definitely doesn't belong in XFree86
  in its current state.
  

Probably not.

Egbert.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel


Re: MGA fixes don't compile

2003-07-02 Thread Alex Deucher
--- Egbert Eich [EMAIL PROTECTED] wrote:
 
 The truth is that we don't know what MGA HAL does exactly.
 It does a lot of initialization stuff when it is called in
 PreInit()(!)
 and it sets up video modes differently than the OpenSource code does.
 In some cases it does the wrong thing so I had to add a lot of
 workarounds. In some other cases it does a better job - for example
 when setting up a video mode for flat panels.
 We could try to make the OpenSource driver better so we didn't have
 to use the HAL library any more - this however isn't really feasable
 without detailed docs on the chipsets and I don't think anybody is
 into register dumping and comparing.
 

Actually you could probably replace the HAL functionality by using the
linux matrox framebuffer driver or directfb driver as a reference.  it
exposes just about all the functionality of the Gxxx driver (tv out,
flatpanel, YUV modes on the second crtc).

Alex


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel


MGA fixes don't compile

2003-07-01 Thread Dr Andrew C Aitchison

 260. Disabled mode writeback to client program from MGA driver (Egbert 
Eich).

This doesn't compile on RedHat 6.2 / egcs-2.91.66

mga_driver.c:3542: warning: preprocessing directive not recognized within macro arg
mga_driver.c:3542: warning: preprocessing directive not recognized within macro arg
mga_driver.c:3542: warning: preprocessing directive not recognized within macro arg
mga_driver.c:3542: warning: preprocessing directive not recognized within macro arg
mga_driver.c:3542: warning: preprocessing directive not recognized within macro arg
mga_driver.c:3542: warning: preprocessing directive not recognized within macro arg
mga_driver.c: In function `MGASwitchMode':
mga_driver.c:3503: undefined or invalid # directive
mga_driver.c:3505: undefined or invalid # directive
mga_driver.c:3507: undefined or invalid # directive
mga_driver.c:3509: undefined or invalid # directive
mga_driver.c:3523: undefined or invalid # directive
mga_driver.c:3527: undefined or invalid # directive
mga_driver.c: In function `MGAAdjustFrame':
mga_driver.c:3609: warning: implicit declaration of function `HALSetDisplayStart'
make: *** [mga_driver.o] Error 1

This patch expands the macro MGA_HAL() thus allowing the code to compile.

-- 
Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge
[EMAIL PROTECTED]   http://www.dpmms.cam.ac.uk/~werdna
Index: mga_driver.c
===
RCS file: /home/CVS/XFree86/xc/programs/Xserver/hw/xfree86/drivers/mga/mga_driver.c,v
retrieving revision 1.234
diff -u -r1.234 mga_driver.c
--- mga_driver.c2003/06/30 16:52:56 1.234
+++ mga_driver.c2003/07/01 07:32:12
@@ -3490,15 +3490,18 @@
 char sCmdIn[256];
 char sCmdOut[256];
 FILE* fdIn;
+#ifdef MATROX_WRITEBACK
 FILE* fdOut;
 #endif
+#endif
 MGAPtr pMga;
 ScrnInfoPtr pScrn = xf86Screens[scrnIndex];
 pMga = MGAPTR(pScrn);
  
 if  (mode-Flags  0x8000) {
 #ifdef USEMGAHAL
- MGA_HAL(
+  MGAPtr pMga = MGAPTR(pScrn);
+  if (pMga-HALLoaded  HAL_CHIPSETS) {
fdIn = fopen(/tmp/mgaDriverIn, rt);
 #ifdef MATROX_WRITEBACK
fdOut = fopen(/tmp/mgaDriverOut, wt);
@@ -3539,7 +3542,7 @@
mode-Flags = 0x7FFF;
return FALSE;
}
-   )
+  }
 #endif
return FALSE; 
 }   else


Re: MGA fixes don't compile

2003-07-01 Thread Dr Andrew C Aitchison
On Tue, 1 Jul 2003, Egbert Eich wrote:

 Dr Andrew C Aitchison writes:
   
260. Disabled mode writeback to client program from MGA driver (Egbert 
   Eich).
   
   This doesn't compile on RedHat 6.2 / egcs-2.91.66
   
 
 Hi Andrew,
 
 Yes, thanks!
 Mattieu already told me. 
 It builds with gcc 3.3 (however issues warnings). I'll 
 commit a little different fix later.
 I have been thinking to remove the Matrox HAL stuff completely
 and tell Matrox to ship this stuff in their binary only driver.
 
 I had to program around so many things in the HALlib.
 Furthermore using our driver with this lib is quite rediculous.
 
 This lib does allmost all initialization. Only the hw cursor, dri
 and accel functions are taken from our driver. 

I'd be very unhappy to lose the HAL;
it helps a lot when getting a G550 to work with DVI monitors.
Some monitors work without it, but others just don't seem to work
unless I use mga_hal_drv.o

I believe that the /tmp/mgaDriverIn/Out stuff is only used by the
MGA PowerDesktop, and I can live without that, but please don't remove 
the HAL.

-- 
Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge
[EMAIL PROTECTED]   http://www.dpmms.cam.ac.uk/~werdna


___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel


Re: MGA fixes don't compile

2003-07-01 Thread Alex Deucher
it's also needed for mergedfb support on mga, although it could
probably be rewritten to not use HAL.

Alex

--- Dr Andrew C Aitchison [EMAIL PROTECTED] wrote:
 On Tue, 1 Jul 2003, Egbert Eich wrote:
 
  Dr Andrew C Aitchison writes:

 260. Disabled mode writeback to client program from MGA driver
 (Egbert 
Eich).

This doesn't compile on RedHat 6.2 / egcs-2.91.66

  
  Hi Andrew,
  
  Yes, thanks!
  Mattieu already told me. 
  It builds with gcc 3.3 (however issues warnings). I'll 
  commit a little different fix later.
  I have been thinking to remove the Matrox HAL stuff completely
  and tell Matrox to ship this stuff in their binary only driver.
  
  I had to program around so many things in the HALlib.
  Furthermore using our driver with this lib is quite rediculous.
  
  This lib does allmost all initialization. Only the hw cursor, dri
  and accel functions are taken from our driver. 
 
 I'd be very unhappy to lose the HAL;
 it helps a lot when getting a G550 to work with DVI monitors.
 Some monitors work without it, but others just don't seem to work
 unless I use mga_hal_drv.o
 
 I believe that the /tmp/mgaDriverIn/Out stuff is only used by the
 MGA PowerDesktop, and I can live without that, but please don't
 remove 
 the HAL.
 
 -- 
 Dr. Andrew C. Aitchison   Computer Officer, DPMMS, Cambridge
 [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna
 
 
 ___
 Devel mailing list
 [EMAIL PROTECTED]
 http://XFree86.Org/mailman/listinfo/devel


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel


Re: MGA fixes don't compile

2003-07-01 Thread Egbert Eich
Dr Andrew C Aitchison writes:
  On Tue, 1 Jul 2003, Egbert Eich wrote:
  
  I'd be very unhappy to lose the HAL;
  it helps a lot when getting a G550 to work with DVI monitors.
  Some monitors work without it, but others just don't seem to work
  unless I use mga_hal_drv.o
  
  I believe that the /tmp/mgaDriverIn/Out stuff is only used by the
  MGA PowerDesktop, and I can live without that, but please don't remove 
  the HAL.
  

OK, you have to know - as you are the MGA maintainer.
I just think it makes the code very ugly. 
It hasn't helped me getting two G450 running in one 
system, either.


Egbert.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel


Re: MGA fixes don't compile

2003-07-01 Thread David Dawes
On Tue, Jul 01, 2003 at 02:55:19PM +0100, Dr Andrew C Aitchison wrote:
On Tue, 1 Jul 2003, Egbert Eich wrote:

 Dr Andrew C Aitchison writes:
   
260. Disabled mode writeback to client program from MGA driver (Egbert 
   Eich).
   
   This doesn't compile on RedHat 6.2 / egcs-2.91.66
   
 
 Hi Andrew,
 
 Yes, thanks!
 Mattieu already told me. 
 It builds with gcc 3.3 (however issues warnings). I'll 
 commit a little different fix later.
 I have been thinking to remove the Matrox HAL stuff completely
 and tell Matrox to ship this stuff in their binary only driver.
 
 I had to program around so many things in the HALlib.
 Furthermore using our driver with this lib is quite rediculous.
 
 This lib does allmost all initialization. Only the hw cursor, dri
 and accel functions are taken from our driver. 

I'd be very unhappy to lose the HAL;
it helps a lot when getting a G550 to work with DVI monitors.
Some monitors work without it, but others just don't seem to work
unless I use mga_hal_drv.o

Maybe the situation would be better if the mga_hal module was limited
to doing just those initialisations that can't, for whatever reasons,
be done in open source.  If I recall correctly, the original reason for
not having this in open source was that enabling the second display on
the G400 couldn't be done without exposing how macrovision could be
disabled (or something like that).

I get the impression that the mga_hal module went beyond what was
originally intended, and it definitely makes a mess of the mga driver,
as Egbert noted.

I believe that the /tmp/mgaDriverIn/Out stuff is only used by the
MGA PowerDesktop, and I can live without that, but please don't remove 
the HAL.

When the PowerDesktop stuff was originally discussed a while back, it
was recommended that it be implemented via a server extension.  That
recommendation was obviously ignored.  What Matrox puts in their own
driver is their business, but it definitely doesn't belong in XFree86
in its current state.

David
-- 
David Dawes
Founder/committer/developer The XFree86 Project
www.XFree86.org/~dawes
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel