RE: XAA2 namespace?

2004-03-01 Thread Mark Vojkovich
On Mon, 1 Mar 2004, Sottek, Matthew J wrote: > Will there be open discussion of what makes up Xaa? I know > you have already have a working design but rather than accept > major changes wholesale can we discuss the finer points before > they become defacto-accepted. > > -Matt It depends what

Re: XAA2 namespace?

2004-03-01 Thread Mark Vojkovich
On Tue, 2 Mar 2004, Alan Hourihane wrote: > On Mon, Mar 01, 2004 at 04:19:21PM -0800, Mark Vojkovich wrote: > > The current XAA has functions starting with "XAA" and header files > > starting with "xaa". To avoid namespace pollution, the second > > implementation of XAA will need a different n

RE: XAA2 namespace?

2004-03-01 Thread Sottek, Matthew J
Will there be open discussion of what makes up Xaa? I know you have already have a working design but rather than accept major changes wholesale can we discuss the finer points before they become defacto-accepted. -Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED

Re: Multiple Monitors

2004-03-01 Thread Thomas Winischhofer
Alex Deucher wrote: I like Option 1. but either is ok with me. Also, FWIW, a lot of the other mergedfb code could/should be moved into a general mergedfb lib. Stuff like pseudo-xinerama could be folded into the real xinerama extension. some of this work may already be done for the OSX port. AFA

Re: XAA2 namespace?

2004-03-01 Thread Alan Hourihane
On Mon, Mar 01, 2004 at 04:19:21PM -0800, Mark Vojkovich wrote: > The current XAA has functions starting with "XAA" and header files > starting with "xaa". To avoid namespace pollution, the second > implementation of XAA will need a different namespace. It seems > good to avoid calling it any

Re: XAA2 namespace?

2004-03-01 Thread Thomas Winischhofer
Mark Vojkovich wrote: The current XAA has functions starting with "XAA" and header files starting with "xaa". To avoid namespace pollution, the second implementation of XAA will need a different namespace. It seems good to avoid calling it anything with a '2' in the name. I'm leaning towards

Re: XAA2 namespace?

2004-03-01 Thread Alan Hourihane
On Mon, Mar 01, 2004 at 04:19:21PM -0800, Mark Vojkovich wrote: > The current XAA has functions starting with "XAA" and header files > starting with "xaa". To avoid namespace pollution, the second > implementation of XAA will need a different namespace. It seems > good to avoid calling it any

Re: Multiple Monitors

2004-03-01 Thread Thomas Winischhofer
Alan Hourihane wrote: I'm looking to enhance the parser in XFree86 so that a lot of redundant code in the current drivers that implement the 'mergedfb' mode can be eliminated such that they don't have to do all the monitor munging in the driver. So here's two variants of the modifications to the XF

Re: Multiple Monitors

2004-03-01 Thread Alan Hourihane
On Mon, Mar 01, 2004 at 04:11:02PM -0800, Mark Vojkovich wrote: > And please don't break binary compatibility with drivers who > parse the current Monitor info in the ScrnInfoRec. Absolutely, that is a main priority, as is allowing the new XFree86 server to still parse older XF86Config files. Ala

XAA2 namespace?

2004-03-01 Thread Mark Vojkovich
The current XAA has functions starting with "XAA" and header files starting with "xaa". To avoid namespace pollution, the second implementation of XAA will need a different namespace. It seems good to avoid calling it anything with a '2' in the name. I'm leaning towards "Xaa" for the functio

Re: Multiple Monitors

2004-03-01 Thread Mark Vojkovich
On Mon, 1 Mar 2004, Alan Hourihane wrote: > I'm looking to enhance the parser in XFree86 so that a lot of redundant > code in the current drivers that implement the 'mergedfb' mode can > be eliminated such that they don't have to do all the monitor munging > in the driver. > > So here's two varia

Re: Multiple Monitors

2004-03-01 Thread Alan Hourihane
On Mon, Mar 01, 2004 at 02:57:50PM -0800, Alex Deucher wrote: > --- Alan Hourihane <[EMAIL PROTECTED]> wrote: > > I'm looking to enhance the parser in XFree86 so that a lot of > > redundant > > code in the current drivers that implement the 'mergedfb' mode can > > be eliminated such that they don't

Re: Multiple Monitors

2004-03-01 Thread Alex Deucher
--- Alan Hourihane <[EMAIL PROTECTED]> wrote: > I'm looking to enhance the parser in XFree86 so that a lot of > redundant > code in the current drivers that implement the 'mergedfb' mode can > be eliminated such that they don't have to do all the monitor munging > in the driver. > > So here's two

Re: Multiple Monitors

2004-03-01 Thread Alan Hourihane
On Mon, Mar 01, 2004 at 10:10:40PM +, Alan Hourihane wrote: > I'm looking to enhance the parser in XFree86 so that a lot of redundant > code in the current drivers that implement the 'mergedfb' mode can > be eliminated such that they don't have to do all the monitor munging > in the driver. >

Multiple Monitors

2004-03-01 Thread Alan Hourihane
I'm looking to enhance the parser in XFree86 so that a lot of redundant code in the current drivers that implement the 'mergedfb' mode can be eliminated such that they don't have to do all the monitor munging in the driver. So here's two variants of the modifications to the XF86Config I'm thinking

Re: XFree86 4.4.0 RC3 -configure problems

2004-03-01 Thread Marc Aurele La France
On Fri, 27 Feb 2004 [EMAIL PROTECTED] wrote: > I have a couple of problems when running XFree86 -configure on Solaris > 2.5.1 x86, with two Matrox G450 cards. > The first is that it exits with: >Fatal server error: >xf86MapVidMem: mmap failure: No such device or address > I have deter