On Mon, Mar 22, 2010 at 1:29 PM, LiYe omni.l...@gmail.com wrote:
I'm interested in openGL implementation and the DRI driver development.
Specifically, I want to learn how an OpenGL command was implemented and
how it was converted into direct rendering context and transferred to
the hardware. I
On Mon, Mar 22, 2010 at 2:24 AM, Luc Verhaegen l...@skynet.be wrote:
In
particular, the Mesa core - classic driver split only makes sense if
there are enough people who are actually working on those drivers who
would support the split. Otherwise, this is bound to lead straight
into hell.
In
On Thu, Mar 18, 2010 at 5:38 PM, Luc Verhaegen l...@skynet.be wrote:
So, identify the volatile interfaces, and the more stable interfaces,
and then isolate the volatile ones, and then you come to only one
conclusion.
Except that the Mesa core - classic driver interface also wants to
change
think this patch should be committed, but directly followed by a patch to
reduce the number of registers used.
On 3/18/07, Nicolai Haehnle [EMAIL PROTECTED] wrote:
There were a number of bugs related to the pairing of vector and
scalar operations where swizzles ended up using the wrong source
There were a number of bugs related to the pairing of vector and
scalar operations where swizzles ended up using the wrong source
register, or an instruction was moved forward and ended up overwriting
an aliased register.
The new algorithm for register allocation is slightly conservative and
may
Hello,
back when I was actively working on DRI drivers almost three years
ago, I always felt uneasy about the fact that I didn't have an
extensive array of tests that I could rely on to test for regressions.
Now I've decided to do something about it. I've taken Glean and some
code from Mesa and
On Thursday 29 September 2005 18:30, Alan Cox wrote:
On Iau, 2005-09-29 at 09:49 +0200, Christoph Hellwig wrote:
On Wed, Sep 28, 2005 at 04:07:56PM -0700, Andy Ritger wrote:
Some of the topics raised include:
- minimum OpenGL version required by libGL
- SONAME change to
On Saturday 17 September 2005 16:04, Aapo Tahkola wrote:
On Sat, 17 Sep 2005 09:48:37 -0400 (EDT)
Vladimir Dergachev [EMAIL PROTECTED] wrote:
The user error messages is due to the fact that glxgears sometimes
outputs
insufficient number of vertices to draw a primitive - for example only 2
On Tuesday 21 June 2005 10:54, Jerome Glisse wrote:
On 6/21/05, Vladimir Dergachev [EMAIL PROTECTED] wrote:
On Sat, 18 Jun 2005, Johannes Berg wrote:
Any idea where I should start looking for the source of the lockups or
what else to do?
The problem is likely either due to the radeon
On Tuesday 21 June 2005 18:06, Aapo Tahkola wrote:
On Thu, 16 Jun 2005 14:22:36 +0200
Nicolai Haehnle [EMAIL PROTECTED] wrote:
On Thursday 16 June 2005 13:41, Aapo Tahkola wrote:
Update of /cvsroot/r300/r300_driver/r300
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv6333
On Tuesday 21 June 2005 21:15, Rune Petersen wrote:
Aapo Tahkola wrote:
*snip*
+if (info-ChipFamily = CHIP_FAMILY_R300) {
+ unsigned char *RADEONMMIO = info-MMIO;
+ OUTREG(0x180, INREG(0x180) | 0x1100);
+}
+
0x180 is defined as R300_MC_INIT_MISC_LAT_TIME in r300_reg.h.
This
On Tuesday 21 June 2005 20:57, Vladimir Dergachev wrote:
Now that the driver paints usable pictures without lockups on many cards,
including AGP versions of X800 and Mobility M10, it would make sense to
ready it for inclusion into main DRI codebase.
I do not think that elusive lockups of
On Wednesday 22 June 2005 03:09, Rune Petersen wrote:
Nicolai Haehnle wrote:
Also I remember seeing that the values
are different depending on chip family. Is this safe?
Well, I have tested this on three different chips (R300, rv350 (mobile)
and
R420, which is quite a nice sample
On Saturday 18 June 2005 08:20, Benjamin Herrenschmidt wrote:
On Fri, 2005-06-17 at 18:37 +0200, Jerome Glisse wrote:
Correct value (previous were ones of a dumb test :)):
0x01480xf7fff000 RADEON_MC_FB_LOCATION
0x014c0xfdfffc00 RADEON_MC_AGP_LOCATION
Those
On Thursday 16 June 2005 13:41, Aapo Tahkola wrote:
Update of /cvsroot/r300/r300_driver/r300
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv6333
Modified Files:
r300_reg.h r300_state.c
Log Message:
Use depth tiling.
Will this work with software fallbacks?
cu,
Nicolai
On Friday 10 June 2005 18:10, Vladimir Dergachev wrote:
On Fri, 10 Jun 2005, Aapo Tahkola wrote:
Someone, I believe it was Aapo, said that they see white lines across
the
screen when the framerate is fairly high. I didn't see this up until
yesterday
when I had to change from my
On Friday 10 June 2005 16:52, Aapo Tahkola wrote:
On Fri, 10 Jun 2005 14:31:48 +1000
Ben Skeggs [EMAIL PROTECTED] wrote:
Aapo Tahkola wrote:
Someone, I believe it was Aapo, said that they see white lines across
the
screen when the framerate is fairly high. I didn't see this up until
On Sunday 05 June 2005 15:55, Vladimir Dergachev wrote:
On Sat, 4 Jun 2005, Nicolai Haehnle wrote:
The mirroring works as follows: each time scratch register is written
the
radeon controller uses PCI to write their value to a specific location
in
system memory.
Are you sure
On Sunday 05 June 2005 20:07, Vladimir Dergachev wrote:
My understanding is that dev-agp-base is the address where the AGP
GART
mirrors the pieces of system RAM comprising AGP space.
Yes, that's my understanding, too. But what is the Radeon's business
knowing
that address? Why does it
On Saturday 04 June 2005 15:01, Vladimir Dergachev wrote:
I just wanted to contribute the following piece of information that
might
help with R300 lockups. I do not know whether it applies or not in this
case, but just something to be aware about.
Radeon has a memory controller which
On Friday 03 June 2005 10:28, Aapo Tahkola wrote:
On Thursday 02 June 2005 13:08, Boris Peterbarg wrote:
Aapo Tahkola wrote:
I did some figuring on the CB_DPATH problem.
After little testing it turns out that the lock up with
progs/demos/isosurf goes away when the pacifier sequences
On Friday 03 June 2005 00:25, Benjamin Herrenschmidt wrote:
You guys seem to be getting closer...
When I had X + xfce4 + quake3 running (with this patch +
patch.drm-cmdbuf-more-pacifiers + patch.remove-userspace-pacifiers) X
locked up within 2 minutes.
However, X + quake3 (no
Hello everybody,
today's lockup-chasing wrapup follows :)
Two observations about the lockups I've been seeing:
(1) Lockups are more likely to occur when the ring buffer is filled with
packet2s for alignment (see the attached experimental
patch.drm-align-ring).
(2) Lockups are a lot less
Hi,
On Monday 30 May 2005 08:51, Vladimir Dergachev wrote:
On Mon, 30 May 2005, Bernhard Rosenkraenzer wrote:
Hi,
I've just tried out the r300 driver - works remarkably well for
untested and
broken code.
:))
I've run into 2 bugs though:
It doesn't work well if the display
On Sunday 29 May 2005 02:31, Ben Skeggs wrote:
Morning,
After playing UT2004 for 10 or so minutes, and then quickly checking
some other
apps known to worn, I see no regressions with either patch.
I'll be putting it through some more rigorous testing as the day
progresses, will
report
On Tuesday 24 May 2005 22:54, Jerome Glisse wrote:
On 5/24/05, Nicolai Haehnle [EMAIL PROTECTED] wrote:
Unfortunately, I don't think so. The thing is, all those OUT_RING and
ADVANCE_RING commands do not really call into the hardware immediately;
all
they do is write stuff to the ring
On Wednesday 25 May 2005 17:01, Vladimir Dergachev wrote:
Are you sure the read pointer is still moving 2mins after the lockup?
That
would be rather surprising, to say the least.
I think I can imagine how this might be happenning. You see a lockup from
the driver point of view is when
On Tuesday 24 May 2005 18:33, Adam K Kirchhoff wrote:
Vladimir Dergachev wrote:
Vladimir Dergachev wrote:
In the past I found useful not to turn drm debugging on, but, rather,
insert printk statements in various place in radeon code. This should
also provide more information about
On Sunday 22 May 2005 21:00, Jerome Glisse wrote:
Hi,
I setup a x86 with radeon 9800 pro or xt, trying to find
why it locks. I see little improvement with option no silken
mouse can you test and tell me if it dones anythings for
you (X -nosilk).
My thought on this lockups is that it's
On Saturday 21 May 2005 17:42, Jerome Glisse wrote:
On 5/21/05, Ben Skeggs [EMAIL PROTECTED] wrote:
Also, while I was debugging some problems in ut2004, I noticed that it
re-uses
the same few programs over and over, but they are translated each time.
I'm
thinking about adding a cache
On Thursday 19 May 2005 09:20, Keith Whitwell wrote:
Vladimir Dergachev wrote:
Hi Aapo, Ben, Jerome, Nicolai:
I recently checked fresh code from CVS and was pleasantly surprised
to see that all Quake3 levels that were broken are now perfect - in fact
I cannot find anything that
On Tuesday 17 May 2005 15:47, Brian Paul wrote:
Note that it can be easy to be miss this problem. One way that should
trigger the issue in all drivers is:
1. Make sure that you hit software rasterization fallbacks (e.g.
no_rast=true).
2. Run any GL application in a window and resize
On Friday 13 May 2005 04:45, Jeff Smith wrote:
There is a format/argument mismatch in r300_texprog.c. The format given
is '%d' while
the argument is a char*. This patch corrects the format to '%s'.
Applied to CVS.
cu,
Nicolai
-- Jeff Smith
pgp5MmPtTQEc6.pgp
Description: PGP signature
On Friday 13 May 2005 04:43, Jeff Smith wrote:
There are several places in r300_maos.c where a GLvoid* parameter is more
appropriate
than char*. This patch makes these changes (which also fixes a compiler
warning for me).
Applied to CVS.
cu,
Nicolai
-- Jeff Smith
On Monday 02 May 2005 16:56, Brian Paul wrote:
This weekend I finished updating the DRI drivers to work with the new
framebuffer/renderbuffer changes. My DRI test system is terribly out
of date so I haven't run any tests. I'm tempted to just check in the
changes now and help people fix
On Sunday 01 May 2005 06:41, Vladimir Dergachev wrote:
On Sun, 1 May 2005, Paul Mackerras wrote:
Vladimir Dergachev writes:
* the R300 driver derived from it appears under the same
license due to the notices left over from R200 files
(as we originally thought
On Tuesday 05 April 2005 22:11, Brian Paul wrote:
If you increase MAX_WIDTH/HEIGHT too far, you'll start to see
interpolation errors in triangle rasterization (the software
routines). The full explanation is long, but basically there needs to
be enough fractional bits in the GLfixed
Meh, I originally sent this from the wrong email address, sorry...
On Monday 21 March 2005 12:50, Peter Zubaj wrote:
I just realized something - isn't the application supposed to change
Z test for that ?
I don't know, but all application I tested and which uses alpha test -
has z test
On Monday 21 March 2005 12:50, Peter Zubaj wrote:
I just realized something - isn't the application supposed to change
Z test for that ?
I don't know, but all application I tested and which uses alpha test -
has z test enabled and all displays errors (tuxracer, enemy territory,
fire - from
On Sunday 13 March 2005 23:46, Adam K Kirchhoff wrote:
Adam K Kirchhoff wrote:
I really am confused. This was all working (with my 9200) prior to
reinstalling Debian on my system on Friday. Thankfully it still works
(with drm 1.15.0) on my FreeBSD installation. Not really sure if that
On Sunday 13 March 2005 03:10, Adam K Kirchhoff wrote:
Was it always shared with the USB controller? Can you try changing that?
Some more info for both of you...
I remarked, in an earlier e-mail, that glxgears wouldn't cause the
lockups. That's not true. For whatever reason, it doesn't
On Sunday 06 March 2005 14:15, Adam K Kirchhoff wrote:
Unfortunately, I'm still getting pretty constant lockups that seem to be
related to high framerates. From ppcracer with RADEON_DEBUG set to all:
http://68.44.156.246/ppracer.txt.gz
On the plus side, the texture problem that I had
On Sunday 27 February 2005 23:10, Hamie wrote:
I've added in the pci-id's for the Saphire 9600 AGP card. As it has 2
pci-id's, I've added both to the pciids file, and added it into
radeon_screen, but left the seocnd head commented out on radeon-screen.c
as I'm unsiure whether or not it
On Monday 21 February 2005 17:40, John Clemens wrote:
On Mon, 21 Feb 2005, John Clemens wrote:
give it a go on my fanless 9600se (RV350 AP).
How much memory do you have ? What kind of CPU and motherboard ?
Duron 1.8G, 256MB ddr, old(ish) via km266 motherboard in a shuttle sk41g.
On Tuesday 22 February 2005 21:57, Adam K Kirchhoff wrote:
No luck. I setup my xorg.conf file to limit X to 640x480, and used
xrandr to drop the refresh rate to 60... Launched neverputt at 640x480,
fullscreen. Lockup was nearly instantaneous... The music continues, at
least till
On Saturday 19 February 2005 02:06, Vladimir Dergachev wrote:
I think I found the cause of lockups in VB mode - they were due to cursor
updating function in radeon_mergedfb.c calling OUTREGP() which in turn
called INREG.
When silken mouse is enabled this function could be called at any
On Thursday 17 February 2005 22:34, Rune Petersen wrote:
On my system it works on my X800 with no lockups.
For now I have only tested with glxgears and q3demo.
So I won't be of much help fixing this apart from being a success-vector.
Are there any pattern in what systems works with VB?
I
Hi everybody,
As reported earlier, I had a perfectly repeatable lockup in VB mode that
always happened after the exact same number of frames in glxgears. I can't
explain everything about the lockup, mostly because I still don't know what
the two registers in the begin3d/end3d sequence actually
On Friday 18 February 2005 16:03, Keith Whitwell wrote:
Ben Skeggs wrote:
I still have a 100% reproducable bug which I need to find the cause of,
but time is once again a problem for me. If I move a window over the
top
of a glxgears window my machine locks up immediately, but sysrq still
On Friday 18 February 2005 18:17, Keith Whitwell wrote:
Ben Skeggs wrote:
I'm still rather new at this, so forgive me if this is a bad suggestion.
How about going with option 2, but only submitting the command buffer
anyway if nr_released_bufs != 0.
Would this cause any unwanted side
On Friday 18 February 2005 20:04, Nicolai Haehnle wrote:
There's still at least one hardware lockup bug that can be triggered with
glxgears; unfortunately, this one doesn't seem to be so easily
reproducible.
This bug can be triggered on my machine by a single instance of glxgears. It
seems
Hi,
On Saturday 19 February 2005 00:46, Roland Scheidegger wrote:
There is some problem with driconf, it seems to have some problems
because the driver's name (radeon) does not match what it expects
(r200). Likewise, I couldn't figure out how you'd have 2 separate config
sections for both
On Saturday 19 February 2005 01:05, Adam K Kirchhoff wrote:
Nicolai Haehnle wrote:
Please, everybody, get the latest CVS (anonymous will take some time to
catch up...) and test vertex buffer mode with it (go to r300_run_render()
in r300_render.c and change the #if so that r300_vb_run_render
On Friday 04 February 2005 21:52, Vladimir Dergachev wrote:
On Fri, 4 Feb 2005, Adam Jackson wrote:
Here again, ideally this would get folded upstream too, once it's at
least secure.
I can't really mandate a policy since I haven't been contributing much
to r300, but I would like to hear
On Saturday 29 January 2005 02:47, Dave Airlie wrote:
I've noticed fglrx advertises this for the r200, and doom 3 wants it...
So after I manage to beat fragment_shader into shape, going to have a look
at how to get ARB_vp working.. r300 guys you have something going on this
already?
I
On Monday 10 January 2005 04:42, Vladimir Dergachev wrote:
Update of /cvsroot/r300/r300_driver/r300
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv1824
Modified Files:
r300_render.c
Log Message:
For some reason we need r300Flush when using textures. Perhaps the problem
is
with
Hi,
On Monday 13 December 2004 18:29, Kronos wrote:
Hi,
Makefile in drm/linux-core/ doesn't pass CC to linux kernel build
system. This prevents loading the modules if kernel has been compiled
with a compiler different from the default (ie. gcc).
The following patch add CC to kernel
On Sunday 21 November 2004 04:36, Michael Lothian wrote:
Hi
I'm having problems compiling the r300 Mesa stuff
I get the following errors:
[snip]
Anyone know what's causing this
You have to make sure that the compiler uses the radeon_drm.h from
drm/shared-core in r300 CVS.
cu,
On Wednesday 10 November 2004 08:10, eGore wrote:
Hi list,
I ran into some trouble getting DRI running with r300 (I have no idea if
it is already supported or not), but it didn't work. I looked at xorg's
logfile and found out that DRI was disabled and I also found out that
this is caused by
Hi,
On Saturday 06 November 2004 10:09, Ben Skeggs wrote:
I think the AGP issues *are* related to the lockup. I've just switched
sysloggers, and switched to CVS XServer (was using release 6.8 before).
My previous problems still occurred, but I now seem to have a lot more
debugging
Hi,
On Saturday 06 November 2004 01:04, Ben Skeggs wrote:
Hello,
I've been trying to get the experimental r300.sf.net driver to work on
my machine. I've compiled and installed it ok, but everytime I start
the X server with DRI enabled, the top of the screen is corrupted, which
I'm
Hi,
On Friday 05 November 2004 23:12, Pat Suwalski wrote:
[snip]
I am running the following system:
- AMD 64 fx-51
I'm afraid that this is a very likely culprit, assuming you're running in 64
bit mode. The trouble is that parts of the DRM interface and also some of
the code interfacing the
On Monday 01 November 2004 07:01, Thomas Hellström wrote:
You are probably right, and it would be quite easy to implement such
checks in the via command verifier as long as each lock is associated with
a certain hardware address range.
However, I don't quite see the point in plugging such a
Hi,
First of all, you should really check out the r300_driver module from CVS of
the r300 project on SourceForge, and especially have a look at
docs/r300_reg.h, which is where I put all register information that I and
others have found so far.
On Tuesday 26 October 2004 14:18, Jerome Glisse
On Thursday 28 October 2004 20:11, Roland Scheidegger wrote:
- 0x2284. This one is interesting. The script gives this the name
X_VAP_PVS_WAITIDLE, the driver always emits this right before
R200_SE_VAP_CNTL. Apparently it exists on r200 too. Looks like it forces
the VAP (whatever that stands
On Sunday 24 October 2004 19:38, Bernardo Innocenti wrote:
Even though I just have a Radeon 9200, I'm very excited about the
ongoning R300 effort and with there was a similar project for NVidia
cards too.
If that with above is a wish like I think it probably is, you might want
to have a look
Hi,
shouldn't the inter_module_get(agp) in drm_core_init() be
inter_module_get(drm_agp) instead? drm_agp is what the old (non-core)
DRM uses, and it works for me (unlike agp).
Also, which kernel version do I need for the symbol_get() thing to work?
cu,
Nicolai
pgpF3XicFohtp.pgp
Description:
On Monday 18 October 2004 16:04, Tino Keitel wrote:
On Mon, Oct 18, 2004 at 09:13:57 +0200, Tino Keitel wrote:
[...]
Thanks again. Looks like I used the wrong 2d driver patch before
(xorg680.atipatch.r300). Now the glxinfo output looks right:
OpenGL renderer string: Mesa DRI R300
Hi,
There is disagreement about the meaning of the CLIPSPAN _n parameter in CVS.
The drivers I have looked at and drivers/dri/common/spantmp.h treat _n as
the number of pixels in the span after clipping.
depthtmp.h and stenciltmp.h treat _n as the end+1 x coordinate of the span.
This
Hi,
I have uploaded my changes to the r300_driver CVS. I haven't merged any
changes to the R200 driver that might apply, and I haven't merged the
drm-core changes. I will do that within the next days.
Accelerated color buffer clear and basic clipping (without GL scissors)
works, although I
Hi,
I decided to commit what I have in terms of an R300 driver so far. You can
find You can find it in th r300 project on SourceForge in the r300_driver
module:
cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/r300 checkout
r300_driver
As you can easily see I started with the R200 driver. Since I
On Tuesday 28 September 2004 15:02, Vladimir Dergachev wrote:
On Tue, 28 Sep 2004, Nicolai Haehnle wrote:
Hi Nicolai, you can just rename the driver so it produces r300_dri.so -
the 2d driver is in fact configured to tell DRI clients to use that
binary.
Well, it does produce r300_dri.so
On Monday 27 September 2004 19:00, Barry Scott wrote:
I have failed to find a tar ball of CVS tag that names any
specific version of DRM. What did I miss?
To my knowledge, there is no global DRM version like this. Each driver has
an interface version number, but this number does not
Hi,
I'm trying to completely understand the command buffer stuff for my R300
driver work, and I noticed something about the save_on_next_unlock code.
I'm concerned about the state_atom::check function.
The check functions use the current state of the context to figure out which
atoms must be
Hi,
apparently I'm the first to use a full software fallback for glClear(), as I
ran into a few problems that the attached patch should fix:
- spantmp.h doesn't check for NULL masks
- add a WriteMonoDepthSpan function to the swrast to driver interface
- use this function to clear the depth
Hi,
On Wednesday 22 September 2004 00:45, Dag Bakke wrote:
If I load dri in my xorg.conf, the graphics gets wedged as soon
as I start X. I get more or less garbled stuff from the previous session.
I
can move the cursor, but that's it. I can not exit from X with
ctrl-alt-backspace, or shift
On Sunday 19 September 2004 03:53, Vladimir Dergachev wrote:
Hi Nicolai,
I committed a modification of pretty_print_command_stream.tcl that
decodes most of PFS_INSTR* registers.
It still prints the actual value written - as a last value after
equals
sign. So, I am hoping that
On Tuesday 14 September 2004 17:01, Vladimir Dergachev wrote:
Hi all,
The new project name on SF is R300, the registration just went
through,
so I am in the process of setting things up.
Everyone is welcome ! Also, despite the name, this project is *not*
just about R300. If are
Hi,
while I've had less success (read: hard locks and reboots) with the recently
drmtest and r300_demo, I did use glxtest to find out registers of the R300.
Basically, what I did is run a small GL program, get the command buffer,
make some small changes and rerun. Often, this results in only a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Friday 04 June 2004 12:22, Michel Dnzer wrote:
Currently, if you set the gart size manually higher than what's possible
(set in bios), dri will just get disabled due to missing agp support,
which I consider bad behaviour, and that you get a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tuesday 25 May 2004 23:43, Maurice van der Pot wrote:
The modifications I made to the driver were visible when I executed an
OpenGL app, so I knew it was using the right r200_dri.so. Strangely,
I was unable to get most of the debug prints
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've attached a new version of the patch. This should fix a minor bug: I put
the call to init_timer() too late, which resulted in a kernel warning when
the module was loaded/unloaded without actually being used.
On Sunday 23 May 2004 14:37, Michel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As you may be aware, I was trying to get R300 support into a state where it
is possible to start OpenGL applications, let them hang the CP and *not*
bring down the entire machine.
Looks like I was successful :)
The attached patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Saturday 22 May 2004 16:04, Michel Dnzer wrote:
On Sat, 2004-05-22 at 14:04, Nicolai Haehnle wrote:
It seems to me as if DRM(unlock) in drm_drv.h unlocks without checking
whether the caller actually holds the global lock
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It seems to me as if DRM(unlock) in drm_drv.h unlocks without checking
whether the caller actually holds the global lock. There is no
LOCK_TEST_WITH_RETURN or similar, and the helper function lock_transfer has
no check in it either.
Did I miss
Hi,
browsing the DRI source, I stumbled upon this. I have absolutely no idea
what it does, but this just doesn't look right (drm_drv.h:317)
#ifdef __HAVE_COUNTER15
dev-types[14] = __HAVE_COUNTER14;
#endif
Looks like this should be 15, i.e.
#ifdef __HAVE_COUNTER15
86 matches
Mail list logo
