[Fwd: xorg Digest, Vol 36, Issue 18]
Regina
regina.apel at gmx.de
Thu Jul 3 02:27:51 PDT 2008
-------- Original-Nachricht --------
Betreff: xorg Digest, Vol 36, Issue 18
Datum: Thu, 03 Jul 2008 02:04:22 -0700
Von: xorg-request at lists.freedesktop.org
Antwort an: xorg at lists.freedesktop.org
An: xorg at lists.freedesktop.org
Send xorg mailing list submissions to
xorg at lists.freedesktop.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freedesktop.org/mailman/listinfo/xorg
or, via email, send a message with subject or body 'help' to
xorg-request at lists.freedesktop.org
You can reach the person managing the list at
xorg-owner at lists.freedesktop.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of xorg digest..."
Today's Topics:
1. Re: ati-6.9.0 unstable dualhead (Alex Deucher)
2. Re: [mythtv-users] stuttering video in LiveTV with greedy2x
and yadif2x (Tino Keitel)
3. Re: cairo with glitz vs Xrender (KAMALNEET SINGH)
4. Re: synaptics touchpad. reconnect not supported (Steven J Newbury)
5. Re: ati-6.9.0 unstable dualhead (Simon Thum)
6. DWIM (was: Resolution indpendence) (olafBuddenhagen at gmx.net)
7. Re: Resolution indpendence (olafBuddenhagen at gmx.net)
8. How to build DRI2 with xorg-server 1.5? (Stefan Dirsch)
----------------------------------------------------------------------
Message: 1
Date: Wed, 2 Jul 2008 18:30:36 -0400
From: "Alex Deucher" <alexdeucher at gmail.com>
Subject: Re: ati-6.9.0 unstable dualhead
To: "Simon Thum" <simon.thum at gmx.de>
Cc: xorg at lists.freedesktop.org
Message-ID:
<a728f9f90807021530x3b11a5ccmb886a0e09ed39011 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Jul 2, 2008 at 6:06 PM, Simon Thum <simon.thum at gmx.de> wrote:
> Alex Deucher wrote:
>>
>> On Wed, Jul 2, 2008 at 4:47 PM, Simon Thum <simon.thum at gmx.de> wrote:
>>>
>>> But 6.9 + 1.4.2 was worst yet. Impossible to use.
>>>
>>
>> Are you saying the xserver makes a difference? One thing you might
>
> No, that just happens to reflect day-to-day and development instances.
>
>> for your monitor. A lot of DVI monitors are pretty picky about the
>> timings they like. if you post your xorg log I'll take a look. If
>> you see differences between 6.8.191 and 6.8.192/6.9.0 let me know, as
>> I made some changes to the pll code.
>
> Saw that. FWIW, the first start with git ati .192 made my LCD do something I
> never saw: A box telling me that the mode needs to be below 1280x1024/75 hz.
> However this was unreproduceable. Aside from that, it seems to work.
>
Are you saying it's working ok now?
Which log is which? Does one version of the driver work better than
the other? You'll notice they are each using different pll dividers:
Xorg.0.log is using:
freq: 108000000
best_freq: 108000000
best_feedback_div: 96
best_ref_div: 12
best_post_div: 2
while Xorg.1.log is using:
freq: 108000000
best_freq: 108000000
best_feedback_div: 16
best_ref_div: 2
best_post_div: 2
Alex
------------------------------
Message: 2
Date: Thu, 3 Jul 2008 00:11:26 +0200
From: Tino Keitel <tino.keitel+xorg at tikei.de>
Subject: Re: [mythtv-users] stuttering video in LiveTV with greedy2x
and yadif2x
To: xorg at lists.freedesktop.org
Message-ID: <20080702221126.GA2632 at x61>
Content-Type: text/plain; charset=us-ascii
Hi folks,
I had stuttering video in MythTV and now found the culprit. It seems to
be caused by a strange Xorg behaviour (or bug?). I set the refresh rate
to 60 Hz using xrandr --rate 60. However, if I check xvidtune, it still
shows 50 Hz. After running xrandr --rate 60 again, xvidtune shows 60
Hz.
And after running xrandr --rate 60 a second time, the stuttering video
doesn't seem to occur anymore.
I tried again and was able to reproduce that. Here is what I did:
$ xrandr --rate 50
$ xrandr --rate 50
$ xrandr -q | grep " 1024"
1024x768 50.0*+ 60.0 40.0
$ xvidtune -show
"1024x768" 54.16 1024 1048 1184 1344 768 771 777 806 -hsync -vsync
$ mythfrontend -> stutter happens
$ xrandr --rate 60
$ xrandr -q | grep " 1024"
1024x768 50.0 + 60.0* 40.0
^^^^^
reported 60 Hz
$ xvidtune -show
"1024x768" 54.16 1024 1048 1184 1344 768 771 777 806 -hsync -vsync
^^^^^
but no real changes
$ mythfrontend -> stutter happens
$ xrandr --rate 60
$ xrandr -q | grep " 1024"
1024x768 50.0 + 60.0* 40.0
$ xvidtune -show
"1024x768" 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync
^^^^^
now it really changed
$ mythfrontend -> no stutter happens
I use Xorg server 1.4.2 and the Intel driver 2.3.2 on a i965GM chipset.
Regards,
Tino
------------------------------
Message: 3
Date: Thu, 03 Jul 2008 01:20:50 +0000 (GMT)
From: KAMALNEET SINGH <kamalneet.s at samsung.com>
Subject: Re: cairo with glitz vs Xrender
To: Mohan Parthasarathy <suruti94 at gmail.com>
Cc: "xorg at lists.freedesktop.org" <xorg at lists.freedesktop.org>
Message-ID: <7950059.509471215048050725.JavaMail.weblogic at epml06>
Content-Type: text/plain; charset=windows-1252
Mohan Parthasarathy wrote:
> Hi,
>
> I understand that Cairo uses Xrender and on the server side EXA provides
> the acceleration. I also see that
> glitz, which is not actively developed any more, used GLX with OpenGL on
> the server side for acceleration.
> I am trying to understand as to whether one is better over the other. As
> we already use the 3D driver on
> the Xserver today for other purposes, it might be possible that we use
> that instead of EXA. I miss a lot
> of history. So, can someone provide insight into this ?
>
Also depends on where do you want to use it. On embedded, where you have
only ES version of OpenGL, it may be better to implement KAA/EXA instead
of porting glitz to OpenGL ES. And if hardware+drivers can run OpenVG
fast, OpenVG backend is a very compelling choice.
> thanks
> mohan
------------------------------
Message: 4
Date: Thu, 03 Jul 2008 03:09:20 +0100
From: Steven J Newbury <steve at snewbury.org.uk>
Subject: Re: synaptics touchpad. reconnect not supported
To: Nicol? Chieffo <84yelo3 at gmail.com>
Cc: xorg at lists.freedesktop.org
Message-ID:
<1215050960.4710.4.camel at infinity.southview.snewbury.org.uk>
Content-Type: text/plain; charset=ISO-8859-1
On Wed, 2008-07-02 at 13:19 +0200, Nicol? Chieffo wrote:
> Maybe I need some help, I'm not so expert in this stuff... I edited
> the fdi file and I copied it to
> /usr/share/hal/fdi/policy/20thirdparty/
> then I rebooted but the problem persists. Do I have to add some
> xorg.conf tweak? or the udev rule too?
> Thank you
Local fdi policy files should really go in /etc/hal/fdi/policy
You should have something in your X server log to show what's happening.
------------------------------
Message: 5
Date: Thu, 03 Jul 2008 08:34:18 +0200
From: Simon Thum <simon.thum at gmx.de>
Subject: Re: ati-6.9.0 unstable dualhead
To: Alex Deucher <alexdeucher at gmail.com>
Cc: xorg at lists.freedesktop.org
Message-ID: <486C72EA.2040300 at gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Alex Deucher wrote:
> On Wed, Jul 2, 2008 at 6:06 PM, Simon Thum <simon.thum at gmx.de> wrote:
>> Alex Deucher wrote:
>> Saw that. FWIW, the first start with git ati .192 made my LCD do something I
>> never saw: A box telling me that the mode needs to be below 1280x1024/75 hz.
>> However this was unreproduceable. Aside from that, it seems to work.
>>
>
> Are you saying it's working ok now?
Aside from a single failed startup *per server instance*, I must admit
there isn't much to reproduce. In each it was the first time that
horribly failed (and/or looked like earlier issues), since then it
worked OK (for now).
The only thing I can imagine is check for something the PLL code might
depend on, which would be persited or somehow randomly fails (though I'm
yet to see a second failure). Sounds a bit like a memory hole to me, but
really I'm out of ideas what it could have been.
So basically yes.
Regards,
Simon
------------------------------
Message: 6
Date: Wed, 2 Jul 2008 10:07:31 +0200
From: <olafBuddenhagen at gmx.net>
Subject: DWIM (was: Resolution indpendence)
To: xorg at lists.freedesktop.org
Message-ID: <20080702080727.GF1596 at alien.local>
Content-Type: text/plain; charset=us-ascii
Hi,
On Mon, Jun 30, 2008 at 09:05:12PM +0100, Glynn Clements wrote:
> The interface between software components needs to be rigid, but the
> interface between the computer and a human less so. Users are normally
> asking for more DWIM, not less.
Well, they are asking for that, but that doesn't mean that it really
helps when they get it... For my own view on this matter, see
http://tri-ceps.blogspot.com/2008/06/smartass-software.html
-antrik-
------------------------------
Message: 7
Date: Thu, 3 Jul 2008 08:38:29 +0200
From: <olafBuddenhagen at gmx.net>
Subject: Re: Resolution indpendence
To: xorg at lists.freedesktop.org
Message-ID: <20080703063825.GG1596 at alien.local>
Content-Type: text/plain; charset=us-ascii
Hi,
On Fri, Jun 27, 2008 at 01:32:18PM -0400, Behdad Esfahbod wrote:
> There are two points of physical information:
>
> A) Dots per inch on the display surface (LCD panel, TV screen,
> projector screen, The Wall, ...)
>
> B) Viewing distance
>
> Those two are very real and can be measured. If we have both, we can
> compute a third value:
>
> C) Normalized dpi / angular resolution / whatever you call it.
> Physical dpi times viewing distance does the job.
>
>
> At the end, C is all the application developers care about. That's
> why I suggest we redefine application DPIs to be that.
>
> Next question is where to get A and B from. A is already coming from
> X and EDID info and many devices have buggy values. B is nonexistent.
> The solution to both is already there: HAL device info files. These
> are small XML files setting A and a default value for B depending on
> the manufacturer and model of the display device. The user can set
> both. This is just about defaults.
First of all, we do usually have two information points: Resolution and
display size. From these, I think we can make a pretty good guess at the
viewing distance/angular resolution -- no need for an enormous database.
The viewing distance normally depends mostly on the display size. For
anything from the size of a desktop monitor upwards, it should usually
be roughly proportional to the display size. For smaller displays, it
will obviously not be proportional, but rather approximate some minimum
realistic distance, say 25 cm or so.
The resolution also plays some role: With a higher resolution display we
will generally tend to get closer so we see better, while with a lower
resolution one there is no use so we won't.
Of course, this relation isn't linear either. With higher resolutions,
the display size becomes more dominant.
Note however that the viewing distance/angular resolution alone is not
really an ideal base. To determine the optimal effective resolution used
for size calculations, there are other factors to take into account.
For one, while I do not agree with Glynn that for today's typical
resolution it's *only* the pixel grid matters, it's certainly true that
with a better resolution, things remain legible at a slightly smaller
physical size. (And in fact subjectively look bigger than at a lower
resolution.) The truth is somewhere in between.
Also, with very small displays, we are usually ready to accept smaller
size even at the expense of some legibility, because, well, the display
being tiny, it just can't be helped...
The bottom line is that finding the effective resolution involves many
parameters, which all have nonlinear effects. Yet the result is a
relatively simple two parameter function on display size and resolution.
Starting with a number of data points found by experiment, it should be
possible to fit a function that pretty well models typical user's
expectations about effective resolution.
Now what to do with this effective resolution? I'm quite ambivalent
about the suggestion to redefine DPI. On one hand, it just feels wrong;
it must result in even more breakage and confusion... It surely would be
more elegant to change applications to explicitely use effective
resolution, or a scaling factor on top of the physical DPI.
>>From a pragmatical point though it doesn't sound like a terribly bad
idea. The truth is that the "everthing is 96 DPI" hack is often
considered a good thing, because such a fixed resolution is actually
closer to the effective resolution than the physical resolution in many
important real-world use cases. (60" projector or large TV, tiny 200-300
DPI devices.)
It would still be a hack, but unlike the fixed resolution one, it would
actually take into account the true resolution -- in a manner that meets
users' expectations fairly well, unlike just scaling to the physical
resolution no matter what. It would Just Work (TM) with those
applications that already scale depending on DPI. I wonder how much
support this approach could gain?
Of course, this will break those few applications (dealing with print
documents) that actually care about the real physical size. As pointed
out by others, these applications will need to be adapted anyways to use
a special interface for querying the real physical resolution, because
of multihead... And also, it's much more realistic to adapt those few
apps rather than all the others. (Especially if for most practical
purposes the starting point is the 96 DPI hack, so with the current way
of handling things they don't really work in most cases anyways...)
-antrik-
------------------------------
Message: 8
Date: Thu, 3 Jul 2008 11:04:19 +0200
From: Stefan Dirsch <sndirsch at suse.de>
Subject: How to build DRI2 with xorg-server 1.5?
To: xorg at freedesktop.org
Message-ID: <20080703090419.GA16834 at suse.de>
Content-Type: text/plain; charset=iso-8859-15
Hi
Since I switched to libdrm 2.3.1 (official release) - which forced me
to current Mesa git (commit 6befdca, instead of Mesa 7.1 RC1) - I
cannot build DRI2 any longer with xorg-server 1.4.99.905. Build works
with "--disable-dri2". libdrm 2.3.1 and Mesa git (commit 6befdca) is
installed when I tried to build xorg-server.
Making all in dri2
make[4]: Entering directory `/usr/src/packages/BUILD/xorg-server-1.4.99.905/hw/xfree86/dri2'
/bin/sh ../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../../include -DHAVE_XORG_CONFIG_H -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/include/freetype2 -I/usr/include/pixman-1 -I../../../include -I../../../include -I../../../Xext -I../../../composite -I../../../damageext -I../../../xfixes -I../../../Xi -I../../../mi -I../../../miext/shadow -I../../../miext/damage -I../../../render -I../../../randr -I../../../fb -DHAVE_XORG_CONFIG_H -DXF86PM -I/usr/include/drm -I../../../hw/xfree86/common -I../../../hw/xfree86/os-support/bus -O2 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -g -fno-strict-aliasing -MT libdri2_la-dri2.lo -MD -MP -MF .deps/libdri2_la-dri2.Tpo -c -o libdri2_la-dri2.lo `test -f 'dri2.c' || echo './'`dri2.c
mkdir .libs
gcc -DHAVE_CONFIG_H -I. -I../../../include -DHAVE_XORG_CONFIG_H -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/include/freetype2 -I/usr/include/pixman-1 -I../../../include -I../../../include -I../../../Xext -I../../../composite -I../../../damageext -I../../../xfixes -I../../../Xi -I../../../mi -I../../../miext/shadow -I../../../miext/damage -I../../../render -I../../../randr -I../../../fb -DHAVE_XORG_CONFIG_H -DXF86PM -I/usr/include/drm -I../../../hw/xfree86/common -I../../../hw/xfree86/os-support/bus -O2 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -g -fno-strict-aliasing -MT libdri2_la-dri2.lo -MD -MP -MF .deps/libdri2_la-dri2.Tpo -c dri2.c -fPIC -DPIC -o .libs/libdri2_la-dri2.o
dri2.c:60: error: expected specifier-qualifier-list before 'drmBO'
dri2.c: In function 'DRI2ScreenAllocEvent':
dri2.c:86: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:90: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:90: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:93: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:93: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:95: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:95: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:97: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:100: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:100: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:101: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c: In function 'DRI2ScreenCommitEvents':
dri2.c:109: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:109: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c: In function 'DRI2PostBufferAttach':
dri2.c:195: error: 'struct _DRI2Screen' has no member named 'getPixmapHandle'
dri2.c: In function 'DRI2ClipNotify':
dri2.c:217: error: 'struct _DRI2Screen' has no member named 'locked'
dri2.c:218: error: 'struct _DRI2Screen' has no member named 'beginClipNotify'
dri2.c:219: error: 'struct _DRI2Screen' has no member named 'locked'
dri2.c:222: error: 'struct _DRI2Screen' has no member named 'ClipNotify'
dri2.c:223: error: 'struct _DRI2Screen' has no member named 'ClipNotify'
dri2.c: In function 'DRI2HandleExposures':
dri2.c:238: error: 'struct _DRI2Screen' has no member named 'HandleExposures'
dri2.c:239: error: 'struct _DRI2Screen' has no member named 'HandleExposures'
dri2.c:246: error: 'struct _DRI2Screen' has no member named 'locked'
dri2.c:247: error: 'struct _DRI2Screen' has no member named 'endClipNotify'
dri2.c:248: error: 'struct _DRI2Screen' has no member named 'locked'
dri2.c: In function 'DRI2CloseScreen':
dri2.c:257: error: 'struct _DRI2Screen' has no member named 'ClipNotify'
dri2.c:258: error: 'struct _DRI2Screen' has no member named 'HandleExposures'
dri2.c:260: warning: implicit declaration of function 'drmBOUnmap'
dri2.c:260: warning: nested extern declaration of 'drmBOUnmap'
dri2.c:260: error: 'struct _DRI2Screen' has no member named 'sareaBO'
dri2.c:261: warning: implicit declaration of function 'drmBOUnreference'
dri2.c:261: warning: nested extern declaration of 'drmBOUnreference'
dri2.c:261: error: 'struct _DRI2Screen' has no member named 'sareaBO'
dri2.c: In function 'DRI2CreateDrawable':
dri2.c:295: error: 'struct _DRI2Screen' has no member named 'nextHandle'
dri2.c:300: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c: In function 'DRI2ReemitDrawableInfo':
dri2.c:344: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c: In function 'DRI2Connect':
dri2.c:361: error: 'struct _DRI2Screen' has no member named 'driverName'
dri2.c:362: error: 'struct _DRI2Screen' has no member named 'sareaBO'
dri2.c: In function 'DRI2GetPixmapHandle':
dri2.c:383: error: 'struct _DRI2Screen' has no member named 'getPixmapHandle'
dri2.c: In function 'DRI2SetupSAREA':
dri2.c:393: error: 'struct _DRI2Screen' has no member named 'sareaSize'
dri2.c:394: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:398: error: 'DRM_BO_FLAG_READ' undeclared (first use in this function)
dri2.c:398: error: (Each undeclared identifier is reported only once
dri2.c:398: error: for each function it appears in.)
dri2.c:398: error: 'DRM_BO_FLAG_WRITE' undeclared (first use in this function)
dri2.c:398: error: 'DRM_BO_FLAG_MAPPABLE' undeclared (first use in this function)
dri2.c:399: error: 'DRM_BO_FLAG_MEM_LOCAL' undeclared (first use in this function)
dri2.c:399: error: 'DRM_BO_FLAG_SHAREABLE' undeclared (first use in this function)
dri2.c:401: warning: implicit declaration of function 'drmBOCreate'
dri2.c:401: warning: nested extern declaration of 'drmBOCreate'
dri2.c:401: error: 'struct _DRI2Screen' has no member named 'sareaSize'
dri2.c:401: error: 'struct _DRI2Screen' has no member named 'sareaBO'
dri2.c:404: warning: implicit declaration of function 'drmBOMap'
dri2.c:404: warning: nested extern declaration of 'drmBOMap'
dri2.c:404: error: 'struct _DRI2Screen' has no member named 'sareaBO'
dri2.c:405: error: 'struct _DRI2Screen' has no member named 'sarea'
dri2.c:406: error: 'struct _DRI2Screen' has no member named 'sareaBO'
dri2.c:412: error: 'struct _DRI2Screen' has no member named 'sareaSize'
dri2.c:412: error: 'struct _DRI2Screen' has no member named 'sareaBO'
dri2.c:413: error: 'struct _DRI2Screen' has no member named 'sarea'
dri2.c:413: error: 'struct _DRI2Screen' has no member named 'sareaSize'
dri2.c:415: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:415: error: 'struct _DRI2Screen' has no member named 'sarea'
dri2.c:416: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:417: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:419: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:421: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c:421: error: 'struct _DRI2Screen' has no member named 'buffer'
dri2.c: In function 'DRI2ScreenInit':
dri2.c:435: error: 'struct _DRI2Screen' has no member named 'driverName'
dri2.c:436: error: 'struct _DRI2Screen' has no member named 'nextHandle'
dri2.c:438: error: 'struct _DRI2Screen' has no member named 'getPixmapHandle'
dri2.c:439: error: 'struct _DRI2Screen' has no member named 'beginClipNotify'
dri2.c:440: error: 'struct _DRI2Screen' has no member named 'endClipNotify'
dri2.c:442: error: 'struct _DRI2Screen' has no member named 'ClipNotify'
dri2.c:444: error: 'struct _DRI2Screen' has no member named 'HandleExposures'
ICECC[21782] 21:12:38: Compiled on 10.11.0.140
make[4]: *** [libdri2_la-dri2.lo] Error 1
make[4]: Leaving directory `/usr/src/packages/BUILD/xorg-server-1.4.99.905/hw/xfree86/dri2'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/usr/src/packages/BUILD/xorg-server-1.4.99.905/hw/xfree86'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/usr/src/packages/BUILD/xorg-server-1.4.99.905/hw/xfree86'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/packages/BUILD/xorg-server-1.4.99.905/hw'
make: *** [all-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.87838 (%build)
Any hints? Which bits are missing/wrong this time?
Best regards,
Stefan
Public Key available
------------------------------------------------------
Stefan Dirsch (Res. & Dev.) SUSE LINUX Products GmbH
Tel: 0911-740 53 0 Maxfeldstra?e 5
FAX: 0911-740 53 479 D-90409 N?rnberg
http://www.suse.de Germany
-----------------------------------------------------------------
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg)
-----------------------------------------------------------------
------------------------------
_______________________________________________
xorg mailing list
xorg at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
End of xorg Digest, Vol 36, Issue 18
************************************
More information about the xorg
mailing list