On Sat, 2004-09-04 at 16:36 -0400, Patrick McFarland wrote:
> On Sat, 04 Sep 2004 14:14:55 -0400, Michel DÃnzer <[EMAIL PROTECTED]> wrote:
> > What version of the DRI driver?
>
> Where do I look for that?
Where did you get r200_dri.so from?
--
Earthling Michel DÃnzer | Debian (powerpc
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=1003
--- Additional Comments From [EMAIL PROTECTED] 2004-09-04 19:06 ---
looks like
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=1003
--- Additional Comments From [EMAIL PROTECTED] 2004-09-04 18:09 ---
Created an
I realized, that from a snapshot point of view, it would be easy to cope
with a separate library module + additional binary interface. As far as
I gathered the main argument against another binary interface is that
upgrading one driver would break the other ones that may still be
installed on the s
El SÃbado, 4 de Septiembre del 2004 11:06 PM, Lee Revell escribiÃ:
> OK, please explain how I install the latest Unichrome DRI driver. The
> docs at the unichrome site are correct except they refer to this guide
> which is out of date:
>
> http://dri.sourceforge.net/cgi-bin/moin.cgi/Building
Yes,
On Sat, Sep 04, 2004 at 11:17:40PM +0100, Dave Airlie wrote:
>
> Actually after sleeping on this, I've just realised technically whether
> the code is in a core separate module or driver module is only going to
> affect maybe 5% of the work and the Makefiles/Kconfig at the end, so
> following the
Actually after sleeping on this, I've just realised technically whether
the code is in a core separate module or driver module is only going to
affect maybe 5% of the work and the Makefiles/Kconfig at the end, so
following the principles of a)least surprise, b) kernel must remain
stable, I think I
On Sat, 04 Sep 2004 14:31:16 -0700, Eric Anholt <[EMAIL PROTECTED]> wrote:
> You mean all the rearchitecting you've been doing to make the driver
> behave like it actually attaches to specific device? Yeah, BSD has
> wanted that since the very beginning. I just never implemented it
> because I di
>
> How about getting the VIA DRI module into the kernel?
As soon as it is secure it goes in, the VIA DRI developers are working on
it at the moment, and it should be suitable for merging soon...
we also have out of kernel DRM drivers for mach64 and savage that would
pose security issues if shipp
On Sat, 2004-09-04 at 07:42, Dave Jones wrote:
> If dri stuff isn't getting into distros fast enough, take it up with the
> distros. For Fedora at least, we have a very quick turnaround right now.
How about getting the VIA DRI module into the kernel?
Lee
--
On Sat, 2004-09-04 at 07:26, Christoph Hellwig wrote:
> On Sat, Sep 04, 2004 at 12:24:32PM +0100, Dave Airlie wrote:
> > >
> > > A user without a clue should better be using a supported distribution.
> > > If he used Fedora Core2 instead of the totally outdated and unsupported
> > > RH9 he'd alread
On Sat, 2004-09-04 at 08:25, Christoph Hellwig wrote:
> Okay, let's take Debian stable as an example. How do you get an agpgart
> that deals with the i915 into the 2.4.18 kernel woody ships?
The same way you demonstrate that the driver you just wrote is stable.
Run it for a few years and get bac
On Sat, 2004-09-04 at 08:59, Jon Smirl wrote:
> On Sat, 4 Sep 2004 17:43:13 +0200, Simon 'corecode' Schubert
> <[EMAIL PROTECTED]> wrote:
> > I think David Airlie broke it already before. Yes I am using DRM on
> > DragonFlyBSD and yes there are lots of people who'd like to use it on
> > *BSD too. I
On Fri, 2004-09-03 at 23:04, Jon Smirl wrote:
> We're going to have to work out a GPL/BSD solution for the fbdev
> merge. There are 80,000 lines of code in the fbdev directory. It is
> impractical to rewrite them. It's probably also impractical to
> relicense the fbdev code BSD since we would have
On Sat, 2004-09-04 at 06:54, Dave Airlie wrote:
> >
> > Just out of interest, what would the scenario be if you do if you could
> > get a compatible driver?
>
> It's one of the major successes I feel of the DRI project, those
> snapshots allowed people with Radeon IGP chipsets to get 3d accelerati
On Sat, 04 Sep 2004 14:14:55 -0400, Michel Dänzer <[EMAIL PROTECTED]> wrote:
> What version of the DRI driver?
Where do I look for that?
--
Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED]
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd
all be running around in
On Fri, 3 Sep 2004 18:25:10 -0700 (PDT), Jon Smirl <[EMAIL PROTECTED]> wrote:
> --- Dave Airlie <[EMAIL PROTECTED]> wrote:
> > >
> > > Will this redesign allow for multiple 3d accelerated cards in the
> > same
> > > machine? could I have say an AGP radeon and a PCI radeon or a AGP
> > > matrox and
.tar.bz2
savage-20040904-linux.i386.tar.bz2
Kernel 2.6.5-7.108 (SuSE) with preempt and DRI enabled.
grep bpp /var/log/XFree86.0.log
(++) SAVAGE(0): Depth 24, (++) framebuffer bpp 32
(--) Depth 24 pixmap format is 32 bpp
(II) SAVAGE(0): [drm] bpp: 32 depth: 24
(II) SAVAGE(0): bpp:32
On Sat, 2004-09-04 at 05:16 -0400, Patrick McFarland wrote:
>
> All of this was tested with a virgin 2.6.8.1 (with debug info and
> frame pointers enabled) and Debian's XFree86 4.3.0.1, [...]
What version of the DRI driver?
--
Earthling Michel DÃnzer | Debian (powerpc), X and DRI deve
On Sat, 04 Sep 2004 18:43:16 +0100, Keith Whitwell
<[EMAIL PROTECTED]> wrote:
> > You may think that X on GL (gnuLonghorn) is a crazy idea. But
> > comptetive pressures from the Mac and Longhhorn will force us into
> > doing it so or later. I'd rather do it sooner.
> >
>
> Not a crazy idea at all,
Jon Smirl wrote:
On Sat, 04 Sep 2004 14:52:35 +0100, Keith Whitwell
<[EMAIL PROTECTED]> wrote:
Currently we have to perform two merges and three releases to get a driver to
a users:
Merge DRM CVS --> LK
Release stable kernel --> Picked up by vendor
Release stable Mesa 3D
Jon Smirl wrote:
On Sat, 04 Sep 2004 08:36:38 +0100, Keith Whitwell
<[EMAIL PROTECTED]> wrote:
Jon Smirl wrote:
Would this work? drm/shared and drm/bsd directories are BSD licensed.
drm/linux is GPL licensed.
This just isn't true. What on earth makes you think this? Read the license
before you m
On Sad, 2004-09-04 at 13:04, Dave Airlie wrote:
> I've got nothing to do with Tungsten whatsoever, I've never met any of the
> other major DRI developers, my worries here is this is turning into a
> company issue, people keep mentioning Fedora this and that, Fedora is one
> distro, I happen to use
On Saturday 04 September 2004 11:43 am, Simon 'corecode' Schubert wrote:
> On 04.09.2004, at 08:04, Jon Smirl wrote:
> > So what do we do about FreeBSD? For example I need to bring in the I2C
> > and mode setting code from the GPL fbdev radeon driver into the DRM
> > one. I don't want to rewrite a
On Sat, 04 Sep 2004 08:36:38 +0100, Keith Whitwell
<[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
>
> > Would this work? drm/shared and drm/bsd directories are BSD licensed.
> > drm/linux is GPL licensed.
>
> This just isn't true. What on earth makes you think this? Read the license
> before you
On Sat, 4 Sep 2004 17:43:13 +0200, Simon 'corecode' Schubert
<[EMAIL PROTECTED]> wrote:
> I think David Airlie broke it already before. Yes I am using DRM on
> DragonFlyBSD and yes there are lots of people who'd like to use it on
> *BSD too. I just didn't want to stomp right in and scream "you brea
Am Samstag, 4. September 2004 17:36 schrieb Jon Smirl:
> On Sat, 04 Sep 2004 14:52:35 +0100, Keith Whitwell
>
> <[EMAIL PROTECTED]> wrote:
> > Currently we have to perform two merges and three releases to get a
> > driver to a users:
> If DRM went into a kernel development model
>
> R
On Sat, 4 Sep 2004 08:52:00 +0100 (IST), Dave Airlie <[EMAIL PROTECTED]> wrote:
>
> > We're going to have to work out a GPL/BSD solution for the fbdev
> > merge. There are 80,000 lines of code in the fbdev directory. It is
> > impractical to rewrite them. It's probably also impractical to
> > reli
On 04.09.2004, at 08:04, Jon Smirl wrote:
So what do we do about FreeBSD? For example I need to bring in the I2C
and mode setting code from the GPL fbdev radeon driver into the DRM
one. I don't want to rewrite a 1,000 lines of working driver code.
How many DRM users are there on FreeBSD? I've only
On Sat, 04 Sep 2004 14:52:35 +0100, Keith Whitwell
<[EMAIL PROTECTED]> wrote:
> Currently we have to perform two merges and three releases to get a driver to
> a users:
>
> Merge DRM CVS --> LK
> Release stable kernel --> Picked up by vendor
> Release stable Mesa 3D
>
Dave Jones wrote:
On Sat, Sep 04, 2004 at 01:08:26PM +0100, Keith Whitwell wrote:
> So, we are coming out of a period of history where it was extremely
> difficult to get our drivers to users through the 'official' channels - to
> the extent that many people have given up on the possibility of
On Sat, Sep 04, 2004 at 11:54:06AM +0100, Dave Airlie wrote:
> >
> > Just out of interest, what would the scenario be if you do if you could
> > get a compatible driver?
>
> you just grab a DRI snapshot which contains new userspace and DRM, and
> install it... it builds the DRM against your curren
> > properly with the core...
>
> or they just ship their own matching core .c file as well
>
> Lets face it, for the core there are 2 things that are entirely at
> conflicts: small interface and core being useful.
> I rather go for the useful side myself.
It's still useful, it just is built i
>
> Again, how is drm different from scsi or net or whatever drivers except
> that you need a big userlevel component aswell?
Well I've always wondered why I couldn't download drivers for my i845 on
board soundcard for Redhat 9 (back when it was a supported distro), why
the hell did I need to go i
Dave Jones wrote:
On Sat, Sep 04, 2004 at 01:04:17PM +0100, Dave Airlie wrote:
> releases, I would like to give those people a chance to use their graphics
> cards, and the snapshots are not the only way, Intel have i915 Linux
> drivers on their site from TG, they work on most kernels/distros, I
> If we make a library split that sits inside the kernel, their DRM can
> stop working if someone busts the interface, hence the idea of having the
> core reg/dereg in the kernel, and locking it down, then they can ship a
> complete DRM source tree, and do as they wish as long as they interface
>
On Sat, Sep 04, 2004 at 01:04:17PM +0100, Dave Airlie wrote:
> I've got nothing to do with Tungsten whatsoever, I've never met any of the
> other major DRI developers, my worries here is this is turning into a
> company issue, people keep mentioning Fedora this and that, Fedora is one
> distro, I h
On Sat, Sep 04, 2004 at 01:17:54PM +0100, Dave Airlie wrote:
> Lets take an example, I'm DA graphics card vendor, I write a DRI driver
> for my brand new 3d graphics cards (they rock btw :-), people buy loads of
> them, I want to give them something on my website that they can deploy to
> use their
On Sat, Sep 04, 2004 at 01:08:26PM +0100, Keith Whitwell wrote:
> So, we are coming out of a period of history where it was extremely
> difficult to get our drivers to users through the 'official' channels - to
> the extent that many people have given up on the possibility of them
> working
>
> Are you suggesting for instance, that RedHat might pick up individual drivers
> out of Xorg or better still Mesa, rather than waiting for a full stable
> release? That would probably be the biggest help - by comparison kernel
> releases are very frequent.
Lets take an example, I'm DA graphics
On Sat, Sep 04, 2004 at 01:04:17PM +0100, Dave Airlie wrote:
> releases, I would like to give those people a chance to use their graphics
> cards, and the snapshots are not the only way, Intel have i915 Linux
> drivers on their site from TG, they work on most kernels/distros, I get a
> machine
Dave Jones wrote:
There's already a per-distro mechanism to make all this all nice and
transparent to end-users. In Fedora, we even have 3 (apt-get/yum/up2date).
The problem is when 3rd parties like the DRI project expect users not to
use the tools they are familiar with, and expect them to run of
> Even if you are not speaking for Thungesten you pretty much show that
> Thungsten has developers that in an area that overlaps with their works are
> not willing to get things done the kernel way.
I don't know if you anyone can claim the "kernel way" except Linus, if he
decideds our argument is
On Sat, Sep 04, 2004 at 12:41:40PM +0100, Keith Whitwell wrote:
> > > >Download a new kernel.org kernel or petition the fedora legacy folks to
> > > >include a drm update. The last release RH-9 kernel has various
> > security
> > > >and data integrity issues anyway, so you'd be a fool to kee
Dave Jones wrote:
If dri stuff isn't getting into distros fast enough, take it up with the
distros. For Fedora at least, we have a very quick turnaround right now.
Indeed. Maybe it's time to try again. There will always be a lag, though,
and the binary snapshots were only ever intended as a mec
On Sat, Sep 04, 2004 at 12:41:40PM +0100, Keith Whitwell wrote:
> Please don't think that I'm talking for Tungsten at this or any other time on
> the DRI list. I'm talking for myself and have never attempted to convey here
> or elsewhere a "company" view without explictly flagging it up as such.
Christoph Hellwig wrote:
On Sat, Sep 04, 2004 at 12:30:33PM +0100, Keith Whitwell wrote:
So, I've got this file "patch-2.6.8.1.bz2". Lets suppose my older brother
comes in & compiles it up for me & I'm now running 2.6.8.1 - it's implausible
I know, but let's make it easier for you. Now, why isn
On Sat, Sep 04, 2004 at 12:12:31PM +0100, Dave Airlie wrote:
> > > OK, I've found www.kernel.org, and clicked on the 'latest stable kernel' link.
> > > I got a file called "patch-2.6.8.1.bz2". I tried to install this but
> > > nothing happened. My i915 still doesn't work. What do I do now?
Dave Jones wrote:
On Sat, Sep 04, 2004 at 11:30:54AM +0100, Keith Whitwell wrote:
> >>Sure, explain to me how I should upgrade my RH-9 system to work on my new
> >>i915?
> >
> >Download a new kernel.org kernel or petition the fedora legacy folks to
> >include a drm update. The last release R
On Sat, Sep 04, 2004 at 12:30:33PM +0100, Keith Whitwell wrote:
> >>So, I've got this file "patch-2.6.8.1.bz2". Lets suppose my older brother
> >>comes in & compiles it up for me & I'm now running 2.6.8.1 - it's implausible
> >>I know, but let's make it easier for you. Now, why isn't my i915 wo
Christoph Hellwig wrote:
On Sat, Sep 04, 2004 at 12:18:24PM +0100, Keith Whitwell wrote:
You didn't stick with that long Christoph. We're not even past first base
yet. Let's try again?
So, I've got this file "patch-2.6.8.1.bz2". Lets suppose my older brother
comes in & compiles it up for me &
On Sat, Sep 04, 2004 at 11:30:54AM +0100, Keith Whitwell wrote:
> >>Sure, explain to me how I should upgrade my RH-9 system to work on my new
> >>i915?
> >
> >Download a new kernel.org kernel or petition the fedora legacy folks to
> >include a drm update. The last release RH-9 kernel has va
On Sat, Sep 04, 2004 at 12:24:32PM +0100, Dave Airlie wrote:
> >
> > A user without a clue should better be using a supported distribution.
> > If he used Fedora Core2 instead of the totally outdated and unsupported
> > RH9 he'd already have a kernel with i915 support on his disk.
>
> What about D
>
> A user without a clue should better be using a supported distribution.
> If he used Fedora Core2 instead of the totally outdated and unsupported
> RH9 he'd already have a kernel with i915 support on his disk.
What about Debian? they would have a 2.4 kernel.. is Debian not supported,
no-one tol
On Sat, Sep 04, 2004 at 12:18:24PM +0100, Keith Whitwell wrote:
> You didn't stick with that long Christoph. We're not even past first base
> yet. Let's try again?
>
> So, I've got this file "patch-2.6.8.1.bz2". Lets suppose my older brother
> comes in & compiles it up for me & I'm now runnin
On Sat, Sep 04, 2004 at 11:54:06AM +0100, Dave Airlie wrote:
> > Just out of interest, what would the scenario be if you do if you could
> > get a compatible driver?
>
> you just grab a DRI snapshot which contains new userspace and DRM, and
> install it... it builds the DRM against your cur
Christoph Hellwig wrote:
On Sat, Sep 04, 2004 at 11:30:54AM +0100, Keith Whitwell wrote:
include a drm update. The last release RH-9 kernel has various security
and data integrity issues anyway, so you'd be a fool to keep running it.
OK, I've found www.kernel.org, and clicked on the 'latest stable
On Sat, Sep 04, 2004 at 12:12:31PM +0100, Dave Airlie wrote:
> > > OK, I've found www.kernel.org, and clicked on the 'latest stable kernel' link.
> > > I got a file called "patch-2.6.8.1.bz2". I tried to install this but
> > > nothing happened. My i915 still doesn't work. What do I do now?
> >
> > OK, I've found www.kernel.org, and clicked on the 'latest stable kernel' link.
> > I got a file called "patch-2.6.8.1.bz2". I tried to install this but
> > nothing happened. My i915 still doesn't work. What do I do now?
>
> You could start getting a clue.
>
Which is the problem, Keith was
Keith Whitwell wrote:
Christoph Hellwig wrote:
On Sat, Sep 04, 2004 at 11:23:35AM +0100, Keith Whitwell wrote:
Actually regulat users do. And they do by pulling an uptodate
kernel or
using a vendor kernel with backports. This model would work for
video drivers
aswell.
Sure, explain to me how I
On Sat, Sep 04, 2004 at 11:30:54AM +0100, Keith Whitwell wrote:
> > include a drm update. The last release RH-9 kernel has various security
> > and data integrity issues anyway, so you'd be a fool to keep running it.
>
> OK, I've found www.kernel.org, and clicked on the 'latest stable kernel' lin
Can you insmod the radeon drm module with drm_opts=debug do the test and
send on the trace, it may be getting wedged somewhere unexpected...
Dave.
>
> All of this was tested with a virgin 2.6.8.1 (with debug info and
> frame pointers enabled) and Debian's XFree86 4.3.0.1, using DarkPlaces
> and
Nick Piggin wrote:
Keith Whitwell wrote:
Christoph Hellwig wrote:
On Sat, Sep 04, 2004 at 11:23:35AM +0100, Keith Whitwell wrote:
Actually regulat users do. And they do by pulling an uptodate
kernel or
using a vendor kernel with backports. This model would work for
video drivers
aswell.
Sure,
>
> Just out of interest, what would the scenario be if you do if you could
> get a compatible driver?
you just grab a DRI snapshot which contains new userspace and DRM, and
install it... it builds the DRM against your current kernel, now if your
current kernel has a DRM module built-in which is a
Christoph Hellwig wrote:
On Sat, Sep 04, 2004 at 11:23:35AM +0100, Keith Whitwell wrote:
Actually regulat users do. And they do by pulling an uptodate kernel or
using a vendor kernel with backports. This model would work for video drivers
aswell.
Sure, explain to me how I should upgrade my RH-9 s
On Sat, Sep 04, 2004 at 11:23:35AM +0100, Keith Whitwell wrote:
> > Actually regulat users do. And they do by pulling an uptodate kernel or
> > using a vendor kernel with backports. This model would work for video drivers
> > aswell.
>
> Sure, explain to me how I should upgrade my RH-9 system to
Christoph Hellwig wrote:
On Sat, Sep 04, 2004 at 10:45:33AM +0100, Keith Whitwell wrote:
Umm, the Linux kernel isn't about minimizing interfaces. We don't link a
copy of scsi helpers into each scsi driver either, or libata into each sata
driver.
But regular users don't tend to pull down new scsi o
On Sat, Sep 04, 2004 at 11:48:47AM +0200, Arjan van de Ven wrote:
> > true but the DRM isn't only about the Linux kernel, the DRM is a lowlevel
> > component of a much larger system, of which the DRM just has to reside in
> > the kernel,
>
>
> you seem to be confusing 2 things.
>
> The kernel<->
On Sat, 2004-09-04 at 11:43, Dave Airlie wrote:
> >
> > Umm, the Linux kernel isn't about minimizing interfaces. We don't link a
> > copy of scsi helpers into each scsi driver either, or libata into each sata
> > driver.
>
> true but the DRM isn't only about the Linux kernel, the DRM is a lowleve
On Sat, Sep 04, 2004 at 10:45:33AM +0100, Keith Whitwell wrote:
> > Umm, the Linux kernel isn't about minimizing interfaces. We don't link a
> > copy of scsi helpers into each scsi driver either, or libata into each sata
> > driver.
>
> But regular users don't tend to pull down new scsi or ata dr
On Sat, Sep 04, 2004 at 10:43:39AM +0100, Dave Airlie wrote:
> >
> > Umm, the Linux kernel isn't about minimizing interfaces. We don't link a
> > copy of scsi helpers into each scsi driver either, or libata into each sata
> > driver.
>
> true but the DRM isn't only about the Linux kernel, the DRM
Christoph Hellwig wrote:
On Sat, Sep 04, 2004 at 01:51:24AM +0100, Dave Airlie wrote:
Then drm_core would always be bundled with the OS.
Is there any real advantage to spliting core/library and creating three
interface compatibily problems?
Yes we only have one binary interface, between the core an
>
> Umm, the Linux kernel isn't about minimizing interfaces. We don't link a
> copy of scsi helpers into each scsi driver either, or libata into each sata
> driver.
true but the DRM isn't only about the Linux kernel, the DRM is a lowlevel
component of a much larger system, of which the DRM just h
On Sat, Sep 04, 2004 at 01:51:24AM +0100, Dave Airlie wrote:
> >
> > Then drm_core would always be bundled with the OS.
> >
> > Is there any real advantage to spliting core/library and creating three
> > interface compatibily problems?
>
> Yes we only have one binary interface, between the core an
On Sat, Sep 04, 2004 at 01:12:16AM +0100, Dave Airlie wrote:
> DRM core - just the stub registration procedure and handling any
> shared resources like the device major number, and perhaps parts of sysfs
> and class code. This interface gets set in stone as quickly as possible
> and is as min
I'm currently using an r200 (specifically, an agp 'ATI Technologies
Inc Radeon R200 QM [Radeon 9100]') on a uniproc Pentium 3 board
equipped with an intel 440bx/piix4 type chipset (the agp controller is
identified as 'Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev
03)'
All of this was tes
Dave Airlie wrote:
Let me be clear that I am unwilling to support changes to the DRM that break
it's usability on other operating systems on principle.
I'm in agreement on that, ...
Maybe it's time to consider a fork of the DRM to allow a major experimentation
of the form Jon envisages to proceed
>
> Let me be clear that I am unwilling to support changes to the DRM that break
> it's usability on other operating systems on principle.
I'm in agreement on that, ...
>
> Maybe it's time to consider a fork of the DRM to allow a major experimentation
> of the form Jon envisages to proceed withou
Dave Airlie wrote:
drm/linux is GPL licensed.
This just isn't true. What on earth makes you think this? Read the license
before you make these sorts of comments, you dweeb. There shouldn't be any
GPL code in there at all.
I think you mis-read Keith, he said about converting it in the future to
> > drm/linux is GPL licensed.
>
> This just isn't true. What on earth makes you think this? Read the license
> before you make these sorts of comments, you dweeb. There shouldn't be any
> GPL code in there at all.
I think you mis-read Keith, he said about converting it in the future to
that fo
> We're going to have to work out a GPL/BSD solution for the fbdev
> merge. There are 80,000 lines of code in the fbdev directory. It is
> impractical to rewrite them. It's probably also impractical to
> relicense the fbdev code BSD since we would have to locate all of the
> coders.
Well I've bee
Jon Smirl wrote:
Would this work? drm/shared and drm/bsd directories are BSD licensed.
drm/linux is GPL licensed.
This just isn't true. What on earth makes you think this? Read the license
before you make these sorts of comments, you dweeb. There shouldn't be any
GPL code in there at all.
Kei
82 matches
Mail list logo
