KdEnqueueMouseEvent
...
...
EINTR
...
ProcessInputEvents
miPointerUpdate
Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab
___
Xpert mailing list
[EMA
in
Xft has been rewritten since 4.2. I've patched Qt to build with the new
version, but haven't heard anything from the Troll's about integrating
the changes into the regular release.
KDE has some dependencies on the old Xft as well that will cause it to
stop building. I'
request identical to ChangeSaveSet
with an additional mode (SetModeInsertRoot).
Are there other WM related extensions that we could usefully merge with
this extension? I'd like to solve any outstanding issues all at once,
rather than with a zillion tiny extensions.
Keith PackardXFre
reported coordinates; you'll want
to use something higher order than linear though; that leaves terrible
jaggies.
Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
un on a
machine with no writable file system.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
er layer of variables so that EtcX11Directory
is derived from EtcDirectory which can point at /etc and be shared by the
fontconfig Imakefile.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
Xpert mailing list
[EMAIL PROTECTED]
http:/
on the floor and generated no events.
Jg has a plan to return a special event when the connection is lost;
that's probably pretty workable and would make notifying the outer loop a
bit easier.
It shouldn't be that hard to fix; we'd really appreciate the help as there
are more a
r; that's
part of RandR which hasn't been implemented yet.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Around 16 o'clock on May 20, Alex Pavloff wrote:
> Option B) Attempt to figure out what Keith Packard was doing with the
> "other" drivers in the kdrive directory, and modify the geode source code to
> match that.
That's the right option -- you'll find severa
What problem are you trying to avoid by skipping this step?
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Around 3 o'clock on May 22, "Axel H. Siebenwirth" wrote:
> I have encountered an error during make install of freshly build x from
> cvs..
Sorry 'bout that -- I didn't get the changes into Xft1 that are needed to
deal with changes in fontconfig.
All fixed now
Around 11 o'clock on May 22, [EMAIL PROTECTED] wrote:
> now I am finding that regardless of the window manager I use, most colours
> have already been allocated.
Fixed in current CVS.
Keith PackardXFree86 Core TeamHP Cambridge R
tched.
I use this to switch sizes when plugging into an external projector.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
e modest portion.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
ver?
xfs uses the X Font Services Protocol which is documented in the XFree86
xc/doc directory. It sends glyphs as bitmaps.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree
ul
even on pseudo-color screens as it permits applications to efficiently draw
text using client-side fonts.
I stronglye believe that Render is a necessary part of a modern X server;
those without it should be considered "broken".
Keith PackardXFree86 Core Team
g would at least
make them appear no worse under transformation.
I've tried this with Xft2 and (after fixing several bugs), it works
just fine.
I think I'll add an aspect ratio field to allow the right thing to
happen.
Keith Packard
Around 13 o'clock on Jun 2, Keith Packard wrote:
> I think I'll add an aspect ratio field to allow the right thing to
> happen.
Yes, that looks much better now -- aspect ratios of 1.2 still snap glyphs
to the pixel grid to make them appear sharper when hinting is enabled.
which adjust all kinds of cool
parameters, the synaptics touchpad is used in lots of laptops; perhaps
those hacks have some helpful information.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
Xpert mailing list
[EMAI
imately equal in the result, except that some distances will be
adjusted to improve the appearance of the glyphs. Square characters will
remain approximately square.
Snapping the aspect ratio to whole integers would have been pretty boring
:-)
Keith PackardXFree86 Core TeamHP Ca
static unsigned char _back_msb[4] = {0x11, 0x44, 0x22, 0x88};
Set these to zero and you'll have a black root window by default. You'll
also get black when you do 'xsetroot -default' with this change.
Keith PackardXFree86 C
default, you have to ask for
each one now. Try adding:
#define XfbdevServerYES
#define XvesaServer YES
to your host.def file.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
Xpert mailing list
[EMAIL PROTECTED]
h
CVS that uses Render when available and otherwise leaves the current
behaviour unchanged.
Polite comments on the fine choice of default colors in Render mode would
also be appreciated; I realize my limitations in the area of aesthetics.
Keith PackardXFree86 Core TeamHP Ca
e (as in beer) web fonts from MS and rebuilding your freetype
library to enable the bytecode interpreter.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
all of the various versions that are out there and merge them
together.
Please let the list know if you've got other xscope fixes available or have
an interest in helping merge these things together.
Keith PackardXFree86 Core TeamHP Cambrid
can work to get this contributed under
> the proper license.
That would be nice, but it does depend to some degree on how hard you
think that will be. It is getting easier to open-source code from
HP these days though.
Keith PackardXFree86 Core T
//www.presentationmaster.com/2002/04_apr/news/cw_sharp_lcdmill.htm
Hmm. Looks I need to do more research in color space conversion and
monitor calibration -- one must always direct ones research towards the
area with the nicest toys...
Keith PackardXFree
the WM reconfigures an
application window. Now the WM will be put to sleep and the app will run.
That should be easy enough to test too.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
Xpert mailing list
[EMAIL PROTECTED]
Around 17 o'clock on Jun 26, Soeren Sandmann wrote:
> The behaviour where the client stops drawing completely is not
> difficult to get with a moderately complex gtk+ 2.0 application and
> the X server running without -dumbScheduler.
Please give the enclosed patch a try -- it transfers scheduli
DR, DDR radeons, 7000, 7200).
If anyone is interested, please download the patch and apply it to current
CVS before Kevin lands a giant merge from ATI.
http://keithp.com/~keithp/download/radeon_video.diff
Keith PackardXFree86 Core Team
bs, it doesn't restrict the
reporting of higher numbered mouse buttons in regular button events, nor
grabbing those buttons.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
er since Mesa 4 hit XFree86 CVS
shortly after 4.2.
I use the DRI tcl-0-0 branch on my 7500, but that wasn't working on my M6
when I last tried it a month or so ago.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
X
to get
them integrated so they could have wider testing for a while before the
XFree86 release.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
resulting
image, not the refresh rate.
If you have programming information for your video card, it's quite
possible to hack up a custom server that can change the pixel clock after
the server has initialized the card. I've done that in the Xtrident
server which is based on Xvesa.
K
rmat (bpp) is
irrelevant here, aside from needing to be no smaller than depth.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
However, the 3D hardware doesn't deal with 32bpp
frame buffers, so if you want to run the DRI, you'll have to pick either
32bpp or 16bpp (iirc).
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
Xpert mailing l
om this line down to the creation of the
format stored in this value, so it's not (actually) a typo, but it
is a misuse of the macro. Instead, a different PICT_FORMAT macro
should be created for PICT_TYPE_COLOR/PICT_TYPE_GRAY which can hold
the entire visual index, even if the server has mor
y extension to allow deeper pixels would have to hide the additional
bits from the core protocol.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
o hear from a developer on
> those...))
As a first hack, all that's really needed is to hook the RandR
reconfiguration function up to the existing size switching code
in the XFree86 DDX.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
ck to see if you have /etc/fonts/fonts.conf, that
would indicate you're using fontconfig now.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
pe1.
the xft.pc file installed with current XFree86 CVS Xft2 should point at
the right headers.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Around 11 o'clock on Aug 13, Mark Vojkovich wrote:
>Replys are synchronous. The reply goes with whatever request
> was before it. There is no need for reply codes.
In particular, within Xlib, replies are matched with requests by sequence
number.
Keith PackardXFree8
nship with
XFree86 which permits the redistribution of material covered by various
old NDAs that XFree86 used to have with hardware manufacturers; most
current vendors use other methods to keep their designs private.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
__
server (CVS), I think you'll find the analog mode
quite entertaining.
To change fonts in Render mode, use the '-fa' flag instead of '-fn'. To
get your old xclock back, use the '-norender' flag.
Keith PackardXFree86 Core TeamHP Cambridge Research
ength, but the reply length indicates the number of additional
4-byte values beyond the 32-byte fixed-size reply header.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree
ks?
Yeah, you have to send a motion event before you can send the button
event. That's just the way the server works. It ignores position
in button events.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
Xpert m
g with
a reasonable commitment to helping with the implementation, it seems more
important to get the subset of the specification known to work deployed
widely rather than wait an indeterminant time for this final piece of the
original design to be completed. Please comment if you have an opinion
keithp/talks/randr/
has what you want.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
structures.
Another important point -- legacy apps often assume that the 8-bit visual
is the default. RandR doesn't address this issue at all; the default
visual is not effectively switchable so RandR leaves the default visual
alone making legacy apps suffer if i
gacy applications would run on the Xnest-like display, while modern
> applications talk directly to the real X server.
That's probably a reasonable approach for switching which visual is the
default. Couple that with server-side support for emulated visuals and
you've got a pretty com
uld be relatively
easy given the internal structure of XFree86. Drivers using XAA may even
be able to provide rotation, although I haven't investigated that very far.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
just leave RandR
as the resize/rotate extension and leave hardware visual swaps for some
future extension if we ever need it ?
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
inside the X server is actually quite easy, the hard
part that RandR added was the ability to switch which visuals were
emulated and which were mapped directly to the hardware. The current
server internals are not structured well to handle that case.
K
screen resolution would change appropriately. maybe some option in
> their .xinitrc.
You can't change the depth, but you can change the size with the 'xrandr'
program.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
__
My hope is that the configuration file becomes entirely optional. There's
essentially nothing there which can't be autodetected on a reasonable
system.
At that point, the format of the file is moot.
Keith PackardXFree86 Core TeamHP Cambridge Re
ny video modes added through
the VidMode extension.
RandR also permits DDX to reprobe the monitor whenever the app requests
the available sizes. The kdrive-based Xvesa server requeries the BIOS
at this point to catch monitor changes.
Keith PackardXFree86 Core TeamHP Cambridg
;t test or change any of that code. If you've got a
fix that makes it work, please send it along with a sample program to
actually test this stuff.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
Xpert mailing list
[E
#x27;m also realistic about the
installed base of X configuration files and the existing community
expertise in managing them. You can't throw that away lightly, instead
you'll have to replace that with a more compelling solution.
Keith PackardXFree86 Core TeamHP Ca
Around 9 o'clock on Sep 15, Sidik Isani wrote:
|> With 8 bpp pseudocolor, I'm finding that simply starting the
|> X-Server allocates almost all the color cells in the default
|> colormap. There are only about 12 free cells, and most programs
|> either fail or install a private colormap.
Around 12 o'clock on Sep 15, Mark Vojkovich wrote:
>Can render allocate the colors as needed and use whatever it
> gets? This would be more consistent with traditional PsuedoColor
> behavior. That is, first come first serve and if you don't like that
> use a private map.
Hmm. Not with
Around 10 o'clock on Sep 15, Sidik Isani wrote:
> Unfortunately, there is. We look at astronomy CCD images, and
> the visualization tools like to manipulate a colormap to give a
> quick contrast adjustment.
If you have source, you could consider fixing these to use DirectColor
instead;
Around 11 o'clock on Sep 15, Sidik Isani wrote:
> It may be enough. Usually we look at our images with simple
> grey scales, and just need a way to exaggerate contrast to bring
> out features. I'd like to learn more about DirectColor. How much
> control does it give over luminence cur
Around 15 o'clock on Sep 15, Mark Vojkovich wrote:
> 3) No preallocated colors by default.
>
> It might be reasonable to assume users stuck in PseudoColor are there
> because they have antiquated hardware, in which case, they don't have
> very high expectations for things like anti-aliasing.
Around 16 o'clock on Sep 15, Mark Vojkovich wrote:
>Like by temporarily lowering the sigBits? Changing current allocation
> behavior makes me uneasy. Doesn't the specification say something
> about this?
AllocColor:
"This request allocates a read-only colormap entry corresponding to the
Around 16 o'clock on Sep 20, Mark Vojkovich wrote:
>XShmGetImage is blocking, so maybe it's not important for XvShmGetImage
> to be asynchronous. Having to send the event (and receive it)
> probably just increases the latency anyhow. OK, the event is
> a bad idea.
The protocol isn't bloc
Around 19 o'clock on Sep 22, Juliusz Chroboczek wrote:
> On an eight-bit visual, XDPS will allocate a 9-level gray ramp, and a
> 4x4x4 colour cube, for a total of 73 colourmap entries. (Colour
> allocation happens on the client side in XDPS.)
> Can RENDER deal with such a configuration?
RENDE
Around 16 o'clock on Sep 23, Juliusz Chroboczek wrote:
> The 9 + 4 x 4 x 4 scheme gives excellent results (to my eyes) while
> leaving a lot of colour cells free. I was suggesting that you should
> try implementing a similar colourmap for RENDER, and see what the
> results look like.
I think a
Around 2 o'clock on Sep 25, "Mike A. Harris" wrote:
> I just received the following bug report. I have confirmed the
> behaviour described occurs, although I am not sure if it should
> be considered a bug or not.
>
> =
> Using t
Around 22 o'clock on Sep 25, "Mike A. Harris" wrote:
> (void) sprintf(openLicenseString, "%s:%d",
>LICENSE_METHOD_OPEN,
>OPEN_LICENSE_VERSION);
> openLicenseMethod = XInternAtom(dpy, openLicenseString, True);
>
> Since the return code of sprintf i
Around 23 o'clock on Sep 25, "Mike A. Harris" wrote:
> Hmm. Looks to me like the programmer probably tried to silence
> the warning resulting from the lack of inclusion of stdio.h by
> adding (void) then..
More likely a warning was generated on a system where sprintf returned a
char * inste
Around 16 o'clock on Oct 4, Alan Hourihane wrote:
> > I agree, hotkey display switching will most likely mess up the
> > video offsets. The Xserver doesn't get notified when a switch happens
> > therefore we cannot adapt our values. I don't like to read back the
> > CRTC registers on every frame
Around 17 o'clock on Oct 24, "David Harris" wrote:
> Whoever I log in as using xdm it says 'Login Incorrect'
> What could cause a login to fail ?
Xdm is probably not using the right password options -- you might have MD5
passwords or shadow passwords enabled and xdm might not have support for
Around 11 o'clock on Oct 24, Mark Vojkovich wrote:
> > >I don't know that there are any plans to hack this. It's not
> > > worth the effort in my opinion. It's a mess and the problems are
> > > with the apps, not the server. It's a TrueColor world.
> >
> > Doesn't the RandR extension giv
Around 21 o'clock on Nov 1, Mark Vojkovich wrote:
> Looks to me like UpdateCurrentTimeIf doesn't actually
> update the current time. Shouldn't this function look like:
>if (CompareTimeStamps(systime, currentTime) == LATER)
>currentTime = systime;
This check should never fail --
Around 23 o'clock on Nov 1, Mark Vojkovich wrote:
>So that means that it's not possible to just update the
> currentTime. You can get the current system time, but you can't
> update currentTime without processing events. OK.
Right. Until R2 (R3?) the only way server time got updated was
Around 11 o'clock on Nov 2, Mark Vojkovich wrote:
>Not the currentTime field. I need more reliable current time but
> I can use GetTimeInMillis and do my own month accounting. I discovered
> that you can't call UpdateCurrentTime() any place you like. If you
> do it in the pointer/viewport
Around 17 o'clock on Nov 2, Christopher Blizzard wrote:
> Attached is a test case for the client library that always exits on my
> machine. Sometimes it gets a SIGPIPE, sometimes it gets a real X error
> but most of the time that it does get a real X error it has a random
> request_code.
>
Around 19 o'clock on Nov 2, Jim Gettys wrote:
> I had about 5 minutes to look into this this afternoon: BIG-REQUESTS
> postdates me, but it sort of looks like XDrawString doesn't implement
> it, from what I could tell in a very quick look.
That's right, none of the text requests even attempt to
Around 12 o'clock on Nov 3, Christopher Blizzard wrote:
> It would be good if you guys went through and looked at that code,
> though. If you can generate bad bits on the wire through an abusive,
> yet still legal use of the api, it probably needs to be fixed.
Yeah, anything which trashes th
Around 14 o'clock on Nov 3, Jim Gettys wrote:
> Or we could have Xlib generate the error: that is easy, I think... It
> could still look as if it were generated as a protocol error.
Having Xlib generate the error is actually somewhat hard -- it would have
to generate a synthetic request (as a
Around 22 o'clock on Nov 12, Alex Bustamante wrote:
> Got one question. Whats the difference between compiling
> xfree86 from source, or compiling the soruces directly from
> x.org?
X.org ships a completely separate implementation from XFree86; it's
designed to provide a stable X base for X.org
Around 19 o'clock on Nov 14, [EMAIL PROTECTED] wrote:
> But if I start in the default mode (640x480x8) and do an
> "fbset -a 800x600x16" before starting Xfbdev the upcomming
> X is totally corrupted (wrong memory layout??) while all other
> (text) virtual terminals switch correctly to the new
Around 11 o'clock on Nov 15, Branden Robinson wrote:
> As I understand it, "packed pixel modes" are those in which pixel data
> is not aligned on (Intel 80386+) word boundaries, which are 32 bits.
That's not the historical usage. In the old days, there were two kinds of
frame buffers -- packe
Around 15 o'clock on Nov 16, Alex Larsson wrote:
> I've stumbled upon a rasterization bug while drawing lines of width 1.
Nice one. There's an "optimization" in the wide line code to avoid
drawing joins when one of the two lines will do it. It's busted.
This patch is already in XFree86 CVS.
Around 10 o'clock on Nov 22, Michael Wake wrote:
> Here is a small one line startup/server regeneration
> related bug fix in the mouse handling code that I
> think should be added into
> xc/programs/Xserver/hw/kdrive/linux/mouse.c
Thanks. It's in XFree86 CVS.
> Who looks after, vetting
Around 10 o'clock on Nov 21, Michel D nzer wrote:
> > In 1600x1200x24 It takes 1 full second to draw the screen, or a
> > good 3/4 of a second. That is definitely not accelerated.
> > Again, disabling DRI, the MMIO accel makes everything fly.
>
> Color expansion is probably what's missing.
Around 15 o'clock on Nov 26, Dr Andrew C Aitchison wrote:
> Come to that, there is no good reason why the average application
> should be using fonts where it matters. If I have two 1024x768 displays,
> one a 14" laptop and the other a 50" plasma display, I usually want the
> text to be the same
hang when suspending if the server with
DRI isn't running. Kinda loses the integrated desktop feel, but I can run
other X apps in the same server for IRC or whatnot.
Keith PackardXFree86 Core Team
___
Xpert mailing list
[EMAIL PRO
e from various helpful mail
systems is not pleasant.
Keith PackardXFree86 Core Team
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
a member of the list; is there anyone
for whom that would be a significant burden?
Keith PackardXFree86 Core Team
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
ses that get people kicked off the
list by management. Limiting posting to members will reduce spam, but
won't eliminate the viruses, unless I also eliminate postings from
Outlook...
Keith PackardXFree86 Core Team
___
Xpert mailing lis
Please don't forward the virus header to the list; that just annoys the
various virus scanners, and there's no easy way to filter it out; it's
not an attachment, it's just a regular email (lame scanners).
Keith Packard
might eventually be reasonable to consider switching the core server to
using that mechanism so that a single font configuration can be truely
shared by all font consumers. We would get better XLFD matching for free,
too :-)
Keith Packard
'm afraid I won't be much help here; but if this BIOS works with it
mapped from /dev/zero, I'd rather leave it like that for now. You might
add some config options that change the mapping around so we can test
other bioses without recompiling the server.
Keith PackardXFree8
this, and there are a couple of questions
to be answered before we can design one:
+ What basic signalling mechanism should be used
+ Who has permission to signal apps
Suggestions are welcome, as this would be a useful addition to the
architecture.
Keith Pac
see it?
If the X server and Xfs shared the same font configuration mechanism as
Xft, then they'd get updated information via the same route. Right now,
you can install new fonts, re-run 'mkfontdir' and then 'xset fp rehash'
and the X server will see the new fonts.
Ke
unless you are running as root
> (and it is common convention to not run as root whenever
> possible to avoid accidently damaging the OS).
One can modify the X server's font path to point at a directory controlled
by the current user.
Keith PackardXFree86 Core Team
to share fonts
> between users.
You can't have it both ways -- either the user has administrative rights
to modify the system font configuration, in which case they have rights to
modify the X related font configuration, or they don't. Two separate
cases that must be handled different
stalled fonts. Might not
be a graphical application either; just some console app run by the
administrator.
Keith PackardXFree86 Core Team
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
a good thing or not...
Please feel free to complain if it either appears not to work, or if it
blocks some reasonable posting.
Keith PackardXFree86 Core Team
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
1 - 100 of 197 matches
Mail list logo
