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
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
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
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
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
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
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
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
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
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
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
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
--- 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
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.
>
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
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
16 matches
Mail list logo