Re: XAA2 namespace?

2004-04-06 Thread Andrew C Aitchison
On Tue, 6 Apr 2004, Mark Vojkovich wrote:

> I saw changes coming to the X world that I didn't like and started
> moving away from it a while ago.

> Pardon that public reply folks.  I mistakenly replied to the list
> rather than just to Alan like I intended.

If you don't mind answering anyway...

Are these undesirable changes related to XFree86 or to X in general ?
If they relate to X in general, what are they ?

-- 
Andrew C. Aitchison Cambridge
[EMAIL PROTECTED]


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


Re: XAA2 namespace?

2004-04-06 Thread Mark Vojkovich
  Pardon that public reply folks.  I mistakenly replied to the list
rather than just to Alan like I intended.


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


Re: XAA2 namespace?

2004-04-06 Thread Mark Vojkovich
On Tue, 6 Apr 2004, Alan Hourihane wrote:

> Mark,
>
> What's the current status of the new xaa ??

   Not much has changed.  I've been busy with work and lately
haven't been too motivated to work on it anyhow.  I don't even
work on X stuff at NVIDIA anymore.  I saw changes coming to the
X world that I didn't like and started moving away from it a
while ago.  I work on embedded stuff now.


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


Re: license statements in CVS commit messages

2004-04-06 Thread David Dawes
On Tue, Apr 06, 2004 at 09:05:06AM -0700, Alan Coopersmith wrote:
>I notice many of the affected files do not bear the license notice
>mentioned in the checkin notice.  Is that intentional?  Will everyone
>investigating the license that applies to a file now have to check
>every CVS commit log entry for that file as well as the file itself
>to find out which license applies?

Assume that anything attributed to me is covered by the 1.1 licence
unless explicitly stated otherwise.

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


Re: (patch seq: 6202) XFree86-4.4.0 -- IPv6 support causes serious problems

2004-04-06 Thread Marc Aurele La France
On Mon, 5 Apr 2004, Peter Breitenlohner wrote:

> > > > Note: The change in xdmcp.c(NetworkAddressToHostname) is quite a kludge,
> > > > but somehow I got tired to further nail down what goes wrong. There is a
> > > > comment in the code to that effect and explaining exactly what went wrong.

> > > One reason the affected code doesn't work could be that the memcmp part of
> > > the condition ending the loop appears inverted, a fix for which (s/!=/==/)
> > > I've now committed.  Please verify.

> yes, that was it. I have revoked my changes to xc/programs/xdm/xdmcp.c
> lines ca. 1420ff (patch-16-IPv6, kludge) and instead fixed the (s/!=/==/)
> and this works for us, except on the notebooks without network connection.

> When I have some time during the easter hollidays I'll try to figure out
> that last problem.

OK.  Thanks for getting back to me on that.

Marc.

+--+---+
|  Marc Aurele La France   |  work:   1-780-492-9310   |
|  Computing and Network Services  |  fax:1-780-492-1729   |
|  352 General Services Building   |  email:  [EMAIL PROTECTED]  |
|  University of Alberta   +---+
|  Edmonton, Alberta   |   |
|  T6G 2H1 | Standard disclaimers apply|
|  CANADA  |   |
+--+---+
XFree86 developer and VP.  ATI driver and X server internals.

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


Re: XAA2 namespace?

2004-04-06 Thread Alan Hourihane
Mark,

What's the current status of the new xaa ??

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


Re: elographics problem

2004-04-06 Thread Tristan Van Berkom
David L wrote:
I sent this to the general xfree86 mailing list but received no 
responses.  I think there is a bug with the elographics driver:
[snip]

Hi David,
This is a bug in xf86Elo.c (or a bug that I personaly fixed
in a local copy of that file).
The problem is that this driver reads exactly one packet from the
port every time the driver's ReadInput function is called, so if
the server revieves a third SIGIO before the input module has finished
posting events for the first packet, then we are exactly one packet
out of sync. It is possible for a mouse module to adapt the same
functionality without visible errors because mouse coordinates are
relative, but touchscreen coordinates are absolute.
My patch is significantly outdated, essentialy my fix is to loop
over serial packets untill no data is readable on the port instead
of assuming one packet (although I guess it may be more appropriate
to drop all packets except the last one on the port; to avoid possibly
useless spamming).
At a glance, this piece of code in current CVS:
(ReadInput method)
===
  /*
   * Try to get a packet.
   */
  if (xf86EloGetPacket(priv->packet_buf,
   &priv->packet_buf_p,
   &priv->checksum,
   local->fd) != Success) {
return;
  }
===
Can be changed to:
===
  while (xf86EloGetPacket(priv->packet_buf,
   &priv->packet_buf_p,
   &priv->checksum,
   local->fd) == Success) {
 /*
Code body
  */
===
Good luck!
 -Tristan
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel


elographics problem

2004-04-06 Thread David L
I sent this to the general xfree86 mailing list but received no responses.  
I think there
is a bug with the elographics driver:

I'm using XFree86 Version 4.4.0 (with circa redhat6.2 libraries and linux 
kernel 2.6.4)
with an ELO touchscreen (elo2300 I think).  If I have a "real-time" high 
priority (SCHED_FIFO)
task that periodically sucks a lot of CPU time, the ELO touch interface 
falls behind.  Once
it's behind, it stays behind, even if I kill the high priority task.  It 
seems to have a queue of
data that doesn't get serviced unless a new event happens.

For example, say that during a period when the CPU is being hogged, I try to 
move
the pointer in a big clockwise circle multiple times.  Then I kill the CPU 
hog process.
The pointer does not start moving to catch up when the CPU hog dies.  It 
just sits there
at its last location.  If I wait 5 minutes and then touch the screen, the 
pointer starts
moving in the circle that my finger followed 5 minutes earlier.  When I stop 
touching the
screen, the pointer stops.  If I touch it again, it continues following my 
earlier finger
motion.  It seems to slowly catch up if I continue interacting with the 
screen.

If I have a mouse in addition to the touchscreen, movement of the mouse also 
causes
the pointer to service the events in the elo touchscreen queue and at a much 
faster
rate.  However, motion of the mouse during the time that the CPU is being 
hogged
does not seem to fall behind the way the touchscreen does.

Thanks:

  David

_
MSN Toolbar provides one-click access to Hotmail from any Web page – FREE 
download! http://toolbar.msn.com/go/onm00200413ave/direct/01/

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


license statements in CVS commit messages

2004-04-06 Thread Alan Coopersmith
I notice many of the affected files do not bear the license notice
mentioned in the checkin notice.  Is that intentional?  Will everyone
investigating the license that applies to a file now have to check
every CVS commit log entry for that file as well as the file itself
to find out which license applies?
-Alan Coopersmith-   [EMAIL PROTECTED]
 Sun Microsystems, Inc. - X Window System Engineering
David Dawes wrote:
CVSROOT:/home/x-cvs
Module name:xc
Changes by: [EMAIL PROTECTED]   04/03/17 23:07:14
Log message:
  A second invocation of 'make' shouldn't change anything.
  
  --
  These changes are Copyright (c) 2004 The XFree86 Project, Inc
  Rights as per version 1.1 of the XFree86 License
  (http://www.xfree86.org/legal/licenses.html).

Modified files:
  xc/config/cf/:
Imake.rules OpenBSDLib.rules X11.tmpl bsdLib.rules 
lnxLib.rules 
  xc/fonts/scaled/Type1/:
Imakefile 
  xc/lib/GL/GL/:
Imakefile 
  xc/lib/GL/apple/:
Imakefile 
  xc/lib/GL/dri/:
Imakefile 
  xc/lib/GL/dri/drm/:
Imakefile 
  xc/lib/GL/glx/:
Imakefile 
  xc/lib/GL/mesa/src/:
Imakefile 
  xc/lib/GL/mesa/src/OSmesa/:
Imakefile 
  xc/lib/GL/mesa/src/SPARC/:
Imakefile 
  xc/lib/GL/mesa/src/X/:
Imakefile 
  xc/lib/GL/mesa/src/X86/:
Imakefile 
  xc/lib/GL/mesa/src/array_cache/:
Imakefile 
  xc/lib/GL/mesa/src/drv/common/:
Imakefile 
  xc/lib/GL/mesa/src/drv/ffb/:
Imakefile 
  xc/lib/GL/mesa/src/drv/gamma/:
Imakefile 
  xc/lib/GL/mesa/src/drv/i810/:
Imakefile 
  xc/lib/GL/mesa/src/drv/i830/:
Imakefile 
  xc/lib/GL/mesa/src/drv/mga/:
Imakefile 
  xc/lib/GL/mesa/src/drv/r128/:
Imakefile 
  xc/lib/GL/mesa/src/drv/r200/:
Imakefile 
  xc/lib/GL/mesa/src/drv/radeon/:
Imakefile 
  xc/lib/GL/mesa/src/drv/sis/:
Imakefile 
  xc/lib/GL/mesa/src/drv/tdfx/:
Imakefile 
  xc/lib/GL/mesa/src/math/:
Imakefile 
  xc/lib/GL/mesa/src/swrast/:
Imakefile 
  xc/lib/GL/mesa/src/swrast_setup/:
Imakefile 
  xc/lib/GL/mesa/src/tnl/:
Imakefile 
  xc/lib/GL/mesa/src/tnl_dd/:
Imakefile 
  xc/lib/font/FreeType/module/:
Imakefile 
  xc/lib/font/Speedo/module/:
Imakefile 
  xc/lib/font/Type1/module/:
Imakefile 
  xc/lib/font/X-TrueType/module/:
Imakefile 
  xc/lib/font/bitmap/module/:
Imakefile 
  xc/nls/:
Imakefile 
  xc/nls/Compose/:
Imakefile 
  xc/nls/XI18N_OBJS/:
Imakefile 
  xc/nls/XLC_LOCALE/:
Imakefile 
  xc/programs/Xserver/GL/:
Imakefile 
  xc/programs/Xserver/GL/dri/:
Imakefile 
  xc/programs/Xserver/GL/glx/:
Imakefile 
  xc/programs/Xserver/GL/mesa/GLcore/:
Imakefile 
  xc/programs/Xserver/GL/mesa/GLcore/module/:
Imakefile 
  xc/programs/Xserver/XTrap/module/:
Imakefile 
  xc/programs/Xserver/Xext/extmod/:
Imakefile 
  xc/programs/Xserver/afb/:
Imakefile 
  xc/programs/Xserver/cfb/:
Imakefile.inc 
  xc/programs/Xserver/dbe/module/:
Imakefile 
  xc/programs/Xserver/fb/:
Imakefile 
  xc/programs/Xserver/hw/xfree86/:
Imakefile 
  xc/programs/Xserver/hw/xfree86/ddc/:
Imakefile 
  xc/programs/Xserver/hw/xfree86/drivers/apm/:
Imakefile 
  xc/programs/Xserver/hw/xfree86/drivers/ark/:
Imakefile 
  xc/programs/Xserver/hw/xfree86/drivers/ati/:
Imakefile 
  xc/programs/Xserver/hw/xfree86/drivers/chips/:
Imakefile 
  xc/programs/Xserver/hw/xfree86/drivers/cirrus/:
Imakefile 
  xc/programs/Xserver/hw/xfree86/drivers/cyrix/:
Imakefile 
  xc/programs/Xserver/hw/xfree86/drivers/dummy/:
Imakefile 
  xc/programs/Xserver/hw/xfree86/drivers/fbdev/:
Imakefile 
  xc/programs/Xserver/hw/xfree86/drivers/glide/:
Imakefile 
  xc/programs/Xserver/hw/xfree86/drivers/glint/:
Imakefile 
  xc/programs/Xserver/hw/xfree86/drivers/i128/:
Imakefile 
  xc/programs/Xserver/hw/xfree86/drivers/i740/:
Imakefile 
  xc/programs/Xserver/hw/xfree86/drivers/i810/:
Imakefile 
  xc/programs/Xserver/hw/xfree86/drivers/imstt/:
Imakefile 
  xc/programs/Xserver/hw/xfree86/drivers/mga/:
Imakefile 
  xc/programs/Xserver/hw/xfree86/drivers/neomagic/:
Imakefile 
  xc/programs/Xserver/hw/xfree86/drivers/newport/:
Imakefile 
  xc/programs/Xserver/hw/xfree86/drivers/nsc/:
Imakefile 
  xc/programs/Xserver/hw/xfree86/drivers/nv/:
Imakefile 
  xc/programs/Xserver/hw/xfree86/drivers/rendition/:
Imakefile 
  xc/programs/Xserver/hw/xfree86/