antly
> different way.
> Also both of us are quite short on spare time.
That, pretty well, sums it up. And more of GATOS will be merged shortly.
I know I promised earlier to get the merge done before 4.3, but that just
didn't happen, sorry.
Marc.
+---------
;>the function exits
> >>I can provide a patch if wanted
> > Please do.
> Michel, do you have a patch for this. I think this problem has come up in a
> separate instance with multithreaded applications -- it would be good to get
> it resolved.
Please review what I'v
7,6 @@
break;
}
xf86ExecX86int10(pVbe->pInt10);
-return (pVbe->pInt10->ax == 0x4f);
+return (R16(pVbe->pInt10->ax == 0x4f));
}
... should be ...
+return (R16(pVbe->pInt10->ax) == 0x4f);
Marc.
+----------+-
On Thu, 23 Jan 2003, Marc Aurele La France wrote:
> > Does anybody see problems with the attached patch?
> > I think there is some misnaming in the register field names, i.e. instead
> > of "pInt->ax" maybe it should now be called "pInt->eax", anyw
dBIOSBase: %x\n", ret);
> +#endif
> return ret;
> }
>
> /*
> * xf86Bus.c interface
Hummm. Can you re-post that log again? The output from `scanpci -v`
would also help.
Thanks.
Marc.
+--+---+
| Marc Aurele La France
On Fri, 24 Jan 2003, Wayne Whitney wrote:
> On Fri, 24 Jan 2003, Marc Aurele La France wrote:
> > Hummm. Can you re-post that log again? The output from `scanpci -v`
> > would also help.
> OK, I've included three things below: the original log, the output of
>
On Mon, 27 Jan 2003, Wayne Whitney wrote:
> On Mon, 27 Jan 2003, Marc Aurele La France wrote:
> > OK, thanks. Please try the attached.
> That patch works great! Thank you very much.
You're welcome. I'll commit this shortly (meaning that
es
> if (mode == pScr->currentMode)
> return TRUE;
> of the function xf86SwitchMode() in
> xc/programs/Xserver/hw/xfree86/common/xf86Cursor.c (around line 190).
The attached modifies the extension instead. Please try it out.
Marc.
+----------
have been committed.
Thanks.
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]
ou mean depth 24/32? If so, does the problem show in 24/24?
Marc.
+----------+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-492-1729 |
| 352
nomouse.log
Could you narrow this down to the XAA primitive causing the problem? The
driver currently accelerates screen-to-screen copies, solid fills, 8x8
mono pattern fills, scanline CPU-to-screen colour expansion and (other
than for 24bpp) solid lines.
Thanks.
Marc.
+-
onfiguration tools and the command-line
> xf86cfg (even that had the problem so I used xf86cfg -textmode
> -nomodules). So far the only way I've been able to use the card
> productively is by using the vesa driver.
Try Option "LCDSync" in the XF86Config's device
multi-head support for 460GX-based Itanium systems.
(... and hopefully in a day or two, for ZX1-based Itanium2's)
* Experimental support for SunOS/Solaris on UltraSPARC systems.
Marc.
+----------+---+
| Marc Aurele La France
rect way, probably by first querying a function in the core
> server for which way to use.
Just another data point: libGLU compilation on such systems fails also.
Marc.
+--+---+
| Marc Aurele La France | work: 1-780-492-9310
amp; friends as macros.
> We don't build libGLU for libc5-based systems, but I don't have access to
> one (RH 4.2, is one I think -- anyone have a CD image for RH 4.2? I don't
> see one on RH's ftp site.).
I am the one that removed libGLU from libc5 builds. That wa
mpBuffer *j )
> {
> return ::setjmp( j->buf );
> }
> Maybe it depends on the g++ version?
Could be. I'll investigate. Thanks.
Marc.
+--+---+
| Marc Aurele La France | work: 1-780-492-9310
t; (==) ATI(0): Chipset: "ati".
> (**) ATI(0): Depth 16, (--) framebuffer bpp 16
I've committed a change to fix this problem.
Marc.
+--+---+
| Marc Aurele La France | work: 1-780-492-9310 |
ibc5 system, so I'll fix this too.
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 P
c*`
> > < 2.2.2, not 2.2, although a host.def override is available (see
> > xfree86.cf).
Marc.
+--+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Service
On Sun, 2 Mar 2003, David Dawes wrote:
> On Sat, Mar 01, 2003 at 08:27:49PM -0700, Marc Aurele La France wrote:
> >On Sat, 1 Mar 2003, Mark Vojkovich wrote:
> >> setjmp is a *macro* (for __sigsetjmp) defined in /usr/include/setjmp.h.
> >> This is libc 2.2. so it does
On Mon, 3 Mar 2003, Marc Aurele La France wrote:
> On Sun, 2 Mar 2003, David Dawes wrote:
> > On Sat, Mar 01, 2003 at 08:27:49PM -0700, Marc Aurele La France wrote:
> > >On Sat, 1 Mar 2003, Mark Vojkovich wrote:
> > >> setjmp is a *macro* (for __sigsetjmp) de
r for longjmp(). Now my (spoken) C++ is less than
> > adequate, but what the heck does "::" do/mean?
> It means use the global namespace. In this case, it sez to call the setjmp()
> function from the C library.
OK. Thanks.
Marc.
+--------------+---
t affect the building of
libc_wrapper, and it should.
Marc.
+--+-------+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-492-1729 |
| 352 General Services Buil
y.
> As we've seen, the host.def override was incompletely implemented in
> 4.3.0.
Right. The override becomes unnecessary also, so I'll remove it.
BTW, without HAS_GLIBC_SIGSETJMP, we end up with the equivalent to
__sigsetjmp(env, 1). I don't think the discrepancy is ri
ouldn't be seeing any software cursors.
>I hope this is just because I haven't synced up in a few days
Possible. There was an eleventh-hour fix that went in.
> (doesn't build).
Soon. Soon.
Marc.
+------+---+
|
to build.
Try it now.
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]
Version(module) <= Version(core binary)
There are also inter-module dependencies to consider.
Marc.
+--+-----------+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:
s does
not absolve you of the responsibility to ensure the thus-generated binary
works with later core binary versions.
Marc.
+------+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Ne
On Wed, 5 Mar 2003, Marc Aurele La France wrote:
> On Wed, 5 Mar 2003, Kendall Bennett wrote:
> > > > Is that the correct approach? Or should we be building modules for each
> > > > released version of XFree86 (ie: 4.1.0, 4.1.2, 4.1.3, 4.2.0, 4.2.1 etc)?
> >
s regard (and how XFree86 gets around such nonsense).
grsec and facilities like it are based on a false premise: that 'root'
can be broken into is sufficient justification to limit what 'root' can
do, or even to remove entire system functions.
The security pedants should instead concentra
e: *** [xf86cfg] Error 1
> (It works today on Red Hat 8.0 / glibc 2.2.93).
OK. `cvs update` and try again this now.
Marc.
+--------------+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Net
In the meantime, for the sake of your students, please lighten up. The
world is not as evil a place as you make it out to be.
Marc.
+--------------+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Netwo
4.3.0.
> I think this patch may help.
I have committed this fix. Thanks for reporting the problem.
Marc.
+--+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Service
bugzilla ?
Nah.
Marc.
+--+-----------+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-492-1729 |
| 352 General Services Building | em
mdep.h, especially if this system needs
special command line #define's to be recognised.
Marc.
+--------------+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-492-1729
ee.
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 o
nt pre-processors have, in general, different pre-defines. Using a
different pre-processor to generate Makefiles than that used to
pre-process the C source is asking for trouble (and getting it). While
that might not be the case for SCO by some happenstance, it definitely is
on Solaris and IRIX,
someone add this to cvs? it shouldn't be a
> > lot of work.
> I believe this patch was already applied to cvs (HEAD, don't know about
> the branches) a while back.
Not yet, no. But it will be.
Marc.
+------+-----------+
|
On Wed, 9 Jul 2003, Marc Aurele La France wrote:
> CVSROOT: /home/x-cvs
> Module name: xc
> Changes by: [EMAIL PROTECTED] 03/07/09 08:27:41
> Log message:
>300. X.Org IPv6 changes (Bugzilla #227, Alan Coopersmith, Marc La France).
> Se
On Wed, 9 Jul 2003, Alan Coopersmith wrote:
> Marc Aurele La France wrote:
> >>- Incorporate X.Org responses to comments #'s 1, 2, 4, 5, 7, 10, 11, 12,
> >> 13, 14 and 15 (taken from an X.Org-internal document dated 2003.06.17).
> I'm still wo
; parse.c
> which is not consistent, does not look very nice and requires more
> processing by the shell.
... but is still required for portability reasons.
> I have no more arguments, sorry. Please forget the issue if you don't
> agree with my reasoning.
Done.
Marc.
+---
ncluding this change would up
the pressure to deal with the more generic problem.
Marc.
+------+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-492-1729 |
| 352 Gener
are obsoleted and
> replaced by IPV6_{JOIN,LEAVE}_GROUP, that's why I change the values
> used in the code.
> Any comments are welcome before I commit this (or a better version).
Looks good to me.
Marc.
+--+----------
ork.
Done.
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] |
gt; ./xc/programs/xkbcomp/Imakefile:ROOT_DEFINES =
> -DDFLT_XKB_CONFIG_ROOT=\"$(LIBDIR)/xkb\"
> ./xc/programs/xdm/Imakefile:RANDOM_DEFINES = -DDEV_RANDOM=\"/dev/urandom\"
Those are not macro expansions (in the cpp sense).
Marc.
+--+
; included from x11trans.c:80:
> ../../lib/xtrans/Xtranssock.c:338: structure has no member named `ss_family'
> ../../lib/xtrans/Xtranssock.c: At top level:
> ../../lib/xtrans/Xtranssock.c:1315: `MAXHOSTNAMELEN' undeclared here (not in a
> function)
> m
and would
> anyone be heartbroken if I removed that block of code?
Such a patch would be rejected.
Marc.
+--------------+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Ser
On Wed, 9 Jul 2003, Marc Aurele La France wrote:
> > > - libdps needs IPv6 work. Perhaps other things (not included in X.Org's
> > > tree) do also.
> > True. I did not touch DPS at all - I didn't think anyone made a DPS/NX
> > standalone agent th
t's in that one twice. I'll remove the duplicate from my set of patches.
Thanks again, Alan.
Marc.
+----------+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:
uld be a better choice since it's defined by
> > RFC 2133.
> NI_MAXHOST is in /usr/include/netdb.h on RedHat 6.2, 7.3 and 8.0.
> Value 1025 on all three. Do the extra 961 bytes matter ?
RH9 is the same as RH8 in both respects.
Marc.
+------+
ufficient reason to remove it.
Marc.
+--+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-492-1729 |
| 352 General Services Building | email
On Tue, 15 Jul 2003, Nick Hudson wrote:
> On Tuesday 15 July 2003 1:32 pm, Marc Aurele La France wrote:
> [...]
> > I feel that the fact SharedLibObjCompile() is unused in our _current_ tree
> > is insufficient reason to remove it.
> It provides nothing over and above Norm
PIC,
others non-PIC, still others don't care. I forget the details, recalling
instead only that it's not obvious from just perusing the code.
Marc.
+--+-------+
| Marc Aurele La France | work: 1-780-492-9310
one else beating me to it.
Marc.
+--+-------+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-492-1729 |
| 352 General Services Building | email
t's exactly
what socklen_t has been. I'll change it.
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 o
approach espoused by Itojun, Todd, Matthieu and Andrew is better.
Marc.
+----------+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-492-1729 |
| 352 General Services Buil
On Wed, 23 Jul 2003, Egbert Eich wrote:
> Marc Aurele La France writes:
> > I don't like the peppering of this code with more OS #ifdef's. I think
> > the approach espoused by Itojun, Todd, Matthieu and Andrew is better.
> So maybe you can tell what the big differe
[xf86DDC.o] Error 1
> make[6]: Leaving directory
> `/var/tmp/portage/xfree-4.3.99.9/work/xc/programs/Xserver/hw/xfree86/ddc'
This has already been fixed. Update from CVS.
Marc.
+--+-----------+
| Marc Aurele La France
e-4.3.99.9/work/xc/programs/Xserver/hw/xfree86/ddc'
> > This has already been fixed. Update from CVS.
> How much needs to be updated?
> The entire X tree or just the --/xfree86/ddc/ tree?
b)
Marc.
+----------+--
p for inclusion, as this information would be extremely useful in
some logs.
Why the extra symbol, if I may ask, instead merely using defined(linux)?
Marc.
+--+-----------+
| Marc Aurele La France | work: 1-780-492-9310
#x27;t think
SlowBCopy() should continue to assume 0x80 remains free for that purpose
for very much longer, even on ix86, let alone other archs.
Marc.
+------+---+
| Marc Aurele La France | work: 1-780-492-9310 |
able to test for _SC_OPEN_MAX instead of __GNU__.
Marc.
+------+-----------+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-492-1729 |
| 352 General
provide it. The one in libc
is used if provided.
Marc.
+------+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-492-1729 |
| 352 General Services Building | email:
ely stopgaps which I
intend to deprecate.
You seem to be "submitting" a string of old patches, some of them twice.
Why?
The proper patch submission mechanism is patch@, or bugs.xfree86.org.
Marc.
+------+---+
| Marc Aurele
ed. sparcPci.c is already compiled for Linux/Sparc. See lines
114-117.
Marc.
+--+-----------+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-492-1729
the status on the banking layer
> is. Marc La France would know.
There is an example of doing this in the atimisc module when "NoLinear"
and "Accel" are in effect. Start looking in atiscreen.c.
Marc.
+--+---
ed what's in our CVS? There have been a number
of int10-related fixes since 4.3.
Marc.
+--+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-492-1729 |
| 352
t; thingie, but Mike can send a patch to include it if he,
or anyone else, feels that strongly about it.
Marc.
+--+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-49
I don't see how this EFI MDT can be accurate given that, in
general, whether or not a particular PCI memory assignment will tolerate
caching and/or write-combining is highly device-specific. That would be a
horrific PCI device database for EFI to maintain.
Marc.
+
after calling the driver's Sync() function, and change mibank to do
the same after telling the driver to switch banks.
Marc.
+--+---------------+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Networ
pecialCObjectRule(parse,$(_NOOP_),'-DSYSTEM_INIT_FILE="$(TWMDIR)/system.twmrc"')
Yes, that works.
> It's not about commiting this senseless patch, of course :-)
I did so anyway.
Marc.
+--+---+
| Marc A
er, or common module, is not
doing its job.
Marc.
+------+-----------+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-492-1729 |
| 352 General Services Building | email: [EMA
On Thu, 28 Aug 2003, Marc Aurele La France wrote:
> On 28 Aug 2003, John Dennis wrote:
> > On Thu, 2003-08-28 at 12:46, Marc Aurele La France wrote:
> > > Secondly, EFI is already doing the wrong thing by marking PCI ROMs as
> > > non-cacheable. This doesn't insp
On 28 Aug 2003, John Dennis wrote:
> On Thu, 2003-08-28 at 12:46, Marc Aurele La France wrote:
> > Secondly, EFI is already doing the wrong thing by marking PCI ROMs as
> > non-cacheable. This doesn't inspire confidence...
> I believe there is a difference betwee
th architecture #ifdef's. There should be something like a
xf86FlushDataCache(Start, End) function in (or macro provided by) the
common layer.
Marc.
+--+---+
| Marc Aurele La France | work: 1-780-492-9310 |
|
es.
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 o
sure to
> submit the end result for possible inclusion in 4.4.0.
The atimisc module has been VideoRAM specifications for a long time. In
the case of ATI adapters at least, if the driver doesn't properly detect
video memory size, I'd consider it a bug.
Marc.
+---
On Wed, 1 Oct 2003, Marc Aurele La France wrote:
> > My goal is to disable this option by default in drivers which
> > correctly detect video memory on all supported cards, at least
> > for our shipped drivers. I've disabled this setting in our
> > radeon driv
th kernel modules, per se. It's just that XFree86
exists, and has existed, on quite a bit more platforms that just Linux.
Marc.
+--+-----------+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computin
, there
is a distinction to be made between DAC-provided and controller-provided
cursors.
Marc.
+----------+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-49
> interface looking for stuff.
[EMAIL PROTECTED] is an ML anyone can subscribe to. I am, and, I
believe, so is Egbert.
Marc.
+----------+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and N
-+-------+
| 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 +--
#x27;ll look into fixing it too.
Thanks for the report. I'll get back to you.
Marc.
+------+-------+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-492-1729
k a patch for it in our
bugzilla (for inclusion post-4.4 timeframe). If not, base your decision
on whether or not RedHat wants to continue supporting it.
Marc.
+--+---+
| Marc Aurele La France | work: 1-780-492-9310
thanks for reporting the problem.
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
the CPU is maxed out (only when I move
> the windows)
> This means (I guess) that I do not have 2D acceleration.
Not necessarily. Use `top` is figure out which process is "eating up" CPU
time.
Marc.
+--+------------
On Sat, 8 Nov 2003, Marc Aurele La France wrote:
> On Fri, 7 Nov 2003, Salvio Sergi wrote:
> > Everything starts fine with no errors (as you can see from the logs).
> > The problem I have is that I don't think I have 2D acceleration.
> > The simple test I do is to
emes
> and such: I can see the windows being actually redrawn on screen when
> I drag them around the screen.
> FYI: I'm using Red Hat 9 which ships with Gnome. This problem happens
> using Gnome and it is a general problem across all X applications.
If you want help, stop wasting
> I'm testing using two XTerm windows and an empty desktop.
OK.
> what is the meaning of this?
> <>
Replace your XF86Config's videoRam line with Option "BackingStore" "On".
Marc.
+--+---+
|
cause problems on some BSD versions that link threaded
> apps with -lc_r (instead of -lc), and I believe that was one of the main
> reasons for not linking shared libraries against -lc explicitly on these
> platforms.
> I'm not sure what the best answer to all of this is.
So the newer libc isn't
objects.
You can be more selective than that, of course. But, frankly, it's not
worth the effort.
Marc.
+----------+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services |
ch).
I'll be fixing them shortly.
Marc.
+------+-----------+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-492-1729 |
| 352 General Ser
--+
| 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 +-
On Sun, 16 Nov 2003, Salvio wrote:
> I have attached the latest config file and log.
I see no attachments here.
Marc.
+--+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Netw
start two xterms, i.e.
xterm &
xterm &
(That's "xterm", not "gnome-terminal".)
In one of them run top. Move the other xterm around, watching what top
reports. Does CPU utilisation max out when only moving an xterm?
Marc.
+-
it into 4.4, because, among other things,
you are in fact building a case to do that here, which, I believe is
David's point, no?
Marc.
+--+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing
On Thu, 4 Dec 2003, Harald Nordgård-Hansen wrote:
> Marc Aurele La France <[EMAIL PROTECTED]> writes:
> > Log message:
> > An improved implementation of ...
> >573. Rework REGION_* macros to eliminate NEED_SCREEN_REGIONS build failures
> > (Marc La
ted, should now be fixed (or at least after cvsup's next
resync).
Marc.
+--------------+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-492-1729 |
| 352 General Services
ror there. Please forward, to me
privately, a log generated with -logverbose 4.
Thanks.
Marc.
+--+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780
ng. and are _not_ available on
all platforms XFree86 builds on.
Marc.
+--------------+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-492-1729 |
| 352 General Services Bui
1 - 100 of 383 matches
Mail list logo
